Entwicklung und Vermarktung von Handy-Apps: Einstieg in die Welt der mobilen Applikationen

Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

1. Einleitung
1.1. Motivation und Zielsetzung
1.2. Vorgehen und Abgrenzung

2. Grundlagen
2.1. Definition des Begriffs „App“
2.2. Mobile Endgeräte
2.3. Mobile Betriebssysteme
2.3.1. Google Android
2.3.2. Apple iOS
2.3.3. Microsoft Windows Phone
2.3.4. Nokia Symbian
2.3.5. Research In Motion Blackberry OS
2.4. Mobile Applikationen
2.4.1. Geschichte und Akzeptanz der mobilen Applikationen
2.4.2. Abgrenzung zu Desktop-Anwendungen
2.4.3. Abgrenzung zu mobilen Web-Applikationen
2.4.4. Kategorien und Beispiele innovativer Apps

3. Entwicklung
3.1. Android
3.1.1. System-Architektur
3.1.2. Laufzeitverhalten
3.1.2.1. Lebenszyklus einer Android Anwendung
3.1.2.2. Dalvik Virtual Machine und Multitasking
3.1.2.3. Sandbox und Datenaustausch
3.1.3. Entwicklungsumgebung und -Werkzeuge
3.1.3.1. Werkzeuge für das GUI-Design
3.1.3.2. Debugger und Emulator
3.1.4. Aufbau eines Android-Projekts
3.1.5. Basiskonzepte der Android-Entwicklung
3.1.5.1. Activities
3.1.5.1.1. Zustandssicherung
3.1.5.1.2. Menüs
3.1.5.1.2.1. Optionen-Menü
3.1.5.1.2.2. Kontext-Menü
3.1.5.1.3. Spezielle Activities
3.1.5.1.3.1. ListActivity
3.1.5.1.3.2. PreferenceActivity
3.1.5.1.4. Exkurs: Benachrichtigungen
3.1.5.1.4.1. Toasts
3.1.5.1.4.2. AlertDialogs
3.1.5.2. Intents
3.1.5.2.1. Explizite Intents
3.1.5.2.2. Implizite Intents und Intent-Filter
3.1.5.2.3. Broadcast Receiver
3.1.5.2.4. Broadcast Intents
3.1.5.2.5. Statischer Broadcast Receiver
3.1.5.2.6. Dynamischer Broadcast Receiver
3.1.5.3. Service
3.1.5.3.1. Lebenszyklus
3.1.5.3.2. Services, Prozesse und Threads
3.1.5.3.3. Interaktion mit Services
3.1.5.3.3.1. Local Service
3.1.5.3.3.2. Remote Service
3.1.5.4. Content Provider
3.1.5.4.1. Content Resolver
3.1.5.4.2. Adapter und AdapterViews
3.1.5.4.3. Content Provider und Datenhaltung
3.1.5.4.3.1. SQLite Datenbank
3.1.5.4.3.2. Implementierung des Content Providers
3.1.5.5. Android Manifest
3.1.6. Weitere Konzepte der Android Entwicklung
3.1.6.1. Location Based Services
3.1.6.2. Zugriff auf Hardware-Komponenten
3.1.6.3. Grafik
3.1.7. Socket-Programmierung in Android
3.1.8. Programmstruktur der Android Beispiel-Anwendung
3.2. iOS
3.2.1. System-Architektur
3.2.2. Laufzeitverhalten
3.2.2.1. Lebenszyklus einer iOS Anwendung
3.2.2.2. Sandbox und Datenaustausch
3.2.2.3. Multitasking und Interapplikations-Kommunikation
3.2.2.4. Memory Management
3.2.3. Entwicklungsumgebung und -Werkzeuge
3.2.3.1. Werkzeuge für das GUI-Design
3.2.3.2. Debugger und Simulator
3.2.4. Aufbau eines iOS-Projekts
3.2.5. Basiskonzepte der iOS-Entwicklung
3.2.5.1. Delegation
3.2.5.2. Target Action
3.2.5.3. Model View Controller
3.2.6. Socket-Programmierung in iOS
3.2.7. Programmstruktur der iOS Beispiel-Anwendung
3.3. Windows Phone
3.3.1. Windows Phone und Windows Mobile
3.3.2. System-Architektur
3.3.3. Laufzeitverhalten
3.3.3.1. Lebenszyklus einer Windows Phone Anwendung
3.3.3.2. Sandbox und Datenaustausch
3.3.3.3. Multitasking
3.3.4. Entwicklungsumgebung und -Werkzeuge
3.3.4.1. Werkzeuge für das GUI-Design
3.3.4.2. Debugger und Emulator
3.3.5. Aufbau eines Windows Phone Projekts
3.3.6. Basiskonzepte der Windows Phone Entwicklung
3.3.6.1. Datenbindung
3.3.6.1.1. Datenbindung zwischen GUI-Elementen
3.3.6.1.2. Datenbindung zwischen GUI-Element und Datenmodell
3.3.6.2. Model-View-ViewModel-Entwurfsmuster
3.3.7. Socket-Programmierung in Windows Phone
3.3.8. Programmstruktur der Windows Phone Beispiel-Anwendung

4. Vertrieb und Vermarktung
4.1. Der Markt der mobilen Applikationen
4.2. Monetarisierung
4.2.1. Geschäftsmodelle für mobile Applikationen
4.2.1.1. Pay-per-download
4.2.1.2. In-App Werbung
4.2.1.3. Premium Versionen und In-App Käufe
4.2.1.4. Abonnements
4.2.2. Umsatzerwartung
4.2.3. Lukrative App-Entwicklungsfelder
4.3. Vertriebsmöglichkeiten
4.3.1. Google Android Market
4.3.1.1. Spezifikationen
4.3.1.2. Veröffentlichung
4.3.2. Apple App Store
4.3.2.1. Spezifikationen
4.3.2.2. Veröffentlichung
4.3.3. Microsoft Windows Phone Marketplace
4.3.3.1. Spezifikationen
4.3.3.2. Veröffentlichung

5. Abschlussbetrachtung
5.1. Zusammenfassung und Vergleich
5.1.1. Allgemeine Kriterien und Merkmale
5.1.2. Entwicklungs-Umgebung und -Werkzeuge
5.1.3. Entwicklungskonzepte
5.1.4. Wirtschaftliche Kriterien und Merkmale
5.2. Fazit und Ausblick

Literaturverzeichnis

Abbildungsverzeichnis

Abb. 1: Betriebssysteme Marktanteile Q1/Q2, 2011

Abb. 2: Links Facebook-App, Rechts Facebook Web-App

Abb. 3: Architektur von Android

Abb. 4: Lebenszyklus einer Activity

Abb. 5: Kompilieren für JVM und DVM

Abb. 6: Integrierter Oberflächen-Editor für Eclipse

Abb. 7: Android Emulator-Konfiguration und -Oberfläche

Abb. 8: DDMS-Perspektive in Eclipse

Abb. 9: Anlegen eines Android-Projektes

Abb. 10: Cross-Compiling und Deployment

Abb. 11: Einbindung des Layouts in die Main-Activity

Abb. 12: Laden einer Menü-Struktur mit dem MenuInflater

Abb. 13: ListActivity mit ListView

Abb. 14: XML-Definition der PreferenceActivity-Elemente

Abb. 15: Toast-Benachrichtigung

Abb. 16: AlertDialog mit LayoutInflater

Abb. 17: Aufruf der IntentsDemo-Activity

Abb. 18: Auswahl-Dialog für passende Intent-Filter

Abb. 19: Service Lebenszyklus

Abb. 20: Application Not Responding Event

Abb. 21: Lokaler Service mit Direktzugriff

Abb. 22: Remote Service mit Messenger

Abb. 23: ListActivity und ContentProvider

Abb. 24: Berechtigungen der Demo-App

Abb. 25: Strukturplan der Android Demo-App

Abb. 26: Architektur von iOS

Abb. 27: iOS App-Lebenszyklus, Teil Launching-State

Abb. 28: iOS App-Lebenszyklus, Teil Background-State

Abb. 29: iOS App-Lebenszyklus, Teil Relaunch-State

Abb. 30: Xcode-Oberfläche mit Core Data Modellierung

Abb. 31: Interface Builder mit Window und Screens der Demo-App

Abb. 32: Verbindung von GUI-Element und Controller mit Interface Builder

Abb. 33: iPhone-Simulator und Konsole

Abb. 34: Projekttypen in Xcode

Abb. 35: MVC Entwurfsmuster

Abb. 36: Ein Screen der Navigation-based Einstellungen-App

Abb. 37: Interaktion von iOS und Android App

Abb. 38: Strukturplan der iOS Demo-App

Abb. 39: Windows Phone Architektur

Abb. 40: Lebenszyklus einer Windows Phone Anwendung

Abb. 41: Visual Studio 2010 Express for Windows Phone

Abb. 42: Aufnahme von Zuständen in Expression Blend

Abb. 43: Hinzufügen von Verhalten in Expression Blend

Abb. 44: Daten-/Element-Bindung in Expression Blend

Abb. 45: Beispieldaten in Expression Blend

Abb. 46: Windows Phone Emulator und Tools

Abb. 47: Interaktion von Windows Phone und Android App

Abb. 48: Programmstruktur der Windows Phone Demo-App

Abb. 49: Wachstum des App-Marktes

Abb. 50: application user base

Abb. 51: Top 5 Geschäftsmodelle

Abb. 52: Zahlungsbereitschaft für Apps

Abb. 53: Umsatzerwartung und Zufriedenheit

Abb. 54: Einnahmen je Plattform im Vergleich

Abb. 55: Umsatz durch In-App Verkäufe

Tabellenverzeichnis

Tab. 1: Smart Devices

Tab. 2: Web-Apps und Apps im Vergleich

Tab. 3: Beispiel für innovative Apps

Tab. 4: Android Projekt Struktur

Tab. 5: System Broadcast Intents

Tab. 6: Ergebnis einer ContentProvider-Abfrage

Tab. 7: iOS Projekt Struktur

Tab. 8: Windows Phone Projekt Struktur

Tab. 9: Kennzahlen des App-Marktes

Tab. 10: Google Android Market

Tab. 11: Aplle App Store

Tab. 12: Windows Phone Marketplace

Tab. 13: Vergleich der Plattformen

1. Einleitung

1.1. Motivation und Zielsetzung

Seitdem Apple im Sommer 2008 das erste iPhone vorstellte und zeitgleich die Pforten seines App Stores öffnete, befindet sich der Begriff „App“ in aller Munde. Apps, so nennen sich die kleinen Zusatzprogramme aus dem App Store, die auf das iPhone geladen werden konnten, um es so mit allerlei nützlichen und unnützen Funktionalitäten zu bereichern. Manche von ihnen schafften es sogar in das Fernsehen. So trug sicherlich auch der mediale Auftritt von Wasserwaage- und Barcode-Scanner-App, nicht unwesentlich dazu bei, dass die App-Wirtschaft einen rasanten, nicht enden wollenden Aufstieg erlebt. Mittlerweile tummeln sich mehr als 425.000 Apps, für jedes nur denkbare Anwendungsgebiet, in Apples App Store.

„Es gibt für fast alles eine App!“

So lautet der damals noch belächelte Werbeslogan der Firma Apple für die kleinen Zusatzprogramme. Mittlerweile spiegelt er die Realität erschreckend gut wieder.

Doch was genau sind Apps? Was unterscheidet sie von den Anwendungen, die auf stationären Desktop-Systemen beheimatet sind? Warum sind sie nicht zu verwechseln mit den mobilen Web-Apps, die ebenso oft einen Weg auf das Display des Smartphones finden? Und wie werden Apps überhaupt angefertigt, geschweige denn zu Geld gemacht?

Diese und weitere, sind die grundlegenden Fragen, dessen Beantwortung sich die vorliegende Diplomarbeit zum Ziel gemacht hat. Ein gewichtiger Schwerpunkt wird dabei auf dem Aspekt der Entwicklung von Apps liegen. Dabei wird allerdings nicht die Entwicklung unter Apples mobilem Betriebssystem iOS im Vordergrund stehen. Vielmehr wird der Fokus auf dessen schärfsten Konkurrenten gelegt werden, dem mobilen Betriebssystem Android der Firma Google. Dieses bietet, unter anderem auf Grund seiner durchweg offenen Systemschnittstellen, eine Vielzahl von interessanten Konzepten für die Realisierung von innovativen, mobilen Anwendungen.

Die vorgestellten Konzepte der mobilen Entwicklung, sollen anhand von, zu entwickelnden Demonstrations-Anwendungen für die Plattformen Android, iOS und Windows Phone, praxisnah veranschaulicht werden. Eine wesentliche Funktionalität dieser Demo-Apps soll in der Bereitstellung einer plattformübergreifenden TCP Client-Server Struktur liegen.

Das abschließende Untersuchungsfeld dieser Arbeit soll den App-Markt und seine wirtschaftlichen Kennzahlen zum Thema haben. Zusätzlich dazu sollen die Mittel und Wege vorgestellt werden, die es dem Entwickler ermöglichen, seine Apps für den Endkunden verfügbar zu machen. Auch die Frage nach den zu erwartenden Erlös-Dimensionen soll geklärt werden.

