Mobile Information Device Profile

MIDP (Mobile Information Device Profile) ist ein Profil der Java 2, Micro Edition (J2ME), das speziell auf die Fähigkeiten kleiner Mobilgeräte wie Mobiltelefon oder PDA ausgelegt ist. Es umfasst daher Funktionen zur Ansteuerung und Abfrage von ITU-T Einhandtastaturen, Miniaturbildschirmen, flüchtigem und nicht-flüchtigem Speicher im Kilobyte-Bereich etc.

MIDP-Applikationen heißen MIDlets.

Es existieren bisher das MIDP 1.0 und das MIDP 2.0, das einige Erweiterungen aufweist. MIDP 3.0 ist bereits als JSR 271 in Bearbeitung^[1].

MIDP ist ein Sandboxmodell, was große Sicherheit gegenüber Computerviren oder Hackerangriffen gewährleistet. Der Benutzung von Netzwerkeinrichtungen geht eine Bestätigung vom Benutzer voraus, der sie explizit für jedes MIDlet bei erforderlichem Verbindungsaufbau erlauben muss. Viren oder vergleichbare Programme sind laut Sun Microsystems ebenfalls nicht möglich^[2], da das Dateisystem außerhalb der Sandbox liegt und darauf nur sehr eingeschränkt zugreifbar ist.

Hardwarevoraussetzungen

Die Spezifikation MIDP 2.0 stellt Forderungen für die minimale Hardwareausstattung eines Gerätes auf. Unter anderem muss das Gerät eine Displayauflösung von 96×54 Pixeln, 384 Kilobyte Arbeitsspeicher, eine Internetverbindung sowie eine (virtuelle) Soundausgabe besitzen.

MIDP-APIs

Benutzeroberfläche

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.

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 bewegendem Text.

Low-Level-API

Im Gegensatz hierzu arbeitet die Low-Level-API auf Pixelebene. Die Klasse Canvas ist der Eingangspunkt für graphische Zeichnungen. 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.

Record Management System (RMS)

RMS-Struktur

MIDP stellt spezielle APIs für die permanente Speicherung von Daten bereit, die die Realisierung einfacher Datenbank-gestützter Anwendungsprogramme erlaubt. Die Speicherung von Daten innerhalb des Dateisystems am Mobilgerät ist unter J2ME aus Sicherheitsgründen und zur Beibehaltung größtmöglicher Portierbarkeit nicht möglich. MIDP stellt für die persistente Speicherung von Daten eine 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 ist das funktionale Äquivalent zur Java Database Connectivity (JDBC) der J2SE und 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.

Siehe auch

• Connected Device Configuration
• CLDC

Einzelnachweise

1. ↑ http://jcp.org/en/jsr/detail?id=271
2. ↑ http://www.forum.nokia.com/main/resources/technologies/java/faq.html

Weblinks

• http://java.sun.com/products/midp/
• Einführung in die MIDP-Anwendungsentwicklung mit dem Wireless Toolkit (auf zdnet.de)