Projektarbeit. Datenhaltung auf mobilen Endgeräten

Transkript

1 Projektarbeit Datenhaltung auf mobilen Endgeräten Georgi Georgiev März 2006 Betreuer: Prof. Dr. Paul Müller Dipl.-Wirtsch.-Ing. Jochen Müller Fachbereich Informatik AG Integrierte Kommunikationssysteme Universität Kaiserslautern Postfach Kaiserslautern

2

3 Ich versichere, dass ich die vorliegende Diplomarbeit selbstständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel verwendet habe. Kaiserslautern, <Datum> (Georgi Georgiev)

4

5 Abstract Die Erfassung, Bearbeitung und Visualisierung von Daten ist ein wichtiges Thema für mobile Anwendungen. Dieser Bereich hat sich in den letzten Jahren schnell entwickelt. Eine kritische Aufgabe von solchen Anwendungen ist es, Daten sicher und schnell zu speichern, zu lesen und zu suchen. Diese Arbeit untersucht die möglichen Ansätze und Vorgehensweisen bei der Datenspeicherung auf mobilen Plattformen. Dabei wird der Schwerpunkt auf eine effektive Nutzung der Ressourcen von mobilen Geräten gelegt. Speziell wird dies bei der Entwicklung von mobilen Anwendungen untersucht, dargestellt und bewertet. Abschließend wird ein mobiles Wörterbuch als Beispielanwendung entwickelt.

6

7 Inhaltsverzeichnis Inhaltsverzeichnis Kapitel 1: Einleitung...9 Kapitel 2: Mobile Plattformen Java 2 Plattform, MicroEdition (J2ME) J2ME Komponente Datenspeicherungsmöglichkeiten DoJa Symbian OS Einführung DBMS System File Zugriff System Microsoft Windows CE Einführung Dateisystem Datenbank Registry Zusammenfassung...19 Kapitel 3: Model Kompromisse der Anwendung Texteingabe Benutzerfreundlichkeit Kompression Datenspeicherungsansätze Dateibasierte Speicherung Native Datenbanken Datenbankportierung...23 Kapitel 4: Framework Datenerstellung Framework J2ME Framework Datenausleseframework Suchframework...25

8 Inhaltsverzeichnis GUI-Handling Framework HTTP Framework Internationalisation...26 Kapitel 5: Anwendungsentwicklung Anwendungsarchitektur Präsentationsschicht Suchschicht Ergänzende Hilfsklassen Anwendungsablauf Datenspeicherung Ähnliche Anwendungen Dictionary4Mid SlovoEd...39 Kapitel 6: Zusammenfassung...40 Kapitel 7: Anhang Literaturverzeichnis Abbildungsverzeichnis Code der Beispiel-Anwendung...42

9 Datenhaltung auf mobilen Endgeräten Kapitel 1: Einleitung Durch die stetig steigende Nachfrage nach mobilen, drahtlosen und überall einsetzbaren Geräten, wie z. B. PDAs, Smartphones, Handys und Notebooks, und deren immer besser werdende Leistungsfähigkeit, ergeben sich neue Möglichkeiten für mobile Anwendungen und Dienste. Bei der Entwicklung von Anwendungen für mobile Endgeräte stößt man häufig auf das Problem der persistenten Datenhaltung. Sowohl die Verwendung eines Datenbanksystems, als auch das Zurückgreifen auf eine richtige Datenbank mit Hilfe einer Client-Server Architektur scheint weder sinnvoll noch praktikabel. In dieser Projektarbeit werden verschiedene Lösungen zur Datenhaltung auf mobilen Endgeräten beschrieben und untersucht (z. B. File-System, Record-Store, JDBC-Datenbank usw.). Die Vor- und Nachteile dieser Ansätze (Update-Fähigkeit, gemeinsame Nutzung durch verschiedene Programme, Speicherbedarf) werden herausgearbeitet und verglichen. Im praktischen Teil wird eine Wörterbuch-Anwendung für mobile Endgeräte mit J2ME Plattform realisiert. Der Benutzer kann nach Stichwörter in den Datenbestand suchen und findet als Ergebnis eine Übersetzung/Beschreibung des Wortes. Die Ausarbeitung fängt mit einer Darstellung der verschiedenen populären mobilen Plattformen in Kapitel 2 an. Die Datenspeicherungsmöglichkeiten und die Datenbankunterstützung von diesen Plattformen werden genauer betrachtet. In Kapitel 3 werden die Begrenzungen den mobilen Geräten, wie z. B. Texteingabeschwierigkeiten und die möglichen Einsätzen für Datenspeicherung beschrieben. Das entwickelte Framework für mobile Datenhaltung wird in Kapitel 4 vorgestellt. Anhand von diesem Framework ist ein mobiles Wörterbuch MobiDict entwickelt, der in Kapitel 5 beschrieben wird. Kapitel 6 enthält eine Zusammenfassung der Projektarbeit und eine Bewertung des ausgewählten ansatzes zur Datenspeicherung. Am Ende des Kapitels werden weitere Speicherungsalternativen und Möglichkeiten für zur Weiterentwicklung des Konzepts dargestellt.

