Programmierung mit MIDP 1.0 und MIDP 2.0 Trainingsunterlage Java 2 Micro Edition Programmierung mit MIDP 1.0 und MIDP 2.0 © S. Rupp, Stuttgart 5/2003

Programmierung mit Java 1 : Übersicht über Architektur und Releases 2 : Java 2 Micro Edition 3 : Connected Limited Device Configuration 4 : Mobile Information Device Profile 5 : Wireless Toolkit 6 : Ausblick - MIDP 2.0 und weiter © S. Rupp, Stuttgart 5/2003

Java Architektur und Releases 1.0 : Einführung 1.1 : Laufzeitumgebung 1.2 : Spezifikationen für Anwendungen (API) 1.3 : Releases Notes: © S. Rupp, Stuttgart 5/2003

Was ist Java? Eine objektorientierte Sprache. Ein kommunaler Prozess zur Spezifikation objektorientierter Modelle, zur Entwicklung von Konzepten und technologischer Lösungen für alle für die Entwicklung von Software interessanten Bereiche (der Java-Baukasten). Ein Baukasten für Entwickler (Spezifikationen für Application Program Interfaces, Bibliotheken, Quelltexte, Beispiele, Referenzimplementierungen) Eine Software-Umgebung für portable Anwendungen (virtuelle Maschine, ladbarere Bytecode, Absicherung der Systeme durch Beschränkungen der Rechte der Anwendungen) © S. Rupp, Stuttgart 5/2003

Java Applications and Applets Die Java Architektur Java Applications and Applets Java API + Libraries Java Plattform Java Virtual Machine System Plattform Operating Sytem Hardware Drivers Hardware

Was ist eine Programmierschnittstelle (API)? Spezifikation von Objektklassen, Methoden und Attributen Nach Anwendungspaketen geordnet, wie z.B. graphische Benutzerschnittstellen (z.B. Swing) Kommunikation über Netze Verwendung von Datenbanken (z.B. JDBC) verteilte Anwendungen (z.B. RMI, JINI) Verarbeitung von Medien (z.B. Java Media Framework) Intranet, Internet, Software-Integration in Unternehmen, mobile Endgeräte, TV, Chip-Karten, ... © S. Rupp, Stuttgart 5/2003

API-Spezifikation als HTML-Framesets (1)

API-Spezifikation als HTML-Framesets (2)

Java Community Process Offene Organisation von Java Entwicklern und Lizenznehmnern weltweit Ziel: Entwicklung und Weiterentwicklung technischer Spezifikationen, Referenzimplementierungen, sowie Tools und Testspezifikationen für die Kompatibiltität von Java Technologien Von SUN Microsystems 1995 initiiert und inzwischen eine eigenständige Organisation, siehe www.jcp.org Hauptprodukt für Entwickler: Java Specification Requests (JSRs), z.B. JSR-82 für künftige Bluetooth APIs oder JSR-118 über die Programmierung mobiler Telefone (MIDP, mobile independent device profile) © S. Rupp, Stuttgart 5/2003

Was benötigt man für die Anwendungsentwicklung? Das geeignete Java Release: für Desktop Anwendungen die Standard Edition für Mobiltelefone und Consumer-Elektronik die Micro Edition für Anwendungen in Unternehmen die Enterprise Edition Laufzeitumgebung (Virtual Machine, Compiler, Bibliotheken, Referenzimplementierung, ...) Entwicklungs-Toolkit (Integrierte Tools, Emulatoren, gerätespezifische Tools) Dokumentation (API-Spezifikationen, ...) © S. Rupp, Stuttgart 5/2003

Java Programming Language Java Releases Workstation Network Computer Communicator Server Mobile phone PC, Notebook Set-Top Box PDA Java 2 Enterprise Edition Point of Sales Screenphone Java 2 Standards Edition Smartcard CDC CLDC Java 2 Micro Edition Java Programming Language Hot Spot JVM KVM Card VM Physical memory: Processor: 10 MB 64 Bit 1 MB 32 Bit 512 kB 32 Bit 32 kB 16 Bit 8 Bit

