imported>SchlurcherBot: Bot: http → https

2025-10-19T03:25:25Z

Bot: http → https

Neue Seite

'''MIDP''' ('''''M'''obile '''I'''nformation '''D'''evice '''P'''rofile'') war ein Profil der ''Java Micro Edition'' ([[Java ME]]), das speziell auf die Fähigkeiten kleiner [[Mobilgerät]]e wie [[Mobiltelefon]] oder [[Personal Digital Assistant|PDA]] ausgelegt war. Es umfasste daher Funktionen zur Ansteuerung und Abfrage von [[Internationale Fernmeldeunion|ITU]]-T Einhandtastaturen, Miniaturbildschirmen, flüchtigem und nicht-[[Random Access Memory|flüchtigem Speicher]] im Kilobyte-Bereich etc.

MIDP-Applikationen heißen [[MIDlet]]s.

MIDP ist ein [[Sandbox]]modell, was große Sicherheit gegenüber [[Computervirus|Computerviren]] oder [[Hacker]]angriffen gewährleistete. Der Benutzung von Netzwerkeinrichtungen geht eine Bestätigung vom Benutzer voraus, der sie explizit für jedes MIDlet bei erforderlichem Verbindungsaufbau erlauben muss.

== Hardwarevoraussetzungen ==
Die Spezifikation MIDP 2.0 stellt Forderungen für die minimale Hardwareausstattung eines Gerätes auf. Unter anderem muss das Gerät eine [[Bildauflösung|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.

== 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-[[Programmierschnittstelle|APIs]] für die [[Grafische Benutzeroberfläche|Benutzeroberfläche]] bieten dem Entwickler ein minimales Set aus User-Interface-Elementen ([[Benutzerschnittstelle|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 ====
[[Datei:UI-API.svg|400px|miniatur|Low- und High-Level-API des MID-Profils]]
Die High-Level-API stellt Ein- und Ausgabefelder, wie z. B. Textfelder (<code>TextField</code>) oder Fortschrittsanzeigen (<code>Gauge</code>), zur Verfügung. Sie sind der Elternklasse <code>Item</code> untergeordnet. Objekte von <code>Item</code> können auf einem Formular platziert werden, sind jedoch nur eingeschränkt positionierbar. Formulare sind Objekte der Klasse <code>Form</code>. Sie können an das aktuelle <code>Display</code> 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:
* <code>Form:</code> Container für andere UI-Elemente.
* <code>Command:</code> Repräsentiert einen Menüeintrag. Mehrere Kommandos können in einem Menü zusammengefasst und an ein Formular angehängt werden.
* <code>Alert:</code> [[Pop-up]]-Nachrichten, die den Benutzer über Fehler, [[Exception]]s, Warnungen oder über sonstige Informationen benachrichtigen.
* <code>ChoiceGroup:</code> 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.
* <code>TextField:</code> Einzeilige Eingabefelder, in denen der Benutzer Text einfügen bzw. editieren kann.
* <code>TextBox:</code> Ähnlich einem <code>TextField</code>, allerdings mehrzeilig.
* <code>Gauge:</code> Fortschrittsanzeige.
* <code>[[Nachrichtenticker|Ticker]]:</code> Anzeige von sich bewegendem Text.

==== Low-Level-API ====
Im Gegensatz hierzu arbeitet die Low-Level-API auf [[Pixel]]ebene. Die Klasse <code>Canvas</code> ist der Eingangspunkt für grafische Darstellungen. Sie selbst enthält hierfür keine Methoden, jedoch stellt sie die Callback-Funktion <code>paint()</code> bereit. Sie wird immer dann aufgerufen, wenn der Programmmanager entscheidet, das <code>Display</code> neu zu zeichnen. Ihr einziger Parameter ist ein Objekt <code>Graphics</code>, welches sämtliche Zeichnungsfunktionen, wie beispielsweise <code>drawLine()</code> zum Zeichnen einer Linie oder <code>fillRect()</code> 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 <code>Display</code> zugreifen. Man erhält es als Rückgabeobjekt der statischen Methode <code>getDisplay()</code> mit dem MIDlet als Argument. Die Methode <code>setCurrent()</code> bestimmt, welches Objekt <code>Displayable</code> den Inhalt eines Displays darstellen soll. <code>Displayable</code> ist die Elternklasse von <code>Screen</code> und <code>Canvas</code>. 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) ===
[[Datei:RMS-Struktur.svg|256px|miniatur|RMS-Struktur]]

MIDP stellt spezielle APIs für die permanente Speicherung von Daten bereit, die die Realisierung einfacher [[datenbank]]gestützter [[Anwendungsprogramm]]e erlaubt. Die Speicherung von Daten innerhalb des [[Dateisystem]]s ist aus Gründen der Portabilität nicht in MIDP selbst enthalten, sondern im JSR 75<ref>[https://jcp.org/en/jsr/summary?id=75 jcp.org]</ref> 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.

[[Datei:RMS-Datenbankstruktur.svg|150px|miniatur|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 (Technologie)|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 Byte[[Feld (Datentyp)|arrays]] mit einer zugehörigen, eindeutigen [[Identifikator|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.
[[Datei:Lebenszyklus RMS-DB.svg|320px|miniatur|Lebenszyklus einer RMS-Datenbank]]
Zunächst wird ein RecordStore vom Zustand ''Not Exists'' mit <code>openRecordStore()</code> 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 <code>addRecord()</code>, <code>setRecord()</code> und <code>deleteRecord()</code> modifiziert werden, wobei ein [[Zeitstempel]] (engl. timestamp) den Zeitpunkt ihrer letzten Änderung markiert und ein Zähler nach jeder Änderung inkrementiert wird. Mit <code>getRecord()</code> werden Datensätze unter Angabe ihrer ID ausgelesen. Greifen mehrere [[Thread (Informatik)|Threads]] auf ein RecordStore zu, ist es Aufgabe des MIDlets, diese Zugriffe zu koordinieren. <code>closeRecordStore()</code> 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 <code>RecordStoreNotOpenException</code>. <code>deleteRecordStore()</code> löscht die Datenbank und der Zustand ''Not Exists'' wird erreicht. RecordStore definiert die Methode <code>enumerateRecords()</code> mit Hilfe derer Datensätze gefiltert oder sortiert werden können. Sie liefert ein Objekt <code>RecordEnumeration</code> 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 <code>RecordListener</code> und <code>RecordFilter</code>. <code>RecordListener</code> erlaubt das Abfangen von Ereignissen, wie z. B. Modifikationen der Datenbank, sodass entsprechende Reaktionen gesetzt werden können. Mit <code>RecordFilter</code> 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 [[Obfuskation (Software)|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]]

== Weblinks ==
* [http://www.oracle.com/technetwork/java/index-jsp-138820.html Mobile Information Device Profile (MIDP); JSR 118] bei [[Oracle]]
* [http://www.zdnet.de/builder/program/0,39023551,20000854,00.htm Einführung in die MIDP-Anwendungsentwicklung mit dem Wireless Toolkit] zdnet.de

== Einzelnachweise ==
<references />

[[Kategorie:Java (Programmiersprache)|Midp]]
[[Kategorie:Abkürzung]]

MIDP - Versionsgeschichte

imported>SchlurcherBot: Bot: http → https