1.2. Vorgehen und Abgrenzung

Die schriftliche Ausarbeitung beginnt mit der Erläuterung der Grundlagen der mobilen Anwendungen. Dazu gehört neben der Definition des Begriffs „App“, auch die Vorstellung der mobilen Umgebung, welche aus den beherbergenden mobilen Geräten und den mobilen Betriebssystemen besteht. Es folgt eine Auseinandersetzung mit der Geschichte und den Charakteristika der Apps. Hierfür werden sie gegen Desktop-Anwendungen und Web-Apps abgegrenzt, bevor einige konkrete und innovative Beispiele, das Grundlagen-Kapitel abschließen.

Das dann folgende Kapitel beinhaltet den eigentlichen Kern der Arbeit. Es befasst sich mit der Entwicklung der mobilen Anwendungen auf einer grundlegenden Ebene. Aus der Menge der möglichen App-Plattformen werden drei Vertreter gewählt. Das ist zum einen der aktuelle Markführer und Initiator des App-Booms, Apple, mit dem mobilen Betriebssystem iOS. Zum anderen ist es der, bereits erwähnte, erfolgversprechendste Konkurrent Google, mit dem mobilen Betriebssystem Android. Ergänzt wird diese Runde durch einen aussichtsreichen Aufsteiger, das Betriebssystem Windows Phone der Firma Microsoft. Der Untersuchungsgang beinhaltet für alle drei Plattformen die Auseinandersetzung mit der System-Architektur, dem Laufzeitverhalten von Anwendungen, dem SDK und den Entwicklungswerkzeugen sowie den charakteristischen Basiskonzepten der Entwicklung.

Das Hauptaugenmerk dieser Diplomarbeit und des Entwicklungskapitels liegt auf dem Betriebssystem Android. Dieses wird etwa 60 Prozent dieser Arbeit vereinnahmen, während die anderen beiden Betriebssystem zu jeweils 20 Prozent vertreten sein werden. Dies zeigt sich insbesondere durch eine umfassende und vertiefende Behandlung der Entwicklungsgrundlagen für das Android System.

Die vorgestellten theoretischen Grundlagen der mobilen Entwicklung auf den einzelnen Plattformen werden, zum Zwecke der praxisnahen Veranschaulichung, von jeweils einer Demonstrations-Anwendung begleitet. Auch hier wird die Android-Anwendung den größten Umfang aufweisen. Die Anwendung ist in Form eines Tutorials aufgebaut, welches analog zur Vorgehensweise in der schriftlichen Ausarbeitung, eine schrittweise Vorstellung der fundamentalen Entwicklungskonzepte vorsieht. Darüber hinaus fungiert sie als TCP Server für die Entgegennahme von Steuerungsbefehlen an einen Musikwiedergabe-Service. Die entsprechenden Clients werden von den Windows Phone und iOS-Anwendungen repräsentiert.

Die Untersuchung des aktuellen App-Marktes und seiner zukünftigen Entwicklung, folgt im Anschluss an das Kapitel der Entwicklung. Hier werden insbesondere auch die Möglichkeiten und Monetarisierungspotentiale aufgezeigt, welche die offiziellen App-Vertriebskanäle für den Entwickler bereithalten.

Den Abschluss der Diplomarbeit bildet ein zusammenfassender Vergleich aller technischen und wirtschaftlichen Aspekte der vorgestellten Plattformen. Dieses Kapitel kann einem unschlüssigen Entwickler durchaus als Entscheidungshilfe dienen.

Da sowohl der Markt als auch die Entwicklungs-Plattformen der Apps einer hohen Dynamik unterworfen sind, soll im Folgenden eine Abgrenzung in Bezug auf die verwendete Technik vorgenommen werden.

- Google Android: Es wurde auf Grundlage der Version 2.2 des Betriebssystems gearbeitet. Für die Entwicklung kam ein HTC Desire HD zum Einsatz. Die aktuelle Version 2.3 sowie die Tablet-Versionen 3.x wurden nicht berücksichtigt.
- Apple iOS: Es wurde auf Grundlage der Betriebssystem Version 4.3 gearbeitet. Für die Entwicklung kam ein iPod Touch der vierten Generation zum Einsatz. Die iOS 5 beta Version sowie die jüngst erschienene, vollständig überarbeitete Version 4 der Entwicklungswerkzeuge, wurden nicht berücksichtigt.
- Microsoft Windows Phone: Grundlage der schriftlichen Ausarbeitung war die Version 7.0 des Betriebssystems. Auf Grund der massiven Einschränkungen dieser Version, insbesondere in Hinblick auf die Socket-Programmierung, wurde für die Entwicklung der Beispiel-Anwendung, die Beta-Version des SDKs für das kommende Windows Phone 7.1 Update, verwendet. Dementsprechend wird auch in der schriftlichen Ausarbeitung stellenweise auf die 7.1 Version vorgegriffen. Für die Entwicklung kam ein LG E900 Optimus 7 mit nachträglich aufgespielter Windows Phone 7.1beta Version zum Einsatz.

2. Grundlagen

2.1. Definition des Begriffs „App“

Der Begriff „ App “ ist die Kurzform für das englische Wort Application bzw. Application Software - zu deutsch also Applikations- oder Anwendungs-Software. Er beschreibt somit grundsätzlich jede Art von Anwendungsprogramm, ganz unabhängig davon, ob dieses nun auf einem Desktop-Computer, einem mobilen Endgerät oder auf einem anders gearteten IT-gestützten System läuft. Diese Abkürzung findet im EDV-Umfeld bereits seit Jahrzehnten Verwendung. Der Firma Apple ist es wohl zu verdanken, dass seit der Einführung des firmeneigenen App Stores im Juli 2008, zum Zwecke des Vertriebes von kleinen Zusatzanwendungen für das iPhone und den iPod Touch - den sogenannten Apps - die synonyme Verwendung des Begriffs „ App(s)“ für Anwendungen, welche für den Einsatz auf einem mobilen Endgerät konzipiert worden sind, mehr und mehr an Popularität gewinnt. Dementsprechend fallen heutzutage auch die Versuche einer Definition des Begriffs „ App“ aus:

„Substantiv, feminin oder Substantiv, Neutrum oder Substantiv, maskulin - zusätzliche Applikation, die auf bestimmte Mobiltelefone heruntergeladen werden kann“^[1]

„EDV, umgangssprachlich: Anwendung (meist kleines Programm für ein modernes Mobiltelefon)“^[2]

„The term has been used as shorthand for "application" in the IT community for decades. However, it became newly popular for mobile applications in smartphones and tablets…”^[3]

Programme, welche auf einem Mobiltelefon oder anderen mobilen Endgeräten laufen, können Ableger herkömmlicher Desktop-Programme sein, die für die mobile Nutzung lediglich recodiert und redesigned wurden, wie zum Beispiel E-Mail-Clients, Internet-Browser oder Office-Applikationen. Diese Programme unterscheiden sich von ihren Desktop-Pendanten in erster Linie dadurch, dass ihr Funktionsumfang und die grafische Benutzeroberfläche stärker eingeschränkt sind, also vergleichsweise „schlanker“ daherkommen. Interessanter sind jedoch zweifelsohne diejenigen Programme, welche ausschließlich auf mobilen Endgeräten sinnvoll eingesetzt werden können, da diese die spezifischen Hardware-Komponenten und/oder die Mobilität der Hardware voraussetzen, wie zum Beispiel Navigationssoftware, Ortsabhängige Dienste oder ein Barcode-/QR-Code-Scanner. Von der Menge der Apps hingegen abzugrenzen sind diejenigen Programme, welche für die softwaretechnische Umsetzung essentieller Systemfunktionen, wie das Telefonieren oder das Empfangen und Versenden von SMS, verantwortlich sind und bereits werkseitig in das Betriebssystem des jeweiligen mobilen Gerätes eingebettet werden.^[4]

An dieser Stelle soll ebenso eine kurze Abgrenzung von Apps gegen ihre größten Konkurrenten auf dem Markt der mobilen Anwendungen, den mobilen Web-Apps erfolgen. Web-Apps können den gewöhnlichen Apps sowohl optisch, als auch technisch bis ins kleinste Detail gleichen, weshalb hier für den Nutzer durchaus ein Verwechslungsrisiko entstehen kann. Im Gegensatz zu den gewöhnlichen Apps haben Web-Apps jedoch den nicht unerheblichen Vorteil der Plattform-Unabhängigkeit inne, da sie lediglich einen entsprechenden Browser, den nahezu alle mobilen Plattformen ab Werk mitliefern, für die Lauffähigkeit voraussetzen. In diesem Zusammenhang spricht man bei den Plattform-abhängigen Apps auch von den sogenannten nativen Apps.^[5] Native Apps sind an ihre jeweilige mobile Plattform angepasst und können nur mit Aufwand auf eine andere Plattform portiert werden. Gegenüber Web-Apps laufen sie jedoch sehr viel performanter und können alle Plattform-spezifischen Features ausnutzen.

Der Begriff „ App“, wie er im heutigen Sprachgebrauch verwendet wird, beschreibt also ein „schlankes“, zusätzliches Programm, welches dem Benutzer, über die Basis-/System-Funktionen des mobilen Endgerätes hinaus, einen Mehrwert liefert. Dabei ist es unerheblich, ob dieses Programm bereits im Auslieferungszustand vorinstalliert ist, wie es etwa bei Apps von Netzbetreibern, Geräteherstellern oder Plattformanbietern der Fall sein kann^[6], oder ob es erst über bestimmte Distributionskanäle bezogen werden muss, beispielsweise per Download aus einem App-Shop. Apps sind im Gegenteil zu ihren Konkurrenten, den mobilen Web-Apps, in der Regel Plattform-abhängig, also native Software.

2.2. Mobile Endgeräte

Die Hardware-Systeme, auf welchen die mobilen Apps ausgeführt werden, sind in der Regel mobile Endgeräte, wie etwa Mobilfunktelefone, Tablet-Computer (z.B. iPad) oder portable MP3-Player (z.B. iPod touch). Aus den verschiedenen Kategorien der mobilen Endgeräte, muss insbesondere die Gruppe der sogenannten Smartphones hervorgehoben werden, da diese, wie sonst keine andere Gerätegruppe, ein Initiator und Treiber des aktuellen und anhaltenden App-Booms ist. Unter dem Begriff „ Smartphone“ werden im weitesten Sinne alle modernen Mobilfunktelefone mit erweiterter technischer Ausstattung, wie zum Beispiel einer Kamera, einem GPS-Modul, diversen Sensoren sowie Computer-ähnlichem Funktionsumfang eingeordnet. Eine allgemein anerkannte und einheitliche Definition des Begriffs „Smartphone“ sowie eine eindeutige und überschneidungsfreie Abgrenzung des Smartphones zu den Vorläufer-Modellen, welche im englischen Sprachgebrauch auch unter dem Begriff „Feature Phones“^[7] zusammengefasst wurden, existiert jedoch bis heute nicht. Der Versuch einer Definition von Morgan Stanley im Rahmen einer Studie vom Dezember 2009 lautete folgendermaßen:

„We define a smartphone as a mobile device that in addition to performing basicphone functions (voice calls / SMS / contact database…):
- runs on an operating system

- has Internet / email access;
- provides a standardized interface and platform for application developers
- supports advanced digital functions like music, video, gaming, pictures, browsing, and messaging (some support navigation + mobile TV).”^[8]

Das Problem der Abgrenzung von Smartphones zu der Vorgänger-Generation dieses Gerätetyps, den Feature Phones, beschreibt Chetan Sharma in einer von GetJar in Auftrag gegebenen Studie treffend mit:

„While no one will confuse the current version of Apple’s iPhone or Google’s Nexus One to be featurephone or conversely a Motorola Razr or Nokia 2720 to be a smartphone, it is the middle category that is becoming more difficult to separate out.Consider devices like the Samsung Instinctwhich is a 3G device with capabilities for video, applications, emails, and with up to 8 GB, it can’t be confused for a featurephone, yet, since it is a Java phone, some might categorize it as a featurephone based on the platform.”^[9]

Festzuhalten ist also, dass die Grenze zur Unterscheidung von Smartphones zu den Mobiltelefonen mit vergleichsweise rudimentärerer Technik, fließend ist. Einhergehend mit dem technologischen Fortschritt und dem immer größer werdenden Funktionsumfang aktuellerer Geräte, werden zusehends auch Evolutions-Abstufungen innerhalb der Gruppe der Smartphones erkennbar. Marketingtechnisch wird dieser Umstand von den Herstellern oft dazu genutzt, die jeweils aktuellste Generation der Mobiltelefone als der Kategorie „ Superphones “ zugehörig zu propagieren, um sie so von der Gruppe der Smartphones abzuheben.

Smartphones können auch als Ergebnis der Symbioseaus Mobilfunktelefonen und PDAs gesehen werden. Dabei ist die Verschmelzung der Funktionalitäten beider Gerätetypen auf dem Smartphone nahezu vollständig gegeben, so dass eine Einzelanschaffung für den Anwender theoretisch obsolet wird.

