Page: 1© S. Rupp, 2003, Symbian_j2me.ppt Java 2 Micro Edition Trainingsunterlage Programmierung mit...

Page: 1© S. Rupp, 2003, Symbian_j2me.ppt

Java 2 Micro Edition

Trainingsunterlage

Programmierung mit MIDP 1.0 und MIDP 2.0


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

Programmierung mit Java


1.0 : Einführung

1.1 : Laufzeitumgebung

1.2 : Spezifikationen für Anwendungen (API)

1.3 : Releases

Java Architektur und Releases


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)

Was ist Java?


JavaPlattform

Hardware

SystemPlattformOperating Sytem

Hardware Drivers

Java Virtual Machine

Java API + Libraries

Java Applications and Applets

Die Java Architektur


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, ...

Was ist eine Programmierschnittstelle (API)?


API-Spezifikation als HTML-Framesets (1)


API-Spezifikation als HTML-Framesets (2)


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)

Java Community Process


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, ...)

Was benötigt man für die Anwendungsentwicklung?


Java Programming Language

Hot Spot JVM KVM Card VM

Java 2Enterprise

EditionJava 2

StandardsEdition Java 2 Micro Edition

Server

Workstation

Set-Top Box

PC, Notebook

Network Computer

Communicator

PDA

Screenphone

Smartcard

Mobile phone

Point of Sales

CLDCCDC

Physical memory:Processor:

10 MB64 Bit

512 kB32 Bit 8 Bit

1 MB32 Bit

32 kB16 Bit

Java Releases


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.

Was ist die Standard Edition (J2SE)?


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)

Was ist die Enterprise Edition (J2EE)?


J2EE Architektur und Komponenten

Applet

AppletContainer

J2SE

J2SE

ClientApplication

ClientApplicationContainer

Database

JMS

JND

I

RM

I

JDB

C

JMS

JND

IJT

AJ-

Mai

lJA

FR

MI

JDB

C

J2SE

WebContainer

JSP Page

Servlet

JMS

JND

IJT

AJ-

Mai

lJA

FR

MI

JDB

C

J2SE

EJBContainer

Enterprise Bean

HTTP

HTTP

RMI-IIOP


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

Erläuterungen zu J2EE (1)


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.

Erläuterungen zu J2EE (2)







6 : Ausblick MIDP 2.0 und weiter



2.0 : Übersicht

2.1 : Zielsysteme

2.2 : Aufbau von J2ME

2.3 : Funktionsumfang von CDC und CLDC

2.4 : MIDP 1.0

Java 2 Mirco Edition


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

Was ist die Java Micro Edition (J2ME)?


Zielsysteme für J2ME (1)


Mobiltelefone

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

Zielsysteme für J2ME (2)


JVM KVM


CLDCCDC

Foundation Profile

Midlet

Mobiltelefone

MIDP

Der Aufbau von J2ME (1)


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)

Der Aufbau von J2ME (2)


J2SE (Standard Edition)

J2MECDC J2ME

CLDC Funktionen ausserhalb des java.* Namens-raumes

CDC: Connected Device ConfigurationCLDC: Connected Limited Device Configuration

Funktionsumfang von J2ME


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)

Einschränkungen beim CLDC gegenüber J2SE (1)


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.

Einschränkungen beim CLDC gegenüber J2SE (2)


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

Die Komponenten des MIDP 1.0


3.0 : Übersicht

3.1 : Sicherheitskonzept

3.2 : Das Generic Connection Framework

Connected Limited Device Configuration


Propr.

KVM

Betriebssystem

CLDC

Midlet

Mobiltelefon

Propr.

MIDP

System-spezifische

Anwendungen

Connected Limited Device Configuration


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.

Die Komponenten des CLDC


Sicherheitskonzept (1)

Verifizierung des Bytecodes

vorgegebener Namensraum

Gesicherte Kommunikations-

schnittstellen

Voneinander isolierte Daten und

Anwendungen

Virtuelle Maschine


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.

Sicherheitskonzept (2)


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

Generic Connection Framework (1)


Connection

StreamConnectionNotifier

