Erste Schritte Spieler an anderen Frame weitergeben

[Creepaz]

Moin wiedermal,

ich glaube langsam werde ich mit meinen Fragen lästig, ich weiss

Ich habe 3 Frames: Der Login-Frame wo man sich anmeldet, der Registrations-Frame wo man sich einen Account erstellen kann und den Frame der sichtbar wird sobald man sich erfolgreich eingeloggt hat.

Was ich an der Sache aber voll und ganz vergessen habe, ist die Tatsache das ich im Eingeloggten Frame ja natürlich wissen müsste um welchen Spieler es sich gerade handelt. Ich habe in diesem Frame eine Menübar, wo ich einen bestimmten Punkt nur sichtbar machen möchte wenn der Spieler einen bestimmten Rang hat. Um diesen Rang abzufragen, muss ich ja wissen welcher Spieler sich gerade eingeloggt hat und das an diesen Frame eben weitergeben. Wie könnte ich das ganz am besten realisieren?

Zu meinem Login-/Registrationssystem: Ich frage mittels einer Datenbank ab ob der Spieler darin vorkommt, falls ja wird der Loginframe geschlossen und der eingeloggte Frame geöffnet. Deshalb sehe ich momentan keine Möglichkeit um diesen Spieler an den dritten Frame weiterzugeben.

 

[mihe7]

ich glaube langsam werde ich mit meinen Fragen lästig, ich weiss

Das glaub ich kaum, da gab es hier schon ganz andere...

das ich im Eingeloggten Frame ja natürlich wissen müsste um welchen Spieler es sich gerade handelt.

Was ist der "eingeloggte Frame"?

Um diesen Rang abzufragen, muss ich ja wissen welcher Spieler sich gerade eingeloggt hat und das an diesen Frame eben weitergeben. Wie könnte ich das ganz am besten realisieren?

Poor man's Variante: Login per Dialog. Nach dem Login den Frame erzeugen und dabei den Spieler mitgeben. Ansonsten: Google mal nach MVC.

Allgemeiner Tipp: bau die Anwendung erst ohne GUI, die kannst Du im Anschluss immer noch dranhängen.

 

[Creepaz]

Das glaub ich kaum, da gab es hier schon ganz andere...


Was ist der "eingeloggte Frame"?


Poor man's Variante: Login per Dialog. Nach dem Login den Frame erzeugen und dabei den Spieler mitgeben. Ansonsten: Google mal nach MVC.

Allgemeiner Tipp: bau die Anwendung erst ohne GUI, die kannst Du im Anschluss immer noch dranhängen.

Na dann hoffe ich mal das ich in nächster Zeit nicht zu den anderen dazugehöre

Die Variante die du mir geschrieben hast, hatte ich tatsächlich auch so im Kopf, wollte nur eben erstmal was essen. Ich habe jetzt einen String erstellt, dieser wird beim Einloggen mit dem Username übergeben an meinen eingeloggten Frame. Dadurch kann ich den Spielername von dem String auslesen, und so wieder alle Spielerdaten der Datenbank auslesen.

Besten Dank

 

[Robat]

Anstatt verschiedene JFrame Instanzen zu erstellen kannst du nur 1 JFrame benutzen und den Inhalt austauschen. Das geht zB über das CardLayout.

 

[Creepaz]

Okay, dann werde ich mir das bei Zeiten mal anschauen wenn es im Endeffekt soweit ist. Danke dir, wusste ich nicht. Habe jetzt für jeden "Bereich" einen neuen JFrame erstellt ._.

 

[mihe7]

Na dann hoffe ich mal das ich in nächster Zeit nicht zu den anderen dazugehöre

Ne, die Gefahr sehe ich bei Dir nicht - außer Du hast vor, schlagartig sämtliche Lernbereitschaft (bzw. -fähigkeit) einzustellen und Threads mit mehreren Hundert Kommentaren zu provozieren, damit Dir jemand Deine Aufgabe löst

 

[Robat]

@mihe7 oder wenn er 100k verdienen will

 

[mihe7]

@mihe7 oder wenn er 100k verdienen will

Den meinte ich

 

[Creepaz]

Nö, das glaube ich jetzt doch nicht Darum frage ich hier immer nach, mir werden Optionen genannt die möglich sind, evtl. mit einem kleinen Stücken Code als Hilfe den ich mir dann selbst zurechtbastel (oder basteln muss) -> und meiner Meinung nach ist das genau der richtige Weg um sowas zu lernen

 

[Creepaz]

Aber verwirrt bin ich gerade trotzdem.. der mag mir den Spieler nicht übergeben.