Neben den, aus der Morgan Stanley Studie bereits zitierten, typischen funktionellen Merkmalen eines Smartphones, sieht die übliche technische Ausstattung eines Smartphones zum Zeitpunkt dieser Ausarbeitung folgendermaßen aus:^[10]

- Vergleichsweise große, hochauflösende Touch-Displays mit hoher Pixeldichte
- Virtuelle alphanumerische Tastaturen (HW-Tastaturen sind rückläufig)
- Prozessoren im Taktbereich um 1GHz und höher
- Interne Speicher mit Kapazitäten bis zu mehreren Gigabyte (z.T. extern erweiterbar)
- WLAN-, Bluetooth-, Infrarot-, USB-Schnittstellen
- Häufig eine Digitalkamera für Foto- und Video-Aufnahmen
- Sensoren, wie Beschleunigungs-, Lage-, Magnetfeld-, Licht- und Näherungssensoren
- Häufig einen GPS-Empfänger

Eine weitere Gruppe der mobilen Endgeräte, welche in jüngster Zeit hohe Aufmerksamkeit erlangt hat, ist die Gruppe der Tablet -Computer. Prominente Vertreter dieses Gerätetyps sind Apple’s iPad oder das Galaxy Tab von Samsung. Tablet-Computer sind technisch gesehen sozusagen die „großen Brüder“ der Smartphones, ausgestattet mit einem größeren Display und leistungsfähigerer Hardware, teilweise aber ohne Telefonie-Funktionen.^[11] Sie eignen sich, im Vergleich zu den Smartphones, besser für Display-lastige Anwendungen, wie etwa im Multimedia- oder Office-Bereich. Auf Grund der vielen Gemeinsamkeiten von Tablet-Computern und Smartphones, aber insbesondere auf Grund der Tatsache, dass auf vielen Tablet-Computern dieselben mobilen Betriebssysteme, wie auf den Smartphones laufen^[12], soll im Rahmen dieser Arbeit zwischen diesen beiden Gerätetypen keine differenziertere Betrachtung erfolgen. Häufig wird für App-fähige Gerätetypen, also Tablets, Smartphones oder andere Geräte, wie der iPod Touch, synonym der Begriff „Smart Devices“ verwendet.

Abbildung in dieser Leseprobe nicht enthalten

Tab. 1: Smart Devices ; eigene Darstellung

2.3. Mobile Betriebssysteme

Neben der zugrundeliegenden Hardware des jeweiligen Tablet-Computers oder Smartphones, ist das mobile Betriebssystem die zweite essentielle Komponente der App-fähigen Plattform. Das mobile Betriebssystem verwaltet alle Hardware-Komponenten und Systemfunktionen des mobilen Endgerätes und stellt entsprechende Schnittstellen, sowohl für Benutzer als auch für Programmierer zur Verfügung. Das mobile Betriebssystem unterscheidet sich von Desktop-Betriebssystemen primär in der Hardware, die es zu verwalten hat. Darüberhinaus grenzt es sich vor allem auch in den Anforderungen an die Performanz im laufenden Betrieb ab. Mobile Betriebssysteme müssen sehr viel effizienter und sparsamer im Umgang mit den knapperen System-Ressourcen sein, da jeder Overhead entweder mit höheren Materialkosten – zum Beispiel auf Grund der Notwendigkeit zusätzlichen Speichers oder eines schnelleren Prozessors – oder größerem Stromverbrauch bezahlt wird. Diese Aspekte sind ebenso bei der Programmierung von Apps wichtig und zu berücksichtigen, da es auch zu den Aufgaben des mobilen Betriebssystems gehört, nicht-performanten Programmcode zu unterbrechen, beziehungsweise komplette Anwendungsprozesse bei Ressourcen-Knappheit zu beenden.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 1: Betriebssysteme Marktanteile Q1/Q2, 2011 ; eigene Darstellung

Im Folgenden sollen zunächst die wichtigsten mobilen Betriebssysteme im Bereich der Smart Devices, kurz und mit Fokus auf ihre historische Entwicklung, vorgestellt werden. Dabei soll sich hier die „Wichtigkeit“ eines Betriebssystems anhand seines aktuellen weltweiten Marktanteils bemessen werden, welcher in Abb.1illustriert ist.

2.3.1. Google Android

Mit weltweit über 36 Millionen verkauften Android-Geräten im ersten Quartal 2011^[13] und weiteren 46 Millionen Geräten im zweiten Quartal^[14], was einem Marktanteil von aktuell 43,4 Prozent entspricht, ist Googles Android das sich aktuell am Besten verkaufende mobile Betriebssystem des Marktes. Laut einer Prognose des Marktforschungsinstitutes Gartner Inc. soll der Martkanteil von knapp 50 Prozent, bis in das Jahr 2015 gehalten werden können.^[15]

Androids Erfolgsgeschichte begann mit der Gründung des gleichnamigen Unternehmens durch Andrew Rubin im Oktober 2003. Ziel des Unternehmens war es, Software für Mobilfunktelefone zu entwickeln und dabei den Fokus auf standortbezogene Dienste zu legen.^[16] Im August 2005 wurde Android Inc. dann von Google übernommen. Ab diesem Zeitpunkt wurde klar, dass Google schon bald in den Markt der Mobilfunktelefonie einsteigen würde. Mit der Gründung der Open Handset Alliance im November 2007, einem von Google geführtem Konsortium bestehend aus diversen Software-Firmen, Netzbetreibern, sowie Geräte- und Hardware-Herstellern, wurden die Pläne für Googles Markteinstieg konkreter. Vorrangiges Ziel der OHA war die Entwicklung offener Standards für mobile Endgeräte. Das Hauptprodukt des Konsortiums wurde ein auf Linux basierendes Open-Source-Betriebssystem, welches flexibel und durch leichte Upgrade-Fähigkeit, für verschiedenste mobile Endgeräte einsetzbar sein sollte. Getauft wurde dieses Betriebssystem auf den Namen Android. Die erste Version von Android, wurde am 21. Oktober 2008 unter der Apache-Lizenz offiziell zur Verfügung gestellt. Das erste Gerät mit dem Android-Betriebssystem, das HTC Dream^[17], kam einen Tag später auf den Markt. Seitdem gab es bereits 13 Updates für Android. Zahlreiche Smartphone-Modelle unterschiedlicher Hersteller wurden mit Android ausgestattet. Aber auch Fahrradcomputer, automobile Boardsysteme, Netbooks oder Fernseher wurden mit Android als Betriebssystem bestückt. Die aktuellste Version ist die im Juli 2011 veröffentlichte Version 2.3.5 mit dem Namen Gingerbread. Die angepassten Versionen für Tablet Computer besitzen die Versions-Nummern 3.x, wovon Version 3.2 mit dem Namen Honeycomb die aktuellste ist. Im Oktober 2011 werden diese beiden Entwicklungslinien in der Version 4.0 zusammengeführt.

Technisch gesehen basiert Android auf dem Linux-Kernel 2.6, welcher für Android 1.0 jedoch stark modifiziert wurde. In der Regel werden Apps für Android in der Sprache Java geschrieben. jedoch gibt es die Möglichkeit für geschwindigkeitskritische Komponenten, nativen Code in C/C++ zu verfassen. Viele Bibliotheken von Android, wie zum Beispiel die OpenGL Grafikbibliothek, der auf WebKit basierende Browser oder die SQLite-Datenbank, liegen in C/C++ vor.

2.3.2. Apple iOS

Mit weltweit knapp 17 Millionen verkauften iOS-Geräten im ersten Quartal 2011^[18] und über 19 Millionen iOS-Geräten im zweiten Quartal^[19], was einem Marktanteil von 18,2 Prozent entspricht, rangiert Apples Betriebssystem iOS noch auf Platz drei hinter Google Android und Nokia Symbian. Auf Grund des anstehenden Umstiegs von Nokia auf das Betriebssystem Windows Phone von Microsoft^[20], bahnt sich in naher Zukunft jedoch ein Ende der Ära Symbian an. Gartner rechnet damit, dass iOS spätestens 2012 den zweiten Platz im Verkaufszahlen-Ranking von Symbian erben wird.^[21]

Auf Grund der strikten Geheimhaltungspolitik im Hause Apple, ist nur sehr wenig über den Entwicklungsprozess von iOS bekannt. Sicher ist, dass die Entwicklungsarbeiten an der ersten Version des Betriebssystems und des ersten iPhones, etwa im November 2005 begannen, nachdem Apple und der US-Netzprovider AT&T sich auf eine exklusive Zusammenarbeit einigen konnten. Am 9. Januar 2007 dann, stellte Steve Jobs auf der Macworld das Ergebnis dieser Zusammenarbeit erstmalig vor: das iPhone und die erste noch namenlose Version des iOS-Betriebssystems. Der Verkaufsstart folgte im Juni desselben Jahres und war ungeachtet der Tatsache, dass das Produkt sehr teuer war, nur in AT&Ts Edge-Netz lief und essentielle Technologien, wie Java und Flash, nicht unterstützte, ein durchschlagender Erfolg. Mit dem iPhone revolutionierte Apple den Smartphone-Markt und setzte einen de facto Standard, an welchem sich die Konkurrenten zukünftig messen lassen mussten.

iOS ist ein, für den mobilen Einsatz auf dem iPhone, optimiertes Derivat des Betriebssystems Mac OS X, welches wiederum von UNIX abstammt. Anders als, beispielweise das Android Betriebssystem von Google, ist iOS nicht quelloffen, sondern ein proprietäres, geschlossenes System. Apples restriktive Produktpolitik war auch ein Grund dafür, dass es in der ursprünglichen Version von iOS nicht vorgesehen war, außenstehenden Entwicklern die Möglichkeit einzuräumen, eigene Apps für das iPhone zu entwickeln. Erst im März 2008 wurde ein entsprechendes SDK in einer Beta-Version veröffentlicht und das Betriebssystem bekam darüberhinaus erstmals einen offiziellen Namen: iPhoneOS.

Programmiert werden Apps für iOS bzw. iPhones OS in der Sprache Objective-C, einem objektorientierten Ableger der Sprache C, welche von NeXT, einer von Steve Jobs gegründeten und später von Apple übernommenen Firma, im Jahre 1988 entwickelt wurde. Um das fertig entwickelte App auf einem physischen Gerät testen beziehungsweise auf den Verbrauchermarkt bringen zu können, wurde, damals wie heute, eine kostenpflichtige Entwickler-Lizenz benötigt. Außerdem durfte der iOS-Entwickler sein fertiges Produkt ausschließlich in Apples App Store veröffentlichen, welcher im Juli 2008 seine Türen öffnete. Trotz dieser Umstände, verhalfen zahlreiche „ 3rd party “-Entwickler, Apple zu einem nicht unerheblichen Erfolg des App Stores. Bis zum Ende des Jahres 2008 konnte Apple bereits über 500 Millionen Downloads bei 15.000 verfügbaren Apps im App Store verbuchen.^[22] Das innovative Geschäftsmodell des App Stores, sowie die Revolutionierung des Smartphone-Marktes mit der Einführung des iPhones, waren somit zweifelsohne die Haupt-Initiatoren des noch heute anhaltenden App-Booms.

Seit der Ersteinführung des Betriebssystems von Apple gab es mehrere Updates, darunter drei weitere major releases.Aktuell befindet sich iOS in der Version 4.3. Im Juni 2010 wurde der Name von iPhone OS in iOS geändert, da das Betriebssystem nunmehr nicht nur auf dem iPhone, sondern auch auf dem iPod Touch, dem iPad und AppleTV eingesetzt wurde. Ein Einsatz auf weiteren Geräten ist nicht vorgesehen.

2.3.3. Microsoft Windows Phone

Das jüngste hier untersuchte mobile Betriebssystem ist Microsofts Windows Phone, wenngleich es auf Grund seines Vorgängers Windows Mobile eine längere Vorgeschichte vorweisen kann. Der Marktanteil von Windows Phone ist zurzeit noch verschwindend gering. Jedoch muss berücksichtigt werden, dass Windows Phone Geräte erstseit Oktober 2010 erhältlich sind. Nicht zuletzt auf Grund der Ankündigung Nokias, ihr primäres Betriebssystem Symbian durch Windows Phone ersetzen zu wollen, verfügt das Microsoft-Produkt über enormes Wachstumspotential. Demzufolge sieht das Marktforschungsinstitut Gartner die Marktpositionierung von Windows Smartphones im Jahre 2015, mit prognostizierten 19,5 Prozent Marktanteil, an zweiter Stelle hinter Marktführer Google Android und vor Apple iOS.^[23]

