Mobile Computing. Betriebssysteme und Entwicklungsumgebungen. Ausarbeitung zum Hauptseminar. vorgelegt von

Transkript

1 Mobile Computing Betriebssysteme und Entwicklungsumgebungen Ausarbeitung zum Hauptseminar vorgelegt von Betreuer Gabriele Frings am 12. Juni 2002 Dr. Jürgen Nützel

2

3 Inhaltsverzeichnis 1 Einleitung 1 2 Schichten-Architektur 3 3 (Mobile) Kommunikationskanäle Überblick Die erste Generation Die zweite Generation Interim Die dritte Generation Protokolle (Mobile) Hardware Mobile Geräte Rahmenbedingungen (Mobile) Betriebssysteme Palm OS Windows CE Symbian EPOC Embedded Linux (Mobile) Entwicklungsumgebungen Entwicklungsansätze Proprietäre und plattformgebundene SDKs Microsoft.NET Plattformübergreifende SDKs Java 2 Micro Edition Die verschiedenen Editionen Unterschiede J2ME / J2SE Sprachumfang Kompatibilität zur Java Virtual Machine Specification Inhaltsverzeichnis i

4 7.3 Konfigurationen und Profile J2ME Profile und APIs MIDP PDA Profile Java APIs for Bluetooth Foundation Profile Personal Profile RMI Profile Mobile Media API Hardware für CLDC und MIDP CLDC MIDP Vorgehensweise J2ME und i-mode Beispiel J2ME 29 9 Zusammenfassung und Ausblick 33 Literaturverzeichnis 35 Alle Quellen alphabetisch 44 ii Inhaltsverzeichnis

5 1 Einleitung Was ist Mobile Computing? Leichte, tragbare aber dennoch leistungsfähige Rechner werden drahtlos vernetzt und transparent in Kommunikations- und Informationsinfrastrukturen eingebunden. aus: [15] Mobilität ist ein wichtiges Kennzeichen unserer modernen Gesellschaft. Daraus resultiert der Wunsch, umfassende Informationen nicht nur zu Hause, sondern auch unterwegs abrufen zu können. Mobile Computing bezeichnet nicht nur portable Geräte sie müssen auch über drahtlose Kommunikationskanäle verfügen. Die Verbindung zum Netz wird auch während der Fortbewegung aufrecht erhalten. Sie ist nicht an einen festen Ort wie etwa ein Gebäude oder den Campus gebunden. Beispiele sind WAP-fähige Handies oder UMTS-Geräte. Mobile Computing wird in der Literatur oft um die Bedeutung von Nomadic Computing erweitert. Nomadic Computing steht für portable Geräte, die durch ihre Netzwerk-Verbindung an einen Ort gebunden sind. Zu dieser Gruppe gehört beispielsweise ein Laptop. Dieser kann über einen festen Anschluß (z. B. Ethernet) oder durch räumlich begrenzte Funktechnologien (z. B. W-LAN) in ein Netzwerk eingebunden sein oder ohne Netzwerk arbeiten. Mobile Computing portabel + mobil + vernetzt Nomadic Computing portabel + räumlich begrenzt mobil, evtl. vernetzt Ubiquitious Computing Nomadic + Mobile Computing No Network Fixed Network Nomadic Computing Fixed Wireless Network Ubiquitious Computing Wireless Network Mobile Computing Da der Unterschied zwischen mobiler Kommunikation und Mobile Computing zunehmend verschwimmt, werden auch die Begriffe oft synonym verwendet. Einen Überblick über die Begriffswelt gibt obige Abbildung. Kapitel 1. Einleitung 1

6

7 2 Schichten-Architektur Die (mobilen) Kommunikationskanäle bilden mit der Hardware die Rahmenbedingungen für darauf aufsetzende Schichten wie Betriebssysteme, Entwicklungsumgebungen und Anwendungen. Einen Überblick über die Architektur gibt die folgende Abbildung. Abbildung 2.1: Schichten Es scheint offensichtlich, dass gewöhnliche Betriebssysteme für die effektive Ressourcenverwaltung nicht zu gebrauchen sind. Spezielle Entwicklungen in diesem Bereich werden auch unter dem Begriff Operating Systems for Handicapped Devices geführt um die notwendigen Einschränkungen zu betonen. Es existieren verschiedene Ansätze zur Anwendungsentwicklung. Die Applikationen setzen auf dem jeweilgen Betriebssystem auf. Auch hier ist eine ressourcenschonende Programmierung empfehlenswert. Die einzelnen Schichten werden in den folgenden Kapiteln erläutert. Kapitel 2. Schichten-Architektur 3

8

9 3 (Mobile) Kommunikationskanäle 3.1 Überblick Die Entwicklung der Mobilfunknetze lässt sich in einzelne Schritte unterteilen. Diese werden auch oft als Generationen bezeichnet. Wir befinden uns heute im Interim, dem Übergang von der zweiten zur dritten Generation. Die folgende Tabelle bietet eine Übersicht. Generation Übertragungs-Technologie Verbreitung 1G AMPS USA (analog) Advanced Mobile Phone Service CDMA USA 2G Code Division Multiple Access TDMA USA (digital) Time Division Multiple Access GSM Japan, Europa Global System for Mobile Communications 2.5G cdma2000 (1X), GPRS / EDGE,... USA, Europa (digital) Verbesserungen bestehender Technologien 3G CDMA2000 Breitband CDMA USA (digital) W-CDMA Wideband CDMA Japan, Europa, USA Tabelle 3.1: Überblick Mobilfunk-Generationen 3.2 Die erste Generation Als erster Mobilfunk-Standard konnte sich AMPS (Advanced Mobile Phone Service) etablieren. Dieses System basiert auf FDMA (Frequency Division Multiple Access). Dabei wird das zur Verfügung stehende Frequenz-Spektrum in Bänder von 0.03 MHz aufgeteilt. Jedes Band kann einen Anruf übertragen. Benachbarte Sender dürfen nicht die selben Bänder verwenden. Deshalb sind maximal 118 Verbindungen zur selben Zeit möglich. AMPS ist weitverbreitet in den USA, aber in Großstädten nimmt die Nutzung ab. Kapitel 3. (Mobile) Kommunikationskanäle 5

