user.home

[jf]

Hallo, Android ist ja eine Abart von Linux - allerdings klappte es im Test nicht, das AppData-Verzeichnis wie folgt zu ermitteln:

String appDataPath = System.getProperty("user.home");

Welches Konzept liegt diesbzgl. Android zugrunde?

 

[Gast2]

Hilft Dir das weiter?

 

[jf]

Hilft Dir das weiter?

Ich hatte die Seite leider erst nach meiner Frage gefunden - aber es bestehen dazu Restfragen:
Muss ich beim lesen der Datei stets mit read() arbeiten und in deiner Schleife jedes Byte einzeln auslesen?
Aus Effizienzgründen wäre mir das Auslesen in einen Puffer (Byte-Array) lieber - doch hierfür benötige ich die Länge der Datei. Da mir aber openFileInput() nur den Stream liefert, habe ich Schwierigkeiten, die die Größe der Datei zu ermitteln... - Wie macht ihr das?

 

[schlingel]

Was genau hast du den vor?

Aber prinzipiell mache ich das schon in einer Schleife in der ich einen Buffer immer wieder vollschreibe und mit den Daten etwas tue. Hausnummer 1024 byte Buffer oder so etwas.

 

[jf]

Was genau hast du den vor?

Ich möchte Daten über eine XML-Datei persistieren (serialisieren des Menü-Objektes). - Ich würde sagen, sie wird maximal 10k groß.

Aber prinzipiell mache ich das schon in einer Schleife in der ich einen Buffer immer wieder vollschreibe und mit den Daten etwas tue. Hausnummer 1024 byte Buffer oder so etwas.

Ok, an der Stelle würde ich sagen, kommt die "goldene Regel" zum Tragen: Optimierung erst wenn es wirklich nötig ist!
Ich wollte nur abklären, ob es nicht doch eine Möglichkeit gibt, die Datei komplett auf einmal einzulesen - ohne, dass eine Schleife nötig wäre...

 

[Gast2]

Optimiert finde ich es, wenn man eben nicht alles erst mal in den Speicher müllt, sondern das Häppchenweise macht?! Vielleicht haben wir da ein unterschiedliches Verständnis von optimiert.

Im übrigen mache ich es auch so, sei es Dateien zu lesen, Streams zu lesen, XXX zu lesen. Ausnahmen gibts da bei mir meist nur in Config Dateien (xml) welche ich direkt komplett parsen lasse (von der lib) um dann den Object tree auszuwerten.

 

[jf]

Optimiert finde ich es, wenn man eben nicht alles erst mal in den Speicher müllt, sondern das Häppchenweise macht?! Vielleicht haben wir da ein unterschiedliches Verständnis von optimiert.

Nein, je nachdem WAS man eben optimiert:
man kann das vollständige Einlesen einer Datei optimieren - oder aber den Einlesevorgang ansich, wie du schreibst.

Im übrigen mache ich es auch so, sei es Dateien zu lesen, Streams zu lesen, XXX zu lesen. Ausnahmen gibts da bei mir meist nur in Config Dateien (xml) welche ich direkt komplett parsen lasse (von der lib) um dann den Object tree auszuwerten.

Und genau so eine Ausnahme habe ich hier ja.
PS: verwendest du auch die lib xstream?

 

[Gast2]

Verwende JDOM für XMLs.

 

[Gast2]

Ich möchte Daten über eine XML-Datei persistieren (serialisieren des Menü-Objektes). - Ich würde sagen, sie wird maximal 10k groß.

Wäre das sqlite-Built-in von Android hier evtl. eine Alternative?

Ok, an der Stelle würde ich sagen, kommt die "goldene Regel" zum Tragen: Optimierung erst wenn es wirklich nötig ist!

Eine sehr gewagte Aussage!

 

[jf]

Wäre das sqlite-Built-in von Android hier evtl. eine Alternative?

Nein: das Menü ändert sich je nach Einsatzzweck. Momentan bin ich mir noch nicht sicher, ob ich eine Funktion in die Anwendung aufnehme, welche es erlaubt ein Menü anzulegen - oder ob dies am Rechner passiert (da dies mit Tastatur und Maus wesentlich komfortabler ist) und die xml dann einfach auf das Andorid-Gerät kopiert wird.

