Motivation

Es gibt kaum noch Menschen, die nicht über mindestens ein Mobiltelefon (Handy) verfügen. Dies gilt international ebenso wie für den Mobilfunk-Markt in Deutschland. Bemerkenswert ist hierbei, daß diese Geräte inzwischen viel mehr sind als reine Telefone. Liest man sich die Leistungsbeschreibung eines Handys der neuesten Generation durch, so scheint es, daß Telefonieren schon fast zur Nebensache geworden ist.

Ein Mobiltelefon von heute bietet u.a. MMS, polyphone Klingeltöne, Kamerafunktionen, eingebaute Spiele und vieles mehr. Außerdem gibt es die interessante Möglichkeit, spezielle Anwendungen aus dem Netz auf das Handy herunterzuladen.

Hierbei gibt es mehrere Faktoren, die den Trend in der Entwicklung von Handys beschleunigen. Zum einen müssen die Gerätehersteller angesichts des rasanten Entwicklungstempos der Wettbewerber stets nach neuen Funktionen Ausschau halten, mit denen sie ihre Marktposition sichern und ausbauen können. Viel entscheidender ist jedoch, daß die Mobilfunkanbieter selbst nach immer neuen Geldquellen suchen müssen, denn die wenigsten Geräte werden heutzutage zu einem für den Anbieter wirtschaftlichen Preis verkauft. Viele Anbieter subventionieren Endgeräte in der Hoffnung, diese Kosten während der Vertragslaufzeit wieder einzuspielen. Neben Grundgebühr, Mindestumsatz und zum Teil immer noch recht hohen Gesprächspreisen bieten sich daher vor allem Mehrwertdienste an.

Urlaubsfotos als MMS, den Busfahrplan im WAP, der neueste Hit als Klingelton und andere Anwendungen werden so als kostenpflichtige Zusatzleistungen von Mobilfunkanbietern angeboten.

Dieser kann solche Dienste jedoch nur dann erfolgreich am Markt plazieren, wenn möglichst viele seiner Kunden auch ein Handy mit den entsprechenden Funktionen ihr eigen nennen. Somit haben Gerätehersteller und Mobilfunknetzbetreiber ein vitales Interesse daran, daß die Funktionalität der Geräte stetig anwächst.

In diesem Zusammenhang geht man immer mehr dazu über, neue Mobiltelefone auch mit der Fähigkeit auszustatten, ladbare Anwendungsprogramme auszuführen, ähnlich, wie dies bei PCs oder Organizern längst der Fall ist. Das Geschäftsmodell hierbei ist, solche Applikationen über das Mobilfunknetz zum gebührenpflichtigen Download bereitzustellen.

Der Fokus in der Zielgruppe liegt dabei vor allem bei jüngeren Benutzern. Die Entwicklung von Anwendungen konzentriert sich daher häufig auf Spiele, welche auch Interaktion zwischen Spielern erlauben sollen, wobei dies natürlich ebenfalls eine kostenpflichtige Zusatzleistung darstellt.

Auch wenn zur Zeit geringe Bandbreiten und hohe Latenzzeiten die Entwicklung solcher Software noch beschränken, zeichnet sich hier doch ein beachtlicher neuer Markt ab. Daher ist es nicht verwunderlich, daß gleich mehrere Konzepte und Plattformen existieren. Verschiedene Hersteller versuchen dabei, ihr proprietäres Konzept durchzusetzen, um so den Wettbewerb für sich zu entscheiden.

Im Gegensatz zu PCs, auf denen man eine, in wesentlichen Teilen immer gleiche Systemumgebung vorfindet, gehen Handyhersteller in Bezug auf Hard- und Softwareplattformen häufig eigene Wege und eine Standardisierung scheint derzeit nur sehr schwer durchsetzbar.