10 3.3 Die zweite Generation TDMA (Time Division multiple Access) und GSM (Global System for Mobile Communications) multiplexen die Verbindungen über Zeitschlitze. TDMA teilt das Spektrum in 3 Teile, GSM bildet 8 Zeitsegmente. TDMA und CDMA sind in den US-Städten verbreitet, GSM im Rest der Welt, vor allem in Europa und Japan. Nicht durch die Bandbreite wird CDMA (Code Division Multiple Access) begrenzt, sondern durch die Verarbeitungsgeschwindigkeit der Geräte. Es basiert auf einem komplexen mathematischen Modell, das es erlaubt, viele Gespräche simultan zu übertragen. Bei CDMA empfängt jeder Teilnehmer alle Gespräche und filtert seines durch Multiplikation mit einem Identifier heraus. 3.4 Interim Um den Dienstanbietern den Umstieg zu erleichtern und das unternehmerische Risiko zu senken erfolgt der Übergang von der zweiten zur dritten Generation mittels eines Zwischenschrittes. In dieser Zeit werden die Technologien der zweiten Generation durch Verbesserungen leistungsfähiger gemacht angeblich um den Faktor 40. Die Investitionen können auch in der dritten Generation weiterbenutzt werden. Eine Verbesserung von CDMA ist cdma2000 (1X). Sie verspricht die Datenraten von auf maximal 144 kbps zu erhöhen. Ziel ist die Umstellung auf die dritte Generation: cdma2000 (3X). GSM wird durch folgende Technologien ergänzt: HSCSD, GPRS und EDGE. HSCSD (High Speed Circuit Switched Data) ist eine Verbesserung der leitungsvermittelten GSM- Netze durch neue Software. GPRS (General Packet Radio System) ermöglicht paketvermittelte Verbindungen. Es ist optimiert für kurze, sporadische Übertragung und erlaubt Datenraten von bis zu 144 kbps. EDGE (Enhanced Data for Global Evolution) ist der große Bruder von GPRS. Es bietet noch höhere Bandbreiten mit Geschwindigkeiten von maximal 384 bps. Mit dieser Schnelligkeit ermöglicht es mobile Multimedia- Anwendungen. 3.5 Die dritte Generation UMTS (Universal Mobile Telecommunications System) ist das Schlagwort der dritten Generation. Es umfasst alle Technologien der dritten Generation. Die Versteigerungen Die zweite Generation

11 der UMTS Lizenzen haben bereits vor Augen geführt, welch hohe Investitionen nötig sind. Schließlich sollen Übertragungen zwischen 156 kbps und 2 Mbps möglich werden. Zum ersten Mal überhaupt soll globales Roaming, also das Einbuchen in jegliche Art von Netzen, möglich werden. 3.6 Protokolle Die Datenübertragung erfolgt leitungsvermittelt (Circuit Switched) oder paketvermittelt (Packet Switched). Bei der Leitungsvermittlung ist ein Kanal während der gesamten Nutzungsdauer besetzt. Durch Paketvermittlung ist eine effizientere Nutzung möglich. Man kann also ständig eingebucht bleiben, da nach Volumen abgerechnet wird. Um Informationen darzustellen, stehen verschiedene Sprachen zur Verfügung. HDML (Handheld Device Markup Language) ist in den USA weit verbreitet. Eine Teilmenge von XML (Extensible Markup Language) ist WML (Wireless Markup Language). Sie wird von WAP (Wireless Application Protocol) verwendet und ist daher in Europa und Asien gebräuchlich. Über WAP kommuniziert der mobile Nutzer mit einem Gateway. Dieses übersetzt seine Anfrage, schickt sie an den Server und verpackt die Antwort wieder, um sie zum mobilen Gerät zurückzuschicken. Über das Gateway können Dienst-Anbieter entscheiden, welche Angebote für ihre Kunden verfügbar gemacht werden. In Japan findet man die Sprache chtml (compact Hypertext Markup Language). Diese Untermenge von HTML wird über i-mode (information-mode) genutzt. i-mode bezeichnet ein Bündel aus Diensten, Software und Geräten, die von NTT DoCoMo bereitgestellt werden. Ein Gateway wird nicht benötigt. Man kann auf jedes beliebige Internet-Angebot zugreifen. Kapitel 3. (Mobile) Kommunikationskanäle 7

12

13 4 (Mobile) Hardware 4.1 Mobile Geräte Es existiert bereits eine Vielzahl mobiler Geräte. Diese lassen sich grob in 3 Kategorien einteilen. Diese Aufteilung spiegelt sich in Referenzdesigns der (mobilen) Betriebssysteme wider. Sehr kleine Display und geringe Funktionalität kennzeichnen die erste Gruppe von Geräten. Unter dem Begriff Handset werden Handies vom einfachen Modell bis zum Smartphone subsummiert. Die Eingabe erfolgt tastaturbasiert, die Geräte sind sprachzentriert bzgl. der Kommunikation. Symbian nennt das entsprechende Referenzdesign Pearl, bei Microsoft trägt es den Namen Smartphone. Personal Digital Assistants (PDAs) bilden die zweite Kategorie. Das bekannteste Beispiel ist wohl der Palm. Die Eingabe erfolgt mit einem Stift auf dem Touchscreen oder über wenige Funktionsknöpfe. Handschriftenerkennung und Emulation einer Tastatur durch Software erleichtern die Benutzung. Geräte dieser Gruppe verfügen über ein vergleichsweise großes Display (ca. 1 VGA) und sind informationszentriert. Quartz heißt 4 das Referenzdesign bei Symbian, Microsoft spricht vom Pocket PC. Hinter dem etwas mißverständlichen Begriff Personal Computer (PC) verbirgt sich das Spektrum vom leistungsstärkeren PDA bis hin zum Notebook. Ihnen gemeinsam ist die tastaturbasierte Eingabe und eine informationszentrierte Nutzung. Geräte 1 mit einem Display von ca. VGA fallen bei Symbian unter den 2 Namen Crystal. Bei Microsoft firmieren sie als Handheld PCs. Der Trend für mobile Geräte ist klar: Sie werden kleiner, billiger und verfügen über mehr Funktionen. Durch Personalisierung werden sie intimer. Diese Entwicklung ist der bei den Uhren vergleichbar. Heute ist Zeitinformation überall vorhanden und selbstverständlich. Uhren werden unbewußt genutzt. Vielleicht sind Wearables (intelligente Kleidung) die Armbanduhr der Computer-Entwicklung? Kapitel 4. (Mobile) Hardware 9

14 4.2 Rahmenbedingungen Aus den Kategorien mobiler Geräte lassen sich folgende Beschränkungen bezüglich Hardware und Kommunikation ableiten: Eingabe Die Möglichkeiten zur Eingabe unterliegen Beschränkungen durch die fortschreitende Miniaturisierung der Geräte. Neben winzigen Tastaturen, mehrfacher Tastenbelegung (z. B. beim SMS-Tippen am Handy) existieren auch neue Bedienkonzepte. Vom etablierten Stift bei den PDAs über Touchscreen bis hin zu innovativen Designs mit druckempfindlichen Gehäuseteilen gibt es viele Ideen. Sie können jedoch alle nicht den Komfort einer gewohnten Tastatur ersetzen. Verarbeitung Arbeits- und Massen-Speicher ist kostbar wie vor Jahren bei Desktop-Geräten. Auch die Leistungsfähigkeit der Prozessoren reicht nicht an das gewohnte Niveau heran. Deshalb sollte man bei der Programmierung schonend mit diesen Ressourcen umgehen und unnötigen Verbrauch vermeiden. Ausgabe Die Ausgabe ist nicht nur in der Größe beschränkt, es muß auch Rücksicht auf die Umgebung genommen werden. Die Entwicklung von ausreichend hellen Displays auch in dunklem Umfeld wird noch erforscht. Bei der Gestaltung sollte man nicht nur auf eine klare Strukturierung achten, sondern auch bedenken, dass ältere Geräte nur Graustufen unterstützen. Netzwerk Die Netzwerk-Verbindung ist nicht immer stabil. Durch Fortbewegung können Unterbrechungen entstehen. Die drahtlose Anbindung verursacht auch mehr Übertragungsfehler, die die knappe Bendbreite noch zusätzlich begrenzen. Befindet sich ein Gerät mal im Netzwerk und mal nicht, muß auch die Synchonisation zwischen offline bearbeiteten Dateien und den im Netzwerk befindlichen beachtet werden Rahmenbedingungen

