Mobile Endgeräte. Andreas Neupert Seminar Mobile Endgeräte 24. Januar 2011

Transkript

1 MOBILE ENDGERÄTE 1 Mobile Endgeräte Andreas Neupert Seminar Mobile Endgeräte 24. Januar 2011 Zusammenfassung In diesem Seminar betrachte ich die Möglichkeiten, die uns die Plattformen Google Android und Windows Phone 7 bieten. Dabei konzentriere ich mich auf die offiziellen Entwicklungsumgebungen. Alternative Frameworks werden nicht vorgestellt. Der Schwerpunkt liegt auf den für die Entwicklung von Anwendungen essentiellen Konzepten der Android beziehungsweise Windows Phone Programmierung. F I. EINLEITUNG ÜR dieses Seminar hatte ich die Freiheit, außer dem Pflichtprogramm Android und Windows Phone 7 auch andere Plattformen zu beleuchten. Einzig ios wurde von vorneherein vom Kunden ausgeschlossen. Die weiteren verfügbaren Plattformen wie BlackberryOS, WebOS oder Symbian bieten uns, meiner Meinung nach, keine essentiellen Vorteile und würden zudem eine längere Einarbeitung benötigen. Zudem kann man mit dem oben genannten Pflichtprogramm ein Seminar problemlos füllen, beziehungsweise fiel es mir schwer, im Rahmen dieses Seminars alle wichtigen Themen unterzubringen, sodass die Leser ausreichend informiert sind, um sich ein Bild über die Möglichkeiten und Schwachstellen der Plattformen zu machen. Im Weiteren unterteile ich das Seminar in die drei Abschnitte Hardware, Entwickeln und Benutzen. Die Kapitel erklären sich weitestgehend durch ihre Namen. So beinhalten die Kapitel Hardware und Benutzen einen kurzen Überblick über die, für die jeweilige Plattform verfügbare Hardware und die Hürden, die einem im Weg stehen, wenn man eigene Applikationen benutzen will. Der mit Abstand größte Teil des Kuchens wird allerdings dem Kapitel Entwickeln gewidmet, welches ein möglichst komplettes Bild über die Applikations-Entwicklung zeichnen soll. zu einer fragmentierten Plattform-Landschaft, denn es obliegt dem Geräte-Hersteller zu entscheiden, welche Hardware eingesetzt wird und ob das System regelmäßige Updates auf die neuste Android Version erhält. Diesem Effekt der Fragmentierung versucht Google mit dem Android Compatibility Program entgegenzuwirken. Dieses enthält die sogenannte Android Compatibility Definition (=CDD), welche einen Rahmen für die Hardware und Software definiert. Für Android-Geräte, die sich an diesen Rahmen halten, verspricht Google Support und garantiert die Lauffähigkeit für entsprechende also für die gleiche Android- Version entwickelte Software. Bisher war Android (Version 1.5 Version 2.3) ausschließlich für Smartphones gedacht. Android 3.0 (beziehungsweise Gingerbread) wird allerdings eine auf Tablets optimierte Oberfläche erhalten; dementsprechend wird die CDD sicher erweitert. Einige Beispiele aus der CDD: mögliche Auflösungen: 480*800, dynamische Orientierung, Touch-Screen, USB Client, Home-, Menu- und Back-Taste B. Entwickeln 1) Tools: Als Entwicklungsumgebung wird in erster Linie Eclipse in Verbindung mit dem von Google bereit gestellten ADT Plugin (ADT = Android Developer Tools) vorgesehen. Das ADT Plugin bietet ein vorgefertigtes Android Projekt, einen OnScreen-Emulator, diverse.xml-editoren und natürlich die Möglichkeit die entwickelte App im Debugging-Modus auf dem eigenen Smartphone zu testen, oder als.apk-datei (= Android Package -Datei) auf das eigene Smartphone zu laden und zu installieren. II. ANDROID A. Hardware Da Android eine offene Plattform ist, gibt es eine große Vielfalt an Hardware, auf der Android als Betriebssystem eingesetzt wird. Hauptsächlich handelt sich dabei um verschiedenste Varianten von Smartphones. Bald wird aber auch eine Vielzahl an Tablets verfügbar sein (Android 3.0 / Gingerbread wird eine neue, auf Tablets optimierte, Oberfläche beinhalten). In einzelnen Fällen wurde es auch für die Verwendung auf TV-Geräten oder Bordcomputern im Auto portiert. Die äußerst unterschiedliche Nutzung von Android führt (Abbildung1: Screenshot von Google ADT Plugin Android Emulator)