10 10 Datenhaltung auf mobilen Endgeräten Kapitel 2: Mobile Plattformen 2.1 Java 2 Plattform, MicroEdition (J2ME) Java 2 MicroEdition ist eine Ansammlung von APIs, zielend auf eingebettete Endbenutzerprodukte, wie PDAs, Mobiltelefone und andere Verbrauchergeräte. Die Architektur enthält eine Vielzahl von Konfigurationen, Profilen und optionalen Paketen J2ME Komponente Die J2ME-Plattform besteht aus drei verschiedene Komponenten: eine Konfiguration, ein Profil und zusätzliche optionale Komponenten (Abbildung 1). Eine Konfiguration schließt eine virtuelle Maschine (VM) und minimale Menge von Klassenbibliotheken ein. Sie bietet der Basisfunktionalität für eine Gruppe von Geräten, die ähnlichen Charakteristiken, wie Netzwerkverbindung und vorhandenes Speicher haben. Aktuell sind zwei solche Konfigurationen vorhanden: Connected Limited Device Configuration (CLDC) und Connected Device Configuration (CDC). CLDC ist sehr kleinen Schnitt von Java 2 Standard Edition (J2SE) und beinhaltet nur Basisklassen wie String, Exception, I/O Streams und Threading. Mindestanforderung für CLDC/1.0 ist 160 kb ROM und 32 kb RAM Speicher (gesamt für die Anwendung, JVM und Bibliotheken). Auch zu notieren ist, dass Realzahlarithmetik in Version 1.0 nicht unterstützt ist. Sie kommt erst in die Version 1.1 von CLDC, es ist aber möglich eigene Bibliothek für Fixkommaoperationen zu implementieren. CDC dagegen bietet praktisch alle Bibliotheken aus J2SE, die nicht GUI-bezogen sind. Anforderung dafür ist 32 bit CPU, 2 MB RAM und 2,5 MB ROM Speicher. Ein Profil andererseits, ist eine Menge von High-Level-APIs, die den Anwendungslebenszyklus definieren, Benutzerschnittstellen und Zugriff zu gerätspezifischen Eigenschaften bereitstellen. Ein Profil ist mit einer Konfiguration kombiniert, um ein komplettes Framework für Anwendungsentwicklung für eine konkrete Reihe von Geräten anzubieten. Die aktuell vorhandenen Profile sind den MIDP-1.0 und den MIDP-2.0 Profil. Der MIDP Profil umfasst Funktionen zur Ansteuerung und Abfrage von Einhandtastaturen, Minibildschirmen, Higlund Low-Level-GUIs und Datensatzmanagement. Speziell MIDP-1.0 hat gewisse Begrenzungen. Zum Beispiel kann man nicht den Tastenstatus abfragen, oder Audio abspielen. Nur den http Protokol für Netzwerkkommunikation wird unterstützt. Diese Begrenzungen sind teilweise in MIDP-2.0 behoben. MIDP-2.0 bietet bessere Möglichkeiten den Tastaturstatus abzufragen, Multimedia-API, Authentifikation und Zertifikatesmanagement.