15 5 (Mobile) Betriebssysteme Diese Kapitel bietet einen Überblick über die wichtigsten Betriebssysteme für mobile Geräte. Eine Link-Sammlung mit einigen Exoten findet sich unter [53]. 5.1 Palm OS Das bekannteste Betriebsystem für einen PDA ist Palm OS. Um sicherzustellen, dass ein Palm-Programm auf jedem Palm funktioniert existiert das sog. Palm OS Ready Program. Die teilnehmenden Hardware-Hersteller müssen ihre Bausteine nach den vorgegebenen Normen entwickeln. Über den Silicon Porting Kit erhalten sie die Möglichkeit, den Hardware and Device Abstraction Layer anzupassen. Beides wird geprüft, bewertet und empfohlen. Das Zertifikat erlaubt es dem Hersteller dann, seine Bauteile samt Software an Lizenznehmer von Palm OS zu verkaufen. Zu diesen zählen z. B. Sony und IBM. Palm OS ist ein 32-Bit-Betriebssystem, das für den Einsatz auf Palm PDAs spezialisiert ist. Durch die Beschränkung auf ein Referenzdesign soll wiederum die Kompatibilität der Palm-Programme abgesichert werden. Basis für den Erfolg von Palm OS war die Handschriftenerkennungssoftware Graffitti. Diese erkennt Buchstaben eines schnell erlernbaren, vereinfachten Alphabets. Die Zeichen werden auf die wichtigsten Linien reduziert. 5.2 Windows CE Microsoft s Betriebssystem für eingebettete Systeme ist Windows CE. Frühere Versionen zeichneten sich noch durch die Unterstützung sehr vieler Referenzdesigns und Prozessoren aus. Doch diesen Vorteil verspielte Microsoft durch die Fixierung auf den Strong ARM Prozessor. Bei den Nachfolgern herrscht Namens-Verwirrung. Zu Windows CE 3.0 gibt es verschiedene Nachfolger mit Codenamen wie Talisker oder Merlin. Zusätzliche Irritationen ruft die Versionsnummer hervor. Hinter Pocket PC 2002 verbirgt sich Windows CE für Pocket PC Version 2.1, das unter der OS-Version 3.0 läuft. Ähnlich verhält es sich bei Handheld PC Das Spektrum umfasst spezielle Versionen für Smartphones, Automotive,... bis hin zu Windows XP embedded. Kürzlich propagierte Microsoft Windows CE.NET, um auf das generelle Ziele die Plattform.NET Bezug zu nehmen. Kapitel 5. (Mobile) Betriebssysteme 11

16 Windows CE bietet ein komplettes präemptives Multitasking mit acht Prioritätsleveln für Applikationen. Auch Threads können gestartet werden. Zu deren Synchronisation stehen dem Programmierer viele Möglichkeiten offen. Nutzer von Microsoft Produkten wie Office empfinden es als angenehm, dass abgespeckte Versionen dieser Produkte für Windows CE verfügbar sind. Das einheitliche Look and Feel der Microsoft Mobile Software erleichtert den Einstieg. Die umfasst Adaptionen der bekannten Office-Produktpalette. 5.3 EPOC Der PDA wurde 1984 von Psion definiert. Man konnte ihn mit der BASIC-ähnlichen Programmiersprache OPL programmieren. Mit der Serie 3 erhielt er einen Betriebssystem- Kern, der EPOC hieß. Eine mögliche Erklärung für diese Abkürzung ist die Hoffnung auf eine neue Epoche. Eine andere Interpretation geht von Electronic Piece of Cheese aus. Mit der Serie 5 wurde der Name auf das 32-bit-Betriebssystem ausgeweitet. EPOC sollte zum Standard werden, deshalb entstand ein Joint Venture von Psion mit Nokia, Motorola, Ericsson, Sony Ericsson und Panasonic unter dem Namen Symbian. Deshalb spricht man auch von Symbian OS. EPOC ist auf jede Hardwarearchitektur portierbar und verfügt über drei Referenzdesigns (vgl. Abschnitt 4.1 Mobile Geräte auf Seite 9). 5.4 Embedded Linux Prognosen zufolge ist Embedded Linux auf dem besten Weg dazu, den Markt zu erobern. Eigentlich ist der skalierbare Kernel gut geeignet, aber viele Firmen schrecken aus kommerziellen Gründen zurück. Ein Open-Source-Betriebssystem zu verwenden, verpflichtet quasi dazu, den Konkurrenten die eigene Arbeit auf dem Silbertablett zu präsentieren. Zweifelhafte Berühmtheit erlangte der Yopy. Lange angekündigt, kam der PDA vor kurzem nicht wie geplant von Samsung, sondern nur über den Hardware-Hersteller G.Mate auf den Markt. Das versprochene Allround- Talent wurde stark in der Funktionalität beschnitten. Da nur wenige mobile Geräte mit embedded Linux ausgeliefert werden stellt Compaq s Angebot, den ipaq mit dem Open Handheld Program nachzurüsten, eine interessante Alternative dar. Mittlerweile sind auf dem Markt für mobile Geräte fast so viele Linux-Distributionen zu finden wie für Desktop Computer. Kommerzielle Produkte sind genauso verfügbar wie Symbian EPOC