Hinzu kommt, daß mobile Endgeräte große Leistungsunterschiede aufweisen, die von einer Minimalausstattung fürs Prepaid-Paket bis zum Smartphone mit Kamera, Organizer-Funktion und Bluetooth-Anbindung reicht. Die daraus resultierenden verschiedenen Preissegmente dieser Handys bedingen somit bereits große Unterschiede in den Hardware-Sourcen. Hinzu kommen unternehmensbedingte, unterschiedliche Ansätze bei der Systemsoftware.

Systemkonzepte

Das Symbian OS ist ein komplettes Betriebssystem, das derzeit auf verschiedenen High-End-Geräten zu finden ist. Symbian bietet dabei gleich zwei Plattformen für dynamisch ladbare Anwendungen.

Programme für Handys können u.a. in C++ entwickelt werden. Dies ist insbesondere dann sinnvoll, wenn Programme die speziellen Funktionen eines Symbian-Telefons ausnutzen wollen oder tief in die Systemarchitektur eingreifen müssen.

Genau hier liegt aber auch ein Schwachpunkt, denn solche Software läuft eben auch nur unter Symbian OS. Für Anwendungen, die auf Portabilität setzen - und dies dürften, wie oben ausgeführt, in Zukunft die meisten sein - bieten Symbian-Handys daher zusätzlich eine Java-Schnittstelle auf Basis von MIDP und CLDC, auf die im folgenden noch genauer eingegangen werden soll.

Microsoft hingegen stellt eine speziell für Mobiltelefone angepaßte Version seines schon von diversen PDAs bekannten Betriebssystems Windows CE bereit. Das System wird als Windows Mobile Pocket PC Phone Edition bezeichnet und findet sich z.B. in den von O2 vertriebenen XDA und XDA II.

Microsoft setzt hierbei seit der 2003-Edition ganz auf die DotNet-Technologie, in der Hoffnung, daß sich auf diese Weise Erfahrungen aus der PC-Welt auf Mobiltelefone übertragen lassen. Bisher ist das Interesse an Microsoft-Handys allerdings relativ gering, so daß die Zukunft zeigen muß, ob sich nennenswert viele Hersteller und Anbieter dauerhaft in der Applikationstechnologie von Microsoft abhängig machen möchten.

Qualcomm bietet als Umgebung für ladbare Anwendungen das sog. BREW. Diese Plattform setzt auf bestehende Betriebssysteme auf und steht in direkter Konkurrenz zu Java. Das Interessante daran ist, daß im Gegensatz zur Java-Technologie gleich der Aspekt des Geschäftsmodells mit berücksichtigt wurde. Dieser Ansatz zeigt, daß die Mobilfunkanbieter ein wesentliches Wort bei der Entscheidung für oder gegen eine Plattform mitreden.

Sun verfolgt schon seit geraumer Zeit die Strategie der prozessorunabhängigen Anwendungsentwicklung und stellt mit der Java 2 Platform Micro Edition eine Umgebung für ressourcenarme Systeme bereit. Mit der Connected Limited Device Configuration (CLDC) und dem Mobile Information Device Profile (MIDP) wird ein kleinster gemeinsamer Nenner definiert, den alle Java-Handys erfüllen müssen. Tatsächlich finden sich immer mehr Handys mit Javaunterstützung am Markt und zwar auch solche Geräte, die keine Organizer-Funktionen bereitstellen.

Selbst Qualcomm wirbt mit der Unterstützung dieser alternativen Sprache unter BREW, was den Java-Ansatz zumindest gegenwärtig als das erfolgversprechendste Konzept erscheinen läßt.

Java-Programmierung

Aufgrund der vielen unterschiedlichen Typen von Java-Handys ist der o.g. kleinste gemeinsame Nenner auf den ersten Blick auch relativ eng begrenzt in den Möglichkeiten der Anwendung.

Bildschirmmanipulation, Sound-Ausgabe, Tastaturbehandlung, Zugriffe auf Teile des persistenten Speichers und die Möglichkeit, http-Verbindungen aufzubauen: das sind die Funktionen, auf die Geräte einen Zugriff durch Java ermöglichen müssen.

Sicherheitsrelevante Systemzugriffe sind dabei grundsätzlich ausgeschlossen. Aus diesem Grund ist es auch nicht möglich, auf die Benutzerdaten wie Telefonbuchspeicher oder Terminkalender zuzugreifen.

Der Funktionsumfang reicht jedoch für die Entwicklung von Spielen und anderen intelligenten Rechen- und Notizanwendungen, soweit letztere nicht sowieso schon in das Gerät integriert sind. Ferner lassen sich über http nahezu beliebige Daten mit dem Internet austauschen. Einzig die Kosten für die mobile Datenübertragungen sind dabei noch ein Hemmnis für eine weitere Verbreitung dieser Technologien.

Einführung in Java und MIDP

Die folgenden Abschnitte wenden sich nicht nur an erfahrene Software-Entwickler, sondern auch an jene, die beruflich oder privat einen Einstieg in diese Technologie suchen.

Im Gegensatz zum PC lassen sich auf Mobiltelefonen noch vergleichsweise einfache Programme realisieren, so daß dies ein geeignetes Umfeld für das Sammeln von Erfahrungen in der Programmierung sein kann. Alles, was man dazu als Entwickler neben etwas Geduld benötigt, ist ein javafähiges Handy, ein PC und ggf. eine Internetverbindung. Entwicklungsumgebungen und Werkzeuge sind dann durch kostenlose Downloads aus dem Internet beziehbar.

Wie bereits erwähnt, können größere Projekte aber auch sehr schnell an Komplexität zunehmen. Besteht für ein Unternehmen die Notwendigkeit, professionelle Anwendungen zu entwickeln, so bedarf es häufig großer Erfahrung, um zuverlässige, robuste und hochwertige Software für den mobilen Markt zu konzipieren. Es sind in diesem Fall viele Restriktionen und Randbedingungen einzuhalten, und diese lassen sich nur mit einem umfassenden Projektmanagement realisieren. Es gilt also im Vorfeld abzuwägen, wie groß der Aufwand einer Eigenentwicklung sein wird und ob man ggf. auf eine Unterstützung durch erfahrene Entwicklungsunternehmen zurückgreift.

Entwicklungsumgebung und Werkzeuge

Im Prinzip unterscheidet sich die Entwicklung eines Java-Programms für ein Handy nicht von der Entwicklung eines PC-Programms, da beide auf dem PC erstellt und in einen Bytecode übersetzt werden. Java-Handys besitzen jedoch nur einen eingeschränkten Bytecode-Interpreter mit geringerem Leistungsumfang, der nur die Programme verarbeiten kann, die zuvor auf einem PC vorverarbeitet wurden. Man bezeichnet dies als sog. ?pre-verify?, auf das später noch näher eingegangen wird.

Benötigt wird daher zunächst eine ganz normale Java-Entwicklungsumgebung, das sog. Java Development Kit (JDK). Zusätzlich benötigt man Werkzeuge, welche die handyspezifischen Operationen erledigen.

Man muß dabei beachten, das vollständige JDK zu installieren und nicht nur die Laufzeitumgebung (JRE). Ansonsten benötigt man vor allem das sog. Wireless Toolkit (WTK). Um eine möglichst breite Kompatibilität zu gewährleisten, sollte die Version 1.0.x verwendet werden, die gleichzeitig aber auch die leistungsschwächste Version darstellt.

Sun bietet mit Sun ONE Studio 5 eine komplette Entwicklungsumgebung zum Download an, ist aber zu umfassend, um hier auf wenigen Seiten erläutert zu werden. Stattdessen wird das nachfolgende Beispielprojekt mit einer im Wireless Toolkit (WTK) enthaltenen IDE namens ?KToolbar? übersetzt und kann mit dem auf jedem Windows-System vorhandenen Programm Wordpad oder einem vergleichbaren Texteditor bearbeitet werden.

Die Installation der beiden Tools auf Windows-Rechnern ist recht intuitiv, solange man mit der Installation des JDKs beginnt, da das WTK bei der Installation einen bereits installierten JDK-Compiler voraussetzt. Alle anderen zum Teil recht umfangreichen Komponenten des JDKs werden nicht unbedingt benötigt so daß sich die Frage stellt, weshalb nicht einfach ein passender Compiler im WTK enthalten ist.

Nach der Installation sollte im Startmenü der Eintrag "J2ME Wireless Toolkit 1.0.x" enthalten sein. Dort findet man auch die KToolbar.

Dieses Tool bietet außer einem Editor eine minimale, aber funktionelle Umgebung und ist bestens für einen Einstieg in die Java-Programmierung geeignet. Dabei besteht keine Notwendigkeit, die Compileroptionen manuell einzustellen, was die Arbeit sehr erleichtert.

Um zu testen, ob alles richtig installiert wurde, läßt sich eines der Beispielprojekte übersetzen. Unter ?File->Open Project? werden eine Reihe von Demoprojekten aufgelistet, die sich mit ?Project->Build? übersetzen lassen. Im linken Fenster wird dann das Ergebnis des Compilierens angezeigt.

Der Handy-Emulator

Bevor man ein selbst geschriebenes Programm auf das Handy überträgt, ist es ratsam, dieses zunächst auf dem PC zu testen. Hierzu stehen gleich mehrere sog. Emulatoren zur Verfügung, die unterschiedliche Plattformen repräsentieren.

Das Standardgerät läßt sich u.a. direkt mit einem WTK-Dienstprogramm aus dem Startmenü heraus einstellen. Für das Beispielprojekt sind insbesondere "Default Color Phone" und "Default Monochrome Phone" von Interesse, da diese emulierten Geräte nicht mehr können als das, was die Java-Plattform vorschreibt.

Mit ?Project->Run? startet der Emulator und es läßt sich nachvollziehen, in welcher Weise das gerade übersetzte Programm auf dem Handy arbeiten würde.

Erstellen von Installationspaketen

Auf dem PC lassen sich Java-Programme direkt nach dem Übersetzen ausführen. Bevor ein Programm hingegen auf einem Handy lauffähig ist müssen noch einige, teilweise automatisierte Arbeitsschritte durchgeführt werden.

Zunächst einmal werden alle übersetzten Javaklassen pre-verified, d.h. auf Konsistenz überprüft. Aufgabe des Pre-verify ist es auch festzustellen, ob man Dinge in seinem Programm verwendet, die in der jeweiligen Plattform verboten sind - bei MIDP 1.0 ist dies z.B. das Arbeiten mit Gleitkomma-Arithmetik. Mit dem Pre-verify erhalten alle Klassen eine Art Gütesiegel in Form einer Kennzeichnung. Nur solche geprüften Klassen werden vom Endgerät akzeptiert.

Alle Klassen werden zusammen mit einem sogenannten Manifest-File in ein .jar-Archiv verpackt. Das Manifest-File ist eine einfache Textdatei mit Beschreibungen für die Anwendung. Zu jedem .jar-Archiv muß es darüber hinaus eine .jad-Datei geben, die solche Informationen wie die Dateigröße der zugehörigen .jar-Datei enthält. Das scheint relativ umständlich, die Aufgaben werden aber vom WTK weitestgehend übernommen.

Der Grund für das Verpacken und Beschreiben des Java-Files liegt darin begründet, daß dieser Vorgang mehr Sicherheit und Verifikationsmöglichkeiten bringt. Beispielsweise wird durch Angabe einer Dateigröße im .jad-File deutlich gemacht, wie groß denn das zu ladende Paket letztendlich sein wird und zwar, bevor es zu spät ist, einen Download noch abzubrechen.

In der KToolbar läßt sich mit ?Project->Package->Create_package? ein solches Paket erstellen, das dann im Projektverzeichnis unter "bin" abgelegt wird.

Diese Pakete können entweder mit einer PC-Software des Herstellers oder über den Umweg einer WAP-Seite auf das Handy überspielt werden, auf der man einen Internetlink zu den Dateien bereitstellt. Nokia beispielsweise ermöglicht das Herunterladen direkt aus der PC-Suite heraus, in der unter ?Extras->Gerätesoftware installieren? schlicht die entsprechende .jad-Datei ausgewählt werden kann.

Eine praktische Anwendung

Nachdem die Werkzeuge installiert wurden und die Umgebung getestet wurde, besteht nun die Möglichkeit, eine eigene Anwendungen zu realisieren. Dazu sollte man sich zum Einstieg ein möglichst kleines Projekt wählen, da viele Anwendungen sehr schnell zu umfangreich werden können. Daher scheiden Spiele, Börsenticker o.ä. in der Regel zunächst aus.

Für das nachfolgende Beispiel wird daher eine nicht ganz ernst gemeinte Anwendung realisiert, die aber sehr gut in die verschiedenen Möglichkeiten der Java-Programmierung einführt. Es soll dazu ein Verhütungscomputer auf Basis der Knaus-Ogino-Methode programmiert werden. Diese Methode beschreibt ein relativ ungenaues Verfahren zur Empfängnisverhütung anhand eines zu erstellenden Zykluskalenders, für das aber Geräte tatsächlich auch heute noch kommerziell angeboten werden.

Für eine Einführung in Java sind dabei vor allem folgende Gründe ausschlaggebend:

• Es ist potentiell eine mobile Anwendung
• Der Displayaufbau läßt sich generisch halten, ohne Farben oder eine bestimmte Mindestgröße zu benötigen
• Man kann elementare High-Level Steuerelemente wie Datumseingabe und Ankreuzfelder verwenden
• Man kann die Verwendung der Minidatenbank (RecordStore) testen
• Es wird zum Testen keine Internetverbindung benötigt, so daß keine zusätzlichen Kosten anfallen

Funktion und Aufbau

Nicht nur für mobile Anwendungen gilt, daß vorher geplant werden muß, wie das Programm ablaufen soll. In diesem Fall ist das recht einfach. Die Anwendung soll nach dem Start im oberen Teil des Display ein editierbares Datumsfeld zeigen, das mit dem aktuellen Datum vorbelegt ist. Sofern bereits genügend Daten vorliegen, wird weiter unten im Display durch eine Anzeige dargestellt, wie "fruchtbar" der Tag ist, der durch das Datumsfeld bezeichnet wird. Anderenfalls wird ein entsprechendes "keine Daten"-Symbol angezeigt. Im dritten und untersten Teil des Displays besteht die Möglichkeit, den Tag persistent als Start des Zyklusses zu kennzeichnen.

Persistent bedeutet in diesem Fall, daß dieser Wert nach Verlassen des Programms in der Datenbank gespeichert wird. Um eine geeignete Anzahl an Daten zu ermitteln, muß die Eingabe von Start- und Endzyklus mindestens für die nächsten fünf Monate erfolgen. Andernfalls lassen sich keine geeignet sicheren Aussagen treffen.

Mobiltelefone haben in aller Regel einen vertikal orientierten Bildschirm. Daher ist es sinnvoll, Oberflächenelemente vertikal und nicht in Spalten anzuordnen. Aufgrund der geringen Display-Größe sollte sich ferner bei der Darstellung von Informationen auf das Wesentlichste beschränkt werden.

Auch bei der Speichermöglichkeit in der Datenbank müssen zum Teil Einschränkungen in Kauf genommen werden. Die Größe des freien Speichers ist dabei einerseits vom Handytyp und andererseits von der Anzahl an zusätzlich installierten Programmen, z.B. Spielen, begrenzt. Bei der Datenspeicherung muß also beachtet werden, daß der freie Speicher entsprechend limitiert sein kann. Beim Entwurf von Datenmodellen ist diese kritische Größe daher mit zu beachten.

In dem vorliegenden Beispiel wäre es sicher möglich gewesen, die Daten mandantenfähig, d.h. unter Berücksichtigung mehrerer unterscheidbarer Nutzer abzulegen. Dies hätte jedoch eine zusätzliche Relation und damit mehr Speicherplatz gekostet, weshalb hier nur von einem einzigen Nutzer ausgegangen wird.

Anlegen eines neuen Projekts

Um möglichen Problemen mit den Tools aus dem Wege zu gehen, sollte das Projekt von KToolbar angelegt werden. Unter ?File->New_Project? wird nach dem Namen und der Klasse der anzulegenden mobilen Applikation (MIDLet) gefragt. In diesem Beispiel wird es mit ?Knaus? bezeichnet. Den gleichen Namen kann man auch für die (Haupt)Klasse angeben, und nach dem Bestätigen mit ?OK? werden die Verzeichnisstrukturen des Projekts so eingerichtet, wie sie von KToolbar standardmäßig erwartet werden. Links im Bild erscheint dann in etwa:

Creating project "Knaus"

Place Java source files in "d:\WTK104\apps\Knaus\src"

Place Application resource files in "d:\WTK104\apps\Knaus\res"

Place Application library files in "d:\WTK104\apps\Knaus\lib"

MIDLets

Alle MIDLets erben, ähnlich wie dies auch bei Java Applets der Fall ist, von einer eigens für diesen Zweck implementierten Basisklasse:

javax.microedition.midlet.MIDlet.

Nur so läßt sich gewährleisten, daß alle Anwendungen vom Applikationsmanager überwacht werden, der für das Starten, Unterbrechen und Beenden von MIDLets zuständig ist. Die Anforderungen an diese Kontrollinstanz sind fast noch härter, als dies beispielsweise auf einem PC der Fall ist, denn bei Handys sind Abstürze durch Programme oder das Betriebssystem auf jeden Fall zu vermeiden. Probleme wie nicht ankommende Anrufe oder der Verlust einer SMS sind hier nicht tolerierbar.

Wohl kein Handy-Nutzer hätte dafür Verständnis, und so ist es nachvollziehbar, weshalb MIDLets nur äußerst reglementierte Zugriffsrechte auf das Gesamtsystem bekommen. Ein MIDLet kann dabei die folgenden Zustände annehmen:

• Active: Die Anwendung wurde gestartet und darf nun Systemressourcen beanspruchen
• Paused: Die Anwendung wurde temporär unterbrochen, z.B. weil gerade ein Telefongespräch geführt wird
• Destroy: Die Anwendung wird beendet und alle Ressourcen (bis auf persistent gespeicherte Daten) müssen freigegeben werden

Mit

• startApp()
• pauseApp()
• destroyApp()

werden die Methoden bezeichnet, die ein MIDLet zwingend bereitstellen muß, damit der Applikationsmanager es aufrufen kann, wobei man mit startApp() Applikationen starten darf, die Systemressourcen belegen, z.B. eine Ausgabe auf dem Display.

APIs

Für die Display-Ausgabe stehen Java-Programmen zwei unterschiedliche Konzepte zur Verfügung. Zum einen läßt sich mittels einer Klasse "Canvas" direkt auf dem Handy-Display zeichnen. Dies ist insbesondere für Spiele unverzichtbar, da diese ja gerade von ihrer graphischen Gestaltung leben.

Ein großes Problem ist jedoch, daß man bei der Programmentwicklung stets die unterschiedlichen Geräteeigenschaften, speziell die Bildschirmauflösung, berücksichtigen muß, es sei denn, man möchte sich auf bestimmte Modelle beschränken. Für eine universelle Anwendung wie diese bietet sich daher die High-Level-API an. Sie stellt eine Reihe von Oberflächenelementen zur Verfügung, wobei das eigentliche Aussehen und die Bedienung dieser Elemente bewußt dem Gerätehersteller überlassen wird.

Ein gutes Beispiel hierfür ist das Datumsfeld. Es erlaubt dem Nutzer die Eingabe eines Datums und wahlweise auch einer Uhrzeit. Wie die Eingabe erfolgt, ob über einen eingeblendeten Kalender auf einem Sony-Erricsson oder als Textfeld bei Nokia, diese Entscheidung liegt beim Gerät. Dies gilt ebenso für das Format des Datums, welches ja bekanntlich international nicht einheitlich gehandhabt wird. Gemäß dieses Schemas benötigt man drei Oberflächenelemente.

1. Eine Datumseingabe
2. Einen Anzeigebalken mit Textbeschreibung zur Ergebnisdarstellung
3. Ein Kontrollkästchen mit Beschreibung, das der Benutzer für den ersten Tag der Periode aktivieren kann

Für jedes elementare Oberflächenelement hält MIDP eine separate Klasse bereit. Hierbei kann man sich über Statusänderungen, wie sie insbesondere durch Benutzereingaben erzeugt werden, benachrichtigen lassen. Dies erfolgt, wie in Java üblich, über einen sog. ?Listener?, also eine registrierte Routine, die im Bedarfsfall aufgerufen wird. Über diesen Mechanismus erfährt man, ob der Anwender etwas eingegeben hat und kann darauf entsprechend reagieren.

Datenbanken in MIDLets verwenden

Selbst wenn man großzügig von einer Nutzung dieser Anwendung über 20 Jahre ausgeht, so fallen nur ca. 20 * 12 = 240 Datensätze a 32 Bit an. Das ist ungefähr ein Kilobyte. Auf dem PC würde man keinen Moment zögern und die Daten schlicht bei Programmstart in den Arbeitsspeicher einlesen, um sie aktualisiert bei Programmende wieder auf der Festplatte abzulegen. Auf mobilen Geräten hingegen scheidet dieses Vorgehen gleich aus mehreren Gründen aus:

• MIDP stellt keine Low-Level-Dateioperationen zur Verfügung
• Mobile Geräte sind akkubetrieben und können schon aus diesem Grunde zu jeder Zeit abgeschaltet werden, was dann natürlich Datenverlust zur Folge hätte
• Arbeitsspeicher ist potentiell extrem knapp und es ist alles zu vermeiden, was diesen mehr als notwendig füllt

Zum Zwecke der persistenten Datenhaltung stehen MIDLets sog. Datenbankfunktionen (Record Management System) zur Verfügung. Diese sind allerdings weit weniger umfangreich als beispielsweise bei SQL oder anderen eleganten Abfragesprachen. Ein RecordStore ist nur eine Liste von binären Datensätzen, wobei jedem neu hinzugefügten Record eine eindeutige, aufsteigende ID zugeordnet ist, welche auch dann nicht wiederverwendet wird, wenn der Datensatz gelöscht wird. Mittels Filter und Sortierobjekten lassen sich über einen Enumerations-Mechanismus "Abfragen" von Hand programmieren, wobei sowohl das Einfügen und Auslesen von Daten als auch das Suchen selbst vergleichsweise kompliziert ist.

Datensätze werden binär abgelegt und ausgelesen. Sollen Daten wie Strings, Zahlen o.ä. gespeichert werden, so geschieht dies am einheitlichsten, indem hierfür ein Datenstrom, ein sog. Stream, erzeugt wird, der in ein ByteArray schreibt bzw. aus einem solchen liest.

Mit diesem Stream können dann durch herkömmliche Read- und Write-Operationen Daten ausgetauscht werden. Dies sind einige der Mechanismen, die man besser als Template erzeugen sollte, da sie häufiger verwendet werden müssen. Das gleiche gilt für das Durchsuchen der Datenbank. Dies geschieht über Enumerations-Objekte, denen man beim Erzeugen einen Filter und ein Vergleichsobjekt mitgeben kann. Beim Iterieren über die Datenbank mittels eines solchen Objekts werden dabei nur die vom Filter akzeptierten Elemente zurückgeliefert, und zwar in der Reihenfolge, wie diese durch das Vergleichsobjekt definiert sind.

Nicht minder gewöhnungsbedürftig gestaltet sich auch das Löschen von Elementen. In der einschlägigen Webliteratur über das RMS findet sich daher zum Teil recht abenteuerliche Lösungsansätze für dieses Problem. Zum Löschen benötigt man die ID des zu entfernenden Datensatzes, jedoch gibt es keinerlei Funktion, um sich zu einem Record direkt dessen ID ausgeben zu lassen. So behelfen sich einige Autoren mit dem Markieren eines Records als "gelöscht" oder dem Mitführen einer Liste von IDs im Arbeitsspeicher nur, um diese Datensätze ggf. löschen zu können - alles in allem sind das aber sehr umständliche Vorgehensweisen.

Eleganter kann man sich von unbenötigten Elementen trennen, indem man das zu löschende Element mittels eines Filters auffinden läßt und zwar so, daß keine weiteren Elemente im Ergebnis stehen können. Nun ermittelt man die ID des ersten Elements des Ergebnisses und, sofern man eine ID erhält, löscht man das Element mit eben dieser ID.

Die Anforderung für die Beispiel-Applikation umfaßt damit die Aufgaben, Daten zu erfassen, aufzufinden und zu löschen. Ferner ist es für eine Berechnung unerläßlich, die Daten in logischer Reihenfolge, d.h. aufsteigend sortiert, zu erhalten. Dies muß selbst dann gewährleistet sein, wenn die Daten nicht chronologisch eingegeben wurden. Damit benötigt man letztlich alle Techniken, die das MIDP Record Management System (RMS) bereitstellt.

Der Quellcode

Wer in die Java-Programmierung von Handys einsteigen möchte, sollte seine ersten Schritte an praktischen Beispielen erproben. In diesem Sinne haben wir darauf verzichtet, hier den gesamten Quelltext dieser kleinen Beispiel-Anwendung abzudrucken. Stattdessen sind die Dateien ausführlich kommentiert und zum Download bereitgestellt. Ist die Entwicklungsumgebung eingerichtet und lauffähig, sollte man die Funktionsweise des MIDLet nachvollziehen. Für eine weitergehende Einarbeitung in das Thema reicht dann häufig die Dokumentation der API für die meisten Problemstellungen völlig aus. Diese wird mit dem WTK mitgeliefert und anhand der ebenfalls in diesem Paket enthaltenen Beispiele werden die meisten Klassen auch in ihrer Anwendung gezeigt.

Fazit

Angesichts des rasant steigenden Anteils der javafähigen Handys handelt es sich hier vielleicht um einen der wenigen Bereiche der Software-Entwicklung, in dem in den nächsten Jahren ein Wachstum zu erwarten ist. Dies wird dadurch begünstigt, daß der Mobilfunkmarkt nach Absatzzahlen als gesättigt angesehen wird. Die technologische Innovation der Geräte ist daher die einzige Möglichkeit, den Absatz von Geräten zu erhöhen und zusätzliche Vertragsabschlüsse mit Netzbetreibern zu gewährleisten. Dazu muß das Verbraucherinteresse nach neuen Funktionalitäten, die über das reine Telefonieren hinaus gehen, geweckt werden. Ladbare Anwendungen aller Art sind daher bestens geeignet, dieses Interesse zu erzeugen.

Für den Bereich der Software-Entwicklung ist zu erwarten, daß der Umfang der standardisierten Java-APIs in nächster Zeit erheblich erweitert wird, damit auch andere Funktionen wie Telefonie und Organizer-Software nach dem "Ein Programm für alle Handys"-Verfahren entwickelt werden können. Derzeit wird auch bei telos® an derartigen Erweiterungen zur Standardisierung bereits gearbeitet.