Windows Phone ging aus Windows Mobile, einem Windows CE basiertem Betriebssystem, hervor, welches bereits seit 2002 auf verschiedenen mobilen Endgeräten eingesetzt wurde.Seit den Markteintritten von Apple und Google, mit ihren moderneren, benutzerfreundlicheren Betriebssystemen, verliert Windows Mobile beim privaten Endanwender jedoch rapide an Zuspruch und Bedeutung. Mit Windows Phone 7, welches weniger ein Upgrade zu Windows Mobile, als vielmehr eine komplette Neuentwicklung darstellt, möchte Microsoft den Rückstand auf die Innovations-Vorreiter Apple und Google zukünftig neutralisieren. Erreicht werden soll dies, aus Entwicklersicht, unter anderem durch einen verbesserten Entwicklungs- und Distributions-Support für eigene Apps, sowie aus Konsumentensicht, durch eine höhere Bedienbarkeit mit einem optisch ansprechenderem Design. Letzteres wurde durch eine standardisierte Oberfläche mit animierten Kacheln als Auswahlelemente realisiert. Das Design unterscheidet sich stark von den Konkurrenz-Produkten und darf von den Smartphone-Anbietern gar nicht oder nur marginal geändert werden.

Insgesamt vertritt Microsoft, wie auch Apple, eine sehr restriktive Produktpolitik. Wie das iOS von Apple, ist auch Windows Phone ein geschlossenes Betriebssystem. Darüber hinaus wird in Windows Phone, jede Art der nativen Programmierung verboten. Erlaubt ist lediglich managed code in Visual C# oder Visual Basic.NET.

2.3.4. Nokia Symbian

Der älteste Vertreter der hier aufgeführten mobilen Betriebssysteme ist Nokias Symbian, vor der kompletten Übernahme durch Nokia im Dezember 2008 auch unter dem Namen Symbian OS bekannt. Symbian OS entstammt dem mobilen Betriebssystem EPOC, welches seit den frühen 90er Jahren hauptsächlich für den Einsatz in PDAs entwickelt wurde. Seit 1998 trägt EPOC den Namen Symbian OS und entwickelte sich zu dem am weitesten verbreiteten Handy-Betriebssystem der nachfolgenden Jahre. Nach der Übernahme durch Nokia Ende 2008 änderte sich der Name letztmalig in Symbian und das Betriebssystem wurde seit Februar 2010, mit kurzweiliger Unterbrechung, unter einer Open Source Lizenz vertrieben. Im Februar 2011 kündigte Nokia an, künftig auf Symbian als Betriebssystem verzichten zu wollen und stattdessen nur noch Smartphones mit Microsofts Windows Phone zu vertreiben. Nokia-CEO Stephen Elop begründete diesen Schritt mit dem allzu großen technischen Rückstand der Symbian-Plattform gegenüber den Konkurrenz-Produkten. Eine Renovierung von Symbian würde zu viel Zeit und Geld in Anspruch nehmen.^[24] Aktuell rangiert Symbian auf einem komfortablen zweiten Platz im Verkaufsranking.InAbb.1 ist jedoch auch deutlich rückläufige Tendenz,auf Grund der steigenden Marktdominanz von Android und iOS, zu erkennen. Als Folge der strategischen Allianz von Nokia und Microsoft, dürfte der Marktanteil von Symbian schon in wenigen Jahren gegen Null tendieren.

2.3.5. Research In Motion Blackberry OS

Ein weiterer Dinosaurier im Smartphone-Markt ist die kanadische Firma Research In Motion, welche vor allem große Erfolge mit ihren Blackberry-Geräten verbuchen kann. Das Blackberry OS ist ein, in Java geschriebenes, proprietäres Betriebssystem, welches dank umfangreicher Unterstützung von E-Mail Funktionen, einen Wettbewerbsvorteil im Geschäftskundenbereich erlangen konnte. Weitere Wettbewerbsvorteile verschaffte sich RIM auch in den weiteren Büro-typischen Anwendungsgebieten, wie der Synchronisation von Terminen, Aufgaben, Notizen, Kontakten und weiteren Daten über den Blackberry Enterprise Server. Dieser diente darüber hinaus auch dazu, die komplette unternehmenseigene Blackberry-Infrastruktur zu verwalten. Das erste Blackberry mit Telefonfunktion erschien 2002. Seitdem haben Blackberrys im Unternehmenseinsatz, eine ähnlich erfolgreiche Laufbahn vorzuweisen, wie Symbian-Geräte im Privatanwender-Bereich. Im zweiten Quartal 2011 rangiert RIM mit über zwölf Millionen verkauften Geräten und einem Marktanteil von 11,7 Prozent auf Platz vier des Verkaufsrankings.^[25] Auf Grund der starken Konkurrenz, welche dem Blackberry auch die Vormachtstellung im Unternehmensbereich allmählich streitig macht, versucht RIM mit neuen Geräten und erweiterter Software vermehrt Privatanwender als Kunden zu gewinnen. Der jahrelange Verzicht auf den Einsatz von Touchscreens, welche sich mittlerweile als Smartphone-Standard etabliert und auf dem Massenmarkt durchgesetzt haben, führte unter anderem jedoch dazu, dass RIM immer mehr ins Hintertreffen gelangte.^[26] Die Prognosen von Gartner sagen voraus, dass sich der Marktanteil von RIM in den kommenden Jahren weiterhin leicht verringern wird, der vierte Platz aber auf Grund des noch schlechter prognostizierten Abschneidens von Symbian, gehalten werden kann.^[27]

2.4. Mobile Applikationen

Nach der einleitenden Definition des Begriffs „App“ und den grundlegenden Ausführungen zu den Themenbereichen „mobile Endgeräte“ und „mobile Betriebssysteme“, soll sich der folgende Abschnitt eingehender mit der Geschichte und den Charakteristika der mobilen Anwendungen auseinandersetzen. Es wurde bereits angeführt, dass ein App, jede Art von Software sein kann, welche dem Nutzer des mobilen Endgerätes, über die Basis- und Systemfunktionen hinaus, einen Mehrwert liefert. Neben der Möglichkeit, dass Apps bereits von Netzprovidern, Geräte-Herstellern oder den Plattform-Anbietern ab Werk vorinstalliert werden, können Apps auch nachträglich aus den plattformeigenen App-Shops bezogen werden.

Nach einem kurzen Exkurs in die Geschichte der mobilen Helferlein, soll im Folgenden untersucht werden in welchen Aspekten sich mobile Apps von ihren Desktop-Pendanten und den Web-Applikationen unterscheiden. Im Anschluss daran soll ein Versuch der Aufteilung und Kategorisierung des gegenwärtigen App-Universums unternommen werden. Im Zuge dessen werden auch einige innovative Beispiele aus der App-Welt vorgestellt.

2.4.1. Geschichte und Akzeptanz der mobilen Applikationen

Die Geschichte der Apps begann nicht erst mit der Öffnung des Apple App Stores im Sommer 2008, sondern bereits viele Jahre zuvor. Erste erfolgreiche Entwicklungs-Kits kamen Ende der neunziger Jahre mit Java ME und Anfang des neuen Jahrtausends mit BREW auf den Markt. Die damals geläufigen, plattform-unabhängigen Distributionskanäle für Apps waren zum Beispiel Handango seit 2000, und GetJar seit 2004. Während jedoch in den frühen Jahren Apps ein, von der Masse der Privatanwender, eher unbemerktes Schattendasein, in überwiegend unternehmerischen Gefilden fristeten, erlebte der Markt der mobilen Anwendungen in jenem Sommer 2008 den entscheidenden Wendepunkt. Plötzlich entstand ein, in dieser Form nicht zu erwarten gewesenes Interesse, nicht nur innerhalb des Fachbranche, sondern auch auf dem Massenmarkt. Binnen eines halben Jahres, seit der Öffnung des App Stores, konnte Apple bereits 15.000 Apps im Angebots-Katalog und über 500 Millionen Downloads für sich verbuchen. Zum jetzigen Stand, beziffert sich die Anzahl der verfügbaren Apps bereits auf mehr als 425.000 und die Anzahl der verbuchten Downloads auf mehr als 15 Milliarden.^[28] Ähnlich imposante Wachstumsraten konnten auch Apples ärgste Konkurrenten, darunter insbesondere Google, für sich verbuchen. Nach dem heutigen Stand, kann der Google Android Market, welcher im Oktober 2008 erstmals seine Türen öffnete, bereits über 260.000 Anwendungen^[29] bei über 5 Milliarden Downloads^[30] vorweisen.

Die Gründe für diese Renaissance der App-Wirtschaft sind vielschichtig. Aus Produzentensicht ist das durch Apple renovierte Vergütungs-Modell eines der ausschlaggebenden Gründe. 70 Prozent des Verkaufserlöses eines über den App Store veräußerten Apps, fließen direkt an den Entwickler, lediglich 30 Prozent behält Apple ein. Im Vergleich zu vormals gängigen Beteiligungs-Modellen, bei welchen der Entwickler mit nur rund zehn Prozent des Gesamt-Erlöses rechnen konnte, gewann das Handwerk der App-Entwicklung hiermit eine ganz neue Attraktivität.^[31] Der große Konkurrenz-Druck innerhalb des Plattform-Anbieter-Marktes und der daraus resultierende Kampf um die freien Entwickler, kamen letzteren ebenfalls dadurch zugute, dass Qualität und Quantität der Entwicklungs-Tools und des Entwickler-Supports beständig stiegen. Auch die signifikant verkürzte time-to-market Dauer, ermöglicht durch das direktere Vertriebsmodell der App Shops, verhalf zum Abbau von Hürden auf Entwicklerseite. Aus Konsumentensicht führten insbesondere der rasante technische Fortschritt bei den mobilen Endgeräten, angefangen bei Apples iPhone, als auch die, dank UMTS und HSDPA, höheren Übertragungsraten im Mobilfunknetz, zu einem verstärkten Bedarf an mobilen Content. Befriedigt wurde diese Nachfrage durch eine nach und nach immer größer werdende Bandbreite von Apps für jedes erdenkliche Anwendungsgebiet. Davon waren einige so innovativ und nützlich, dass sie erheblich zu einem positiven Image von Apps in der allgemeinen Wahrnehmung beitrugen. So ermöglichten Barcode-Scanner Apps den Anwendern einen sofortigen Online-Preisvergleich, während sie das entsprechende Produkt noch in der Offline-Welt in Augenschein nahmen, Navigations Apps machten mit dem entsprechenden GPS-Modul die Anschaffung eines teuren, separaten Navigations-Gerätes überflüssig, Musik-Erkennungs Apps halfen überall und zu jeder Zeit, das gerade gehörte Musikstück zu identifizieren.

Die hohe Akzeptanz und die tiefe Verflechtung von Smartphones und Apps in unserem Alltag, werden von einer jüngst veröffentlichten Studie „ The Mobile Movement “ von Google untermauert.^[32] Demnach geht Google davon aus, das bis Ende des Jahres 2011 jeder zweite erwachsene US-Amerikaner in Besitz eines Smartphones sein wird. 89 Prozent der Smartphone-Besitzer nutzen ihr Gerät mindestens einmal am Tag, um Dienste in Anspruch zu nehmen, die über die reinen Telefonie-Funktionen hinausgehen. Die drittbeliebteste Aktivität in diesem Zusammenhang ist, hinter dem „Surfen im Internet“ und der Online-Suche, die Nutzung von Apps. 68 Prozent der befragten Smartphone-Nutzer gaben an, innerhalb eines einwöchigen Beobachtungs-Zeitraumes mindestens einmal eine App genutzt zu haben. Interessant für die Konsumwirtschaft dürften insbesondere die Zahlen sein, die im Zusammenhang mit dem Kaufverhalten von Smartphone-Nutzern ermittelt wurden. So gaben 79 Prozent der befragten Nutzer an, ihr Smartphone schon einmal als Hilfsmittel für eine Kaufentscheidung herangezogen zu haben, sei es, um Informationen über Produkt und Shop zu erhalten, einen Online-Preisvergleich durchzuführen, oder um Einkaufsgutscheine herunterzuladen. Bei diesen Aktivitäten können natürlich entsprechende Apps assistieren, welche darüber hinaus auch den Bezahlvorgang zur Abwicklung bringen.

2.4.2. Abgrenzung zu Desktop-Anwendungen

Im Vergleich zu Anwendungen, welche speziell für den Desktop-Bereich entwickelt worden sind, fällt bei mobilen Applikationen zunächst auf, dass sie wesentlich „schlanker“ daherkommen. Oft umfasst der Funktionsumfang eines mobilen Apps, nur einen Bruchteil der Funktionen seines Desktop-Pendanten. So können beispielweise in QuickOffice, einer mobilen Variante gängiger Office-Software, zwar alle Basis-Funktionen, wie das Anzeigen, Bearbeiten und Speichern von Dokumenten, genutzt werden, jedoch bleiben weit darüberhinaus gehende Funktionen, wie umfangreiche grafische Visualisierungen oder der Einsatz komplex verschachtelter Excel-Formeln, weiterhin ausschließlich den Desktop-Programmen vorbehalten. Diese Funktions-Einschränkungen sind zum einen auf die spezifischen Hardware-Unterschiede zurückzuführen. Hersteller mobiler Systeme sind primär darauf bedacht, die Mobilität, die Handlichkeit und die Sparsamkeit im Stromverbrauch ihrer Geräte zu gewährleisten, so dass hier Einbußen in der Leistungsfähigkeit der Hardware-Ausstattung generell in Kauf genommen werden müssen. So ist es nicht weiter verwunderlich, dass selbst durchschnittliche Desktop-Systeme über wesentlich mehr physikalischen Speicher, höhere Prozessorleistung oder bessere Grafik-Performance verfügen, als die aktuellsten mobilen Systeme. Die größten Unterschiede sind jedoch bei den Ein- und Ausgabe-Komponenten erkennbar. Auf Grund der wesentlich reduzierteren Display-Größen und des Fehlens von ergonomisch akzeptablen Tastaturen oder Zeigegeräten, sind langwierige Arbeitssitzungen mit komplexen Ein- und Ausgaben an mobilen Geräten eher undenkbar. Apps sind daher auf kurze Eingaben und auf Ausgaben bedacht, die auf das Wesentliche reduziert sind.