Was ist die Standard Edition (J2SE)? Zweck der Java Releases ist die Ordnung der mit der Zeit stark gewachsenen APIs nach Anwendungsgruppen. Die Java Standard Edition beinhaltet alles, was zur Entwickung von Client-Anwendungen benötigt wird. Zielsysteme für J2SE sind vorwiegend Desktop-Systeme bzw. mobile Computer und Netzcomputer. J2SE entspricht weitgehend dem Funktionsumfang des Development Kits JDK 1.2 (ca. 1500 Klassen in 1999) und enthält ausserdem die Laufzeitumgebung (JRE). Inzwischen stehen mit JSE 1.4 zusätzliche Funktionen bereit, wie z.B. die HotSpot Virtual Machine und APIs zur Verarbeitung von XML Dokumenten. © S. Rupp, Stuttgart 5/2003

Was ist die Enterprise Edition (J2EE)? Ein Konzept zur Realisierung und Integration von Anwendungen im Web und in Unternehmen. Alle dazu benötigten Komponenten, die über den Bedarf der Standard Edition hinausgehen, sind in der Enterprise Edition enthalten. Die Architektur unterscheidet folgende Schichten: Client für Präsentation und Benutzerschnittstellen z.B. in einem Browser (Applet Container), bzw. in einer Client-Anwendung (Application Client Container) Server im Web bzw. im Unternehmen (Web-Container bzw. Enterprise Java Beans Container) Datenverwaltung (Datenbank) © S. Rupp, Stuttgart 5/2003

J2EE Architektur und Komponenten Applet Container HTTP Applet Web Container EJB Container JSP Page J2SE Enterprise Bean HTTP JMS JNDI JTA J-Mail JAF RMI JDBC Servlet JMS JNDI JTA J-Mail JAF RMI JDBC Client Application Container Database Client Application JMS JNDI RMI JDBC J2SE J2SE RMI-IIOP J2SE © S. Rupp, Stuttgart 5/2003

Erläuterungen zu J2EE (1) J2EE beinhaltet die J2SE und bietet weitere Funkionen. Zu den zusätzlichen Funktionen gehören: Servlets (Server-seitige Anwendungen für Web-Server) und die Server-seitige Unterstützung von Java Server Pages (zur Erzeugung dynamischer Web-Seiten) Server-Applikationen mit Hilfe von Enterprise Java Beans. Der Anwendungsentwickler konzentriert sich dabei auf seine Anwendung. Infrastrukturaufgaben (wie z.B. die Behandlung von Transaktionen und die Behandlung persistenter Daten) übernimmt der EJB-Container. CORBA und Transaktionsdienste © S. Rupp, Stuttgart 5/2003

Erläuterungen zu J2EE (2) Zur J2EE gehören: die Spezifikationen die Referenzimplementierung von SUN Microsystems die Test-Suite zur Kompatibilität von J2EE Technologien Design Richtlinien für Anwendungen Server für die J2EE Technologie werden von Technologiepartnern realisiert und angeboten. Die Funktion der in der Abbildung aufgeführten Komponenten werden in einem separaten Teil des Trainings erläutert. © S. Rupp, Stuttgart 5/2003

Programmierung mit Java 1 : Übersicht über Architektur und Releases 2 : Java 2 Micro Edition 3 : Connected Limited Device Configuration 4 : Mobile Information Device Profile 5 : Wireless Toolkit 6 : Ausblick MIDP 2.0 und weiter © S. Rupp, Stuttgart 5/2003

2.3 : Funktionsumfang von CDC und CLDC 2.4 : MIDP 1.0 Java 2 Mirco Edition 2.0 : Übersicht 2.1 : Zielsysteme 2.2 : Aufbau von J2ME 2.3 : Funktionsumfang von CDC und CLDC 2.4 : MIDP 1.0 Notes: © S. Rupp, Stuttgart 5/2003

Was ist die Java Micro Edition (J2ME)? Eine kleine virtuelle Maschine KVM (benötigt nur ca. 100 kBytes Arbeitsspeicher) Prä-verifizierter Bytecode zur Entlastung des Zielsystems Konfigurationen (Systemeigenschaften): CDC (Connected Device Profile): 32/64 Bit-Prozessor, 2MB CLDC (Connected Limited Device): 16 Bit Prozessor, 256 kB Profile (Gebrauchsmuster für Anwendungen): MIDP (Mobile Interconnected Device Profile) für CLDC: z.B. Mobiltelefon mit kleinem Display und Telefon-Tastatur Wireless Toolkit für die Entwickung und Tests von MIDlets © S. Rupp, Stuttgart 5/2003

Zielsysteme für J2ME (1)

Zielsysteme für J2ME (2) Mobiltelefone Digitale Set-Top-Boxen (MHP) derzeit basierend auf CLDC und MIDP 1.0 im Handel für Spiele und Web-Clients Digitale Set-Top-Boxen (MHP) unidirektionale Netzanbindung Java Media Framework CDC nicht wörtlich umgesetzt Embedded Systems erste Bluetooth basierende Implementierungen nach dem JSR-82 verfügbar © S. Rupp, Stuttgart 5/2003

Der Aufbau von J2ME (1) Mobiltelefone Midlet Foundation Profile MIDP CDC CLDC JVM KVM Java 2 Micro Edition

Der Aufbau von J2ME (2) CLDC verwendet eine kleinere VM (KVM) Speicherbedarf min. 160 kBytes (96 kB für KVM, 32 kB Heap, 32 kB CLDC Klassenbibliotheken) MIDP ergänzt den Funktionsumfang des CLDC Speicherbedarf für MIDP 1.0 zusätzlich min. 168 kB (128 kB für MIDP Klassenbibliotheken, 32 kB Heap, 8kB für persistente Daten) gleicher Compiler wie bei J2SE, jedoch andere Basis-bibliotheken gegenüber der J2SE fängt J2ME wiederum klein an (als erweitertes Subset des J2SE) © S. Rupp, Stuttgart 5/2003

Funktionsumfang von J2ME J2SE (Standard Edition) J2ME CDC J2ME CLDC Funktionen ausserhalb des java.* Namens-raumes CDC: Connected Device Configuration CLDC: Connected Limited Device Configuration

Einschränkungen beim CLDC gegenüber J2SE (1) keine Floating Point Datentypen und Operationen keine Native Interfaces (zu anderen Programmen) keine Beeinflussung des Class Loaders möglich keine Reflexion (Sichtbarkeit von System-eigenschaften zur Laufzeit wie Objekte, Threads etc), dadurch auch keine Remote Method Invocation eingeschränkte Unterprozesse (keine Tread-Gruppen und Demon Threads) © S. Rupp, Stuttgart 5/2003

Einschränkungen beim CLDC gegenüber J2SE (2) keine finalisation() Methode und keine schwachen Referenzen (Objekte, die der Garbage Collector bei Bedarf abräumen darf) Verlagerung des Aufwandes für die Klassen-verifizierung auf das Entwicklungssystem als Prä-verifizierung. Vereinfachte Verifizierung auf dem Zielsystem auf Basis von Attributen im Bytecode. © S. Rupp, Stuttgart 5/2003

Die Komponenten des MIDP 1.0 MIDP User Interface: Benutzerführung an Bildschirm und Tastatur MIDP Record Management System: Haltung persistenter Daten MIDP Network Libraries: Herstellung von Verbindungen über das Netz basierend auf dem CLDC Generic Connection Framework Einige systemspezifische Funktionen wie z.B. die Verwendung von Timern © S. Rupp, Stuttgart 5/2003

Programmierung mit Java 1 : Übersicht über Architektur und Releases 2 : Java 2 Micro Edition 3 : Connected Limited Device Configuration 4 : Mobile Information Device Profile 5 : Wireless Toolkit 6 : Ausblick - MIDP 2.0 und weiter © S. Rupp, Stuttgart 5/2003

Connected Limited Device Configuration 3.0 : Übersicht 3.1 : Sicherheitskonzept 3.2 : Das Generic Connection Framework Notes: © S. Rupp, Stuttgart 5/2003

Connected Limited Device Configuration Midlet Propr. System- spezifische Anwendungen Propr. MIDP CLDC KVM Betriebssystem Mobiltelefon

