Options möglichkeiten? Speichern und beliebig Laden?!

A

Alex Großmann

Erfahrenes Mitglied
Hiho!

Ich möchte mal wissen wie bzw ob folgendes möglich ist:
In Programmen gibts ja immer Optionsmöglichkeiten, die kann man beliebig Ändern und dann für die Ewigkeit abspeichern...

Ich mag mit Swing jetzt nen Programm schreiben was dann eben ein Optionsmenü bietet um gewisse Daten die in Berechnungen vorkommen zu ändern. Also z.B. den Mehrwertsteuersatz und sowas :)

Gibts da möglichkeiten?

Würde mich sehr freuen :)
Grüße
 
Hi

sicher gibts da Möglichkeiten.
aber was genau weißt du nicht?

Wie man solche Optionsdinger (Radioboxen etc) grafisch erstellt?
Wie man das abspeichert/lädt?
...?
 
Wie man das abspeichert und lädt ;)
Also z.b. jetzt die Mehrwertsteuer:
In einem Neuen Frame, das wo die ganzen Optionen drin sind, soll es möglich sein die % Zahl von z.b. 19 auf 15 umzuändern. Dann solls eben gespeichert werden und so in die Variable die für die Mehrwertsteuer verantwortlich ist, übernommen werden.

Ich kann mir einfach nicht so richtig vorstellen wie das geht? Die Daten würden ja von mir aus in ne neue Datei angelegt werden und die könnte dann ausgelesen werden... ICh mein, so Options Lösungen bietet ja echt jedes Programm an, daher wäre das ja schon sehr gut zu wissen :)

Danke ;)
 
Viele Programme arbeiten hier mit Registry-Einträgen, was für Java allerdings aufgrund der Plattformunabhängigkeit eher kontraproduktiv ist. Daher sind wiederum viele auf eine config-Datei umgestiegen, die beim Öffnen geladen und bei Änderungen geschrieben wird. Aufgrund der Änderungen während der Laufzeit hat sich hier das XML-Format hervorgehoben. Änderungen geschehen ja immer in irgendeiner Zeile, die man immer erst Suchen müsste. XML-API's bieten Möglichkeiten einfach zu sagen ändere mir den Wert des Attributes x, außerdem sind XML-Dateien einfacher erweiterbar, wenn man z.B. verschiedene Profile anlegen möchte.
 
Oder man nimmt ganz stumpf die ini-Datei-Variante, welche die Klasse Properties verwendet. mit store() speichert man die Properties ab und mit load() werden se halt geladen.

XML ist an sich ja nicht schlecht, hat sich auch in vielen Bereichen, wie z.B. Kommunikation oder Datenaustausch etabliert, ist aber etwas overpowert für solche Kleinigkeiten.
 
Ich stimme Akeshido zu, Properties ist hier angebracht.
XML rentiert sich, wenn du Anwendungen mit >50 Einstellungen hast
 
Hallo,

Ich weiß nicht ob das der Overkill wäre, jedoch wundert es mich warum noch niemand serialisierte Objekte erwähnt hat.

Lieber Threadersteller, du könntest dann einfach ein Objekt haben welches die Eigenschaften hält und dieses auf die Festplatte schreiben sowie irgendwann später wieder auslesen.

Diese Methode ist viel einfacher als die Erstellung von XML Dateien und bequemer als Properties, da Properties nur Strings seien dürfen.

Bei serialisierten Objekten sind alle Arten von Objekten möglich welche das "Serializable" Interface implementieren sowie alle Grunddatentypen.

Die Wahl der richtigen Methode ist abhängig von der Anzahl und Art der Eigenschaften.

Denn es macht einen großen Unterschied ob man nur einen boolschen Wert (Checkboxes), eine Vektorgraphik oder eine Stringtabelle abspeichern möchte.

Properties, serialisierte Objekte, XML, SQL Datenbanken, alles ist möglich aber nicht immer nötig.

Was Properties und Properties als XML angeht kann ich wie immer das Openbook "Java ist auch eine Insel" empfehlen:

http://openbook.galileodesign.de/javainsel5/javainsel11_006.htm#Rxx747java11006040003921F020100

Dort gibt es eine nette Einführung.


Und hier das Thema: "Persistente Objekte und Serialisierung":

http://openbook.galileodesign.de/javainsel5/javainsel12_013.htm#Rxx747java12013040004041F046100


Liebe Grüße,
Martin C.
 
Aber selbst bei der Serialisierung würde ich die XML-Variante (XMLEncoder/XMLDecoder) der binären Variante (ObjectOutputStream/ObjectInputStream) vorziehen. Zum einen ist das Zeug dann wieder textbasiert abgelegt (is irgendwie son Tick von Linuxern xD) und zum andern muss man sich dann nicht mit der serialVersionUID rumschlagen, was in diesem Fall nämlich nicht nötig ist.

EDIT:
Ach und von wegen Properties können nur Strings speichern: reicht doch. Ich habe noch nie erlebt, dass man in den Einstellungen irgendwelche Objekte abgespeichert hat. Zum Beispiel das mit den Dateien (Bilder, etc.), da wird eigentlich immer der Pfad abgespeichert und nicht die Datei als solches, hab ich jedenfalls so bei keinem Programm gesehen. Möglich ist es allerdings, das ist richtig.
 
Zuletzt bearbeitet:
Huhu,

Aber selbst bei der Serialisierung würde ich die XML-Variante (XMLEncoder/XMLDecoder) der binären Variante (ObjectOutputStream/ObjectInputStream) vorziehen. Zum einen ist das Zeug dann wieder textbasiert abgelegt (is irgendwie son Tick von Linuxern xD) und zum andern muss man sich dann nicht mit der serialVersionUID rumschlagen, was in diesem Fall nämlich nicht nötig ist.
Zum Vergrößern anklicken....

Das ist auch Geschmackssache.
Bei manchen Daten ist die Darstellung via XML jedoch weniger sinnvoll.
Dennoch stimmt es, dass man textbasierte Konfigurationsdateien besser warten kann, da man nicht auf externe Programme angewiesen ist (außer auf einen Texteditor).

Was die serialversionUID angeht, das ist überhaupt kein Problem.
Diese wird für die Klasse generiert - um die Checks kümmern sich die readXXX Methoden.

Ach und von wegen Properties können nur Strings speichern: reicht doch. Ich habe noch nie erlebt, dass man in den Einstellungen irgendwelche Objekte abgespeichert hat...
Zum Vergrößern anklicken....

Was Programmeinstellungen angeht - ja es reicht aus.
Auch wenn es etwas fehleranfälliger ist, da zum Beispiel Zahlen und boolsche Werte aus Strings geparsed werden müssen und man darauf vorbereitet sein sollte, dass User dort jeden Wert eintragen können.

Das hängt wie bereits erwähnt alles vom Verwendungszweck ab.
Habe ich jetzt zum Beispiel ein Zeichenprogramm werde ich die Arbeitsdatei nicht als XML abspeichern.

Da es hier aber um Properties geht wäre XML geeignet, jedoch ist vielleicht auch das (wie serialisierte Objekte) etwas zu viel des Guten.

mfg,
Martin
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück