MIDP

MIDP (Mobile Information Device Profile) ist ein Profil der Java Micro Edition (Java ME), 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 bzw. 2.1, 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. Da MIDP allerdings auf die CLDC-Konfiguration aufsetzt, sind viele Hardwarevoraussetzungen bereits dadurch bestimmt.

Aktueller Status MIDP 2.0

Gegenüber der Version 1.0 ist die derzeit verbreitete Version 2.0 (mit der Variante 2.1) deutlich leistungsfähiger. Es gibt eine Reihe von Features, die den aktuellen Funktionsumfang von Java ME-Anwendungen ausmachen:

• Abspielen von Sound (WAV, MID, MP3)
• Video-Streaming (benötigt zusätzlich Multimedia-API)
• Game-API mit Sprites, Layern etc.
• Unterstützung von HTTPS, Sockets, Serielle Schnittstelle
• Push-Architektur (Server kann MIDlets aktivieren)
• OTA-Provisioning (Verbreitung über Funknetz)

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 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^[3] 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.

Verteilen eines MIDlet

Die Verteilung von MIDlets, also die Zusammenstellung zu einer Programmdatei, erfolgt als Java Archive (JAR). Zusätzlich ist noch eine beschreibende Textdatei spezifiziert, der Java Archive Descriptor (JAD). Viele Mobiltelefone verlangen heute aber keine JAD-Datei mehr, sondern entnehmen die nötigen Informationen dem sog. Manifest, einer im JAR enthaltenen Textdatei mit ähnlichem Aufbau und Inhalt.

Ein JAR kann dabei mehrere MIDlets enthalten, die man dann auch als Midlet-Suite bezeichnet. Natürlich sind im Archiv jeweils nur die kompilierten .class-Dateien und kein Quelltext enthalten. Selbst diese werden meist noch mit einem Obfuscator behandelt. Neben dem Programmcode enthält das JAR oft auch die notwendigen Ressourcen wie Sounds, Grafiken etc.

Im JAD bzw. Manifest sind u.a. Informationen enthalten zu

• Name und Version der MIDlet-Suite
• Name, Icon und Programmdateien der MIDlets
• Anzahl der Bytes in der JAR-Datei (nur JAD)
• Erforderliches Java ME-Profil sowie erforderliche Konfiguration, d.h. CLDC-Version

Zusätzlich haben einige Hersteller wie Nokia Erweiterungen spezifiziert. Auch benutzerdefinierte Einträge zur Konfiguration der Anwendung ähnlich wie Kommandozeilenparameter sind möglich.

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
3. ↑ http://jcp.org/en/jsr/summary?id=75

Weblinks

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