Grundlagen und Konzept eines Location Based Services für ein virtuelles Museum

Transkript

1 Ausarbeitung zur Veranstaltung Projekt (Master) im Sommersemester 2008 Grundlagen und Konzept eines Location Based Services für ein virtuelles Museum Enriko Podehl Matrikelnummer: Bearbeitungszeitraum April 2008 bis August 2010 Dozent: Prof. Dr. Christian Noss

2 Zusammenfassung In dieser Ausarbeitung werden die Grundlagen für die Entwicklung von Location Based Services beleuchtet und ein Konzept samt Prototyp für das virtuelle Museum des Kölner Sports präsentiert. Hierfür werden zuerst die technsichen Grundlagen wie die mobilen Endgeräte, die verschiedenen mobilen Betriebssysteme und Browser untersucht, um anschließend die Kommunikation mobiler Endgeräte mit dem Internet mit ihren unterschiedlichen Übertragungstechnologien zu betrachten. Danach werden die Eigenschaften von Location Based Servicse gezeigt. Hierzu gehören die Unterschiedlichen Lokalisierungsmethoden und der Zugriff auf die Lokalisierungsdaten, sowie die Datenhaltung von POIs. Auf den technischen und logischen Grundlagen aufbauend wird ein mögliches Konzept für einen Location Based Service vorgestellt. Dazu gehört eine konkrete, wenn auch spartanische Umsetzung einer mobilen Anwendung. In diesem technischen Prototypen wird die Lokalisierung und die Client-Server-Kommunikation eines mobilen Endgerätes erprobt. ii

3 Inhaltsverzeichnis Zusammenfassung Abbildungsverzeichnis Quellcodeverzeichnis Abkürzungen ii vii viii ix 1 Virtuelles Museum des Kölner Sports Projektbeschreibung Ziel dieser Arbeit Aufbau dieser Arbeit Mobile Anwendungen und Endgeräte Mobile Endgeräte Notebook Subnotebook Tablet-PC Convertible WebPad Handheld-PC/PDA, consumer-orientiert Handheld-PC/PDA, industrietauglich Mobilfunktelefon Smartphone MP3-Player Wearable Computer Mobile Betriebssysteme und Browser 14 iii

4 Inhaltsverzeichnis 3.1 Grundlagen zu mobilen Betriebssystemen Symbian OS Architektur Merkmale und Funktionsumfang Anwendungsentwicklung Windows Mobile Architektur Merkmale und Funktionsumfang Anwendungsentwicklung Mac OS X iphone Architektur Merkmale und Funktionsumfang Anwendungsentwicklung Linux Embedded Linux Linux Kernel Architektur Merkmale und Funktionsumfang Anwendungsentwicklung Android Plattformunabhängige Programmiersprachen Mobile Browser Kommunikation mobiler Endgeräte mit dem Internet Übertragungstechnologien GSM HSCSD GPRS EDGE UMTS WLAN Ausbaustadien der Netzbetreiber Location Based Service 48 iv

5 Inhaltsverzeichnis 5.1 Location Based Service Lokalisierung Zugriff auf Lokalisierungsdaten Point of Interest Was sind POI? Geo-Tagging Konzept eines Location Based Services Positionsbestimmung Kommunikation Socket Web-Service - SOAP WebRequests und WebResponse Prototyp Positionsbestimmung Client-Server-Kommunikation Anwendung Erkenntnisse aus dem Prototypen und weitere Funktionen Abschließende Betrachtung 74 A Weltweite Smartphone-Marktanteile A.1 Marktanteile Smartphone Verkauf in A.2 Marktanteile Smartphone Betriebssysteme in B Technische Spezifikationen von Betriebssystemen 78 B.1 Symbian OS v B.2 Windows Mobile B.3 Mac OS X iphone B.4 Android SDK Literaturverzeichnis 87 v

6 Abbildungsverzeichnis 2.1 Convertible Siemens SIMpad SL Palm TX PDA Industrietauglicher Handheld mit integriertem Identcode-Leser Ein Smartphone vereint den Leistungsumfang eines Mobilfunktelefones mit dem eines PDAs Ein mögliches Anwendungsfeld für Wearable Computer Ein allgemeines Betriebssystemmodell Symbian OS v9.3 Architektur Windows Embedded CE Architektur Mac OS X 10.5 Architektur Embedded Linux Architektur Eine architektonische Sicht auf den Linux Kernel OpenMoko 2008 Architektur ACCESS Linux Architektur Android Architektur Hierarchisches Wirkungssystem der mobilen Kommunikation [TC07] Kategorien von Location Based Services GPRMC Datensatz im NMEA-Protokoll Ablauf dieses Location Based Services Ablauf einer mobilen Client Server Kommunikation Die Positionsbestimmung starten Die bestimmten Positionsdaten Die Antwort des Servers vi

7 Abbildungsverzeichnis A.1 Marktanteile Smartphone Verkauf in 2008, nach Gartner A.2 Marktanteile Smartphone Betriebssysteme in 2008, nach Gartner B.1 Neuerungen Windows Mobile 6.1, Teil B.2 Neuerungen Windows Mobile 6.1, Teil vii

8 Quellcodeverzeichnis 6.1 Quellcode für die Positionsbestimmung - Variablendeklaration Quellcode für die Positionsbestimmung - Eventhandler Quellcode für die Positionsbestimmung - gps LocationChanged Quellcode für die Positionsbestimmung - gps DeviceStateChanged Quellcode für die Positionsbestimmung - UpdateData Quellcode für die Serverkommunikation - start post Quellcode für die Serverkommunikation - serverside.php Quellcode für die Serverkommunikation - start post Response viii

9 Abkürzungen ARM BSD CDC CLDC CPU CSD EDGE E-OTD GIMP GMSK GNU GPRS GPS GPSRMC GPX GSM GTK GUI HSCSD Acorn Risc Machine Berkeley Software Distribution Connected Device Configuration Connected Limited Device Configuration Central Processing Unit Circuit Switched Data Enhanced Data Rates for GSM Evolution Enhanced Observed Time Difference GNU Image Manipulation Program Gaussian Minimum Shift Keying GNU is not Unix General Packet Radio Service Global Positioning System Global Positioning Recommended Minimum Sentence C GPS Exchange Format Global System for Mobile Communications GIMP-Toolkit Graphical User Interface High Speed Circuit Switched Data ix

10 Abkürzungen HSDPA HSUPA HTTP IBM IDE IrDA JSON JVM LAN LBS LMU NMEA NMR MDA ME MIPS High Speed Downlink Packet Access High Speed Uplink Packet Access Hypertext Transfer Protocol International Business Machines Corporation Integrated Development Environment Infrared Data Association JavaScript Object Notation Java Virtual Machine Local Area Network Location Based Service Location Measurement Unit National Marine Electronics Association Network Measurement Reports Mobile Digital Assistent Micro Edition Microprocessor without interlocked pipeline stages MP3 MPEG-1 Audio Layer 3 MPEG MSA OS PAN PC PDA PIM POI PSK Moving Picture Experts Group Mobilen Service Architektur Operating System Personal Area Network Personal Computer Personal Digital Assistent Personal Information Management Point Of Interest Phase Shift Keying x

11 Abkürzungen QoS RAM RDF ROM SDK SMTP SOAP SP TA TNS TTFF UI UMTS URI URL USB VM VPN WAN WAP WLAN WSDL XML XNU Quality of Service Random Access Memory Resource Description Framework Read Only Memory Software Development Kit Simple Mail Transfer Protocol Simple Object Access Protocol Service Pack Timing Advance Taylor Nelson Sofres Time To First Fix User Interface Universal Mobile Telecommunications System Uniform Resource Identifier Uniform Resource Locator Universal Serial Bus Virtual Machine Virtual Private Network Wide Area Network Wireless Application Protocol Wireless Local Area Network Web Services Description Language Extensible Markup Language X is Not Unix xi

12 Kapitel 1 Virtuelles Museum des Kölner Sports 1.1 Projektbeschreibung Das Gemeinschaftsprojekt des Instituts für Sportgeschichte der Deutschen Sporthochschule Köln und drei Fakultäten der Fachhochschule Köln (Fakultät für Architektur: Institut für Gestaltung und Corporate Architecture, Fakultät für Angewandte Sozialwissenschaften: Institut für Medienforschung und Medienpädagogik, Fakultät für Informatik und Ingenieurwissenschaften: Institut für Informatik) beschäftigt sich mit der Konzeption eines virtuellen Museums zum Kölner Sport. Das Projekt wird von der RheinEnergie-Stiftung für den Zeitraum April 2008 bis März 2010 finanziell gefördert. Im Archiv der Sporthochschule Köln befinden sich zahlreiche Exponate, wie Bilder, Pokale, Modelle, Sportgegenstände oder Vereinsdokumentationen, die einen Überblick über die Geschichte des Kölner Sports geben. Leider fehlen finanzielle und räumliche Voraussetzungen, um sie der Öffentlichkeit in einer Ausstellung dauerhaft zugänglich zu machen. Mit dem Virtuellen Museum soll dies möglich gemacht werden, indem die Sportwissenschaftler ein Großteil der Dokumente digitalisieren und für das Vorhaben aufbereiten. Um das Museumsangebot im Internet ansprechend zu gestalten, entwickeln die Architekten ein virtuelles Raumkonzept, das Aspekte herkömmlicher Museumsgebäude mit den Möglichkeiten des Internets verbindet. So entwickeln die Informatiker bspw. vielfältige Interaktionsmöglichkeiten, die es den Museumsbesuchern ermöglichen, ihren eigenen Beitrag zur Ausstellung zu leisten und miteinander in Kontakt zu treten. Darüber hinaus soll das Museumsangebot nicht auf den virtuellen Raum beschränkt bleiben sondern durch moderne Kommunikationstechnik (GPS, Mobiltelefonie) virtuelle Präsentation und realen Erlebnisraum in der Stadt miteinander verknüpfen. Dies eröffnet auf Seiten der Pädagogik zahlreiche Möglichkeiten ein 1

13 Kapitel 1 Virtuelles Museum des Kölner Sports neuartiges didaktisches Vermittlungskonzept zu erstellen und die Museumsbesucher generationsübergreifend mit Hilfe spielerischer Elemente aktiv einzubinden und zur körperlichen Betätigung zu animieren Ziel dieser Arbeit Ziel dieser Arbeit ist es, die Grundlagen eines Location Based Services für das virtuelle Museum zu legen. Dafür sollen sowohl die technischen Voraussetzungen (Hardware, Software), als auch die logischen Zusammenhänge (Kommunikation, Anwendungslogik) untersucht und vorgestellt werden. Auf Basis der umfassenden Grundlagenarbeit wird ein Konzept für einen Location Based Service entwickelt. Dieses soll neben den verwendeten Technologien und der Anwendungslogik auch Rückschlüsse auf die Gestalt der Datenbasis zulassen. Mit Hilfe dieses Konzeptes kann schließlich ein erster Prototyp entwickelt werden. 1.3 Aufbau dieser Arbeit Zuerst wird eine allgemeine Klassifizierung von mobilen Endgeräten, auf denen (mobile) Anwendungen ausgeführt werden können, vorgenommen (Kapitel 2). Im Anschließenden 3 werden die unterschiedlichen mobilen Betriebssysteme vorgestellt. Außerdem wird auf die unterschiedlichen, verfügbaren Browser eingegangen. Das Kapitel 4 widmet sich der Kommunikation mobiler Endgeräte mit dem Internet. Hierzu gehören auch die verschiedenen Übertragungstechnologien. Danach werden im Kapitel 5 allgemeine Informationen zu Location Based Service (Positionsermittlung, POI) gegeben. Im vorletzten Abschnitt (6) wird auf Basis der vorher gesammelten Grundlagen ein Konzept vorgestellt, um den Location Based Service für das virtuelle Museum des Kölner Sports daraufhin entwickeln zu können. In diesem Kapitel wird auch ein Prototyp präsentiert, der die Lokalisierung und Client-Server-Kommunikation einer mobilen Anwendung zeigt. Im abschließenden Kapitel wird ein kurzes Fazit dieser Arbeit gezogen. 1 Vgl.: Stand:

14 Kapitel 2 Mobile Anwendungen und Endgeräte Um sich einer Lösung der Aufgabe zu nähern, ist es wichtig, zu verstehen, was unter mobilen Anwendungen verstanden wird. Dabei spielt der Begriff mobil eine entscheidende Rolle. Uwe Baumgarten unterscheidet drei Aspekte von Mobilität [Bau02]: strukturelle Mobilität, man kann Systemkomponenten hinzufügen oder entfernen funktionale Mobilität, die Möglichkeit, die Funktionsmenge eines Systems zu ändern örtliche Mobilität, das System selbst kann ohne großen Aufwand bewegt werden Da die ersten beiden Aspekte zum Beipiel auch auf Desktop Computer zutreffen, welche aber kaum als mobile Geräte bezeichnet werden können, beschränkt sich diese Arbeit allein auf die Geräte, die eine örtliche Mobilität aufweisen. Mobile Anwendungen, auch Mobile Applications oder Wireless Applications genannt, werden nach Frech [Fre03] für mobile Endgeräte entwickelt. Zu diesen mobilen Endgeräten gehören programmierbare Mobiltelefone, Smartphones, PDAs (Personal Digital Assistent), MDAs (Mobile Digital Assistent) oder auch mobile Kleincomputer wie SIMpads und auch Laptops. Diese Geräte sind im Allgemeinen klein, sehr flexibel und verfügen über die angesprochene örtliche Mobilität. Sie besitzen entweder keine oder meist eine kabellose Verbindung zu anderen Geräten, wovon sich die Bezeichnung Wirless ableitet. Im Zusammenhang mit mobilen Anwendungen spricht man von einer Mobile Solution oder auch Wireless Solution, also ein System mit sehr flexiblen und vor allem ortsunabhängigen Eigenschaften und Möglichkeiten. 3

15 Kapitel 2 Mobile Anwendungen und Endgeräte 2.1 Mobile Endgeräte Dieser Bereich folgt weitgehend einer Auflistung von Endgeräteklassen von Schwarz [Sch03], um die unterschiedlichen Arten von Endgeräten kurz vorzustellen. Bei der Auswahl wurde auf Digitalkameras und Handheld-Spielekonsolen verzichtet, da sie zu weit vom grundlegenden Problem wegführen. Generell muss man feststellen, dass die Grenzen zwischen Schwarz s Kategorien zu Weilen verschwimmen. Dies ist den aktuellen Entwicklungen im Bereich des Mobilfunks zuzuschreiben. Der Markt der mobilen Endgeräte zeichnet sich durch eine hohe Dynamik und Vielschichtigkeit 1 aus. Der Trend zu mobilen Multifunktionsgeräten, die scheinbar alles können (Audio-/Videoaufnahmen, Internet, Navigation, Kommunikation,... ) wird dieses Problem weiter verschärfen Notebook Ein Notebook entspricht in vielen Belangen einem herkömmlichen Desktop-PC. Aufgrund des kompakteren Gehäuses müssen aber Abstriche bei Erweiterbarkeit und Ergonomie gemacht werden. Problematisch ist auch die Energieversorgung, denn die Akkus liefern modellabhängig nur für maximal drei bis vier Stunden Strom. Die Hardwareausstattung eines Notebooks erstreckt sich von leistungsstarken Prozessoren (evtl. in stromsparenden Versionen) und Graiksystemen, wie sie auch in stationären Rechnern eingesetzt werden, über CD/DVD-ROM-Laufwerke bis hin zu internen Modems und Netzwerkkomponenten. Während das Gehäuse nur wenig Platz für zusätzliche Hardware bietet, so kann man diese, auf Kosten der Mobilität, über die oft zahlreichen Schnittstellen (z.b. USB, Firewire) anschließen. Eine weitere Option zur Erweiterung sind PCMCIA-Karten. Aufgrund der der hohen Rechenleistung ist dieselbe Software wie auf gewöhnlichen PCs lauffähig, was es universell einsetzbar macht. Da die ergonomisch wichtigen Ein-/Ausgabekomponenten nicht für dauerhafte Benutzung ausgelegt sind, ist es möglich, externe Lösungen anschließen, sodass das Notebook zusammen mit einer Docking-Station einen Desktop-PC vollständig ersetzen kann. 1 Vgl. Stand:

16 Kapitel 2 Mobile Anwendungen und Endgeräte Subnotebook Subnotebooks sind wesentlich kleiner und leichter als traditionelle Notebooks, bieten aber weitestgehend dieselbe Funktionalität [Leh02, Seite 72]. Dieser Vorteil wird sowohl durch kleinere Tastaturen und Bildschirme als auch durch den Verzicht auf für den Betrieb nicht unbedingt notwendige Hardware wie das CD-ROM-Laufwerk erkauft. Werden solche Komponenten benötigt, so muss man sie extern anschließen Tablet-PC Tablet-PCs sind eine relativ neue Entwicklung im Bereich der mobilen Computersysteme. Abgesehen von wenigen Bedienelementen wird fast die gesamte Oberfläche der Geräte von dem, trotz fehlender Tastatur, nicht berührungssensitiven Bildschirm eingenommen. Die Eingaben erfolgen mit einem aktiven digitalen Stift. Auch hier erlaubt bei vielen Geräten der Anschluss einer Tastatur und einer Docking- Station die Nutzung als Desktop. Die Rechenleistung ist zwar etwas geringer als die eines Notebooks, was für die meisten Anwendungen jedoch immer noch ausreicht und die netzunabhängige Betriebszeit verlängert. Die Schnittstellen betreffend steht der Tablet-PC einem Notebook in nichts nach. Platzintensive Hardware muss wie bei Notebooks extern angeschlossen werden Convertible Convertibles (Abb. 2.1) 2 vereinen die innovative Bedienung eines Tablet-PCs mit der umfangreicheren Ausstattung eines Notebooks. Der bekannten Klappvorrichtung letzterer wurde zusätzlich ein Drehmechanismus hinzugefügt, der es dem Convertible ermöglicht, den Schirm mit der Bildfläche nach oben auf die Tastatur zu klappen und ihn als Tablet-PC zu verwenden. 2 Quelle: dell-latitude-xt-convertible.jpg, Stand:

17 Kapitel 2 Mobile Anwendungen und Endgeräte Abbildung 2.1: Convertible WebPad Das Äußere eines WebPads entspricht in etwa einem Tablet-PC und wurde speziell auf die Darstellung von Webseiten ausgelegt. Ansonsten hat es allerdings aufgrund seiner Hardwarespezifikationen und des in der Regel eingesetzten Betriebssystems (Windows CE) mehr mit einem PDA gemeinsam. Auch die Bedienung erfolgt über einen Touchscreen. Die eingangs genannten SIMpads (Abb. 2.2) 3 gehören zu den hier beschriebenen WebPads. Abbildung 2.2: Siemens SIMpad SL 4 Im Zuge der Einführung des ipads von Apple, welches im Grunde auch ein Web- Pad darstellt, jedoch über mehr Funktionen verfügt, werden in den nächsten Jahren vermehrt tragbare Mini-Computer auf den Markt kommen. Diesen dienen vor allem 3 Quelle: Stand:

18 Kapitel 2 Mobile Anwendungen und Endgeräte dem Surfen im Netz, können aber mit ihren unzähligen Anwendungen auch in vielen anderen Bereich zum Einsatz kommen. So können sie den ganzen Print-Markt revolutionieren, in dem Zeitungen und Magazine nur noch in digitaler Form erscheinen und direkt über das WebPad bezogen werden können. Aber auch als Ersatz einer Speisekarte könnte ein WebPad in der Gastronomie eingesetzt werden. Darüber hinaus wären ebenfalls digitale Kataloge denkbar. Die größte Problematik bei diesen Geräten dürften allerdings ihr Strombedarf und die Hitzeverträglichkeit werden. Um einen breiten Einzug in unseren Alltag zu erreichen, müssen diese Schwachstellen von der Industrie entfernt werden Handheld-PC/PDA, consumer-orientiert Handheld-PCs können dem Namen nach in einer Hand gehalten werden. Sie sind mit Tastatur und/oder Touchscreen ausgestattet, der häufig mit einem Stift (Stilus) bedient wird. Die Ausgabe erfolgt je nach Modell entweder auf einem Farb- oder einem energiesparenden Graustufendisplay. Handhelds, die besonders auf PIM- und Office-Anwendungen ausgerichtet sind, werden auch PDAs genannt. Hinsichtlich der Rechenleistung und Ausstattung kann man eine grobe Differenzierung nach den installierten Betriebssystemen vornehmen. Abgesehen von einigen Geräten mit proprietären Betriebssystemen oder Linux sind folgende drei am weitesten verbreitet: Windows CE/Pocket PC ist optisch stark an die Windows- Versionen für Desktop-PCs angelehnt. Es benötigt daher ein Farbdisplay und eine leistungsstarke Hardware, was sich negativ auf die Akkulaufzeit niederschlägt. PalmOS(Abb. 2.3) 4 ist speziell für seinen Einsatzzweck (in PDAs) entwickelt worden und ist damit auf relativ langsam getaktete (=stromsparende) Prozessoren ausgelegt. Um mit den Pocket PCs Schritt halten zu können, wurden in der Version 5 die Multimedia-Fähigkeiten weiterentwickelt, was aber eine leistungsfähigere Hardware erforderlich machte. Die aktuelle Version 6 wurde trotz weiterer Neuerungen von keinem Hersteller angenommen. Es existiert lediglich ein Prototyp mit diesem Betriebssystem. EPOC/Symbian, die Fortentwicklung des Betriebssystems EPOC der Firma 4 Quelle: Stand:

19 Kapitel 2 Mobile Anwendungen und Endgeräte Psion durch ein Joint-Venture namhafter Unternehmen wie Nokia und Motorola laufen auch auf vergleichsweise leistungsschwachen Handhelds. Das EPOC- Betriebssystem bildet die Basis für das Symbian OS, welches eher in Geräten mit Mobilfunkeigenschaften eingesetzt wird (siehe auch Smartphone). Abbildung 2.3: Palm TX PDA Bezüglich der Erweiterbarkeit sind die Unterschiede ebenfalls enorm. Einige Handhelds verzichten etwa zugunsten des Preises oder der Gehäusegröße auf PCMCIAund Speicherkarten- Slots. Auch die Bandbreite der Schnittstellen reicht von einem seriellen Anschluß in älteren Modellen bis hin zur Komplettausstattung mit USB, IrDA, Bluetooth, GPS und WLAN. Viele Geräte erlauben den Datenaustausch mit einem Desktop-PC. Der softwareseitige Funktionsumfang hängt von der installierten Hardware ab. Kommunikations-, PIM- und Officeanwendungen beherrscht so gut wie jedes Modell. Mittlerweile sind sogar Bildbearbeitung sowie das Abspielen von Videos möglich. Die multifunktionalen PDAs werden immer häufiger auch zum M-Lerning (Mobiles Lernen) in Unternehmen, Schulen und Universitäten ingesetzt Handheld-PC/PDA, industrietauglich Die consumer-orientierten Handheld-PCs sind nicht für die härtere Beanspruchung in einer industriellen Umgebung ausgelegt. Zu diesem Zweck existieren spezielle Modelle, die sich vor allem in folgenden Aspekten unterscheiden: 8

20 Kapitel 2 Mobile Anwendungen und Endgeräte Schutz vor Stößen, Staub oder Feuchtigkeit für einhändige und grobe, d.h. Handschuh-Bedienung konzipiert Ausstattung mit Barcode-Scanner (Abb. 2.4) 5 Ansonsten sei hier auf die Ausführungen im vorhergehenden Abschnitt?? verwiesen. Abbildung 2.4: Industrietauglicher Handheld mit integriertem Identcode-Leser Mobilfunktelefon Die Mobilfunktelefone dienen längst nicht mehr allein der akustischen Kommunikation. Neben den schon länger vorhandenen SMS- und Organizerfunktionen ist inzwischen auch WAP zum Standard geworden. In absehbarer Zeit werden sie von den sogenannten Smartphones weitgehend ersetzt, welche die Mobilfunktelefone um Multimedia-Eigenschaften, Internetzugang und PIM- sowie Office-Funktionen erweitern Smartphone Hinter dem Begriff Smartphone verbirgt sich eine Kombination aus Mobilfunktelefon und Handheld bzw. PDA (Abb. 2.5) 6. Mit smart wird die Fähigkeit beschrieben, nicht nur Sprache sondern auch Daten zu bearbeiten und zu übermitteln [Leh02, Sei- 5 6 Quelle: Bild01a.jpg, Stand: Quelle: images/verlauf.gif, Stand:

21 Kapitel 2 Mobile Anwendungen und Endgeräte te 70]. Die meisten Smartphones sind schlanker als PDAs ausgeführt, verfügen über eine Tastatur (physisch und virtuell) und liegen wie ein gewöhnliches Mobiltelefon in der Hand. Smartphones sind eine Untergruppe der Electronic Organizer und verfügen daher über eine PIM-Funktionalität. Abbildung 2.5: Ein Smartphone vereint den Leistungsumfang eines Mobilfunktelefones mit dem eines PDAs. TNS 7 definiert beispielsweise alle Handymodelle als Smartphone, die neben einem Internetzugang mindestens zwei Anwendungen aus Funktionalität, PDA- Funktion, drahtlose Datenübertragung (WLAN), Microsoft Office Kompatibilität und Touchscreen aufweisen. Statt des Begriffes Smartphone findet sich in der freien Wirtschaft auch die Bezeichnung MDA 8. Diese wird unter anderem von T-Mobile für die eigenen Smartpho- nes verwendet. In dieser Arbeit werden mobile Endgeräte, welche Eigenschaften von Mobilfunktelefonen und PDAs vereinen, als Smartphones bezeichnet. In der freien Wirtschaft werden Geräte, welche in ihren Eigenschaften und Funktionen der Smartphone-Klassifizierung folgen, nicht immer als solche bezeichnet. Hierfür sind unter anderem die Marketingstrategien der jeweiligen Hersteller, die Entwicklungsgeschichte eines Produktes, aber auch die Zielgruppe verantwortlich. 7 8 Vgl. Stand: Vgl.: Stand:

22 Kapitel 2 Mobile Anwendungen und Endgeräte Abgrenzung vom Mobilfunktelefon Smartphones verfügen meist über ein Betriebssystem eines Drittanbieters (zum Beispiel Symbian OS). Es ermöglicht dem Benutzer, selbst Programme nach Belieben zu installieren. Mobilfunktelefone haben im Gegensatz dazu meist nur eine vordefinierte Programmoberfläche, die nur begrenzt, z. B. durch Java-Anwendungen erweitert werden kann. Smartphones können, im Gegensatz zu gewöhnlichen Mobilfunktelefonen, über einen druckempfindlichen Bildschirm (Touchscreen) verfügen, der die manuelle Eingabe mit dem Finger oder speziellen Plastikstiften ermöglicht. Abgrenzung vom PDA Smartphones verfügen auch über Mobilfunkeigenschaften, mit denen Handyfunktionen ausgeführt werden können. In der Regel handelt es sich um Mobilfunkmodule für GSM, HSCSD, GPRS oder UMTS und HSDPA für die Funktion des mobilen Internets. PDAs weisen dagegen eine starke Ausrichtung auf PIM- und Officeanwendungen auf und vernachlässigen solche Mobilfunkeigenschaften. Auf der anderen Seite statten einige Hersteller ihre PDAs mit zusätzlichen Mobilfunkeigenschaften aus. Diese Systeme werden Wireless Handheld genannt. Unabhängig von den Bezeichnungen, die die Hersteller für ihre Produkte wählen, werden in Zukunft klassische, consumer-orientierte PDAs von Smartphones abgelöst MP3-Player MP3-Player dienen im Grunde allein dem Abspielen von Audio-Dateien im MP3- Format. In der Regel können aktuelle Geräte auch andere Audio-Dateien abspielen. Darüberhinaus verfügen einige MP3-Player über Möglichkeiten zum Abspielen von Video-Dateien. Diese Geräte gehören dann eher zu den Multimedia-Playern. An dieser Stelle sei lediglich der ipod Touch von der Firma Apple erwähnt, da dieser, mit Hilfe eines kleinen Hacks, auch als Telefon zu gebrauchen ist und im wesentlichen alle Funktionen des bekannten iphones aufweist. Außerdem finden sich einige Smartphones, die besonders auf das Abspielen von Audiodateien sowie Radioempfang spezialisiert sind. Dank solcher Geräte verschwimmen auch hier die Grenzen hin zu einem Multifunktionsgerät. 11

23 Kapitel 2 Mobile Anwendungen und Endgeräte Wearable Computer Als Wearable Computers oder Wearables bezeichnet man Computer, die in Form von Kleidung oder in der Kleidung direkt am Körper getragen werden [Leh02, Seite 87]. Da diese Entwicklung noch in den Kinderschuhen steckt, ist man noch weit von dem Ziel entfernt, komplette Rechner in den Stoff eines Kleidungsstücks zu integrieren. Der aktuelle Stand der (marktreifen) Technik entspricht im Allgemeinen einer kleinen, irgendwo an der Kleidung befestigten, Zentraleinheit sowie Ein- und Ausgabeperipherie die möglichst nicht in der Hand getragen werden muss (z.b. am Unterarm befestigte Tastatur, Brille mit eingebautem Display). Einige mögliche Anwendungsfelder (Abb. 2.6) 9 der Wearable Computers zeigt die folgende Liste: mobile Koordination und Information (z.b. von Außendienstmitarbeitern oder Rettungskräften) Datenerfassung durch Spracheingabe oder Scanner mobile Durchführung von Messungen Abbildung 2.6: Ein mögliches Anwendungsfeld für Wearable Computer Die soeben vorgestellten Endgeräteklassen helfen die unterschiedlichen Mobilgeräte in Kategorien zu sortieren und damit einen groben Überblick über die verfügbaren 9 Quelle: Stand:

24 Kapitel 2 Mobile Anwendungen und Endgeräte mobilen Endgeräte zu erhalten. Für diese Geräte können mobile Anwendungen entwickelt werden. Es sei nochmals darauf hingewiesen, dass die Kreativität der Hersteller bei der Wahl einer Bezeichnung für ihre jeweiligen Produkte keine Grenzen kennt. Hier lohnt sich ein Blick auf die tatsächlichen Eigenschaften eines Gerätes, um eine Zuordnung anhand einer festen Kategoriesierung zu treffen. Die folgenden Kapitel konzentrieren sich allein auf Smartphones. Dies gründet sich zum Einen auf ihre Verbreitung in Deutschland (mehr als 40 Prozent besitzen bereits ein Smartphone) 10, des Weiteren auf ihre glänzenden Zukunftsaussichten 11 und letztlich auch auf ihren Funktionsumfang. Denn sie sind eine Verbindung aus leistungsfähigen und dennoch kleinen Mobilfunkgeräten, welche PIM- und Office-Funktionen besitzen und zu dem über einen mobilen Internetzugang 12 verfügen. Mit Blick auf die Problemstellung ist es besonders interessant, dass zunehmend mehr Smartphones mit GPS-Chips ausgestattet werden und somit die Verwendung für Location Based Services erleichtern. 10 Vgl. Stand: Vgl. Stand: Die Nutzung des mobilen Internets gewinnt aus Sicht der Mobilfunkanbieter, aber auch der Contentanbieter sowie der Werbetreibenden deutlich an Bedeutung. - Vgl. Stand:

25 Kapitel 3 Mobile Betriebssysteme und Browser Nachdem im vorigen Kapitel die unterschiedlichen mobilen Endgeräte (Hardware) vorgestellt wurden, folgt in diesem Kapitel eine allgemeine Betrachtung der notwendigen Software. Allen voran steht das Betriebssystem eines Smartphones. Aber auch die verschiedenen, verfügbaren Browser werden betrachtet. 3.1 Grundlagen zu mobilen Betriebssystemen Ein Betriebssystem (engl. Operating System) ermöglicht die Verwendung und damit den Betrieb eines Systems. Es steuert die Ausführung von Programmen, verwaltet die Betriebssystemmittel. Die Abbildung 3.1 zeigt einen vereinfachten, schematischen Aufbau von Betriebssystemen [Hau05, Seite 43ff]. Abbildung 3.1: Ein allgemeines Betriebssystemmodell 14

26 Kapitel 3 Mobile Betriebssysteme und Browser Die Hardware-Schicht beinhaltet die Peripheriegeräte und Baugruppen eines Systems, wie beispielsweise Prozessoren, Ein- und Ausgabegeräte, Speichermedien oder auch Geräte zur Kommunikation. Um die Sicherheit eines Systems zu erhöhen, können Zugriffe auch durch interne, hier nicht sichtbare zusätzliche Schichten gesteuert werden. Der Hardware-Abstraktion-Layer (HAL) schirmt die hardwarespezifischen Eigenschaften einer Zielplattform vor dem Rest des Betriebssystems ab. Dadurch ist ein Betriebssystem einfacher auf verschiedene Plattformen portierbar. Die Bereitstellung eines oder mehrerer Systeme zur Datei-Verwaltung sowie Treibern zur Unterstützung der Hardware gehört ebenfalls zu den Grundfunktionen eines Betriebssystems. Das Prozess- und Ressourcen- Management regelt den Ablauf von Prozessen bzw. Aufgaben, indem es Speicher zuordnet und den Zugriff auf die Geräte des Systems effizient steuert. Unterschiedliche Prioritäten von Prozessen und Aufgaben dienen zur Vermeidung von Konflikten. Prozesse oder einzelne Aufgaben können dabei von einem Benutzer oder einem Programm ausgelöst werden. Desweiteren sollte ein Betriebssystem eine normierte Programmierschnittstelle (API) zur Verfügung stellen. Zur Kapselung dieser API vom Betriebssystemkern gibt es eine Systemschnittstelle, die auch ggf. mit einem Kommandointerpreter angesprochen werden kann. Programme oder Bibliotheken können dann diese API nutzen, um betriebssystemspezifische Operationen, wie beispielsweise Funktionen zur Datei-Verwaltung, auszuführen. In den folgenden Abschnitten werden einige mobile Betriebssysteme für Smartphones vorgestellt 1. Hierzu gehören Symbian OS, Windows Mobile, Mac OS X iphone, Embedded Linux, LiMo und Android. Die Betriebssysteme Palm OS und RIM Black- Berry werden hier nicht betrachtet. Palm OS ist ein Betriebssystem vorwiegend für Organizer und PDAs und wird in Smartphones (siehe Abgrenzung in 2.1.9) nicht eingesetzt. Das Betriebssystem der Firma Research In Motion (RIM) 2 wird ausschließlich für die hauseigenen Geräte (BlackBerry) 3 eingesetzt. 1 Marktanteile von Smartphone Betriebssystemen im Jahr 2008 (siehe Anhang A) 2 Vgl. Stand: Vgl. Stand:

27 Kapitel 3 Mobile Betriebssysteme und Browser 3.2 Symbian OS Die Firma Symbian 4 ist der Marktführer im Bereich der mobilen Betriebssysteme für Smartphones (Vgl. Anhang A). Symbian wurde 1998 von den Unternehmen Sony- Ericsson, Motorola, Nokia and Psion gegründet. Zum Zeitpunkt der Erstellung dieser Arbeit liegt das Symbian OS in der Version vor, wobei aktuell nur Smartphones mit der Version ausgeliefert werden Architektur Abbildung 3.2: Symbian OS v9.3 Architektur 4 Vgl. Stand: Vgl. Stand: Vgl. Stand:

28 Kapitel 3 Mobile Betriebssysteme und Browser Die Abbildung 3.2 zeigt die Architektur von Symbian OS Version 9.3. In der untersten Schicht finden sich die Kernfunktionen des Betriebssystems. Sie ermöglicht dem Symbian OS auf verschiedenen Hardware-Plattformen eingesetzt zu werden. Ausserdem werden verschiedene Kernel-Dienste und Geräte-Treiber angeboten. Desweiteren stellt Sie grundlegende Bibliotheken zur Verfügung, mit denen beispielsweise Datei- Operationen ausgeführt werden können. Diese Kernfunktionen werden von allen anderen Komponenten genutzt. Darauf setzt die Middleware auf. Hier werden Bibliotheken und Dienste für unterschiedliche Anwendungsbereiche zur Verfügung gestellt. Die OS Services unterteilen sich in Dienste für die Kommunikation, graphische und multimedia Inhalte und zur Verbindung mit einem Personal Computer. Die Application Services stellen Kernfunktionalitäten wie beispielsweise Messaging- (SMS, MMS, usw.), Kalenderund Kontakt-Funktionen zur Verfügung. Als grafische Benutzerschnittstelle dient das UI Framework. Auf dieser Schnittstelle baut die oberste Schicht (Application Services / App. Logic) mit ihren zusätzlichen Anwendungen auf Merkmale und Funktionsumfang Im Anhang B.1 befindet sich eine Auflistung der technischen Spezifikation des Symbian OS. Das Symbian OS v9.3 basiert auf einer Microkernel-Architektur und implementiert ein volles Multi-Tasking und Threading. Alle System-Dienste bzw. Anwendungen benutzen ihre eigenen Prozesse. Die Architektur ist komplett komponentenbasiert, um eine hohe Flexibilität zu erreichen, damit Symbian auf verschiedenen Gerätetypen eingesetzt werden kann. Als Server wird ein Programm ohne Benutzerschnittstelle bezeichnet. Diese Server verwalten meist ein oder mehrere Ressourcen, auf die über eine vom Server zur Verfügung gestellten API zugegriffen werden kann. Symbian verwendet Server um Dienste bereitzustellen. Sensitive Operationen, wie z.b. das Verändern von Benutzerdaten, telefonieren oder der Aufbau von Netzwerkverbindungen können nur von Applikationen ausgeführt werden, die sich zuvor zertifiziert haben. Außerdem bietet Symbian OS zahlreiche weitere Sicherheits-Funktionen. Als Protokolle nutzt Symbian OS Https, SSL und TLS. Symbian OS unterstützt verschiedene Sprachen, wie z.b. C++ oder Java zur Entwicklung von eigenständigen Anwendungen. Charakteristisch für ein Smartphone ist eine Telefonfunktion sowie sog. PIM-Anwendungen. Diese werden von Symbian OS bereitgestellt. Hierzu zählt 17