17 Open Source Alternativen. Die wichtigsten frei verfügbaren Implementationen werden im Folgenden kurz vorgestellt. Sie basieren alle auf dem Kernel von handhelds.org [23]. Compaq ist Sponsor dieses Entwicklerforums, das ursprünglich mit der Portierung von Linux auf den ipaq begann. Century Software hat auf dem genannten Kernel basierend das Microwindows PDA Operating Environment entwickelt. In feinster Open Source Tradition wurden dabei verschiedene Tools, Cross-Compiler und andere Komponenten zu einer GUI-Entwicklungsumgebung zusammengefügt. Microwindows bietet alle Funktionalitäten eines gewöhnlichen Windows-Systems. Durch die Emulation der Schnittstellen sowohl von Windows GDI als auch des X Systems wird die Portierung von Applikationen erheblich erleichtert. Darauf aufsetzend, ist es möglich, eine angepasste Variante des Fast Light Toolkits (FLTK) zu benutzen, die FLNX heisst. Neben der Portierung von FLTK - Anwendungen wird auch Qt unterstützt. Die Anbindung des Qt Frameworks wird durch eine Kompatibilitätsschicht realisiert, die die Qt Aufrufe nach FLNX übersetzt. Weitere Informationen zu Microwindows findet man unter [49]. Das bereits erwähnte Qt Framework stammt von Trolltech. Dort wurde das Qt Palmtop Environment entwickelt. Dieses setzt auf Qt/Embedded auf, welches direkt mit der Linux Ein-/Ausgabe interagiert. Die Anwendungsentwicklung erfolgt beispielsweise unter C++ mit der Qt API. Diese kompakte Umgebung ermöglicht eine schnelle Portierung existierender Anwendungen. Unter [51] sind weitere Informationen erhältlich. Eine weitere Möglichkeit stellt Pocket Linux dar. Die Architektur dieser Umgebung von Transvirtual Technology läßt sich kurz und knapp als Implementierung einer Java Virtual Machine unter Linux beschreiben. Die Benutzerschnittstelle wird in XML beschrieben, die damit verknüpften Events werden unter Java abgearbeitet. Alle Anwendungen sind von einer Basisklasse abgeleitet, die ein standardmäßiges Event-Handling zur Verfügung stellt. Es sind also nur die Ausnahmebehandlungen explizit zu codieren. Von Nachteil dürfte jedoch die Performanz von Java sein. Weiterführende Angaben sind unter [50] verfügbar. Einen Überblick über die verschiedenen GUI / Windowing Systeme für Embedded Linux findet man bei [45]. Kapitel 5. (Mobile) Betriebssysteme 13

18

19 6 (Mobile) Entwicklungsumgebungen Auf den (mobilen) Betriebssystemen setzen Entwicklungsumgebungen auf (vgl. Abbildung 2.1 auf Seite 3). Mit den verschiedenen Software Development Kits (SDKs) können Entwickler eigene Anwendungen erstellen. 6.1 Entwicklungsansätze Aus dem breiten Spektrum mobiler Geräte, der Vielfalt an Betriebssystemen und der Vielzahl an Anwendungsszenarien ergeben sich drei Möglichkeiten, Applikationen zu erstellen: die Anwendung setzt auf einem Browser auf (Browser Based), man programmiert für den jeweiligen Prozessor (Native Code) oder eine plattformunabhängige Programmiersprache wie Java wird verwendet. Naheliegend, ist der Ansatz, speziell für ein Gerät in dessen Sprache und für dessen Betriebssystem angepassten Code zu schreiben. Der Ansatz, Native Code zu verwenden, bietet folgende Vorteile: umfangreichere Funktionalität, höhere Flexibilität und er ist off-line verwendbar. Eine zweite Möglichkeit, bietet sich über den auf jedem Betriebssystem vorhandenen Browser. Man nutzt dessen Darstellungsmöglichkeiten. Für diese Überlegung spricht: die geringe Komplexität, die Schnittstellen sind standardisiert und damit die Anwendungen portabel. Möchte man jedoch portable Applikationen erstellen, die auch off-line verwendbar sind, ist keiner der beiden genannten Ansätze ausreichend. Man kann jedoch auf eine plattformunabhängige Programmiersprache wie Java zurückgreifen. Diese vereint die Vorteile der ersten beiden Überlegungen. Was ist dann der Haken daran? Man bezahlt in Form von Ressourcen. Java wird manchmal als langsam und fett bezeichnet. Es sind jedoch abgespeckte Varianten verfügbar. Kapitel 6. (Mobile) Entwicklungsumgebungen 15

20 Der plattformunabhängige Ansatz erscheint also akzeptabel. Dennoch werden zuerst proprietäre und plattformgebundene Entwicklungsumgebungen genannt und am Beispiel von Microsoft.NET vorgestellt. In den nächsten Kapiteln wird dann auf Java eingegangen und ein Beispiel vorgestellt. 6.2 Proprietäre und plattformgebundene SDKs Zu jedem der in Kapitel 5 vorgestellten Betriebssysteme gibt es proprietäre SDKs. Sie sind speziell darauf zugeschnitten und plattformgebunden. Möchte man Applikationen für Palm OS entwickeln, kann man auf das frei verfügbare SDK, den kostenlosen Emulator und viele Entwicklungsumgebungen zurückgreifen. Zum Einstieg bieten sich die freien GNU-PRC-Tools an. Eine Windows-Portierung dieser Linux/Unix-Tools ist auch kostenlos verfügbar. Ein Vorteil dieser Lösung ist, dass jede auf dem GCC aufsetzende Entwicklungsumgebung benutzt werden kann. So lassen sich C- oder C++-Programme entwickeln. Möchte man auf BASIC basierende Sprachen verwenden, ist dies mit Kosten verbunden. Bisher wurde die Windows Plattform wegen der vielen internen Inkompatibilitäten eher übergangen. Deshalb existieren hier auch vergleichsweise wenige Applikationen. Das Microsoft SDK ist frei erhältlich. Als integrierte Entwicklungsumgebung bietet sich Visual Studio an. Die Betaversion des.net Compact Frameworks und die Extensions for Smart Devices sollen Windows XP mit der Microsoft-PDA-Plattform zusammenführen. Mit diesem Schritt versucht Microsoft, den Entwicklern diese Plattform schmackhaft zu machen. Auf fast allen mobilen Geräten mit Symbian EPOC ist eine komplette Entwicklungsumgebung vorinstalliert. Aufgrund der kleinen Tastatur greift man jedoch gerne auf die SDKs für den PC zurück. Sie sind frei verfügbar und erlauben es mit dem Emulator in C++, Java oder OPL zu entwickeln. Eine Portierung von Windows auf Linux ist im Gange. Momentan ist nur C++-Programmierung möglich und ein Emulator wie WINE wird benötigt Proprietäre und plattformgebundene SDKs

21 6.3 Microsoft.NET Was ist.net? Microsoft.NET ist eine Plattform zur Entwicklung von Internet-Anwendungen. Dabei werden offene Standards wie http und XML verwendet. Die Plattform.NET gliedert sich in vier Komponenten: Framework und Tools, Building Block Services, Enterprise Servers und Devices. Für Entwickler interessant ist der Bereich Framework und Tools. Hier wird die einheitliche Klassenbibliothek Common Language Runtime für Visual Studio.NET bereitgestellt. Das.NET-Framework ist eine Entwicklungsplattform für Anwendungen. Es existieren Compiler für Visual Basic.NET, Visual C++ und C#. Nur für C++ kann der Compiler noch nativen Code erzeugen. Aus jeder Sprache kann man einen Zwischencode erzeugen. Die Zwischensprache Microsoft Intermediate Language (MSIL) ist offengelegt und dokumentiert. Bringt man ihn unter Aufsicht der Common Language Runtime zur Ausführung, spricht man von Managed Code. Dieser wird per Just In Time Compiler (JIT-Compiler) in Maschinensprache übersetzt und ausgeführt. Microsoft.NET ist ein entfernter Nachfahre von COM (Component Object Model). Das Konzept der Code- Integration auf binärer Ebene wurde weiterverfolgt. Ergebnis ist die Sprachintegration von.net. Komponenten können in jeder der unterstützten Sprachen geschrieben werden und von allen anderen Sprachen aus benutzt werden. Die problematische Verteilung und Installation der Komponenten wurde drastisch vereinfacht. Alte COM-Komponenten können von.net aus benutzt werden. Die Building Block Services stellen vorgefertigte WebServices zur Verfügung. Man kann sie über den Verzeichnisdienst UDDI auffinden und in eigene Anwendungen integrieren. Hinter Enterprise Servers verbirgt sich die 2000-Server-Familie bzw. die.net Enterprise Server. Unter Devices fallen mobile Geräte, die angebotene Anwendungen nutzen können, z. B. ein Handy oder Handheld. Kapitel 6. (Mobile) Entwicklungsumgebungen 17