Eine sehr gewagte Aussage!

Überhaupt nicht! - Warum den Code unleserlicher und anfälliger für Fehler machen und dabei noch Zeit verschwenden, wenn es am Schluss keinen merklichen Unterschied bringt??? :noe:

 

[schlingel]

Ok, an der Stelle würde ich sagen, kommt die "goldene Regel" zum Tragen: Optimierung erst wenn es wirklich nötig ist!

Sehe ich auch so. Erst wenn ich Probleme habe fange ich zu messen an und optimiere an den Stellen deren Optimierung tatsächlich etwas bringen. Aber mit einem byte-buffer arbeiten ist wohl eher common(best?) practice als premature optimization.

10k sind schon ziemlich happig für ein Android System. Wenn du den Serializer-Weg gehen willst kannst du ORMLite für Android verwenden. Dann kannst du mit Objekten arbeiten hast aber trotzdem den Vorteil, dass das Lesen und Speichern schnell geht.

Allerdings dauert das Initialisieren des ORMLite-Objekts ziemlich lang. Das heißt wenn du es nur einmal aufrufst um das Menü aufzubauen, wäre es vielleicht sogar klüger du verwendest das gute alte Java Serializable oder Plain SQLite. Habe eigentlich mit allen bisher genannten Technologien gute Erfahrungen gemacht. Außer mit JDOM, das habe ich nur für Java SE verwendet, aber ansonsten kann ich die anderen (xstream, ormlite, sqlite, serializable) auch für Android empfehlen.

Die Aussage, dass Datenbanken nicht in Frage kommen weil sich die Daten ändern können auch auf anderen Plattformen sei mal einfach so dahingestellt, wenn den ORMLite und XSTREAM Annotations könntest du aber die selben Klassen verwenden.

 

[jf]

Aber mit einem byte-buffer arbeiten ist wohl eher common(best?) practice als premature optimization.

Klar, aber für einen reinen Funktionstest wäre es dennoch unötig.

10k sind schon ziemlich happig für ein Android System.

Man könnte evtl. auch über

getFilesDir()

den Pfad der Datei ermitteln und dann die Datei ohne Schleife in einen passenden Puffer lesen.

Wenn du den Serializer-Weg gehen willst [...]
ORMLite für Android
Java Serializable
SQLite
JDOM
XSTREAM

Huh, da gibt es ja genügend Auswahl...
Hat da schon mal jemand die Vor- und Nachteile der verschiedenen Technologien anlaysiert?

Die Aussage, dass Datenbanken nicht in Frage kommen weil sich die Daten ändern können auch auf anderen Plattformen sei mal einfach so dahingestellt

Ich würde das Menü gern am Rechenr erstellen und dann damit die xml auf dem Gerät ersetzen.
Wenn das Menü aber aus einer Datenbank gelesen wird, dann würde dieser Weg doch wegfallen, oder?

wenn den ORMLite und XSTREAM Annotations könntest du aber die selben Klassen verwenden.

Das habe ich nicht verstanden. Meintest du, dass ORMLite zu XSTREAM kompatibel ist - also von einem Objekt die gleiche xml-Struktur erzeugt wird?


[EDIT]In dem Beispiel der Doku wird einfach so

openFileOutput()

verwendet - bei mir mahnt Eclipse aber einen Fehler an (es kennt die Funktion nicht und bietet das Erstellen einer solchen Methode an).
Was ist hier nun schon wieder falsch...? :bahnhof:[/EDIT]

 

[schlingel]

wenn den ORMLite und XSTREAM Annotations könntest du aber die selben Klassen verwenden.

Damit ist gemeint, dass du einmal deine POJO-Klassen schreibst und die relevanten Member für DB und XML mit den Annotations des jeweiligen Framework ausstatten kannst.

Dann hättest du eine Klasse die eben die Annotations für die ORM- und für XML-relevanten Aspekte enthält.

Wenn du am Rechner die XML-Struktur erstellst und sie nur auslesen möchtest am Endgerät würde ich weder zu JDOM noch zu einem Serializer raten sondern zu einem SAX-Parser. Das ist viel schneller und speicher schonender.