Auf der anderen Seite gebieten aber auch die Nutzungsgewohnheiten von Besitzern mobiler Endgeräte, eine Einschränkung des Funktions-Umfangs von Apps. Die überwiegende Nutzung von Smartphones findet nebenbei und in der Regel kurz statt. So wird das Smartphone gerne beim Warten im Supermarkt, auf dem Weg zur Arbeit im Zug oder beim Abendessen zu Hause, aus der Tasche genommen, um schnell E-Mails abzurufen, Informationen und Nachrichten aus dem Internet zu beziehen, die sozialen Netzwerke abzuklappern oder eine Navigationsanfrage zu starten.^[33] Damit werden auch die Einsatzbereiche mobiler Apps in Abgrenzung zu den Desktop-Anwendungen klar.

„Niemand nimmt seinen Desktop-Rechner mit ins Auto, um sich an ein Fahrziel navigieren zu lassen. Im Umkehrschluss ergibt es keinen großen Sinn, Photoshop oder Word in all ihrer Leistungsvielfalt auf ein kleines mobiles Gerät zu bringen … Anders als bei Desktop-Anwendungen, die gerne mit der Zahl ihrer Features werben, ist auf mobilen Geräten schlicht und einfach nur Platz für das Wesentliche. Vergleichen Sie Ihre Anwendung mit einem Werkzeugkasten. Natürlich wäre es toll, im Urlaub immer den gesamten Werkzeugkasten dabei zu haben. Aber aus Platzgründen können Sie nur das Schweizer Offiziersmesser mitnehmen. Sie erwarten nicht, dass sich daran beispielsweise eine Lötlampe oder etwas ähnlich Exotisches befindet. Aber die wichtigsten Tätigkeiten sollten sich auch mit der mobilen Version des Werkzeugkastens erledigen lassen.“^[34]

Benutzer und Entwickler von mobilen Apps, sehen sich durch die minimierten Display-Größen und den neuartigen Eingabemethoden, ganz neuen Herausforderungen gegenübergestellt. Die im Vergleich zur stationären Hardware eher winzig ausfallenden Display-Dimensionen stellen spezielle Anforderungen an das Design mobiler Anwendungen. Das begrenzte Display darf nicht überladen werden. Sowohl die Navigationselemente als auch die eigentlichen Inhalte sind bei den mobilen Applikationen daher, wie schon erwähnt, auf das Wesentlichste beschränkt sein.Die sinnvolle, ergonomisch ansprechende Gestaltung des User Interfaces ist eine der größten Herausforderungen, denen ein Entwickler für mobile Software gegenübersteht, ganz besonders dann, wenn er sein App auf vielen unterschiedlich proportionierten Geräten mit unterschiedlichen Display-Auflösungen und Pixel-Dichten verfügbar machen möchte.

Während bei Desktop-Anwendungen, Eingaben bequem über Maus und physikalische Tastatur getätigt werden können, sieht sich der Anwender der mobilen Anwendungen zumeist einer Touch-Bedienung mit unterdimensionierter, virtueller Tastatur gegenüber. Hier ist höchstes Fingerspitzengefühl gefragt, um präzise Eingaben tätigen zu können.

Es bleibt noch zu erwähnen, dass viele mobile Systeme über Ausstattung verfügen können, die bei Desktop-Systemen keinen Sinn machen würde, wie etwa GPS-, Lage-, Beschleunigungs-Sensoren, eine Kamera oder einKompass. Darauf aufbauend resultieren Apps für Anwendungsfälle, die mit einem Desktop-System nicht abgedeckt werden können. Darunter fallen die bereits mehrfach erwähnten Navigationslösungen oder Code-Scanner, aber auch Spiele, die zum Beispiel die Nutzung der verschiedenen Sensoren in ihr Spielkonzept integrieren sowie „Augmented Reality“-Anwendungen, welche die aktuellen Kamera-Aufnahmen, beispielsweise um entsprechende Touristen-Informationen aus dem Internet bereichern.

2.4.3. Abgrenzung zu mobilen Web-Applikationen

Während eine Abgrenzung von mobilen Apps zu Desktop-Applikationen noch relativ leicht fällt, erfordert die Unterscheidung von Apps zu Web-Applikationen, und hier insbesondere zu den Web-Applikationen für den mobilen Einsatz, eine genauere Betrachtung. Es gibt zahlreiche Beispiele für Apps, welche stellenweise von ihren mobilen Web-Entsprechungen, optisch kaum mehr zu unterscheiden sind. In Abb.2ist dies anhand des Beispiels Facebook zu erkennen.

Abbildung in dieser Leseprobe nicht enthalten
Abb. 2: Links Facebook-App, Rechts Facebook Web-App ; eigene Darstellung

Die bereits zuvor erwähnten Design-technischen Herausforderungen bei der Erstellung von mobilen Apps, sind exakt dieselben, die es auch bei der Erstellung von mobilen Webanwendungen zu bewältigen gilt. Auch technisch gesehen können sich Apps und Web-Apps bis in das kleinste Detail gleichen. Um bei dem Beispiel Facebook zu bleiben: Beiden Anwendungstypen ist es möglich, auf die Kamera- und/oder GPS-Schnittstellen des mobilen Endgerätes zuzugreifen, um so den aktuellen Standort oder eine Kamera-Aufnahme im Facebook-Profil zu veröffentlichen. In Anbetracht dessen und vor dem Hintergrund der zunehmenden Fragmentation^[35] der mobilen Geräte, stellt sich natürlich die Frage, ob es nicht sinnvoller wäre, von vornherein eine Plattform-unabhängige Web-Anwendung anzubieten, anstatt native Apps für jedePlattform zu entwickeln. Diese Diskussion beschäftigt die Industrie schon seit längerer Zeit. In der folgenden Tabelle sind einige der ermittelten Vor- und Nachteile des Einsatzes von Web-Apps gegenüber nativen Apps aufgelistet.^[36]

Abbildung in dieser Leseprobe nicht enthalten

Tab. 2: Web-Apps und Apps im Vergleich ; eigene Darstellung

Es ist also zu erwarten, dass insbesondere in Performance-lastigen Anwendungsbereichen, wie zum Beispiel bei Grafik-intensiven Spielen, oder bei Anwendungen, die auf Systemkomponenten zugreifen, wie dem Barcode-Scanner, die Implementierung einer nativen Lösung seitens der Entwickler präferiert wird. Mit der Weiterentwicklung der heutigen Web-Technologien, speziell in Hinblick auf HTML5, aber auch mit den Möglichkeiten randständigerer Technologien, wie Javelin und WURFL, welche den oben skizzierten Funktionsumfang des Facebook-Web-Apps liefern, werden die Web-Lösungen in Zukunft noch mehr an Attraktivität gewinnen.

2.4.4. Kategorien und Beispiele innovativer Apps

Dieser Abschnitt soll sich der Vorstellung einiger konkreter App-Ideen widmen. Die schiere Masse an derzeit existierenden Apps soll dafür zunächst, der Übersicht halber, in Kategorien eingeteilt werden. Aus den einzelnen, ermittelten Kategorien soll eine Auslese besonders innovativer und/oder erfolgreicher App-Ideen getroffen werden, die im Anschluss vorgestellt wird.

Auf höherer Abstraktionsebene lassen sich Apps grob in drei Gruppen einordnen:

- Vernetzung/Information
- Produktivität
- Unterhaltung

Diese Kategorisierung nach dem Nutzwert von Apps wird bereits in verschiedener Fachliteratur angewandt.^[37]

Die Kategorie der Vernetzung/Information, umfasst diejenigen Apps, deren primäre Aufgabe es ist, dem Anwender schnellen Zugang zu Informationen jeder Art zu ermöglichen. Dies können beispielsweise Dienste für Nachrichten, Aktienkurse, Sportergebnisse, Wetter, Produktinformationen, Übersetzungen oder für standortbezogene Informationen sein. Auch Informationen den Status des eigenen sozialen Netzwerkes betreffend, also letztendlich alle Social-Media-Dienste, fallen unter diese Kategorie.

Eine Komplexitätsstufe darüber siedeln sich die Produktivitäts -Apps an, welche analog zu den Vernetzungs-/Informations-Apps ebenfalls den Zugang zu Informationen liefern können, deren primäre Aufgabe es jedoch ist, den Anwender in einem „Schaffens-Prozess“ zu assistieren. Dieser Schaffens-Prozess kann beispielsweise das Organisieren des alltäglichen oder des Arbeitslebens mit Hilfe von Terminplanern, To-Do-Listen, Adressbüchern oder komplexen Projektplanungs-Tools sein. Natürlich fallen ebenso Apps für die Erstellung von Briefen, E-Mails, Dokumenten oder anderweitigen Dateien in diese Kategorie. Auch die Erstellung von Navigationsrouten, sowie Apps, die den Anwender bei sportlichen Aktivitäten unterstützen, wie zum Beispiel Jogging-Tracker, sind der Kategorie Produktivität zugehörig. Letztendlich sind noch die praktischen Werkzeug-Apps zu erwähnen, welche das Smartphone in ein Schweizer Taschenmesser verwandeln, wie etwa Wasserwaage-, Taschenlampe- oder Zollstock-Apps.

Die dritte und bei Endverbrauchern wahrscheinlich beliebteste Kategorie, ist die Kategorie der Unterhaltungs -Apps. Selbstredend gehört jede Art von Spiel dieser Kategorie an. Musik-, Video- und TV-Apps, sowie E-Book-Reader sind der Kategorie ebenfalls zugehörig.

Diese Form der Kategorisierung erhebt keinen Anspruch auf Überschneidungsfreiheit. So kann ein E-Book-Reader, je nach Sichtweise, auch der Kategorie Information/Vernetzung, ein Social-Media-App hingegen ebenso der Kategorie Unterhaltung zugeordnet werden.

Eine weitere Möglichkeit der Einteilung orientiert sich an den Kategorien, welche sich die Anbieter der großen, plattformabhängigen App-Shops, also Google und Apple, für ihren Android Market bzw. App Store erdacht haben. Hier ist die Tiefe der Unterteilung ungleich größer, sodass jeweils mehr als 20 Kategorien zu Buche stehen. Beiden Plattformen ist aber gemein, dass die beliebteste Kategorie mit den meisten täglichen Downloads, die Kategorie der Spiele ist.

Im Folgenden sollen nun einige innovative Apps in tabellarischer Form vorgestellt werden. Neben den eigentlichen Basis-Informationen zum App selbst, werden auch die zugehörige Kategorie im jeweiligen Market/Store, sowie ein QR-Code, wenn vorhanden, für den direkten Download auf das eigene mobile Gerät zur Verfügung gestellt.

Abbildung in dieser Leseprobe nicht enthalten

Tab. 3: Beispiel für innovative Apps ; eigene Darstellung

3. Entwicklung

In diesem Kapitel soll der Fokus auf die Entwicklung der mobilen Applikationen gelegt werden. Die Vielzahl der verfügbaren Betriebssysteme und damit auch der einhergehenden Entwicklungssprachen, -Techniken, -Umgebungen und -Tools, erfordert eine Beschränkung der in dieser Arbeit zu untersuchenden Plattformen auf eine übersichtliche Auswahl. Die Auswahl beinhaltet die beiden meist beachteten Betriebssysteme Google Android und Apple iOS, sowie den „Aufsteiger“ Microsoft Windows Phone.

Eine umfassende oder gar vollständige Betrachtung aller entwicklungstechnischen Möglichkeiten dieser drei Plattformen würde den Rahmen dieser Arbeit bei Weitem sprengen. Die Untersuchung wird sich daher auf die fundamentalen, für das jeweilige Betriebssystem charakteristischen Konzepte begrenzen. Diese Grundkonzepte werden ausreichend sein um die grundlegende Funktionsweise des Betriebssystems zu verstehen und um eine Basis-Anwendungfür die jeweilige Plattform entwickeln zu können. Da in der Regel bekannte Programmiersprachen zum Einsatz kommen, wie zum Beispiel Java für Android, wird sich diese Ausarbeitung nicht mit den umfassendenMöglichkeiten und Besonderheiten dieser Sprachen auseinandersetzen.