InputConnection

OutputConnection

DatagramConnection

StreamConnection

ContentConnection

Klassenhierarchie des CLDC GCF


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.



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



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

Mobile Information Device Profile


Web-Server

ApplicationLogic

Client

HTTP

MidletSuite

MidletContainer/

OS

WebContainer

Servlet

Content

Download Server

load application(Midlet Suite)

Appli-cation

Midlets benehmen sich wie Applets (1)


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.

Midlets benehmen sich wie Applets (2)


JADDatei

JARDatei

WML-Link klicken

Browser lädt JAD

Programm installieren? Ok.

Browser lädt JARMidlet Suite

Programm wird installiert

Midlets laden und starten

Laden erfolgt in zwei Stufen: Beschreibung laden und anzeigen

Laden und Installation nach Einverständis des Benutzers

Midlet lässt sich vom Benutzer starten


pauseApp

startApp

destroyAppdestroyApp

new myWorld()

Paused Active

Destroyed

Zustandsdiagramm eines gestarteten Midlets (1)


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.

Zustandsdiagramm eines gestarteten Midlets (2)


MyWorld.java

Compiler

Java Quellcode

Java Bytecode

Preverifyer

Java Bytecode

MyWorld.class

MyWorld.class JAD Datei

JAR Datei

archivejar -m MyWorld.jad, MyWorld.class

MyWorld.jad

MyWorldSuite.jar

Entwicklungs-system

Zielsystem

JAR Datei

JAD Datei

Download JAD?

Download JAR?

RuntimeVerifyer

Interpreter(KVM)

manifest

Resources

Erstellung von Midlets (1)


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

Erstellung von Midlets (2)


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

MIDP Persistent Libraries (Record Store)


RecordId 1

RecordId 5

RecordId 3Midlet1Midlet2

Midlet_Suite_1

Midlet2

Midlet1

Midlet_Suite_2

Record Store

Struktur des MIDP Record Stores


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

Die grafische Benutzeroberfläche des MIDP (1)


Display

Displayable

StringItem

Screen(High Level UI)

Canvas (Low Level UI)

Alert

List

TextBox

Form

Item

ImageItem

TextField

DateField

ChoiceGroup

Gauge

0..1

0..n



Alert

Textbox

Formular mit Regler

Auswahlmenüs (List)


Beispiele


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, ...



Zuordnung von Tastatureingaben zu einem Screen

Screen

Command1

Command2

CommandListener



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.



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, ...).

MIDP Network Library


J2ME Wireless Toolkit


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“.

Das J2ME WTK laden und starten


Hello World im Wireless Toolkit (1)


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 ); }



protected void pauseApp() {}

protected void destroyApp(boolean unconditional) {}

public void commandAction( Command c, Displayable

d ) {if ( c == EXIT_CMD ) {

destroyApp( true );notifyDestroyed();

}}

}



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)

MIDP 2.0


Die API 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

Anforderungen des MIDP 2.0


Wireless Toolkit 1.4 mit MIDP 2.0 Demos


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.

Ausrichtung des MIDP 2.0


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)

Künftige Erweiterungen nach MIDP 2.0 (1)


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.

Künftige Erweiterungen nach MIDP 2.0 (2)


JamtelHansNicoleMüller-Schulz

Select

Tel. geschäftl.

Mobiltel. geschäftl.

Tel. privat

Mobiltel. privat

IMS nach:• SMS • e-mail • inst. Message

Voice mail

... bin im Geschäft

... bin privat unterwegs

... bin off-line

Ziele der Verbindung

Mobiltelefon

Ausblick - Der Telefondienst neu aufgelegt?

Kommunikations-zustände


ENDE

Trainingsunterlage

Programmierung mit MIDP 1.0 und MIDP 2.0


Page: 1© S. Rupp, 2003, Symbian_j2me.ppt Java 2 Micro Edition Trainingsunterlage Programmierung mit...

Documents

Transcript of Page: 1© S. Rupp, 2003, Symbian_j2me.ppt Java 2 Micro Edition Trainingsunterlage Programmierung mit...