29 Kapitel 3 Mobile Betriebssysteme und Browser beispielsweise ein Kalender, ein Adressbuch und eine Aufgabenliste. Daneben werden diverse Multimedia-Dienste angeboten, welche die Benutzung einer Kamera, die Verwendung von Audio- und Videodateien und die Unterstützung von 3D-Grafiken ermöglichen Anwendungsentwicklung Neben zahlreichen Netzwerken zur Entwicklung von Anwendungen (auch open source) für Symbian Betriebssysteme stellt Symbian ein eigenes Netzwer bereit. Das Symbian Developer Network 7 bietet umfangreiche Unterstützung bei der Anwendungsentwicklung. Neben einer aktiven Community und umfangreichen Informationen, wird dort auch Software (Tools und SDKs) zur Entwicklung kostenlos bereitgestellt. Die Entwicklung von Anwendungen ist ebenfalls kostenlos. Diese können, je nach Lizenz des Entwicklers, frei verwendet oder gekauft werden. Außerdem sind diverse Bücher zum Symbian OS und die Anwendungsentwicklung erschienen. Symbian OS-Programme werden üblicherweise in C++ implementiert. Dies ermöglicht den direkten Zugriff auf Gerätefunktionen wie Kamera, Sensoren oder das Dateisystem. Somit können auch systemnahe Anwendungen programmiert werden. Mit dem Aufkauf durch Nokia soll Symbian in Zukunft eine Open Source Plattform werden 8. Dadurch soll eine breite Palette an mobilen Open Source Anwendungen bereitgestellt werden. Ziel dieser strategischen Veränderung ist vermutlich die eindeutige Positionierung gegen Googles Open Handset Alliance, die hinter der Android- Plattform (siehe Abschnitt 3.5.6) steht. 3.3 Windows Mobile Das mobile Betriebssystem Windows Mobile 9 wird von der Firma Microsoft 10 entwickelt und liegt mit dem Stand dieser Arbeit in der Version 6.1 vor. 7 Vgl. Stand: Vgl. Stand: Vgl. Stand: Vgl. Stand:

30 Kapitel 3 Mobile Betriebssysteme und Browser Architektur Die Architektur von Windows Mobile 6 11 basiert auf Windows Embedded CE und unterstützt das.net Compact Framework in der Version 2 SP2. Abbildung 3.3: Windows Embedded CE Architektur Die Windows Embedded CE Architektur 13 in der Abbildung 3.3 unterstützt die Prozessorarchitekturen Intel x86, MIPS, ARM (mit Intel PXA) und Hitachi SuperH. Die unterste Schicht von Windows CE bildet der OEM Layer. Dieser entspricht im wesentlichen einem Hardware Abstraction Layer. Dies hat den schon erwähnten Vorteil, das für unterschiedliche Hardware nicht jedes Mal das komplette Betriebssystem neu angepasst werden muss. Multitasking und Multithreading werden vom Kernel unterstützt. Dieser enthält außerdem unterschiedliche Funktionen wie beispielsweise einen Scheduler, Power-Management und Möglichkeiten zur Ablaufsteuerung. In der 11 Vgl. Stand: Vgl. Stand: Vgl. Stand:

31 Kapitel 3 Mobile Betriebssysteme und Browser mittleren Schicht befinden sich verschiedene zusätzliche Komponenten. Die Multimedia Technologies Komponente enthält die von Microsoft bekannten DirectX-API s zum Benutzen der von einem Gerät unterstützten Multimedia-Funktionen. Das Graphic Windowing and Event System (GWES) stellt die Oberfläche und damit die Benutzerschnittstelle dar. Der Device Manager erkennt, ob ein Gerät zum System hinzugefügt wurde. Dementsprechend werden die Treiber geladen und überwacht. Zur Bereitstellung der unterschiedlichen Kommunikationsmöglichkeiten existiert die Communication Services and Networking-Komponente. In der obersten Schicht können dann Anwendungen und Dienste die zur Verfügung gestellten Bibliotheken und Funktionen nutzen Merkmale und Funktionsumfang Im Anhang B.2 befindet sich eine Auflistung der Funktionen von Windows Mobile 6.1 im Vergleich zur Version 6.0. Der Kernel von Windows CE ist voll multitasking- und multithreadingfähig. Er bietet verschiedene Kernfunktionalitäten. Das Power-Management kennt unterschiedliche Energiespar-Modi, welche je nach Verwendung und Betriebsart eingeschaltet werden. Das Betriebssystem und die mitgelieferten Anwendungen werden im ROM des Gerätes gespeichert. Falls eine Anwendung komprimiert ist, wird sie in das RAM geladen, dort entpackt und ausgeführt. Das RAM unterteilt sich in zwei verschiedene Teile. Den Objektspeicher und den Programmspeicher. Der Objektspeicher stellt eine permanente virtuelle RAM-Disk dar, zur Speicherung aktueller Daten, die bei einem Systemausfall oder Soft-Reset wiederhergestellt werden können. Der Programmspeicher arbeitet ähnlich wie der Speicher in gewöhnlichen PCs. LASS (Local Authentication Subsystem) stellt den Rahmen zur Verfügung, über den sich unabhängig von der Applikation und des Authorisierungsmechanismus Benutzer authentifizieren müssen. Außerdem kann ein Trusted Environment definiert werden, in dem nur zertifizierte Anwedungen ausführbar sind. Windows CE (bzw. Windows Mobile) unterstützt für die verschiedenen Netzwerktypen, wie beispielsweise LAN, PAN und WAN, die folgenden Protokolle und Technologien: TCP/IP, Bluetooth, IrDA, PPPoE, IPv4 und IPv6. Zusätzlich wird die Kommunikation über USB unterstützt. Verbindungen können durch eine Firewall abgesichert werden. 20

32 Kapitel 3 Mobile Betriebssysteme und Browser Die folgenden Eigenschaften 14 von Windows Mobile 6.1 ermöglichen es dem Anwender, mobil auf die verschiedensten Anwendungen und Services zuzugreifen: Direct Push integrierter Windows Media Player 10 (Abspielen von Videos und Musik) Fotos, Musik und Videos können als Anhänge in s versendet werden Ständiger Zugriff auf relevante Daten (Outlook, Webmail, Zugriff auf Windows Live Spaces, Windows Live Messenger) Threaded Text Messaging (SMS werden mit vorhergehenden Nachrichten in einer SMS-Unterhaltung gezeigt, so haben Nutzer die gesamte Konversation im Überblick) Oberfläche / Benutzerfreundlichkeit (schnellen und einfachen Zugriff auf relevante Programme und Funktionen) System Center Mobile Device Manager (SCMDM) 2008 (sichere Verwaltung der Geräte eines großen Unternehmens durch firmeneigene IT-Administratoren, Sicherheitsrichtlinien durch Server gewährleistet, sicherer und kontrollierter Datenzugriff durch VPN) Anwendungsentwicklung Microsoft stellt ein Developer Center 15 bereit, um Entwickler mobiler Anwendungen bei ihren ersten Schritten im Bereich von Windows Mobile zu unterstützen. Jedoch führt nicht jeder Link auch zu einem Ziel. Außerdem sind die Informationen sehr oberflächlich. An dieser Stelle setzt das Microsoft Developer Network (MSDN) 16 an. Hier werden neben HOW-TOs auch Software, Tools und SDKs angeboten (tlw. kostenpflichtig), die den Entwickler die Arbeit erleichtern sollen. Außerdem gibt es unabhängige Communities, wie z. B. XDA Developers 17. Generell gibt es zwei Möglichkeiten, Anwendungen für Windows Mobile zu entwickeln. Programme können entweder nativ laufen und haben dann direkten Zugriff auf die Gerätehardware. Im Allgemeinen kommen dafür die Programmiersprachen C oder C++ zum Einsatz. Die andere Variante ist, den sogenannten Managed Code zu 14 Vgl. MWM_080725_Windows_Mobile_Backgrounder.pdf, Stand: Vgl. Stand: Vgl. Stand: Vgl. Stand:

33 Kapitel 3 Mobile Betriebssysteme und Browser verwenden. Dieser Code ist keine Maschinensprache, sondern ein plattformunabhängiger Zwischencode, der von der.net-laufzeitumgebung ausgeführt wird. Hierfür verwendete Programmiersprachen sind beispielsweise Visual C#.NET oder Visual Basic.NET. Die primäre Entwicklungsumgebung für Windows Mobile ist Microsoft Visual Studio, aktuell in der Version Diese ist allerdings kostenpflichtig. Hierfür gibt es jedoch eine Testversion. Unabhängig von dieser Entwicklungsumgebung ist die Anwendungsentwicklung und Ausführung (Installieren, Programmstart) der mobilen Software kostenlos. Hierzu sei angemerkt, dass Microsoft den Download von Smartphone-ROMs, trotz der Support- und Upgrade-Probleme der Windows Mobile Betriebssysteme, untersagt Mac OS X iphone Das mobile Betriebssystem des iphones 19 stellt eine angepasste, auf die ARM-Architektur portierte Version von Mac OS X dar. Diese Version wird ebenfalls von der Firma Apple Inc. 20 entwickelt und liegt mit dem Stand dieser Arbeit in der Version 2.1 vor Architektur Zum iphone OS bzw. dem OS X iphone sind keine freien Informationen zur Architektur und dessen Spezifikation verfügbar. Um dennoch an einen Überblick zum iphone OS zu gelangen, ist eine kostenpflichtige Mitgliedschaft im iphone DevCenter 21 notwendig. Das zu Grunde liegende Betriebssystem Mac OS X liegt zum Zeitpunkt dieser Arbeit in der Version 10.5 (Leopard) vor. Die Version 10.6 (Snow Leopard) wurde für Mitte 2009 angekündigt. 18 Vgl. Stand: Vgl. Stand: Vgl. Stand: Vgl. Stand:

34 Kapitel 3 Mobile Betriebssysteme und Browser Abbildung 3.4: Mac OS X 10.5 Architektur In der untersten Schicht der Max OS X Architektur (Abb. 3.4) befindet sich Darwin 22, ein freies Unix-Betriebssystem, welches die Grundlage für Mac OS X bildet. Darwins Kernel XNU ist ein Hybridkernel. Dieser versucht die Vorteile eines monolithischen Kernels mit den Vorteilen eines Mikrokernels zu verbinden. Darwin basiert auf 4.4BSD und einem Mach-Kernel (3.0)) und bildet so für Benutzer und Software eine Schnittstelle zur Kommunikation mit der Hardware. Durch das verwandte Unix Design profitiert Mac OS X vom geschützten Speicherbereich und ausgereiften präemptiven Multitasking. Der Kernel besteht aus 5 Bestandteilen. Dazu gehört der Mach Mikrokernel mit dem BSD Subsystem, Dateisystem, Netzwerkfähigkeit und das I/O Kit. 23 Über Darwin befinden sich die Core und Application Services. In den 22 Vgl. Stand: Vgl. Stand: 23

35 Kapitel 3 Mobile Betriebssysteme und Browser Core Services befinden sich einige kritische non-gui System Services (allen voran: CarbonCore, CFNetwork,... ). Die Application Services umfassen Dienste, die für die Grafik- und Fenster-Umgebung (Quartz) von Mac OS X zuständig sind. Auf dieser Schicht setzt eine Anwendungs Umgebung auf, welche weitere ausführbare Umgebungen enthält (BSD, Carbon, Classic, Cocoa, Java, QuickTime). 24 Die oberste Schicht enthält die graphische Benutzeroberfläche (Aqua). Das iphone OS 1.0 identifizierte sich als Darwin 9.0.0d1 und entspricht im Kern dem Mac OS X 10.5 (Leopard). Im Vergleich zur Mac OS X Architektur, fehlt dem iphone OS unter anderem die Java-Plattform. Auch die graphische Benutzeroberfläche wurde an die Anforderungen des Multi-Touch-Bildschirms angepasst. In seiner Keynote zur Einführung des iphone wies Steve Jobs auf Cocoa als Haupt-API der iphone-software hin. In wie fern weitere Schichten angepasst wurden, ließ sich nicht recherchieren Merkmale und Funktionsumfang Die iphone Benutzeroberfläche basiert auf dem Konzept der direkten Manipulation mittels sogenannter multi-touch Gesten. Zusätzlich beeinflussen drei Sensoren die ausgeführten Anwendungen (Näherungssensor, Drei-Achs-Beschleunigungssensor, Helligkeitssensor). Der Home Screen zeigt Icons der Anwendungen, die der Nutzer am häufigsten benutzt. Es existiert kein Konzept für das Starten und Beenden von Anwendungen. Die Anwendungen werden über den Home Screen geöffnet und mit der Rückkehr zum Home Screen (über die Anwendung oder durch drücken des Home Buttons) wieder verlassen. Viele der mitgelieferten Anwendungen wurden entwickelt, um zusammen zu arbeiten. Hierzu gehört das Teilen oder quer Verbreiten von Daten von einer Anwendung zur anderen. Zum Beispiel kann eine Telefonnummer aus einer gelöst und als Kontakt gespeichert oder direkt angerufen werden. Die ARM-basierte CPU verwendet OpenGL ES 1.1, welches durch den 3D Grafik Hardware beschleunigten Co-Prozessor gerendert wird. Mac OS X Anwendungen können nicht auf ein Gerät mit dem iphone OS kopiert und ausgeführt werden. Sie müssen speziell für das iphone OS mit seiner ARM-Architektur geschrieben und kompiliert werden. Im iphone sind diverse Anwendungen 25 vorinstalliert. Systemei Vgl. Stand: Vgl. Stand:

36 Kapitel 3 Mobile Betriebssysteme und Browser nege Anwendungen können über den Apple App Store 26 bezogen werden. Daneben gibt es einige unauthorisierte Anwendungen von Drittanbietern, welche zwar geduldet aber nicht unterstützt werden. Somit können diese durch Updates des iphone OS beschädigt werden, was jedoch nicht das Ziel von OS Updates sein soll. Der enthaltene Webbrowser (Safari) unterstützt Webanwendungen, die auch von Drittanbietern kommen können und Webtechnologien verwenden Anwendungsentwicklung Das iphone OS ist nicht Open Source. Das iphone SDK zur Entwicklung von systemeigenen Anwendungen ist kostenlos, jedoch ist hierfür eine Mitgliedschaft im iphone Developer Program erforderlich, welche zwischen 99$ (Standard Program) und 299$ (Enterprise Program) kostet. Nur mit dieser Mitgliedschaft ist es möglich Anwendungen in den App Store zu laden, auf spezifische Informationen zum iphone OS zu zugreifen und Hilfe zur iphone OS Anwendungsentwicklung zu erhalten. Der Apple App Store stellt den einzigen offiziellen Vertriebsweg von Anwendungen für das iphone dar. Jedoch gelangt nicht jede eingereichte Software auch in die Plattform. Apple allein behält sich das Recht vor, zu entscheiden, welche Anwendung auch freigegeben wird. Außerdem besteht für Apple die Möglichkeit Anwendungen nachträglich zu entfernen. Die zugrunde liegenden Regeln sind allerdings sehr vage. 27 Hinzu kommt, dass Apple für den Vertrieb einer Anwendung 30% ihres Erlöses einbehält. Java wird von Apple und dem iphone OS nicht unterstützt. Jedoch gibt es einige Bestrebungen (u.a. von Sun Microsystems 28 ), um dennoch Java bzw. J2ME Anwendungen auf dem iphone installieren und auszuführen zu können. 29 Gleiches gilt für Flash. Hier arbeitet Adobe 30 an der Entwicklung eines FlashLite Players als eigene Anwendung Vgl. Stand: Vgl. meldung/115950, Stand: Vgl. Stand: Vgl. Stand: Vgl. Stand: Vgl. Stand:

37 Kapitel 3 Mobile Betriebssysteme und Browser 3.5 Linux Im Gegensatz zu den bisher betrachteten mobilen Betriebssystemen, gibt es nicht das eine Linux OS, sondern viele unterschiedliche Distributionen, die auf einem Linux- Kernel 32 basieren. Ähnlich den Distributionen im Bereich der PC-Betriebssysteme existieren viele unterschiedliche Anbieter von mobilen Betriebssystemen, die auf einem Linux-Kernel aufbauen. Vor allem in Japan und China ist Linux auf mobilen Endgeräten verbreitet. 33 Mit der Einführung von Android 34, einem ebenfalls linuxbasierten OS der Open Handset Alliance 35, könnte sich dies in Zukunft ändern, da Google 36 mit einem starken, globalen Partner für Smartphones zusammenarbeitet: HTC Die momentan verbreitetste Distribution stellt Mobilinux (aktuell Version 5.0) von MontaVista da. 39 Es findet sich auf ca. 90% der linuxbasierten Smartphones (angeboten von Motorola, NEC und Panasonic). Weitere Distributionen werden unter anderem von LiMo 40, ACCESS 41, Maemo 42, welches von Nokia initiiert wurde und OpenMoko 43, welches auf OpenEmbedded 44 basiert, angeboten Embedded Linux Der Ausdruck eingebettetes System (auch engl. embedded system ) bezeichnet einen elektronischen Rechner oder auch Computer, der in einen technischen Kontext eingebunden (eingebettet) ist. Dabei hat der Rechner die Aufgabe, das System, in das er eingebettet ist, zu steuern, zu regeln oder zu überwachen. Als Embedded Linux (deutsch: eingebettetes Linux ) bezeichnet man im Allgemeinen ein Eingebettetes System bzw. das darauf laufende Betriebssystem, welches auf 32 Vgl. Stand: Vgl. SymbianMarketRound-UpIssue2Oct07FINAL.pdf, Stand: Vgl. Stand: Vgl. Stand: Vgl. Stand: Vgl. Stand: Vgl. Stand: Vgl. Stand: Vgl. Stand: Vgl. Stand: Vgl. Stand: Vgl. Stand: Vgl. Stand:

38 Kapitel 3 Mobile Betriebssysteme und Browser einem Linux-Kernel basiert. Dies impliziert nicht den Gebrauch bestimmter ( Mindest -) Bibliotheken oder Anwendungen mit diesem Kernel. Embedded Linux Systeme werden normalerweise aufgrund ihrer verschiedenen Systemeigenschaften und nicht aufgrund ihrer Einsatzorte eingeteilt. Das können u. a. die Skalierbarkeit, die Unterstützung für bestimmte Prozessoren, der Stromverbrauch, das Zeitverhalten (Echtzeitfähigkeit), der Grad der möglichen Nutzerinteraktionen oder andere wesentliche Faktoren sein. Die ARM-Architektur sowie die des StrongARM sind im Bereich der Eingebetteten Systeme beliebte Prozessoren und zwar in erster Linie auf Grund ihrer geringen Stromaufnahme. Daher kamen sie schon früh für Embedded Linux Systeme in Betracht und wurden unterstützt. Als zukunftsweisend ist zu erwähnen, dass in den Embedded Linux Systemen auch häufig schon die Java-Coprozessoren der ARMs verwendet werden können. Für den Einsatz von Embedded Linux sprechen neben den fehlenden (oder bei fertigen Distributionen geringeren) Lizenz- und Laufzeitgebühren, dem Zugang zum Quellcode (besseres Verständnis für Entwickler, leichtere Anpassung, leichteres Debugging, formale Zertifizierung möglich), guter Skalierbarkeit und der breiten Hardwareunterstützung auch Punkte wie der gute Netzwerksupport der OpenSource-Gemeinschaft (Mailing-Listen) und die Unabhängigkeit von proprietären Anbietern. Bei OpenEmbedded 45 handelt es sich um eine Ansammlung von Metainformationen und Konfigurationsdateien die von BitBake 46 verwendet werden, um ein Linux-Image für ein bestimmtes Gerät zu erzeugen oder Softwarepakete für das selbige Linux Kernel Der Kern (Kernel) findet in einer Vielzahl von Distributionen und Betriebssystemen seine Anwendung. Der Begriff Linux bezeichnet somit gleichermaßen den Linux- Kern selbst, Linux-Distributionen wie auch Linux-basierte Systeme. Der Kernel eines Betriebssystems bildet die hardwareabstrahierende Schicht (Hardware Abstraction Layer). Die Software kann so immer auf die Schnittstelle zugreifen und braucht die Hardware selbst, die sie nutzt, nicht genauer zu kennen. Linux ist dabei ein modularer monolithischer Betriebssystemkern und zuständig für Speicherverwaltung, Prozess- 45 Vgl. Stand: Vgl. Stand:

39 Kapitel 3 Mobile Betriebssysteme und Browser verwaltung, Multitasking, Lastverteilung, Sicherheitserzwingung und Eingabe/Ausgabe- Operationen auf verschiedenen Geräten. Die letzte stabile Version des Linux-Kernels liegt aktuell ( ) bei Die Entwicklung von Linux liegt in der Hand einer weltweiten Gemeinschaft vieler Programmierer, die sich in erster Linie über das Internet austauschen. In vielen -Listen, aber auch in Foren und im Usenet besteht für jedermann die Möglichkeit, die Diskussionen über den Kernel zu verfolgen, sich daran zu beteiligen und auch aktiv Beiträge zur Entwicklung zu leisten. Durch diese unkomplizierte Vorgehensweise ist eine schnelle und stetige Entwicklung gewährleistet, die auch die Möglichkeit mit sich bringt, dass jeder dem Kernel Fähigkeiten zukommen lassen kann, die er benötigt. Eingegrenzt wird dies nur durch die Kontrolle von Linus Torvalds und einigen speziell ausgesuchten Programmierern, die das letzte Wort bei der Aufnahme von Verbesserungen und Patches haben. Der Linux-Kernel wurde zwischenzeitlich auf eine sehr große Anzahl von Hardware- Architekturen portiert (u. a. für Mobiltelefone). Distributoren von Linux-basierten Betriebssystemen pflegen meistens ihre eigenen Versionen des Kernels und beschäftigen zu diesem Zwecke fest angestellte Kernel-Hacker, die ihre Änderungen meist auch in die offiziellen Kernels einfließen lassen. Distributions-Kernel sind häufig intensiv gepatcht, um auch Treiber zu enthalten, die noch nicht im offiziellen Kernel enthalten sind, von denen der Distributor aber glaubt, dass seine Kundschaft sie benötigen könnte und die notwendige Stabilität respektive Fehlerfreiheit dennoch gewährleistet ist Architektur Ein Embedded Linux System ist grob in drei Schichten unterteilbar (Abb ). Die unterste Schicht wird durch die zugrunde liegende Hardware gestellt. Hierbei wird von den Treibern der folgenden Schicht so gut wie alles an Hardware abgedeckt, was einen 32-Bit Prozessor bietet. 47 Vgl. dgr-wikialinuxkernel#n1008d, Stand:

40 Kapitel 3 Mobile Betriebssysteme und Browser Abbildung 3.5: Embedded Linux Architektur Die zweite Schicht besteht aus dem eigentlichen Kernel (Abb )) welcher wieder dreifach geschichtet ist. Abbildung 3.6: Eine architektonische Sicht auf den Linux Kernel Die unterste Schicht hiervon ist eine Low-Level-Schnittstelle, welche eine erste Hardware-Abstraktion mit kleiner API für darüberliegende Schichten bietet. Danach folgen kleine Module zur (Vorab-)Interpretation von strukturierten Daten aus den Filesystem- und Netzwerkprotokollen, welche der Kernel empfängt und sendet. An 48 Vgl. dgr-wikialinuxkernel#n100d6, Stand:

41 Kapitel 3 Mobile Betriebssysteme und Browser dieser Stelle können schon erste Weichen zu Standards auf höheren Schichten gestellt werden. Die letzte Kernelschicht wird auch High-Level-Abstraction-Layer genannt und ist schon bei vielen Linux-Derivaten und Unixen gleich oder ähnlich. Diese Schicht ist bis auf Ausnahmen hardwareunabhängig; hier werden z. B. Prozesse, Threads, Dateien, Sockets und Signale generiert bzw. verarbeitet. In der letzten Schicht des Embedded Linux Systems sind verschiedene C-Bibliotheken (oder speziell für eingebettete Systeme speicheroptimierte Ersatzbibliotheken) und auch die Anwendungssoftware angesiedelt. Die Bibliotheken werden meist dynamisch mit den Anwendungen verlinkt. Nachfolgend sind zwei Beispiele für die Architektur einer Distribution zu sehen. Die Abbildung 3.7 zeigt die zuvor beschriebenen Schichten und wie sie im OpenMoko Framework 49 entsprechend auf das Endgerät abgestimmt wurden. Hier ist zu erkennen, wie in einer Middleware Low-Level Services und High-Level Services auf dem Kernel aufsetzen. Dabei gilt es zu bedenken, dass es sich hierbei um ein Framework handelt, welches die Entwicklung von Linux-basierten Architekturen erleichtern soll und demnach viel Raum für Eigenentwicklungen lässt. Abbildung 3.7: OpenMoko 2008 Architektur 49 Vgl. Stand:

42 Kapitel 3 Mobile Betriebssysteme und Browser Eine komplexere Sicht auf die Architektur eines Linux-basierten Betriebssystems erhält man in der Abbildung Abbildung 3.8: ACCESS Linux Architektur In dieser Abbildung ist auch der Kernel mit seinen Bestandteilen und einer Erwei- 50 Vgl. Stand:

43 Kapitel 3 Mobile Betriebssysteme und Browser terung von ACCESS Linux zu erkennen. Die Middleware dieser Plattform umfasst im Vergleich zum OpenMoko Framework neben Service für GPS, Bluetooth und Telephony auch die GTK+ Komponentenbibliothek und das X-Windowings System. Grundsätzlich hält sich die Architektur an den in Abbildung 3.5 gezeigten Aufbau Merkmale und Funktionsumfang Die Merkmale einer Linux-Distribution sind letztlich von der jeweiligen Distribution abhängig. Wobei sich der Kernel kaum unterscheiden sollte. Linux-basierte Betriebssysteme können von jedem weiterentwickelt werden, da sie Open Source sind. Damit lassen sie sich an alle denkbaren Anforderungen anpassen und auf bestimmte Endgeräte perfekt zuschneiden. Neben klassichen PIM-Funktionen verfügen die Betriebssysteme auch über Multimediafähigkeiten wie die Wiedergabe von MP3-Files, Animationen und Videokonferenzen Anwendungsentwicklung Bei der Entwicklung von Embedded Linux Systemen kann grob zwischen Cross- Development und Standalone Setups unterschieden werden. Cross-Development lässt sich außerdem in die beiden Untergruppen Linked Setup und Removable Storage Setup unterteilen. Linked Setup ist die Entwicklungsumgebung, die das klassische Cross-Development darstellt. Man benutzt ein Host-System auf dem eine größere IDE laufen kann zum Implementieren des eigentlichen Quellcodes. Dieser Code wird über die Links (daher der Name Linked Setup) auf das Target übertragen, auf dem sich dann ein Bootloader, der Kernel und ein (minimales) Rootfilesystem oder ein Networkfilesystem befinden. Die Links sind serielle Verbindungen oder aber Ethernet oder beides zusammen. Der Aufbau des Removable Storage Setup lehnt sich grundsätzlich an den des Linked Setup an, jedoch wird bei der Entwicklung ein Zwischenspeicher (Storage) zur Verfügung gestellt, auf dem der zweite Bootloader, der Kernel sowie das Rootfilesystem vom Host abgelegt werden. Auf dem Target befindet sich vorerst lediglich der erste Bootloader, welcher danach den Rest des Systems vom Zwischenspeicher bootet. Bei der Entwicklung mit sogenanntem Standalone Setup verzichtet man auf ein große, separate Entwicklungsplattform zu Gunsten eines alleinstehenden, entwicklungsfähigen Targets. Bei gegebener Hardware ist diese Möglichkeit populär, da dann alle zu entwickelnden Komponenten von vornherein in 32

44 Kapitel 3 Mobile Betriebssysteme und Browser ihrer natürlichen Arbeitsumgebung laufen. Ein Entwickler von Anwendungen für Embedded Linux besitzt alle Freiheiten, da die jeweiligen Linux-basierten Betriebssysteme Open Source sind. Dem Entwickler stehen hierfür diverse Entwicklungsumgebungen zur Verfügung. Häufig werden diese von den jeweiligen Distributoren angeboten. Es stehen aber auch unabhängige IDEs zur Verfügung. Einzig auf die GUI-Bibliotheken und zur Verfügung stehenden Frameworks muss der Entwickler Acht geben. Die verschiedenen Distributoren setzen dabei auf unterschiedliche Lösungen oder bringen sogar Eigenentwicklungen mit. Um möglichst plattformunabhängige Anwendungen zu entwickeln, kann Java verwendet werden, da auf allen Linux-basierten Betriebssystemen eine JVM läuft. Embedded Linux erfreut sich einer regen Community, die stetig den Linux Kernel, aber auch die jeweiligen Distributionen weiterentwickeln und in zahlreichen Projekten Anwendungen, Services und Tools rund um die Betriebssysteme schaffen. Somit kann man auf eine Fülle von Informationen zurückgreifen, welche die eigene Entwicklungsarbeit erleichtern. Diese stehen sowohl online als auch gedruckt zur Verfügung. Embedded Linux ist ein stetig wachsendes Feld, in welches eine zunhemende Anzahl von Firmen investieren: wie z. B. Nokia, Motorola, IBM, Intel und nun auch Google Android An dieser Stelle wird Android 51, als eines der Linux-Betriebssysteme, gesondert betrachtet, da hier starke und schnelle Entwicklungen sowie ein großer Hype zu erwarten sind (besonders durch Google angetrieben). Die Open Handset Alliance 52, eine Gruppe von über 30 Technologie und Mobil Unternehmen (u. a. T-Mobile, Vodafone, ASUS, Intel, NVIDIA, Google, Ebay, Garmin, HTC, Motorola), entwickelt Android. Diese Mobilplattform umfasst in ihrem Software-Stapel ein Betriebssystem, eine Middleware und diverse Schlüsselanwendungen. Zum Zeitpunkt dieser Arbeit liegt das Android SDK in der Version 1.0 vor. 51 Vgl. Stand: Vgl. Stand:

45 Kapitel 3 Mobile Betriebssysteme und Browser Architektur Die Abbildung stellt die Android Architektur dar. Diese teilt sich in die Ebenen Linux Kernel, Android Laufzeitumgebung, Bibliotheken, Anwendungs Framework und Anwendungen. Abbildung 3.9: Android Architektur Linux Kernel Android basiert auf der Linux Version 2.6 und enthält diverse Kern Services (wie Prozess- und Speicher-Management) und arbeitet zusätzlich als Abstraktionsschicht zwischen Hardware und der restlichen Software (Treiber-Verwaltung). Android Laufzeitumgebung Android enthält eine Menge von Kern-Bibliotheken, welche den größten Teil der Funktionen bereitstellen, welche in den Java Kern-Bibliotheken 53 Vgl. Stand:

46 Kapitel 3 Mobile Betriebssysteme und Browser verfügbar sind. Jede Android Anwendung läuft als eigenständiger Prozess, mit seiner eigenen Instanz der Dalvik Virtual Machine. Dalvik wurde entwickelt, damit ein Eingabegerät multiple VMs effizient betreiben kann. Die register-basierte Dalvik VM führt Dateien im Dalvik Executable (.dex) Format aus, welches für minimalen Speicherbedarf optimiert wurde. Die Dalvik VM baut auf dem Linux Kernel auf, um die zugrunde liegenden Funktionen wie Threading oder Low-Level Speicher- Management verwenden zu können. Bibliotheken Android enthält eine Menge von C/C++ Bibliotheken, die von verschiedenen Systemkomponenten verwendet werden. Zu diesen Kern-Bibliotheken gehören unter anderem folgende: System C Bibliothek Eine angepasste und für embedded Linux-Eingabegeräte optimierte Implementierung der Standard C Systembibliothek (libc). Medien Bibliotheken Diese Bibliotheken basieren auf PacketVideo s Open- CORE und unterstützen das Abspielen und Aufzeichnen von diversen Audio/Video Formaten (wie MPEG4, H.264, MP3, AAC, AMR), sowie statischen Bildformaten (JPG und PNG). Surface Manager Organisiert den Zugriff auf das Display Subsystem und setzt nahtlos 2D und 3D Grafikschichten von multiplen Anwendungen zusammen. LibWebCore Eine moderne Webbrowser Engine, die neben anderen Browsern auch den Android Browser unterstützt. SGL Die zugrunde liegende 2D Grafik Engine. 3D Bibliotheken Die Implementierung basiert auf OpenGL ES 1.0 APIs und setzt sowohl die 3D Hardwarebeschleunigung, als auch die optimierte 3D Softwarerasterung ein FreeType Hiermit wird Bitmap und Vector Font Redndering durchgeführt. SQLite Diese Relationale Datenbank Engine steht jeder Anwendung zur Verfügung. Anwendungs Framework Anwendungsentwickler haben den vollen Zugriff auf die gleichen Framework APIs, die von den Kernanwendungen verwendet werden. Die Architektur wurde besonders auf die Wiederverwendung von Komponenten ausgerichtet. Jede Anwendung kann seine Ressourcen veröffentlichen und alle anderen Anwendungen können diese dann verwenden. Der selbe Mechanismus erlaubt es dem Benutzer Komponenten zu ersetzen. Hinter allen Anwendungen liegt ein Satz an Services und 35

47 Kapitel 3 Mobile Betriebssysteme und Browser Systemen, wie zum Beispiel: Ein umfangreicher und erweiterbarer Satz an Sichten (unter anderem Listen, Grids, Textboxen, Buttons und ein eingebetteter Webbrowser), welche zum Entwickeln von Anwendungen verwendet werden können. Content Provider, die Anwendungen ermöglichen auf Daten aus anderen Anwendungen zuzugreifen (wie zum Beispiel Kontakte), oder um ihre eigenen Daten mit anderen zu teilen. Ein Ressourcen Manager, der Zugriff auf nicht-code Ressourcen (wie zum Beispiel lokalisierte Strings, Grafiken und Layout Dateien) ermöglicht. Ein Benachrichtigungs Manager, der allen Anwendungen ermöglicht individuelle Benachrichtigungen (Alerts) in der Statusleiste anzuzeigen. Ein Aktivitäts Manager, der den Lebenszyklus von Anwendungen managt. Anwendungen Android wird mit einem Satz an Kernanwendungen ausgeliefert, die unter anderem einen Client, ein SMS Programm, einen Kalender, Karten, Browser, Kontakte enthalten. Alle Anwendungen wurden mit Java entwickelt. Merkmale und Funktionsumfang Im Anhang B.4 befindet sich eine zusammengefasste Auflistung der Funktionen des SDK Version 1.0. Android und das zugrunde liegende SDK wurde spezielle auf eine leichte Erweiterbarkeit abgestimmt. Anwendungsentwickler profitieren besonders von der offenen Plattform und dem Anwendungs Framework. Anwendungsentwicklung Anwendungsentwickler können mit Hilfe des Android SDKs Anwendungen für diese Plattform entwickeln. Anwendungen werden in Java geschrieben und laufen in Dalvik, der individuellen virtuellen Maschine, welche für die eingebettete Benutzung entwickelt wurde und über einem Linux Kernel läuft. Einem Anwendungsentwickler stehen viele Hilfsmittel bei der Erstellung neuer Android-Anwendungen zur Verfügung. Im Internet finden sich viele hilfreiche und auch für Anfänger geeignete Artikel. 54 Diese umfassen Themen wie: Installation des 54 Vgl. Stand:

48 Kapitel 3 Mobile Betriebssysteme und Browser SDKs und Plugins, Entwickeln und Debuggen, ein Hallo Welt Tutorial, Anleitung zur Struktur und Architektur von Android Anwendungen, Notizzettel Tutorial, Entwicklungs Tools, Anleitung zu Anwendungen, Aufgaben, Prozesse und Threads und Informationen zum Lebenszyklus einer Android Anwendung. Zusätzliche stellt Google einige nützliche Packages bereit, die man sich ansehen und herunterladen bzw. verwenden kann. Außerdem gibt es Artikel, die die Philosophie hinter dem System erläutern und detailliert die Subsysteme beschreiben. Darin sind unter anderem Artikel zur Implementierung eines UI, Beschreibung der Android Komponenten, Speichern und Wiederfinden von Daten und dem Sicherheitsmodell enthalten. Neben diesen bereitgestellten Informationen kann der Entwickler auch auf ein Forum 55 zugreifen, in dem Entwickler Probleme und Lösungen diskutieren können. Außerdem findet sich ein Blog 56 in dem unterschiedliche Themen besprochen werden, die teilweise einen tieferen Blick in oder hinter Android Anwendungen ermöglichen. Android Anwendungen können mit den gleichen Entwicklungsumgebungen und Tools entwickelt werden, die auch für die Entwicklung von Java Anwendungen geeignet sind. Demnach können Java Entwickler ihre gewohnten Tools auch weiterhin benutzen, wenn sie speziell Anwendungen für Android zu entwickeln. Für das Einstellen von Anwendungen in den Android Market ist ein Developer Account von Nöten. Für diesen müssen einmalig 25 bezahlt werden. 3.6 Plattformunabhängige Programmiersprachen Die Betrachtung der mobilen Betriebssysteme offenbart ein Problem. Eine bestimmte Anwendung ist nicht auf jedem Betriebssystem lauffähig. Vielmehr müsste eine mobile Anwendung an jedes Betriebssystem angepasst und dafür sogar mit unterschiedlichen Programmiersprachen entwickelt werden. Eine mögliche Lösung für dieses Problem scheinen plattformunabhängige Programmiersprachen. Hier bieten sich Java ME 57 und FlashLite 58 an. Diese werden von den meisten mobilen Betriebssystemen unterstützt. Allerdings nicht von allen, denn bisher können beide Produkte nicht im iphone verwendet werden. 55 Vgl. Stand: Vgl. Stand: Vgl. Stand: Vgl. Stand:

49 Kapitel 3 Mobile Betriebssysteme und Browser 3.7 Mobile Browser Die Auswahl an mobilen Browsern ist deutlich umfangreicher, als die der etablierten Internet-Browser für PCs bzw. Notebooks. Die Gründe hierfür liegen in einem umkämpften und vor allem jungen Markt, auf den nahezu jeder Hersteller von Smartphones oder Betriebssystemen für Smartphones ein Produkte unterbringen möchte. Die mobilen Browser unterscheiden sich nicht nur in ihren Herstellern, sondern auch ob sie an ein bestimmtes Endgerät bzw. Betriebssystem gebunden sind, oder vom Nutzer selbständig (zusätzlich) installiert werden können. Ein weiteres Unterscheidungskriterium liegt im Lizenzmodell des Browsers, denn die meisten sind nicht frei und Open Source, sondern sind proprietär. Natürlich unterscheiden sich die Browser auch in ihren Leistungsmerkmalen, welchem im Rahmen dieser Arbeit nicht untersucht wurden. Zu den verfügbaren mobilen Browsern gehören unter anderem: Fennec 59 Android Browser Internet Explorer Mobile 60 Safari 61 Opera Mobile 62 Skyfire 63 NetFront 64 Es gibt viele Statistiken zu Marktanteilen von mobilen Browsern bzw. von Plattformen, die für das mobils browsing genutzt werden. Dabei scheint keine Statistik zuverlässig und aussagekräftig zu sein. Bei einigen ist es generell fragwürdig, wie die Daten erhoben wurden. Da keine repräsentative Statistik zu entsprechenden Marktanteilen vorgefunden wurde, wird in dieser Arbeit auf etwaige Grafiken und darauf basierende Aussagen verzichtet. 59 Vgl. Stand: Vgl. mspx, Stand: Vgl. Stand: Vgl. Stand: Vgl. Stand: Vgl. internet_appliances.html, Stand:

50 Kapitel 3 Mobile Betriebssysteme und Browser In diesem Kapitel wurde gezeigt, dass häufig ein Betriebssystem eng mit einem konkreten Endgerät zusammenhängt, nur die Linux-Distributionen mit ihren Endgeräten stellen da eine Ausnahme dar. Dieser Umstand erschwärt die Softwareentwicklung. Derzeit ist es nicht möglich eine Software für alle Endgeräte zu entwickeln, ohne Kompromisse einzugehen oder Mehrarbeit zu verursachen. Entweder man muss die Software an das konkrete Betriebssystem/Endgerät anpassen und ggf. mit unterschiedlichen Programmiersprachen arbeiten oder man nimmt in Kauf, dass sie nicht auf jedem Smartphone lauffähig ist. Das entwickelte Konzept für einen Location Based Service ist unabhängig von Betriebssystemen und Engeräten. Für den Prototypen musste allerdings eine Entscheidung getroffen werden (siehe Abschnitt 6). Nachdem die Kapitel 2 und 3 einen Einblick in die Hardware und grundlegende Software (Betriebssysteme und Browser) von Smartphones - im Kontext der Erstellnug eines Location Based Services - gewährten, wird sich das nächste Kaiptel mit der Kommunikation mobiler Endgeräte (Smartphones) mit dem Internet beschäftigen. Diese Kommunikation ist notwendig, um Daten, wie die Position des Nutzers und Informationen zu dieser Position, zwischen dem Endgerät und einem Server auszutauschen. 39

51 Kapitel 4 Kommunikation mobiler Endgeräte mit dem Internet Zu einem Location Based Service gehört neben dem mobilen Endgerät und seiner Positionsbestimmung auch die Kommunikation des Gerätes mit dem Internet. An dieser Kommunikation sind unterschiedliche Schichten beteiligt. Die Zusammenhänge der einzelnen technologischen Schichten (Übertragungstechnologien, Übertragungsprotokolle und Anwendungen sowie Endgeräte) lassen sich nach Steimer (vgl. [FLS01, Seite 28]) in einem hierarchischen Wirkungssystem darstellen. Die Abbildung 4.1 skizziert dieses Technologiemodell sowie die Beziehungen zwischen den einzelnen Schichten. 40

52 Kapitel 4 Kommunikation mobiler Endgeräte mit dem Internet Abbildung 4.1: Hierarchisches Wirkungssystem der mobilen Kommunikation [TC07] Im folgenden werden die unterschiedlichen Übertragungstechnologien vorgestellt. Durch die Verfügbarkeit der jeweiligen Funknetze und ihrer Bandbreiten sowie ihrer realen, physischen Dimension werden spätere Anwendungen begrenzt. Somit haben sie Einfluss auf Kosten und Erreichbarkeit des Benutzers. Deswegen wird zusätzlich die Netzabdeckung von unterschiedlichen Anbietern betrachtet. 4.1 Übertragungstechnologien Die mobilen Übertragungstechnologien lassen sich grundsätzlich in zwei Technologiefamilien unterteilen: Technologien aus dem Bereich der Mobiltelefonie und dem Bereich der Computernetze. Die hervorgegangenen Standards unterscheiden sich hin- 41

53 Kapitel 4 Kommunikation mobiler Endgeräte mit dem Internet sichtlich ihrer Leistung in Bezug auf Übertragungskapazitäten, Reichweite von Basisstationen, Datensicherheit und weiterer Kriterien. [TC07] Diese Faktoren sind beim Design von Interaktionen zu berücksichtigen GSM GSM ist ein Standard der zweiten Mobilfunkgeneration, der 1987 grundsätzlich definiert wurde und verschiedene überwiegend analoge Mobilfunkstandards der ersten Generation (in Deutschland: A-Netz, B-Netz und C-Netz) ablöste. GSM Handys verständigen sich untereinander in den Frequenzbändern um 900 und 1800 MHz (in den USA um 1900 MHz). Dualband-Handys wählen dabei automatisch jeweils die Frequenz mit der höheren freien Kapazität. Derzeit wird GSM von über zwei Milliarden Kunden genutzt (weltweit). Wie alle anderen mobilen Datenübertragungstechnologien setzt die Verwendung von GSM eine funkzellenbasierte Infrastruktur voraus, die durch GSM-Basisstationen gebildet werden. Innerhalb des GSM Standards wurde mit Circuit Switched Data (CSD) eine Datenübertragungstechnologie vorgesehen. Da bei diesem Standard für jede Kommunikationsverbindung exklusiv Bandbreite reserviert werden muss, erfolgt die Abrechnung zeitbasiert. Die heutigen GSM-Netze können Daten mit einer Leistung von 9,6 kbit/s mit Fehlerkorrektur oder 14,4 kbit/s ohne Fehlerkorrektur übermitteln (in einem GSM-Zeitschlitz). Das genügt lediglich für einfache s und Kurzmeldungen (SMS) HSCSD HSCSD ist eine Erweiterung des GSM-Mobilfunk-Standards CSD um schnellere Datenübertragung zu erreichen. Er funktioniert nach einem ähnlichen Prinzip wie eine ISDN-Leitung: mehrere GSM-Funkkanäle werden zu einem leistungsfähigen Datenkanal gebündelt (bis zu 12). Dadurch kann HSCSD eine theoretische Datenrate von bis zu 115,2 kbit/s erreichen. Unter realen Bedingungen sind jedoch nicht mehr als 57,6 kbit/s möglich (4 Kanäle mit je 14,4 kbit/s). HSCSD ermöglicht eine sogenannte transparente und non-transparente Datenübertragung. Bei der transparenten Übertragung wird die Fehlerkontrolle der Anwendung überlassen. Dies ermöglicht einen gleichmäßigen Datenstrom, was für Echtzeitanwendungen (wie z. B. Video-Übertragungen) notwendig ist. Kleine Fehler im Bild sind 42

54 Kapitel 4 Kommunikation mobiler Endgeräte mit dem Internet dabei nicht so störend, wodurch HSCSD besser für diese Art von Anwendungen geeignet ist, als GPRS. Bei der non-transparenten Datenübertragung übernimmt das Netz die Fehlerkorrektur. Dies wird beim Surfen und Mailen benutzt GPRS GPRS ist das erste Übertragungsverfahren, das eine paketorientierte Datenübertragung unterstützt. Die Abrechnung erfolgt dabei nicht nach Verbindungszeit, sondern nach Übertragungsvolumen. Dadurch kann eine dauerhafte Verbindung zwischen mobilem Endgerät und Netz aufrecht erhalten werden ( Always On ), ohne zusätzliche Kosten zu verursachen. Wenn GPRS aktiviert ist, besteht nur virtuell eine dauerhafte Verbindung zur Gegenstelle. Erst wenn wirklich Daten übertragen werden, wird der Funkraum besetzt, ansonsten ist er für andere Benutzer frei. Deshalb braucht kein Funkkanal dauerhaft (wie bei CSD) für einen Benutzer reserviert zu werden. GPRS eignet sich damit besonders gut für die Nutzung von Anwendungen mit schwankendem Kommunikationsbedarf (z. B. Lesen von s, Nutzung von WAP, Zugriff auf das Internet) (vgl. u. a. [Rot05, Seite 64f]). Die GPRS-Technik ermöglicht bei der Bündelung aller acht GSM-Zeitschlitze eines Kanals theoretisch eine Datenübertragungsrate von 171,2 kbit/s. Im praktischen Betrieb ist die Anzahl der nutzbaren Zeitschlitze innerhalb eines Rahmens jedoch durch die Fähigkeit der Mobilstation (multislot capability) und der Netze begrenzt. Am Markt befinden sich (Stand 2008) Geräte der Multislot Class 12 mit maximal je vier Zeitschlitzen im Downlink und im Uplink (jedoch gleichzeitig maximal 5 Zeitschlitze). Die damit erreichbare Datenübertragungsrate beträgt abhängig vom verwendeten Coding Scheme (hängt ab vom Signal und Rauschverhältnis) und der von der Netzauslastung abhängigen Anzahl der zugeteilten Zeitschlitze (Timeslots) bis zu 55,6 kbit/s. Dies entspricht in etwa der Geschwindigkeit eines V.90-Telefonmodems EDGE EDGE 1 ist ein weiteres Verfahren zur Steigerung der Datenrate, das ähnlich wie HSCSD ein neues Modulationsverfahren einsetzt und weitestgehend die bestehende Infrastruktur von GPRS benutzt. Mit EDGE werden die Datendienste GPRS zu 1 Vgl. Stand:

55 Kapitel 4 Kommunikation mobiler Endgeräte mit dem Internet E-GPRS (Enhanced GPRS) und HSCSD zu ECSD erweitert. EDGE wird als ein Zwischenschritt auf dem Weg hin zu UMTS angesehen, in ländlichen Gebieten mittelfristig auch als UMTS-Ersatz, und wurde bisher in 75 Ländern eingeführt. Die Steigerung der Datenübertragungsrate bei EDGE wird erreicht durch einen Wechsel hin zu einem effizienteren Modulationsverfahren. Dabei kommt anstatt des beim GSM-Standard üblichen Gaussian Minimum Shift Keying-Verfahrens (GMSK) das sogenannte 8-PSK-Verfahren zum Einsatz. Hierdurch wird bei EDGE eine Datenübertragungsrate von bis zu 59,2 kbit/s pro Kanal ermöglicht. Bei Verwendung von acht Kanälen werden bis zu 473 kbit/s erreicht. Der Wechsel des Modulationsverfahrens erfolgt selektiv nur auf den Kanälen, die von EDGE-fähigen Geräten belegt werden. Dadurch ist eine gleichzeitige störungsfreie Nutzung von GSM/GPRS- und EDGE-fähigen Endgeräten in derselben Funkzelle möglich. Die derzeit marktüblichen Endgeräte gehören zur EDGE-Klasse 10. Dies bedeutet, dass diese Geräte über maximal vier Downlink-Slots sowie zwei Uplink-Slots verfügen. Hieraus resultiert eine mögliche Datenübertragungsrate von 220 kbit/s im Download und 110 kbit/s im Upload UMTS UMTS ist der Europäische Mobilfunkstandard der dritten Generation (3G) und wird allgemein als der Nachfolgestandard für die aktuellen GSM-Netze zur Mobiltelefonie angesehen. Dieser Standard wurde mit dem Ziel entwickelt, ein weltweit einheitliches Mobilfunknetz zu schaffen und einen Standard zu definieren, der den Anforderungen zukünftiger mobiler Anwendungen gerecht wird und neben höheren Datenraten auch paketvermittelte Übertragungen ermöglicht. Zur Nutzung von UMTS wird ein spezielles mobiles Endgerät benötigt sowie ein UMTS Subscriber Identity Module (USIM), das eine höhere Speicherkapazität als die herkömmliche SIM bietet. [TC07] Mit UMTS sind deutlich höhere Datenübertragungsraten (bis zu 7,2 Mbit/s) als mit dem Mobilfunkstandard der zweiten Generation (2G), dem GSM-Standard (bis zu 220 kbit/s), möglich. Der Standard wird ständig erweitert, beispielsweise erhöhte HSDPA die maximal mögliche Empfangs-Datenrate (Downlink); für die Sende-Datenrate ist mit HSUPA eine vergleichbare Technik verfügbar. HSDPA 2 ermöglicht DSL-ähnliche Datenübertragungsraten im Mobilfunknetz (abhängig 2 Vgl. Stand:

56 Kapitel 4 Kommunikation mobiler Endgeräte mit dem Internet von der Qualität der Funkverbindung 3,6 Mbit/s bis 13,98 Mbit/s) und macht damit das Herunterladen von großen Datenmengen (etwa Spielen, Filmen, etc.) ohne Kabeloder WLAN-Verbindung möglich. Die maximale Datenrate ist von der Kategorie des Empfängers beschränkt. Typisch sind 3,6 Mbit/s (Kategorie 6) und 7,2 MBit/s (Kategorie 8), was mit der Verbindungsgeschwindigkeit von DSL im Festnetz vergleichbar ist. Die mit Kategorie 14 maximal mögliche Datenrate von 13,98 MBit/s ist im Feld allerdings kaum erreichbar, da sie eine Koderate von 1 erfordert. Ein wesentliches Merkmal von HSDPA ist schnelles und flexibles Scheduling, wodurch Datenlast effizient verteilt und Kanalkodierung sowie Modulationsverfahren an die Signalqualität angepasst werden können. HSUPA 3 ist ein Übertragungsverfahren des Mobilfunkstandards UMTS, das höhere Datenübertragungsraten im Uplink ermöglicht und die Roundtrip-Zeiten (oft als Ping bezeichnet) verkürzt. Mit HSUPA konnten bis zu 5,8 Mbit/s erreicht werden. HSUPA ist Teil des Release 6 von UMTS. HSDPA und HSUPA sind - abhängig vom jeweiligen Mobilfunkbetreiber - nicht überall in Deutschland verfügbar (sieht... ). Sollte ein UMTS-fähiges Mobilgerät kein UMTS-Netz vorfinden, so versucht es eine andere, nicht ganz so leistungsfähige Übertragungtechnologie zu verwenden WLAN Als vierte Generation (4G) der Mobilfunknetze wird die Integration drahtloser LAN und WAN- Netze in die Mobilfunkinfrastruktur gesehen. Der Vorteil eines solchen hybriden Netzes ist die signifikant weit höhere Übertragungsrate, die aus einem geringeren Radius der Netze und einem effizienteren Modulationsverfahren resultiert. Beispiele hierfür sind der WLAN-Standard IEE , der je nach Ausführung zwischen 11 und 108 MBits/s übertragen kann sowie IEEE e-2004 (WiMAX), das eine Übertragungsrate von bis zu 4 MBits/s pro Endgerät ermöglicht. Es wird erwartet, dass 4G sich erst ab 2010 etablieren. [TC07] Der Nachteil dieser Übertragunstechnologie ist ihre Verbreitung. Es stehen nicht flächendecken Hot Spots zur Verfügung, um eine Verbindung mit dem Internet aufzubauen. Sie finden sich häufig nur an öffentlichen Knotenpunkten wie Hotels, Restaurants, Flughäfen und Bahnhöfen zu finden und sind meistens kostenpflichtig. Darin 3 Vgl. Stand:

57 Kapitel 4 Kommunikation mobiler Endgeräte mit dem Internet unterscheidet sich die vierte von der dritten Generation, welche in naher Zukunft eine flächendeckende und nicht zusätzlich kostenpflichtige Verbreitung erreichen wird Ausbaustadien der Netzbetreiber Neben der Datenrate ist auch die Verfügbarkeit ein wichitger Faktor, denn die hohen HSDPA-Übertragungsraten können nur genutzt werden, wenn ein UMTS-Netz auch verfügbar ist. In Deutschland ist die Netzabdeckung vom jeweiligen Netzbetreiber abhängig. 4 Grundsätzlich ist festzustellen, dass alle Netzbetreiber UMTS nur in größeren Städten ausgebaut haben, auf dem Land sucht man das neue Netz mitunter vergebens. T-Mobile hat nach eigenen Angaben flächendeckend EDGE und bietet darüber hinaus HSDPA mit 3,6 sowie HSUPA mit 1,4 Megabit pro Sekunde im gesamten UMTS-Netz an. An mehr als 1000 Standorten soll HSDPA Download-Raten von 7,2 Megabit pro Sekunde ermöglichen, HSUPA mit zwei Megabit pro Sekunde sei an vielen Standorten verfügbar. Bis 2010 soll das gesamte UMTS-Netz auf HSDPA mit 7,2 und HSPUA mit zwei Megabit pro Sekunde aufgerüstet sein. Vodafone gibt diesbezüglich an, mit über Standorten das schnelle Internet zu offerieren, was mehr als 80 Prozent der Bevölkerung entspreche. Dies bezieht sich auf HSDPA mit 3,6 und HSUPA mit 1,45 Megabit pro Sekunde. In 650 Regionen sei HSDPA mit 7,2 Megabit pro Sekunde verfügbar. Überall, wo noch nicht auf HSDPA aufgerüstet worden sei, werde EDGE angeboten. E-Plus will nach eigenen Aussagen bis Ende 2009 die EDGE-Versorgung auf über 90 Prozent der Bevölkerung aufstocken. Mit UMTS erreiche man derzeit rund 65 Prozent der Bevölkerung. HSDPA mit 3,6 Megabit pro Sekunde werde in ausgewählten Bereichen verfügbar sein; welche dies sind, wollte E-Plus nicht näher präzisieren. O 2 deckt nach eigenem Bekunden derzeit mit UMTS rund 65 Prozent der Bevölkerung ab. Im gesamten UMTS-Netz werde HSDPA mit 3,6 Megabit pro Sekunde unterstützt. HSDPA mit 7,2 Megabit befinde sich im Ausbau; in Citylagen, an Flughäfen und ähnlichen Hot Spotsßtehe diese Datenrate bereits jetzt zur Verfügung. In Gebieten, in denen kein HSDPA respektive UMTS geplant ist, biete man EDGE an. 4 Vgl. kaufberatung-uebertragungstechnologien-gsm-umts-und-co-_aid_ html, Stand:

58 Kapitel 4 Kommunikation mobiler Endgeräte mit dem Internet HSUPA mit zwei Megabit pro Sekunde sei derzeit in weiten Teilen Süddeutschlands verfügbar, der bundesweite Ausbau solle bis Ende des Jahres abgeschlossen sein. Abschließend stellt sich die Frage, an welcher Übertragungstechnologien man sich bei der Entwicklung des Location Based Services orientieren sollte? UMTS (HSD- PA/HSUPA) ist zwar vielerorts verfügbar, aber selbst in Großstädten gibt es viele Plätze, an denen kein UMTS vom mobilen Endgerät gefunden wird. Deswegen sollte man sich an GPRS orientieren und beachten, dass bei der Kommunikation mit dem Server nicht zu große Daten gesendet und empfangen werden müssen. Das würde die Anwendung verlangsamen und unter Umständen dazu führen, dass sie nicht genutzt wird. Zu den technischen Voraussetzungen im Bereich der mobilen Endgeräte (Hardware und Software) wurden jetzt auch die kommunikationstechnischen Voraussetzungen zwischen Smartphone und Internet ermittelt, damit der mobile Client mit dem Webserver Daten austauschen kann. Hierfür sind die vorgestellten Übertragungstechnologien maßgeblich. Somit fehlt noch die Positionsbestimmung als Grundlage für den Location Based Service des virtuellen Museums. Außerdem wird sich das folgende Kapitel grundsätzlich mit Location Based Services und ihrer Anwendungslogik beschäftigen. 47

59 Kapitel 5 Location Based Service In diesem Kapitel wird geklärt, was sich hinter einem Location Based Service verbirgt, wie die Position eines mobilen Endgerätes ermittelt werden kann und wie mögliche Point of Interest auf dem Server gesichert werden können. 5.1 Location Based Service Die GSM Association definiert einen Location Based Service als einen Dienst, der dem Nutzer personalisierte Services abhängig von seiner Position anbietet.[ham08] Solche Dienste können nach Symbian grob in 3 Kategorien geteilt werden: öffentliche Sicherheit, Konsumenten Services und Unternehmens Services (siehe Abbildung 5.1). Abbildung 5.1: Kategorien von Location Based Services 48

60 Kapitel 5 Location Based Service Eine zentrale Eigenschaft dieser Services ist ihre Context Awareness. Context Awareness bezeichnet die Fähigkeit eines Systems, den Kontext einer Person oder eines Gerätes zu erkennen und auszunutzen. Damit kann ein Gerät auf unterschiedliche Kontexte reagieren. Bei der Entwicklung von Location Based Services spricht man auch von Location-Aware Computing, da hier die Lokalisierung und damit der Orts- Kontext im Mittelpunkt steht Lokalisierung Im folgenden werden unterschiedliche Lokalisierungstechniken vorgestellt. Die Genauigkeit bei der Positionsbestimmung eines mobilen Endgeräts hängt von der verwendeten Lokalisierungstechnik ab, welche wiederum von weiteren Faktoren abhängig ist: erforderte QoS Leistungsfähigkeit des Netzes Leistungsfähigkeit des mobilen Endgeräts Bei der Lokalisierung wird zwischen Zellenbasierten Systemen und Satellitengestützten Systemen unterschieden. Zellenbasierte Systeme Um eine Lokalisierung von mobilen Endgeräten über ein Mobilfunknetz durchzuführen, verfügt jede Vermittlungsstelle MSC über ein Register VLR. In diesem Register werden alle mobilen Teilnehmer aufgelistet, die sich aktuell in den zugeordneten Zellen aufhalten. Jede Zelle wird durch eine eindeutige Nummer identifiziert, die auch als Cell ID bezeichnet wird. Ein eingeschaltetes Mobiltelefon ist immer genau einer Zelle zugeordnet und kann somit eindeutig identifiziert werden. Cell ID Wie eben beschrieben, wird die Position des Mobilfunkgerätes über dessen Cell ID ermittelt. Dies ist sowohl der einfachste, als auch der günstigste Weg, um eine Position zu bestimmten. Alle Mobilfunktelefone können mit dieser Technik lokalisiert werden, ohne das Veränderungen an den Geräten vorgenommen werden müssen oder eine bestimmte Hardware erforderlich ist. Die Genauigkeit dieser Lokalisierungstechnik hängt von den Zellgrößen ab, welche von 0,5 km in Stadtgebieten bis hin zu 35 49

61 Kapitel 5 Location Based Service km in ländlichen Gebiten schwanken können. Außerdem ist die Zellgröße vom Mobilfunknetz abhängig, mit dem das Gerät verbunden ist. UMTS weist eine kleinere Zellgröße auf, als das Standard GSM-Netz.[Ham08] Cell ID mit TA TA steht für Timing Advance und bezeichnet die Zeit, die ein Signal benötigt, um vom Mobiltelefon aus die Basisstation zu erreichen, mit der es verbunden ist. Diese Technik kann in Verbindung mit der Cell ID-Methode eine größere Genauigkeit bei der Lokalisierung ergeben. Die TA-Methode ergibt einen Kreisbogen, in dem sich das mobile Engerät befindet. Bei sektorierten Zellen kann die Position des Gerätes auf einen bestimmten Sektor oder eine bestimmte Region in der Zelle verringert werden. Die Genauigkeit dieser Methode liegt bei ca. 0,5 km bis 2 km.[ham08] Cell ID mit NMR Diese Methode verwendet sogenannte Network Measurement Reports. Hierbei handelt es sich um Messungen der Signalstärke von der Zelle in der sich das Mobilfunkgerät befindet und den Nachbarzellen. Das Gerät kann dann am Schnittpunkt der Kreise, welche von den Signalstärkemessungen definiert werden, lokalisiert werden. Diese Methode kann die Genauigkeit der Cell ID mit TA Methode um weitere 25% erhöhen.[ham08] Enhanced Observed Time Difference (E-OTD) Ein E-OTD-fähiges Mobilfunkgerät misst die Zeitdifferenz zwischen Signalen benachbarter Basisstationen. Diese wird benötigt, um die Position des Gerätes im Verhältnis zu den Basisstationen zu berechnen. Damit diese Methode verwendet werden kann, müssen die Positionen der Basisstationen bekannt sein. Die Genauigkeit dieser Methode wird mit 100 bis 300 Metern angegeben.[ham08] Time Difference of Arrival (TDOA) Bei der TDOA Methode wird die exakte Zeit gemessen, die das Signal des mobilen Endgeräts benötigt, um an drei oder mehr sogenannten Location Measurement Units (LMUs) anzukommen. Hiefür müssen die LMUs feste und bekannte Positionen haben, damit die Ankunftszeit (Time of Arrival (TOA)) der Signale genau gemessen werden kann. Die Position des Mobilfunkgeräts kann dann mittels Triangulierungsverfahren (Lateration) berechnet werden. Diese Methode funktioniert mit jedem mobilen Endgerät und erfordert nur Veränderungen am Mobilfunknetz. Die Genauigkeit beträgt 50 bis 150 Meter.[Ham08] 50

62 Kapitel 5 Location Based Service Satellitengestützten Systeme Eine andere grundlegende Kategorie zur Lokalisierung benutzt Satelliten zur Positionsbestimmung. Ist die Position mehrerer Satelliten und der Abstand zu ihnen zu einem bestimmten Zeitpunkt bekannt, lässt sich die Position äußerst präzise bestimmen. Einer der weiteren Vorteile der satellitengestützten Lokalisierungssysteme ist die breite Verfügbarkeit [Fle04]. Nachteilig ist, dass die Lokalisierung abhängig von einer Sichtverbindung zu den Satelliten ist. Aus diesem Grund scheidet die Technik für die Lokalisierung innerhalb von Gebäuden (auch als Indoor-Lokalisierung bezeichnet) aus.[lan05] Standalone Global Positioning System (GPS) Diese Methode wurde ursprünglich für das Verteidigungsministerium der Vereinigten Staaten von Amerika entwickelt, kann aber mittlerweile kommerziell genutzt werden. GPS setzt sich aus 24 stationären Satelliten zusammen, die auf 6 Umlaufbahnen die Erde umkreisen. Jeder dieser Satelliten sendet Signale, aus denen ein GPS Empfänger seine Position, Richtung und Geschwindigkeit berechnen kann. Für eine Berechnung, die Minuten dauern kann, benötigt ein GPS Empfänger die Signale von 3-4 Satelliten. Die Genauigkeit dieser Methode liegt bei 10 bis 100 m.[ham08] Bei diesem Verfahren kommt es zu Laufzeitfehlern (bei 3 Satelliten), deren Auswirkungen durch zusätzliche Berechnungen reduziert werden können. Hierfür ist allerdings ein vierter Fixpunkt (Satellit) nötig. Die Lokalisierung mit Hilfe mindestens 4 Satelliten erreicht die größte Genauigkeit. Assisted GPS (A-GPS) Bei dieser Methode bestimmt das mobile Endgerät seine Position über die erhaltenen GPS Signale und unterstützende (assisted) Daten vom Mobilfunknetz. Diese zusätzlichen Daten entahlten eine Liste mit Satelliten, die in Sichtweite des Mobilfunkgerätes sein müssen. Hierbei wird von der jeweiligen Basisstation ausgegangen, mit der das Gerät verbunden ist. Somit wird der Suchbereich für die Satellitensignale eingeschränkt, um die Messung zu beschleunigen. Diese Informationen geben A-GPS einen merklichen Vorteil gegenüber dem Standalone GPS: Schnellere Time To First Fix (TTFF) - Positionsbestimmung innerhalb von Sekunden Erhöhte Empfindlichkeit - besser Abdeckung gegenüber Standalone GPS (teilweise sogar in Gebäude nutzbar) 51

63 Kapitel 5 Location Based Service Geringerer Energiebedarf - der GPS Empfänger muss nicht permanent den Himmel nach GPS Satelliten absuchen Weniger Satelliten werden benötigt - die Informationen über die Position im Netz werden verwendet, um fehlende Satelliteninformationen zu kompensieren A-GPS erreicht eine Genaugkeit von 5 bis 10 Metern.[Ham08] Zugriff auf Lokalisierungsdaten Nachdem die unterschiedlichen Verfahren zur Lokalisierung vorgestellt wurden, ist es nun von Interesse, wie eine Anwendung auf jene Daten zugreifen kann, um diese zu verwenden. In diesem Abschnitt wird lediglich der Zugriff auf GPS-Daten betrachtet, da alle anderen Verfahren zu ungenau sind. Dies setzt voraus, dass das mobile Endgerät über einen GPS-Empfänger verfügt oder bspw. mittels Bluetooth mit einem externen Empfänger verbunden werden kann. Außerdem wird vorausgesetzt, dass Java auf dem Mobiltelefon verfügbar ist. Im Vergleich zu allen anderen Möglichkeiten werden hier nur ältere Mobiltelefone und das iphone ausgeschlossen. Bei allen Herstellern, mit Ausnahme von Apple, gehört Java heutzutage zur Standardausstattung von Smartphones. Um auf die empfangenen GPS-Daten zugreifen zu können, wird die Java Location API (JSR 179) 1 verwendet. Diese ist ein optionales Paket, welches im Rahmen des Java Community Prozesses (JCP) als Java Specification Request (JSR) 179 definiert wurde. Um die API verwenden zu können, ist entweder die Connected Device Configuration (CDC) oder die Version 1.1 der Connected Limited Device Configuration (CLDC) erforderlich. Als Teil der Mobilen Service Architektur (MSA)-Spezifikation muss das Location API von einem MSA-Gerät unterstützt werden, welches einen GPS-Empfänger enthält oder welches mit anderen Methoden Lokalisierungsinformation über ein API anbietet. Das Java Location API besteht aus zwei Schnittstellen und 11 Klassen (davon zwei Exception Klassen). Mit der Methode LocationProvider.getInstance() wird eine Lokalisierungsmethode angefordert. Als Parameter können Kriterien definiert werden, die von der Lokalisierungsmethode erfüllt werden müssen. Die Kriterien spezifizieren z. B. die Genauigkeit der Lokalisierungsmethode, eine maximale Antwortzeit oder 1 Vgl. Stand:

64 Kapitel 5 Location Based Service eine Angabe über den erlaubten Stromverbrauch. Das Location API wird von den Geräteherstellern implementiert. Diese entscheiden damit, welche Lokalisierungsmethoden sie bereitstellen. Das Location API erlaubt jedoch nicht abzufragen, welche Methoden unterstützt werden (und welche Kriterien diese noch erfüllen können). Bei der Loaklisierung mittels GPS können sogenannte NMEA (National Marine Electronics Association) Daten ausgelesen und geparst werden. Beim NMEA- Protokoll gibt es verschiedene Datensätze. Ein Beispieldatensatz (GPRMC - Recommended Minimum Sentence C) könnte wie folgt aussehen 2 : Abbildung 5.2: GPRMC Datensatz im NMEA-Protokoll Mit der Methode Location.getQualifiedCoordinates() wird der Zugriff auf die Koordinaten im GPRMC-Datensatz erleichtert. Diese können dann mit jeweils einer weiteren Methode direkt ausgelsen werden. Somit liegt die aktuelle Position des mobilen Endgerätes vor. Eine konkrete Umsetzung dieser Methoden war für das Kapitel 6.3 vorgesehen. Allerdings stellten sich bei der Entwicklung des Prototypen Probleme ein, die das verhinderten. Darauf wird auch im anschließenden Kapitel eingegangen. 2 Vgl. Stand:

65 Kapitel 5 Location Based Service 5.2 Point of Interest Neben der eigenen Position ist es für den LBS des virtuellen Museums des Kölner Sports notwendig, dass alle interessanten Orte (POI) und Daten (Texte, Bilder, Audio, Video) zu diesen Orten in einer Datenbank hinterlegt sind und diese Datenbank um zusätzliche Daten erweitern werden kann. Im Folgenden werden diese interessanten Orte hinsichtlich ihrer Datenhaltung genauer betrachtet. Es wird also untersucht, welche Daten zu einem bestimmten Ort gespeichert werden und in welcher Form diese vorliegen sollten. Nach einem allgemeinen Zugang wird im Bereich des Geo-Taggings dieser Frage nachgegangen Was sind POI? Point of Interest (POI) sind Orte, die für einen Nutzer eines Navigationssystems oder einer Karte von Interesse sind. Hierbei kann es sich um unterschiedliche Arten von interessanten Punkten handeln. Denn das Interesse an diesen Orten kann zum Beispiel der Befriedigung eines täglichen Bedarfs genügen (nächste Geldautomat, Poststelle). Es kann sich auch um Anlaufstellen in Notfällen (Notapotheke, umliegende Ärzte) handeln oder schlicht reisspezifischen Bedürfnissen entsprechen (Sehenswürdigkeiten, Unterkünfte). Im Bereich der Navigationssysteme und Routenplaner existieren unterschiedliche Dateinformate, um diese POI zu sichern. Dies läßt sich auf unterschiedliche Gründe zurückzuführen und ist im wesentlichen dem Fehlen eines einheitlichen Standards zu schulden. Es gibt mit dem GPS Exchange Format (GPX) 3 einen Versuch, ein offenes, lizenzfreies Datenformat zur Speicherung von Geodaten zu etablieren. Es basiert auf dem allgmeinen XML-Standard und erleichtert den Austausch von Geodaten zwischen verschiedenen Programmen. Für das Design der Datenbank ist GPX weniger wichtig, jedoch sollte es für spätere Anwendungsfälle, wie dem Datenaustausch mit Navigationsgeräten, berücksichtigt werden Geo-Tagging Um einen geeigneten Aufbau der POI-Datenbank zu entwickeln, wird in diesem Abschnitt das Geo-Tagging genauer betrachtet. 3 Vgl. Stand:

66 Kapitel 5 Location Based Service Unter Geo-Tagging oder auch Georeferenzierung wird das Zuweisen von raumbezogenen Referenzinformationen zu einem Datensatz verstanden. Dieser Vorgang wird vor allem in Geoinformationssystemen eingesetzt. Es werden mehrere Arten des Geo- Taggings unterschieden, wobei besonders das sogenannte Geo-Imaging für den zu entwickelnden Service interessant ist. Hierbei wird ein Photo mit geographischen Koordinaten angereichert. Dieses Vorgehen lässt sich auch auf andere Medien übertragen und ist nicht allein auf Photos beschränkt. Häufig werden die raumbezogenen Daten direkt bei der Aufnahme eines Photos ermittelt. Sie können allerdings auch nachträglich mit Hilfe eines GPS-Empfängers oder eines Services wie Google Maps 4 und OpenStreetMap 5 bestimmt und einem Photo bzw. Medium zugewiesen werden. Für den LBS des virtuellen Museums sind beide Vorgehensweisen wichtig, da zum Einen die bestehenden Medien in der Datenbank um Rauminformationen angereichert werden müssen, damit Nutzer diese an einem entsprechenden Ort mit ihrem Smartphone abrufen können. Zum Anderen sollen die Nutzer des LBS Medien zu einem bestimmten Ort hochladen können und diese automatisch mit ihren aktuellen Positionsdaten versehen. Empfohlene Felder für die Sicherung in einer Datenbank Neben den Positionsdaten (Längengrad, Breitengrad) sollten auch andere Metadaten zu einem georeferenzierten Medium gespeichert werden. Hierzu gehören Angaben wie: Autor Titel Beschreibung Art des Mediums Datum Uhrzeit Link zum Medium Link zur Vorschau des Mediums Außerdem sollten zu jedem ortsbezogenen Medium Annotationen gesichert werden. Diese können zum Beispiel in Form von einzelnen Begriffen (so genannten Tags) erfasst werden. Diese Annotationen haben den Zweck das Medium und die darin ent- 4 Vgl. Stand: Vgl. Stand:

67 Kapitel 5 Location Based Service haltenen Daten näher zu beschreiben. Da es für Computer nach wie vor zu schwierig ist den Inhalt eines Mediums zu erkennen und von sich aus zu beschreiben, ist eine Unterstützung durch den Menschden notwendig. Diese Daten müssen in einer Datenbank auf dem Server gehalten werden. Die Verwendung solcher Metadaten legt den Einsatz von RDF nahe. Im Rahmen dieser Arbeit, die sich mit den Voraussetzungen und einem ersten Prototypen eines Location Based Services beschäftigt, würde eine Betrachtung dieses Frameworks zu weit führen. Es empfiehlt sich allerding in einer weiteren Arbeit darauf einzugehen und den Einsatz im virtuellen Museum zu erwägen. Es wurden nun alle technsichen, kommunikativen und logischen Voraussetzungen betrachtet. Damit kann im anschließenden Kapitel ein Konzept vorgestellt werden. 56

68 Kapitel 6 Konzept eines Location Based Services In diesem Kapitel stelle ich mein grundlegendes Konzept für den Location Based Service (LBS) vor. Dessen Aufbau, die verwendeten Komponenten und sein Ablauf sind in der Abbildung 6.1 zu erkennen. Abbildung 6.1: Ablauf dieses Location Based Services Wie in den vorigen Kapiteln bereits besprochen, beschränkt sich dieser LBS auf Smartphones. Für die Entwicklung und das Testen eines Prototyps stand ein XDA Touch Diamond von HTC (ROM: GER) mit Windows Mobile 6.1 zur Verfügung. Die Entwicklung sollte mit J2ME erfolgen, damit der LBS neben Windows Mobile auch auf anderen mobilen Betriebssystemen verfügbar wäre. Für die nötige Positionsbestimmung sollte die Java Location API verwendet werden. Auf dem verwendeten HTC Smartphone mit dem Windows Mobile 6.1 Betriebssystem wurde diese Bibliothek allerdings nicht von der Java VM unterstützt. Eine Recherche zu diesem Problem 57

69 Kapitel 6 Konzept eines Location Based Services ergab, dass es vom Gerätehersteller abhängig ist, ob die Location API von der jeweiligen Java VM unterstützt wird. Dieses Problem zeigte, dass in diesem konkreten Anwendungsbereich die betriebssystemübergreifende Verfügbarkeit nicht allein vom Betriebssystem abhängt, sondern auch von der Unterstützung der nötigen Funktionen und Bibliotheken. Es gibt vermutlich Workarounds, die jenes Problem umgehen und die Verwendung der Location API ermöglich. Allerdings schien dies für den Prototypen im Kontext dieser Arbeit zu aufwändig, weswegen der Prototyp nicht mit J2ME entwickelt wurde, sondern klassich für Windows Mobile Anwendungen: mit C#. Damit ist der entwickelte Prototyp nicht auf jedem Betriebssystem einsetzbar. Das Ziel der Quasie-Plattformunabhängigkeit konnte also nicht erreicht werden und es empfiehlt sich damit, für jedes mobile Betriebssystem eine eigene Version des LBS zu entwickeln. Der Prototyp setzt die Kernfunktionen (Positionsbestimmung und Client-Server- Kommunikation) um. Aus diesem Grund wurde er so knapp wie möglich gestaltet. Welche Funktionen über diesen Prototyp hinaus für den LBS des virtuellen Museums als sinnvoll erscheinen, wurde im Kapitel erfasst. 6.1 Positionsbestimmung Das Prinzip der Positionsbestimmung bei Smartphones mit GPS Empfänger wurde im Kapitel bereits vorgestellt, auch wenn dort von der Verwendung der Location API ausgegangen wurde. Dieses Prinzip gilt aber auch für die Location Bibliothek von Windows Mobile, wie das Kapitel zeigen wird. Aus diesem Grund wird nicht noch einmal darauf eingegangen, sondern gleich die Kommunikation zwischen mobilem Client und einem Server betrachtet. 6.2 Kommunikation Die Abbildung 6.2 zeigt ein Modell der Kommunikation eines mobilen Clients mit einem Server. An dieser Stelle wird nicht weiter auf die Grundlagen von verteilten Systemen so wie den Unterschied zwischen synchroner und asynchroner Kommunikation eingegangen. 1 1 Weiterführende Literatur: Verteilte Systeme: Prinzipien und Paradigmen, Tanenbaum, Steen, Stand: 2007 [AST07] 58

70 Kapitel 6 Konzept eines Location Based Services Abbildung 6.2: Ablauf einer mobilen Client Server Kommunikation Im Kontext dieser Arbeit ist es viel mehr wichtig zu prüfen, welche Wege es gibt, um die ermittelten Positionsdaten an einen Server zu senden, um darauf POIs von diesem zu erhalten. Windows Mobile Anwendungen stehen hierfür mehrere Möglichkeiten zur Verfügung, um Daten mit einem Server auszutauschen Socket Sockets sind bidirektionale Kommunikationspunkte, über die Daten gesendet und empfangen werden können. Bevor Daten übertragen werden, müssen sowohl der Client als auch der Server einen Socket anlegen und diese verbinden. Die jeweiligen Sockets setzen sich aus einer IP-Adresse und einer Protnummer zusammen. Neben den Daten der Kommunikationspunkte müssen auch das gewünsche Adressierungsschema, die Socket-Art und das Übertragungsprotokoll für jeden Socket angegeben werden. Sobald eine Verbindung hergestellt wurde, können der Client und der Server direkt miteinander mittels Send und Receive kommunizieren. Neben der Möglichkeit Daten direkt zwischen den Sockets zu senden und zu empfangen, können sie auch über einen Datenstrom (NetworkStream) gelesen und geschrieben werden. Der NetworkStream übernimmt als Datenquelle ein Socket-Objekt, auf dem dann alle Lese- und Schreibvorgänge durchgeführt werden. Somit kann vermieden 59

71 Kapitel 6 Konzept eines Location Based Services werden mit byte-arrays zu arbeiten. [WB06] Web-Service - SOAP Web-Services sind heterogene verteilte Dienste, die in einer beliebigen Anwendung benutzt werden können. Dafür wird die bestehende Infrastruktur des Internets (z.b. HTTP, SMTP, Webserer) für den Transport von Daten und XML für die Beschreibung der transportierten Daten verwendet. Diese Web-Services können unabhängig von Betriebssystem, Programmiersprache und binärem Übertragungsprotokoll erstellt und verwendet werden. Für die Kommunikation wird ein XML-basiertes Protokoll namens SOAP verwendet. Es besteht auf kein eigenes verteiltes Objektmodell, sondern unterstützt beliebige in XML beschriebene Datenstrukturen. SOAP-Aufrufe sind im Prinzip nur Textdateien, die zwischen einem Client und einem Server verschickt werden. Somit kann die bereits bestehende Netzwerkinfrastruktur verwendet werden. Zuerst muss der serverseitige Web-Service entwickelt werden, der später über einen URI erreichbar sein wird. Zusätzlich muss dessen Funktionalität in WSDL beschrieben werden. Anschließend muss ein.net-client entwickelt werden, welcher auf die URI der WSDL-Beschreibung des Web-Services zugreift, um daraus Proxies zu bilden. Diese dienen als Platzhalter bzw. Stellvertreter für den entfernten Web-Service. Sie stellen die in WSDL beschriebene Funktionalität des Web-Services als.net-klasse dar, führen die Umwandlung der.net-datentypen in XML-Daten durch und initiieren den Aufruf der Web-Service-Methoden über das Netz. Des Weiteren muss der Web-Service in der Datei Web.config konfiguriert werden. [WB06] WebRequests und WebResponse Die Kommunikation über Sockets erfordert zahlreiche Detailoperationen. Die Kommunikation mittels Web-Services bringt einen gewissen Aufwand bei der Einrichtung des Services mit sich, dessen Zweckmäßigkeit zumindest bei einfach Operationen in Frage gestellt werden kann und sollte. Das.Net-Framework bietet aber auch Kommunikationsklassen auf höherer Ebene, mit denen gängige Protokolle wie oder file:// bequem genutzt werden können. 60

72 Kapitel 6 Konzept eines Location Based Services Grundlage für diese Art von Kommunikation sind die abstrakten Klassen WebRequest und WebResponse, die den Zugriff auf Web-Ressourcen (im Allgemeinen Dateien) mittels eines Request/Response-Protokolls erlauben. Der Client schickt dabei dem Server eine Anforderung (Request) und der Server schickt als Antwort (Response) die gewünschte Web-Ressource zurück. Der Request richtet sich an einen URI und kann über die Methoden GET oder POST erfolgen. Als Antwort erhält man ein WebResponse-Objekt, welches, je nach verwendeten Protokoll, vom Typ HttpWebResponse oder FileWebResponse sein kann. Das empfangene Response-Objekt kann über seine Properties ausgewertet werden. Den Antwortstrom (z.b. Inhalt einer HTML-Datei) kann man mit einer Methode abrufen und verarbeiten. [WB06] Somit ist es möglich, mit wenig Aufwand und einfachen Mitteln eine Client-Server- Kommunikation aufzubauen und Daten zu übertragen. Für den Prototypen, der neben der Positionsbestimmung (6.3.1) auch eine Client- Server-Kommunikation (6.3.2) demonstrieren soll, wurden WebRequest und WebResponse verwendet, um mit wenigen Mitteln (Quellcode) einen Datenaustausch zu ermöglich. Da zu Testzwecken nur wenige, einfache Daten übertragen werden sollten, empfahl sich diese Umsetzung. Wenn im weiteren Verlauf des Projektes komplexere Daten ausgetauscht werden müssen, sollte eine Umsetzung mit Web-Services erwogen werden. Nachfolgend wird der entwickelte Prototyp vorgestellt. 6.3 Prototyp In diesem Abschnitt stelle ich zuerst den C#-Quellcode der.net-anwendung, der für die Positionsbestimmung und die Client-Server-Kommunikation nötig ist, vor. Desweiteren zeige ich die ausgeführte Anwendung auf einem HTC Smartphone, um zum Schluss auf die gesammelten Erkenntnisse und weitere mögliche Funktionen einzugehen Positionsbestimmung Um die Position mit Hilfe eines GPS Empfängers zu bestimmen, ist es nötig ein Objekt vom Typ Gps zu erzeugen (siehe Quellcode 6.1). Außerdem werden ein paar 61