22 Das.NET Compact Framework Eben für diese mobilen Geräte wurde das.net Compact Framework (CF) entwickelt. Diese Light-Version des.net Framework weist folgende Unterschiede zum großen Bruder auf: kein ASP.NET, keine COM-Interoperabilität (Nutzung der COM-Komponenten von.net aus), keine ActiveX-Unterstützung, einige Windows-Forms-Steuerelemente fehlen, die Nutzung beliebiger OLEDB-Provider fehlt, keine Dateisystemüberwachung, kein Remoting, das über WebService-Clients hinausgeht, die Grafik-Bibliothek GDI+ fehlt, kein Drucken, Drag & Drop fehlt, keine binäre Serialisierung, kein XPath, keine XML-Validation per XML-Schemas, keine Laufzeitgenerierung und die Erzeugung eines Native Image (Install Time Compilation) fehlt. Die Smart Device Extensions Die Smart Device Extensions sind ein Add-On für Visual Studio.NET. Sie enthalten Werkzeuge für die Entwicklung auf Basis des CF. Auch ein Pocket PC Emulator zum Testen der Anwendung liegt bei. Eine Alternative für die Hardware-nahe Entwicklung stellt embedded Visual C++ dar. Damit kann man jedoch keinen Zwischencode erzeugen. Eine Entwicklung mit Visual Basic ist nicht mehr möglich; der Umstieg auf Visual Basic.NET wird empfohlen Microsoft.NET

23 Fazit Die Bezeichnung der Plattform.NET führt zu weiterer Begriffsverwirrung. War die Namensgebung bei der Betriebssystemen schon undurchsichtig, kann man nun nicht einmal mehr Entwicklungsumgebung und Betriebssystem unterscheiden. Hinter dem Namen Windows CE.NET vermutet man fälschlicherweise eine Unterstützung der.net Plattform und nicht Windows CE Version 4.0. Die Plattform wird oft auch als plattformunabhängig angepriesen, was sie aber nicht ist. Bibliotheken zur Nutzung der (Windows-) Betriebssystemfunktionalitäten unterminieren diesen Gedanken. Aufgrund vieler Ähnlichkeiten wirkt die Ankündigung des.net Compact Framework wie ein Schachzug, um Java den Rang abzulaufen. Ein weiterer Grund könnte das geringe Software-Angebot für Windows CE im Vergleich zu Palm OS darstellen. Unterstützt wird diese These durch die Ankündigung Microsofts, eine Bibliothek ähnlich wie DirektX für PDAs herauszugeben. Damit sollen die Spiele-Programmierer ins Boot geholt werden. Letzendlich werden die Programmierer entschieden, ob Microsoft auf diesem Markt Fuss fassen kann. 6.4 Plattformübergreifende SDKs Die Wabasoft Corporation stellt mit Waba eine Entwicklungsumgebung für Java mit angepasster virtueller Maschine zur Verfügung. Diese ist auf mobile Geräten mit Windows CE oder Palm OS zugeschnitten und wird als Open-Source-Produkt vertrieben. Diese eingeschränkte Portabilität wird mit enormer Geschwindigkeit aufgewogen. Auch stellt Waba viel mehr GUI-Komponenten zur Verfügung als andere virtuelle Maschinen. IBM s virtuelle Maschine trägt den Namen J9. Mit Visual Age Micro Edition (VA- ME) verfügt man über eine komfortable IDE. Diese wichtigsten Funktionen dieser preisgekrönte Entwicklungsumgebung sind nun als Plug-In für WebSphere Studio Workbench frei verfügbar. Durch diesen Schritt lösten sich auch Probleme, die bei der Portabilität und der Verwendung der API aufgetreten waren. Java ist fast untrennbar mit der Firma SUN verknüpft. Deshalb verwundert es auch kaum, dass aus diesem Hause Referenzimplementierungen und Standardisierungsbemühungen stammen. In den folgenden Kapiteln wird diese Entwicklungsumgebung näher beleuchtet. Kapitel 6. (Mobile) Entwicklungsumgebungen 19

24

25 7 Java 2 Micro Edition 7.1 Die verschiedenen Editionen Einen Überblick über die verschiedenen Editionen der Java 2 Plattform und ihre Einsatzgebiete stellt folgende Abbildung dar. Servers & enterprise computers Desktop & personal computers Optional Packages High-end consumer devices Optional Packages Low-end consumer devices Personal Profile Smartcards Java 2 Enterprise Edition (J2EE) Java 2 Standard Edition (J2SE) Foundation Profile CDC MIDP CLDC Profile Configuration Java 2 Micro Edition (J2ME) Java Card APIs Edition HotSpot VM JVM CVM KVM Card VM Virtual Machine 10 MB 512 kb 32 kb 64 bit 32 bit 16 bit 8 bit Memory Abbildung 7.1: Die Java 2 Plattform Für mobile Geräte ist die Java 2 Micro Edition, kurz J2ME, gedacht. Sie setzt auf der C Virtual Machine (CVM) oder der Kilo (Byte) Virtual Machine (KVM) auf. Beides sind virtuelle Maschinen, die für den ressourcenschonenden Einsatz optimiert wurden. 7.2 Unterschiede J2ME / J2SE Sprachumfang Eine CLDC konforme Virtual Machine ist zur Java Language Specification kompatibel mit folgenden Abweichungen: Kapitel 7. Java 2 Micro Edition 21