2 MOBILE ENDGERÄTE 2 2) Architektur & Konzepte Komponenten: Da in Android einige Begriffe und Konzepte verwendet werden, die einem noch nicht zwangsweise begegnet sein müssen, erkläre ich diese zu Beginn des Abschnitts. Eine Android-Applikation besteht aus mehreren lose gekoppelten Komponenten: Der Activity, dem Service, dem Content Provider und dem Broadcast Receiver. Es müssen allerdings nicht all diese Komponenten vorhanden sein, aber alle können auch mehrfach vorkommen. Diese grundlegenden Komponenten stelle ich nun Schritt für Schritt vor. Eine Activity entspricht einer Seite der Applikation. Soll eine Applikation also mehr als nur die Startseite (die Seite, die erscheint, wenn man die Applikation startet) beinhalten, benötigt man hierfür auch mehrere Activities. Eine Activity besteht nun wiederrum auch aus zwei Teilen. Zum einen aus einer Java-Klasse, in der die Funktionalität der Activity definiert wird, und zum anderen aus dem Layout, das in einer.xml-datei ausgelagert, aber auch dynamisch aus dem Java-Code manipuliert werden kann. In diesem Layout wird festgelegt, welche Oberflächenelemente genannt Views auf dem Bildschirm erscheinen, wenn die Activity angezeigt wird und wie diese angeordnet sind. Views werden die typisch in einer Oberfläche vorkommenden Elemente genannt. Dies sind zum Beispiel: Textboxes, Grids, Labels und so weiter. Will man eine Applikation wiederrum im Hintergrund ohne Anzeige arbeiten lassen, verwendet man hierfür einen Service. Dieser besitzt keine Anzeige und kann Hintergrundaufgaben, wie das Abspielen von Musik, oder das Überprüfen auf bereit stehende Updates, übernehmen. Eine weitere Komponente, die Teil einer Android- Applikation sein kann, ist der Content Provider. Dieser ist in der Lage größere Datenmengen zu verwalten. Hierfür stellt er eine kleine Datenbank (SQLite) zur Verfügung, sowie die Möglichkeit, die Daten an eine spezifische, oder auch mehrere Applikationen freizugeben. Die letzte Komponente, die man in einer Android- Applikation anfinden kann, ist der Broadcast Receiver. Dieser ermöglicht es einer Applikation Systemnachrichten, die in Form von Intents (siehe: Konzepte) auftreten, zu empfangen und darauf zu reagieren. Solch eine Systemnachricht könnte zum Bespiel über eine Empfangsstörung oder einen schwachen Akku unterrichten. 3) Architektur & Konzepte Konzepte: Diese Komponenten existieren zunächst prinzipiell jede für sich, ohne von den Anderen zu wissen. Das Konzept des oben erwähnten Intents (übersetzt: Absichtserklärung ) ermöglicht es nun, aus einer losen Ansammlung von Komponenten eine Applikation zu konstruieren. Es bietet uns die Möglichkeit, Nachrichten und Daten zwischen Komponenten auszutauschen. Aus vorher einzelnen Elementen entsteht nun eine lose gekoppelte Gemeinschaft. Man kann dabei nicht nur auf Komponenten eigener Applikationen, sondern auch auf Komponenten Dritter oder Komponenten der Android- Plattform zugreifen. Man ist also in der Lage, bereits vorhandene Funktionalität ohne großen Aufwand wiederzuverwenden. Wie funktioniert dies nun im Detail? Der für die Kopplung von Komponenten zuständige Intent tritt in zwei verschiedenen Varianten auf: In Form des expliziten Intents und des impliziten Intents. Der explizite Intent richtet sich an einen vorher bekannten eindeutigen Empfänger, der implizite Intent wiederrum hofft darauf, dass die bereits vorhandenen Komponenten anderer Applikationen Interesse an ihm zeigen. Dies kann durch sogenannte Intent-Filter (wie zum Beispiel der Broadcast Receiver einer ist, siehe: Komponenten) erreicht werden. Jede Applikation kann also bestimmte Intents abfangen und darauf reagieren. Will man zum Beispiel aus einer Applikation ein Video abspielen, genügt es, einen entsprechenden (impliziten) Intent abzusenden. Dieser wird dann von einem auf dem System installierten Player abgefangen, und das Video abgespielt. Sollte kein entsprechender Player installiert sein, wirft das Programm eine Fehlermeldung zu Laufzeit. Es wäre allerdings etwas abenteuerlich, jeder Applikation unbeschränkt auf alle Komponenten und Daten (zum Beispiel über Content Provider, siehe: Komponenten) Zugriff zu gewähren. Darum kann eine Applikation zunächst einmal nur sich selbst sehen. Um unbefugte Zugriffe, Datenmissbrauch und ein instabiles System aufgrund instabiler Applikationen zu verhindern, wird jede Android-Applikation in einer Sandbox ausgeführt. Das Sandbox-Prinzip wird so weit geführt, dass jede Applikation nicht nur in einer eigenen Dalvik Virtual Machine (siehe: Die Android Plattform) läuft und ihren eigenen Speicherbereich besitzt, sondern auch einen eigenen User im Linux-Kern von Android erhält. Dies bietet viele Vorteile für die Sicherheit (beschränkte Zugriffe) und die Stabilität des Systems (abstürzende Applikationen benötigen nur einen Neustart ihrer eigenen Dalvik Virtual Machine). Um nun wiederrum den oben beschriebenen, aber kontrollierten Zugriff auf externe Komponenten per Intent zu ermöglichen, gibt es das Konzept der Berechtigungen. Diese werden vom Entwickler im Android-Manifest (siehe: Projektaufbau) registriert und erlauben der Applikation Zugriffe, wie zum Beispiel die Möglichkeit, eine Internetverbindung aufzubauen. Bei der Installation der Applikation werden diese Berechtigungen dem Anwender aufgelistet, sodass er genau erkennen kann, welche Möglichkeiten der Applikation gewährt werden. Mit den Berechtigungen wird also das Konzept der Sandbox aufgeweicht. Durch das Sandbox-Prinzip entsteht allerdings noch eine weitere Thematik, die man betrachten sollte. Da für jede Applikation eine eigene Dalvik Virtual Machine genutzt wird, verbraucht das Starten einer Applikation natürlich viele Ressourcen. Darum will man, dass eine Applikation, beziehungsweise deren Komponenten, möglichst selten beendet und wieder gestartet werden. Komponenten werden also erst beendet, wenn das System die von der Komponente benutzten Ressourcen benötigt. Wir betrachten dieses Konzept am Bespiel der Activity. Der das Konzept beschreibende Activity Life Cycle wird in der folgenden Grafik veranschaulicht. Man sieht, dass die Activity nicht geschlossen wird, wenn sie teilweise (

3 MOBILE ENDGERÄTE 3 onpause()) oder ganz - ( onstop()) durch beispielsweise eine andere Activity verdeckt wird. Erst, wenn die Activity nicht mehr aktiv ist, und das System (oder eine andere Applikation) die Ressourcen benötigt, wird die Activity tatsächlich geschlossen (symbolisiert durch den Pfad links mit dem Punkt Process is killed ). Dies erfordert vom Benutzer die Implementierung der Funktionen onstop() und onpause(), damit benötigte Informationen nicht verloren gehen können, wenn die Applikation geschlossen wird. (Abbildung2: Activity Life Cycle; Quelle: android/app/activity.html) 4) Architektur & Konzepte Projektaufbau: Durch die bisherigen Betrachtungen der Komponenten und Konzepte einer Android-Applikation sollte eine grobe Übersicht über die Zusammensetzung einer solchen entstanden sein. Um das Bild noch etwas detaillierter zu zeichnen, möchte ich hier noch einmal die einzelnen Dateien und Ordner eines Projekts durchgehen und deren Bedeutung erklären. Von oben beginnend, treffen wir als erstes auf den Source-Ordner (src). Dieser beinhaltet die Komponenten unserer Applikation, ausgenommen dem Broadcast Receiver. Man kann hier also Actvities, Services und Content Provider definieren (Ergänzung: Die Definition eines Widgets ist hier ebenfalls möglich). In dem abgebildeten Projekt enthält er nur die Start-Activity der Applikation (Start.java). Der Generated-Ordner (gen) enthält die automatisch beim Kompilieren erstellte Ressourcen-Klasse R.java. Diese referenziert in bekannten Formaten abgelegte Ressourcen, (Abbildung 3: Android Projekt; Screenshot, Standard Android Projekt in Eclipse) welche dann über R.* aus dem Programm aufgerufen werden können. Der Ordner Android 2.2 enthält wie der Name schon andeutet die Klassen der Android-Plattform (und auch alle aus Java und SQLite zur Verfügung gestellten Klassen). Als nächstes enthält das Projekt den assets-ordner (assets; übersetzt: Kapital, Vermögenswert). Dieser ergänzt den darauf folgenden Ressourcen-Ordner (res). Beide bieten eine Ordnerstruktur, um die Ressourcen eines Projekts abzulegen. Der Ressourcen- Ordner hat hierbei eine feste Ordnerstruktur, in der Ressourcen in bekannten Formaten abgelegt werden können. Unter diese bekannten Formate fallen zum Beispiel diverse xml-definitionen wie Layouts (im Beispielprojekt: main.xml, welche das Layout der Start.java-Activity definiert / siehe: Komponenten), Text-Ressourcen (im Beispielprojekt: strings.xml; beinhaltet Key-Value-Paare von Strings) und Animationen. Aber auch Bilder und Multimedia-Inhalte (im Beispielprojekt: icon.png; 3 Versionen für verschiedene Ansichten, oder Geräte mit unterschiedlicher Auflösung / highdpi, middledpi, lowdpi) können im Ressourcen-Ordner untergebracht werden. Diese Ressourcen werden dann vom Resource-Manager vorkompiliert und indexiert. Im assets- Ordner landet nun noch alles, was nicht im Ressourcen- Ordner unterkommt. Hier muss man sich selbst um die Behandlung der Inhalte kümmern. Als letztes stoßen wir auf das Android Manifest (AndroidManifest.xml). Dieses bildet ein Verzeichnis über alle Komponenten unserer Applikation und legt weitere grundsätzliche Eigenschaften dieser fest. Beispielsweise der Package-Name, die Versionsnummer der Applikation, der minimale Android-API-Level (unter dem die Applikation lauffähig ist), die Berechtigungen, die verwendeten Bibliotheken und eben die Komponenten der Applikation werden hier festgelegt. 5) Architektur & Konzepte Die Android Plattform: Um Applikationen für Android zu entwickeln, steht dem geneigten Programmierer in erster Linie der Anwendungsrahmen des Android SDKs zur Verfügung. Die folgende Grafik zeigt zunächst einmal eine Übersicht über die Plattform.

