Best Practice zum Speichern großer Datenmengen mit J2ME
https://stackoverflow.com/questions/19011
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianFrage
Ich entwickle eine J2ME-Anwendung, die eine große Datenmenge auf dem Gerät speichern muss (ca. 1 MB, aber variabel).Da ich mich nicht auf das Dateisystem verlassen kann, bin ich auf das Record Management System (RMS) angewiesen, das zwar mehrere Plattenspeicher zulässt, aber jeweils eine begrenzte Größe hat.Meine ursprüngliche Zielplattform, Blackberry, begrenzt jeweils 64 KB.
Ich frage mich, ob sich noch jemand mit dem Problem der Speicherung großer Datenmengen im RMS auseinandersetzen musste und wie er damit umgegangen ist?Ich denke darüber nach, die Datensatzgrößen berechnen zu müssen und einen Datensatz auf mehrere Geschäfte aufzuteilen, wenn er zu groß ist, aber das erhöht die Komplexität erheblich, um ihn intakt zu halten.
Es werden viele verschiedene Datentypen gespeichert, aber nur ein Satz überschreitet die 64-KB-Grenze.
Lösung
Für alles, was über ein paar Kilobyte hinausgeht, müssen Sie entweder JSR 75 oder einen Remote-Server verwenden.RMS-Datensätze sind in Größe und Geschwindigkeit extrem begrenzt, selbst bei einigen High-End-Handys.Wenn Sie 1 MB Daten in J2ME verwalten müssen, ist die Speicherung im Netzwerk die einzig zuverlässige und tragbare Möglichkeit.Die HttpConnection-Klasse und die Methoden GET und POST werden immer unterstützt.
Auf Mobiltelefonen, die JSR 75 FileConnection unterstützen, ist es möglicherweise eine gültige Alternative, aber ohne Codesignatur ist es ein Albtraum für die Benutzererfahrung.Fast jeder einzelne API-Aufruf ruft eine Sicherheitsabfrage ohne pauschale Berechtigungsauswahl auf.Unternehmen, die Apps mit JSR 75 bereitstellen, benötigen in der Regel ein halbes Dutzend Binärdateien für jeden Port, nur um einen kleinen Teil der möglichen Zertifikate abzudecken.Und das gilt nur für die Herstellerzertifikate;Einige Mobiltelefone verfügen nur über betreibergebundene Zertifikate.
Andere Tipps
RMS-Leistung und -Implementierung variieren stark zwischen den Geräten. Wenn also die Plattformportabilität ein Problem darstellt, kann es sein, dass Ihr Code auf einigen Geräten gut funktioniert und auf anderen nicht.RMS ist darauf ausgelegt, kleine Datenmengen (Highscore-Tabellen oder was auch immer) und nicht große Datenmengen zu speichern.
Möglicherweise stellen Sie fest, dass einige Plattformen schneller sind, wenn die Dateien in mehreren Plattenläden gespeichert sind.Einige sind mit mehreren Datensätzen in einem Geschäft schneller.Viele sind für die Speicherung in Ordnung, werden jedoch unbrauchbar langsam, wenn große Datenmengen aus dem Speicher gelöscht werden.
Am besten verwenden Sie stattdessen JSR-75, sofern verfügbar, und erstellen Sie Ihre eigene Dateispeicherschnittstelle, die auf RMS zurückgreift, wenn nichts Besseres unterstützt wird.
Wenn es um JavaME geht, werden Sie leider oft dazu verleitet, gerätespezifische Varianten Ihres Codes zu schreiben.
Ich denke, der flexibelste Ansatz wäre die Implementierung eines eigenen Dateisystems auf dem RMS.Sie können die RMS-Datensätze ähnlich wie Blöcke auf einer Festplatte behandeln und a Inode-Struktur oder ähnliches, um logische Dateien über mehrere Blöcke zu verteilen.Ich würde empfehlen, eine Byte- oder Stream-orientierte Schnittstelle über den Blöcken zu implementieren und dann möglicherweise eine weitere API-Schicht darüber zu erstellen, um spezielle Datenstrukturen zu schreiben (oder Ihre Objekte einfach für den Datenstrom serialisierbar zu machen).
Tanenbaums klassisches Buch über Betriebssysteme behandelt, wie man ein einfaches Dateisystem implementiert, aber ich bin sicher, dass Sie online andere Ressourcen finden können, wenn Sie kein Papier mögen.
Unter Blackberry OS 4.6 wurde die RMS-Speichergrößenbeschränkung auf 512 KB erhöht, aber das hilft nicht viel, da viele Geräte wahrscheinlich keine Unterstützung für 4.6 haben.Die andere Option auf Blackberry ist der Persistent Store, der eine Datensatzgrößenbeschränkung von 64 KB, aber keine Beschränkung der Speichergröße hat (abgesehen von den physischen Grenzen des Geräts).
Ich denke, Carlos und izb haben Recht.
Es ist ganz einfach: Verwenden Sie JSR75 (FileConnection) und denken Sie daran, Ihr Midlet mit einem gültigen (vertrauenswürdigen) Zertifikat zu signieren.
Für den schreibgeschützten Zugriff erreiche ich akzeptable Zeiten (innerhalb von 10 Sekunden), indem ich eine Ressourcendatei indiziere.Ich habe zwei ca. 800 KB große CSV-Preislistenexporte.Programmklassen und beide Dateien werden in ein 300-KB-JAR komprimiert.
Bei der Suche zeige ich ein List und eine Zwei ausführen ThreadEs wird im Hintergrund ausgeführt, um es zu füllen, so dass die ersten Ergebnisse ziemlich schnell vorliegen und sofort sichtbar sind.Ich habe zuerst eine einfache lineare Suche implementiert, aber das war zu langsam (~2 Minuten).
Dann habe ich die Datei (die alphabetisch sortiert ist) indiziert, um die Anfänge jedes Buchstabens zu finden.Bevor ich nun Zeile für Zeile parse, muss ich zunächst Folgendes tun InputStreamReader.skip() an die gewünschte Position, basierend auf dem Anfangsbuchstaben.Ich vermute, dass die Verzögerung hauptsächlich auf die Dekomprimierung der Ressource zurückzuführen ist, sodass eine Aufteilung der Ressourcen die Geschwindigkeit noch weiter erhöhen würde.Ich möchte das nicht tun, um den Vorteil des einfachen Upgrades nicht zu verlieren.CSV werden ohne Vorverarbeitung exportiert.
Ich fange gerade erst an, für JavaME zu programmieren, habe aber Erfahrung mit alten Versionen von PalmOS, bei denen alle Datenblöcke in ihrer Größe begrenzt sind, was den Entwurf von Datenstrukturen mithilfe von Datensatzindizes und Offsets erfordert.
Vielen Dank an alle für nützliche Kommentare.Am Ende bestand die einfachste Lösung darin, die Menge der gespeicherten Daten zu begrenzen, Code zu implementieren, der die Daten an die Größe des Speichers anpasst, und Daten bei Bedarf vom Server abzurufen, wenn sie nicht lokal gespeichert sind.Interessant ist, dass das Limit in OS 4.6 erhöht wurde. Mit etwas Glück passt sich mein Code einfach von selbst an und speichert mehr Daten :)
Die Entwicklung einer J2ME-Anwendung für Blackberry ohne Verwendung des .cod-Compilers schränkt die Verwendung von JSR 75 etwas ein, da wir das Archiv nicht signieren können.Wie Carlos betonte, ist dies auf jeder Plattform ein Problem, und ich hatte ähnliche Probleme bei der Verwendung des PIM-Teils davon.Das RMS scheint auf der Blackberry-Plattform unglaublich langsam zu sein, daher bin ich mir nicht sicher, wie nützlich ein darüberliegendes Inode/B-Tree-Dateisystem wäre, es sei denn, die Daten würden im Speicher zwischengespeichert und in einem Hintergrundthread mit niedriger Priorität in RMS geschrieben.