26 Keine Gleitkomma-Berechnungen Aufgrund der fehlenden Hardware-Unterstützung werden die Datentypen float und double und entsprechende Wrapper-Klassen nicht unterstützt. Die software-seitige Simulation über Festkomma kann durch das Paket MathFP erfolgen. Kein finalize() Diese Methode aus der Klasse Object wird vom Garbage Collector aufgerufen. Um diesen zu vereinfachen ist finalize() nicht in der CLDC-Bibliothek enthalten. begrenzte Internationalisierung Grundlegende Konvertierungen zwischen Byte Streams und Unicode sind möglich, weitergehende Konzepte wie Locale, ResourceBundle und DateFormat sind in J2ME nicht definiert. eingeschränktes Error-Handling Im Wesentlichen ist das Error-Handling für CLDC auf zwei Klassen beschränkt: java.lang.virtualmachineerror und java.lang.outofmemoryerror. Dieser Schritt resultiert aus den Ressourcen-Beschränkungen der Geräte. Auch soll sich der Programmierer nicht mit gerätespezifischen Fehlern befassen, um Plattformunabhängigkeit zu gewährleisten Kompatibilität zur Java Virtual Machine Specification Hier sind folgende Abweichungen der KVM zu nennen: Keine Gleitkomma-Berechnungen Begründung siehe oben. Kein finalize() Auch hier gelten obige Betrachtungen. eingeschränktes Error-Handling Neben den oben erwähnten Grenzen sollte das Error-Handling an das Zielgerät angepasst werden. Kein Java Native Interface (JNI) Das Sicherheitsmodell von CLDC setzt voraus, dass der Satz an nativen Funktionen fest ist. Ein Nachladen ist wegen der implementations-abhängigen Funktionsweise nicht sinnvoll. Auch wäre eine vollständige Umsetzung von JNI zu speicherintensiv Unterschiede J2ME / J2SE

27 Keine Nutzer-definierten Class Loader Aus Sicherheitsgründen kann der eingebaute Class Loader nicht überschrieben, ersetzt oder rekonfiguriert werden. Keine Reflection Reflection ist für CLDC nicht vorgesehen. Darauf basierende Möglichkeiten wie Remote methode Invocation (RMI), Serialisierung von Objekten, JVM Debugging Interface (JVMDI) und Profile Interface (JVMPI) sowie weitergehende Funktionalitäten der J2SE sind nicht verfügbar. Keine Thread Groups und Daemon Threads Multithreading ist implementiert, aber Operationen auf Gruppen von Threads können nur durch explizite Collections realisiert werden. Keine lose Kopplung Die KVM sieht keine Möglichkeit vor, ein Programm lose an ein Objektes zu koppeln. 7.3 Konfigurationen und Profile Bei den mobilen Geräten wird grob in 2 Kategorien unterschieden: High-end consumer devices können die CVM benutzen und low-end consumer devices steht die KVM zur Verfügung. Diese Unterteilung spiegelt sich in den sogenannten Konfigurationen wider. Die Connected, Limited Device Configuration (CLDC) umfasst die einfacheren Geräte und charakterisiert sie weniger über die Funktion als über technische Gegebenheiten wie wenig Speicherplatz und geringe Bandbreite. Eine Konfiguration umfasst die Menge aller implementierten Bibiliotheken und Funktionen der virtuellen Maschine. Sie stellt einen kleinsten gemeinsamen Nenner dar. Deshalb ist die CLDC auch in der etwas mächtigeren Connected Device Configuration (CDC) vollständig enthalten. Ihr werden Geräte wie Set-Top Boxen oder High-End Communicator zugeordnet. Einen Vergleich von CDC und CLDC anhand der Hardware gibt die untenstehende Tabelle. (Massen-) Netzwerk- Band- TCP/ Energie- Konfiguration Speicher verbindung breite IP versorgung CDC 2-4 MB persistent hoch ja fest CLDC ab 128 kb flüchtig gering nein Batterie Tabelle 7.1: CDC und CLDC Kapitel 7. Java 2 Micro Edition 23

28 Während eine Konfiguration einer horizontalen Einteilung entspricht, definiert ein Profil eine vertikale Einteilung. Ein mobiles Gerät kann mehrere Profile erfüllen, z. B. gerätespezifisch als Smartphone und applikationsspezifisch als Homebanking-Einrichtung. Die Homebanking-Software muss dazu nicht wissen, auf welchem Gerät sie läuft, sondern nur, dass es dieses Profil unterstützt. Die Hardware-Hersteller können selbst entscheiden, welche Profile sie für ein Gerät implementieren. Das wichtigste Profil ist derzeit das Mobile Information Device Profile (MIDP). 7.4 J2ME Profile und APIs MIDP Das Mobile Information Device Profile (MIDP) setzt auf der CLDC auf und ist für Mobile Information Devices ausgelegt. Darunter versteht man den kleinsten gemeinsamen Nenner mobiler Geräte. Die genauen Hardware-Anforderungen werden später aufgelistet. Man kann sich ein MID z. B. als Handy vorstellen. Das MIDP stellt APIs auf den folgenden Gebieten zur Verfügung: Anwendungen definieren und steuern, Text und Graphik darstellen und Eingaben verarbeiten, Daten in einfachen Datenbanken ablegen, eine Netzwerk-Verbindung über eine Untermenge von HTTP herstellen und einen Timer verwenden. Die Version 2.0 des MIDP ist bereits in Vorbereitung PDA Profile Wie das MIDP setzt dieses Profile auf dem CLDC auf. Es zielt jedoch auf PDAs ab, die mehr Speicher und bessere Darstellungsmöglichkeiten bieten als die Ziel-Geräte des MIDP. Es wird 512 kb Speicher vorausgesetzt entweder als RAM oder als Kombination aus RAM und ROM. Auch für das Display gelten strengere Richtlinien. Die Auflösung beträgt mindestens Pixel, ein Zeigegerät muss bereitgestellt werden und eine Möglichkeit, Buchstaben einzugeben. Eine Untermenge des AWT soll unterstützt werden J2ME Profile und APIs

29 7.4.3 Java APIs for Bluetooth Da Bluetooth in Verbindung mit J2ME große Potentiale verspricht wurde eine API dafür spezifiziert. Protokolle zur Auffindung von Diensten, RFCOMM und OBEX werden unterstützt. Die Voraussetzungen entsprechen denen des MIDP. Die APIs basieren auf dem CLDC Foundation Profile Das Foundation Profile setzt auf dem CDC, nicht auf dem CLDC, auf. Es dient als Basis für weitere Profile und stellt deshalb keine Klassen für das Benutzerinterface zur Verfügung. Es dient im Wesentlichen dazu, die Pakete des CDC konzeptuell integer verfügbar zu machen. Enthalten sind java.lang, java.util, java.net, java.io, java. text und java.security. Die Hardware-Anforderungen werden auf 1024 kb persistenten Speicher und 512 kb Arbeitsspeicher erhöht Personal Profile Auf dem Foundation Profile setzt das Personal Profile auf. Es macht PersonalJava auf Basis von J2ME verfügbar. Dieses Profil bietet volle Unterstützung des AWT und ist auf Web Applets ausgerichtet. Es umfasst folgende Pakete: java.applet, java.awt, java.awt.datatransfer, java.awt.event, java.awt.font, java.awt.im, java.awt. im.spi, java.awt.image, java.beans und javax.microedition.xlet. Der Ressourcenbedarf ist dadurch auch signifikant höher: 2,5 MB persistenter und 1 MB flüchtiger Speicher RMI Profile Ein weiteres Profile, das auf dem Foundation Profile aufsetzt, ist das RMI Profile. Ein Teil von RMI wird bereitgestellt. Datailliertere Informationen enthält [61]. Es stellt die gleichen Hardware-Anforderungen wie das Personal Profile Mobile Media API Neben den Profilen wird eine Multi Media API für verschiedene multimediale Typen, z. B. Töne, bereitgestellt werden. Sie wird auf dem CLDC basieren, aber auch CDC unterstützen. Kapitel 7. Java 2 Micro Edition 25

30 7.5 Hardware für CLDC und MIDP CLDC Für eine effiziente Nutzung der KVM mit den CLDC Bibliotheken gelten folgende Empfehlungen ( [63, 17]). Art Minimum Maximum Bemerkung Speicherbedarf, gesamt 160 kb 512 kb für die Java Plattform persistenter Speicher 128 kb JVM und CLDC Bibliotheken Arbeitsspeicher 32 kb Java Runtime und Heap Prozessor 16 bit 32 bit Geschwindigkeit Energieversorgung 25 MHz Batterie Netzwerk-Verbindung 9600 bps flüchtig, drahtlos Tabelle 7.2: Hardware-Empfehlungen für CLDC MIDP Nach [63, 17] wird für MIDP mindestens die folgende Hardware vorausgesetzt. Art Minimum Bemerkung Speicherbedarf persistenter Speicher 128 kb für MIDP Komponenten persistenter Speicher 8 kb für Daten, die von Anwendungen erstellt wurden Arbeitsspeicher 32 kb VM Runtime und Heap Display Größe Farbtiefe 1 bit Verhältnis 1 : 1 Form der Pixel Eingabe 1 Mechanismus Tastatur oder Touch Screen Netzwerk drahtlos bidirektional, begrenzte Bandbreite, evtl. flüchtig Tabelle 7.3: Minimal-Anforderungen für MIDP Hardware für CLDC und MIDP

31 7.6 Vorgehensweise Eine Anwendung, die das MIDP erfüllt, wurde in Analogie zu den Applets MIDlet getauft. Folgende Vorgehensweise ist beim Erstellen einer solchen Applikation zu beachten. Man erstellt also den Code und speichert ihn in Form einer *.java Datei. Der Compiler erzeugt daraus ein *.class File. Dieses wird durch das Preverifizieren um ca. 5 % größer. Dabei werden Informationen eingefügt, die das Verfizieren zur Laufzeit erleichtern. Einige Prüfungen werden aber auch schon am Entwicklungsrechner durchgeführt. Die Emulation ist ein erster Test der Implementierung. Dieser ganze Prozess wird durch Tools unterstützt. So umfasst ein Build compilieren und preverifizieren. Anschliessend packt man das Ergebnis mittels Package in ein *.jar Archiv. Dieses Archiv wird dann auf das Zielgerät geladen und installiert. Zur Laufzeit wird noch einmal Verifiziert. Dies geht jedoch rasch vonstatten durch die vorher eingefügten Zusatzinformationen. Während der Ausführung kann man die Anwendung erneut testen. Ein Beispiel, das diese Vorgehensweise illustriert, wird im nächsten Kapitel vorgestellt. 7.7 J2ME und i-mode Die japanische Firma NTT DoCoMo wurde durch der Erfolg von i-mode in Japan bekannt. Sie hat einige Java-fähige i-mode Handies im Angebot. Deren J2ME-Implementation ist nicht Standard. Sie erfüllt die CLDC, aber nicht die Anforderungen des MIDP. NTT Do- CoMo hat seine eigenen proprietären Klassen für Netzwerk, GUI etc. auf Basis der KVM und CLDC entwickelt. Da diese ein Äquivalent zum MIDP sind, ist eine Unterstützung des Standards nicht vorgesehen. Deshalb heissen die Anwendungen bei NTT DoCoMo auch nicht Midlets, sondern iappli. Sie erben von com.nttdocomo.ui.iapplication. Ein Midlet implementiert die Methoden startapp(), pauseapp() und destroyapp(). Beim iappli ist nur start() Pflicht. Optional können resume() und terminate() überschrieben werden. Auch die Verteilung der Anwendungen unterscheidet sich. Bei NTT DoCoMo kommt zur Beschreibung eine *.jam Datei zum Einsatz. Diese unterscheidet sich nicht nur in der Endung vom *.jad File Descriptor bei Midlets. Auch der interne Aufbau ist anders. Des weiteren ist die Größe eines iappli *.jar Archives auf 10 kb beschränkt. Kapitel 7. Java 2 Micro Edition 27

32

33 8 Beispiel J2ME Für mobile Geräte, die das MIDP erfüllen, kann man mit J2ME programmieren. Man erstellt dabei sogenannte MIDlets. Dazu benötigt man: Java 2 SDK Standard Edition, Version oder höher oder Java 2 Runtime Environment, Version oder höher, falls man keine Entwicklungsumgebung benötigt J2ME wireless Toolkit, aktuell ist die Version einen Editor Nach der Installation öffnet man KToolbar. Ein Fenster erscheint: Durch Klicken auf New Project legt man ein neues Projekt mit Einstellungen wie in folgender Abbildung an. Darauf hin öffnet sich ein Fenster mit Projekt-Einstellungen, das man mit OK bestätigt. Kapitel 8. Beispiel J2ME 29

34 Im Ausgabefenster erhält man Hinweise, wo man die Quellcode-Dateien und andere Ressourcen ablegen soll. Nun öffnet man den Editor und erstellt eine Datei namens HelloMidlet.java. Zum Speichern verwendet man den vorher empfohlenen Pfad. beinhalten: import javax.microedition.lcdui.*; import javax.microedition.midlet.*; public class HelloMIDlet extends MIDlet implements CommandListener { private Form mmainform; } public HelloMIDlet() { mmainform = new Form("HelloMIDlet"); mmainform.append(new StringItem(null, "Hello, MIDP!")); mmainform.addcommand(new Command("Exit", Command.EXIT, 0)); mmainform.setcommandlistener(this); } public void startapp() { Display.getDisplay(this).setCurrent(mMainForm); } public void pauseapp() {} public void destroyapp(boolean unconditional) {} public void commandaction(command c, Displayable s) { notifydestroyed(); } Die Datei sollte folgenden Code Man geht zurück zur KToolbar. Dort stößt man Build an. Die folgende Abbildung zeigt ein korrektes Ergebnis. 30

35 Durch Build wird das Projekt compiliert und preverifiziert. Dieser Mechanismus ist nötig, um dem mobilen Gerät später Arbeit abzunehmen. Beim Preverifizieren wird der Code geprüft und um Informationen für das spätere Verifizieren erweitert. Dadurch wächst die Klasse um etwa 5%. Folgende Abbildung verdeutlicht den Ablauf. Mit Run startet man eine Emulation, z. B. auf einem Standard-Handy mit Graustufen- Display. Die linke Abbildung zeigt das erwartete Ergebnis. Über den Button unter Launch gelangt man zum nächsten Bildschirm, den die rechte Abbildung zeigt. Über Project Package kann man das Projekt als *.jar-file bündeln lassen, um es auf die mobilen Geräte zu übertragen. In Verbindung mit Java Servlets und HTTP lassen sich viele verschiedene Anwendungen entwickeln. Kapitel 8. Beispiel J2ME 31

36

37 9 Zusammenfassung und Ausblick Es wurden die wichtigsten Betriebssysteme für mobile Geräte vorgestellt. Ihre Marktanteile im 4. Quartal 2001 in Westeuropa können der nebenstehenden Grafik (nach [69]) entnommen werden. Zu jedem Betriebssystem gibt es entsprechende Entwicklerkits für die proprietäre Anwendungsentwicklung. Auch plattformübergreifende Lösungen wurden vorgestellt. Symbian 14% Rest 15% Windows CE 28% Palm OS 43% Welcher Ansatz den Vorzug erhält, hängt im Wesentlichen vom Zielpublikum ab. Möchte man möglichst viele Nutzer und Geräte ansprechen, liegt Java nahe. Ob Microsoft s Bemühungen, das.net Framework in diesem Bereich zu etablieren, Erfolg hat wird größtenteils vom Zuspruch der Entwickler abhängen. Dabei sollte man auch an die mobilen Geräte von morgen denken. Diese erfordern teils komplett neue Bedienkonzepte. Studien über See-through Displays oder Wearables wecken große Erwartungen. Wearables sind Kleidungsstücke, in die die Technik integriert ist. Man kann diese sogar waschen, ohne vorher etwas entfernen zu müssen. Ein Beispiel für ein See-through Display gibt das nebenstehende Bild. Aber auch Technologien, die es erleichtern, bisherige Konzepte auf mobile Geräte zu übertragen, wie der Anoto Pen oder ein Cross Pad, erscheinen vielversprechend. Damit kann man wie gewohnt auf einem Block schreiben, aber die Notizen liegen zugleich auch digital vor. Die Informationen werden beim Anoto Pen über die Schreibbewegungen erfasst, beim abgebildeten Cross Pad werden sie über das Klemmbrett des Blocks erfasst. Diese Technologien erleichtern den Einstieg in eine moderne Technik-Welt. Auch Visionen wie Networked Surfaces oder Intra-Body Kommunikation wecken Interesse. Spektakulär wirkt das abgebildete Beispiel von Intra-Body Kommunikation bei dem Informationen über Nano-Ströme durch den menschlichen Körper übertragen werden. Kapitel 9. Zusammenfassung und Ausblick 33

38 Networked Surfaces ermöglichen es, über besondere Werkstoffe z. B. für Tische mit eingearbeiteten Kontaktpunkten, Informationen zu erfassen. Ein Beispiel gibt die untenstehende Abbildung. Innovative Geräte, wie eine Milchtüte, die selbst feststellt, dass sie zu lange in der Sonne steht, oder eine Tasse, die ihren Füllstand erkennt, könnten das Leben erleichtern. Die Idee vom vernetzten Heim könnte also bald Wirklichkeit werden. Man kommt nach Hause und kann sich in der Badewanne entspannen, die man vorher per Handy eingelassen hat. 34

39 Literaturverzeichnis

40

41 Alle Quellen alphabetisch [1] David Adamczewski: Handy-Spielereien. In c t, Ausgabe 10, Seiten , Mai [2] allnetdevices.com: allnetdevices Wireless Devices. URL [3] Prof. Michael Amberg: Mobile Computing (RWTH Aachen, 2001). Material zur Vorlesung. URL [4] Prof. Michael Amberg: Mobile Entwicklungsumgebungen. In Vorlesung [3]. Video zur Vorlesung vom URL [5] Prof. Michael Amberg: Mobile Entwicklungsumgebungen. In Vorlesung [3]. Folien zur Vorlesung vom URL [6] Christoph Andriessens, Olaf Seng und Michael Winter: Proseminar Mobile Computing und web-basierte Anwendungen: Literaturverweise. URL [7] Verschiedene Autoren: Diverse Artikel zum Stichwort Mobile Computing. In c t, [8] Dr. Joachim Baumann: Mobile Computing. Material zur Vorlesung. URL [9] Holger Bleich: Wozu noch WAP? In c t, Ausgabe 26, Seiten 92 94, Dezember [10] Holger Bleich: E-Plus startet i-mode. In c t, Ausgabe 6, Seite 54, März [11] Carlos Camacho: The Situation in Japan. URL Alle Quellen alphabetisch 37

42 [12] Dimitris N. Chorafas: High-Performance Networks, Personal Communications and Mobile Computing (Macmillan Press Ltd., Houndmills, 1997). ISBN [13] GeoComm International Corporation: Wireless Developer Network - Online PDA Programming Training and Tutorials. URL [14] Bill Day: J2ME Archive. URL [15] Nobert Diehl und Albert Held: Mobile Computing (International Thompson Publishing, Bonn, 1995). ISBN X. [16] Hannes Federrath: Sicherheit in der Mobilkommunikation. URL [17] Yu Feng and Dr. Jun Zhu: Wireless Java Programming with J2ME (Sams Publishing, Indianapolis, 2001). ISBN [18] Frank Fitzek, James Gross und Andreas Köpsel: Kurzstrecken-Sprinter. In c t, Ausgabe 26, Seiten , Dezember [19] Tom Fitzpatrick: WAP and i-mode: A Comparison. URL [20] formulasys: The Basics of Wireless - A WHITE PAPER. URL [21] David Fox: Java 2 Micro Edition and the Mobile Information Device Profile. URL [22] Gundolf S. Freymuth: Telefonie 3.0. In c t, Ausgabe 8, Seiten , April [23] Jim Gettys: handhelds.org. URL [24] Eric Giguère: Java 2 Micro Edition (Wiley Computer Publishing, New York, 2000). ISBN Alle Quellen alphabetisch

43 [25] golem.de: Studie: Mobile Computing boomt in Deutschland. URL [26] Daniel Görlich: Operating Systems for Handicapped Devices. In Reinefeld und Schintke [62]. URL [27] Abdelsalam Helal, Bert Haskell, Jeffery L. Carter, Richard Brice, Darrell Woelk and Marek Rusinkiewicz: Any Time, Anywhere Computing (Kluwer Academic Publishers, Dordrecht, 1999). ISBN [28] Werner Heuser: PDAs/Handheld PCs and UniX. URL [29] Sebastian Hochstetter: Antriebskräfte. In c t, Ausgabe 1, Seiten , Januar [30] hpc.net: Pocket PC 2002 Information and Update Guide. URL [31] Tomasz Imielinski and Henry F. Korth, (editors): Mobile Computing (Kluwer Academic Publishers, Dordrecht, 1996). ISBN [32] Yahoo! Inc.: indowireless forum Wireless Indonesia - Engineer Forum. URL [33] Zucotto Wireless Inc.: Zucotto Wireless Inc. - See Us At... URL [34] Mobile Media Japan: I-mode Java Specifications. URL [35] javamobiles.com: javamobiles.com. URL [36] Martin Kirst: IRDA und Bluetooth. URL [37] Jonathan Knudsen: Wireless Development Tutorial Part II. URL Alle Quellen alphabetisch 39