Java Speichern und Laden von Gui Komponenten

[FrazeColder]

Hey Community,

Ich habe eine GUI entworfen und würde gerne den Status speichern und laden können.
Wie kann ich also, die ganzen Eigenschaften der ganzen Komponenten speichern und laden?

Ich habe das hier schon gefunden:
http://stackoverflow.com/questions/8280951/java-read-and-save-gui-elements

Allerdings funktioniert es bei mir nicht...

MfG und Danke!

 

[Nexialist.]

Ich rate dir, mach die GUI mit Scenebuilder und JavaFX. (youtube-videos ansehen...)

 

[HominiLupus]

Allerdings funktioniert es bei mir nicht...

Die Menge an Information erschlägt einen geradezu. IIRC alle Swing Klassen implementieren serializable.

 

[ICH_BIN_LETZTER]

Hi,

ich würde dich beim Wort nehmen. Speichere dir den Status nicht die GUI. Wenn du sauber entwickelt hast macht das so durchaus mehr Sinn (m.M.n)

Achtung PseudoCode

class ZustandGUI {
 wert1,
 wert2,
 wert3
}

Class GUI {

  ZustandGUI  zustand

  setZustand(ZustandGUI neu ) {
    zustand =  neu
    updateGUI()
  }

Den Zustand persistierst du dann nach blieben, Platte (Serializable), DB (DAO, DTO, ....)

Gruß....

 

[DieFritte]

Ich würde dir auch raten nur die Zustände zu speichern. Die GUI hast ja schon fertig programmiert und die entsprechenden Zustände kannst ja dann einfach in XML Format speichern oder DB. Später musst du dann nur noch beim Start die Zustände auslesen und entsprechend Parsen. DB oder XML dürften sich da von der Geschwidigkeit nicht viel schenken (je nach größe).

Du kannst aber auch die komplette GUI in ein XML-Format Speichern. So könntest du ggf. noch änderungen an der GUI im XML vornehmen.

Ich würde aber generell dazu tendieren nur die Zustände zu speichern.

 

[FrazeColder]

Und wie kann ich die Zustände mir speichern bzw. auslesen lassen?
Ich denke mal, dafür gibt es ein Befehl oder eine Schleife und ich muss nicht jeden einzelne CheckBox oder Textfield etc. nach Editable, Selectable usw. abfragen?

 

[DieFritte]

Ich glaube eine vorgefertigte Funktion/Methode gibts dafür glaube ich nicht (zumindest fällt mir auf die schnelle keine ein). Du müsstest dir da am besten was eigenes Schreiben. Die GUI ist ja warsch. wie in einem Tree aufgebaut. Du gehst dann einfach den Kompletten Tree mit schleifen durch gehen und prüfst um was für ein Objekt es sich handelt und dem entsprechend werden dann die Zustände abgefragt und gespeichert.

So in der Art würde ich das machen.

Ein Art wie man es noch machen könnte, wäre einfach beim Ändern der GUI im Betrieb die Änderungen entsprechend mit zu schreiben und in einer extra Klasse zu Speichern. So müsstest du nicht den Kompletten GUi-Tree durch gehen sondern du hast in der (extra) Klasse die Voreinstellungen für die GUI und sobald dein User etwas änder wird dies direkt in der Klasse geändert. Zum Schluss speicherst du dann nur die Zustände in der Klasse ab. Wenn die GUI wieder geladen wird, holt die sich ihre Daten aus dieser einen Klasse.

 

[JenZor]

Wie wäre es, wenn du ein Observer Pattern implementierst, mit dem, was DieFritte vorgeschlagen hast.

Du Baust dir eine Klasse ZustandsInformation, die alle wesentlichen Informationen zu deiner GUI hält.
Diese Klasse implementiert das Interface Observer und beobachtet damit das die Klasse Observerable erweiterne GUI Objekt. Das ZustandsInformation Objekt wird per

Observable.addObserver(Observer o)

als Beobachter bei der GUI angemeldet.
Treten Änderungen in der GUI auf, die den Zustand ändern, wird dann eine Benachrichtigungsfunktion (Observerable.notifyObservers(...)) aufgerufen und du kannst die Informationen direkt beim Ändern weitergeben. Dadurch hast du deine ZustandsInformation immer aktuell.
Anstelle eines Pulls (ich möchte die GUI speichern, also brauch ich jetzt ein Pull auf die ganzen Daten und ich muss mich selbst drum kümmern) hättest du ein Push (Ich will die GUI Zustände speichern, ich brauche die Daten, wie gut, dass die on the fly bereits aufgezeichnet wurden).

Erspart dir das einmalige Durchlaufen der gesamten GUI und das rausfischen der Infos, auf der anderen Seite bekommst du so jede Änderung mit. Alle Änderungen müssen verarbeitet werden, wenn du das nicht filterst und es kann passieren, dass du bei vielen Änderungen, bevor die GUI gespeichert wird erstmal ne Menge Performance brauchst um die Infos immer aktuell zu halten.

Dazu gibt es diverse Tutorials im Netz, z.B. sowas dieses hier.
Mehr Lesestoff dazu gibt's auch auf Wikipedia.

Sollte deine GUI nur einie Zustände erreichen, dann könntest du auch drüber nachdenken das State Design Pattern umzusetzen.


Es gibt auch noch ein paar andere Design Pattern, die du vlt für nützlich erachtest, ließ dich einfach mal schlau drüber.


Grüße

J.

 

[kuddlmuddl]

Ich hatte das selbe Problem (unter C++ mit QT) und habe es auch so gelöst wie vorgeschlagen:
Verstellt man einen Parameter wird auf diesen veränderten Parameter normal reagiert und zusätzlich wird dieser gewählte Wert im 'Backend' gespeichert. Beim starten der Software initialisiere ich dann die Gui mit Werten des Backends - manuell. Das nervt natürlich und ist Fehleranfällig aber mir wäre neu, dass man das eleganter hinbekommt.
Selbst wenn jedes Ui-Element (QWidget) leicht seralisierbar wäre und ich es bei jedem Programmstart wieder herstellen KÖNNTE wäre das noch keine Lösung: Macht mein Backend etwas und braucht zB den Wert des oben genannten Parameters dann nutze ich natürlich den im Backend hinterlegten und frage nicht das UI Element. Hier könnte man jetzt denken:
"Wozu doppelt speichern? Der Parameter könnte ausschließlich durch den Zustand in der Ui existieren?"
=> Das würde aber bedeuten, das mein Backend an jeder Stelle wo dieser Parameter verwendet wird auf dieses Ui Element zugreifen können muss - und dadurch muss quasi alles global erreichbar werden, was natürlich gegen hohe kohäsion spricht und die Ui viel zu stark mit der eigentlichen Programmlogik koppelt.

Durch diesen Weg ergibt sich ein positiver Nebeneffekt: Mein Programm erlaubt das schnelle wechseln zwischen verschiedenen Parametersätzen. Jedesmal wenn dies geschieht muss die gesamte UI aktualisiert werden damit jeder Regler eben diese neuen Werte anzeigt. Hierzu nutze ich natürlich die selbe Funktion wie zum Programmstart und spätestens jetzt hat sich der Aufwand so einer Funktion "restoreSettingsToUi" gelohnt.