73 Kapitel 6 Konzept eines Location Based Services Variablen deklariert, die später verwendet werden. 1 p r i v a t e EventHandler updatedatahandler ; 2 p r i v a t e GpsDeviceState d e v i c e = n u l l ; 3 p r i v a t e GpsPosition p o s i t i o n = n u l l ; 4 p r i v a t e S t r i n g l a t i t u d e = ; 5 p r i v a t e S t r i n g l o n g i t u d e = ; 6 p r i v a t e Gps gps = new Gps ( ) ; Quellcode 6.1: Quellcode für die Positionsbestimmung - Variablendeklaration Anschließend werden drei Event Handler erzeugt (Quellcode 6.2). Zwei davon prüfen, ob sich die Position oder der Status des Empfangsgerätes geändert haben, um dann ggf. eine entsprechende Methode aufzurufen. Der updatedatahandler wird dann von der jeweiligen Methode aufgerufen, um die Anzeige der Positionsbestimmung zu aktualisieren. 1 updatedatahandler = new EventHandler ( UpdateData ) ; 2 gps. DeviceStateChanged += new DeviceStateChangedEventHandler ( gps DeviceStateChanged ) ; 3 gps. LocationChanged += new LocationChangedEventHandler ( gps LocationChanged ) ; Quellcode 6.2: Quellcode für die Positionsbestimmung - Eventhandler Die Methode gps LocationChanged erfasst die neue Position und ruft die Methode UpdateData über den updatedatahandler auf, um die Bildschrimanzeige zu aktualisieren (Quellcode 6.3). 1 p r o t e c t e d void gps LocationChanged ( o b j e c t sender, LocationChangedEventArgs a r g s ) 2 { 3 p o s i t i o n = args. P o s i t i o n ; 4 // c a l l the UpdateData method via the updatedatahandler so that we 5 // update the UI on the UI thread 6 Invoke ( updatedatahandler ) ; 7 } Quellcode 6.3: Quellcode für die Positionsbestimmung - gps LocationChanged 62

74 Kapitel 6 Konzept eines Location Based Services Die Methode gps DeviceStateChanged erfasst den neuen Status und ruft die Methode UpdateData über den updatedatahandler auf, um die Bildschrimanzeige zu aktualisieren (Quellcode 6.4). 1 void gps DeviceStateChanged ( o b j e c t sender, DeviceStateChangedEventArgs a r g s ) 2 { 3 d e v i c e = args. DeviceState ; 4 // c a l l the UpdateData method via the updatedatahandler so that we 5 // update the UI on the UI thread 6 Invoke ( updatedatahandler ) ; 7 } Quellcode 6.4: Quellcode für die Positionsbestimmung - gps DeviceStateChanged Der Quellcode 6.5 zeigt die Methode UpdateData, welche die Positionsdaten (Grundlage sind die NMEA Daten) ausliest und anzeigt, sofern der GPS-Empfänger aktiviert ist. In der Variable str wird der String geschrieben, der später in einem Label (status) auf dem Display des Smartphones ausgegeben wird. Wenn eine Position bestimmt werden konnte, werden die Werte für den Längen- und den Breitengrad in die Ausgabevariable geschrieben. Hier kann auch erfasst werden, wie viele Satelliten erreichbar sind. Dafür werden die Attribute Latitude, Longitude und SatelliteCount des position Objekts ausgelesen. Sollten Werte für den Längen- und Breitengrad verfügbar sein, wird die Methode start post() (siehe Quelltext 6.6) aufgerufen, um diese Werte an den Server zu geben, der für die Verarbeitung der Werte zuständig ist. Außerdem werden die Event Handler für die Positions- und Statusänderung des Empfangsgerätes wieder entfernt. 1 void UpdateData ( o b j e c t sender, System. EventArgs args ) 2 { 3 i f ( gps. Opened ) 4 { 5 s t r i n g s t r = P o s i t i o n wird e r m i t t e l t... \ n\n ; 6 i f ( d e v i c e!= n u l l ) 7 { 8 s t r += d e v i c e. FriendlyName + + d e v i c e. S e r v i c e S t a t e +, + d e v i c e. DeviceState 63

75 Kapitel 6 Konzept eines Location Based Services 9 } + \n ; i f ( p o s i t i o n!= n u l l ) 12 { 13 i f ( p o s i t i o n. LatitudeValid ) 14 { 15 s t r = I h r e P o s i t i o n : \n\n ; 16 s t r += Latitude (DD) : \ n + p o s i t i o n. Latitude + \n ; 17 s t r += Latitude (D,M, S ) : \ n + p o s i t i o n. LatitudeInDegreesMinutesSeconds + \n ; 18 l a t i t u d e = p o s i t i o n. Latitude. ToString ( ) ; 19 } i f ( p o s i t i o n. LongitudeValid ) 22 { 23 s t r += Longitude (DD) : \ n + p o s i t i o n. Longitude + \n ; 24 s t r += Longitude (D,M, S ) : \ n + p o s i t i o n. LongitudeInDegreesMinutesSeconds + \n ; 25 l o n g i t u d e = p o s i t i o n. Longitude. ToString ( ) ; 26 } i f ( p o s i t i o n. S a t e l l i t e s I n S o l u t i o n V a l i d && 29 p o s i t i o n. S a t e l l i t e s I n V i e w V a l i d && 30 p o s i t i o n. S a t e l l i t e C o u n t V a l i d ) 31 { 32 s t r += S a t e l l i t e Count : \ n + p o s i t i o n. G e t S a t e l l i t e s I n S o l u t i o n ( ). Length + / + 64

76 Kapitel 6 Konzept eines Location Based Services 33 p o s i t i o n. G e t S a t e l l i t e s I n V i e w ( ). Length + ( + 34 p o s i t i o n. S a t e l l i t e C o u n t + ) \n ; 35 } i f ( p o s i t i o n. TimeValid ) 38 { 39 s t r += Time : + p o s i t i o n. Time. ToString ( ) + \n ; 40 } i f ( p o s i t i o n. LatitudeValid && p o s i t i o n. LongitudeValid ) 43 { 44 s t a t u s. Text = s t r ; 45 // S t a r t Client Server Kommunikation 46 s t a r t p o s t ( ) ; gps. DeviceStateChanged = new DeviceStateChangedEventHandler ( gps DeviceStateChanged ) ; 49 gps. LocationChanged = new LocationChangedEventHandler ( gps LocationChanged ) ; 50 } 51 } 52 } 53 } Quellcode 6.5: Quellcode für die Positionsbestimmung - UpdateData 65

77 Kapitel 6 Konzept eines Location Based Services Client-Server-Kommunikation Client Die Methode start pos() stellt eine Verbindung zum Server her, sendet die Positionswerte und nimmt den Response (siehe Quelltext 6.8) des Servers entgegen, um diesen letztlich über das Display an den Nutzer auszugeben. Im buffer Array vom Typ byte werden die Positionsdaten geschrieben, um sie später an den Server senden zu können. Anschließend wird ein HttpWebRequest Objekt erstellt. Diesem wird mit der Methode Create() die Adresse der Serverressource übergeben, welche die Positionsdaten verarbeiten soll. In diesem Fall wurde ein simples PHP-Script geschrieben (siehe Quellcode 6.7). Es können natürlich auch andere serverseitige Sprachen verwendet werden. Dem Objekt wird die Methode, welche für das Senden der Variablen verwendet werden soll, zugewiesen. In diesem Prototyp wird die POST Methode verwendet. Alternativ kann die GET Methode eingesetzt werden, dann müssten die Variablen in die URL des HttpWebRequest Objekts geschrieben werden. Desweiteren wird der Content Type und die Länge des Contents festgelegt. Danach wird ein Stream geöffnet, um die Daten an den Server zu senden. Hierfür wird die Methode Write() verwendet. Dieser Stream wird danach wieder geschlossen. Zum Schluss wird der Response Handler einem HttpWebResponse Objekt zugewiesen. Damit wurde aber noch kein möglicher Response verarbeitet. 1 p r i v a t e void s t a r t p o s t ( ) 2 { 3 s t a t u s. Text += \n\n Kommunikation mit Server g e s t a r t e t... ; 4 //Our p o s t v a r s 5 byte [ ] b u f f e r = Encoding. ASCII. GetBytes ( l a t i t u d e= + l a t i t u d e + &l o n g i t u d e= + l o n g i t u d e ) ; 6 // I n i t i a l i s a t i o n, we use l o c a l h o s t, change i f a p p l i a b l e 7 HttpWebRequest WebReq = ( HttpWebRequest ) WebRequest. Create ( http : / /www. s c h a t t e n g e s t a l t. de/ prototypes / l b s / s e r v e r s i d e. php ) ; 8 //Our method i s post, o t h e r w i s e the b u f f e r ( p o s t v a r s ) would be u s e l e s s 66

78 Kapitel 6 Konzept eines Location Based Services 9 WebReq. Method = POST ; 10 //We use form contenttype, f o r the p o s t v a r s. 11 WebReq. ContentType = a p p l i c a t i o n /x www form urlencoded ; 12 //The length o f the b u f f e r ( p o s t v a r s ) i s used as c o n t e n t l e n g t h. 13 WebReq. ContentLength = b u f f e r. Length ; 14 //We open a stream f o r w r i t i n g the p o s t v a r s 15 Stream PostData = WebReq. GetRequestStream ( ) ; 16 //Now we write, and afterwards, we c l o s e. Closing i s always important! 17 PostData. Write ( b u f f e r, 0, b u f f e r. Length ) ; 18 PostData. Close ( ) ; 19 //Get the response handle, we have no true response yet! 20 HttpWebResponse WebResp = ( HttpWebResponse ) WebReq. GetResponse ( ) ; [... ] 23 } Quellcode 6.6: Quellcode für die Serverkommunikation - start post Server Auf der Serverseite sieht das PHP-Script sehr überschaubar aus. Hier werden lediglich die empfangenen Werte ausgegeben. Diese Ausgabe wird vom Response-Handler dann gelesen. Letztlich zeigt das Script, dass die gesendeten Werte erhalten und verarbeitet wurden. An dieser Stelle könnten die übermittelten Daten mit einer Datenbank abgeglichen werden, um zum Beispiel POIs im Umkreis der aktuellen Position zurückzugeben. 1 <? php 2 3 echo I h r e P o s i t i o n : ; 4 p r i n t r ($ POST) ; 5 67

79 Kapitel 6 Konzept eines Location Based Services 6?> Quellcode 6.7: Quellcode für die Serverkommunikation - serverside.php Verarbeitung der Rückgabe Um die Ausgabe des PHP-Scripts lesen zu können, muss ein Response-Stream geöffnet werden. Dann wird der Server-Response gelesen und direkt ausgegeben. An Stelle der direkten Ausgabe könnten mögliche POIs geeignet auf einer Karte dargestellt werden. 1 [... ] 2 3 s t a t u s. Text += \n Server Response \n\n ; 4 //Now, we read the response ( the s t r i n g ), and output i t. 5 Stream Answer = WebResp. GetResponseStream ( ) ; 6 StreamReader Answer = new StreamReader ( Answer ) ; 7 s t a t u s. Text += Answer. ReadToEnd ( ) ; 8 } Quellcode 6.8: Quellcode für die Serverkommunikation - start post Response Der Prototyp zeigt, wie wenig Quellcode nötig ist, um die GPS Daten des eingebauten Empfängers zu verarbeiten und einen möglichen Weg der Client-Server- Kommunikation von Windows Mobile 6 umzusetzen. Ob der verwendete Weg mit zunehmender Komplexität der Anwendung noch allen Anforderungen genügt, muss später geprüft werden. Hier dient es dem Zweck, den reibungslosen Ablauf der Client- Server-Kommunikation im Rahmen einer Windows Mobile Anwendung zu demonstrieren Anwendung Das GUI wurde, wie die Anwendung selbst, auf das Nötigste reduziert. 68

80 Kapitel 6 Konzept eines Location Based Services Mit einem Klick (Fingerdruck) auf die Schaltfläche start GPS wird der GPS Empfänger eingeschaltet (siehe Abbildung 6.3). Abbildung 6.3: Die Positionsbestimmung starten 69

81 Kapitel 6 Konzept eines Location Based Services Sobald genügend Satelliten erreicht und die Position bestimmt wurde, werden dem Benutzer die erfassten Daten angezeigt (siehe Abbildung 6.4). Abbildung 6.4: Die bestimmten Positionsdaten 70

82 Kapitel 6 Konzept eines Location Based Services In der Abbildung 6.5 ist der Server Response zu sehen, den der Nutzer nach erfolgter Client-Server-Kommunikation erhält. Abbildung 6.5: Die Antwort des Servers Die angezeigten Daten dienen im Prototyp als Funktionsnachweis. In einer späteren Anwendung werden diese Daten im Hintergrund verarbeitet Erkenntnisse aus dem Prototypen und weitere Funktionen Die ersten Tests mit dem Prototypen wiesen auf diverse Problem sowohl bei der Positionsermittlung als auch bei der Client-Server-Kommunikation hin. 71

83 Kapitel 6 Konzept eines Location Based Services In einigen Testläufen konnten nicht ausreichend Satelliten gefunden werden oder es dauerte über 10 Minuten, um die ausreichende Anzahl für eine Positionsbestimmung zu erreichen. Besonders bei bedecktem Himmel und in Räumen kann die Satellitensuche sehr lange dauern. Anwendungen wie QuickGPS können durch das Herunterladen aktueller Satelliten Positionen die Dauer beim Finden jener deutlich verringern. In geschlossenen Räumen ist aber auch diese nutzlos. Aus diesem Grund empfiehlt es sich die Positionsbestimmung auch über die Cell ID durchzuführen, wenn in einem Zeitraum von maximal einer Minute keine GPS-Positionsdaten zur Verfügung stehen. Somit kann die Position auch ohne Satelliten bestimmt werden, selbst wenn dieses Verfahren deutlich ungenauer ist. Ein weiteres Problem besteht mit der HSDPA-Netzabdeckung, die für einen zügigen Datentransfer erfordertlich ist. Besonders in ländlichen Gebieten ist UMTS nicht verfügbar. Aber auch in einer Großstadt wie Köln gibt es Lücken in der Netzabdeckung. In U-Bahnen (unter der Erde) und auch in einigen Häusern stehen nur weniger leistungsfähige Netze zur Verfügung. Deswegen ist es erforderlich die Größe der transportierten Datenmenge so gering wie möglich zu halten, um Verzögerungen bei der Kommunikation zu vermeiden. Neben den aufgetretenen Problemen konnten bei den Testläufen auch altrnative Umsetzungen sowie wünchenswerte Funktionen ermittelt werden, die sich in einer späteren Anwendung wiederfinden sollten. Die zwischen Client und Server übertragenen Daten sollten in JSON kodiert werden, um eine ressourcenarme Übertragung sowie Verarbeitung der Daten in unterschiedlichen Programmiersprachen zu ermöglichen. JSON zeichnet sich außerdem durch eine bessere Lesbarkeit für Menschen und Maschinen gegenüber einer Kodierung in XML aus. Zusätzlich wird der Overhead bei der Verarbeitung von XML Dokumenten reduziert. Dies ist besonders wichtig, um Ressourcen zu sparen, was im vorliegenden, mobilen Kontext von großer Bedeutung ist. Auf der anderen Seite ist XML weiter verbreitet als JSON und nicht typisiert. Somit lassen sich auch komplexe Daten kodieren. Im Verlauf der Arbeit wurde bereits auf eine mögliche Verwendung von SOAP, welches auf XML basiert, hingewiesen, für den Fall, dass komplexe Daten ausgetauscht werden müssen. Demnach sollte der Einsatz von SOAP erwogen werden. Unabhängig von SOAP ist XML als Auszeich- 72

84 Kapitel 6 Konzept eines Location Based Services nungssprache grundsätzlich vielseitiger einsetzbar als JSON, welches lediglich ein Datenaustauschformat ist. An dieser Stelle muss die Verwendung abgewogen werden. Es spricht auch nichts gegen den Einsatz beider Technologien, je nach Anforderungen der jeweiligen Anwendungsfälle. Aus funktionaler Sicht sollte es basierend auf der Positionsermittlung des eigenen Standorts eine Umkreissuche geben, die dem Nutzer alle POIs im gewählten Umkreis zurückliefert. Hierfür wäre eine Berechnung dieses Umkreises und damit die Definition von Innerhalb und Außerhalb notwendig. Diese sollte vor einer Datenbankabfrage auf dem Server erfolgen. Es gibt mehrere Wege, um eine solche Berechnung durchzuführen. Eine recht leichte, wenn auch nicht ganz genaue Möglichkeit ist die Umkreissuche 2 basierend auf den Postleitzahlen. Bei einer anderen Möglichkeit müssten die Entfernungen der gespeicherten POIs zur aktuellen Position berechnet werden. Hier bietet es sich an, bereits beim Holen der POIs aus der Datenbank geeignet zu selektieren, um für eine eingegrenzten Menge an Orten die Entfernungsberechnung durchzuführen. Die gefundenen POIs könnten dann auf einer Google Maps Karte dargestellt werden. Für die Nutzung der Karten würden keine Kosten anfallen und man würde von der Technik hinter den Karten über die kostenlose API profitieren. Eine weitere wünschenswerte Funktion ist die Anzeige (bzw. Vorschau) von Medien, die mit den gefundenen POIs verbunden sind. Hier müssen allerdings Strategien entwickelt werden, um die Medien komplett zu nutzen und damit den Download auf das Smartphone zu ermöglichen, ohne lange Wartezeiten für den Nutzer zu erzeugen. Dabei müssen natürlich die momentan geringen Datenübertragungsraten beachtet werden. Die zunehmende Verbreitung von WLAN Hot Spots und einer Kommunikation via Wi-Fi könnte diesem Problem in Zukunft entgegenwirken. 2 Vgl. Stand:

85 Kapitel 7 Abschließende Betrachtung In dieser Arbeit wurden die unterschiedlichen mobilen Endgeräte voneinander abgegrenzt, wobei diese Abgrenzung bei einigen Geräten heutzutage schwer fällt, da sie über eine Fülle an Funktionen verfügen. Besonders der Trend aktuelle Smartphones und WebPads über so genannte App-Markets um Anwendungen zu erweitern, führt die Geräte weit über ihre scheinbare Bestimmung hinaus. In meinen Augen ist es nötig einige Definitionen zu überarbeiten oder gar eine neue Bezeichnung für diese Geräte zu finden. Sowohl die Definition der Smartphones als auch der WebPads fasst nicht annähernd den Funktionsumfang und die Möglichkeiten der aktuellen Geräte. Auf das Konzept für einen Location Based Service hatte dies jedoch kaum Einfluss. Hier spielen die unterschidlichen Betriebssysteme eine deutlich größere Rolle. Wenn man vom iphone absieht, welches das einzige Gerät darstellt, bei dem das Betriebssystem an die Hardware gebunden ist, setzen die Hersteller von Mobiltelefonen ansonsten auf unterschiedliche Betriebssysteme. Dies macht es nötig, um eine möglichst breite Verwendung des LBS zu erreichen, auf jene Betriebssysteme Rücksicht zu nehmen. Es empfiehlt sich, für jedes Betriebssystem eine eigene Anwendung zu schreiben, die den LBS des virtuellen Museums umsetzt. Allerdings sollte die Entscheidung, für welche Betriebssysteme eine Version entwickelt werden soll, nicht voreilig gefällt werden. Unter Umständen macht man sich zu sehr von einem Unternehmen abhängig. Dies gilt im Besonderen für Apple. Hier unterliegt die fertige Anwendung allein der Willkür von Apple. Der Konzern entscheidet, ob eine fertige Anwendung in ihrem App-Market angeboten wird oder nicht. Ablehnungen werden nicht einmal begründet. Selbst wenn die Anwendung im App-Market angeboten wird, ist das keine Garantie, dass es auch so bleibt. Bei einer erneuten Prüfung kann die Anwendung auch abgelehnt werden. Außerdem nimmt Apple bei der 74

86 Kapitel 7 Abschließende Betrachtung Weiterentwicklung des iphone OS keine Rücksicht auf erstellte Anwendungen. Man muss also mit jeder neuen Betriebssystemversion prüfen, ob die eigene Anwendung noch funktionsfähig ist. Hinzu kommt, dass die Geschäftsbedingungen von Apple alles andere als beständig sind. Diese wurden schon mehrmals geändert, was dazu führte, dass viele Anwendungen aus dem App-Market entfernt wurden. Diversen Firmen wurden mit den neuen Geschäftsbedingungen die Grundlage für ihre Anwendungen genommen und sie mussten die Entwicklung einstellen. Mit dem neuerlichen Verbot von Multiplattform-Compilern und Code Konvertern wird die Entwicklung erneut erschwert. Anwendungen dürfen jetzt nur noch in Objective-C, C, C++ oder JavaScript geschrieben werden. Als Entwickler kann ich eine solche Geschäftspolitik, die keine Rücksicht auf die Entwickler nimmt, obwohl Apple von ihnen und deren Anwendungen lebt, nicht unterstützen. Ich empfehle keine Anwendung für das iphone zu entwickeln. Stattdessen lege ich eine Entwicklung für Android nahe, welches als Open Source Betriebssystem eine andere Strategie verfolgt. Der in dieser Arbeit entwickelte Prototyp zeigt, wie die Positionsbestimmung für Windows Mobile 6.1. abläuft und eine Möglichkeit der Client-Server-Kommunikation. Dies sind die zentralen Bestandteile der späteren Anwendung für das virtuelle Museum. Die Tests des Prototypen ergaben, dass es auch heutzutage noch nicht ausreicht, wenn die Position allein über GPS bestimmt wird. In einem weiteren Prototypen sollte die Client-Server-Kommunikation unter Berücksichtigung des gewünschten Datenmodells erneut getestet werden. Dieser sollte auch die anderen Möglichkeiten zur Client-Server-Kommunikation beinhalten. Außerdem sollte sich ein weiterer Prototyp mit der Mediendarstellung (im Besonderen audiovisuelle Medien) auf dem mobilen Endgerät beschäftigen. 75

87 Anhang A Weltweite Smartphone-Marktanteile 2008 Die Firma Gartner 1 veröffentlichte am 11. März 2009 die weltweiten Marktanteilszahlen 2 der Smartphone-Hersteller und Smartphone-Betriebssysteme für das Jahr A.1 Marktanteile Smartphone Verkauf in 2008 Abbildung A.1: Marktanteile Smartphone Verkauf in 2008, nach Gartner 1 Gartner ist ein Anbieter für Marktforschung und Analyse in der weltweiten Technologie-Industrie. 2 Vgl. Stand:

88 Anhang A Weltweite Smartphone-Marktanteile 2008 A.2 Marktanteile Smartphone Betriebssysteme in 2008 Abbildung A.2: Marktanteile Smartphone Betriebssysteme in 2008, nach Gartner 77

89 Anhang B Technische Spezifikationen von Betriebssystemen B.1 Symbian OS v9.3 Die folgende Auflistung entspricht den offiziellen Angaben von Symbian zur Version Communication infrastructure TCP, IPv4, IPv6, MSCHAP v2 IPSec, IPSec for UMA RTP, RTCP and SIP TCP/IP plug-in framework HTTP plug-in framework - HTTP Pipelining WAP push Connectionless WSP Multiple Primary and Secondary PDP contexts Multihoming Bearer mobility PPP to CDMA specifications Enablers for CDMA specification Mobile IP 1 Vgl. Stand:

90 Anhang B Technische Spezifikationen von Betriebssystemen Telephony / telephony API Multimode ETel GSM Phase 2+ SIM Application Toolkit, class 3 SIM and USIM support HSCSD GPRS, classes A, B and C (R97/98) EDGE (CSD and GPRS) WCDMA (3GPP R4 and R5 IMS support) Quality-of-Service framework Phone book synchronizer CDMA IS-95 and 1xRTT R-UIM support CDMA network roaming support Third party OTA API NAM Programming Mode Messaging Post Office Protocol Version 3 (POP3), RFC 1939 Internet Message Access Protocol Version 4rev1 (IMAP4), RFC 3501 Simple Mail Transfer Protocol (SMTP), RFC 2821 IMAP4 IDLE command, RFC2177 SMTP Service Extension for Authentication, RFC 2554 Using TLS with IMAP, POP3, and ACAP, RFC 2595 SMTP Service Extension for Secure SMTP over Transport Layer Security, RFC 3207 Internet Message Format, RFC 2822 SMS (3GPP TS V6.5.0) EMS (3GPP TS V4.5) Java CLDC HI 1.1.1s (JSR139) MIDP 2.0 (JSR118) JTWI (JSR185) 79

91 Anhang B Technische Spezifikationen von Betriebssystemen Bluetooth (JSR082) including OBEX PIM & FileGCF (JSR075) Wireless Messaging 1.1 (JSR120) including CBS Mobile Media 1.1 (JSR135) Mobile 3D Graphics (JSR184) Content Handler (JSR211) Multimedia Abstract camera interface supporting multi-megapixel cameras Audio capture and recording framework Video captured recording framework Direct screen access Abstract tuner interface Hardware abstraction layer for multimedia acceleration Still image conversion (all common formats) with scaling enhancements 3D Graphics support with OpenGL ES API and reference implementation (for use with WINS emulator and test hardware only) Personal Area Networking Bluetooth stereo headset support Bluetooth v2.0 (L2CAP, RFCOMM, SDP, GAP and SPP) Bluetooth PANu and PAN GN IrDA USB v2.0 High Speed (Mass storage, ACM, WHCM) Serial Obex over Bluetooth, IrDA and USB PC Connectivity - agenda and contacts sync framework - file transfer OMA Data synchronization v1.2 Application framework Advanced UI framework 80

92 Anhang B Technische Spezifikationen von Betriebssystemen Contacts (incl. vcard v2.1) Agenda (incl. vcalendar v1.0) Unicode v3.0 Now supports Thai, Arabic, Hebrew, Japanese, Chinese, Hindi and Vietnamese Device management Smart Messaging - vcard and vcalendar - OTA system configuration OMA Device Management v1.2 OMA Client provisioning v1.1 Security Application capability management Application data caging DRM framework and reference implementation Cryptographic algorithms DES, 3DES, RC2, RC4, RC5 and AES Certificate management (X509 certificates) Secure Software Install MIDP 2.0 support Cryptographic token framework SSL/TLS (secure web connections) IPSec and VPN client support Software development J2ME MIDP 2.0 Metrowerks CodeWarrior v3.0 and ARM RVCT 2.2 compiler PC emulation environment 81

93 Anhang B Technische Spezifikationen von Betriebssystemen B.2 Windows Mobile 6.1 Die folgende Auflistung stammt aus einem offiziellen Windows Mobile 6.1 Flyer 2 und stellt die Neuerungen in der Version 6.1 der Vorgängerversion gegenüber. Diese Auflistung kann demnach auch als Funktionsübersicht herangezogen werden. Abbildung B.1: Neuerungen Windows Mobile 6.1, Teil 1 2 Vgl. WindowsMobile-Flyer_online.pdf, Stand:

94 Anhang B Technische Spezifikationen von Betriebssystemen Abbildung B.2: Neuerungen Windows Mobile 6.1, Teil 2 Bei Microsoft finden sich auch vergleichende Funktionsübersichten zur Version B.3 Mac OS X iphone Es findet sich keine frei erhältliche Spezifikation des Betriebssystems für das Mac OS X iphone. Deswegen wird hier ein Auszug der technischen Spezifikation des iphones abgebildet, welche in einigen Teilen Rückschlüsse auf die OS-Spezifikation zulässt, da das Betriebssystem auf die Erfordernisse des iphones zugeschnitten wurde. Capacity 8GB or 16GB flash drive 3 Vgl. Stand: