Kapitel 2 - DSpace at ICSY

Transcrição

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 3049 • 67653 Kaiserslautern
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)
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.
Inhaltsverzeichnis
Inhaltsverzeichnis
Kapitel 1:
Einleitung........................................................................................................ 9
Kapitel 2:
Mobile Plattformen....................................................................................... 10
2.1
Java 2 Plattform, MicroEdition (J2ME) .............................................................. 10
2.1.1
J2ME Komponente ....................................................................................................... 10
2.1.2
Datenspeicherungsmöglichkeiten .................................................................................. 11
2.2
DoJa................................................................................................................... 12
2.3
Symbian OS ....................................................................................................... 14
2.3.1
Einführung.................................................................................................................... 14
2.3.2
DBMS System .............................................................................................................. 15
2.3.3
File Zugriff System ....................................................................................................... 16
2.4
Microsoft Windows CE...................................................................................... 17
2.4.1
Einführung.................................................................................................................... 17
2.4.2
Dateisystem .................................................................................................................. 18
2.4.3
Datenbank..................................................................................................................... 18
2.4.4
Registry ........................................................................................................................ 19
2.5
Zusammenfassung.............................................................................................. 19
Kapitel 3:
Model ............................................................................................................ 21
3.1
Kompromisse der Anwendung ........................................................................... 21
3.1.1
Texteingabe .................................................................................................................. 21
3.1.2
Benutzerfreundlichkeit .................................................................................................. 21
3.1.3
Kompression................................................................................................................. 21
3.2
Datenspeicherungsansätze.................................................................................. 22
3.2.1
Dateibasierte Speicherung ............................................................................................. 22
3.2.2
Native Datenbanken ...................................................................................................... 22
3.2.3
Datenbankportierung..................................................................................................... 23
Kapitel 4:
Framework ................................................................................................... 24
4.1
Datenerstellung Framework ............................................................................... 24
4.2
J2ME Framework............................................................................................... 25
4.2.1
Datenausleseframework ................................................................................................ 25
4.2.2
Suchframework............................................................................................................. 25
Inhaltsverzeichnis
4.2.3
GUI-Handling Framework ............................................................................................ 26
4.2.4
HTTP Framework ......................................................................................................... 26
4.2.5
Internationalisation ....................................................................................................... 26
Kapitel 5:
Anwendungsentwicklung.............................................................................. 28
5.1
Anwendungsarchitektur...................................................................................... 28
5.1.1
Präsentationsschicht ...................................................................................................... 28
5.1.2
Suchschicht................................................................................................................... 31
5.1.3
Ergänzende Hilfsklassen ............................................................................................... 34
5.2
Anwendungsablauf............................................................................................. 35
5.3
Datenspeicherung............................................................................................... 36
5.4
Ähnliche Anwendungen ..................................................................................... 38
5.4.1
Dictionary4Mid ............................................................................................................ 38
5.4.2
SlovoEd........................................................................................................................ 39
Kapitel 6:
Zusammenfassung ........................................................................................ 40
Kapitel 7:
Anhang.......................................................................................................... 41
7.1
Literaturverzeichnis............................................................................................ 41
7.2
Abbildungsverzeichnis ....................................................................................... 42
7.3
Code der Beispiel-Anwendung ........................................................................... 42
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
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.
2.1.1 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
Authentifikation und Zertifikatesmanagement.
den
Tastaturstatus
abzufragen,
Multimedia-API,
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]
2.1.2 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
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.
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
2.3 Symbian OS
2.3.1 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.
•
Ü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 ModelView-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.
2.3.2 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
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.
2.3.3 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.
2.4 Microsoft Windows CE
2.4.1 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
2.4.2 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.
2.4.3 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.
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.
2.4.4 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
Ja, volle
Transaktionsunterstützung Transaktionsunterstützung,
streng begrenzten SQL
Windows CE
ROM, RAM, Flash
Ja, volle
Ja, volle
card
Transaktionsunterstützung Transaktionsunterstützung
Tabelle 1. Speicherungsmöglichkeiten von mobilen Plattformen
20
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.
.
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.
3.1.1 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.
3.1.2 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.
3.1.3 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
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
3.2.1 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.
3.2.2 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.
3.2.3 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.
24
Kapitel 4: Framework
Das Framework hat das Ziel, die Möglichkeit zu geben, leichter die Datenspeicherungsprobleme mit
J2ME zu lösen und allgemein J2ME Anwendungen zu erstellen. Dabei ist es besonders bei
Organisation und Suchen von größeren Datenbestanden zur Hilfe.
Das Framework besteht aus mehreren Teilen. Ein Teil ist damit zuständig, Daten in passendem Format
für die J2ME Plattform bereitzustellen. Anderes Teil ist damit beschäftigt, diese Daten von Plattform
auszulesen, Suchfunktionen auf die Daten bereitzustellen und diese Daten zu visualisieren.
Hauptanwendungsfeld ist die Unterstützung bei Erstellung von mobilen Wörterbüchern. Das schließt
nicht die Anwendung in anderen Bereichen von mobilen Computing, obwohl in diesen Fall den Wert
der Frameworks geringer ist und nur Teile davon von Bedeutung sind.
Das Framework unterstützt das Model-View-Controller Architektur um spätere Änderung und
Erweiterung einfach zu halten. Das Framework bietet Funktionalität für den Model und Controller.
Das View ist dem Anwendungsprogrammierer überlassen.
4.1 Datenerstellung Framework
Das Framework stellt Werkzeuge bereit, um Daten in ein Format umwandeln, der leicht von mobilen
Geräten auslesbar ist. Das Werkzeug ist im Zustand textbasierte CSV-basierte Dateien mit
Wörterbuchdaten in mehrere verschiedene Dateien zu trennen, die von der mobilen Plattform lesbar
sind.
Das Ausgabeformat ist textbasiert, sodass er auch später von Hand editierbar ist. Die eigentliche
Ausgabe ist keine einzige, sondern mehrere Dateien. Das Ausgabeformat ist sehr einfach. Er besteht
aus mehreren Zeilen. An jede Zeile gibt es ein Paar: Wort(Schlüssel) und Übersetzung, getrennt von
einem speziellen Zeichen. Bei jeder generierten Datei wird die Anzahl der Datensätze der Datei
gespeichert, um das Auslesen der Daten bei dem J2ME-Plattform möglichst leicht zu machen (s.3.2.1).
Das einfache Textformat war vor eine XML-basierte Ausgabe bevorzugt. Die J2ME-Plattform besitze
kein standarten XML-Parser. Der Grund warum mehrere Dateien generiert sind ist die RAMSpeicherbegrenzung der meisten mobilen Endgeräte. Das erlaubt nicht größere Datenmengen im
RAM-Speicher zu behalten.
Das J2ME-Teil der Plattform(s.u.) bietet eine flexible Möglichkeit, nur die aktuell relevanten
Datenmengen für Schnellsuche im RAM zu haben. Die Daten werden bei Auslesen sortiert. Weil die
Sortierung der Daten (für schnelle Suche) auf J2ME Plattform zu aufwändig für eine Anwendung sein
kann, wird diesen Schritt bei der Generierung der Daten ausgeführt. Es wird auch eine Indexdatei
generiert, mit Information, welche Wörter in welche Dateien gespeichert sind.
Das Werkzeug kann die Ausgabe in unterschiedliche Zeichenkodierung ausgeben und auch
verschiedene Trennzeichen für die Wörter benutzen. Ein Problem bei der Datengenerierung ist die
mangelnde Standartisation der Wörterbuchdaten. Verschiedene Wörterbuchdaten erweisen teilweise
große Unterschiede in ihre Struktur. Wahrscheinlicher Grund dafür ist, dass auf diese Dateien mehrere
verschiedene Leute mit unterschiedlichen Werkzeugen (Editoren usw.) gearbeitet haben. So erweisen
auch einzelne Datei Inkonsistenzen in der Art und Weise der Kodierung der einzelnen Zeichen. Bei
einem neuen Eingabeformat ist eine Quellcodeanpassung des Werkzeugs notwendig um diesen
auszulesen.
4.2 J2ME Framework
Das J2ME Teil des Frameworks besteht aus vier Teilen: Datenleseframework, Suchframework, GUIHandling und HTTP Framework. Ziel des Frameworks ist Erleichterung bei Implementierung von
J2ME Client-Anwendungen, die Daten auf mobile Geräte zugreifen.
4.2.1 Datenausleseframework
Dieses Teil hat das Ziel die Daten der mobilen Anwendung auszulesen. Dabei wird die Anwendung
von dem aktuellen Format der Daten abstrahiert, auch von den unterschiedlichen Möglichkeiten
Textdaten zu kodieren. Das Teil besteht aus Klassen mit statischen Funktionen, die Daten mit
möglichst schnell und ohne Zwischenpuffer auslesen können. Der Heap-Speicher von vielen Geräten
würde sehr belastet, wenn ein Zwischenpuffer bei Auslesen der Daten verwendet wird.
4.2.2 Suchframework
Dieses Teil des Frameworks bietet Funktionen, um die Daten durchzusuchen. Es wird eine
Kombination von binären und linearen Suchen der Daten unterstützt, da die schon sortiert sind (s.4.1.).
Der Algorithmus führt erst eine binäre Suche um die relevanten Daten zu finden. Dann sucht er weiter
linear, um die einzelnen relevanten Daten herauszufiltern (wenn mehrere als eine Daten gesucht sind).
Das Teil des Frameworks ist so entwickelt, dass man leicht die Suchfunktion mit einer Wildcardsuche
erweitern kann. Es wird das Datenausleseframework benutzt, um die durchgesuchten Datenblöcke im
Speicher zu laden.
Das Suchframework unterstützt nicht die Sortierung der Daten und deren dynamische Manipulation.
Indexsuche wird aber unterstützt, mit dem Index, der von der Datenerstellungsframework (3.1)
generiert ist.
26
4.2.3 GUI-Handling Framework
Dieses Teil erlaubt eine nahtlose Integration von unterschiedlichen GUI Elementen über das
Suchframework. Die Suchergebnisse werden in einen einzelnen GUI Element gegeben. Dieses GUI
Element wird von dem GUI Schicht gegeben. Es werden auch Klassen angeboten, die die eigentliche
Suchfunktion in einen getrennten Thread ausführen. Das GUI Schicht wird benachrichtigt, wenn die
Suche abgeschlossen ist, durch einen Callback-Interface. So wird auch vermieden, dass den GUI für
lange Zeit blockiert ist (wenn die Suche lange Zeit braucht). Nach Bedarf aber kann eine Anwendung
direkt den Suchframework zugreifen, ohne durch das GUI-Handling Schicht zu gehen, wenn es sicher
ist, dass die Suchfunktion kurze Zeit benötigt. Dieses Teil des Frameworks ist als Singleton Pattern
implementiert. Es ist möglich nur eine Suchabfrage gleichzeitig zu haben. Es ist möglich diese
Beschränkung umzugehen, wenn man direkt das Suchframework abfragt. In meisten Fällen bei den
mobilen Geräten ist das ausreichend und wünschenswert, da die mobilen Plattformen schwäche
Parallelitätsmöglichkeiten anbieten. Sogar die Ausführung von zwei rechenintensiven Aufgaben
gleichzeitig kann zu sichtbare Verlangsamung der Benutzerinteraktion und Blockierung des Systems
für lange Zeit.
4.2.4 HTTP Framework
Das HTTP Framework bietet leichte Möglichkeit Daten per HTTP Protokoll von Handy zu lesen. Die
HTTP Abfragen werden in eigenen Thread durchgeführt, so dass den GUI Interface nicht blockiert
wird. Es wird die GUI-Handling Framework benutzt, um die Ergebnisse der HTTP Kommunikation an
den GUI zu übergeben. Die Methoden für Senden und Empfangen von Daten bei der HTTP
Komponente sind erweiterbar, so dass es leicht zu setzen ist, welche Daten geschickt und gelesen
werden. Es wird den Callback-Mechanismus von GUI-Handling Framework benutzt, um die GUI von
Änderungen zu benachrichtigen. Es wird auch die Möglichkeit gegeben, laufende HTTP Abfragen
sicher zu beenden, z. B. nach Benutzerwunsch.
4.2.5 Internationalisation
Es werden Komponenten angeboten, um die alle Texte der Anwendung in eine oder andere Sprache
anzuzeigen. Die Wörter für die Internalisation sind von den Wörterbuchwörtern getrennt gehalten. Die
Liste der unterstützten Sprachen ist parametrisiert und aus einer Konfigurationsdatei ausgelesen. Alle
anderen Teile des Frameworks benutzen die Internalisationskomponente um verschiedene Fehler- und
Statusmeldungen anzuzeigen. Wenn die benutzte Sprache geändert wird, werden alle grafische
Komponenten sofort mit den neuen Texten aktualisiert. Ein Neustart der Anwendung ist dafür nicht
notwendig.
Nur einige kritische Ausnahmefehler werden nur auf Englisch dargestellt. Das wird so gemacht, weil
diese Meldungen für den Benutzer nicht sehr hilfreich sind. Das Auftreten solcher Fehler würde
bedeuten, dass die Anwendung auf dem benutzten Gerät nicht lauffähig wäre.
28
Kapitel 5: Anwendungsentwicklung
Von den vorgestellten mobilen Plattformen hat die J2ME Plattform die größte Verbreitung. Fast alle
neue Handys unterstützen J2ME, auch bei PDAs ist es möglich in viele Fälle ein J2ME JVM zu
installieren. So war J2ME als Entwicklungsplattform ausgewählt und speziell MIDP-1.0/CLDC-1.0.
Einstellung auf einem höheren Profil (wie MIDP-2) bietet keine besonderen Vorteile für die
Anwendung und begrenzt deutlich die Anzahl der mit der Anwendung kompatiblen mobilen Geräte.
Die Möglichkeit für Online-Suche war eingebunden. So wenn ein Wort in dem Wörterbuch nicht
gefunden ist, kann man ein Online-Dienst für die Übersetzung benutzen.
5.1 Anwendungsarchitektur
Die Anwendung ist in drei Schichten verteilt: Präsentationsschicht (GUI), Suchschicht und ergänzende
Hilfsklassen.
5.1.1 Präsentationsschicht
Der Präsentationsschicht besteht aus 5 Klassen, welche die grafische Oberfläche der Anwendung
erzeugen und bei Benutzereingabe die Suchanfrage an den Suchschicht weiterleiten (Abbildung 5).
Diese Schicht benutzt nicht die Plattformkomponenten, sondern ist extra für die Anwendung
implementiert. Hier hat man an eine Begrenzung von J2ME Plattform angestoßen, dass man keine
direkte Einfluss an die GUI Präsenz hat. Der Look-and-Feel der Anwendung ist sehr unterschiedlich
an verschiedenen Geräten. Damit die Anwendung eine einheitliche GUI an allen Geräten benutzt, ist
es möglich eigenes GUI zu entwickeln, ohne die Plattformguiklassen zu verwenden. Das bereitet aber
Probleme mit der Benutzbarkeit der Anwendung, weil die Abfrage von der Benutzereingabe in diesen
Fall begrenzt ist. So waren im Endeffekt die Standart-GUI-Klassen verwendet.
Abbildung 5. UML Diagram der Präsentationsschicht
Die Klasse MobiDict ist den Eingangspunkt der Anwendung. Er sorgt sich dafür, die Ressourcen der
Anwendung korrekt beim Start zu initialisieren (Menus auslesen, Such-Thread starten) und bei der
Ende die laufenden Tasks zu beenden.
Die Klasse SuchForm.java zeigt das Hauptsuchformular der Anwendung. Der Benutzer gibt ein Wort
in dem Suchfeld. Um die Eingabe freundlicher zu gestalten, braucht den Benutzer keine Funktion für
die Translation aufzurufen. Das Formular reagiert auf jede Texteingabe in dem Suchfeld und startet
30
die Suche im Hintergrund. So kann den Benutzer noch bei Eintippen sehen ob es Wörter mit dem von
dem Benutzer schon eingetippten Buchstaben gibt (Abbildung 6).
Abbildung 6. Screenshot der Hauptsuchform bei Nokia 6600
Die Online Suchform ist in OnlineSearchForm.java implementiert. Hier passiert die Übersetzung nicht
automatisch, sondern ist von Menu aktiviert, weil die Datenübertragung mit Kosten für den Benutzer
verbunden ist und auch der Plattformsoftware oft eine zusätzliche Erlaubnis von dem Benutzer braucht
um Internet Verbindung zu erlauben. Hier wird auch explizit die Übersetzungsrichtung gefragt. Bei
der normale Suchfunktion ist das nicht notwendig, da gleichzeitig in allen Richtungen gesucht wird (s.
Abbildung 7).
Abbildung 7. Screenshot der Online Suchform bei Nokia 6600
Die Anwendung bietet auch ein Einstellungsformular, wo man die Anzahl der gewünschten
Suchergebnisse und die Menusprache ändern kann (Abbildung 8).
Es gibt auch einen Info Formular, der Information für die Anwendung (Version, Sprache, Lizenz usw.)
anzeigt.
Abbildung 8. Einstellungen der Anwendung
5.1.2 Suchschicht
Die Suchschicht besteht aus 4 Komponenten, welche die Suchfunktionen der Anwendung
implementieren: SearchThread, OnlineSearchTask, Dictionary und DictIndex. Es wird den Standart
Rückfragemechanismus des Frameworks benutzt, um die Ergebnisdaten und Fehlermeldungen an den
GUI-Schickt zu übergeben (Abbildung 9).
32
Abbildung 9. UML Diagramm der Suchschicht
Die Klasse Dictionary hat die Aufgabe das Wörterbuch zu verwalten. Intern wird er mit zwei
eindimensionälle Arrays dargestellt. Der eine Array enthält die Suchschlüsselwörter in sortierte
Reihenfolge, der andere enthält die Übersetzung. Die Übersetzung eines Suchwortes hat den gleichen
Index wie das Suchwort. Nicht alle gespeicherte Wörter in der Anwendung werden geladen. Das
ganze Wörterbuch wird in verschiedene Dateien verteilt und gleichzeitig ist nur eine Datei im Speicher
geladen. Es ist nicht praktikabel das ganze Wörterbuch im RAM-Speicher zu laden. Das aktuell
benutzte Wörterbuch ist 400 000 Zeichen groß. Geladen an einem mobilen Gerät würde das ungefähr
800 kB Heap-Speicher anfordern, weil der Java Strings den UTF-16 Format benutzen und er erfordert
zwei Bytes pro Zeichen. Viele mobile Geräte haben so viel Speicher nicht vorhanden. Die Suche
selbst ist in zwei Teilen gemacht: erst eine begrenzte binäre Suche um die Suchmenge zu verkleinern
und danach eine lineare Suche in der gebliebenen Menge. Die lineare Suche ist gemacht, da im
späteren Entwicklungsstadium vorgesehen ist, dass die Anwendung auch eine Wildcard Suche mit
Hilfe von Wildcards wie * und ? erlaubt.
Die Dictionary Komponente ist verantwortlich um die Wörterbuchdaten zu laden. Dabei wird
DictIndex Komponente benutzt, um zu entscheiden in welche Datei das gesuchte Wort sein kann. Die
Index Daten sind von einer getrennten Datei geladen.
Die Suche selbst findet im Hintergrund statt. Grund dafür ist, dass generell eine Suche sehr lange
dauern kann. Wenn solche Aufgaben in dem GUI-Thread ausgeführt sind, wird für lange Zeit den
Refresh des Displays blockiert und auch weitere Benutzereingabe. Das gleiche gilt auch für die Online
Suchfunktion. Dabei ist das dort noch wichtiger, weil erst die Online Suche viel mehr Zeit als die
Offline Suche braucht. Auch die CLDC Spezifikation garantiert nicht, dass bei Verbindungsfehler die
Anwendung überhaupt eine Benachrichtigung bekommt. Wenn die Suche in der GUI-Thread
ausgeführt ist, kann bei der Online Suche die Anwendung für immer blockiert bleiben. Es gibt auch
mobile Geräte (Nokia 7650), die bei der Internet Verbindung Deadlock möglich ist, wenn das in der
GUI-Thread ausgeführt wird.
Die Offline Suche ist die Kernfunktion der Anwendung. Deshalb existiert immer ein HintergrundThread, der bei der Suchanfrage von dem Benutzer aufgeweckt wird. Der Thread hat Referenzen zu
GUI Komponenten, die zu der Hauptsuchform gehören. Diese GUI Komponenten werden mit den
Suchergebnissen gesetzt, wenn der Thread seine Arbeit beendet. Wenn danach eine neue Suchanfrage
steht, beginnt der Thread mit dieser Anfrage. Wenn es keine neuen Aufgaben gibt, wartet der Thread
für neue Anfragen. Dafür wird den wait()-notify() Mechanismus von Java benutzt. Wenn es keine
Anfrage gibt, wartet den Thread mit wait() für neue Anweisungen. Wenn eine Suchanfrage kommt,
setzt der GUI-Thread die Suchanfrage in den Thread Objekt und führt notify() um die Suche zu
starten. Bei der Online Suche wird einen Such-Thread nur bei Bedarf erzeugt und dieser wird nach der
Ende der Übertragung beendet.
34
Die
Online
Suchfunktion
nutzt
den
Google
Translate
Dienst
erreichbar
unter
http://translate.google.com/translate_t. Der Dienst liest einen HTTP POST Anfrage und liefert als
Antwort einen HTML Dokument. Die OnlineSearchTask Komponente hat eine einfache Parsefunktion
um die notwendigen Daten aus der HTML Dokumente zu bekommen. Die Implementierung ist nicht
optimal, da bei Änderungen des Dienstes kann man nicht mehr garantieren, dass die Online
Suchfunktion lauffähig bleibt. Die Nutzung von dem Dictionary Server Protocol (RFC2229) war
beabsichtigt. Es existieren eine Reihe RFC2229 kompatible Dienste im Internet. Die Implementierung
von diesem Protokol bei MIDP-1.0/CLDC-1.0 ist aber nicht möglich, weil den Protokol eine Socket
Verbindung braucht. So eine Verbindung ist aber erst seit MIDP-2.0 vorhanden.
5.1.3 Ergänzende Hilfsklassen
Die Anwendung besitzt auch zwei Hilfskomponenten, AppSettings, Strings und DataAccess
(Abbildung 10).
Die AppSettings Komponente hat die Aufgabe die Benutzereinstellungen zu verwalten. Sie ist
verantwortlich die Benutzereinstellungen permanent in einem RecordStore zu speichern und zu laden
und gibt eine komfortable Möglichkeit diese auszulesen. Es werden die Anzahl der Suchergebnisse bei
der Offline Suche, die aktuelle Menu Sprache der Anwendung und die letzte ausgewählte
Übersetzungrichtung bei der Online Suche (Deutsch nach Englisch oder Englisch nach Deutsch)
gespeichert. Die ersten zwei Einstellungen sind explizit von dem Benutzer verwaltet durch die
SettingsForm Komponente. Die letzte Einstellung wird implizit bei jeder Suchanfrage gespeichert. Die
implementierten Funktionen für Datenspeicherung in den RecordStore sind nach kleinen
Datenmengen, alle Daten werden in einen einzelnen Datensatz gespeichert. Bei jeder Änderung der
Einstellungen werden die (geänderten) Einstellungen gespeichert. So vermeidet man den Verlust der
Einstellungen bei unerwarteten Ereignissen, wie z. B. Ausschalten des Geräts.
Die Strings Komponente enthaltet alle Strings, die in den GUI Elementen der Anwendung angezeigt
sind. Die Anwendung kann die Menus in Deutsch oder Englisch anzeigen. Die Menus Übersetzungen
sind in zwei getrennte Dateien in dem internen Dateisystem der Anwendung gespeichert. Der Auswahl
der Menu Sprache ist im SettingsForm gemacht. Die Änderungen werden sofort angewendet, ohne
Neustart der Anwendung.
Die DataAccess Komponente bietet Hilfsfunktionen um die statischen Anwendungsdaten
(Wörterbuchdaten und sprachspeziphische Daten) auszulesen. Die Komponente ist ein Teil der
Datenausleseframework (3.2.1).
Abbildung 10. UML Diagramm der Hilfsklassen
5.2 Anwendungsablauf
Die Ausführung geht von der Präsentationsschicht durch den Suchschicht zu den Hilfsklassen. In dem
Fall wenn eine untenstehende Schicht Zugriff auf eine höhere Schicht braucht, passiert das nur durch
ein streng definiertes Callback-Interface um zirkuläre Beziehungen zwischen den Schichten zu
vermeiden.
Die Ausführung wird am Model-view-controller Design Pattern basiert.
Die Klassen in der Präsentationsschicht stellen den View vor. Die Controller-Funktionen werden von
den Thread-Klassen genommen (SearchThread und OnlineSearchTask). Die richtige Funktion (den
Model) wird von den Dictionary und den anderen bezogenen mit ihm Klassen ausgeführt.
Die Hauptbenutzerinteraktion ist an der Abbildung 11 zu sehen. Der Benutzer gibt ein Wort an. Die
Suche der passenden Übersetzungen wird automatisch begonnen. Wenn die Suche beendet ist, werden
die gefundenen Übersetzungen dem Benutzer angezeigt. Wenn keine passenden Wörter gefunden sind,
bekommt er eine entsprechende Meldung. Die Online-Suche läuft ähnlicherweise, die einzige
Unterschied ist, dass die Suche von dem Benutzer explizit aufgerufen ist.
36
Abbildung 11. Use-Case Diagramm der Suchablauf
Die Offline Suche in dem Wörterbuch ist die Kernfunktion der Anwendung. So ist sie den zentralen
Punkt der Anwendung. Alle anderen Formulare sind von ihm zugreifbar.
5.3 Datenspeicherung
Die Anwendung hat ein Wörterbuch von 10,000 Wörtern vorhanden. Die Daten werden doppelt
gespeichert, einmal für die Übersetzung von Englisch nach Deutsch und einmal für die Übersetzung
von Deutsch nach Englisch. Die ungepackte Größe der Daten ist 399 kB. Gepackt in die Jar Datei sind
sie 144 kB (36% der Größe der Originaldaten). In der Anwendung sind statisch noch ein Piktogramm
der Anwendung, deutsche und englische Übersetzung der Menus, eine Datei mit der Liste der
unterstützten Menu-Sprachen und eine Index Datei mit Index-Information für die Wörterbuchdaten.
Diese Restdaten betragen noch 2 kB. Die Gesamtanwendung hat eine Größe von 166 kB. Die anderen
20 kB sind Java Class Dateien mit ausführbaren Java Byte Code.
Die Anwendungsgröße von 166 kB ist zu viel für viele mobile Geräte. Es gibt eine Reihe von solchen,
die eine maximale Anwendungsgröße von 128 kB, 100 kB oder 64 kB zulassen. Die Anwendung in
diesem Zustand ist nicht installierbar an diese Geräte. Um diese zu unterstützen wird ein begrenztes
Wörterbuch, der nur Übersetzungen von einer Richtung (nur Deutsch nach Englisch oder nur Englisch
nach Deutsch) enthält. Es werden zwei kleinere Anwendungen generiert, eine mit Übersetzungen nur
von Englisch nach Deutsch und eine mit Übersetzungen nur von Deutsch nach Englisch. So kann man
eine Anwendungsgröße von 98 kB erreicht und die Reichweite der unterstützten Endgeräten wird
deutlich erweitert. Dabei kann den Benutzer die beiden Versionen parallel installieren und an einige
Geräte können diese auch parallel lauffähig sein.
Die von der Anwendung gespeicherten Daten kann man in zwei Gruppen verteilen.
Die erste Gruppe sind die Daten, die mit der Suche verbunden sind. Das sind die Wörterübersetzungen
und eine Indexdatei (/index.dat). Diese Indexdatei enthält Information dafür, welche Wörter in welche
Wörterbuchdatei sich befinden. Die Wörterübersetzungen sind in die einzelnen Dateien sortiert
gespeichert. So vermeidet man die Sortierung der Daten beim Laden, was eine aufwändige Operation
auf ein mobiles Gerät sein würde. Am Anfang der Wörterbuchdatei ist die Anzahl der drin enthaltenen
Wörter gespeichert. Damit kann man von Anfang an genug Elemente in den Schlüsselwort- und
Übersetzungsarray von Anfang an reservieren und das Laden der Daten beschleunigen. Die Daten
selbst sind in den UTF-8 Format gespeichert. In dieses Format besetzen die US-ASCII Symbolen nur
ein Byte Platz. Mit ihm kann man aber trotzdem alle möglichen Unicode Symbolen darstellen. Für die
anderen Symbole werden zwei oder drei Bytes benutzt. Da die meisten Buchstaben des deutschen
Alphabet US-ASCII Symbolen sind, braucht man für die meisten Symbole des Wörterbuchs nur ein
Byte Platz.
Die zweite Gruppe sind Daten, die mit den Anwendungstexten verbunden sind. In diese Kategorie ist
die Datei mit den Sprachen unterstützt von dem GUI (lang.txt) und die Dateien mit den GUI
Übersetzungen der unterstützten Sprachen (Deutsch-Menu.txt und English-Menu.txt). Die
Namenskonvention für die letzten zwei Dateien ist <Sprachname>-Menu.txt, wobei der Sprachname
aus lant.txt genommen wird. An Abbildung 12 kann man die Anwendungsdateien sehen, und deren
Bezug mit den Anwendungskomponenten.
38
Abbildung 12. Übersicht der Datenspeicherung
5.4 Ähnliche Anwendungen
Es gibt eine Reihe von mobilen Anwendungen, die verschiedene Datenspeicherungsfunktionen für
mobile Geräte anbieten. Unter den gesehenen Wörterbuchanwendungen, alle benutzen einen
dateibasierten Zugriff. Es gibt keine mobile Wörterbuchanwendung, die Daten in einer Datenbank
speichern.
5.4.1 Dictionary4Mid
Dictionary4Mid ist eine J2ME Wörterbuchanwendung. Sie benutzt das gleiche Konzept wie die hier
vorgeschlagene: die Wörterbuchdaten werden mit der Anwendung gebunden. Es werden mehrere
verschiedene Wörterbucher angeboten für Englisch, Deutsch, Spanisch, Französisch usw., insgesamt
über 20 verschiedene Wörterbücher. Die Anwendung ist Open-Source und unter den GPL License
angeboten. Die Anwendung zeigt ein Problem mit der Konzeption, Daten statisch in der Anwendung
einzubinden: bei Änderung des Quellcodes müssen alle Anwendungsversionen mit verschiedenen
statischen Daten (Wörterbücher) neu erzeugt sein. So ist ein Teil der angebotenen Wörterbücher nur
mit älteren Anwendungsversionen erhältlich.
5.4.2 SlovoEd
SlovoEd ist ein kommerzielles Wörterbuch für Symbian OS Plattform. Es werden über zehn
verschiedene Wörterbücher angeboten. Die Wörterbuchdaten sind nicht statisch mit der Anwendung
gebunden. Es ist eine Kernplattform vorhanden und man kann zusätzliche Wörterbücher installieren
oder solche entfernen.
40
Kapitel 6: Zusammenfassung
Ziel der Projektarbeit war die Untersuchung von Ansätzen zur Realisierung einer persistenten
Datenspeicherung auf mobilen Endgeräten. Bei der Analyse wurden drei Ansätze betrachtet: native
Datenbanken, die Portierung von Standartdatenbanken nach mobilen Plattformen und interne
Dateisystemspeicherungen.
Die verschiedenen mobilen Plattformen haben sehr unterschiedlichen Charakteristiken, wie
Speicherplatz und Geschwindigkeit. Die Entscheidung, welcher Ansatz der beste ist, hängt
hauptsächlich von der Plattform ab. Von großer Bedeutung ist es, den vorhandenen Speicherplatz
optimal auszunutzen. Die Kompression von den gespeicherten Daten ist spielt daher eine sehr wichtige
Rolle. Leider werden solche Funktionalitäten von den Plattformen wenig bzw. gar nicht unterstützt.
Der native Datenbankansatz ist vorteilhaft für Anwendungen, die ihren Datenbestand häufig
aktualisieren oder wenn mehrere Anwendungen den gleichen Datenbestand benutzen. Das Problem
dieses Ansatzes ist, dass die Datenbankunterstützung in vielen Fällen begrenzt ist. So muss die
Anwendung
Teile
der
Transaktionseigenschaften
Funktionalitäten
(Atomarität,
für
die
Konsistenz,
Bewahrung
Isolation
und
von
den
verschiedenen
Dauerhaftigkeit)
selbst
implementieren.
Die Dateisystemspeicherung ist eine geeignete Lösung, wenn die gespeicherte Datenmenge eine
einfache Struktur besitzt. Bei diesem Verfahren muss die Anwendung selbst alle Teile des
Transaktionskonzepts und Suchfunktionalitäten implementieren, die es braucht. Bei J2ME Plattformen
ist eine effektive Kompression der Daten möglich, da die Anwendungsdaten zusammen mit dem
ausführbaren Kode der Anwendung mit Hilfe des Zip-Algorithmus standardmäßig komprimiert sind.
Die Portierung vorhandener Standartdatenbanken auf mobile Plattformen, ist keine gute Lösung für
mobile Datenspeicherung. Die Standartdatenbanken benutzen ein breites Spektrum von Komponenten,
die in den mobilen Plattformen nicht vorhanden sind. Allein die ausführbare Codegröße der
Datenbank ist ein Hindernis für den Ansatz.
Im weiteren Verlauf der Arbeit wurden deswegen die Speicherungsmöglichkeiten bei den J2ME
Plattform untersucht. Für Anwendungen, die nichteditierbaren Daten speichern, ist der beste Ansatz
die interne Dateisystemspeicherung zu benutzen. Der Vorteile in diesem Fall liegt in der Effizienz der
Speicherung (Zip-Kompression).
Es sind auch mehreren Datenspeicherungsansätze möglich. Ein Ansatz, der in der Projektarbeit nicht
untersucht war, ist die externe Datenspeicherung an einem Server. Die mobile Anwendung fragt in
diesen Fall den Server für die gebrauchten Daten ab und kann diese auch temporal in dem Gerät
speichern. Die Verbreitung von mobilen Internetdiensten (GPRS, UMTS usw.) gibt guten
Perspektiven für diesen Ansatz.
Literaturverzeichnis
41
Kapitel 7: Anhang
7.1 Literaturverzeichnis
[JoBuTh00]
M. Jones, G. Buchanan, H. Thimbleby, G. Mardsen, User Interfaces for Mobile Web
Devices, WWW9 Mobile Workshop Position Paper, web: http://www9.org/w2mobileweb/web9pos.PDF
[LelHir06]
D. Lelewer, D. Hirschberg, Data Compression, 2006, web:
http://www.ics.uci.edu/~dan/pubs/DataCompression.html
[SoVaHo03]
C. Sorensen, A. Wang, O. Hoftun, K. Borkhaufen, An evaluation of a mobile task
reporting system for different mobile devices, 2003, web:
http://www.idi.ntnu.no/grupper/su/publ/carlfrs/sea2003-usability.pdf
[PrBaMa05]
N. Preguica, C. Vaquero, J. Martins u.a., FEW: File Management for Portable
Devices, web: http://asc.di.fct.unl.pt/few/papers/few-iwssps2005.pdf
[Mon06]
M. Monteiro, Using Design Patterns as Indicators of Refactoring Opportunities (to
Asspects). LATE workshop at AOSD 2006, 2006
[FaHiMa97]
R. Faith, C. Hill, B. Martin, A Dictionary Server Protocol (RFC2229), 1997
[Smi06]
Maria Smith, Using the EPOC Database Manager, web:
http://www.symbian.com/developer/techlib/papers/v6/gt/sys/dbms/index.html
[JodTur05]
Martin de Jode, Colin Turfus, Symbian OS System Definition, Symbian Developer
Network, 2005
[Sun01]
Sun Microsystems Inc., MIDP APIs for Wireless Applications, MIDP Whitepaper,
Palo Alto, CA USA, 2001, web: http://java.sun.com/products/midp/midpwirelessapps-wp.pdf
[NTT04]
NTT DoCoMo Inc, DoJa 1.5 API reference, 2004
[Sun00]
Sun Microsystems Inc., Applications for Mobile Information Devices, 2000, web:
http://java.sun.com/products/midp/midpwp.pdf
[Mot06]
Motorola Inc., Introduction of MVC structure in J2ME client. 2006, web:
http://trix2.cellmania.com/downloads/downloads/pdf/MVC_Structure_20060301.pdf
[DanBor03]
A. Dantas, P. Borba, Developing Adaptive J2ME Applications Using AspectJ, 2003,
web:
http://toritama.cin.ufpe.br/twiki/pub/SPG/GenteAreaPublications/SBLP03_dantas.pdf
[BrFaNa06]
N. Brisaboa, A. Farina, G. Navaro, Lightweight Natural Language Text Compression,
2006, web: http://www.dcc.uchile.cl/~gnavarro/ps/ir06.ps.gz
[HSQLDB ]
Project Documentation, web: http://www.hsqldb.org/
Abbildungsverzeichnis
42
7.2 Abbildungsverzeichnis
Abbildung 1. J2ME Architektur Übersicht........................................................................................ 11
Abbildung 2. DoJa Architektur......................................................................................................... 13
Abbildung 3. Symbian OS Architektur ............................................................................................. 14
Abbildung 4. Winsows CE Architektur ............................................................................................ 17
Abbildung 5. UML Diagram der Präsentationsschicht ...................................................................... 29
Abbildung 6. Screenshot der Hauptsuchform bei Nokia 6600 ........................................................... 30
Abbildung 7. Screenshot der Online Suchform bei Nokia 6600......................................................... 30
Abbildung 8. Einstellungen der Anwendung..................................................................................... 31
Abbildung 9. UML Diagramm der Suchschicht ................................................................................ 32
Abbildung 10. UML Diagramm der Hilfsklassen.............................................................................. 35
Abbildung 11. Use-Case Diagramm der Suchablauf ......................................................................... 36
Abbildung 12. Übersicht der Datenspeicherung................................................................................ 38
7.3 Code der Beispiel-Anwendung

Kapitel 2 - DSpace at ICSY

Transcrição

Documentos relacionados

mobile Designer

2016-04-12 Pressemeldung Mobile Legenden 2016 Programm

Optionale Schnittstellen

Product Datasheet - BT Global Services

Das Büro wird mobil - Mittelstand Digital

nokia6630

Siemens-Transformatorenwerk in Jinan, China, absolviert härteste

PRESSEMITTEILUNG Mobile Präsentationssysteme

PDF

gerne herunterladen