Nachdem in Kapitel 2.3 bereits ein kurzer Einblick in die Historie der einzelnen Plattformen geschaffen wurde, soll im Folgenden zunächst ein Einblick in die Architektur der Systeme sowie eine Beschreibung der grundsätzlichen Funktionsweisen erfolgen. Daran anschließend erfolgt eine Betrachtung der jeweiligen Entwicklungsumgebung sowie der vom Hersteller angebotenen Entwicklungstools, ehe es zu der Vorstelllung der entwicklungstechnischen Grundprinzipien für die jeweilige Plattform kommt. Um diese Grundprinzipien praktisch zu verdeutlichen, wird für alle drei Plattformen eine Demonstrations-Applikation, entwickelt.

3.1. Android

3.1.1. System-Architektur

Android basiert auf einem Linux 2.6 Kernel, welcher zur Herstellung mobiler Einsatzfähigkeit bzw. mobiler Effizienz jedoch stark modifiziert wurde. So wurden zahlreiche Treiber und Bibliotheken, welche in ihrer ursprünglichen Form die begrenztmobile CPUund/oder den begrenzten Speicher zu sehr belasten hätten, grundlegend angepasst oder gar ersetzt.^[38] Unter anderem wurden Komponenten des Memory Managements, der Interprozess-Kommunikation und das Power Management umfassend überarbeitet.^[39] So musste das klassische Linux Power Management um Funktionen für die Überwachung und Regulierung des Akkuverbrauchs von mobilen Geräten erweitert werden. Das grunderneuerte Power Management schaltet beispielsweise die Hintergrundbeleuchtung der Navigationstasten an und aus, und reguliert automatisch die Helligkeit des Displays.

Der Kernel wurde des Weiteren um Treiber für spezifische mobile Hardware, wie den verschiedenen Sensoren, den Touchscreen oder der Kamera erweitert. Der modifizierte Linux-Kernel bildet die Basis-Schicht der Android-Architektur, wie auch anhand des folgenden Schaubilds verdeutlicht wird.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 3: Architektur von Android ;o.V.: Android Developers, 2011

Die Kernfunktionalitäten von Android werden über eine Vielzahl von Standard- C/C++ Bibliotheken bereitgestellt. So basiert zum Beispiel der Browser von Android auf der quelloffenen WebKit-Engine. Als Datenbanksystem kommt das allgemein bekannte und bewährte SQLite zum Einsatz. Für 2-D und 3-D Grafik-Anwendungen stehen jeweils die SGL und OpenGL-Bibliotheken parat. Die Schnittstellen der C/C++ Bibliotheken können direkt vom Anwendungsrahmen genutzt werden.

Der Anwendungsrahmen selbst bietet den Unterbau für jede Android-Anwendung. Aus den Komponenten des Anwendungsrahmens stellt sich der Entwickler seine eigene mobile Anwendung zusammen. Es stehen zahlreiche grafische Oberflächen-Elemente, wie Listen, Textfelder, Buttons oder Menüs zur Verfügung, aber auch ein Ressourcen Manager, welcher zum Beispieldie Binärdateien einer Anwendung verwaltet, ein Location Manager, welcher unter anderem den aktuellen Standort liefert, oder Content Provider, welche den Austausch von bestimmten Daten zwischen verschiedenen Anwendungen realisieren. Eine wichtige Rolle spielt der Activity Manager, welcher die Anwendung zur Laufzeit verwaltet und den Lebenszyklus der entsprechenden Anwendungskomponenten überwacht.

Die oberste Schicht der Android-Architektur umfasst sowohl die Android-eigenen Anwendungen, wie die Telefonie-Anwendung, den Home-Screen oder den Web-Browser, als auch die Anwendungen von Drittanbietern, zu denen auch die eigenen gehören.

Die Laufzeit-Umgebung von Android besteht aus den Android Kern-Bibliotheken, welche wiederum aus den DVM -spezifischen Bibliotheken, den Apache http-Client Bibliotheken und den Java-kompatiblen Kernbibliotheken besteht.^[40] Der Funktionsumfang dieser Java-kompatiblen Bibliotheken entspricht in etwa dem der Java Standard Edition, mit dem kennzeichnenden Unterschied, dass die Java Oberflächen-Pakete (AWT und Swing) durch Android-spezifische Oberflächen-Pakete ersetzt wurden. Das Herzstück der Laufzeitumgebung und der eigentliche Motor von Android ist jedoch die Dalvik Virtual Machine, kurz DVM. Auf Grund ihrer Bedeutung wird die DVM inAbschnitt 3.1.2.2etwas näher beleuchtet.

3.1.2. Laufzeitverhalten

3.1.2.1. Lebenszyklus einer Android Anwendung

Wie im Kapitel 3.1.5 noch deutlicher gezeigt wird, handelt es sich bei Android-Apps um komponentenbasierte Anwendungen. Eine Android-Anwendung kann, muss aber nicht, aus mehreren verschiedenen Komponenten zusammengesetzt sein, die weitestgehend unabhängig voneinander agieren bzw. Code ausführen. Dies bedeutet auch, dass jede Komponente ihren eigenen Lebenszyklus durchläuft.

Da der wohl größte Teil aller Android-Anwendungen eine direkte Interaktion mit dem Anwender erstrebt, wird zu diesem Zweck mindestens eine sogenannte Activity-Komponente implementiert werden. Diese beinhaltet eine Benutzeroberfläche und kann für die Verarbeitung der verschiedensten Benutzer- und System-seitigen Ereignisse herangezogen werden. Der Lebenszyklus einer Android-Anwendung kann am sinnvollstem anhand der Lebenszyklen ihrer Activity-Komponenten erläutert werden.

Der Lebenszyklus einer Activity beginnt mit dem onCreate()-Event bzw. Methodenaufruf, welcher in der Regel durch den Benutzer ausgelöst wird, und endet mit dem onDestroy()-Event. Dazwischen befinden sich diverse Pause- und Wiederaufnahme-Zustände, welche einen Kreislauf bilden. Zunächst soll dies an derAbbildung 3 verdeutlicht werden.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 4: Lebenszyklus einer Activity ;o.V.: Android Developer, 2011

- Gesamte Lebenszeit: Wie bereits erwähnt wird die gesamte Lebenszeit von den Methoden onCreate() und onDestroy() umschlossen. Die onCreate()-Methode muss in jeder Activity überschrieben werden. In ihr wirddie Benutzeroberfläche eingebunden und benötigte Ressourcen initialisiert, welche mit dem Aufruf von onDestroy() wieder freigegeben werden.
- Activity sichtbar, aber nicht im Vordergrund: Dieser Zustand liegt zwischen den Methoden onStart() und onStop(). Er tritt beispielsweise ein, wenn ein Popup in den Vordergrund tritt, wobei jedoch Teile der Activity immer noch für den Benutzer sichtbar bleiben.
- Activity im Vordergrund: Zwischen den Aufrufen von onResume() und onPause() ist einzig diese Activity sichtbar. Die Methode onPause() wird beispielsweise aufgerufen, wenn eine andere Activity gestartet und onResume() wenn zu dieser Activity zurückgekehrt wird.^[41]

Die Sicherung von Zustands-Informationen und Anwendungsdaten sollte bereits in der Methode onPause() erfolgen, da der Prozess einer Activity, die nicht mehr im Vordergrund ist, jederzeit vom System beendet werden kann, beispielsweise auf Grund eines auftretenden Ressourcenmangels.^[42]

Schliesst der Benutzer die Anwendung, führt er also die Main-Activity in den Zustand destroyed über, so wird der beherbergende Prozess nicht sofort beendet. Wie dies zu verstehen ist, wird im nachfolgenden Kapitel erläutert.

3.1.2.2. Dalvik Virtual Machine und Multitasking

Wie in der Historie bereits erwähnt, handelt es sich bei der DVM um ein hauseigenes Produkt von Google, welches einer Java Virtual Machine^[43] entlehnt ist und für den mobilen Einsatzoptimiert wurde.Einer der gravierendsten Unterschiede gegenüber einer gewöhnlichen JVM liegt in der Verwendung eines eigenen Bytecodes, dem Dalvik Executable Bytecode, kurz dex -Bytecode. Anwendungen für Android werden in der Regel in Java geschrieben und entsprechend in Java-Bytecode kompiliert. Das Tool „ dx “ übersetzt diesen Bytecode in dex-Bytecode, welcher von der DVM interpretiert werden kann und dank zahlreicher Optimierungen wesentlich kompakter ausfällt als die entsprechenden Java-class-Dateien.^[44]

Abbildung in dieser Leseprobe nicht enthalten

Abb. 5: Kompilieren für JVM und DVM ; Gargenta, Marko: Learning Android, 2011

Ein weiterer Unterschied findet sich in der zugrundeliegenden Architektur der DVM, welche im Gegensatz zu einer JVM nicht Stack-, sondern Register-basiert ist. Der Register-basierte Ansatz der DVM erlaubt es, die Register von Mikroprozessoren für Berechnungen über mehrere Zwischenschritte auszunutzen, so dass diese wesentlich schneller abgearbeitet werden können.^[45]

Des Weiteren wurde die DVM so konzipiert, dass mehrere Instanzen von ihr parallel und dabei Ressourcen-schonend ausgeführt werden können.Dies ermöglicht ein spezielles, Multitasking-fähiges Prozessmodell, in welchem jedem Anwendungs-Prozess eine eigene DVM zugeteilt werden kann.

Die Zuteilung übernimmt ein Systemprogramm namens zygote. Da der Initialisierungsvorgang, mit steigender Anzahl der laufenden Anwendungen, sehr viel Overhead erzeugt, beendet zygote Anwendungs-Prozesse und ihre DVM nicht sofort, auch wenn die entsprechenden Anwendungen vom Benutzer nicht mehr benötigt und daher geschlossen werden. Dieses Systemverhalten macht umso mehr Sinn, wenn berücksichtigtwird, dass Android-Anwendungen häufig aus mehreren Komponenten bestehen, die unabhängig voneinander gestartet und gestoppt werden können. Die entsprechenden Start-Vorgänge gehen schneller von statten, wenn der zugehörige Prozess samt DVM noch läuft.Anstatt einen Prozess also umgehend zu beenden, legt Android ihn auf einem Stack ab, welcher die laufenden Prozesse je nach Zugriffshäufigkeit geordnet hält. Prozesse, deren enthaltene Komponenten selten bis gar nicht mehr benutzt werden, also auch Anwendungen die vom Benutzer explizit beendet wurden, liegen im unteren Bereich des Stacks, während zuoberst, stets der Prozess der gerade angezeigten Komponente liegt. Erst wenn es im Laufe des Betriebes zu Ressourcen-Engpässen kommt, beginntAndroid damit, die untersten Prozesse im Stack zu beenden.

Da Activities keinen Code ausführen können sobald sie in den Hintergrund treten, wird für die Realisierung des Multitaskings stattdessen eine Service -Komponente verwendet, auf die näher in Kapitel 3.1.5.3 eingegangen wird. Aktive Services erhalten einen Anwendungs-Prozess am Leben, auch wenn alle zugehörigen Activities bereits beendet wurden. Mit den Techniken der Interprozess-Kommunikation^[46] können andere Anwendungen auf diesen Service zugreifen.

3.1.2.3. Sandbox und Datenaustausch

Einmal gestartet, wird einerAndroid-Anwendung eine recht exklusive Behandlung zuteil, die folgendes beinhaltet:

- Eineneigenen Prozess, welcher vom Systemprogramm zygote zugeteilt wird und ebenso die Prozess-eigene Dalvik Virtual Machine beinhaltet.
- Einen eigenen Betriebssytem-User. Dieses Vorgehen ist bereits aus dem komplexen Berechtigungskonzept der Linux-Welt bekannt.^[47]
- Einen eigenen, abgeschotteten Bereich im Hauptspeicher des Gerätes, den sogenannten Heap.
- Einen eigenen, abgeschotteten Bereich im Dateisystem des Gerätes.

Diese nahezu vollständige Separierung der Anwendung, auch als Sandbox -Prinzip bekannt, erzeugt zwar viel Overhead und entspricht so gar nicht der Ressourcen-Sparsamkeits-Maxime in der mobilen Entwicklung, ermöglicht dafür jedoch eine hohes Sicherheits-Niveau der Anwendungen und insbesondere der Anwendungsdaten. So beendeteine sterbende Anwendung zum einen nur den eigenen Prozess, ohne dabei andere laufende Prozesse in Mitleidenschaft zu ziehen und zum anderen wird der unerlaubte externe Zugriff auf den internen Speicherbereich bzw. auf die internen Daten einer Anwendung unterbunden.Der Zugriff auf, bzw. der Austausch von Anwendungseigenen Daten erfolgt über ein explizites Berechtigungssystem. Derzeit existieren drei Wege, um Daten für externe Anwendungen zur Verfügung zu stellen.

Zum Ersten können Daten natürlich explizit in einem Bereich abgelegt werden, auf welchen jede Anwendung bzw. jeder Prozess Zugriff hat. Dies ist zum Beispiel bei externen Speichermedien, wie SD-Karten, der Fall.