11 Datenhaltung auf mobilen Endgeräten Es gibt auch eine Reihe von optionalen APIs zu den Konfigurationen und Profilen definiert. Sie dienen dazu spezifische Anwendungsanforderungen zu adressieren. Sie bieten ein Standarteninterface für Technologien für Datenbankverbindung, drahtlose Nachrichtenübermittlung, Multimedia, Bluetooth und Webdienste [Sun01]. Abbildung 1. J2ME Architektur Übersicht [Sun01] Datenspeicherungsmöglichkeiten Es existieren drei unterschiedliche Möglichkeiten in J2ME Daten permanent zu speichern: Die erste Möglichkeit besteht in den MIDP vorhandenen javax.microedition.rms Package (Record Management System). Dieses Mechanismus ist Teil von MIDP und stellt einfache satzorientierte Datenbank dar. Zentrales Objekt bei der Speicherung ist ein RecordStore. Er enthält eine Sammlung von Datensätze, die persistent zwischen mehrere Anrufe der Anwendung bleiben. Dabei die unterliegende Plattform ist verantwortlich für den Datenintegrität inkl. auch Fälle wie Neustart des Geräts, Aufladen der Batterie usw. Es ist erlaubt mehrere RecordStores zu haben, solange sie unterschiedliche Namen bekommen. Standardmäßig sind die RecordStores nur für die Anwendung zugreifbar, von denen sie erzeugt sind. Das Auslesen der Daten ist nur durch den High-Level Recordstore API möglich, Low-Level-API wird nicht unterstützt. In MIDP 2.0 besteht die Möglichkeit, dass mehrere Anwendungen einen RecordStore gemeinsam benutzen, wenn so ein Zugriffsrecht bei der Erzeugung des RecordStores gegeben ist.

12 12 Datenhaltung auf mobilen Endgeräten Es wird keine Lock-Operationen von der API unterstützt. Die Implementation stellt nur sicher, dass alle RecordStore Operationen atomisch, synchron und serialisiert sind, so dass bei konkurenten Zugriff keine Dateninkonsistänzen auftreten. Die einzelnen Datensätze sind Byte-Arrays. Die Entwickler können java.io.datainputstream und java.io.dataoutputstream, sowie java.io.bytearrayinputstream und java.io.bytearrayoutputstream benutzen, um unterschiedliche Datentypen zu packen und entpacken. Jeder Datensatz ist mit einer ganzzahligen Datensatznummer identifiziert. Der Nummer ist eindeutig für einen RecordStore. Die Anwendung kann eine andere Anordnung der Datensätze mit Hilfe einer RecordEnumeration erzeugen. Es gibt auch die Möglichkeit die Datensätze zu filtrieren (mit einem RecordFilter) und RecordListener Interface, um bei Änderungen benachrichtigt zu sein. Die zweite Möglichkeit ist das optionale javax.microedition.io.file.fileconnection Interface (JSR-75). Dieses Interface kann benutzt sein, um Zugriff zu Dateien oder Verzeichnisse von dem Dateisystem des Geräts zu gewährleisten. FileConnection ist Subinterface von StreamConnection, so eine Anwendung kann standarte Streams benutzen um I/O Operationen auszuführen. Zu notieren ist auch, dass die Plattform kann Geräts Systemdateien und Dateien der anderen Anwendungen von Zugriff schützen. Eine Anwendung nicht portabel, wenn sie dieses API benutzt. Erst in letzter Zeit (2006) sind Geräte an den Markt gekommen, die diese API unterstützen. Dritte Möglichkeit persistente Daten zu halten, ist diese in die Anwendung selbst als Ressource zu halten. Eine J2ME Anwendung stellt eine standarte JAR Datei vor. Diese JAR Datei beinhaltet in sich selbst ein read-only Dateisystem. Diese kann von der Anwendung durch Class.getResourceAsStream() zugreifbar sein. Dieses Verfahren kann nur für Lesezugriff benutzt sein. Die Anwendungsstruktur lässt sich von der Anwendung selbst nicht modifizieren. Auch zu notieren ist, dass so eine sehr gute Kompression von Textdaten möglich ist (da eine JAR Datei einen ZIP Archive darstellt). 2.2 DoJa Doja ist ein Java Plattform entwickelt für i-mode Handys von NTT DoCoMo Inc. DoJa hat mit J2ME gemeinsam nur, dass eine Anwendung in eine Java Virtual Machine ausgeführt ist und dass CLDC-1.0 oder CLDC-1.1 Standart für Netzwerkfunktionen benutzt wird. Für die anderen Komponenten (GUI, Datenspeicherung) werden proprietäre NTT DoCoMo Bibliotheken, wie com.nttdocomo.ui API benutzt (Abbildung 2). Das macht die Anpassung von J2ME Anwendungen nach DoJa nicht praktisch.