Database.java -> verarbeitet alles wegen Login. In der Funktion checkPlayerLogin wird der String "fetchUsername" auf username gesetzt. Sprich auf den Name des Spielers. In der selben Klasse gibt es die Funktion initializePlayer() wo fetchUsername dann returned wird.

LoggedInPage.java -> Hier landet man bei erfolgreichem Login. Dort gebe ich mir zum Testen eine Message. Die Message frage ich ab mit Database.initializePlayer(), kriege aber nicht den Usernamen sondern stets immer null... Warum? Bin mit meinen Möglichkeiten schon wieder am Ende. Total simpel wahrscheinlich, nur zu doof zum kapieren ._.

 

[Creepaz]

So, ich habe es jetzt gelöst.. aber ich glaube ihr werdet mich erschlagen *pfeif*

Das Problem war, dass die Message zu früh kam, sprich er hatte den Name noch nicht geladen. Jetzt habe ich es so gelöst, dass ich mir in der Klasse einen String username = ""; angelegt habe.

Der Title des Fensters wird in der Database gesetzt, sprich username + "Eingeloggt". In meiner LoggedInPage splitte ich den title, jage das ganze durch einen Timer und sobald das Fenster vollständig offen ist, danach wird erst die Message angezeigt. Sprich sobald der Timer abläuft (1000ms, 1 Sek) wird mir in der Message der Name angezeigt

Schwere Geburt und wahrscheinlich schlechte Lösung.. aber besser als gar keine Lösung, erstmal zumindest..


Edit: Bringt mir nix.. möchte den Spieler in der JMenuBar einfügen und das haut natürlich nicht hin wenn die Menübar schon gebaut ist bevor der Timer abläuft ._.

 

[Robat]

Zeig mal deinen Code dazu

 

[Creepaz]

Hi,

habe gestern noch eine Lösung gefunden aber wollte jetzt nicht nochmal auf einen eigenen Post antworten Die Lösung war jetzt, dass ich den Frame mit einer Verzögerung von 0,5 Sekunden öffnen lassen, was für den Code genügend Zeit ist um den Username als String an die Variable weiterzugeben. Davor war mein Fehler, dass ich es genau anders rum hatte und mir das dann nichts gebracht hat.

Wenn ich von der Spätschicht daheim bin poste ich später mal den dazugehörigen Code

 

[mihe7]

Die Spätschicht scheint länger geworden zu sein

 

[Creepaz]

Sorry, hatte die letzten Tage keine Zeit. Code kommt gleich

 

[Creepaz]

In der LoggedInPage.php:

public static String username; //Eingeloggter Spieler

Funktion um Spielerlogin zu prüfen, mit dem Timer:

public static void checkPlayerLogin(String username, String password) {
  try {
   con = DriverManager.getConnection("jdbc:mysql://localhost/levelinggame?useUnicode=true&useJDBCCompliantTimezoneShift=true&useLegacyDatetimeCode=false&serverTimezone=UTC", "root", "");
   stmt = con.prepareStatement("select * from userdata where username = ?");
   stmt.setString(1, username);
   rs = stmt.executeQuery();
   
   boolean userExists = rs.next();
   
   if(userExists != false) {
    String uPWD = password;
    int activated = rs.getInt("activated");
    if(uPWD.equalsIgnoreCase(rs.getString("PASSWORD"))) {
     if(activated == 1) {
      //Eingeloggt
      Timer timerCheckLogin = new Timer(true);
      timerCheckLogin.schedule(new Database(), 100);
     
      LoggedInPage.username = username;
      FrameCreator.frameLogin.setVisible(false);
     } else {
      JOptionPane.showMessageDialog(null, "Dein Account ist vorrübergehend deaktiviert!", "Account deaktiviert", JOptionPane.PLAIN_MESSAGE);
     }
    } else {
     //Login fehlgeschlagen!
     JOptionPane.showMessageDialog(null, "Falsches Passwort eingegeben!", "Falsche Anmeldedaten", -1);
    }
   } else {
    JOptionPane.showMessageDialog(null, "Dein Account wurde nicht gefunden! \n\nBitte registriere dich zuerst!", "Kein Account gefunden", -1);
   }
  } catch (SQLException e) {
   e.printStackTrace();
  }
 }

Der Timer:

@Override
 public void run() {
  try {
   new LoggedInPage();
  } catch (SQLException e) {
   e.printStackTrace();
  }
  
  FrameCreator.loggedIn.setTitle(LoggedInPage.username + " | Eingeloggt");
  FrameCreator.loggedIn.setVisible(true);
 }

Also so funktioniert das ganze nun ohne Probleme. Werde aber wenn ich mal wieder etwas Zeit hab, den Spieler nichtmehr als String eingeben sondern direkt auf Player xy umbauen. Scheint mir wohl doch logischer.

 

[mihe7]