Die zweite Möglichkeit liegt in der Deklaration und Vergabe einer sogenannten sharedUserID. Anwendungen mit derselben sharedUserID laufen im selben Prozess, unter demselben Betriebssystem-User in derselben DVM, also in ein und derselben Sandbox. Sie können entsprechend auf den gemeinsamen, internen Speicherbereich zugreifen und so Daten untereinander austauschen. Die sharedUserID wird in den jeweiligen Manifest -Dateien^[48] der zugehörigen Anwendungen deklariert. Im folgenden Programmcode ist dies beispielhaft skizziert.

<manifest

package=“de.fhwedel.androidapp“

android:sharedUserId=“de.fhwedel“>

…

</manifest>

Diese Anwendungen müssen zusätzlich vom selben Hersteller zertifiziert worden sein. So wird verhindert, dass mittels gestohlenersharedUserID, private Daten durch eine externe Anwendung ausgespäht werden können.

Die dritte Möglichkeit besteht in der Bereitstellung eines sogenannten Content Providers. Ein Content Provider ist eine der Grundkomponenten des Android Frameworks und wird in einem der folgenden Kapitel noch näher untersucht werden.^[49] Der Content Provider stellt auf Anfrage, eine bestimmte, vom Programmierer vorab selbst definierte Menge von Daten zur Verfügung. Systemeigene Content Provider stellen beispielweise die Inhalte der Kontakte- oder der Terminkalender-Anwendung zur Verfügung. Die Deklaration des Content Providers findet ebenfalls in der Manifest-Datei der entsprechenden Anwendung statt. Die Implementierung erfolgt durch den Anwendungs-Entwickler als eigenständige Java-Klasse.

3.1.3. Entwicklungsumgebung und -Werkzeuge

Obwohl theoretisch jede integrierte Entwicklungsumgebung für die Android-Entwicklung verwendet werden kann, solange sie nur Java unterstützt, ist es ratsam, das von Google empfohlene und offiziell unterstützte Eclipse zu nutzen. Die quelloffene Eclipse IDE wurde im Jahre 2001 ursprünglich für die Java-Programmierung entwickelt, unterstützt aber mittlerweile, dank der Erweiterbarkeit über Plug-Ins, eine Vielzahl von weiteren Programmiersprachen. Eclipse erfreut sich unter Java-Programmierern einer hohen Beliebtheit und verfügt über einen enormen Funktionsumfang, der hier nicht bis ins Detail erläutert werden soll.

Weiterhin wird für die Entwicklung von Android-Apps natürlich das Android Software Development Kit^[50] benötigt. Im Lieferumfang des SDK enthalten ist das„ SDK and AVD (Android Virtual Devices) Manager “-Tool, mit dessen Hilfe es möglich ist, das SDK laufend um neue Komponenten oder Dokumentationen zu erweitern. Hier lassen sich beispielsweise bequem neuere Versionen des SDKs, die Google Maps APIs oder ein vorkonfigurierter Emulator für das Samsung Galaxy Tabbeziehen. Weitere Tools, die mit dem SDK mitgeliefert und im Laufe der Anwendungs-Entwicklung häufigeingesetzt werden:

- Dalvik Debug Monitor Server (ddms): Ermöglicht das Debuggen einer Android-Anwendung.
- Android Emulator (emulator): Emuliert eine „echte“ Android Laufzeit-Umgebung. Die Rahmenbedingungen der Laufzeit-Umgebung lassen sich individuell konfigurieren und abspeichern.
- Android Debug Brigde (adb): Ein vielseitiges Kommandozeilen-Tool, welches die Verbindung zu einem Android-Gerät oder dem Emulator herstellt und kontrolliert.
- Logcat: Teil des adb-Tools zur Übertragung von Systemmeldungen des Gerätes oder Emulators im Debug-Modus.
- Android Asset Packaging Tool (aapt): Dieses Tool wird unter anderem während des Build-Prozesses automatisch eingesetzt, um die vollständige Installationsdatei einer Anwendung zu erstellen: *.apk.
- dx: Dieses Tool wird ebenfalls im Build-Prozess automatisch eingesetzt um die Java-Klassen in dex-Bytecode umzuschreiben.

Sofern Teile eines Apps in nativen C/C++ Code verfasst werden sollen, muss auchdas Native Development Kit^[51] bezogen werden. Das NDK kann nur in Verbindung mit dem SDK eingesetzt werden, so dass es nicht möglich ist eine Android-Anwendung ausschließlich in nativer Sprache zu verfassen. Google weist darauf hin, dass eine Verwendung von nativem Code nicht immer zu einer Performanz-Steigerung führen muss, aber in jedem Fall in eine Komplexitäts-Steigerung der Anwendung resultiert.^[52]

Um mit dem Android SDK, Anwendungen in Eclipse entwickeln zu können werden noch die Android Development Tools, kurz ADT, benötigt. ADT ist als plug-in für Eclipse erhältlich und ermöglicht neben der bequemen Erstellung von Android-Projekten, außerdem das Designen einer grafischen Benutzeroberfläche mittels eines Editors, das Debuggen zur Laufzeit unter Zuhilfenahme der SDK Tools, sowie den Zertifizierungs- und Distributionsprozess für das auszuliefernde App.

Um ein Android-Projekt unter Windows auf einem Hardware-Gerät testen zu können, wird außerdem noch ein entsprechender USB-Treiber für das Gerät benötigt. Dieser ist bei dem jeweiligen Hersteller erhältlich.

3.1.3.1. Werkzeuge für das GUI-Design

Der grafische Oberflächen-Editor für Android-Anwendungen wird mit den Android Development Tools mitgeliefert und direkt in die Entwicklungsumgebung von Eclipse integriert.

Die Bearbeitungsfläche zeigt einen Screen der Anwendung an, wie ihn in etwa der Benutzer auf dem physischen Gerät präsentiert bekommt. Aus der umfangreichen Library / Palette im linken Bereich lassen sich alle typischen GUI-Elemente des Android-Frameworks, wie Textfelder, Eingabefelder, Image-Views, Buttons und so weiter, per Drag and Drop in den Screen hinein platzieren. Im rechten Bereich wird standardgemäß die Layout-Struktur bzw. die View-Hierarchie des aktuellen Screens angezeigt. Oberhalb der Bearbeitungsfläche lassen sich dann noch Einstellungen vornehmen, um unterschiedliche Display-Größen/-Auflösungen, Plattform-Versionen und Systemeinstellungen zu simulieren. Des Weiteren lassen sich per Rechtsklick auf die eingepflegten GUI-Elemente, die spezifischen Eigenschaften, wie etwa Größe, Füllung, Schriftfarbe und so weiter, anzeigen und modifizieren.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 6: Integrierter Oberflächen-Editor für Eclipse ; eigene Darstellung

Anders als bei eigenständigen Oberflächen-Gestaltungs-Tools, wie etwa denen für iOS und Windows Phone, ist der integrierte Editor für Android-Oberflächen etwas behäbig und umständlich in der Bedienung. Nicht immer lassen sich GUI-Elemente bequem in die gewünschte Position und Darstellungsform bringen. In vielen Fällen ist der Designer besser beraten, manuelle Anpassungen im zugehörigen XML-Code vorzunehmen oder den Layout-Entwurf gar vollständig in Code-Form anzulegen.

Auch wenn eine Vielzahl von Anzeigemodi für die Vorab-Betrachtung des Layouts zur Verfügung stehen, so kann der Designer sich nie hundertprozentig sicher sein, dass sein Layout auf der Vielzahl der unterschiedlichen, physischen Android-Geräte, auch tatsächlich so angezeigt wird, wie er es vorgesehen hat.

Es lässt sich jedoch positiv anmerken, dass in zeitlich kurzen Abständen immer wieder Updates der Android Development Tools und damit auch Verbesserungen für den grafischen Oberflächen-Editor herausgegeben werden. So wurde erst im Juni dieses Jahres ein Update veröffentlicht, welches beispielsweise den Einsatz von eigenen View-Elementen oder das Gruppieren von mehreren View-Elementen ermöglicht. Funktionalitäten, welche die Arbeit mit dem Editor doch erheblich erleichtern.

Dem Android-Designer steht es zudem frei, Drittanbieter-Design-Tools zu verwenden. An dieser Stelle sei zum Beispiel das DroidDraw -Tool genannt, welches sich, dank des Einsatzes von Java-Applets, online nutzen lässt.

Weitere Grafik-Werkzeuge, die im Android SDK mitgeliefert werden, sind:

- HierarchyViewer: Ermöglicht die visuelle Darstellung der View-Hierarchy einer Activity bzw. des Layouts einer Activity. Ebenso können hier die Eigenschaften einzelner Views untersucht und das grafische Ergebnis des Layouts mit beliebiger Vergrößerung erzeugt werden.

- Draw-9-patch: Für die Erzeugung einer sogenannten NinePatch-Grafik, die nur in bestimmten Pixel-Bereichen automatisch skaliert. Die Hintergrund-Grafik der Demo-Applikation ist beispielweise eine NinePatch-Grafik. Nur der Bereich außerhalb des Logos wird auf die verwendete Display-Größe skaliert. Außerdem kann mittels Draw-9-patch festgelegt werden, in welchen Bereichen der Grafik Content gezeichnet werden darf. So können ungünstige Überlagerungen verhindert werden, ohne dass Margin- oder Padding-Angaben für den Content-Bereich eingesetzt werden müssen.

3.1.3.2. Debugger und Emulator

Das bereits kennengelernte Tool SDK and AVD Manager, welches für das Updaten des SDKs und aller assoziierten Komponenten benötigt wird, beherbergt außerdem die Funktionen zur Konfiguration und Inbetriebnahme eines oder mehrerer QEMU -basierten Emulatoren (Android Virtual Devices).

Ein Emulator kann anhand eines vorkonfigurierten AVD -Pakets neu erstellt werden. So lässt sich über den SDK and AVD Manager bereits ein offizielles AVD-Paket für das Samsung Galaxy Tab beziehen, welches dahingehend konfiguriert wurde, dass es dem physischen Gerät so weit wie möglich gleicht. Ein weiterer Weg führt über die Neuerstellung anhand von manuellen Konfigurationen. So können neben der Version des zu emulierenden Betriebssystems, Parameter wie die Größe der Speicherkarte, die Größe des RAMs, Display-Auflösung oder die Aktivierung der GPS-Emulation eingestellt werden.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 7: Android Emulator-Konfiguration und -Oberfläche ; eigene Darstellung

Die Verbindung zum Emulator wird, genauso wie die Verbindung zu einem über USB angeschlossenem physischen Gerät, von dem Tool android debug bridge, kurz adb, hergestellt und überwacht. Jede Form der Kommunikation zwischen Emulator und dem Desktop-System wird über adb automatisch realisiert.

Diesen Umstand nutzt auch das Tool Dalvik Debug Monitor Server, kurz DDMS, welches das primäre Tool zum Debuggen von Android-Anwendungen darstellt. DDMS verfügt über eine grafische Benutzeroberfläche, welche direkt in Eclipse integriert ist. Die folgende Abbildung zeigt die DDMS-Perspektive in der Eclipse IDE.^[53]

Abbildung in dieser Leseprobe nicht enthalten

Abb. 8: DDMS-Perspektive in Eclipse ; eigene Darstellung

Im Devices-Bereich der DDMS-Perspektive sind die aktuell aktiven Geräte und Emulatoren, sowie ihre laufenden Prozesse angezeigt. Im Bereich rechts können unter anderem die zugehörigen Threads und der Heap analysiert werden. Des Weiteren bietet die DDMS-Perspektive einen FileExplorer der sich auch dazu nutzen lässt, Dateien vom und zum Gerät zu kopieren.^[54]

Der Bereich EmulatorControl wird dazu verwendet, um Anrufe, SMS-Nachrichten und sogar GPS-Positionsdaten zu simulieren, welche über adb an den Emulator gesendet werden.

Im untersten Bereich befinden sich die Ansichten für die Debug-Ausgabe. Hier sollte auch die Log Catalog -, oder kurz LogCat -Ansicht, zu finden sein.^[55] In der LogCat-Ansicht werden alle Status-Meldungen des angeschlossenen Systems ausgegeben. Um eigene Statusmeldungen ausgeben zu lassen, empfiehlt sich der Einsatz des Log()-Befehls.^[56]

Die aus dem Umgang mit IDEs bekannten Debug-Techniken, wie das Setzen von Breakpoints, das Inspizieren von Variablen-Inhalten oder die Schritt-für-Schritt Ausführung von Programmcode, sind durch die Eclipse-Standardfunktionen abgedeckt.

Neben den bereits genannten Tools, liefert das SDK noch das TraceView -Werkzeug mit. TraceView ist ein Tool zur Performance -Messung. Es erzeugt eine grafische Zeitleiste, anhand derer gezeigt wird, wann welche Methodenaufrufe in welchen Threads/Prozessen erfolgt sind und wie lange diese zur Abarbeitung gebraucht haben.