13 Datenhaltung auf mobilen Endgeräten Es gibt Inkompatibilitäten sogar bei den CLDC Konfiguration. Zum Beispiel braucht die HttpConnection Klasse bei DoJa einen expliziten connect() Methodenaufruf um Verbindung mit einem Server zu erstellen. Abbildung 2. DoJa Architektur Doja hat die Scratchpad API für Speicherung von permanenten Daten auf dem Handy. Der Scratchpad ist einen Block, der durch einen Stream zugreifbar ist. Er hat selbst keine logische Organisation, die Anwendung ist selbst zuständig seine Daten zu organisieren und bekommt dafür keine Hilfe von dem Framework. Die API implementiert nur Teil des Transaktionskonzepts und speziell nur den Atomarität: alle Änderungen werden entweder voll angenommen oder voll verweigert. Es existiert auch die Möglichkeit wie in J2ME statischen Dateien in der ausführbaren Datei als Ressourcen anzubinden, das ist aber für DoJa nicht sehr praktikabel, da die maximal zulässige Anwendungsgröße sehr gering ist, im Regel 30 kb pro Anwendung.

14 14 Datenhaltung auf mobilen Endgeräten 2.3 Symbian OS Einführung Symbian OS ist ein Betriebssystem, gezielt für mobile Endgeräte mit geringem Speicher entwickelt. Sie hat viele Eigenschaften, wie moderner Desktop Betriebssysteme, wie präemptive Multitasking, Multithreading und Speicherschutz (Abbildung 3). Abbildung 3. Symbian OS Architektur Das System kann in unterschiedliche Schichten unterteilt werden: Am untersten ist den 'base' Schicht. Er enthält ein Kern und User-Libraries, die Abfragen zu dem Kern erleichtern. Das Betriebsystem hat eine Mikrokern-Architektur. Der eigentliche Kern führt nur Task Scheduler und Speicherverwaltung aus. Netzwerk und Dateisystemzugriff sind bereitgestellt von Server-Prozessen, die mit normalen Benutzerprivilegien und Rechte laufen. Der Base-Schicht enthält nur den Kern und Dateisystemserver. Das Dateisystem ist DOS/Windows-Ähnlich, z. B. einzelne Laufwerke sind mit Buchstaben markiert, und das Zeichen \ ist für Trennzeichen bei Pfade benutzt. Eine Schicht oben steht System libraries Schicht. Er nimmt verschiedene Aufgaben, inkl. Zeichentransformationen, DBMS engine und Verwaltung von einzelnen Dateien.