Also so funktioniert das ganze nun ohne Probleme.

Das wage ich zu bezweifeln. Wenn Du hier einen Timer brauchst, stimmt was nicht. Außerdem schließt Du weder Statement, noch Connection und wer überall mit static arbeitet, bekommt früher oder später mit an Sicherheit grenzender Wahrscheinlichkeit ein Problem

 

[Creepaz]

Naja, das mit dem Timer liegt daran, dass dieser Frame direkt beim Starten des Programms generiert wird und so auch der Username auf null gesetzt wird. Durch den Timer habe ich die benötigte Verzögerung, um alles zu übergeben (was niemals 0,5 Sekunden dauert einen String zu übergeben - ohne Timer will er trotzdem nicht :O)

Inzwischen habe ich tatsächlich einiges dazu gelernt, und weiß das es k*** erstellt wurde. Allerdings soll das mehr oder weniger als Test und Versuchsobjekt dienen, weshalb ich nicht nochmal alles komplett neu aufbauen möchte ;-)

 

[Creepaz]

@mihe7 Könntest du mir evtl kurz nochmal erklären, warum genau die static-Methoden evtl. irgendwann mal Probleme bereiten können wenn jetzt aktuell alles funktioniert? Ich weiss vom Sinn her das es blöd aufgebaut ist, aber weshalb Probleme auftreten könnten da bin ich noch nicht ganz mitgekommen.

 

[mihe7]

static-Methoden sind per se nicht das große Problem, so lange sie reine Funktionen darstellen, also keine Änderungen vornehmen (Beispiel: Math.sin()). Für die funktionale Programmierung ist das äußerst praktisch. Meistens wird aber auf andere Variablen zugegriffen, die dann ebenfalls static sein müssen und damit global zur Verfügung stehen.

Gerade diese Eigenschaft erscheint sehr praktisch, schließlich man kann von überall auf solche Variablen zugreifen, ohne sich mit irgendwelchen Objekten herumschlagen zu müssen. Tatsächlich gibt man dadurch aber etwas aus der Hand, das ich als die logische Struktur der Anwendung bezeichnen würde: das Zusammenspiel der Einzelteile zur Laufzeit. Da man einer Methode von außen nicht ansieht, was sie intern macht, weißt Du nie, auf welche statischen Variablen in welcher Form zugegriffen wird (ohne sich den Code der Methode im Detail anzusehen).

Weiß der Programmierer nicht genau, was er tut, bekommst Du Spaghetti-Code, durch den die Anwendung z. T. fürchterlich fragil wird. Dadurch tritt dann z. B. unerwünschtes Verhalten der Anwendung auf, das sich zunächst nicht erklären lässt. Um die Ursachen zu finden, suchst Du Dich dumm und dusselig.

Es gibt noch ein paar weitere Punkte, wie z. B. der Verlust von Polymorphie oder der Testbarkeit aber das führt jetzt zu weit und der Punkt oben sollte Erklärung genug sein, warum static nur "wohl dosiert" eingesetzt werden sollte

 

[Xyz1]

@Creepaz Wenn Du alles statisch machst - also auch statische innere Klassen usw. dann läufst Du ab einer gewissen Levelhöhe in einen Bug. Das hatte ich auch schonmal, es kann aber sein das dieser Bug in Java > 8 inzwischen behoben wurde.

Also wär es ratsam, strikt objektorientiert vorzugehen.

 

[Creepaz]

@mihe7 & @Tobias-nrw

Vielen Dank für die ausfürlichen Antworten. Habe nun wohl endlich mal kapiert, was das ganze ausmacht. Werde dann in meinen nächsten Projekten schauen, dass Funktionen usw. um einiges besser gegliedert werden, um eben nicht alles auf static schreiben zu müssen.

Tobias, bis jetzt hatte ich noch keinen Bug, aber so wie ich das rausgelesen habe ist das auch nur noch eine Frage der Zeit. Werde mich wohl nun doch mal hinsetzen und alles umschreiben, das alles so funktioniert wie es sein soll.

 

[mihe7]

dann in meinen nächsten Projekten schauen, dass Funktionen usw. um einiges besser gegliedert werden, um eben nicht alles auf static schreiben zu müssen.

Wundere Dich nicht: das wird anfangs nicht leicht. Tipp: schreib Deine Anwendung erst ohne GUI.

 

[Creepaz]

Wundere Dich nicht: das wird anfangs nicht leicht. Tipp: schreib Deine Anwendung erst ohne GUI.

Ja, mache ich jetzt gerade auch schon, wirkt um einiges entspannter schonmal. Und wie ich das alles sauber gliedern kann, muss ich mich dann mal noch etwas belesen. Sowohl vom Code als auch von den Klassen.