Die Komponenten des CLDC Verwendet eine erweiterte Untermenge des J2SE: java.io: Eingabe und Ausgabe durch Datenströme java.lang: Basisklassen java.util: Utilities für Zeit, Kalender usw. neues Paket javax.microedition.io für Verbindungen mit der Aussenwelt Dadurch völlig neues und vereinfachtes Konzept für unterschiedliche Typen von Verbindungen zur Kommunikation: das Generic Connection Framework Laden fremder Anwendungen erfordert verschärftes Sicherheitskonzept gegenüber J2SE. © S. Rupp, Stuttgart 5/2003

Sicherheitskonzept (1) vorgegebener Namensraum Verifizierung des Bytecodes Virtuelle Maschine Gesicherte Kommunikations-schnittstellen Voneinander isolierte Daten und Anwendungen © S. Rupp, Stuttgart 5/2003

Sicherheitskonzept (2) Virtuelle Maschine: Schutz des Systems vor unberechtigtem Zugriff und Laufzeitfehlern Verifizierung des Bytecodes: gültige Datentypen, Instruktionen und gültiger Adressraum Vorgegebener Namensraum durch fixierten Class-Loader und vorgegebene Bibliotheken Zugriff auf Kommunikationsschnittstellen nur mit Einverständnis des Benutzers (Dialog) Midlets (Midlet-Suites) laufen in einer Anwendungs-umgebung und können nicht miteinander kommuni-zieren oder auf Daten anderer Midlets zugreifen. © S. Rupp, Stuttgart 5/2003