15 Datenhaltung auf mobilen Endgeräten Über diese Schicht steht das 'Networking and communication' Subsystem, mit drei wichtige Servers: ETEL (Telephone Dienste), ESOCK (sockets) und C32 (serial communication). Bluetooth, IrDA und USB Kommunikation sind ein Teil dieses Subsystems. Anderes wichtiges Subsystem ist 'User Interface'. Es gibt kein einheitliches Benutzerinterface für Symbian OS, sondern drei nicht kompatible miteinander Schnittstellen: SonyEricsson UIQ, Nokia Series 60 und Nokia Series 80 Interface. Ein Gerät unterstützt nur ein von diesen. Anwendungen, geschrieben für ein Interface sind nicht direkt übertragbar zu einem anderen. Portierung ist möglich und relativ leicht erreichbar, wenn man von Anfang der Entwicklung klarer Trennung zwischen GUIspezifische Teile und nicht-gui-spezifische Teile der Anwendung stattfindet, z. B. mit einem Model- View-Controller Patternansatz. Entwicklungssprache für Symbian ist C++. Für Programmentwicklung kann man GNU GCC Compiler benutzen. Auch Symbian-spezifische Version von dem kommerziellen CodeWarrior Compiler ist vorhanden. Selbst die API der Plattform ist in C++. Nur eine Untermenge von C-Sprache und ein Teil des POSIX C-Interface wird unterstützt, geeignet nur für Portierung von schon geschriebenen C-Programme DBMS System Eine eingebetete Datenbank ist für Symbian Anwendungen vorhanden. Es stehen zwei Implementationen zur Verfügung: relativ kleine und leichtgewichtige Client-Slide Implementation, und eine Client-Server für den Fall, wenn mehrere Anwendungen Schreibzugriff zu der Datenbank brauchen. Mehrere Tabellen in einer Datenbank sind unterstützt. Man kann SQL benutzen für Datendefinition und Datenmanipulation. Client-Server Zugriff erlaubt mehreren Prozessen dieselbe Datenbank gleichzeitig zu zugreifen. Die Anwendung braucht eine Session mit dem Server zu öffnen. Die Datenbank selbst ist in eine Datei gespeichert. Das ist aber ein Detail, der von der Client-Anwendung nicht direkt ausgenutzt wird. Es ist theoretisch möglich auch andere Ablageplätze zu benutzen, z. B. ein Internet Server, es steht aber leider nur die Dateiimplementation zur Verfügung. Alternativ zum Client-Server Zugriff, kann eine Anwendung die Datenbank-Datei direkt zu öffnen, mit Hilfe von einem Dateiserver. Der Client kann die DBMS API benutzen, um die Daten zuzugreifen und wird in dem Fall der einzige, der Zugriff auf die Datenbank hat. Man kann diesen Variant benutzen, nur wenn man sicher ist, das nur einen Prozess gleichzeitig die Datenbank braucht. Auch dieses Verfahren ist schneller, als bei den Client-Server Zugriff. Um das Datenbanksystem zu benutzen, man kann zwei verschiedene APIs benutzen: SQL oder proprietäres C++-API. SQL ist leichter zu schreiben. Er ist auch in meisten Fällen schneller ausgeführt, als natives C++ API! Alle standarte Datenbankoperationen (SELECT, INSERT, UPDATE,

16 16 Datenhaltung auf mobilen Endgeräten DELETE) sind von SQL unterstützt, auch weites Bereich von SQL Datendefinitionen und Datenmanupulationen wie Autoinkrement-Felder, Indizes und Views. Es gibt aber Restriktionen auf dem SQL, der man benutzen kann: JOIN zwischen Tabellen ist nicht unterstützt. Man kann nur SELECT aus einer Tabelle machen Nur ein SQL Statement pro Execute Aufruf. Keine arithmetische Ausdrücke in UPDATE Statements Auch einige Operationen sind nur von C++ API ausführbar. Unter dessen sind: lange Transaktionen Recovery Kompaktierung der Datenbank Behandlung von binären Felder Das DBMS unterstützt Transaktionen. Das kann benutzt sein, um mehrere Änderungen atomisch durchzuführen um die Datenbank intern konsistent zu halten, auch um einen Lock auf der Datenbank auszuführen File Zugriff System Symbian OS bietet keinen direkten Zugriff auf das Dateisystem. Das ist nur durch einen Dateiserver durchführbar. Man kann lokale Dateisystemen zugreifen (ROM, RAM und Wechseldatenträger). Es ist auch ein Interface vorhanden, um dynamische installierbare Dateisystemen bereitzustellen. Man braucht eine Session mit dem File Server zu haben, um Dateioperationen auszuführen. Es ist VFAT als lokales Dateisystem benutzt, so ist sie kompatibel mit Desktop PCs Dateisystemen. Es ist Stream Interface über das File API vorhanden, um Dateioperationen zu erleichtern. Die normalen Dateioperationen sind unterstützt: Erzeugung, Öffnen, Ersetzung. Eine Datei muss geöffnet sein, bevor sie benutzt wird. Lese- und Schreiboperationen sind durch File Deskriptoren ausführbar. Ein Verzeichnis kann einen anderen Verzeichnis, Datei oder Volume Label als Einträge besitzen. Die Einträge können ausgelesen oder sortiert sein. Der Dateiserver unterstützt Kopierungs-, Verschiebungs- und andere Dateioperationen in Großerordnung. Es ist zu empfehlen, solche Operationen durch den Dateiserver auszuführen, statt solche direkt zu programmieren, da normalerweise der Dateiserver diese Aufgaben effektiver ausführen kann. Es ist auch High-level Datei Suchfunktionalität vorhanden.

17 Datenhaltung auf mobilen Endgeräten 2.4 Microsoft Windows CE Einführung Windows CE Betriebssystem ist eine Version von Microsoft Windows von Microsoft, speziell orientiert nach den Eingebetteten Systemen. Das System unterstützt große Variation von Mikroprozessoren, wie x86 Familie, MIPS und AMR Prozessoren und ist optimiert für Geräte mit minimalen Speicherkapazitäten (Abbildung 4). Viele PDAs und Mobiltelefone benutzen Windows CE als Betriebssystem. Es unterstützt verschiedene APIs für Entwicklung von Anwendungen: Win32 C API, Microsoft COM (Component Object Model) und Microsoft.NET Compact Framework. Die Plattform ist auch erweiterbar, z. B. kann man für viele PDAs gibt es J2ME JVMs und mit deren Hilfe kann man auch J2ME Anwendungen ausführen. Abbildung 4. Winsows CE Architektur Es werden drei Möglichkeiten für Datenspeicherung unterstützt: Dateisystem, Datenbank und Registry.

18 18 Datenhaltung auf mobilen Endgeräten Dateisystem Windows CE unterstützt ROM (schreibgeschützt), RAM (im Betriebsspeicher) Dateisystem und auch FAT System für Flash Speicher. Der Zugriff auf das Dateisystem wird durch Microsoft Win32 Filesystem-API erlaubt. Das API ist Handler-basiert, d.h. man bekommt einen Handler zu der Datei (z. B. durch CreateFile() Funktion) und benutzt weiter diesen Handler um weitere Operationen mit der Datei auszuführen. Die logische Partitioniertung von externen Datengeräten wird von dem Betriebssystem unterstützt, d.h. man kann mehrere logische Partitionen von einer physischen Datenträger unter unterschiedliche Namen (Laufwerke) im Dateisystem des Geräts zu integrieren. Besonderheit bei Windows CE ist, dass das Verzeichnisskonzept nicht existiert, also alle Dateien sind mit absoluten Pfaden adressiert, Adressierung relativ zu einer Verzeichniss wird nicht unterstützt. Dateien können kompressiert sein (gesteuert durch ein Datei-Attribut) und die maximal unterstützte Dateigröße ist 4 GB Datenbank Windows CE unterstützt unterschiedliche Datenbanktypen. Eine ist CEDB (Windows CE Datenbank). Diese Datenbank ist in eine einzelne Datei gespeichert und nur für kleine Datenmengen und flache Datenbankstruktur optimiert. Nur die einzelnen Schreiboperationen sind transaktionsgeschützt. Bei Stromausfall wird den Datenbanktzustand auf dem Zustand befor die Schreiboperation zurückgesetzt. Es gibt auch kein Schutzt von Dateisystemfehler eingebaut. Die Datenbank kann nur von einem einzelnen Benutzer gleichzeitig benutzt sein. CEDB ist vergleichbar mit dem J2ME Recordstore Mechanismus und mit dem direkten Client-Side Zugriff auf Datenbanken bei Symbian OS. Andere Möglichkeit für Datenbankengine ist EDB (Embedded Database). EDB hat voller Transkationsunterstützung. Mehrere Benutzer gleichzeitig sind unterstützt und auch mehrere Indizes zu einer Tabelle können definiert sein. Auch EDB hat bessere Geschwindigkeit bei der Arbeit mit größeren Datenmengen. Der Entwickler hat die Wahl welche Option (EDB oder CEDB) in der Anwendung zu benutzen. Die API für diese EDB und CEDB ist C/C++ basiert, dabei gibt es kleine Unterschiede zwischen die beide APIs, so dass bei Übertragung einer Anwendung von der einen zu den anderen Quellcodeänderungen notwendig sind. Die letzte Datenbank-Möglichkeit ist die SQL Server CE. Er bietet Engine, Anfragenprozessor, Datensynchronisationsoptionen mit SQL Server. Zugriff ist von C++ und auch von.net Compact Framework durch System.Data.SqlServerCe Package.