Da der vollständige Source-Code aller Android-Pakete nicht im SDK enthalten ist, können beim Debuggen von Anwendungen Fehlermeldungen der Form „Source not found“ bzw. „android.jar has no source attachment“ auftreten. Um den Quellcode verfügbar zu machen, existieren eine Vielzahl von Anleitungen im Web. Zu empfehlen ist insbesondere die Vorgehensweise, die Sayed Hashimi in seinem Buch Pro Android 3 beschreibt.^[57]

3.1.4. Aufbau eines Android-Projekts

Nachdem alle Voraussetzungen für die Entwicklung einer Android-Anwendung geschaffen worden sind, kann ein Android-Projekt in Eclipse, mit Hilfe des mit den Android Development Tools mitgelieferten Project-Wizards, erstellt werden. Bei der Erstellung des Projektes muss zunächst ausgewählt werden, welche Version der Android-API mindestens unterstützt werden soll. Für die Demo-Anwendung wurde die API-Version 8, bzw. Android 2.2 gewählt.^[58] Neben einer Bezeichnung für das Android-Projekt, werden außerdem noch der Paketname, sowie optional der Name für die Einstiegs-Activity angegeben.In der Regel bietet jede Anwendung eine grafische Benutzeroberfläche an, so dass jede Anwendung entsprechend mindestens eine Activity, die Einstiegs-Activity, implementieren muss.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 9: Anlegen eines Android-Projektes ;eigene Darstellung

Die für ein vollständiges Android-Projekt mindestens benötigte Projekt-Struktur, wird mit Hilfe des ADT-Plugins automatisch hergestellt. Alle beinhalteten Verzeichnisse und Dateien sind in der folgenden tabellarischen Aufstellung kurz erläutert.

Abbildung in dieser Leseprobe nicht enthalten

Tab. 4: Android Projekt Struktur ; eigene Darstellung

Die Ressourcen-Dateien werden bereits zur Entwicklungszeit automatisch vom aapt-Tool vorkompiliert und in der R-Klasse indexiert. Die Index-Klasse R ist entsprechend der Verzeichnisstruktur im Ordner /res/ aufgebaut. Sie liefert auf Anfrage die Speicheradresse einer bestimmten Datei im Ressourcen-Paket. Der Speicherorteiner beispielhaften MP3-Datei music.mp3 im Verzeichnis /res/raw/ wird demnach folgendermaßen ermittelt:

int res_index = R.raw.music;

Die Speicheradresse kann zum Beispiel vom Android MediaPlayer dazu genutzt werden, um die hinterlegte Datei abzuspielen:

mplay = MediaPlayer.create(this,res_index);

mplay.start();

Soll der Inhalt einer Speicheradresse im Ressourcen-Paket direkt ausgelesen werden, so bietet sich die Methode getResources() an:

String inhalt = getResources().getString(R.string.inhalt);

Die Identifier die in R.string enthalten sind, verweisen auf die, in der Datei /res/values/strings.xml definierten Strings.Häufig Verwendung findet auch das Unterverzeichnis R.id. Hier sind alle XML-Elemente indexiert, welche ein Attribut mit dem Namen id spezifiziert haben. Über die ID kann später ein programmatischer Zugriff auf das zugehörige Element erfolgen.

Wie bereits gezeigt wurde, wird während des Build-Prozesses, der erzeugte Java-Bytecode in DVM-kompatiblen dex-Bytecode umgewandelt. Für diesen Cross-Compiling-Vorgang ist das Tool dx zuständig. Das Tool aapt, welches bereits zur Entwicklungszeit die R.java Klasse erzeugt und die zugehörigen Ressourcen-Dateien integriert, wird auch während des Build-Prozesses noch einmal tätig. Es fügt die dex-Datei, die Manifest-Datei und das Ressourcen-Paket zu einer einzigen apk-Datei zusammen, welche auf dem Android-Gerät installierbar ist. Der Cross-Compiling- und der Deployment-Vorgang sind in demfolgenden Schaubild grafisch dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 10: Cross-Compiling und Deployment ;o.V.: Android Wiki-Book, 2011

Die apk-Datei der Anwendung wird in dem geschützten Verzeichnis /data/^[61] und dort im Unterverzeichnis /app/, im internen Speicher des mobilen Gerätes installiert. Die Anwendungsdaten der App bekommen einen eigenen, vom Zugriff durch andere Anwendungen geschützten Speicherbereich im Verzeichnis /data/data/.^[62]

3.1.5. Basiskonzepte der Android-Entwicklung

Das Android-Framework ist auf Komponenten-basierte Anwendungsentwicklung ausgerichtet. Es werden vier Grund-Komponenten angeboten, aus denen sich jede Android-App zusammensetzen lässt, ohne jedoch dabei alle vier Komponenten enthalten zu müssen. Die Komponenten sind als eigene Java-Klassen implementiert, können jeweils einzeln instanziiert und als Programm-Einstiegspunkte verwendet werden. Es handelt sich um die Klassen Activity, Service, ContentProvider und BroadcastReceiver.Ein wichtiges Verbindungsstück zwischen diesen Komponenten sind die sogenannten Intents. Sie werden benötigt um zwischen den unterschiedlichen Teilen einer Anwendung hin und her zu wechseln. Weiterhin von Bedeutung ist die obligatorische AndroidManifest.xml Datei. Sie ist sozusagen das Inhaltsverzeichnis der Anwendung und enthält Applikationsweite Konfigurations-Parameter. Im Folgenden sollen die zentralen Konzepte des Android-Frameworks näher erläutert werden.

3.1.5.1. Activities

Die wohl wichtigste Rolle im Android-Framework spielt die Activity-Komponente. Sie entspricht im Regelfall genau einem Screen der Anwendung und kann somit alle typischen GUI-Elemente, wie Buttons, Textfelder, Eingabefelder, Auswahllisten und so weiter enthalten. Das Layout wird jedoch nicht direkt in der Java-Klasse der Activity , sondern in einer gesonderten XML-Datei definiert, vom aapt-Tool vorkompiliert^[63] und anschließend dann in der onCreate()Methode der Activity mittels setContentView() eingebunden.

[...]

---

^[1] o.V.: Duden online: App, 2011

^[2] o.V.: Wiktionary: App, 2011

^[3] o.V.: PCMag: App, 2011

^[4] Also die Systemprogramme.

^[5] Lat. Nativus: “angeboren, natürlich”.

^[6] Beispiel für Netzbetreiber: MeinVodafone App, Gerätehersteller: HTC Hub App, Plattformanbieter: Google Maps App.

^[7] Siehe o.V.: Oxford Dictionaries: feature phone, 2011

^[8] Meeker, Mary u.a.: The Mobile Internet Report, Morgan Stanley, 2009, S.110

^[9] Sharma, Chetan: Sizing up the global apps market, 2010, S.7

^[10] Stand: Mai 2011

^[11] Anm.: Das Galaxy Tab bspw. hat Telefonie-Funktionen, Apples iPad und das Motorola Xoom hingegen nicht.

^[12] Galaxy Tab: Android, iPad: iOS

^[13] Vgl. Pettey, Christy: Gartner Market Share Analysis: Mobile Devices, Worldwide, 1Q11, 2011

^[14] Vgl. Pettey, Christy: Gartner Market Share: Mobile Communication Devices by Region and Country, 2Q11, 2011

^[15] Vgl. Pettey, Christy: Gartner Forecast: Mobile Communications Devices by Open Operating System, Worldwide, 2008-2015, 2011

^[16] Vgl. Rubin, Andrew in Elgin, Ben: Google Buys Android for Its Mobile Arsenal, 2005

^[17] In Deutschland als „T-Mobile G1“ vertrieben

^[18] Vgl. Pettey, Christy: Gartner Market Share Analysis: Mobile Devices, Worldwide, 1Q11, 2011

^[19] Vgl. Pettey, Christy: Gartner Market Share: Mobile Communication Devices by Region and Country, 2Q11, 2011

^[20] Vgl. o.V.: Nokia and Microsoft Announce Plans for a Broad Strategic Partnership to Build a New Global Mobile Ecosystem, 2011

^[21] Vgl. Pettey, Christy: Gartner Forecast: Mobile Communications Devices by Open Operating System, Worldwide, 2008-2015, 2011

^[22] Myselewski, Rik: iPhone App Store breezes past 500 million downloads, 2009

^[23] Vgl. Pettey, Christy: Gartner Forecast: Mobile Communications Devices by Open Operating System, Worldwide, 2008-2015, 2011

^[24] Vgl. Elop, Stephen in Segan, Sascha: Nokia, Microsoft Detail Windows Phone Partnership, 2011

^[25] Vgl. Pettey, Christy: Gartner Market Share: Mobile Communication Devices by Region and Country, 2Q11, 2011

^[26] Vgl. o.V.: Blackberrys? Mega-out!, 2011

^[27] Vgl. Pettey, Christy: Gartner Forecast: Mobile Communications Devices by Open Operating System, Worldwide, 2008-2015, 2011

^[28] Albrecht, Georg / Kuderna, Martin: Über 15 Milliarden Apps aus dem App Store von Apple heruntergeladen, 2011

^[29] o.V.,2011: Number of available Android applications, 2011. Anmerkung: Statistiken, die größere Zahlen angeben, beinhalten zum Teil auch die Angebotszahlen der Vertriebsplattformen von Googles Geschäftspartnern, z.B. Amazon.

^[30] o.V.: AndroLib Statistiken, 2011

^[31] Vgl. Sharma, Chetan: Sizing up the global apps market, 2010, S.4f.

^[32] Vgl. o.V.: The Mobile Movement, 2011

^[33] Vgl. o.V.: The Mobile Movement, 2011, S.7ff.

^[34] Koller, Dirk: iPhone-Apps entwickeln, 2011, S.80

^[35] Fragmentation im Zusammenhang mit mobilen Endgeräten, beschreibt die wachsende Anzahl der unterschiedlichen, zueinander inkompatiblen Geräte und Betriebssysteme.Das Portieren von ein und derselben Software wird dadurch nur mit viel Aufwand und grundlegenden Anpassungen möglich.

^[36] Vgl. Meeker, Mary u.a: The Mobile Internet Report, Morgan Stanley, 2009, S.162f. und o.V.: Native Apps vs. Web Apps, 2010

^[37] Siehe Koller, Dirk: iPhone-Apps entwickeln, 2011, S.76 und o.V.: apps get real, 2009, S.37 sowie Buschow, Sabrina / Olavarria, Marco: Mobile Research Guide 2010, 2010, S.72

^[38] Vgl. Becker, Arno: Die Architektur von Android, 2011

^[39] Siehe McDermott, Peter: Porting Android to a new device, 2008

^[40] Vgl. Pleumann, Jörg: The Android Runtime Environment, 2009

^[41] Die Main-Activity der Demo-Anwendung gibt bei jedem Wechsel seines Zustandes eine Debug-Meldung, mittels des Log.d()-Befehls aus. So kann über LogCat der gesamte Lebenszyklus dieser Activity verfolgt werden.

^[42] Die Thematik der Zustandssicherung wird in Kapitel 3.1.5.1 näher beleuchtet.

^[43] Im Speziellen: Apache Harmony.

^[44] Vgl. Carlo, Nicola: Einblick in die Dalvik Virtual Machine, 2009, S.5ff.

^[45] Vgl. Becker, Arno / Pant, Marcus: Android 2, 2010, S.21

^[46] Siehe Kapitel 3.1.5.3.3.2

^[47] Vgl. Becker, Arno / Pant, Marcus: Android 2, 2010, S.27

^[48] Siehe Kapitel 3.1.5.5

^[49] Siehe Kapitel 3.1.5.4

^[50] Kostenlos auf Googles Android Developer Webseite erhältlich.

^[51] Ebenfalls kostenlos auf Googles Android Developer Webseite erhältlich.

^[52] Vgl. o.V.: Android Developers, NDK, 2011

^[53] Wenn nicht schon geschehen, kann die DDMS-Perspektive über Window àOpen Perspective àOther… geöffnet werden.

^[54] Für den Zugriff auf geschützte Dateien/Verzeichnisse, wie z.B. /data/data/ muss das angeschlossene Gerät ggf. „gerootet“ werden.

^[55] Wenn nicht schon geschehen, kann die LogCat-Ansicht über Window àShow View àOther… àAndroid àLogCat geöffnet werden.

^[56] Anm.: Log.d() für Debug-, Log.e() für Fehler-, Log.i() für Info-Meldungen.

^[57] Siehe Hashimi, Sayed: Pro Android 3, 2011

^[58] Um Google Maps Funktionalitäten in der Anwendung zu gewährleisten, müsste stattdessen die Google API der Version 8 gewählt werden, welche das Android-Paket um die notwendigen Schnittstellen erweitert.

^[59] Siehe Abb. 10

^[60] Siehe Hashimi, Sayed: Pro Android 3, 2011

^[61] Um in diesem Verzeichnis browsen zu können, werden root -Zugriffsrechte benötigt.

^[62] Siehe Kapitel 3.1.2.3

^[63] Siehe auch Kapitel 3.1.4