Generic Connection Framework (1) Unabhängig von ihrem Typ werden Verbindungen generell nach folgendem Schema hergestellt: Connector.open("<Protokoll>:<Adresse>;<Parameter>"); Konkrete Beispiele hierfür wären: Connector.open(“http://www.netads.de"); HTTP-Verbindung Connector.open("socket://162.234.100.200:8090"); Socket-Verbindung Connector.open("comm:0;baudrate=9600"); Serieller Port Connector.open("file:/hiScore.dat"); Datei © S. Rupp, Stuttgart 5/2003

Klassenhierarchie des CLDC GCF Connection StreamConnectionNotifier InputConnection StreamConnection OutputConnection ContentConnection DatagramConnection

Generic Connection Framework (2) CLDC liefert mit dem Interface Connection und seiner Basisklasse Connector den Rahmen. Unterstützte Protokolle werden im jeweiligen Profil spezifiziert, z.B. HTTP bei MIDP 1.0. Zuordung eines Kommunikationsprotokolles erfolgt dynamisch zur Laufzeit. Abstraktion unterschiedlicher Verbindungsarten: eingehende Verbindung bzw. abgehende Verbindung mit kontinuierlichem Datenstrom, Quelle bzw. Senke der Daten in einer Datei, Datagramm. © S. Rupp, Stuttgart 5/2003

Generic Connection Framework (3) Aus der Klassenhierarchie des GCF: InputConnection: serieller Eingang OutputConnection: serieller Ausgang DatagramConnection: einzelnes Paket Eingehende bzw. abgehende Datenströme: StreamConnection: kontinuierlicher Datenstrom ContentConnection: Datei als Quelle oder Senke Benachrichtigung für Server bei eingehendem Verkehr: StreamConnectionNotifier © S. Rupp, Stuttgart 5/2003

Programmierung mit Java 1 : Übersicht über Architektur und Releases 2 : Java 2 Micro Edition 3 : Connected Limited Device Configuration 4 : Mobile Information Device Profile 5 : Wireless Toolkit 6 : Ausblick - MIDP 2.0 und weiter © S. Rupp, Stuttgart 5/2003

Mobile Information Device Profile 4.0 : Einführung 4.2 : Midlets laden und starten 4.3 : Produktionsprozess für Midlets 4.4 : Midlet Record Store 4.5 : Midlet User Interface 4.6 : Midlet Kommunikationsschnittstelle Notes: © S. Rupp, Stuttgart 5/2003

Midlets benehmen sich wie Applets (1) Web-Server Client Midlet Suite Servlet Application Logic Appli-cation HTTP Midlet Container/ OS Content Web Container load application (Midlet Suite) Download Server © S. Rupp, Stuttgart 5/2003

Midlets benehmen sich wie Applets (2) Kommunikation über HTTP (bei MIDP 1.0 einziger standardisierter Verbindungstyp) Laufen in einer speziellen Umgebung (Applikations-manager startet, stoppt und löscht Midlets) Werden über eine URL von einem Server geladen bleiben jedoch nach Installation im System erhalten statt Browser (WML, iMode) auch mit URL per SMS Einverständnis des Benutzers wird vor dem Laden per Dialog abgefragt. Dabei werden dem Benutzer die wichtigsten Eigenschaften des Midlets angezeigt. © S. Rupp, Stuttgart 5/2003

Midlets laden und starten WML-Link klicken JAD Datei Browser lädt JAD Programm installieren? Ok. JAR Datei Midlet Suite Browser lädt JAR Programm wird installiert Laden erfolgt in zwei Stufen: Beschreibung laden und anzeigen Laden und Installation nach Einverständis des Benutzers Midlet lässt sich vom Benutzer starten

Zustandsdiagramm eines gestarteten Midlets (1) new myWorld() pauseApp Paused Active startApp destroyApp destroyApp Destroyed

Zustandsdiagramm eines gestarteten Midlets (2) Die Midlet Maschine (Applikationsmodell): Jedes Midlet muss vorgegebene Klassen implementieren, mit Hilfe derer die Anwendungsumgebung die Zustände des Midlets verwaltet. In einer Midlet-Suite gruppierte Midlets können miteinander kommunizieren. Eine Midlet-Suite erhält einen eigenen persistenten Speicher (Record Store). Das Zustandsdiagramm kennt die Zustände „actice“, „paused“ (Wartezustand), und „destroyed“ (beendet und aus dem Heap gelöscht), zwischen denen durch die vorgegebenen Methoden geschaltet werden kann. © S. Rupp, Stuttgart 5/2003

Erstellung von Midlets (1) Entwicklungs-system Java Quellcode Download JAD? MyWorld.java Compiler JAD Datei Java Bytecode Download JAR? MyWorld.class Preverifyer JAR Datei MyWorld.jad Java Bytecode JAD Datei MyWorld.class Runtime Verifyer Resources manifest jar -m MyWorld.jad, MyWorld.class archive Interpreter (KVM) JAR Datei MyWorldSuite.jar Zielsystem

Erstellung von Midlets (2) Sourcecode lässt sich mit regulärem Compiler in Bytecode übersetzen präverifizierter Bytecode ist ebenfalls kompatibel zu J2SE (regulärer Verifizierer ignoriert zusätzl. Attribute) Midlet-Suite wird in ein Java-Archiv gepackt (JAR), das alle für die Anwendung benötigten Midlets und Resourcen enthält Manifest enthält Informationen über den Inhalt der Midlet-Suite (wie JAD-Datei) MIDP-Paket: javax.microedition.midlet © S. Rupp, Stuttgart 5/2003

MIDP Persistent Libraries (Record Store) Basierend auf Datensätzen (Records) nach dem Prinzip eines Bandgerätes (anhängen, überschreiben an einer vorgegebenen Stelle) Der Record Store repräsentiert die logische Sicht der API, die Implementierung ist herstellerspezifisch. Record Stores sind persistent, z.B. für die Speicherung von Spielständen. Record Stores einzelner Midlet-Suites sind voneinander isoliert (getrennte Namensräume). MIDP-Paket: javax.microedition.rms © S. Rupp, Stuttgart 5/2003

Struktur des MIDP Record Stores Midlet_Suite_1 Record Store RecordId 1 RecordId 5 Midlet2 Midlet1 RecordId 3 Midlet_Suite_2 Midlet1 Midlet2

Die grafische Benutzeroberfläche des MIDP (1) Minimalanforderungen: 96x54 Bildpunkte monochrom Telefontastatur Eine ggf. umfangreichere Ausstattung verwaltet die MIDP-Implementierung des Herstellers (z.B. vertikales Scrollen, spezielle Tasten für Key-Events) Prinzip: Abstraktion von Display (anzeigbare Komponenten) und Tastatur (Ereignisse) MIDP-Paket: javax.microedition.lcdui © S. Rupp, Stuttgart 5/2003

Die grafische Benutzeroberfläche des MIDP (2) Display Alert List Screen (High Level UI) TextBox StringItem 0..1 Form ImageItem Displayable 0..n TextField Item DateField Canvas (Low Level UI) Gauge ChoiceGroup

Die grafische Benutzeroberfläche des MIDP (3) Beispiele Auswahlmenüs (List) Textbox Formular mit Regler Alert

Die grafische Benutzeroberfläche des MIDP (4) Komponenten des User Interfaces: Alert: Hinweise für begrenzte Zeit bzw. mit Quittung des Benutzers (ALARM, CONFIRMATION, ERROR, INFO, WARNING) List: Auswahlmenü. Auswahlobjekte werden per list.append angehängt.Typen von Auswahllisten: implizite, explizite und multiple-choice. TextBox: Textfenster mit Eingabemöglichkeit, z.B. für Texte, Passworter, telefonnummern, URL, E-Mail etc. Form: Formular in Art eines HTML-Formulars zur Komposition verschiedener „Items“ wie Textstrings, Bilder, Texteingabe, Auswahllisten, Schieberegler, ... © S. Rupp, Stuttgart 5/2003

Die grafische Benutzeroberfläche des MIDP (5) Command1 Screen Command2 Zuordnung von Tastatureingaben zu einem Screen CommandListener

Die grafische Benutzeroberfläche des MIDP (6) Screen als zentrale Abstraktion des MIDP UI klassische Menüführung: jeweils gültiger Bildschirm (Screen) wird mit den jeweils möglichen Auswahlmöglichkeiten angezeigt vorgegebene abstrakte Elemente und Ereignisse jedem „Screen“ lassen sich Anweisungen (Commands) zurodnen, die mit passenden Tasten des Gerätes korrespondieren oder durch die Implementierung wiederum als Auswahlmenü wiedergegeben werden, z.B. OK, BACK, CANCEL, STOP, HELP. Ein dem Screen zugeordneter CommandListener übermittelt Tastatureingaben als Ereignisse. © S. Rupp, Stuttgart 5/2003

MIDP Network Library CLDC-Paket javax.microedition.io durch MIDP erweitert um Interface HttpConnection Anwendung nach der Methode des CLDC GCF: string Target_URL = „http://localhost:8008/myPlayer?status=start“ HttpConnection c = (HttpConnection) Connector.open(Target_URL); InputStream is = c.openInputStream(); Eigenschaften der HTTP-Verbindung sind über Methoden des HttpConnection einstellbar (GET, POST, Response Code, ...). © S. Rupp, Stuttgart 5/2003

Programmierung mit Java 1 : Übersicht über Architektur und Releases 2 : Java 2 Micro Edition 3 : Connected Limited Device Configuration 4 : Mobile Information Device Profile 5 : Wireless Toolkit 6 : Ausblick - MIDP 2.0 und weiter © S. Rupp, Stuttgart 5/2003

J2ME Wireless Toolkit

Das J2ME WTK laden und starten Das J2ME gibt es auf der Web-Seite von Sun Microsystems kostenlos zum Laden (java.sun.com/products/j2mewtoolkit) Enthält Emulator zum Ausprobieren fertiger Midlets (z.B. falls kein Java-fähiges Mobiltelefon zur Hand ist). Erstellung eigener Midlets als „Projekt“ mit Verzeichnisstruktur unterstützt Informationen für JAD-Datei und Manifest werden abgefragt Compiler, Präverifizierung und Packen in JAR-Datei durch Bedienelement „Build“. © S. Rupp, Stuttgart 5/2003

Hello World im Wireless Toolkit (1)

Hello World im Wireless Toolkit (2) import javax.microedition.midlet.*; import javax.microedition.lcdui.*; public class HelloWorld extends MIDlet implements CommandListener { private Form myScreen; private static final Command EXIT_CMD = new Command( "Exit", Command.EXIT, 1 ); protected void startApp() { myScreen = new Form( "MIDlet-Titel" ); myScreen.addCommand( EXIT_CMD ); myScreen.setCommandListener( this ); myScreen.append( "Hello World!" ); Display.getDisplay( this ).setCurrent( myScreen ); } © S. Rupp, Stuttgart 5/2003

Hello World im Wireless Toolkit (3) protected void pauseApp() {} protected void destroyApp(boolean unconditional) {} public void commandAction( Command c, Displayable d ) { if ( c == EXIT_CMD ) { destroyApp( true ); notifyDestroyed(); } © S. Rupp, Stuttgart 5/2003

Hello World im Wireless Toolkit (4)

Programmierung mit Java 1 : Übersicht über Architektur und Releases 2 : Java 2 Micro Edition 3 : Connected Limited Device Configuration 4 : Mobile Information Device Profile 5 : Wireless Toolkit 6 : Ausblick - MIDP 2.0 und weiter © S. Rupp, Stuttgart 5/2003

MIDP 2.0 Basiert auf dem CLDC 1.0 und erweitert den Funktionsumfang des MIDP 1.0 um: abgesicherte Verbindungen (HTTPS, Secure Sockets) und signierte Midlets mit besonderen Privilegien (z.B. Kommunikatrionsschnittstelle ohne individuellen Dialog mit dem Benutzer bedienen) mehr Protokolle zur Vernetzung: Sockets, UDP Push-Dienste: Nachrichten von subskribierten Diensten im Netz wecken Midlets auf mehr Multimedia für Audio, Video und Spiele (Teil der Multi Media API, Graphik, Benutzerschnittstelle) standardisiertes Over-the-Air Provisioning (OTA) © S. Rupp, Stuttgart 5/2003

Die API des MIDP 2.0

Anforderungen des MIDP 2.0 Noch einige kBytes mehr: Über den Bedarf des CLDC hinaus erfordert MIDP 2.0 min. 256 kB für Klassenbibliotheken, 128 kB Heap, 8 kB persistente Daten Pakete des MIDP 2.0: Erweiterungen von javax.microedition.lcdui und javax.microedition.io neu sind javax.microedition.lcdui.games und javax.microedition.media (Subset des Multi Media API nach JSR-135 inklusive Media-Controller) ebenfalls neu ist javax.microedition.pki © S. Rupp, Stuttgart 5/2003

Wireless Toolkit 1.4 mit MIDP 2.0 Demos

Ausrichtung des MIDP 2.0 Mit den Erweiterungen gegenüber MIDP 1.0 zielt MIDP 2.0 hauptsächlich auf Spiele (inkl. Multimedia) mobile Clients Standardisierung der OTA-Schnittstelle schafft Kompatibiltiät mit den „Verkaufsmaschinen“ (Java Vending Machines) unterschiedlicher Anbieter. Kopplung über asynchrone Anchrichten, geicherte Verbindungen und Public Key Infrastruktur schaffen Voraussetzungen für mobile Clients in Unternehmen. © S. Rupp, Stuttgart 5/2003

Künftige Erweiterungen nach MIDP 2.0 (1) Mobile Media WTK unterstützt bereits Mobile Media API (JSR-135) MIDP 2.0 fordert nur monophonen Audio-Player, künftig ggf. auch echte multimediale Formate im Standard Mobile Messaging WTK unterstützt Wireless Messaging API (JSR-120) Wireless Messaging API: SMS nach dem GCF mit Connector „sms://+491717654321“ als Textstring Bluetooth (JSR-182) © S. Rupp, Stuttgart 5/2003

Künftige Erweiterungen nach MIDP 2.0 (2) Mobile Games mehr Sound, 3D-Grafik, Anschluss von Gamepads etc. Location Based Services API zu Unterstützung von Navigationshilfen, Routen-planern, bzw. Anwendungen aus dem Personenschutz Die weitere Entwicklung ist abhängig von der Aktzeptanz von MIDP 1.0 und 2.0 der Akzeptanz systemspezifischer Lösungen (z.B. auf Basis des Symbian-Betriebssystems), die sich als Kandidaten für Java-Standards eignen. © S. Rupp, Stuttgart 5/2003

Ausblick - Der Telefondienst neu aufgelegt? Ziele der Verbindung Jamtel Hans Nicole Müller-Schulz Select Tel. geschäftl. Mobiltel. geschäftl. ... bin im Geschäft Mobiltelefon Tel. privat Mobiltel. privat IMS nach: SMS e-mail inst. Message ... bin privat unterwegs Kommunikations-zustände Voice mail ... bin off-line

Programmierung mit MIDP 1.0 und MIDP 2.0 Trainingsunterlage ENDE Java 2 Micro Edition Programmierung mit MIDP 1.0 und MIDP 2.0 © S. Rupp, Stuttgart 5/2003