Best Practice für die Speicherung großer Datenmengen mit J2ME

Question

Ich entwickle eine J2ME-Anwendung, die eine große Menge an Daten auf dem Gerät speichern muss (im Bereich von 1 MB aber variabel). Ich kann mich nicht auf das Dateisystem verlassen, deshalb stehe ich auf dem Record Management System (RMS), das mehrere Plattenspeicher erlaubt, aber jeder eine begrenzte Größe hat. Meine anfängliche Zielplattform, Blackberry, begrenzt jedes auf 64KB.

Ich frage mich, ob jemand anderes das Problem der Speicherung einer großen Datenmenge im RMS und wie sie es bewältigt hat, angehen musste? Ich denke daran, Datensatzgrößen zu berechnen und einen Datensatz über mehrere Filialen hinweg aufzuteilen, wenn es zu groß ist, aber das fügt viel Komplexität hinzu, um es intakt zu halten.

Es gibt viele verschiedene Arten von Daten, die gespeichert werden, aber nur ein Satz überschreitet die Grenze von 64 KB.

Answer 1

Für etwas mehr als ein paar Kilobyte müssen Sie entweder JSR 75 oder einen Remote-Server verwenden. RMS-Aufzeichnungen sind in Größe und Geschwindigkeit extrem begrenzt, selbst in einigen höheren Handgeräten. Wenn Sie 1MB Daten in J2ME jonglieren müssen, ist die einzige zuverlässige, portable Möglichkeit, sie im Netzwerk zu speichern. Die HttpConnection-Klasse und die Methoden GET und POST werden immer unterstützt.

Auf den Handgeräten, die JSR 75 FileConnection unterstützen, kann es eine gültige Alternative sein, aber ohne Codesignierung ist es ein Albtraum für den Benutzer. Fast jeder einzelne API-Aufruf ruft eine Sicherheitsabfrage auf, die keine allgemeine Berechtigungsauswahl enthält. Unternehmen, die Apps mit JSR 75 bereitstellen, benötigen normalerweise für jeden Port ein halbes Dutzend Binaries, um nur einen kleinen Teil der möglichen Zertifikate abzudecken. Und dies ist nur für die Herstellerzertifikate; Einige Mobilteile haben nur trägergesperrte Zertifikate.

Answer 2

Ich denke, der flexibelste Ansatz wäre, ein eigenes Dateisystem auf dem RMS zu implementieren. Sie können die RMS-Datensätze auf ähnliche Weise wie Blöcke auf einer Festplatte behandeln und eine oder ähnliche verwenden, um logische Dateien über mehrere Blöcke zu verteilen. Ich würde empfehlen, eine Byte- oder stream-orientierte Schnittstelle oberhalb der Blöcke zu implementieren und dann eventuell eine weitere API-Schicht zum Schreiben spezieller Datenstrukturen hinzuzufügen (oder einfach Ihre Objekte serialisierbar zum Datenstrom zu machen).

Tanenbaum's classical book on operating systems behandelt, wie man ein einfaches Dateisystem implementiert, aber ich bin sicher, dass Sie andere Ressourcen online finden können, wenn Sie Papier nicht mögen.

Answer 3

Die RMS-Leistung und -Implementierung variiert stark zwischen den Geräten. Wenn also die Plattformportabilität ein Problem darstellt, kann es sein, dass Ihr Code auf einigen Geräten und nicht auf anderen Geräten funktioniert. RMS wurde entwickelt, um kleine Datenmengen (Highscore-Tabellen oder was auch immer) nicht große Mengen zu speichern.

Sie könnten feststellen, dass einige Plattformen schneller sind, wenn Dateien in mehreren Plattenläden gespeichert sind. Einige sind schneller mit mehreren Datensätzen in einem Geschäft. Viele sind für die Speicherung in Ordnung, werden aber beim Löschen großer Datenmengen aus dem Speicher unbrauchbar langsam.

Am besten verwenden Sie JSR-75 stattdessen, wo verfügbar, und erstellen Sie Ihre eigene Dateispeicherschnittstelle, die auf RMS zurückgreift, wenn nichts Besseres unterstützt wird.

Leider, wenn es um JavaME geht, werden Sie oft dazu gebracht, gerätespezifische Varianten Ihres Codes zu schreiben.

Answer 4

Ich fange gerade erst an, JavaME zu schreiben, habe aber Erfahrung mit alten Versionen von PalmOS, wo alle Datenblöcke in der Größe begrenzt sind, die das Design von Datenstrukturen mit Datensatzindizes und Offsets erfordern.

Answer 5

Unter Blackberry OS 4.6 wurde die Größenbeschränkung des RMS-Speichers auf 512 KB erhöht, aber das ist keine große Hilfe, da viele Geräte wahrscheinlich keine Unterstützung für 4.6 haben werden.Die andere Option auf Blackberry ist der Beständige Speicher, der eine Aufzeichnungsgröße von 64 KB hat, aber keine Begrenzung für die Größe des Speichers (abgesehen von den physikalischen Grenzen des Geräts).

Ich denke, Carlos und izb haben Recht.

Answer 6

Es ist recht einfach, verwenden Sie JSR75 (FileConnection) und vergessen Sie nicht, Ihr Midlet mit einem gültigen (vertrauenswürdigen) Zertifikat zu signieren.

Answer 7

Vielen Dank für alle nützlichen Kommentare. Am Ende bestand die einfachste Lösung darin, die Menge der gespeicherten Daten zu begrenzen, indem Code implementiert wurde, der die Daten entsprechend der Größe des Speichers anpasste und Daten vom Server bei Bedarf abrief, wenn sie nicht lokal gespeichert waren. Das ist interessant, dass das Limit in OS 4.6 erhöht wird, mit etwas Glück wird mein Code einfach selbst anpassen und mehr Daten speichern :)

Die Entwicklung einer J2ME-Anwendung für Blackberry ohne den einige was, da wir das Archiv nicht unterschreiben können. Wie von Carlos darauf hingewiesen, ist dies ein Problem auf jeder Plattform und ich hatte ähnliche Probleme mit dem PIM-Teil davon. Der RMS scheint auf der Blackberry-Plattform unglaublich langsam zu sein, so dass ich nicht sicher bin, wie nützlich ein Inode/B-Tree-Dateisystem oben wäre, es sei denn, Daten wurden im Speicher zwischengespeichert und in einem Hintergrundhintergrund mit niedriger Priorität in RMS geschrieben.

Answer 8

Nur lesen, ich komme zu akzeptablen Zeiten (innerhalb von 10s), indem Sie eine Ressourcendatei indizieren. Ich habe zwei ~ 800KB CSV-Preislistenexporte. Programmklassen und beide Dateien werden zu einem 300-KB-JAR komprimiert.

Bei der Suche ich eine List anzeigen und eine zwei Thread s im Hintergrund ausführen, um es zu füllen, so kommen die ersten Ergebnisse ziemlich schnell und sind sofort sichtbar. Ich habe zuerst eine einfache lineare Suche implementiert, aber das war zu langsam (~ 2min).

Dann indexierte ich die Datei (die alphabetisch sortiert ist), um den Anfang jedes Buchstabens zu finden. Jetzt vor dem Parsen Zeile für Zeile, zuerst InputStreamReader.skip() an die gewünschte Position, basierend auf dem ersten Buchstaben. Ich vermute, dass die Verzögerung hauptsächlich von der Dekomprimierung der Ressource herrührt, also würde die Aufteilung der Ressourcen sie weiter beschleunigen. Ich möchte das nicht tun, um den Vorteil eines einfachen Upgrades nicht zu verlieren. CSV wird ohne Vorverarbeitung exportiert.