- 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.
Inhaltsverzeichnis
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
Die High-Level-API stellt Ein- und Ausgabefelder, wie z. B. Textfelder (
TextField
) oder Fortschrittsanzeigen (Gauge
), zur Verfügung. Sie sind der ElternklasseItem
untergeordnet. Objekte vonItem
können auf einem Formular platziert werden, sind jedoch nur eingeschränkt positionierbar. Formulare sind Objekte der KlasseForm
. Sie können an das aktuelleDisplay
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 einemTextField
, 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-Funktionpaint()
bereit. Sie wird immer dann aufgerufen, wenn der Programmmanager entscheidet, dasDisplay
neu zu zeichnen. Ihr einziger Parameter ist ein ObjektGraphics
, welches sämtliche Zeichnungsfunktionen, wie beispielsweisedrawLine()
zum Zeichnen einer Linie oderfillRect()
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 MethodegetDisplay()
mit dem MIDlet als Argument. Die MethodesetCurrent()
bestimmt, welches ObjektDisplayable
den Inhalt eines Displays darstellen soll.Displayable
ist die Elternklasse vonScreen
undCanvas
. 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)
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.
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.
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 MethodenaddRecord()
,setRecord()
unddeleteRecord()
modifiziert werden, wobei ein Zeitstempel (engl. timestamp) den Zeitpunkt ihrer letzten Änderung markiert und ein Zähler nach jeder Änderung inkrementiert wird. MitgetRecord()
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 einerRecordStoreNotOpenException
.deleteRecordStore()
löscht die Datenbank und der Zustand Not Exists wird erreicht. RecordStore definiert die MethodeenumerateRecords()
mit Hilfe derer Datensätze gefiltert oder sortiert werden können. Sie liefert ein ObjektRecordEnumeration
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 KlassenRecordListener
undRecordFilter
.RecordListener
erlaubt das Abfangen von Ereignissen, wie z. B. Modifikationen der Datenbank, sodass entsprechende Reaktionen gesetzt werden können. MitRecordFilter
können Datensätze auf bestimmte Kriterien überprüft werden.Siehe auch
Einzelnachweise
- ↑ http://jcp.org/en/jsr/detail?id=271
- ↑ http://www.forum.nokia.com/main/resources/technologies/java/faq.html
Weblinks
Wikimedia Foundation.