19 Datenhaltung auf mobilen Endgeräten Eine Version von Visual Studio Mobile Edition ist frei erhältlich, und gibt die Möglichkeit leicht Anwendungen für Windows Mobile zu entwickeln. Es sind C/C++, Visual Basic und C# als Entwicklungssprachen unterstützt Registry Die Register sind nicht für Speicherung von großen Datenmengen geeignet. Daher sind sie meistens für Speicherung von Anwendungseinstellungen verwendet. Auch die Einstellungen des Betriebssystems sind dort gespeichert und können leicht von Anwendungen abgefragt und geändert sein. 2.5 Zusammenfassung Man sieht von der Tabelle, dass die Symbian und PocketPC Plattformen bessere Datenspeicherungsmöglichkeiten anbieten im Vergleich mit den Java-basierten Plattformen (J2ME und DoJa). Speziell die Transaktionsunterstützung ist sehr wichtig bei Anwendungen, wo mehrere Anwendungsinstanzen gleichzeitig die gleichen Daten zugreifen und ändern. Diese Plattformen bieten auch die Möglichkeit einer Anwendung Daten in das Dateisystem zu erzeugen und zu ändern. Das interne Dateisystem in der Anwendung, die von J2ME und DoJa angeboten wird, kann nur in einige Fälle eine Ersetzung von einem vollständigen Dateizugriff-API sein. Die Nutzung von SQL ist teilweise begrenz unterstützt (Symbian OS), teilweise auch mit großem Ressourceverbrauch verbunden, was von einigen mobilen Anwendungen von Bedeutung ist. Plattform File API Datensatz DB API SQL API J2ME ROM Ja, kein Nein Transaktionsintegrität DoJa ROM Ja, aber keine logische Nein Struktur, Atomarität garantiert Symbian OS ROM, Flash card Ja, volle Transaktionsunterstützung Ja, volle Transaktionsunterstützung, streng begrenzten SQL Windows CE ROM, RAM, Flash card Ja, volle Transaktionsunterstützung Ja, volle Transaktionsunterstützung Tabelle 1. Speicherungsmöglichkeiten von mobilen Plattformen

20 20 Datenhaltung auf mobilen Endgeräten Die Datenbankunterstützung an die verschiedenen mobilen Plattformen kann man so darstellen: Plattform Atomarität Konsistenz Isolation Dauerhaftigkeit J2ME Nein Nein Nein Ja DoJa Ja Nein Nein Ja Symbian OS Ja Ja Ja Ja Windows CE Ja Ja Ja Ja Tabelle 2. Transaktionskonzeptunterstützung bei mobilen Datenbanken Nur Symbian und Windows CE unterstützen voll das Transaktionskonzept. Daher ist es notwendig an den anderen Plattformen sogar bei Datenbankanwendung Teile des Transaktionskonzepts selbst zu implementieren..

21 Datenhaltung auf mobilen Endgeräten Kapitel 3: Model Es war eine Beispielanwendung Wörterbuch anhand von J2ME Plattform zu entwickeln. Die Plattform ist Objekt von verschiedenen Einschränkungen. 3.1 Kompromisse der Anwendung Die verschiedenen Eigenschaften der Plattform bestimmen die möglichen Einsätze für Datenspeicherung Texteingabe Die meisten Geräte besitzen keine QWERTY-Tastatur. Die meisten Geräte können nur Zifferntasten direkt eingeben. Die Zeichen sind durch Mehrfachbelegung auf den Zifferntasten dargestellt. Das macht praktisch unmöglich große Datenmengen von Hand einzugeben. Auch ein Wörterbuch besteht aus Daten, die sich selten ändern. Daher ist bei Aktualisierung des Datenbestands die Installation einer neuen Anwendungsversion akzeptabel für den Benutzer Benutzerfreundlichkeit Eine Speicherung der Daten in der Datenbank erfordert, dass man zusätzlich nach der Anwendungsinstallation diese Daten von einen externen Server herunterlädt. Das würde an viele mobile Geräte Einstellung von Internet Verbindung erfordern. Auch es ist kostengünstiger für den Benutzer, wenn alle Daten direkt in der Anwendung eingebunden sind. So kann er die Anwendung direkt an dem Gerät übertragen (per Datenkabel, Bluetooth oder Infrarot) ohne Datenübertragungsgebühren zu bezahlen. Eine Speicherung der Daten in der Datenbank (javax.microedition.io.recordstore) erfordert unbedingt, dass die Daten per Internet von einem externen Server geladen ist Kompression Die mobilen Geräte können in meisten Fällen keine große Datenmengen behalten. Andererseits ist aber für viele Anwendungen nützlich möglichst viel Information auf dem mobilen Gerät zu speichern. So ist kritisch, die Daten möglichst viel zu kompressieren. Wenn die Wörterbuchdaten in die Anwendungsdatei eingebunden sind, werden sie automatisch ZIP kompressiert, da das Anwendungsformat eine einfache ZIP Datei mit ausführbaren Java Klassen darstellt. ZIP Algorithmus selbst ist eine Kombination von LZ77 und Huffman coding Algorithmen. Die Daten werden mit ihrem Hinfügen in die Anwendungdatei automatisch kompressiert und weil die Wörterbuchdaten generell