4 MOBILE ENDGERÄTE 4 (Abbildung 4: Android-Plattform, Quelle: Literatur [1]) Auf unterster Ebene arbeitet ein Linux-Kernel, der die Schnittstelle zur Hardware liefert, die Ausführung von Programmen organisiert und weitere typische Kernel- Aufgaben übernimmt, wie zum Beispiel die Energieverwaltung. Auf der zweiten Ebene befinden sich die Android- Laufzeitumgebung bestehend aus Dalvik Virtual Machine und den Android-Laufzeitbibliotheken sowie die Standard-Bibliotheken. Diese beinhalten Bibliotheken verschiedener Hersteller (Android, Java, SQLite-Team) und bieten die grundsätzliche Funktionalität, die die Applikationen benötigen. Sie bieten zum Beispiel die Funktionalität eines Browsers (WebKit) oder einer Datenbank (SQLite) und liefern zudem Unterstützung für Grafik (OpenGL), Multimedia, Touchscreens oder Verschlüsselung (SSL). Auf diese zweite Ebene kann mit dem Android NDK zugegriffen werden. Sie ist in C und C++ programmiert. Auf der nächsten Ebene befindet sich nun der in Java geschriebene Anwendungsrahmen, auf den wir mit dem Android SDK zugreifen können. Dieser beinhaltet Klassen, die uns die Funktionalität der oben eingeführten Komponenten einer Android-Applikation bieten, sowie die Funktionalität des Geräts zugänglich machen. Die Komponenten Activity Manager, Content Provider, Resource Manager und Views bieten die Funktionalität der jeweils gleichnamigen, oben eingeführten Komponenten oder wurden bereits anderweitig erklärt. Auch der Sinn und Zweck der übrigen Komponenten ergibt sich schnell aus der Bezeichnung. Darum gebe ich hier nur eine stichwortartige Übersicht über die einzelnen Komponenten: Activity Manager: Funktionalität der Activity (siehe: Komponenten). Content Provider: Funktionalität des Content Providers (siehe: Komponenten). Location Manager: Bietet Lokalisierungsdienste auf Basis von GPS, GSM-Zellen, Webzugang. Notification Manager: Bietet die Funktionalität einer Mitteilung in der Status-Bar Androids. Package Manager: Verwaltet die installierten Applikationen und deren Intents/Intent-Filter. Gibt zum Beispiel Information darüber, ob eine Applikation installiert ist, die auf einen bestimmten Intent reagiert. Resource Manager: Funktionalität des Resource- Managers (siehe: Projektaufbau) Views: Funktionalität der Oberflächenelemente (siehe: Komponenten) Connectivity-Manager: Bietet die Möglichkeit, Netzwerkverbindungen zu erzeugen, oder deren Zustand abzufragen. Telephony Manager: Bietet Telefondienste. Window Manager: Bietet die Funktionalität des Layouts (Anordnung von Views / siehe: Komponenten) Die letzte Komponente der Android-Plattform, die ich hier vorstellen will, ist die Dalvik Virtual Machine (DVM). Java stellt mit der J2ME bereits eine Java Virtual Machine für mobile Endgeräte zur Verfügung. Es wäre also nicht unbedingt nötig gewesen eine eigene JVM zu entwickeln. Während J2ME allerdings lediglich eine Untermenge des Java SDK s ist, wurde die DVM speziell an die Bedürfnisse von Smartphones angepasst. Da die meisten Smartphones mit auf der ARM-Architektur (basiert auf RISC-Architektur) basierenden Prozessoren ausgerüstet sind, lässt sich die Performance einer VM erheblich steigern, wenn sie Registeroperationen unterstützt. Dadurch wird das Sandbox- Prinzip mit einer eigenen DVM-Instanz für jede Applikation erst möglich ohne dramatischen Performanz-Verlust. Ein weiterer Grund, eine eigene VM zu entwickeln, war, dass für die Nutzung der JVM Lizenzkosten fällig geworden wären. Google umgeht dies, indem der beim Kompilieren erstellte Java-Bytecode durch ein eigens entwickeltes Tool (dx-tool) in sogenannten DEX-Bytecode umgewandelt wird. Dieser DEX-Bytecode wird dann zur Laufzeit von der DVM in Maschinencode übersetzt (die JVM hat nichts zu tun). 6) Google App Inventor: Der Google App Inventor ist ein als Web-App realisierter Oberflächen-Editor. Er bietet die Möglichkeit, mit wenigen Klicks die Oberfläche einer Android-App zu erstellen und den entstandenen Code herunterzuladen. C. Benutzen Selbst entwickelte Android Apps können ohne größere Einschränkungen benutzt werden. Das einzige Hindernis ist eine Voreinstellung, die verhindert, dass Apps von außerhalb des Android Markets installiert werden können. Ist diese beseitigt steht dem Entwickler nichts mehr im Wege. Das Smartphone kann im Debugging-Modus per USB an den PC angeschlossen werden, und die Applikation nach dem kompilieren direkt auf dem Gerät getestet werden. Ist die Applikation fertig, kann mit den Android Developer Tools ein Android-Package (.apk) erstellt werden, welches per USB auf das Smartphone kopiert, und dort installiert werden kann.

5 MOBILE ENDGERÄTE 5 A. Hardware III. WINDOWS PHONE 7 Windows Phone 7 ist im Gegensatz zu Android keine offene Plattform. Die Benutzung von Windows Phone 7 kostet den Geräte-Hersteller Lizenzgebühren und ist in vielen Dingen eingeschränkt. Beispielsweise darf keine alternative Oberfläche installiert werden und auch die Hardware ist in großem Maße reglementiert. Bisher unterstützt Windows Phone 7 lediglich die Auflösungen 480x800 und 320x480. Wobei bisher die große Mehrheit der Geräte-Hersteller auf 480x800 setzt. Der Prozessor muss eine ARMv7-Architektur besitzen und mindestens eine Taktfrequenz von 1GHz bieten. Die 3 Standard-Knöpfe Start, Zurück und Suche werden vorausgesetzt, ebenso wie die Unterstützung von Multi- Touch mit bis zu 4 Fingern. Weiterhin müssen eine GPU mit DirectX 9 Hardwarebeschleunigung, sowie diverse Sensoren (umgangssprachlicher Überbegriff für diverse Ein- und Ausgabe-Komponenten) verbaut sein. Hierbei handelt es sich um WiFi, eine mindestens mit 5 Mega-Pixel auflösende Kamera, einen Beschleunigungsmesser, Ortungdienste (GPS, GSM-Zellen, Wi-Fi), Vibration und Push Notifications (siehe: Konzepte). Die Windows Phone 7 Landschaft sieht durch diese starke Reglementierung im Moment also nicht allzu vielfältig aus. Die meisten Geräte unterscheiden sich lediglich in Details. Windows Phone 7 ist zudem ausschließlich für Smartphones konzipiert. Eine Umsetzung für Tablets wird es laut Steve Ballmer (Quelle: z. B.: html ) nicht geben. B. Entwickeln 1) Tools: Die folgende Grafik zeigt einen Überblick über die vorhandenen Tools. Emulator, der sowohl für Silverlight-, als auch für XNA- Applikationen funktioniert. Für die Designer-orientierte Oberflächenentwicklung liefert Microsoft Expression Blend. Hiermit lassen sich Oberflächen ohne vertiefte Programmierkenntnisse erstellen. Zumindest wenn der Entwickler entsprechende View-Models zur Verfügung stellt. (Anmerkung: Das View-Model lässt es zu, dass der Designer per Drag-and-Drop Data-Bindings, also die Zuordnung von Daten zu Oberflächen-Controls, erstellt.) 2) Architektur: Die folgende Grafik zeigt wieder einen Überblick. Diesmal über die Frameworks und Funktionalitäten, die wir für die Erstellung von Windows Phone 7 Applikationen verwenden können. (Abbildung6: WindowsPhone7-Frameworks; Quelle: Wie man in Abbildung 6 sehen kann, handelt es sich hierbei zum einen um, das als Browser-Plugin für Web- Applikationen bekannte, Silverlight und zum anderen XNA, das für die Entwicklung von Spielen für die X-Box, aber auch den PC oder den Zune Player verwendet wird. Beide Frameworks basieren auf dem.net-framework, können also nur mit managed -Code verwendet werden. Das XNA- GameStudio unterstützt offiziell nur C#. Silverlight for Windows Phone gibt es bisher ebenso nur für C#, Visual Basic.NET soll allerdings bald auch unterstützt werden. Neben den Frameworks für die Applikationsentwicklung wird bei Microsoft die Cloud-Strategie in den Vordergrund gestellt. Die in Abbildung 7 dargestellten Cloud Services, die Microsoft speziell für die Windows Phone 7 Plattform anbietet, dienen als Instrument um die Funktionalität einer Windows Phone 7 Applikation zu erweitern. Bei den erwähnten Services handelt es sich um den allgemeineren Cloud-Service Windows Azure und die speziell (Abbildung5: WindowsPhone7-Tools; Quelle: Die Entwicklungsumgebung für Windows Phone 7 wurde für den Microsoft-erfahrenen Entwickler in die schon vorhandenen Strukturen integriert. Wenn man also mit der Microsoft-Welt vertraut ist, wird man vermutlich keine großen Probleme haben, sich in der Entwicklung für Windows Phone 7 zurechtzufinden. Die Entwicklungsumgebung bietet somit selbstverständlich Visual Studio In dieses integriert ist Silverligth for Windows Phone mitsamt Oberflächen-Editor, das XNA Game Studio 4.0 und natürlich ein OnScreen - Phone (Abbildung7: WindowsPhone7-Cloud-Services; Quelle:

6 MOBILE ENDGERÄTE 6 auf eine Aufgabe zugeschnittenen Services, wie der Push- Notification-Service, der Location-Service, oder der Xbox- Live Service (Cloud-Services im Detail: siehe Konzepte). Das Gerüst auf dem eine Windows Phone 7 Applikation aufbaut, besteht also zunächst aus den beiden Frameworks Silverlight und XNA in ihrer jeweiligen Windows Phone 7 Version. Da diese aber von Grund auf keinerlei Smartphonespezifische Funktionalität mitbringen, spendiert Microsoft den Entwicklern zusätzlich noch die Windows Phone 7 Frameworks. Abbildung 8 zeigt eine detaillierte Auflistung aller zur Verfügung gestellten Komponenten. Auf der untersten Ebene befindet sich zunächst einmal der.net-kern; die sogenannte Common Base Class Library. Diese Klassen bieten die Basis mit grundsätzlichen Features aus.net für die darauf aufbauenden UI-Frameworks, Silverlight Presentation und Media, sowie die XNA Frameworks. Diese zweite Ebene bietet die Funktionalität der Oberfläche und des Event-Handlings. Auf oberster Ebene fügt Microsoft diesem Paket nun noch Windows Phone 7 spezifische Klassen hinzu. Diese kümmern sich um Aufgaben, die speziell auf dem Smartphone anfallen, wie der Umgang mit Sensoren, der Kamera, oder anderen spezifischen Funktionalitäten wie den Launchers & Choosers, oder PhoneApplicationFrame (siehe: Konzepte). (Abbildung8: WindowsPhone7-Frameworks; Quelle: Nachbildung nach Vorlage von 3) Konzepte: Wie bei den meisten mobilen Plattformen, wird auch bei Windows Phone 7 ein Sandboxing-Prinzip angewendet. Das heißt, jede Applikation läuft in einer eigenen Instanz der Common Language Runtime (=.NET- Laufzeitumgebung; hier eine abgespeckte Windows Phone 7 - Version). Zusätzlich hat sie auch noch einen eigenen Speicherbereich. Während man deshalb bei Android versucht hat, das Starten und Beenden von Prozessen so selten wie möglich durchzuführen, scheint man bei Microsoft keine Bedenken wegen des diesbezüglichen Aufwands zu haben. Denn das Application Execution Model schreibt vor, dass in Windows Phone 7 generell immer nur eine Anwendung läuft (von einigen ausgewählten Services des Systems mal abgesehen; zum Beispiel Services zur Audio-Wiedergabe). (Abbildung9: WindowsPhone7-Application Execution Model; Quelle: Nachbildung nach Vorbild aus folgender Webcast-Serie: CS mspx) Passenderweise ist die laufende Applikation diejenige die sich im Vordergrund befindet. Was passiert nun aber mit Applikationen, die nicht mehr im Vordergrund sind? Hier gibt es zwei Möglichkeiten. Im ersten Fall schließen wir die Applikation explizit durch das Betätigen des Zurück-Buttons. Dies impliziert die Absicht, die Applikation schließen zu wollen. Dementsprechend wird die Applikation beendet, und das Closing-Event wird ausgeführt. Da wir als User annehmen, dass die Anwendung geschlossen wurde, müssen wir uns bei der Implementierung ohne Einschränkung der Allgemeinheit nicht weiter um unsere Daten kümmern. Beim nächsten Start wird eine komplett unbelastete Instanz unserer Applikation neu gestartet. Im anderen Fall verlassen wir die Applikation implizit. Das heißt, wir rufen eine andere Applikation durch einen Launcher oder Chooser (siehe: Konzepte weiter unten) auf oder wechseln mit dem Home- Button auf den Startbildschirm. In beiden Fällen erwarten wir, dass beim Zurückkehren in die Applikation alles genauso aussieht wie zuvor. Als wäre die Applikation nur für eine Weile in den Hintergrund geraten und jetzt wieder angezeigt worden. Tatsächlich wird die Applikation aber geschlossen und das Deactivating-Event ausgeführt. Hierbei passiert zunächst das Gleiche wie beim Closing-Event. Die Applikation wird geschlossen. Allerdings haben wir in diesem Fall davor die Chance, einen sogenannten Tombstone (deutsch: Grabstein) oder einen State-Bag (auf Deutsch so etwas wie: Zustands-Koffer ) anzulegen. In diesem können wir alle benötigten Informationen abspeichern, die wir für das komplette Wiederherstellen der Applikation benötigen. Man merkt sich also nur einige

7 MOBILE ENDGERÄTE 7 Informationen über die tote Applikation; sozusagen die Inschrift des Grabsteins. Beim erneuten Aufruf der Applikation wird dann nicht das Launching-Event ausgeführt, sondern das Activated-Event. Hier wird der Applikation also der State-Bag mitgegeben, sodass sie weiß, in welchem Zustand sie gestorben ist und sich vollständig wiederherstellen kann. Für die Sicherung des Zustands im State-Bag stehen dem Entwickler übrigens nur einige Sekunden zur Verfügung. Bei großen Datenmengen empfiehlt es sich daher, permanent Sicherungen anzulegen. Was sich Windows Phone 7 schon ohne Eingriff des Programmierers merkt, ist der Verlauf der aufgerufenen Seiten und Applikationen im sogenannten Session-Stack. Dieser ermöglicht es, mit der Zurück-Taste immer zur zuletzt angezeigten Seite zurück zu gelangen, beinhaltet aber immer nur einen Eintrag für eine Applikation. Navigieren wir uns also vom Start-Bildschirm aus in die Applikation A, dann zur Applikation B, zurück zum Start-Bildschirm und erneut zu Applikation A, geht der alte Zustand der Applikation A verloren und nur der aktuelle gespeichert. Wir könnten also nicht durch das mehrfache Betätigen der Zurück-Taste zum alten Zustand der Applikation A gelangen. Da es bereits erwähnt wurde, erläutere ich an dieser Stelle das Konzept der Launchers und Choosers. Betrachten wir das Konzept des Intents aus Android, sind wir der Beschreibung der Launchers und Choosers schon relativ nah. Dieses ist allerdings nicht so mächtig wie das des Intents. Launcher & Chooser sind für Windows Phone 7 Applikationen das Mittel der Wahl um im Falle des Launchers Applikationen aufzurufen, oder im Falle des Choosers Applikationen aufzurufen und einen Rückgabewert zu erwarten. Zum Beispiel das Starten eines Telefonanrufs ist eine Aufgabe des Launchers, das Auswählen eines Avatar-Fotos aus der Galerie eine des Choosers. Die Auswahl an Launchers und Choosers ist allerdings begrenzt und nur für vorher von Microsoft definierte Funktionen verfügbar. Eine weitere wichtige Komponente ist die Cloud. Diese wird nicht nur als Verbindung zu Konten, Facebook und Twitter interpretiert, sondern allgemein als Datenanbindung. Dazu muss man beachten, dass in Windows Phone 7 keine Hintergrundoperationen möglich sind. Es gibt also kein Pendant zu den aus Android bekannten Services. Da stellt sich die Frage, wie zum Beispiel nach Updates gesucht werden soll. Es ist ja nicht möglich, in regelmäßigen Abständen eine Adresse abzufragen. Dazu müsste die Applikation aktiv, also im Vordergrund, sein. Um dieses zu ermöglichen, bietet Microsoft den Push-Notification- Service an. Dieser bietet einem die Möglichkeit, von der eigenen Applikation aus einen Knotenpunkt in der Cloud zu registrieren. Dieser Knotenpunkt ist dann vom gesamten Web aus erreichbar. Man ist also in der Lage, Updates von einer Web-Applikation aus an den Knotenpunkt zu schicken. Damit dieses Update schließlich auch auf das Gerät gelangt, gibt es auf dem Windows Phone einen Download-Manager. Dieser überprüft von Zeit zu Zeit den Push-Notification- Service und lädt dort die Informationen von allen registrierten Knotenpunkten herunter. Als Reaktion auf ein im Knotenpunkt registriertes Update kann nun auf dem Gerät eine entsprechende Applikation gestartet, eine Notification in der StatusBar angezeigt, oder ein LiveTile aktualisiert werden. (Anmerkung: LiveTiles sind Hubs auf dem Startbildschirm von Windows Phone 7, die live -Informationen anzeigen können. Zum Beispiel: 2 neue Anrufe) Somit ist Windows Phone in der Lage, energiesparend alle Updates für das Gerät zentralisiert zu verwalten. Ein weiterer Cloud-Service ist Location. Dieser liefert auf die Angabe einer GSM-Zelle, W-Lan-Verbindung, oder GPS-Koordinaten, den Ort beziehungsweise gleich die Adresse zurück. Der Xbox-Live Service bietet zum Beispiel die Möglichkeit, Bestenlisten zu verwalten, oder auch Multiplayer-Spiele zu verbinden. Windows Azure bietet die Möglichkeit eigene Anwendungen und Daten in der Cloud zu platzieren, die dann zum Beispiel die eigene Windows Phone 7 Applikation mit Daten speißen. Wenn man an dieser Stelle den Vergleich mit einer Android-Applikation ziehen will, fällt einem auf, dass hier noch kaum von Komponenten gesprochen wurde. Allerdings existieren diese in der Windows Phone 7 Plattform prinzipiell auch nicht. Der Activity entspricht und PhoneApplicationPage, also eine Seite die aktuell angezeigt wird. Einen Service oder einen Content Provider gibt es in Windows Phone 7 nicht, so wie man sie von Android her kennt. Hierfür verwenden wir stattdessen die entsprechenden Cloud-Services. 3) Silverlight: Silverlight bietet die Möglichkeit, im Prinzip klassiche Applikationen zu entwickeln. Solch eine Applikation arbeitet event-driven, wie man es vom PC kennt, und unterscheidet bei der Implementierung zwischen Design und Logik. Während die Logik also in C# definiert wird, ist XAML (extensible Application Markup Language) die Waffe der Wahl, um das Design zu implementieren. Silverlight bietet für die Oberflächenentwicklung spezielle Controls im Windows Phone 7 Stiel, aus denen die Oberfläche zusammengebaut werden kann. Ein Unterschied zu Silverlight auf dem PC ist, dass es auf Windows Phone 7 als standalone Framework zum Einsatz kommt, also nicht im Browser läuft. Aktuell basiert Silverlight for Windows Phone auf Silverlight 3. Auch für Silverlight Applikationen möchte ich kurz die grundsätzliche Struktur anhand eines Standard-Projekts betrachten. Abbildung 10 zeigt ein solches Standart-Projekt. Von oben beginnend, treffen wir zuerst auf den Properties- Ordner. Dieser beinhaltet zwei Manifest -Dateien, wie sie uns auch schon im Android-Projekt begegnet sind. Die WMAppManifest-Datei (WMAppManifest.xml) entspricht dabei dem Android-Manifest. Hier werden alle wichtigen Informationen über die Applikation abgelegt. Zum Beispiel für welche Geräte die Appliaktion gedacht ist, wie sie heißt, Versionsnummern und Ressourcen-Pfade. Die beiden Dateien AppManifest.xml und AssemblyInfos.cs kommen aus der Silverlight-Welt und beinhalten Informationen über geladene Assemblys und andere Bereitstellungseigenschaften

8 MOBILE ENDGERÄTE 8 von Silverlight- Applikationen. Sie sind für die Entwicklung von Windows Phone 7 Applikationen nicht so essentiell wie WMAppManifest.xml. App.xaml und App.xaml.cs bieten die Möglichkeit, Anwendungsweit Ressourcen zu definieren, wie zum Beispiel Farbschemas. (Abbildung 10: WP7-Silverlight- Die zwei.pngs und die Projekt; Screenshot, Standard SL.jpg-Datei erklären sich Projekt in Visual Studio) weitestgehend selbst. ApplicationIcon.png ist das Start-Icon, Background.png definiert das Hintergrundbild in der Applikation und SplashScreenImage.jpg wird angezeigt, während die Applikation startet. Das letzte Datei-Paar ist MainPage.xaml.cs. Dieses entspricht unserer ersten PhoneApplicationPage, also der ersten Seite unserer Applikation. 4) XNA: In den XNA Frameworks werden im Gegensatz zum Silverlight Framework keine Controls zur Oberflächenentwicklung angeboten. Stattdessen bietet XNA die Mittel um high-performance 2D- und 3D-Oberflächen selbst zu kreieren. Dazu gibt es zum Bespiel eine Content- Pipeline, die in der Lage ist, Modelle in bekannten Formaten in.net-objekte umzuwandeln. Einer der größten Unterschiede zwischen Silverlight und XNA ist allerdings, das XNA nicht event-driven, sondern in einem meistens um Grafik-Modelle. Abbildung 11 stellt diesen Ablauf noch einmal grafisch dar. Auch an dieser Stelle werfe ich einen kurzen Blick auf die Projektstruktur einer Windows Phone 7 XNA Applikation. (Abbildung 12: WP7-XNA-Projekt; Screenshot, Standard XNA Projekt in Visual Studio) Die Properties sehen bei einem XNA-Projekt genau gleich aus wie in einer Windows Phone 7 Silverlight Applikation. Der Unterschied liegt in den beiden C#-Dateien Game1.cs und Program.cs. Letztere ist ein Überbleibsel aus XNA-Projekten für die Xbox oder den PC, und spielt für Windows Phone 7 überhaupt keine Rolle. Die Game1.cs beinhaltet im Prinzip alle wichtigen Funktionen, die wir für eine XNA-Applikation benötigen. Das sind hauptsächlich: Initialize(), LoadContent(), Update(), Draw(), und UnloadContent(). Also die schon vom GameLoop bekannten Funktionen. Nun fehlen noch einige Bild-Dateien. Game.ico und GameThumbnail.png repräsentieren beide Icons (ersteres ist für den PC gedacht, das Zweite für die Xbox). Background.png erklärt sich durch seine Bezeichnung selbst. Zu guter Letzt wird unter Inhaltsreferenzen der WindowsPhoneGame3Content weiter unten referenziert. Dies ist der Ort, an dem man seine Inhalte (zum Beispiel Bitmaps oder 3D-Modelle) ablegen kann und um deren Einbindung ins Projekt sich dann die Content Pipeline kümmert. C. Benutzen Microsoft macht es dem Hobby-Entwickler nicht einfach. Denn leider erlaubt Microsoft nur die Installation von Applikationen aus dem Windows Phone Marketplace. Alternativ kann man als Entwickler mit Visual Studio seine Applikation direkt auf dem Smartphone installieren. Allerdings nur, wenn das Gerät davor registriert wurde. Dafür wird ein Developer Account benötigt, der im Jahr $99 USD kostet. Eine Ausnahme wird für Studenten gemacht. Diese erhalten ihren Account im ersten Jahr kostenlos. (Abbildung11: XNA-GameLoop; Quelle: Nachbildung nach Vorlage von: Development-(First-Steps).aspx) klassischen Game-Loop organisiert ist. Das heißt, das Spiel durchläuft permanent einen Kreislauf, in dem zuerst alle Veränderungen an den Daten vorgenommen werden (Update()), und dann die Oberfläche gezeichnet wird. In der Update-Methode werden also alle aktuellen Eingaben verarbeitet, und entsprechende Veränderungen vorgenommen, die dann durch Draw() auf dem Bildschirm ausgegeben werden. Vor und nach diesem Kreislauf werden die Inhalte geladen und entladen. Hierbei handelt es sich LITERATUR [1] Becker, Arno & Pant, Marcus: Android 2 Grundlagen und Programmierung, dpunkt.verlag 2010 [2] Petzold, Charles: Programming Windows Phone 7, Microsoft Press 2010 [3] MSDN Windows Phone Development, [4] App Hub Library Documentation, [5] Windows Phone Schneller Einstieg, [6] Android Developers Dev Guide, [7] Android Developers Reference, [8] Wikipedia Windows Phone 7, [9] Wikipedia Android,