MIDP

MIDP-APIs für die Benutzeroberfläche bieten dem Entwickler ein minimales Set aus User-Interface-Elementen (UI), um eine Interaktivität zwischen Benutzer und MIDlet zu ermöglichen. Es befindet sich im Paket javax.microedition.lcdui. Man unterscheidet zwischen der Low- und High-Level-API.

Low- und High-Level-API des MID-Profils

Die High-Level-API stellt Ein- und Ausgabefelder, wie z. B. Textfelder (TextField) oder Fortschrittsanzeigen (Gauge), zur Verfügung. Sie sind der Elternklasse Item untergeordnet. Objekte von Item können auf einem Formular platziert werden, sind jedoch nur eingeschränkt positionierbar. Formulare sind Objekte der Klasse Form. Sie können an das aktuelle Display angehängt werden und verschiedene UI-Elemente enthalten. Das MIDlet kann Wechsel zwischen Formularen anfordern sowie während der Laufzeit UI-Elemente hinzufügen und auf Benutzereingaben reagieren.

Die wichtigsten UI-Elemente sind:

• Form: Container für andere UI-Elemente.
• Command: Repräsentiert einen Menüeintrag. Mehrere Kommandos können in einem Menü zusammengefasst und an ein Formular angehängt werden.
• Alert: Pop-up-Nachrichten, die den Benutzer über Fehler, Exceptions, Warnungen oder über sonstige Informationen benachrichtigen.
• ChoiceGroup: Implementiert eine Selektionsmöglichkeit zwischen mehreren Einträgen. Die Auswahl ausschließlich einzelner (engl. single choice) oder auch mehrerer Einträge (engl. multiple choice) ist möglich.
• TextField: Einzeilige Eingabefelder, in denen der Benutzer Text einfügen bzw. editieren kann.
• TextBox: Ähnlich einem TextField, allerdings mehrzeilig.
• Gauge: Fortschrittsanzeige.
• Ticker: Anzeige von sich bewegendem Text.

Im Gegensatz hierzu arbeitet die Low-Level-API auf Pixelebene. Die Klasse Canvas ist der Eingangspunkt für grafische Darstellungen. Sie selbst enthält hierfür keine Methoden, jedoch stellt sie die Callback-Funktion paint() bereit. Sie wird immer dann aufgerufen, wenn der Programmmanager entscheidet, das Display neu zu zeichnen. Ihr einziger Parameter ist ein Objekt Graphics, welches sämtliche Zeichnungsfunktionen, wie beispielsweise drawLine() zum Zeichnen einer Linie oder fillRect() zum Ausfüllen eines Rechtecks, enthält.

Grundsätzlich kann man zwischen reinen Hintergrundapplikationen und jenen unterscheiden, die mit dem Benutzer interagieren. Interaktive Applikationen können auf das Display über ein Objekt Display zugreifen. Man erhält es als Rückgabeobjekt der statischen Methode getDisplay() mit dem MIDlet als Argument. Die Methode setCurrent() bestimmt, welches Objekt Displayable den Inhalt eines Displays darstellen soll. Displayable ist die Elternklasse von Screen und Canvas. Ihr sind alle UI-Klassen unterstellt. Mit anderen Worten, sie definiert sämtliche Objekte, die am Display angezeigt werden können.

RMS-Struktur

MIDP stellt spezielle APIs für die permanente Speicherung von Daten bereit, die die Realisierung einfacher datenbankgestützter Anwendungsprogramme erlaubt. Die Speicherung von Daten innerhalb des Dateisystems ist aus Gründen der Portabilität nicht in MIDP selbst enthalten, sondern im JSR 75[1] spezifiziert.

MIDP stellt für die persistente Speicherung von Daten eine eher rudimentäre Alternative zur Verfügung, das Record Management System (RMS). „Persistent“ bedeutet hierbei die Erhaltung der Daten nach mehrmaligen Neustarts des MIDlets und des Mobilgerätes, selbst nach einem Batteriewechsel. Das RMS befindet sich im Paket javax.microedition.rms.

RMS-Datenbankstruktur

Ein MIDlet kann beliebig viele Datenbanken als Instanzen von RecordStore eröffnen. MIDlets innerhalb einer Suite können auf die gleichen Datenbanken zugreifen. MIDlets aus verschiedenen Suiten bleibt der Zugriff verwehrt. Selbst wenn der Name der Datenbank zweier solcher MIDlets gleich ist, existieren zwei getrennte Datenbanken. Erst die MIDP-2.0-Spezifikation erlaubt einen geteilten Datenbankzugriff. Eine RMS-Datenbank befindet sich in einer plattformspezifischen Umgebung. Um das Konzept der Plattformunabhängigkeit von Java zu erhalten, implementiert das RMS intern mehrere auf das jeweilige System abgestimmte Routinen, so dass nach außen hin abstrakte Methoden für Datenbankoperationen verfügbar sind.

Ein RecordStore besteht aus einer Sammlung von Bytearrays mit einer zugehörigen, eindeutigen ID beginnend bei 1. Sie wird als Primärschlüssel (engl. primary key) genutzt. IDs von gelöschten Einträgen werden nicht wiederverwertet. Wird ein neuer Eintrag hinzugefügt, erhält er die nächsthöhere ID der größten jemals vorgekommenen ID. Ein RecordStore kann sich in vier Zuständen befinden.

Lebenszyklus einer RMS-Datenbank

Zunächst wird ein RecordStore vom Zustand Not Exists mit openRecordStore() und einer Bezeichnung (max. 32 Zeichen) als Argument erstellt. Besteht die Datenbank bereits, erfolgt der Übergang vom Zustand Closed. Im darauffolgenden Zustand Open kann die Datenbank mit den Methoden addRecord(), setRecord() und deleteRecord() modifiziert werden, wobei ein Zeitstempel (engl. timestamp) den Zeitpunkt ihrer letzten Änderung markiert und ein Zähler nach jeder Änderung inkrementiert wird. Mit getRecord() werden Datensätze unter Angabe ihrer ID ausgelesen. Greifen mehrere Threads auf ein RecordStore zu, ist es Aufgabe des MIDlets, diese Zugriffe zu koordinieren. closeRecordStore() schließt die Datenbank und führt sie in den Zustand Closed über. In diesem Zustand ist kein Zugriff auf die Datenbank möglich und führt bei einem solchen Versuch zu einer RecordStoreNotOpenException. deleteRecordStore() löscht die Datenbank und der Zustand Not Exists wird erreicht. RecordStore definiert die Methode enumerateRecords() mit Hilfe derer Datensätze gefiltert oder sortiert werden können. Sie liefert ein Objekt RecordEnumeration zurück, das einen flexiblen Umgang mit einer RMS-Datenbank erlaubt. Diese Schnittstelle weist große Ähnlichkeit zur Implementierung einer klassischen verketteten Liste auf. Sie enthält Methoden zum dynamischen Durchlaufen der Datensätze sowie Abfragen, ob es ein nächstes oder vorheriges Element gibt etc. Weitere Schnittstellen sind die Klassen RecordListener und RecordFilter. RecordListener erlaubt das Abfangen von Ereignissen, wie z. B. Modifikationen der Datenbank, sodass entsprechende Reaktionen gesetzt werden können. Mit RecordFilter können Datensätze auf bestimmte Kriterien überprüft werden.