22 22 Datenhaltung auf mobilen Endgeräten Text darstellen, kann man dabei sehr gute Kompression erwarten. So ist auch die Anwendung der Kompression transparent für den Benutzer und die Anwendung. Andererseits wenn die Daten in die Datenbank gespeichert sind, ist automatisch keine Kompression angewendet. Man kann aber zusätzlich eigene Kompression hinfügen. J2ME selbst beinhaltet keinen Kompressionsalgorithmen. Wenn eine Kompression von dem Programmcode erwünscht ist, muss die Code-Implementation selbst in der Anwendung sein. Es gibt eine Reihe von Algorithmen, die man für Kompression benutzen kann. Bei Textbasierte Daten, interessante Ansätze sind die Anwendung von schnellere als ZIP Algorithmen für Kompression und Dekompression, weil die Geschwindigkeit der Anwendung einen limitierenden Faktor ist. In meisten Fällen ist aber das RAM Speicher einen viel mehr begrenzenden Faktor, als die Geschwindigkeit. So ist vielversprechend die Anwendung von Algorithmen, die Suchen in den kompressierten Daten erlauben und so das Speicher viel optimaler benutzen. Für den ersten Fall (Geschwindigkeit) sind Algorithmen vie Dense Codes 5-6 mal besser als standarten Huffman. Auch eine modifizierte Variante des Dense Codes kann auch Suche in den kompressierten Daten erlauben. Dabei ist die Kompressionsrate von Dense Codes ungefähr gleich oder besser im Vergleich mit dem ZIP Algorithmus. 3.2 Datenspeicherungsansätze Dateibasierte Speicherung Die dateibasierte Speicherung ist an der ersten Sicht eine logische und akzeptable Lösung für viele Anwendungen. Dabei ist aber das Problem, dass viele mobile Plattformen begrenzt Dateisysteme unterstützen. Speziell das J2ME, die meist populäre mobile Plattform, unterstützt nur Lesezugriffdateisystem, gebunden direkt in die ausführbare Anwendung als Ressource. Auch wenn den Datenbestand geändert wird, muss die mobile Anwendung sich selbst dafür, um Transaktionskonzepte wie Konsistenz, Isolation, Dauerhaftigkeit und Atomarität zu gewährleisten Native Datenbanken Als zweiter Ansatz kann man vorhandene Datenbanksysteme an den mobilen Plattformen benutzen. Diesen Ansatz ist generell mit einem höheren Ressourceverbrauch zu bezeichnen. Auch haben die mobilen Datenbanken in vielen Fällen begrenzte Unterstützung von modernen Datenbankkonzepten, wie SQL Sprache zum Beispiel. So ist die Anwendung von Gerätedatenbanken zu empfehlen, soweit Datenbankfunktionen von der Anwendung gebraucht sind.

23 Datenhaltung auf mobilen Endgeräten Datenbankportierung Ein dritter Ansatz ist die Portierung von vorhandenen Datenbanksystemen und deren Übertragung auf mobilen Plattformen. Ein Vorteil damit ist, dass man die Funktionen von einer echten Datenbank mit (voller) Unterstützung von modernen Datenbankfunktionen bekommen kann. Dieser Ansatz ist aber in praktisch alle Fälle ungeeignet. Allein eine Anwendung von der Größe des Datenbankengine ist für viele mobile Plattformen unzulässig. Bei J2ME ist diesen Ansatz noch erschwert, da in meisten Schreibdateisystem unterstützt wird. Das API an den vorhandenen RecordStore API ist nicht streambasiert, so ist die Übertragung von ein Java Datenbank nach J2ME nicht trivial, da man alle I/O Operationen überarbeiten muss. Auch ist den J2ME Plattform auf JDK-1.1 basiert. Praktisch alle J2EE und J2SE Projekte benutzen schon JDK-1.3 oder höher. Die Portierung nach neuere Java Features nach J2ME ist ohne von eine JVM Implementierung kaum möglich. Eine Plattform, wo die Portierung von Java Datenbanken eventuell möglich ist, ist Personal Java Plattform, ein Vorgänger von J2ME. Diese ist auf JDK-1.1 basiert und läuft auf Geräten, die auch relativ guten Prozessor und Speichercharakteristiken besitzen. Die Plattformunterstützung ist aber zu ihrer Ende und sie wird nicht weiterentwickelt.