Möglichkeiten und Grenzen von J2ME

Transcription

Möglichkeiten und Grenzen von
J2ME
Studienarbeit im Fach Informatik
vorgelegt von
Merlin Tonka
geb. 01.07.1971 in Mbanga - Kamerun
angefertigt am 11.04.2003
Institut für Informatik
Lehrstuhl für Informatik 2
Programmiersysteme
Friedrich-Alexander-Universität Erlangen–Nürnberg
(Prof. Dr. M. Philippsen)
Betreuer: Dipl.Inf. Frank Strüber
Beginn der Arbeit: 15.01.2003
Abgabe der Arbeit: 14.04.2003
i
Ich versichere, dass ich die Arbeit ohne fremde Hilfe und ohne Benutzung anderer
als der angegebenen Quellen angefertigt habe und dass die Arbeit in gleicher oder
ähnlicher Form noch keiner anderen Prüfungsbehörde vorgelegen hat und von dieser als Teil einer Prüfungsleistung angenommen wurde. Alle Ausführungen, die
wörtlich oder sinngemäß übernommen wurden, sind als solche gekennzeichnet.
Der Universität Erlangen-Nürnberg, vertreten durch die Informatik 2 (Programmiersysteme), wird für Zwecke der Forschung und Lehre ein einfaches, kostenloses,
zeitlich und örtlich unbeschränktes Nutzungsrecht an den Arbeitsergebnissen der
Studienarbeit einschließlich etwaiger Schutzrechte und Urheberrechte eingeräumt.
Erlangen, den 11.04.2003
Merlin Tonka
ii
Zusammenfassung
Die folgende Ausarbeitung beschäftigt sich mit der Java 2 Microedition (J2ME).
Im zweiten Kapitel werden J2ME, die Begriffe Konfiguration und Profil erklärt.
Im dritten Kapitel werden die Anforderungen und Möglichkeiten von Mobil Device Information Profil (MIDP) anhand eines konkreten Beispiels besprochen.
Im vierten Kapitel werden die anderen J2ME Profile und einige wichtige optionale Profile kurz beschrieben. Dannach werden einige Werkzeuge zur Arbeit mit
J2ME vorgestellt.
Abschließend wird im fünften Kapitel einen Ausblick über J2ME gegeben.
Inhaltsverzeichnis
1 Einleitung
1
2 Java 2 Microedition
2
2.1
Übersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
2.2
Die Java Plattformen . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.3
J2ME Architektur
. . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.3.1
Konfigurationen . . . . . . . . . . . . . . . . . . . . . . . .
5
2.3.2
Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
3 Anforderungen und Möglichkeiten von MIDP
10
3.0.3
Grundlagen von MIDP . . . . . . . . . . . . . . . . . . . .
11
3.0.4
Benutzeroberfläche . . . . . . . . . . . . . . . . . . . . . .
16
3.0.5
MIDlet-Beispiel . . . . . . . . . . . . . . . . . . . . . . . .
19
3.0.6
Record Management System (RMS) . . . . . . . . . . . . .
24
3.0.7
Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
3.0.8
Netzwerktechnologie . . . . . . . . . . . . . . . . . . . . .
28
3.0.9
Over The Air (OTA) . . . . . . . . . . . . . . . . . . . . .
29
3.0.10 Sicherheitsmechanismen . . . . . . . . . . . . . . . . . . .
32
iii
INHALTSVERZEICHNIS
4 PDAP, FP und die optionalen Profile
iv
34
4.1
Personal Digital Assistent Profil (PDAP) . . . . . . . . . . . . . .
34
4.2
Foundation Profil (FP) . . . . . . . . . . . . . . . . . . . . . . . .
34
4.3
Die wichtigsten optionalen Pakete . . . . . . . . . . . . . . . . . .
35
4.3.1
Bluetooth API . . . . . . . . . . . . . . . . . . . . . . . .
35
4.3.2
Wireless Messaging API(WMA) . . . . . . . . . . . . . . .
36
4.3.3
Mobile Media API(MMAPI) . . . . . . . . . . . . . . . . .
37
4.3.4
Location API . . . . . . . . . . . . . . . . . . . . . . . . .
37
Werkzeuge zur Arbeit mit J2ME . . . . . . . . . . . . . . . . . .
38
4.4.1
J2ME Wireless Toolkit . . . . . . . . . . . . . . . . . . .
40
4.4.2
JBuilder 7 Enterprise with MobileSet 3 . . . . . . . . . . .
40
4.4.3
Sun One Studio 4 Mobile Edition . . . . . . . . . . . . . .
40
4.4.4
Metrowerks CodeWarrior Wireless Studio . . . . . . . . . .
40
4.4.5
Whiteboard SDK . . . . . . . . . . . . . . . . . . . . . . .
40
Eingebette Systeme, die die J2ME verwenden . . . . . . . . . . .
41
4.4
4.5
5 Ausblick
42
5.1
Vergleich von J2ME mit J2SE . . . . . . . . . . . . . . . . . . . .
42
5.2
Probleme und Grenzen vom J2ME . . . . . . . . . . . . . . . . .
42
5.3
Alternativen zur Verwendung von J2ME . . . . . . . . . . . . . .
43
Literatur und Quellen
43
Index
44
Kapitel 1
Einleitung
Heutzutage gibt es Mikroprozessoren in fast allen elektronischen Geräten.
Die zunehmende Komplexität der Anwendungen eingebetteter Systeme und ihre
Netzverbindung bringt neue Probleme mit sich:
✸ zunehmende Funktionalität der Geräte
✸ existierende Software sollte unter zukünftigen Geräten lauffähig bleiben
✸ Netzwerkfähigkeit
✸ Datensicherheit
✸ große Architekturvielfalt
Für die Erstellung von Software, die auf vielen verschiedenen Architekturen lauffähig
sein soll, gibt es zwei Möglichkeiten:
✸ Es wird eine Plattform spezifiziert, sodass entwickelte Software auf jeder
Architektur lauffähig ist, die diese Plattform unterstützt.
✸ Die Software wird manuell auf jede Architektur portiert.
In der folgenden Arbeit wird der erste Ansatz anhand von J2ME und einigen
Beispielprogrammen, die typische J2ME-Anwendungen verdeutlichen, analysiert.
Im Hauptteil der Arbeit werden die Technik und die Möglichkeiten von J2ME
beschrieben (Kapitel 2), abschließend werden kurz noch die Grenzen von J2ME
betrachtet und es wird ein Ausblick gegeben, wie J2ME in Zukunft eingesetzt
werden könnte (Kapitel 3).
1
Kapitel 2
Java 2 Microedition
J2SE und J2EE sind Java-Plattformen für Desktop und Server Rechner. J2ME
wurde konzipiert, um den Einsatz von Java auf eingebetteten Systemen zu ermöglichen.
Die Weiterentwichklung von Java macht die Bibliotheken und APIs1 immer
grösser, sodass es besonders wichtig ist für kleine Geräte, die begrenzte Ressourcen haben, eigene APIs zu entwichkeln.
2.1
Übersicht
Java ist eine plattformunabhängige Sprache mit dem Leitspruch:“Write once,
run anywhere.“(einmal programmieren, überall ausführen). Der Java-Compiler
erzeugt nicht Maschinencode, sondern einen Java-Bytecode, der dann von der
Laufzeitumgebung (Java Runtime Environment) zur Laufzeit ausgeführt wird.
Es gibt Laufzeitumgebungen für verschiedene Betriebssysteme. Die Anwendungen laufen innerhalb der Java Virtual Machine. Um zu verhindern, dass JavaProgramme die Laufzeitumgebung zum Abstürz bringen, ist in Java eine Prüfung
des Codes zur Laufzeit eingebaut, die sogenannte Bytecode Verifikation. Diese
bringt Performance Einbußen mit sich. Ausserdem ermöglicht Java das dynamische Nachladen von Klassen.
1
Application Program Interfaces sind Bibliotheks-Klassen, die dem Entwickler eine definierte
Funktionalität zur Verfügung stellen.
2
KAPITEL 2. JAVA 2 MICROEDITION
2.2
3
Die Java Plattformen
Wir werfen einen Blick auf die drei Java Versionen, um zu verstehen, welche
Java Plattform für welche Gerate konzipiert ist:
Abbildung 2.1: Java 2 Umgebungen und deren Zielmarkt
✸ Die Java 2 Standard Edition (J2SE)
Die J2SE ist für Desktop Rechner entwickelt worden.
✸ Die Java 2 Enterprise Edition (J2EE)
Die J2EE ist für Server Anwendungen geeignet.
✸ Die Java 2 Microedition (J2ME)
Die J2ME ist für kleine Geräte mit begrenztem Speicher (bis 2MB RAM),
4
Display und Prozessoren (bis 100MHz) wie Handys, PDAs (Personal Digital
Assistent), Smartphone bis hin zu gößeren Geräte wie Set Top Boxen 2 .
2.3
J2ME Architektur
Die J2ME-Architektur basiert auf den Konzepten Konfiguration und Profil,
die die Java-Plattform auf eine spezielle Klasse von Geräten anpassen.
Abbildung 2.2: J2ME Architektur
Diese Bild zeigt uns die vier Bausteine der J2ME-Architektur:
✸ die Konfigurationen
✸ die Profile
✸ die virtuelle Maschine (z.B. JVM, KVM)
✸ das Betriebssystem (z.B. PalmOS, PocketPC)
Um J2ME zu verstehen müssen wir zuerst die Begriffe Konfiguration und Profile genau verstehen. Wir werden in den folgenden Unterkapiteln die beiden Begriffen kennenlernen.
2
Set-Top Boxen sind Geräte, die in Zusammenhang mit einem Fernseher einen Internetzugang ermöglichen
2.3.1
5
Konfigurationen
Eine Konfiguration definiert eine Klasse von Geräten. Eine Konfiguration stellt
Anforderungen an die virtuelle Maschine, unterstützt Bibliotheken und den abgedeckten Java-Sprachumfang. J2ME hat zwei unterschiedliche Konfigurationen:
✸ Die Connected Device Configuration (CDC) arbeitet mit derselben Java 2
Virtual Maschine wie J2SE
✸ Die Connected Limited Device Configuration (CLDC) arbeitet mit einer
“abgespeckten“ virtuellen Maschine
(z.B. der “Kilobyte Virtual Machine “)
Connected Device Configuration (CDC)
Als erste Konfiguration betrachten wir die CDC. Sie kann mit der klassischen
virtuellen Java Maschine ausgefürt werden. Diese virtuelle Maschine benötigt
für ihre Unterstützung mehrere Megabytes Speicher. Diese Konfiguration ist für
Geräte mit permanentem Netzwerkanschluß, einem schnelleren Prozessor (32Bit),
mit mindestens 512KB Speicher (ROM/Flash) für die Ausfürung von J2ME- Anwendungen, mit mindestens 256KB Speicher (RAM) und einer schnellen Netzverbindung (z.B. LAN, 56KB Modem bis hin zu DSL) gedacht. So zusagen für kleine
Geräte mit einbisschen größerem Speicherplatz und Rechenleistung wie “Screen
Phone “ und “Set Top Boxen “.
Connected Limited Device Configuration (CLDC)
Abschließend lernen wir die CLDC als unsere Ziel-Konfiguration kennen. Das
MIDP basiert auf dieser Konfiguration. Die CLDC ist für Geräte mit begrenzten Ressourcen konzipiert. Sie unterstützt Geräte, die hauptsächlich mit Batterie
betrieben sind und verwenden die virtuelle Java Maschine, die für diese Gruppe von Geräte entwickelt worden ist. Diese Geräte haben einen 16 Bit oder 32
Bit Prozessor mit 8 bis 32MHz, eine minimale graphische Oberfläche, 160 bis
512KB Speicheranforderungen für das gesamte J2ME (d.h für die virtuelle Maschine und J2ME-Anwendungen), mindestens 128KB nichtflüchtigen Speicher für
JVM und CLDC-Bibliotheken, mindestens 32KB für die Laufzeitumgebung und
neue erzeugte Objekte und einen Anschluss an einem Netzwerk mit begrenzter
Bandbreite (z.B. GSM-Handy mit 9600 Bit/s). Die gesamten J2SE-Bibliotheken
sind für kleine Geräte mit begrenzten Ressourcen zu groß. Um diese Bibliotheken an kleine Geräte anzupassen, wurden einige Funktionalitäten reduziert (z.B.
6
die java.lang.math wurde deutlich reduziert) oder komplett eliminiert (z.B. das
java.awt Paket von J2SE wurde durch javax.microedition.lcdui Paket in J2ME
ersetzt. Dieses J2ME-Paket passt sich an die Eigenschaften von J2ME-fähigen
Geräte an). CLDC1.1 [5] hat einigen Änderungen an CLDC1.0 gebracht. Folgendes wird jetzt von CLDC1.1 unterstützt:
✸ Gleitkommazahlen mit den Klassen Float und Double.
✸ Neue Klassen:
✸ Die Klasse java.util.Random. Damit hat man einen Zufallsgenerator,
der für die Entwicklung von MIDP-Anwendungen wie Spiele sehr wichtig ist.
✸ Die Klasse java.lang.Math, die die Methoden max, abs, ceil, floor, trigonomische Funktionen und die Berechnung der Wurzel zur Verfügung
stellt.
✸ eine neue Fehlerklasse, die java.lang.NoClassDefFoundError
✸ zwei Weak Reference Klassen, die java.lang.ref.Reference
und java.lang.ref.WeakReference.
CLDC unterstützt Multithreading und Garbage Collection wie in J2SE. Im
Gegensatz zu J2SE, wo meist ein just-in-time Compiler eingesetzt wird, verwendet die J2ME eine KVM Interpretation.
Handys, PDAs3 und Smartphones sind mögliche Zielgeräte der CLDC. Aus
Platz- und Performancegründen, sind die herkömmlichen J2SE-APIs stark eingeschränkt.
Wir haben jetzt die wichtigste Konfiguration kennengelernt. Jetzt werden wir
die virtuelle Machine, die die Eigenschaften der obigen Konfiguration erfüllt, kurz
beschreiben.
Das Kilobyte Virtual Machine (KVM)
Die virtuelle Maschine ist die Maschine hinter jeder Java-Anwendung. Sie ist
zuständig für die Sicherheit, die Speicherverwaltung, und die Ausführung von
Threads. Das KVM ist die virtuelle Maschine von Sun, die die Anforderungen,
der CLDC erfüllt. Deshalb unterstützt die KVM alle CLDC-Bibliotheken. Jedes
J2ME-fähige Gerät muß eine CLDC-fähige virtuelle Maschine unterstützen.
Wie ist die Sicherheitsprüfung innerhalb der KVM?
Die Entwicklung von Anwendungen für KVM erfolgt mit dem normalen “Java
3
Personal Digital Assistent
7
Development Kit (JDK) “. Der Boothclasspath teilt dem Java Compiler mit, dass
er als Basis API, die CLDC APIs verwendet soll. Die Sicherheitsprüfung innerhalb
der virtuellen Maschine (VM) schützt die Laufzeitumgebung gegen gefährlichen
Code, der sie zum Abstürz bringen könnte. In der JVM ist der Class-Verifier
dafür zuständig, dass der Bytecode keine illegale Anweisung ausführt. Die CLDC
fordert, dass diese Klassenverifizierung in zwei Schritten abläuft.
Abbildung 2.3: Zwei Phasen Klassenverifizierung in CLDC
In J2SE wird eine Bytecode-Verifizierung zur Laufzeit durchgeführt. In CLDC
wird hingegen statisch eine Pre-Verifizierung durchgeführt, weil dieser Schritt sehr
viele Ressourcen verbraucht und damit auf einem kleinen Gerät mit begrenzten
Ressourcen nur schwer durchgeführt werden kann. Der Preverifier 4 fügt in den
Bytecode eine Prüfsumme ein, die dann zur Laufzeit geprüft wird. Dieser Mechanismus ist unsicher und kann zum Absturz der Laufzeitumgebung führen, falls
4
Der Peverifier ist ein Hilfsprogramm, der Prüfsummen im Bytecode einfügt
8
eine schädliche Anwendung mit gefälschten Prüfsummen eingeschmuggelt wird.
Der Bytecode wird nicht mehr zur Laufzeit geprüft, sondern nur die Prüfsumme. So wird in CLDC zuerst eine externe Verifizierung (“preverifier “) außerhalb
des Zielsgeräts durchgeführt. Dann wird eine interne Verifizierung (“runtime verifier“) in der virtuellen Maschine des Zielgeräts durchgeführt. Die CLDC benutzt
das “Sandbox (Sandkasten)“Model, das genau sagt, dass nur die VM auf die
Geräte-Ressourcen zugreifen darf. Die Anwendungen werden in einem reservierten Speicherplatz gespeichert und können nur auf die CLDC, ihre Profile und die
zugehörigen optionalen APIs zugreifen.
Wir haben die Elemente, die zur CLDC gehören kennengelernt. Als letzter
wichtiger Schritt wird der Begriff Profil erklärt und anschließend das MIDP.
2.3.2
Profile
Innerhalb einer Konfiguration gibt es viele Typen von Geräten, die unterstützt
werden. Diese Geräte können unterschiedliche Fähigkeiten haben, obwohl sie zur
gleichen Konfiguration gehören (z.B. Handy und PDA haben unterschiedlichen
Bildschirm, aber gehören zur gleichen Konfiguration). Um diese verschiedenen
Fähigkeiten zu adressieren, werden Profile für eine spezielle Klasse von Geräten
spezifiziert.
Ein Profil ist eine Erweiterung der Konfiguration. Es definiert eine Menge von
APIs für die Unterstützung einer speziellen Geräteklasse mit bestimmten Fähigkeiten.
9
Abbildung 2.4: J2ME grundlegende Aufbau
Die J2ME hat drei wichtige Profile und einige optionale Pakete:
✸ CLDC:
✸ Mobile Information Device Profil (MIDP)
✸ Personal Digital Assistent Profil (PDA)
✸ CDC:
✸ Foundation Profil (FP)
Wir werden MIDP ausführlich in den nächsten Kapiteln kennenlernen sowie
die anderen Profile und einige wichtige optionale Pakete kurz beschreiben.
Kapitel 3
Anforderungen und
Möglichkeiten von MIDP
Wie eine Konfiguration, stellt auch MIDP eigene Anforderungen an Software
und Hardware. Wir werden in den folgenden Unterkapiteln, die Anforderungen
von MIDP an Software und Hardware betrachten, abschließend die Möglichkeiten
von MIDP. Der Hersteller eines J2ME-fähigen Geräts muß einige grundlegende
Hardware- und Software-Anforderungen erfüllen.
Hardware Anforderungen
Das MIDP-Gerät muß:
✸ einen Bildschirm mit mindestens 96*54 Pixels besitzen.
✸ die Interaktion zwischen dem Benutzer und der MIDP-Anwendung (z.B.
durch Knöpfe) unterstützen.
✸ mindestens 128KB nichtflüchtigen Speicher (ROM/Flash) für die Ausführung
seiner Komponenten haben.
✸ mindestens 8KB nichtflüchtigen Speicher für die dauerhafte Speicherung
von Daten wie Eigenschaften einer Anwendung oder Dateien haben.
✸ mindestens 32KB flüchtigen Speicher (RAM) für die Ausführung der MIDPAnwendung haben.
✸ eine drahtlose Netzwerkverbindung ermöglichen.
10
KAPITEL 3. ANFORDERUNGEN UND MÖGLICHKEITEN VON MIDP 11
Software Anforderungen
Eine Software, die MIDP unterstützt muß:
✸ einen Scheduler, eine Ausnahmebehandlung und die Ausführung von Interrupts unterstützen.
✸ in der Lage sein, die Java Virtual Machine (JVM) für CLDC zum Laufen
zu bringen.
✸ das Zeichnen von Grafiken auf dem Display unterstützen.
✸ die Eingabe vom Benutzer akzeptieren und die Information an die JVM
übergeben.
✸ das Lesen und Schreiben auf dem nichtflüchtigen Speicher unterstützen.
Nach den Anforderungen von MIDP werden nun seine Möglichkeiten beschrieben.
3.0.3
Grundlagen von MIDP
Das MIDP hat als Ziel eine Architektur und APIs zu entwickeln, um die Entwicklung von Anwendungen für drahtlose Geräte mit beschränkten Ressourcen
zu ermöglichen. MIDP basiert auf CLDC. Wir wissen, dass kleine Geräte sehr
viele Fähigkeiten haben. Die Java Community Process Expert Group hat eine
begrenzte Zahl von APIs spezifiziert, die als absolut wichtig für kleine Geräte
sind:
✸ Bereitsstellung und in Rechnung stellen der Applikation
✸ Lebenzyklus einer Anwendung
✸ Ein Modell der Signierung der Anwendung und ein Sicherheitsmodel für
priviligierte Bereiche
✸ Aufeinanderfolgende Verhandlungssicherheit
✸ Dauerhafte Speicherung von Daten
✸ Netwerktechnologie
✸ Ton
✸ Schuduler
✸ Benutzeroberfläche
Die MIDP Architektur
Bevor wir MIDP beschreiben, werfen wir einen Blick auf die MIDP-Architektur.
Abbildung 3.1: CLDC, MIDP und Bluetooth Architekture
Mit dem folgenden Bild können wir genau sehen, dass es zwei Typen von APIs
über der CLDC gibt:
✸ MIDP mit ihren optionalen APIs (Bluetooth, Location etc). Um zu gewährleisten, dass sich alle MIDP-Anwendungen auf allen MIDP-fähigen Geräten
ausführen lassen, hat das Profil sich nur auf den kleinsten gemeinsamen
Nenner seiner Zielgeräte beschränkt. Es gibt im MIDP keine Unterstützung
für Dinge wie SMS1 oder Bluetooth, die für den Benutzer wichtig sind.
✸ Die OEM-Spezifische2 APIs. Die proprietären Lösungen werden entwickelt,
weil das MIDP nicht alle Funktionalitäten eines Geräts unterstützt. Beim
Nokia und Siemens gibt es Bibliotheken, die den Zugriff auf gewisse Funktionen des Geräts (wie die Infrarot-Schnittstelle) ermöglichen. Die MIDPAnwendungen, die mit proprietären Lösungen entwickelt worden sind, können
1
Short Message Service
Eine OEM-Spezifische Anwendung beinhaltet Klassen, die nicht Teil von MIDP sind. Diese
Anwendungen können nicht zu anderen MIDP-fähigen Geräten portiert werden.
2
selbtverständlich nicht zu anderen MIDP-Fähigen Geräte portiert werden.
Da die OEM-speczifischen APIs nicht portabel sind und die Verbreitung von
MIDP einschränken, wurden in MIDP2.0 optionale APIs definiert, die diese proprietäre Lösungen standardisieren. Bevor die ersten MIDP2.0 Geräte
auf dem Markt kommen, müssen wir noch mit diesen proprietären Lösungen leben. Wir werden die wichtigsten optionalen APIs im nächsten Kapitel
kurz beschreiben.
Die Architektur zeigt auch, dass die CLDC/MIDP-Anwendungen nicht nur auf
einem Betriebssystem (wie PalmOs) laufen können, sondern auch neben NativeAnwendungen3 .
Bevor wir unsere erste MIDP-Anwendung entwickeln können, müssen wir zuerst verstehen was ein MIDlet4 ist.
Abbildung 3.2: MIDP-Architektur und MIDP-Anwendung
Dieses Bild zeigt genau, dass jedes MIDlet über dem MIDP-Profil liegt. Mehrere
MIDlets werden in ein Paket eingepackt und bilden so eine sogenante MIDlet
Suite. Eine MIDlet Suite kann ein oder mehrere MIDlets enthalten. Der Benutzer
kann von einem Server immer eine MIDlet Suite herunterladen, und die einzelnen
MIDlets ausführen.
Das Lebenzyklus eines MIDlets hat 3 Zustände:
3
4
Eine Native-Anwendung ist eine Anwendung, die nicht in Java geschrieben ist.
Ein MIDlet ist eine MIDP-Anwendung, die nur die APIs aus MIDP und CLDC verwendet.
Abbildung 3.3: MIDlet Lebenzyklus
Auf dem Bild sehen wir folgende Zustände:
✸ Ein Midlet befindet sich im Zustand Paused, wenn es gerade nicht genutzt
wird, entweder anfangs oder durch einen entsprechenden Methodenaufruf.
✸ Ein MIDlet befindet sich im Zustand Active, wenn es mit dem Benutzer
interagiert.
✸ Der Zustand Destroyed zeigt, dass das MIDlet alle Ressourcen, die es hat,
freigegeben hat. Danach kann der Garbage Collector es aufräumen.
Nachdem beschrieben wurde, was ein MIDlet ist, werden wir im nächsten Kapitel sehen, wie ein MIDlet erzeugt wird.
Wie wird ein MIDlet entwickelt?
Die Struktur eines MIDlets ist ähnlich der eines Applets. Es gibt hier keine main-Methode, sondern eine start-Methode. Jedes MIDlet wird immer von
der abstrakten Klasse MIDlet abgeleitet. Die Klasse MIDlet hat die folgenden 3
Methoden, die den obigen Zustandsübergängen entsprechen:
✸ abstract void startApp()
✸ abstract void pauseApp()
✸ abstract void destroyApp(boolean unconditional)
Jede abgeleitete Klasse muß alle abstrakten Methoden der Klasse MIDlet implementieren. Wir werden es an einem konkreten Beispiel in Kapitel 3.0.5 zeigen.
Der Java Application Manager (JAM)5 kommuniziert direkt mit dem MIDlet.
Der JAM muß folgendes ermöglichen:
✸ den Zugriff von MIDP-Anwendungen auf MIDP- und CLDC-Bibliotheken
✸ den Zugriff von MIDP-Anwendungen auf die JAR-Datei
Um alles genau zu verstehen, betrachten wir folgendes Bild;
Abbildung 3.4: Kommunikation zwischen JAM und dem MIDlet
Das Bild zeigt die 3 wichtigsten Nachrichten, die in beiden Richtungen gesendet
werden können. Als Beispiel kann der JAM einen MIDlet unterbrechen (pauseApp), damit der Benutzer einen ankommenden Anruf beantworten kann. Wenn
die Verbindung beendet wurde, sendet das MIDlet die Nachricht resumeRequest 6
an JAM. Dann startet JAM das MIDlet wieder.
Wir haben die beiden wichtigsten Begriffe von MIDP gelernt, jetzt werden wir
die wichtigsten MIDP APIs dargestellt.
5
Der JAM ist eine Anwendung, die im Gerät installiert ist, das MIDP unterstützt. Sie ist
für die Installation, die Ausführung und die Deinstallation von MIDlets zuständig.
6
Mit der resumeRequest Methode fordert das MIDlet den JAM auf das MIDlet zu reaktivieren.
3.0.4
Benutzeroberfläche
Eine Möglichkeit die MIDP anbietet, ist die Entwicklung von Benutzeroberflächen. Die “Graphic User Interfaces (GUI)“ bei eingebetteten Systeme haben
anderen Anforderungen als beim Desktop. Die APIs die hier entwickelt wurden
achten auf die Eigenheiten von Handys und Pagers. In allen GUI - Klassen befinden sich spezielle MIDP-KLassen und sie basieren nicht auf “Abstract Window
Toolkit (AWT)“ von J2SE. Unter MIDP wird stets nur ein Fenster am Bildschirm
angezeigt, da das Display sehr klein ist. MIDP stellt folgende Bibliotheksklassen
zur Verfügung.
Abbildung 3.5: Aufbau der Klasse Displayable
Dieses Bild zeigt uns die wichtigsten APIs, die wir haben, um Benutzeroberflächen
zu entwickeln. Ganz oben haben wir die Klasse Display. Jedes MIDlet hat als Instanzvariable ein Display-Objekt. Dieses Objekt zeigt z.B. die Anzahl der Farben,
die das Gerät unterstützt, mit der Methode int numColor() an. Die Klasse Displayable ermöglicht das einfügen einer Form, Canvas, Command, Ereignis-Händler
in einer Anwendung. Wir werden die verschiedenen Elemente, die wir in diesem
Bild haben, kurz beschreiben.
Eigenschaften der Benutzeroberfläche
MIDP ist für drahtlose, kleine Geräte entwickelt worden. Die Geräte wie Handy, PDA und Pager haben alle im Vergleich zum Desktop PC kleine Displays, aber
nicht alle haben einen Touch-Screen. Unter Berücksichtigung dieser Beschränkungen müssen MIDP-Anwendungen die gleichen Funktionalitäten für alle Geräte
haben. So wurde das GUI beim MIDP in zwei Ebenen geteilt:
✸ High-Level API
✸ Low-Level API
Die High-Level APIs
Diese Schnittstellen ermöglichen die Portierung vom GUI auf verschiedene
Geräte. Das Aussehen eines GUI variert von einem Gerät zu anderen. Diese API
hat mehr Klassen als die API aus dem Low-Level. Die wichtigsten APIs sind:
✸ Die Klasse Form (d.h. Formular) gibt die Möglichkeit, mehrere Komponenten in einem Fenster zu zeigen. Sie ist ein Container, der mehrere Komponenten beinhaltet. Mit den Methoden append, insert, replace und delete, kann eine Komponente in einer Form angehängt, eingefügt, ersetzt oder
gelöscht werden. Wenn eine Komponente in einer Form eingefügt wird, muß
der Ereignis-Händler ItemStateListener aufgerufen werden. Ein EreignisHändler überwacht die Ereignisse, die vom MIDlet kommen und reagiert
entsprechend. In einem MIDlet gibt es nur die folgenden zwei Typen von
Ereignis-Händlern:
- Die CommandListener-Schnittstelle definiert eine Methode commandAction(), die aufgerufen wird, wenn ein Knopf gedrückt wird.
- Die ItemStateListener wird aufgerufen, wenn eine Komponente des Formular ihren Zustand geändert hat (z.B. Änderung eines Nachrichten-Texts).
In einer Form können nur folgende Komponenten aus der Unterklasse Item
eingefügt werden.
✸ Die DateField-Komponente aus der Klasse DateField
(javax.microedition.lcdui.DateField) ermöglicht eine Manipulierung
des Datums.
✸ Mit der Gauge-Komponente aus der Klasse Gauge, kann der DownloadAblauf einer Datei oder der Installierungs-Ablauf einer Software angezeigt werden.
✸ Das StringItem aus der Klasse StringItem zeigt einen NachrichtenText, den der Benutzer nicht modifiezieren kann.
✸ Das TextField ermöglicht das Schreiben eines Texts wie Name oder
E-Mail Adresse.
✸ Das ImageItem aus der Klasse ImageItem kann genutzt werden, um
ein Bild an einer bestimmten Position im Formular zu platzieren.
z.B.
private Form fmMain = new Form (“Mein Studienarbeit“);
private DateField dfToday = new DateField (“Today:“,DateField.Date);
...
fmMain.append (dfToday);
fmMain.setItemStateListener(this);
✸ Wir verlassen jetzt die Unterklasse Form, wo Komponenten angehängt werden können, und betrachten andere Unterklassen von Screen (Siehe Abbildung 2.5). Diese Klassen werden jetzt kurz beschrieben.
✸ Die Choice-Schnittstelle definiert Methoden zur Auswahl zwischen mehrere Möglichkeiten. Es gibt in MIDP zwei Klassen, die die obigen
Schnittstellen implementieren:
- public class ChoiceGroup extends Item implements Choice {...}
Ein ChoiceGroup kann die beiden Ereigniss-Händler benutzen.
- public class List extends Screen implements Choice {...}
Sie bietet fast die gleiche Möglichkeit wie ChoiceGroup, aber es gibt
einige Unterschiede. Eine Liste kann nur den Ereignis-Händler CommandListener benutzen. Eine ChoiceGroup wird auf einem Formular
angehängt, wenn mehrere Komponenten ausgewählt werden können.
In einem Display ist stets nur eine Möglichkeit ausgewählt.
✸ Mit der TextBox-Komponente aus der Klasse TextBox kann man
mehrere Zeilen Nachrichten-Text schreiben (Im Gegenteil zum TextField, das nur eine Zeile Nachrichten-Text erlaubt).
✸ Mit der Alert-Komponente kann eine Warnung angezeigt werden. Diese Warnung kann mit einem Ton oder Bild verbunden sein.
✸ Die Ticker-Komponente zeigt eine Text-Zeile. Die Sätze oder Wörter
werden nacheinander mit einer bestimmten Geschwindigkeit gezeigt.
✸ Die letzte Komponente ist die Command-Kommponente (Button in
J2SE). Mit Command kann der Benutzer mit dem MIDlet interagieren. Command ist Unterklasse von Displayable. Die Klasse Command
enhält Informationen über eine Benutzereingabe. Sie hat drei Eigenschaften: den Label, den Typ und die Priorität.
Wir werden diese am konkreten Beispiel zeigen.
Die Low-Level APIs
Diese APIs ermöglichen unmittelbar Änderungen auf dem Display. Sie erlaubt
einen direkten Zugriff auf das Display. Hier ist die Portabilität der Anwendung
nicht garantiert, deshalb muß der Programmierer selbst dafür sorgen. So spricht
man von Low-Level API. Deshalb muß der Entwickler bei der Entwicklung
einer Anwendung genau auf das Zielgerät aufpassen. Diese APIs sind sehr geeignet für die Entwicklung von Spielen aller Art. In der Low-Level API haben wir
folgende Klassen: die Klassen Canvas und Graphics, die das Zeichnen, beliebiger Grafiken auf dem Display ermöglichen. Wir wissen, dass ein MIDlet nur eine
Display-Klasse hat, aber mehrere Displayable-Klassen haben kann (Siehe Abbildung 2.5). Die beiden obigen Klassen gehören zur abstrakten Klasse Displayable.
Mit den obigen Klasssen können auch farbige Grafiken gezeichnet werden. Es gibt
in diesen APIs die Möglichkeit ganz gezielt auf die Tasten der Standardtastatur
eines Geräts zuzugreifen (z.B. keyPressed, keyReleased, keyRepeated etc.).
3.0.5
MIDlet-Beispiel
Nachdem wir einige wichtige Dinge über die Möglichkeiten von MIDP gesehen
haben, wird am konkreten Beispiel gezeigt, wie man ein komplettes MIDlet anhand obiger Elemente entwickeln kann. Wir werden die Programmstruktur eines
MIDlets kennenlernen und folgende Fragen beantworten:
1- Wie wird ein MIDlet erstellt?
2- Was sind JAR- und JAD-Dateien?
3- Wie werden die MIDlets zur Ausführung vorbereitet?
Die meisten Entwicklungsumgebungen für MIDP helfen dem Entwickler erheblich, so dass es nicht mehr nötig ist die verschiedenen Schritte der Entwicklung
eines MIDlets auf einem Dos- Fenster zu zeigen. Die Entwicklungsumgebungen
übernehmen einige Schritte wie die Verifizierung und das Einpacken der MIDlets
in JAR-Dateien selbständig.
Als Beispiel nehmen wir folgenden Programmcode, der Hello World auf dem Emulator ausgibt:
//Verweis auf MIDPspezifischen Klassen
import javax.microedition.midlet.*;
import javax.microedition.lcdui.*;
//Ein MIDlet muss immer von der Klasse MIDlet abgleitet werden.Dies ist eine
//Grundvoraussetzung zum Erstellen eines MIDlets Programms
public class HelloWorld extends MIDlet implements CommandListener
{
private Form fmMain ; //Ein Bildschirmobjekt deklarieren
private Command cmExit; //Ein Command deklarieren
public HelloWorld()
{
fmMain = new Form("Hello World"); // Das Bildschirm bekommt ein Titel
cmExit = new Command("Exit", Command.EXIT,0);//Es bekommt ein Exit-Command
fmMain.append(new StringItem(null, "Hello World! Wir werden gemeinsam" +
"lernen wie MIDP funktioniert und welche Mglichkeiten MIDP" +
"bietet"));
fmMain.addCommand(cmExit);
fmMain.setCommandListener(this);
}
/*---------------------------------------------------------------------*Die folgenden Funktionen sind die Kernfunktionen die ein MIDlet haben
*muss. Der MIDlet Aufbaut ist "ahnlich eines Applets.
*----------------------------------------------------------------------*/
//1. wird zu Beginn des Programmes ausgef"uhrt.
public void startApp()
{
Display.getDisplay(this).setCurrent(fmMain);
}
//2. Hier geht das Programm in den Ruhezustand.
//Alle Ressourcen werden vom MIDlet freigegeben
public void pauseApp() {}
//3. Wird ausgef"uhrt, wenn das MIDlet beendet wird.
public void destroyApp(boolean unconditional) {}
//Pruefen ob den Benutzer den Command cmExit gedr"uckt hat.
public void commandAction(Command c, Displayable s)
{
if(c == cmExit)
{
destroyApp(false);//gibt alle Ressourcen frei
notifyDestroyed();// Das MIDlet wird vom JAM gel"oscht
}
}
}
So haben wir es geschafft unser erstes MIDP-Programm zu schreiben. Wir
müssen jetzt noch klären, wie man es ausführt.
Verifikation des Bytecodes (Classfile)
Wir müssen zuerst die Dateien unseres Quellcodes von der virtuellen Maschine
(d.h. die JVM 1.3 oder 1.4 die auf dem Desktop PC läuft) auf Gültigkeit überprüfen lassen. Dieser Vorgang erfolgt beim Kompilieren automatisch. So wird ein
Bytecode aus dem Quellcode erzeugt. Abschließend wird auf dem Desktop eine
Pre-Verifizierung durch den Preverifier durchgeführt. Dieses Hilfsprogramm ist
im Sun Wireless Toolkit enthalten. Die Ausgabedatei ist größer als die Quelldatei. Dies liegt daran, dass bei der Preverifizierung des Bytecodes eine Prüfsumme
angehängt wird.
JAR-Datei
Eine Anwendung besteht meist aus mehreren Klassen. Es ist sinnvoll alle Klassen, die zu einer Anwendung gehören, in einem Paket zusammenzufassen. Alle
Dateien, die zur Ausführung des Programms benötigt werden, werden in eine
Datei verpackt. Diese Datei trägt die Endung JAR (Java Archive). Auch andere
Quelldateien, wie Bilder oder Icons werden mitverpackt. Der Inhalt einer JARDatei kann auch aus mehreren einzelnen MIDlets bestehen. In diesem Fall spricht
man von einer MIDlet Suite. Eine Manifest-Datei7 muß noch der JAR-Datei
hinzugefügt werden. Die Manifest-Datei muß folgende Attribute beinhalten:
✸ MIDlet-Name: Name der MIDlet Suite
7
Die Manifest-Datei beschreibt den Inhalt der JAR-Datei und muß unter dem Namen manifest.txt gespeichert werden
✸ MIDlet-Version:
✸ MIDlet-Vendor: Name des Entwicklers oder der Firma
✸ MIDlet-<n>: Nummer des MIDlets in der JAR-Datei mit den zwei wichtigten Attributen MIDlet-Name und Klassenname des MIDlets, welche die
JAM beim Aufruf des MIDlet startet.
✸ MicroEdition-Configuration: Version der Konfiguration
✸ MicroEdition-Profile: Version des Profils
JAD-Datei
Nun haben wir beinahe alles durchgeführt, was nötig ist. Nur die JAD-Datei
fehlt noch. JAD bedeutet Java Application Description. Diese Datei beinhaltet
noch einmal die Beschreibung der MIDlet-Suite, also einige Inhalte, die wir bereits aus der Manifest-Datei kennen. Sie wird von den Emulatoren und einigen
Handys benötigt. Ein JAD muß die folgenden Eigenschaften definieren:
MIDlet-Name: Name der MIDlet Suite
MIDlet-Version:
MIDlet-Vendor: Name des Entwicklers oder der Firma
MIDlet-<n>: Nummer des MIDlets im Archiv
MIDlet-Jar-URL:
MIDlet-Jar-Size:
Diese Schritte übernimmt das Wireless Toolkit und erleichtert so die Arbeit. Die
JAR- und JAD-Dateien für unser HelloWorld-MIDlet wird wie folgt im Toolkit
angezeigt:
Abbildung 3.6: Selbst erstellte JAR- und JAD-Datei beim Toolkit
Abschließend können wir unseren Bytecode vom Toolkit ausführen lassen. Als
Endergebnis haben wir dieses schöne Bild vom Emulator:
Abbildung 3.7: Die Anwendung auf den Emulator
3.0.6
Record Management System (RMS)
Als nächste Möglichkeit, bietet uns das MIDP einen guten Weg unsere Daten innerhalb einer Datenbank zu verwalten. Weil die Datenspeicherung auf den
verschiedenen kleinen Geräten unterschiedlich ist, wurde in MIDP das RMS entwickelt. Viele kleine Geräte kennen keine Datei und ihr Speicher arbeitet ohne
Dateisystem wie es auf dem Desktop PC üblich ist. Das RMS bietet eine Alternative zum Dateisystem. Das RMS verwaltet eine kleine Datenbank für die
MIDlet Suite. Jedes MIDlet bekommt innerhalb des RMS einen RecordStore8
zugewiesen. In diesem RecordStore kann das MIDlet beliebig viele Records (Einträge) anlegen, solange Speicherplatz vorhanden ist. Es gibt im Gegensatz zu
J2SE oder J2EE keine Objektserialisierung. Die Objekte werden nicht direkt im
Speicher abgelegt, sondern es ist nur die Speicherung von Byte-Streams möglich.
Der Entwickler muß immer in diesem Fall die Datei selbst in einen Byte-Streams
umwandeln.
8
Der RecordStore ist eine Kollektion von mehreren Records (Einträgen)
Record ID
1
2
3
...
Data
Array of bytes
Array of bytes
Array of bytes
...
Abbildung 3.8: Inhalt eines RecordStores
Kein Eintrag (d.h. Record) in einem RecordStore hat einen Namen, sondern er
bekommt eine Record ID9 . Ein Record besteht aus seiner ID und seinen Daten.
So besteht der nichtflüchtige Speicher (ROM) aus Sicht der MIDP-Anwendung
nur aus einer Menge von RecordStores, die aus eine Menge von Records bestehen.
Die MIDlets der selben MIDlet Suite haben direkt Zugang zu ihrem RecordStore
(falls dieser existiert). Ein RecordStore hat einen eindeutigen Namen innerhalb
eine MIDlet Suite und kann bis zu 32 Unicode-Zeichen lang sein. Verschiedene
MIDlet Suites können die gleichen Namen für RecordStores verwenden. Jeder
RecordStore hat immer zwei Werte, die beim Durchsuchen der Datenbank sehr
wichtig sind. So erhält jeder Record (Eintrag) einen Timestamp10 (d.h. einen Zeitstempel) und eine Versionsnummer. Das folgende Beispiel zeigt wie man RMS auf
einem Gerät verwenden kann.
import java.io.*;
import java.util.*;
import javax.microedition.rms.*;
public class RecordTest {
RecordStore recordStore = null;
static final String REC_STORE = "recordStoreName";
...
//Einen Record Store(RS) "offnen
public void openRS()
{
try
{
recordStore = RecordStore.openRecordStore(REC_STORE, true);
}
catch(RecordStoreException rse)
{
9
10
eindeutige Kennung mit Integer Wert innerhalb der Datenbank
Timestamp ist ein Long Integer, das die Zahl von Millisekunden seit 01.01.1970 darstellt
rse.printStackTrace();
}
}
...
//Ein neues Record(als Byte-Stream) im recordStore einf"ugen
public void addNewRecord(String record)
{
byte[ ] rec = record.getBytes();
try
{
recordStore.addRecord(rec, 0, rec.length);
}
catch(RecordStoreException rse)
{
System.out.println(rse);
}
}
...
//Ein RS muss nach der "Offnung geschlossen werden.
public void close() throws RecordStoreNotOpenException,
{
RecordStoreException
{
if (recordStore.getNumRecords() == 0)
{
String dateiName = recordStore.getName();
recordStore.closeRecordStore(); //aus der Record Store API
recordStore.deleteRecordStore(dateiName);
}
else
{
recordStore.closeRecordStore();
}
}
}
3.0.7
Scheduler
Eine andere Möglichkeit, die MIDP uns anbietet, ist die Verwaltung von mehreren Threads11 . Die API gehört zu der java.util. MIDP bietet uns folgende API:
✸ Mit der Klasse Timer kann man festlegen, wann eine Aufgabe erledigt oder
beendet wird.
✸ Die Klasse TimerTask arbeitet gemeinsam mit der Klasse Timer.
Schauen wir die 6 Methoden dieser API an:
✸ Wir können durch die Methoden void schedule(TimerTask task, long delay)
und void schedule(TimerTask task, Date Time) eine Zeitspanne in Millisekunden festlegen nach welcher ein Task einmalig ausgeführt werden soll.
✸ Wenn ein Task periodisch ausgeführt werden soll, sind zwei Fälle zu unterscheiden:
✸ Fixed-Delay: Es kann vorkommen, dass wir für die Ausführung eines Tasks 30 Sekunden fesgelegt haben. Falls der Garbage Collector
im gleichen Zeitpunkt seine Arbeit auch erledigt, braucht die TaskAusführung in gesamt mehr als 30 Sekunden bevor der nächsten Task
ausgeführt wird. Dies kann zu erheblichen Störungen führen. So gibt
es die Methoden
- void scheduleAtFixedRate(TimerTask task, long delay, long period)
und
- void schedule(TimerTask task, long delay), long period), um solch
eine Störung durch eine Verzögerung zu vermeiden.
✸ Das Fixed-Rate ermöglicht die Ausführung eines Tasks unter Berücksichtigung des Anfangs des vorigen Tasks und der Verzögerungen zwischen verschiedenen Tasks. Hierfür gibt es die Methoden
- void scheduleAtFixedRate(TimerTask task, Date firstTime,long period) und
- void schedule(TimerTask task, Date time)
Diese Timer-API ist sehr hilfreich bei der Entwicklung von Spielen.
11
Ein Thread ist ein unabhängiger sequentieller Ausführungspfad in einer Ausführungsumgebung. Es können gleichzeitig mehrere Threads in einer Umgebung ablaufen.
3.0.8
Netzwerktechnologie
Bevor ein MIDlet auf einem Gerät laufen kann, müssen wir es zuerst herunterladen.
Abbildung 3.9: Der Weg eines MIDlets vom Entwickler bis zum Endbenutzer
Der Entwickler muß zuerst das MIDlet in eine MIDlet Suite einpacken, dann auf
seinem Server veröffenlichen und von dort können die Endbenutzer sie herunterladen.
Wir werden in diesem und den nächsten Kapiteln lernen, wie die Netzwerkverbindung zwischen dem Server und dem mobilen Gerät funktioniert.
Mit mehr als hundert Klassen (ungefähr 200 KB), sind die J2SE APIs, die für
Netzwerk, Ein-/Ausgabe und die Speicherung von Daten entwickelt wurden, zu
groß für CLDC-fähige Geräte. Aufgrund der begrenzten Ressourcen bei kleinen
Geräten wurden in CLDC die obigen Klassen durch das sogenannte “Generic
Connection Framework (GCF)“ersetzt. Das GCF ist eine Menge von Klassen
und Schnittstellen, die für den Zugriff auf gespeicherte Daten und Kommunikationssysteme entwickelt worden ist. Die Konfiguration definiert einen protokollunabhängigen Netzwerkzugang, der vom Profil implementiert werden muß. So
werden beim MIDP- und PDAP-Profile spezifische Protokoll spezifiziert.
Die Basisklasse heißt Connector, die eineVerbindung mit dem Server herstellt.
Mit der Methode open fordert der Client die Übertragung einer bestimmte Datei an ihn. Die generelle Syntax für die Verbindung mit einem Server lautet:
Connector.open(“protokol://adresse:parameter “).
Hier sind die wichtigsten Protokolle, die von MIDP-Profilen unterstützt werden:
✸ Das HTTP-Protokol wird in MIDP-Profilen unterstützt. So kann man es
etwa benutzen um die Homepage der Uni-Erlangen herunterzuladen:
Connector.open(“http://www.uni-erlangen.de “);
✸ HTTPS-Protokoll. Das Problem, dass das MIDP-1.0 nur das HTTP Protokol unterstützt ist, ist im MIDP -2.0 gelöst. Die wichtigste Komponente der
neuen Version ist das Interface HttpsConnection. Das HTTPS-Protokoll garantiert eine sichere Übertragung der Daten. In MIDP-2.0 ist nicht nur die
Sicherheit der Daten bei der Übertragung geregelt. Auch die Vergabe von
Rechten an MIDlet innerhalb einer Protection Domain wird spezifiziert. So
kann man Daten sicher übertragen.
Connector.open(“https://www.amazone.de/login“);
✸ Die Verbindung durch Sockets (peer 2 peer Verbindung). Seit MIDP-2.0 ist
es auch möglich, sichere Socket-Verbindungen aufzubauen.
SocketConnection sc = (SocketConnection) Connector.open(“socket://host.com:79“);
SecureConnection sc = (SecureConnection) Connector.open(“ssl://host.com:79“);
✸ Eine Serielle-Verbindung (d.h ein serieller Port, der die serielle Übertragung
von Daten als Byte ermöglicht).
CommConnection cc = (CommConnection)Connector.open(“comm:com0;baudrate12 =19200“);
In MIDP 1.0 dürfen alle MIDlet Suites nur innerhalb eines Sandkastens laufen.
Seit MIDP 2.0, gibt es jedoch ein neues Konzept: die sogenannte “Trusted Application“ (d.h. sichere Anwendung), die im Gegensatz zum Sandkasten-Konzept
den Zugriff auf Geräte APIs erlaubt. Alle MIDlet Suites aus MIDP 1.0 werden
in MIDP 2.0 als unsicher behandelt, weil ihre JAR- und JAD-Dateien keine Sicherheitserlaubnis enthalten. Unter MIDP 2.0-fähigen Geräten, müssen diese im
Sandkasten bleiben (d.h. sie können nur auf CLDC- und MIDP- API im KVM
zugreifen). Die Public Key Infrastructure (PKI) erlaubt die Signatur von MIDlet
Suites (die JAR-Datei wird so signiert und an die JAD-Datei übergeben).
3.0.9
Over The Air (OTA)
OTA13 spezifiziert, wie MIDP-Anwendungen in einem drahtlosen Netzwerk
übertragen werden können. OTA ist ein Standard Verfahren, das vom MobiltelefonAnbieter und der Netzwerktechnologie unabhängig ist. Es beschränkt sich beim
Herunterladen von MIDlets auf nur zwei Dateien:
✸ Java Application Descriptor (JAD). Der JAD teilt dem Handy mit, wo sich
die zugehörige JAR-Datei befindet. Die URL unter der die JAR-Datei sich
befindet muß angegeben werden, so dass die Installation per OTA möglich
12
13
Baudrate ist die Geschwindigkeit des Ports und ist plattformabhängig.
http://java.sun.com/products/midp/OTAProvisioning-1.0.pdf
ist. Die folgenden Attribute müssen im JAD für OTA angegeben werden:
Attribute
Midlet-Install-Notify
MIDlet-Delete-Notify
MIDlet-DeleteConfirm
Beschreibung
Durch die angebene URL, wird dem Handy der Status
der Installation übermittelt (d.h. ob die neue Version
der MIDlet Suite schon installiert ist).
Durch die angegebene URL, wird dem Handy der Status
der Löschung einer MIDlet Suite übermittelt.
Nach der Löschung einer MIDlet Suite wird der Benutzer
benachrichtigt.
Nach der erfolgten, unerfolgten oder unterbrochenen Installation, kann der
Client seinen Status an den Server über den Verlauf der Installation senden.
Es gibt folgende Status Codes:
Status Code
900
901
902
903
904
905
906
907
908
909
910
911
912
Status Nachricht
Die Installation ist erfolgreich abgeschlossen
Das Gerät hat wenig Speicherplatz
Der Benutzer hat die Verbindung abgebrochen
Unerwartetes Übertragungsende
Die Größe der JAR-Datei ist fehlerhaft
Falsche oder fehlende Attribute
Ungültige JAD
Ungültige JAR-Datei
Die Konfiguration oder das Profil ist inkompatibel
Ungültige Anmeldung bei der Anwendung
Ungenügende Rechte für die Anwendung
Die Registrierung ist fehlgeschlagen
Die Löschung des MIDlets ist bestätigt
✸ und die JAR-Datei.
In MIDP ist es auch möglich, Cookies bei einer Verbindung zwischen Clients
und Servern einzusetzen. Die Cookies bieten eine eindeutige Identifizierung vom
Client beim Herunterladen einer MIDlet Suite. So kann man zum Beispiel mit
MIDP-fähigen Geräten online Bücher bestellen.
Beispiel:
private void connect() throws IOException {
...
try
{
//Verbindung aufbauen
http = (HttpConnection) Connector.open("http://www.amazon.de");
/*----------------------------------* Client Anforderungen
*-----------------------------------*/
//1. Methode der Anforderungen(hier die GET-Methode) senden
http.setRequestMethode(HttpConnection.GET);
//2. Header-Informationen als Cookies an Server senden
if (cookie != null)
http.setRequestProperty("Cookie", cookie);
/*------------------------------------* Server Antwort
*-------------------------------------*/
//1. Verbindungsstatus holen
if (http.getResponseCode() == HttpConnection.HTTP_OK)
{
//2. Header-Informationen vom Client holen
String tmpCookie = http.getHeaderField("Set-Cookie");
// Client-Cookie im rms speichern
if(tmpCookie != null)
{
writeRecord(tmpCookie);
// Cookie-Variable aktualisieren
cookie = tmpCookie;
}
}
}
}
Übertragung einer MIDlet Suite durch ein WAP-Gateway
MIDP-fähige Geräte können entweder durch Browser (z.B. WML14 oder i-mode)
oder durch eine Anwendung neue MIDlet Suites im Server lokalisieren und installieren. Der Server muß HTTP- und HTTPS-Protokolle unterstützen. Die obigen
14
Wireless Markup Language ist eine vereinfachte Version von Hypertext Markup Language
(HTML)
Protokolle benutzen das TCP15 -/ IP16 -Protokoll um mit dem Netz zu kommunizieren. Das WAP17 -Gateway ist beim Client installiert und hat als Aufgabe die
Konvertierung der Prokolle in beide Richtungen. Dieses Gateway (WAP-Browser)
benutzt das WSP18 um mit dem Client zu kommunizieren.
3.0.10
Sicherheitsmechanismen
Wir werden in diesem Kapitel die Neuigkeiten von MIDP2.0 betrachten.
Das folgende Bild zeigt, wie MIDlet Suites in MIDP1.0 geschützt sind.
Abbildung 3.10: MIDP und CLDC API im Sandkasten
In MIDP1.0 dürfen alle MIDlet Suites nur innerhalb eines Sandkastens laufen.
Der Sandkasten schützt alle MIDP und CLDC APIs vor ihrer Umgebung (wie
Geräte APIs).
Das MIDP2.0 hat sich nicht nur über eine sichere Übertragung der MIDlet
Suite gekümmert, sondern ermöglicht auch durch das Signieren von MIDlets die
Authentizität eines MIDlets zu überprüfen. So wurde ein neues Konzept entwickelt: die Trusted Application (TA). Die MIDP-Anwendungen können im
Gegensatz zum Sandkasten-Konzept auf die Geräte-APIs zugreifen, wenn sie als
sicher authentifiziert sind. Diese Geräte-APIs bilden die sogenannte Protection
Domain. Wenn das MIDlet als sicher erkannt ist, bekommt es die Erlaubnis auf
die Protection Domain zuzugreifen. Es gibt auch MIDlet Suites die unsicher sind,
diese werden Untrusted MIDlet Suites genannt. Sie sind unsicher, weil die Herkunft und die Integrität der JAR-Datei nicht sicher sind. Eine unsichere MIDlet
Suite kann nur im Sandkasten laufen (z.B. alle MIDlet Suites aus MIDP1.0 werden in MIDP2.0 als “untrusted“ bezeichnet, weil ihre JAR- und JAD-Datei keine
15
Transfer Control Protocol
Internet Protocol
17
Wireless Application Protocol
18
Wireless Session Protocol
16
Sicherheitserlaubnis haben.)
Jede sichere Umgebung definiert eigene Rechte, die sie einer MIDlet Suite geben
kann.
Kapitel 4
PDAP, FP und die optionalen
Profile
Es gibt in J2ME nicht nur das MIDP, sondern auch noch einige Profile und
optionale Profile, die wir in diesem Kapitel behandeln werden.
4.1
Personal Digital Assistent Profil (PDAP)
Das PDA Profil ist noch im Entwicklungsstadium und ist auf CLDC basiert.
Ziel dieser API ist es, PDAs zu unterstützen. Ein Gerät, das dieses Profil unterstützt, muß:
✸ mindestens 512KB Speicher (ROM und RAM) für die JVM und J2ME APIs
haben und darf nicht mehr als 16MB haben.
✸ beschränkten Stromverbrauch haben und batteriebetrieben sein.
✸ ein Display mit mindestens 20000 Pixels Auflösung haben.
✸ einen Stift als Eingabegerät haben.
4.2
Foundation Profil (FP)
Als letzte J2ME-Profil, stellen wir das FP [7] vor. Dieses Profil gehört zu der
CDC-Konfiguration. Ein Gerät (z.B. Set-Top Box), das dieses Profil unterstützen
will, muß die JVM und die J2SE APIs vollständig implementieren. Um dieses
Profil zu unterstützen, muß ein Gerät folgende Anforderungen erfüllen:
34
KAPITEL 4. PDAP, FP UND DIE OPTIONALEN PROFILE
35
✸ mindestens 1024KB ROM.
✸ mindestens 512KB RAM.
✸ eine Netzwerkverbindung.
✸ es wird keine Benutzeroberfläche benötigt; falls eine solche doch gewünscht
ist, kann sie von einem optionalen Paket geholt werden.
4.3
Die wichtigsten optionalen Pakete
Der Java Community Process (JCP) [2] listet in einer Tabelle alle Spezifikationen und Bibliotheken, die für J2ME bislang existieren oder gerade entstehen
auf. Wir betrachten nur einige, die wir als sehr wichtig erachten und beschreiben
sie ganz kurz, damit man sehen kann welche Möglichkeiten J2ME noch bietet:
✸ Bluetooth API für J2ME.
✸ Wireless Messaging API.
✸ Mobile Media API.
✸ Location API for J2ME.
4.3.1
Bluetooth API
Das Bluetooth API [8], ist eine Menge von APIs, die die kabellose Verbindung
von mehreren Geräten auf eine Distanz von bis zu 10m ermöglicht (z.B. kommunizieren Handys, PDA und Laptop miteinander). So wurde diese API entwickelt
als Standard für MIDP-fähige Geräte entwickelt und markiert so einen wichtigen
Trend auf dem heutigen Markt. Wie wir bereits wissen, schützt jede Standardisierung eines Pakets die Konfiguration und Profile vor proprietären Lösungen
und erleichtert die Arbeit des Entwicklers bei der Portierung.
Diese APIs unterstützen folgende Bluetooth Protokolle:
✸ RFCOM für die einfache Verbindung zwischen Geräten.
✸ OBEX für die Synchronisation und Datenübertragung.
✸ Service Discovery für die Suche von Geräten innerhalb von 10m und die
Ermittlung der Dienste, die sie anbieten.
36
Die Geräte, die Bluetooth unterstützen wollen, müssen mindestens 512KB
Speicher (ROM/Flash und RAM) haben, Bluetooth Netzverbindung haben und
die CLDC und MIDP implementieren. Die Bluetooth Bibliotheken basieren auf
das Generic Connection Framework von CLDC.
4.3.2
Wireless Messaging API (WMA)
Wir haben gerade gesehen, dass die Bluetooth APIs den Zugriff auf Ressourcen bis eine Distanz von 10m erlauben. Was passiert, wenn die Ressourcen weiter als 10m entfernt sind? Wir müssen in diesem Fall WMA [11] benutzen, um
auf die entfernten Ressourcen zuzugreifen. Mit deren Hilfe wird der Zugriff auf
Short Message Service (SMS)1 und andere Ressourcen wie Unstructured Supplementary Service (USSD)2 und Cell Broadcast (CBS)3 vereinheitlicht. Diese APIs
können in jedem J2ME-Profile genutzt werden. Im Generic Connection Framework (GCF) wird das User Datagramm Protokol (UDP) verwendet und jede
Nachricht enthält einen Adressenteil und Nutzinformationsteil. Es wird für jede Nachricht folgendes Paket genutzt: javax.wireless.messaging. Alle Nachrichten
müssen die Schnittstelle Message implementieren. Um Nachrichten entfernt zu
senden oder zu empfangen, muß das GCF genutzt werden. Die zentrale Klasse für diese APIs ist MessageConnection, die das Senden und Empfangen von
Nachrichten sowohl im Client Mode als auch im Server Mode ermöglicht. Das
folgende Beispiel zeigt wie die Nachricht an einen entfernten Client gesendet oder
empfangen wird.
/*------------------------------------------------------------* Client sendet "Hello World" zu einem anderen Client als eine
* normale SMS-Nachricht.
*------------------------------------------------------------/
try
{
String adr = "sms://+491797876880";
MessageConnection conn =
(MessageConnection) Connector.open(adr);
TextMessage msg =
(TextMessage) conn.newMessage(MessageConnection.TEXT_MESSAGE);
msg.setPaxload("Hello World");
conn.send(msg);
1
Das SMS ist eine Anwendung, die das Senden und Empfangen von Daten über das Netz
ermöglicht.
2
Das USSD ist zuständig für den Datenaustausch
3
Das CBS ermöglicht das Funken von Daten
37
}
catch(Exception);
/*--------------------------------------------------------* Im Port 5432 wartet der Server auf Nachrichten und
* antwortet entsprechend.
*--------------------------------------------------------/
try {
String addr = sms://:5432;
MessageConnection conn =
(MessageConnection) Connector.open(addr);
Message msg = null;
while (someExitCondition){
//Warte auf ankommende Nachrichten
msg = conn.receive();
//Empfang eine Nachricht
if (msg instanceof TextMessage) {
TextMessage tmsg = (TextMessage)msg;
String receivedText = tmsg.getPayloadText();
//Antwortet mit dem gleichen Text
tmsg.setPayloadText(Received: + receivedText);
conn.send(tmsg);
}
catch (Exception e) { ... }
}
4.3.3
Mobile Media API (MMAPI)
Das MMAPI [10] stellt eine Schnittstelle zur Nutzung von Ton- und Multimediafähigkeiten von J2ME-Geräten dar. Diese APIs ermöglichen den Zugriff auf die
Funktionen wie das Aufnehmen und Abspielen von Audio- und Video-Daten. Als
Voraussetzung für die Benutzung diese APIs, muß das Gerät die CLDC implementieren. Alle Klassen befinden sich im Paket javax.microedition.media.*.
4.3.4
Location API
Das Location API [9] ist eine Menge von APIs, die Informationen über den Ort
eines Geräts ermöglichen. Diese APIs können nur für MIDP und PDAP angewendet werden und müssen die CLDC implementieren. Um diese APIs zu verwenden,
38
muß das Gerät etwas Speicherplatz (max. 20KB ROM und 2KB RAM) für diese
APIs zur Verfügung stellen. Im Paket javax.microedition.location.* gibt es viele
Klassen, die die Ortung von Geräte ermöglichen.
4.4
Werkzeuge zur Arbeit mit J2ME
J2ME bietet Möglichkeiten für die Entwicklung von Anwendungen für kleine
Geräte. Es gibt viele kostenlose Entwicklungsumgebungen, die die Entwicklung
erleichtern. Viele J2ME-Geräte Hersteller (z.B. Siemens, Nokia, etc.) bieten auch
ihre eigenen Entwicklungsumgebungen an.
Tool
J2ME Wireless Toolkit
Hersteller
Sun Microsystems
PalmOS Emulator
Palm, Inc
Nokia J2ME Tools
Siemens
Mobility
Toolkit
RIM Blackberry JDE
Nokia
Siemens
Motorola iDEN Tools
Motorola
WHITEboard
less Java SDk
Zucotto Wireless
Wire-
Research in Motion
MicroEmulator
Yospace Motorola Accompli 008 Emulator
Forte for Java
Bartek Teodorczyk
Yospace
jBuilder MobileSet
Borland
xKVM
Stefan Haustein und
Michael Kroll
Sun
39
Anmerkung
Es gibt ein Plug-in für das kostenlose
Sun Forte for Java Community Edition
und Borland jBuilder MobileSet.
Es wird mit der PalmOS Version vom
MIDP verwendet.
Für J2ME-konforme Nokia Endgeräte.
Für J2ME-konforme Siemens Endgeräte
Für J2ME-konforme RIM Endgeräte.
Die Entwicklungsumgebung beinhaltet
eine eigene virtuelle Maschine.
Für J2ME-konform Motorola Endgeräte Die Entwicklungsumgebung
beinhaltet eine eigene virtuelle Maschine.
Die Entwicklungsumgebung beinhaltet
eine eigene virtuelle Maschine. Sehr geeignet für J2ME- Entwickler.
Ist ein Emlator, der auf Applets basiert.
Ist ein Online-Emulator.
Hierin sind man viele Tools von privaten Anbitern integriert.
Es gibt eine spezielle Nokia Edition für
J2ME-konforme Nokia Endgeräte.
virtuelle Maschine, die 8-Bit Farben für
PalmOS implementiert.
Abbildung 4.1: J2ME Tools
40
Wir werden einige dieser Entwicklungsumgebungen kennenlernen.
4.4.1
J2ME Wireless Toolkit
Dieses Toolkit arbeitet mit J2ME/MIDP und hat mehrere Emulatoren. Es gibt
Wireless Toolkit für Windows und Unix/Linux Plattformen kostenlos zum Download. Mit KToolBar ist es möglich die Benutzung des Speichers zu beobachten.
4.4.2
JBuilder 7 Enterprise with MobileSet 3
Hier hat man drei Editionen: Personal, Standart (SE) und Enterprise, die
plattformunabhängig sind. Dieses MobileSet läuft nur auf Windows Plattformen
und ist kostenlos.
4.4.3
Sun One Studio 4 Mobile Edition
Es gibt drei Editionen: Community, Mobile, and Enterprise. Community und
Mobile sind kostenlose bei Sun zum Download.
4.4.4
Metrowerks CodeWarrior Wireless Studio
Es gibt keine kostenlose Evaluierungsversion. Das CodeWarrior Studio 7 ist
nur für Windows.
4.4.5
Whiteboard SDK
Für die Programmierung von J2ME wurde von der Firma Zucotto4 die Entwicklungsumgebumg Whiteboard entwickelt. Sie ist für die Entwicklung von J2ME
Programmen mit CLDC und MIDP gedacht. Es gibt einen Nokia-Handy-Emulator,
und es gibt auch ein mitgeliefertes Emulator-Tool, mit dem sich eigene Emulatoren erstellen lassen. Diese Emulatoren sind nicht mit den anderen Entwicklungsumgebungen kompatibel. Whiteboard SDK ist nicht für Palm-Programmierung
geeignet und unterstütz nur J2SDK 1.3, nicht 1.4, außerdem gibt es nur eine
Windows Version.
4
http://www.zucotto.com
4.5
41
Eingebette Systeme, die die J2ME verwenden
Unter der URL http://wireless.java.sun.com/device, lässt sich nachlesen welche Geräte J2ME unterstützen. An der Menge der Einträge lässt sich die Wichtigkeit und schnelle technologische Entwicklung seit der ersten Spezifikation 1999
erkennen.
Kapitel 5
Ausblick
In diesem Kapitel wird der Unterschied zwischen J2ME und J2SE in Bezug
auf den Speicherplatz vorgestellt. Danach werden die Probleme und Grenzen von
J2ME betrachtet. Abschließend wird ein Ausblick für J2ME gegeben.
5.1
Vergleich von J2ME mit J2SE
Ich habe den Algorithmus Quicksort genutzt um J2ME mit J2SE zu vergleichen. Der Quellcode befindet sich auf der beigefügten Diskette. Bei dem Test
kann man genau beobachten, dass mit MIDP eine Array von mehr als 120 000
Elementen nicht möglich ist. Diese Arrays sind zu groß für kleine Geräte. Eine
weiterer, eigentlich offensichtlicher, aber keinesfalls zu vernachlässigender Unterschied zeigt sich selbstverständlich in der Rechengeschwindigkeit: Der J2ME lief
auf den jeweiligen Emulatoren langsamer als die normale J2SE auf Desktop PC.
Beim MIDP startet die Ausführung der Anwendung nicht in der Methode main,
sondern in startApp.
5.2
Probleme und Grenzen vom J2ME
Wir haben gelernt, dass MIDP Bytecode noch vor der Ausführung verifiziert
wird. Die Verifizierung und der Garbage Collector verlangsamen die Ausführung
der Anwendung. J2ME ist eine neue Technologie und existiert seit Juni 1999.
Sie ist noch in der Entwicklungsphase. Wie wir gesehen haben, gibt es noch
Anforderungen (Java Specification Request), wie z.B. PDA Profil, die noch in
der Bearbeitung sind. Obwohl es obige Probleme gibt, hat die J2ME Technologie
42
KAPITEL 5. AUSBLICK
43
Zukunft. Wir müssen noch warten bis viele Geräte auf den Markt sind, die die
verschiedenen Profile von J2ME unterstützen, um eine genaue Aussagen treffen zu
können. MIDP2.0 hat einige Probleme von MIDP1.0 beseitigt, insbesonders die
restrikten Sicherheitsmechanismen von MIDP1.0. Die Veröffenlichung einer neuen
Version einer Konfiguration oder eines Profils, wird J2ME weiter verbessern. Was
wir beim J2SE erlebt haben, wird sicherlich auch hier passieren. Als Nachteil kann
es zu riesigen Bibliotheken kommen, die wie wir es bereits vor dem J2SE kennen,
die den Speicherplatzbedarf enorm ansteigen lassen.
5.3
Alternativen zur Verwendung von J2ME
MIDP bietet wie in der Arbeit dargestellt eine komfortable Plattform für die
Entwicklung von Java-Programmen für Handys über eine Standardisierung. Aber
es gibt noch einen zweiten Weg, nämlich eine Anwendung auf jede Architektur
zu portieren. Wir werden in diesem Kapitel diesen zweiten Weg vorstellen.
Wir wissen aus der Desktop-Welt, dass wenn ein Betriebssystem (z.B. Windows)
ein Monopol hat, die Entwickler Anwendungen nur für ein Zielsystem schreiben
und sich keine Gedanken über eine Portierung auf andere Betriebssysteme machen
(z.B. Das Whiteboard von Zuccoto gibt es nur für Windows). Eine Version genügt,
um einen großen Benutzerkreis anzusprechen. Als mögliche Betriebssysteme sehen
wir:
✸ Das PalmOS hat ein Standard Development Kit (SDK), das frei verfügbar
ist. Es gibt auch den PalmOS Emulator POSE für den Test der Anwendung, der auch frei verfügbar ist. Es wird im Palm meist in C oder C++
programmiert.
✸ Das PocketPC von Microsoft. Es gibt aufgrund der marktbeherrschenden
Position von Microsoft nur die PocketPC SDK als Entwicklungsumgebung.
Hier ist, wie oben gesagt, eine proprietäre Lösung und nur eine plattformgebundene Programmentwicklung möglich, wie bei jedem Monopolisten.
✸ Embedded Linux.
Wenn wir den Markt beobachten, liegen J2ME-fähige Handys im Trend und
immer neue Geräte kommen auf den Markt, die J2ME-fähig sind. Heute gibt
es MIDP für das PalmOS Betriebssystem und morgen wird nach einem langen
Streit auch J2ME für das PocketPC Betriebssystem eingeführt. Was heute auf
dem Desktop PC mit J2SE und J2EE passiert, wird sicherlich auch auf dem Markt
der kleinen Geräte genauso passieren. Mit immer mehr MIDP-fähigen Geräten
auf dem Markt hat J2ME eine breite Zukunft.
Literaturverzeichnis
[1] John W. Muchow: Core J2ME Technology & MIDP
[2] Die gesamte JSR für J2ME: http://www.jcp.org/en/jsr/tech?listByType=Platform
[3] J2ME Spezifikationen, Emulatoren, SDK, und Tools zum herunterladen,
Source Code vom J2ME Archive: http://www.billday.com/j2me/index.html
[4] J2ME
Mobile
Information
Device
Profile
Spezifikation:
http://wwws.sun.com/software/communitysource/midp/download.html
http://jcp.org/aboutJava/communityprocess/final/jsr118/index.html
[5] J2ME
Connected
Device
Configuration
Spezifikation:
[6] J2ME Connected, Limited Device
http://www.jcp.org/en/jsr/detail?id=139
Configuration
Spezifikation:
[7] J2ME Foundation Profile für Endgeräte, die mit CDC arbeiten:
[8] Bluetooth API: http://www.jcp.org/en/jsr/detail?id=82
[9] Location API: http://www.jcp.org/en/jsr/detail?id=179
[10] Mobile Media API: http://www.jcp.org/en/jsr/detail?id=135
[11] Wireless Messaging API: http://www.jcp.org/en/jsr/detail?id=120
[12] Das PDA Profil: http://www.jcp.org/en/jsr/detail?id=075
[13] Microedition FAQ: http://java.sun.com/j2me/faq.html
[14] Die J2ME IDE: http://www.javaworld.com/javaworld/jw-10-2002/jw-1018wireless.html
44
Index
Alert, 18
API, 2, 11, 16
AWT, 16
Item, 17
ItemStateListener, 17
J2EE, 2
J2ME, 1–3, 5, 6, 39, 42, 43
J2SE, 2, 6, 7, 16, 42
JAD, 22, 29
JAM, 15
JAR, 21, 29, 32
Java Community Process, 35
Java-Bytecode, 2
Java-Compiler, 2
JBuilder, 39
just-in-time compiler, 6
Bluetooth, 35
Bytecode, 7, 21, 23, 42
Bytecode Verifikation, 2
Bytecode-Verifizierung, 7
Canvas, 19
CBS, 36
CDC, 5
ChoiceGroup, 18
Class-Verifier, 7
CLDC, 5, 6, 11, 34, 37
CodeWarrior, 39
Command, 18
commandAction, 17
CommandListener, 17
Container, 17
Konfiguration, 4, 5
KVM, 6
List, 18
Location, 37
MIDlet, 13–16, 18, 24, 28
MIDlet Suite, 21, 24, 25, 29, 32
MIDP, 5, 11, 12, 16, 17, 19, 24, 27,
30, 42, 43
MMAPI, 37
DateField, 17
Emulator, 23
Fixed-Delay, 27
Fixed-Rate, 27
Form, 17
Foundation Profil, 34
OTA, 29
PalmOS, 40, 43
PDAP, 34, 37
PI, 19
PKI, 29
PocketPC, 43
Preverifier, 21
Profil, 4, 8
Protection Domain, 29, 32
Gauge, 17
GCF, 36
Graphics, 19
HTML, 31
HTTP, 28, 31
HTTPS, 28, 31
ImageItem, 18
45
INDEX
Record ID, 25
RecordStore, 24, 25
RMS, 24
Sandkasten, 29, 32
Scheduler, 27
SMS, 12, 36
StringItem, 18
Sun One Studio, 39
TextBox, 18
TextField, 18
Thread, 27
Ticker, 18
Timer, 27
TimerTask, 27
Timestamp, 25
Trusted Application, 29, 32
UDP, 36
Untrusted, 32
USSD, 36
WAP, 32
Whiteboard SDK, 41
Wireless Toolkit, 22, 39, 40
WMA, 36
WML, 31
WSP, 32
46

Möglichkeiten und Grenzen von J2ME

Transcription

Similar documents

Caplio RX

Spionage via Webcam: Welchen Schutz bieten Personal Firewalls

GraR - Fachhochschule Salzburg

Willkommen - DJH Sachsen

Juni 2006 - Stadtverwaltung Tanna

Dokument_35.

best ski resort in switzerland - Saas-Fee

klicken für eine Leseprobe

Entwurf und prototypische Realisierung von Maßnahmen

Hinweise zum Arbeiten mit UNIX