Studienrichtung Wirtschaftsinformatik

Transkript

1 Bachelorarbeit Studienrichtung Wirtschaftsinformatik Michael Jaser Evaluation, Bewertung und Implementierung verschiedener Cross-Platform Development Ansätze für Mobile Internet Devices auf Basis von Web-Technologien Verfasser der Bachelorarbeit: Michael-Jaser Carl-von-Ossietzky-Str Peißenberg Telefon: Fakultät für Informatik Telefon: Fax: Erstprüfer: Prof. Dr.-Ing. Schöler Zweitprüfer: Prof. Dr. Rohrmair Abgabe der Arbeit: Hochschule Augsburg University of Applied Sciences Baumgartnerstraße 16 D Augsburg Telefon Fax poststelle@hs-augsburg.de

2 Erklärung Hiermit versichere ich, die vorliegende Arbeit ohne Hilfe Dritter und nur mit den angegebenen Quellen und Hilfsmitteln angefertigt zu haben. Alle Stellen, an denen Quellen verwendet wurden, sind als solche kenntlich gemacht. Diese Arbeit hat in gleicher oder ähnlicher Form noch keiner Prüfungsbehörde vorgelegen. Ort, Datum Unterschrift

3 Hochschule Augsburg Fakultät für Informatik Bachelorarbeit Wirtschaftsinformatik Evaluation, Bewertung und Implementierung verschiedener Cross-Platform Development Ansätze für Mobile Internet Devices auf Basis von Web-Technologien Michael Jaser Erstprüfer Prof. Dr.-Ing. Schöler Fakultät für Informatik Hochschule Augsburg Zweitprüfer Prof. Dr. Rohrmair Fakultät für Informatik Hochschule Augsburg Firmen-Betreuer Oliver Krüger Christian Kirsch IBM Deutschland

4 Michael Jaser: Evaluation, Bewertung und Implementierung verschiedener Cross-Platform Development Ansätze für Mobile Internet Devices auf Basis von Web-Technologien Bachelorarbeit Wirtschaftsinformatik Hochschule Augsburg Bearbeitungszeitraum: 18. November März 2011

5 Kurzfassung Mobile Anwendungen (Apps) gewinnen jeden Tag mehr an Bedeutung: Laut dem Marktforschungsunternehmen Gartner Inc. wird sich die Anzahl der App- Downloads von 4 Milliarden heutzutage, auf ca. 21,6 Milliarden im Jahr 2013 vervierfachen (vgl. Gartner [14]). Im Gegensatz zu den drei wichtigen Plattformen (Windows, Linux, Mac OS X) der herkömmlichen Anwendungsentwicklung, gibt es bei mobilen Geräten deutlich mehr Betriebssysteme. Neben ios (iphone, ipad) und Android gibt es fünf weitere Plattformen die auf mobilen Geräten zum Einsatz kommen. Durch diese Fragmentierung der mobilen Plattformen ist die plattformübergreifende App-Entwicklung ein viel versprechender Ansatz um die Entwicklungskosten gering zu halten und die Wartbarkeit zu gewährleisten. Mobile Webbrowser bieten mit HTML5 und CSS3 zahlreiche neue Möglichkeiten für Entwickler: Mit so genannte Web-Apps lassen sich standard-konforme Anwendungen entwickeln, die den Großteil der mobilen Plattformen erreichen. Um diese Web-Apps zu nativen Apps zu konvertieren und weitere Funktionalität bereitzustellen, gibt es so genannte Hybrid- Frameworks, die ebenfalls auf Web-Technologien basieren. Diese Arbeit beschäftigt ich mit den verschiedenen Möglichkeiten der App-Entwicklung auf Basis von Web-Technologien. Abstract Mobile applications are becoming more important every day: According to Gartner [14], app downloads will quadruple from around 4 billion today, to about 22 billion downloads in In contrast to the PC with its three dominant platforms, the mobile ecosystem is even more fragmented. Besides Android and ios there are five other major platforms. Therefore cross-platform mobile application development is becoming more and more important to reduce development costs and keeping apps maintainable. Mobile web apps offer a great way to build standards-based apps running on most modern mobile platforms. To leverage features of the platform and to extend those web apps, hybrid frameworks can be used to create native apps with more capabilities than web apps, but still using web standard technologies to implement these apps. I

6 II

7 Inhaltsverzeichnis Abbildungsverzeichnis Tabellenverzeichnis Abkürzungsverzeichnis VII IX XI 1 Mobile Internet Devices Begriffsklärung Geräte Smartphones Tablets Plattformen Apple - ios Open Handset Alliance Android RIM BlackBerry Symbian Foundation Symbian Microsoft Windows Mobile/Windows Phone HP Palm - webos Markt und Absatz Smartphones Tablets Plattformverbreitung Apps - mobile Applikationen Begriffserklärung und Markt Entwicklung App-Typen Native Apps Web Apps Hybrid Apps III

8 3 Cross-Plattform App-Entwicklung Mobile Web-Entwicklung Web-Apps HTML Herkunft und Definition Technologie und Verbreitung JavaScript und DOM JavaScript JSON DOM (Document Object Model) CSS Frameworks Web-Application-Frameworks Sencha Touch jquery Mobile Cross-Compiler-Frameworks Appcelerator Titanium Mobile Rhodes Wrapper-Frameworks PhoneGap Bewertung Kriterienkatalog Kriterien Technisch Unterstützte Plattformen Plattform-Ressourcen Performance Offline-Ressourcen Multimedia Benachrichtigungen Lizenzierung Entwicklung Community Tools Wiederverwendbarkeit Dokumentation Usability IV

9 Look & Feel Sicherheit Verschlüsselung Remote-Wartung Marketing Werbung Distribution Monetarisierung Einschränkungen Implementierung Motivation Ist-Analyse Roomieplanet Verwendete Technik Vorhandene Schnittstellen Roomieplanet Mobile Anforderungsanalyse Technologieauswahl App-Typ Verwendete Frameworks Serverseitige API UI-Konzept Implementierung - Web-App Struktur - Sencha Touch Initialisierung und Ablauf Datenbeschaffung und Offline-Caching HTML5 Funktionen Offline Web Applications Persistenter Speicher LocalStorage Lokale Datenbank Web-SQL Geolocation Implementierung - Hybrid-App Motivation PhoneGap Web-App Integration Zusatzfunktionen V

10 5.6 Erfahrungsbericht Testgeräte und Plattformen Reifegrad der Frameworks Sencha Touch PhoneGap Literaturverzeichnis C VI

11 Abbildungsverzeichnis 1.1 Smartphone Apple iphone Tablet Samsung Galaxy Tab ios-logo Android-Logo BlackBerry-Logo Symbian-Logo Windows Phone 7 Logo HP Palm webos Logo Smartphone-Absatz (Bitkom 11/2010) Tablet Absatz (weltweit) Smartphone Plattformverteilung Smartphone - Wachstum Entwicklerumfrage: Mobile Entwicklung Hybrid-App Architektur (Wrapper-Framework) HTML-Entwicklung HTML5 - Spezifikation HTML5 - Verwandte Spezifikationen JavaScript Benchmark SunSpider Kriterienkatalog: Legende Kriterienkatalog: Plattformunterstützung Kriterienkatalog: Plattform-Ressourcen Kriterienkatalog: Performance Kriterienkatalog: Offline Ressourcen LocalStorage roomieplanet mobile (Safari Web-Developer Tools) Kriterienkatalog: Multimedia Kriterienkatalog: Benachrichtigungen Kriterienkatalog: Lizenzierung VII

12 4.10 Kriterienkatalog: Community Kriterienkatalog: Tools Kriterienkatalog: Wiederverwendbarkeit Kriterienkatalog: Dokumentation Kriterienkatalog: Look & Feel Native UI-Komponenten (iphone) Kriterienkatalog: Verschlüsselung Kriterienkatalog: Remote-Wartung Kriterienkatalog: Werbung Kriterienkatalog: Distribution Kriterienkatalog: Monetarisierung Kriterienkatalog: Einschränkungen Roomieplanet Modulübersicht Roomieplanet - Logo Roomieplanet Desktop Roomieplanet mobile Use Case Diagramm Roomieplanet UI-Konzept Roomieplanet mobile UI Roomieplanet mobile (Querformat) Roomieplanet-Mobile Komponentendiagramm Roomieplanet mobile Initialisierung Roomieplanet mobile Datenbeschaffung Datenbeschaffung Web-App Application-Cache Debugging WebSQL - Entwickler-Tools PhoneGap Logo VIII

13 Tabellenverzeichnis 2.1 App-Absatz: Downloads und Umsatz Vergleich nativer Entwicklungsplattformen HTML5-Verbreitung Verbreitung verwandter Spezifikationen Verbreitete JavaScript Engines Einteilung der Kriterien Kriterienkatalog: Plattformunterstützung Kriterienkatalog: Plattform-Ressourcen Kriterienkatalog: Performance Kriterienkatalog: Offline Ressourcen Kriterienkatalog: Multimedia Kriterienkatalog: Benachrichtigungen Kriterienkatalog: Lizenzierung Kriterienkatalog: Community Kriterienkatalog: Tools Kriterienkatalog: Wiederverwendbarkeit Kriterienkatalog: Dokumentation Kriterienkatalog: Look & Feel Kriterienkatalog: Verschlüsselung Kriterienkatalog: Remote-Wartung Kriterienkatalog: Werbung Kriterienkatalog: Distribution Kriterienkatalog: Monetarisierung Kriterienkatalog: Einschränkungen Use-Case Anwendungsfälle IX

14 X

15 Abkürzungsverzeichnis AJAX... Asynchronous JavaScript And XML CSS Cascading Stylesheets DOM.... Document Object Model HTML.. ios JSON... MID..... PHP..... Hypertext Markup Language Apple ios - Betriebssystem für mobile Endgeräte JavaScript Object Notation Mobile Internet Device - (engl. portables internetfähiges Gerät). PHP: Hypertext Preprocessor XML.... Extensible Markup Language XI

16 XII

17 Einleitung Mobile Internet Devices (MIDs) 1 gewinnen immer mehr an Bedeutung. Seit Einführung des iphones 2007 und der Veröffentlichung des Android Smartphone-Betriebssystems 2008 hat sich der mobile Markt stark verändert: Laut Bitkom wird im Jahr 2011 bereits jedes dritte verkaufte Handy ein Smartphone sein und der Gesamtmarkt für Tablets wird laut Gartner von 19,5 Millionen Geräten in 2010 um 181 % auf 54,8 Millionen Geräte im Jahre 2011 wachsen (vgl. Bitkom [9],Gartner [15]). Auf all diesen Geräten sind sogenannte Apps 2 installiert. Es handelt sich dabei um kleine Programme die meist über eine zentrale Stelle bezogen werden können und oft nur für eine bestimmte Aufgabe geschaffen sind. Somit lassen sich MIDs beliebig erweitern und den eigenen Bedürfnissen anpassen. Zum Stand der Arbeit gibt es bereits über Apps für das iphone von Apple und über Apps für Android. Booz & Company prognostiziert bis 2013 ein jährliches App-Wachstum von bis zu 73 % (vgl. Booz and Company [10]). Die Entwicklung dieser Apps stellt sich aber als relativ aufwendig dar, weil es für jedes Betriebssystem eine eigene Entwicklungsumgebung und spezielle Schnittstellen gibt, also eine App für jede Plattform separat implementiert werden muss. Durch die hohe Fragmentierung bei den mobile Geräten ist es aber für die meisten Apps sehr wichtig, möglichst viele Plattformen und somit Anwender zu erreichen. Um plattformübergreifende Apps zu entwickeln, bietet sich im Moment einzig der Browser auf Basis der WebKit-Browser-Engine als einheitliche Basis. Aktuelle Web-Technologien, insbesondere HTML5 3, CSS3 4 und JavaScript bieten eine Vielzahl neuer Möglichkeiten für mobile Anwendungen: So lassen sich auf Smartphones und Tablets angepasste, mobile Webseiten entwickeln, die auch offline nutzbar sind und durch Einsatz zusätzlicher Frameworks dem Look&Feel nativer Apps nahe kommen. Obwohl mit HTML5 deutlich mehr Zugriff auf Ressourcen der Geräte verfügbar ist als mit HTML4 (z. B. Sensoren, Geolocation), so sind einige Komponenten weiterhin den nativen Apps vorenthalten (z.b. Kamera). Außerdem unterscheidet sich 1 Mobile Internet Devices: Portable Geräte zwischen 3 und 10 2 App ist die Kurzform von Application (engl. für Anwendung). 3 Hypertext Markup Language: Web-Auszeichnungssprache 4 Cascading Stylesheets: Sprache zur Definition der Darstellung von HTML 1

18 2 die Distribution bei Web-Apps im Vergleich zu den nativen Apps: Web-Apps werden automatisch lokal abgelegt, ohne dass eine aktive Installation erforderlich ist. Bei nativen Apps hingegen erfolgt die Distribution hauptsächlich über plattform-spezifische zentrale Marktplätze, über welche Anwender ihre Apps hauptsächlich beziehen. Momentan ist es aber nicht möglich Web-Apps direkt über diese Marktplätze zu vertreiben. Um Web-Apps Zugang zu den nativen Marktplätzen zu verschaffen und mehr Zugriff auf Plattform-Ressourcen zu bieten, gibt es sogenannte Hybrid Frameworks : Je nach Framework ist es somit möglich, native Apps zu implementieren, die auf mehreren Plattform lauffähig sind und sich für den Anwender hinsichtlich der Distribution nicht von nativen Apps unterscheiden. Diese Arbeit beschäftigt sich mit den verschiedenen Ansätzen der plattformübergreifenden App Entwicklung auf Basis von Web-Technologien: Im ersten Abschnitt wird zunächst einmal die Gerätekategorie definiert und eine Prognose der zukünftigen Entwicklungen abgegeben. Das zweite Kapitel beschäftigt sich mit den Apps und dazugehörigen betriebswirtschaftlichen Aspekten. Darauf folgt eine Analyse der plattformübergreifenden App-Entwicklung mit einer Beschreibung aktueller Web-Technologien (HTML5, CSS3) und wichtiger Frameworks. Um diese Ansätze besser einschätzen zu können, werden diese im vierten Kapitel hinsichtlich zahlreicher Kriterien evaluiert. Abschließend werden zwei Ansätze in Form von Prototypen implementiert, um den Reifegrad aufzuzeigen und Erfahrungen der plattformübergreifenden Entwicklung zu dokumentieren.

19 Kapitel 1 Mobile Internet Devices 1.1 Begriffsklärung Der Begriff des Mobile Internet Device ist nicht einheitlich spezifiziert und die Definition unterschiedet sich je nach Quelle in einigen Punkten. So beschreibt Texas Instruments die Kernbestandteile eines MIDs in außergewöhnlicher Multimedia-Funktionalität und einer umfangreichen Web-Unterstützung mit großen dynamischen Bildschirmen, wobei die Größe des Gerätes nicht näher definiert ist (vgl. Instruments [28]). Der britische Chip-Hersteller ARM liegt mit seiner Definition nahe an der von Texas Instruments wobei mit einer langen Akku-Laufzeit ein weiterer wichtiger Punkt ergänzt wird (vgl. ARM [7]). Intel definiert ein MID als mobiles Gerät mit ca. fünf Inch Bildschirmdiagonale dessen Hauptaufgabe in der Unterhaltung und hoher Konnektiviät liegt. (vgl. Intel [29]) Um eine einheitliche Definition zu finden, ist ein Mobile Internet Device im Rahmen der Arbeit wie folgt spezifiziert: Betriebssystem: Mobile Plattform (z. B. ios, Android vgl. Kapitel 1.3) Touchscreen mit Multitouch Multimedia-fähig (Video, Audio) HTML5-fähiger Browser Bildschirm-diagonale: 3-10 Zoll Nach dieser Definition sind die meisten aktuellen Smartphones sowie die neue Sparte der Tablets wie z.b. das ipad Untergruppen der Mobile Internet Devices. Auch wenn manche Quellen Mobile Internet Devices anhand der Telefonfunktionalität von Smartphones abgrenzen, sind Smartphones im Rahmen 3

20 4 KAPITEL 1. MOBILE INTERNET DEVICES dieser Arbeit als Teilgruppe der Mobile Internet Devices anzusehen, insbesondere da sich inzwischen einheitliche Plattformen für Smartphones und Tablets etablieren und die Gerätekategorien teilweise verschmelzen. Folgende Geräte sind nach obiger Definition nicht Teil der Mobile Internet Devices, da es sich um Geräte ohne mobile Plattformen handelt und die Bedienung i. d. R. nicht per Touchscreen erfolgt: Feature Phones: Handys die bereits einige Zusatzfunktionen haben, aber noch nicht auf dem Level der Smartphones erweiterbar sind Dumb Phones: Einfache Handys die nur zum Telefonieren gedacht sind Netbooks: Kleine Laptops mit Linux oder Windows Betriebssystem (kein mobiles Betriebssystem)

21 1.2. GERÄTE Geräte Smartphones Abbildung 1.1: Smartphone Apple iphone 4 (Quelle: Wikipedia [65]) Ein Smartphone ["sma:t f@un] ist ein Mobiltelefon mit besonders leistungsfähigem Prozessor, welches den Funktionsumfang eines Mobiltelefons um den eines Personal Digital Assistants (PDA) erweitert. Fortschrittliche Smartphones können über zusätzliche Programme (sogenannte Apps) vom Anwender individuell mit neuen Funktionen aufgerüstet werden Smartphone [52] Auch der Begriff Smartphone ist nicht einheitlich definiert und die Entwicklung ist so rasant, dass man unter einem Smartphone in zwei Jahren deutlich mehr erwarten wird als zum Zeitpunkt dieser Arbeit. Die Abgrenzung zu den Feature Phones ist fließend und lässt sich stark vereinfacht wie folgt beschreiben: Ein Featurephone ist hauptsächlich ein Telefon und bietet zusätzliche Funktionen, wie beispielsweise einen Kalender oder einen Taschenrechner. Ein Smartphone ist auch ein Telefon, bietet darüber hinaus aber weitere Funktionen z. B. , Kalender und Browser, die durch sog. Apps beliebig erweitert werden können. Der signifikanteste Unterschied ist die Geräteplattform: So sind Featurephones oft mit einem eigenen Betriebssystem je Serie ausgestattet und daher sind auch Programme meist auf bestimmte Geräte oder zumindest Hersteller angepasst. Bei Smartphones wird in der Regel eine Plattform eingesetzt die auf mehreren Geräten läuft (z.b. Android, ios) und zentral weiterentwickelt wird, wobei Featurephones meist ein eingeschränktes proprietäres Betriebssystem haben und zusätzliche Software, wenn überhaupt meist auf Basis von Java oder BREW entwickelt wird (vgl. Lee [34]).

22 6 KAPITEL 1. MOBILE INTERNET DEVICES Tablets Abbildung 1.2: Tablet Samsung Galaxy Tab (Quelle: Samsung [50]) Ein Tablet-Computer (engl. tablet Schreibtafel, US-engl. tablet Notizblock), ist ein tragbarer, flacher Computer, der vollständig im Gehäuse eines Touchscreen untergebracht ist und per Finger oder seltener per Stift bedient werden kann. Diese Geräte basieren meist auf einer proprietären Hardwarearchitektur mit einem Embedded-Betriebssystem, welches vom Nutzer nicht ausgetauscht werden kann. [56] Tablets sind eine relativ neue Gerätekategorie, die durch Apples ipad und zahlreiche Tablets anderer Hersteller momentan einen regelrechten Boom erleben. Wichtig ist hierbei die Unterscheidung zwischen Tablet-Computer und Tablet PC: So sind Tablet PCs meist normale Laptops auf Basis einer x86 Architektur, die sich per Stift bedienen lassen, wobei die Bedienung bei Tablet-Computern meist über einen Touchscreen erfolgt und als Betriebssystem überwiegend embedded Systeme, wie ios oder Android eingesetzt werden (vgl. Mag [36]). Im Rahmen der Arbeit ist mit Tablet ein Tablet-Computer gemeint, also ein portables Gerät mit einer mobilen Plattform.

23 1.3. PLATTFORMEN Plattformen Apple - ios Abbildung 1.3: ios-logo (Quelle: Apple [5]) Das proprietäre Betriebssystem ios wurde am 9. Januar 2007 von Apple unter dem Namen iphone OS vorgestellt. Es handelte sich dabei um ein auf das iphone angepasstes Betriebssystem, das auf Mac OS X basiert und dieses für eine Touch-Bedienung optimiert. Nachdem das Betriebssystem auch auf dem ipod und dem ipad eingesetzt wird, hat Apple das Betriebssystem am 7. Juni 2010 in ios umbenannt. Die aktuelle Version zum Zeitpunkt dieser Arbeit ist (vgl.ios [30]). ios wird nur auf Apple-Geräten eingesetzt und ist bis auf einige Open-Source Komponenten ein geschlossenes System. Native Anwendungen für ios werden in Objective-C geschrieben und sind ausschließlich über Apples AppStore erhältlich, sofern diese Apples Richtlinien entsprechen und freigegeben wurden. Mit xcode ist eine komplette Entwicklungsumgebung mit IDE und Simulator erhältlich (vgl. Apple [2]) Open Handset Alliance Android Abbildung 1.4: Android-Logo (Quelle: Open Handset Alliance [44]) Seit dem 5. November 2007 entwickelt Google gemeinsam mit 33 anderen Mitgliedern der Open Handset Alliance ein Betriebssystem namens Android. Dieses basiert auf dem Linux-Kernel 2.6 und ist ein quelloffenes Betriebssystem für Mobile Internet Devices. Momentan ist Android die mobile Plattform mit dem größten Wachstum und neben Smartphones sind inzwischen auch

24 8 KAPITEL 1. MOBILE INTERNET DEVICES Tablet-Computer mit Android auf dem Markt. (vgl.wikipedia [69]). Das enorme Wachstum von Android beweist folgendes Zitat: Am Rand einer Konferenz im kalifornischen Lake Tahoe gab Google- CEO Eric Schmidt das Erreichen einer neuen Marke bekannt: Android-Smartphones würden nun täglich verkauft. Das bedeute eine Verdoppelung innerhalb von nur zwei Monaten. Heise [21] Android ist Open Source, native Anwendungen werden in Java geschrieben, wobei mit Android ADT (Android Development Tools) eine Entwicklungsumgebung in Form eines Eclipse-Plugins zur Verfügung steht. Anwendungen können über den Android Market vertrieben werden, es ist aber auch möglich andere zentrale App-Portale zu nutzen oder die App per Download anzubieten (vgl. Open Handset Alliance [43]) RIM BlackBerry Abbildung 1.5: BlackBerry-Logo (Quelle: RIM [49] Alle BlackBerry-Geräte der kanadischen Firma RIM (Research in Motion) nutzen ein eigenes proprietäres Betriebssystem. Die Bedienung war lange durch ein Daumenrad gelöst, wobei aktuellen Geräten inzwischen auch mit einem Touchscreen ausgestattet sind. RIM bietet für BlackBerry-Smartphones umfangreiche Client-Server-Software und ist besonders im Businessbereich sehr verbreitet. Im September 2010 hat RIM einen Tablet-Computer namens Playbook angekündigt der auf Basis des eigenen Betriebssystems arbeiten wird, welches auf QNX basiert. (vgl. Wikipedia [66]). Anwendungen für BlackBerry werden mithilfe der eigenen IDE in Java geschrieben und die Distribution erfolgt hauptsächlich über RIMs App World, wobei auch andere Kanäle möglich sind (vgl. RIM [48]) Symbian Foundation Symbian Symbian ist der Nachfolger des proprietären Betriebssystems Symbian OS. Es wird seit Juni 2008 im Rahmen der Symbian Foundation, einem Zusam-

25 1.3. PLATTFORMEN 9 Abbildung 1.6: Symbian-Logo (Quelle: Symbian [54]) menschluss mehrerer Unternehmen, entwickelt und ist als Open Source verfügbar. Dieses Betriebssystem wurde u. a auf Smartphones von Nokia, Siemens und Sony Ericsson eingesetzt, allerdings haben sowohl Samsung als auch Sony Ericsson im September 2010 angekündigt keine Geräte mehr mit Symbian auszuliefern (vgl. Symbian [55]). Wie es um die Zukunft der Plattform steht, ist daher fraglich, was folgendes Zitat verdeutlicht: Auch wenn Nokia betont, Symbian sei nicht tot, so macht der Schritt doch eines deutlich: Symbian als Betriebssystem wird künftig keine große Rolle spielen. So werden die Smartphones der N- Serie künftig nicht mehr damit bestückt, sondern mit MeeGo ausgeliefert. Damit rückt Qt als geräte- und plattformübergreifende Entwicklungsplattform in den Mittelpunkt. Symbian ist also nicht tot, wird aber vermutlich aus Entwickler- und Nutzersicht unwichtig. Ihlenfeld [25] Anwendungen für Symbian werden üblicherweise in C/C++ geschrieben, wobei die Möglichkeit besteht, Web-Anwendungen direkt auf die Symbian Plattform zu bringen. Apps können auf unterschiedlichen Wegen angeboten werden und neben diversen Stores (z.b. Ovi Store) ist es auch möglich diese direkt per Download anzubieten. Für Entwickler gibt es eine Entwicklungsumgebung mit Emulator (vgl. Symbian [53]) Microsoft Windows Mobile/Windows Phone 7 Abbildung 1.7: Windows Phone 7 Logo (Quelle: Microsoft [39]) Die erste Version von Windows Mobile wurde 2002 veröffentlicht und basierte auf Windows CE 3.0. Microsofts Betriebssystem für Handhelds und Pocket PCs ist momentan in der Version angekündigt und wird immer

26 10 KAPITEL 1. MOBILE INTERNET DEVICES noch auf einigen Geräten eingesetzt, wobei die Bedienung bei Windows Mobile per Stift erfolgt und die Bedienelemente an das klassische Windows angelehnt sind. Seit Oktober 2010 ist der Nachfolger unter der Bezeichnung Windows Phone 7 auf dem Markt. Es handelt sich dabei um eine Neuentwicklung die besonders auf die Bedienung per Touchscreen und Multitouch ausgelegt ist (vgl. Mobile [40]). Anwendungen für Windows Mobile bzw. Phone 7 werden auf Basis von.net oder Silverlight entwickelt und als IDE wird Visual Studio und ein entsprechendes SDK (Software Development Kit) angeboten. Apps werden in der Regel über den Windows Mobile Marketplace verteilt, wobei es auch die Möglichkeit gibt diese bei anderen Markets anzubieten (vgl. Microsoft [38]) HP Palm - webos Abbildung 1.8: HP Palm webos Logo (Quelle: HP [23]) webos wurde als Nachfolger von Palm OS im Januar 2009 von der Firma Palm vorgestellt. Das Betriebssystem ist auf die Bedienung per Touchscreen ausgelegt, bietet seit der ersten Version Multitasking und setzt bei der Anwendungsentwicklung auf Web-Technologien wie HTML5, CSS und JavaScript. Nachdem Palm von HP aufgekauft wurde, war anfangs nicht klar was mit webos passieren würde, aber im Oktober 2010 kündigte HP webos in der Version 2.0 an, wobei die neue Version sowohl auf den alten, noch von Palm entwickelten, als auch auf neuen von HP entwickelten Geräten eingesetzt werden kann. (vgl. webos [62]) Anwendungen für webos sind auf Basis von Web-Technologien geschrieben und mit Mojo steht eine plattformeigene JavaScript-API für Entwickler zur Verfügung, wobei die Apps über verschiedene Kanäle angeboten werden und keine Bindung an einen zentralen Markt besteht (vgl. HP [22])

27 1.4. MARKT UND ABSATZ Markt und Absatz Smartphones Der Smartphone-Absatz steigt in den letzten Jahren kontinuierlich und es ist zu erwarten, dass sich dieser Trend in den nächsten Jahren fortsetzt. Abbildung 1.9: Smartphone-Absatz (Bitkom 11/2010) (Quelle: Bitkom [9]) Laut einer Bitkom-Studie wird im Jahr 2011 in Deutschland jedes dritte verkaufte Handy ein Smartphone sein, wobei der Durchschnittspreis der Smartphones bei 226 Euro, der Preis normaler Handys bei 116 Euro liegt. Der Smartphone-Absatz in Deutschland wird für das Jahr 2011 auf ca. 10 Millionen Geräte prognostiziert, wobei der Umsatz im Vergleich zum Vorjahr um 35 % auf 2,2 Milliarden steigen wird. Der Smartphone-Markt ist momentan stark umkämpft und jeder Hersteller versucht möglichst schnell neue Geräte auf den Markt zu bringen (vgl. Bitkom [9]). Die Verbreitung von Smartphones liegt weltweit allerdings noch auf einem sehr niedrigen Niveau, nur etwa jeder Achte besitzt ein solches Gerät. In Deutschland sind es dagegen mehr als 40 Prozent, was die Deutschen zu den Vorreitern in der Adoption von Smartphones macht. Infratest [27] Wie dieses Zitat aus dem Jahr 2008 beweist, war die Smartphoneverbreitung in Deutschland bereits vor zwei Jahren schon sehr hoch. Wenn man das aktuellen Wachstum in der Branche betrachtet kann man davon ausgehen, dass die Verbreitung von Smartphones weiter gestiegen ist.

28 12 KAPITEL 1. MOBILE INTERNET DEVICES Tablets Der weltweite Markt für Tablets wird laut Gartner von 19,5 Millionen Geräten im Jahre 2010 um 181 % auf 54,8 Millionen Geräte im Jahre 2011 wachsen und für 2014 wird ein Absatz von 208 Millionen Geräten prognostiziert (vgl. Gartner [15]). Seit der Einführung des ipads im Frühjahr 2010 wurden zahlreiche Tablets anderer Hersteller angekündigt und es sind inzwischen mehrere Geräte erhältlich. Neben Ausnahmen wie dem WeePad auf Basis von MeeGo einem offenen Betriebssystems auf Linux Basis setzen die meisten Tablets auf Android. Google selbst rät davon ab Android vor Version 3.0 auf Tablets einzusetzen, da alle aktuellen Versionen noch nicht auf die neue Gerätekategorie angepasst ist. Die meisten Tablets auf Android Basis sind daher momentan mit einem Mobilfunk-Modul ausgestattet und kleiner als das ipad um den Bestimmungen für Googles Android-Market gerecht zu werden (vgl. Beavis [8]). Dieser Schritt vieler Hersteller verdeutlicht wie wichtig der Markt der Tablets momentan ist und nahezu jeder Hersteller der Elektronik-Branche hat inzwischen ein Tablet auf dem Markt, oder zumindest in Planung. Abbildung 1.10: Tablet Absatz (weltweit) (Quelle: Gartner [15])

29 1.5. PLATTFORMVERBREITUNG Plattformverbreitung Abbildung 1.11: Smartphone Plattformverteilung (Quelle: Gartner [16]) Momentan sind Symbian, Android, ios und RIM-BlackBerry am Absatz gemessen die vier wichtigsten Betriebssysteme für Smartphones. Die Verteilung hat sich in den letzten Quartalen aber stark verändert und so werden sich nach aktuellen Prognosen Android, ios und BlackBerry als die wichtigsten Plattformen etablieren, wobei Symbian nach dem Ausstieg von Samsung und Sony Ericsson immer mehr Marktanteile verlieren dürfte. Für die Marktanteile bei den Tablet-Computern gibt es momentan noch keine aussagekräftigen Zahlen, da es sich um einen sehr jungen Markt handelt, es ist aber zu erwarten dass sich in diesem Markt besonders ios und Android behaupten werden. Zwar wird auch RIM Anfang 2011 mit einem Tablet in den Markt drängen, jedoch wird es für RIM schwer den Vorsprung von Apples ipad und die große Masse an neuen Tablets mit Android als Betriebssystem wieder gut zu machen. Bezieht man Tablets, kleine MIDs wie Apples ipod Touch oder Mischformen wie Dells Streak in die Plattformverteilung mit ein, so dürfte der Marktanteil von Android und ios weitaus größer sein und es ist abzuwarten wie sich der Markt in diesem Bereichen weiterentwickelt.

30 14 KAPITEL 1. MOBILE INTERNET DEVICES Any Plattform that fails to innovate quickly either through a vibrant multi-player ecosystem or clear vision of a single controlling entity will lose developers, manufacturers, potential partners and ultimately users. Cozza [11] Abbildung 1.12: Smartphone - Wachstum (Quelle: Gartner [16]) Gewinnen werden die Plattformen, die sich schnell weiterentwickeln und sich durch Innovation von der Konkurrenz absetzen. Um als Plattform bestehen zu können, muss diese nicht nur einen Gerätetyp unterstützen, sondern von Größe und Ausstattung weitgehend unabhängig einsetzbar sein, um möglichst alle Gerätekategorien und Mischformen abzudecken.

31 Kapitel 2 Apps - mobile Applikationen Nachdem die Mobile Internet Devices definiert sind, beschäftigt sich dieses Kapitel mit den Apps: Dabei geht es um die Definition und die zukünftige Entwicklung der Apps, aber auch um die möglichen Arten einer Implementierung. Obwohl die Anzahl an Apps stetig steigt und unter betriebswirtschaftlichen Gesichtspunkten sehr interessant ist, so ist die Fragmentierung der MIDs ein großen Problem der App-Entwicklung. 2.1 Begriffserklärung und Markt App die Kurzform für Application (engl. Anwendung) ist die Bezeichnung für ein Stück Software bzw. ein Programm. Obwohl der Begriff App keineswegs auf mobile Anwendungen beschränkt ist, hat er sich besonders dort weltweit durchgesetzt, wobei Apple sicherlich eine gewisse Vorreiter-rolle gespielt hat: So sind Apps für Apple-Geräte über den sog. AppStore zu beziehen und der Slogan There is an app for that ist ein eingetragenes Markenzeichen von Apple. Inzwischen bezeichnen alle Anbieter mobile Anwendungen als App und der Begriff ist weit verbreitet. (vgl. Winfuture [70]) Mobile Apps sind im Gegensatz zu Desktop-Anwendungen meist nur für einen bestimmten Aufgabenbereich geschaffen und auf diesen zugeschnitten und optimiert. So hat man auf einem Laptop ein ganzes Office-Paket mit Funktionen für Textverarbeitung, Tabellenkalkulation und Präsentationen. Auf dem ipad während gibt es für jeden dieser drei Bereiche eine eigene App. Es gibt Apps für fast alle Bereiche des Lebens und neben Standard-Apps für das Wetter oder die Börse, sind auch viele skurrile Apps verfügbar. 15

32 16 KAPITEL 2. APPS - MOBILE APPLIKATIONEN Downloads (in Mio.) Gesamtumsatz (in Mio.) 4.237, , ,30 Tabelle 2.1: App-Absatz: Downloads und Umsatz (Quelle: Gartner [14]) Der App-Markt wächst auf allen Plattformen rasant und jeden Tag werden zahlreiche neue Apps entwickelt. Das Wachstum in diesem Bereich wird im Laufe der nächsten Jahre noch deutlich steigen, wobei sich die Anzahl der Downloads allein von 2009 auf 2010 fast verdoppelt hat. Eine proportionale Relation zwischen Downloadzahlen und dem Umsatz ist allerdings nicht gegeben, da momentan ca. 80 % der Apps kostenlos angeboten werden und diese Quote laut Gartner-Prognose bis 2013 auf 87 % steigen wird. Oft werden auch Lite -Versionen von Apps angeboten, eine Art Demo um potentielle Kunden vom Nutzen der Vollversion zu überzeugen. (vgl. Gartner [14]) Kostenlose Apps können auch Einnahmen bringen: Durch Werbung innerhalb der Apps kann auch mit kostenlosen Apps Gewinn erzielt werden und es gibt z. B. mit iad von Apple oder mobile Ads von Google fertige Lösungen die Entwickler integrieren können. Laut Gartner werden mit werbe-finanzierten Apps 2013 bereits 25 % des gesamten App-Umsatzes erzielt. (vgl. Gartner [14]) Eine weitere Möglichkeit mit Gratis-Apps Gewinn zu machen ist das so genannte In-App-Purchasing : Die App an sich ist kostenlos, aber innerhalb der App kann man sich Erweiterungen, wie beispielsweise weitere Spiel-Level kaufen. Viele Magazine wie z. B. der Spiegel nutzen ähnliche Modelle und bieten eine kostenlose App an, wobei jede digitale Ausgabe separat gekauft werden muss. (vgl. Gartner [14]) Die Preise für Apps unterscheiden sich weltweit: In Europa liegt der Durchschnittspreis der bestverkauften Apps bei ca. 3, wobei der Preis in Nordamerika (1,70 ) und in Asien (2 ) geringer ist. Es gibt auch zwischen den Plattformen preislich deutliche Unterschiede: Mit über 5 sind Apps für Windows Mobile im Vergleich am teuersten, wobei Apps für Windows Phone 7 im Schnitt auf dem preislichen Level der Mitbewerber liegt. So liegt der Durchschnittspreis aller kostenpflichtiger Android-, ios- und BlackBerry-Apps bei 2 bis 3. Apps aus dem webos-store, Nokias Ovi-Store und Windows Phones Marketplace liegen im Schnitt um die 1,50. (vgl. Distimo [12])

33 2.2. ENTWICKLUNG Entwicklung Die Entwicklung von Apps hat sich vom Nischenbereich zu einem der wichtigsten Wachstumsmärke entwickelt. According to the survey, more than half of all IT professionals 55 percent expect mobile software application development for devices such as iphone and Android, and even tablet PCs like ipad and PlayBook, will surpass application development on all other traditional computing platforms by IBM [24] So besagt eine Studie von IBM - DeveloperWorks: 55 % aller befragten IT- Experten sind der Meinung dass die Entwicklung von Software für mobile Endgeräte 2015 wichtiger sein wird als die herkömmliche Anwendungsentwicklung. Abbildung 2.1: Entwicklerumfrage: Mobile Entwicklung (Quelle: IBM [24]) Die Entwicklung von Apps ist je nach Gerätetyp und Plattform sehr unterschiedlich und sowohl Programmiersprache, Entwicklungsumgebung und Prozesse unterscheiden sich stark. Deshalb muss man Apps momentan für jede Plattform separat entwickeln und da es keine einheitliche API gibt, ist auch die Code-Wiederverwendbarkeit sehr eingeschränkt. Die Verbreitung der MIDs steigt stetig und der Bedarf nach Apps steigt in selbem Maße. Daher beschäftigt sich der nächsten Abschnitt mit den Möglichkeiten der plattformübergreifenden App-Entwicklungen und den verschiedenen Ansätzen.

34 18 KAPITEL 2. APPS - MOBILE APPLIKATIONEN 2.3 App-Typen Native Apps Native Apps sind auf die jeweilige Plattform angepasste Anwendungen, die über APIs und Bibliotheken Zugriff auf die Hardware haben und direkt auf den Geräten installiert werden können. Die Programmierung erfolgt in der von der Plattform vorgegebenen Sprache und die Distribution der App erfolgt meist über eine zentrale Stelle. (z. B. Apple AppStore, Google Market) Der Großteil der verfügbaren Apps sind nativ und weitere Ansätze sind noch nicht sehr verbreitet. Vorteile nativer Apps: Hohe Performance Hardware/Software-APIs (z. B. Kamera, Adressbuch) Vertrieb über App-Stores (Abrechnung) Nachteile nativer Apps: Plattformbindung Hohe Entwicklungskosten Kosten für Lizenzen (SDK und/oder Vertriebsplattform) Plattform Programmierung IDE Kosten ios Objective-C Xcode 99$ / Jahr Android Java (C, C++) Eclipse (ADT) 25$ einmalig BlackBerry Java JDE 20$ / App Symbian C++ Eclipse 50$ webos JavaScript Eclipse z.z. kostenlos Windows Mobile.NET, C, C++ Visual Studio 99$ / Jahr Tabelle 2.3: Vergleich nativer Entwicklungsplattformen (Quellen: Apple [2], Open Handset Alliance [43], RIM [48], Symbian [53], HP [22], Microsoft [38]) Die Tabelle 2.3 zeigt einen Überblick über die native Anwendungsentwicklung: Unter Kosten sind alle Ausgaben für die Entwicklung bis zur Distribution der App zusammengefasst. dabei ist das prozentuale Verhältnis der Gewinnteilung zwischen Entwickler und dem jeweils größten zentralen Marktplatz bei allen Plattformen 70:30.

35 2.3. APP-TYPEN Web Apps Web-Apps sind (mobile) Webseiten, die auf Basis von Web-Technologien wie HTML, CSS und JavaScript entwickelt werden. Der Begriff Web-App ist aber nicht auf mobile Webseiten beschränkt und so sind im Prinzip alle Anwendungen im Web als Web-App zu sehen. Obwohl es keine genaue Definition gibt, wird der Begriff hauptsächlich im Zusammenhang mit HTML5 genannt. Dabei handelt es sich um offline-fähige Webseiten, die an mobile Geräte angepasst sind und sich an nativen Apps orientieren. Die technische Grundlage ist dabei die selbe wie bei normalen Webseiten, jedoch wird durch die Verwendung von HTML-5-Funktionen eine bessere Plattform-Integration erreicht. (z. B. durch ortsbezogene Dienste und die Integration von Sensoren) Da die Browser auf Smartphones erst seit wenigen Jahren HTML, CSS und JavaScript unterstützen und zuvor angepasste Sprachen wie WML zum Einsatz kamen, ist die Web-App-Entwicklung noch relativ jung. Doch im Vergleich zur herkömmlichen Web-Entwicklung gibt es auf mobilen Plattformen einen entscheidenden Vorteil: Ein großer Kritikpunkt der Desktop-Browser ist die Fragmentierung durch verschiedene Browser-Engines, wodurch es für Web- Entwickler relativ schwer ist Desktop-Web-Apps einheitlich zu gestalten und die Funktion browserübergreifend in vollem Umfang zu gewährleisten. Alle Standard Browser der verbreiteten mobilen Plattformen setzen im Moment auf die Browser-Engine WebKit auf. Somit hat sich eine Art Standard entwickelt, der es für mobile Web-App Entwickler deutlich erleichtert plattformübergreifend mobil zu entwickeln. Bisher waren Web-Apps relativ eingeschränkt und wichtige Funktionen fehlten, wodurch das Einsatzgebiet stark eingeschränkt war. Durch HTML5 eröffnen sich für Entwickler viele neue Möglichkeiten und so ist es inzwischen möglich eine Web-App offline-fähig zu machen oder den Standort des Gerätes per GPS zu ermitteln. Das Einsatzgebiet von Web-Apps wird dadurch deutlich erweitert und komplexe Anwendungen sind inzwischen realisierbar. Durch den Einsatz von zusätzlichen Frameworks wie z. B. Sencha Touch oder jquery mobile ist es deutlich einfacher eine Web-App an das Look&Feel native Apps anzupassen und durch UI-Komponenten, Animationen und zahlreiche Hilfsklassen sind Web-Apps inzwischen in manchen Bereichen von nativen Apps kaum zu unterscheiden. Web-Apps werden in Form einer Webseite angeboten und die Installation erfolgt automatisch, wobei die App für den Anwender nicht als solche wahrgenommen wird. Außerdem sind offline-fähige Web-Apps noch nicht sehr verbreitet, so dass kaum jemand versuchen wird eine Webseite aufzurufen, solange keine Internetverbindung besteht. Es gibt aber bereits Pläne für Web-

36 20 KAPITEL 2. APPS - MOBILE APPLIKATIONEN App-Stores die solche Web-Apps in gepackter Form anbieten, so dass es für Anwender verständlicher wird und die Unterschiede zur nativen App immer geringer werden. Der größte Nachteil ist im Moment der eingeschränkte Zugriff auf Hardware- oder Software-Funktionen der Geräteplattform. So ist es nicht möglich die Kamera der Geräte anzusteuern oder auf den Kalender zuzugreifen. Erste Entwicklungen in diese Richtung sind aber bereits im Gange und es ist zu erwarten dass Web-Apps bald deutlich mehr Möglichkeiten bieten als zum jetzigen Zeitpunkt. (vgl. Apple [4], Google [20]) Vorteile von Web-Apps: Geringe Entwicklungskosten Plattformübergreifende Apps möglich Einfache Distribution Nachteile von Web-Apps: Eingeschränkter Zugriff auf Plattformfunktionen Kein Zugang zu den nativen App-Stores Teilweise schlechtere Performance Eine Web-App läuft also im Browser und emuliert das Look & Feel nativer Apps so gut wie möglich mit HTML, CSS und gegebenenfalls Grafiken. Der Zugriff etwa auf Sensoren, Netzwerk- Interfaces oder Audio/Video ist damit aber nicht möglich, weil JavaScript die Schnittstellen zu diesen Betriebssystemfunktionen fehlen. Damit das funktioniert, braucht es einen Mittler, der die Funktionen JavaScript-seitig bereitstellt. Lau [33] Diese Aussage ist nur bedingt korrekt und inzwischen ist der Zugriff auf Sensoren möglich, jedoch noch sehr eingeschränkt. Web-Apps lassen sich aber durch Framework ergänzen, welche diese Schnittstellen zur Verfügung stellen. Es gibt verschiedene dieser sog. Hybrid-Frameworks, die teilweise Web-Apps direkt erweitern, oder in Form eines kompletten Applikations-Frameworks auf bestimmte Web-Technologien (wie z. B. JavaScript) aufsetzen. Eine Auswahl der wichtigsten Frameworks wird im nächsten Kapitel genauer betrachtet.

37 2.3. APP-TYPEN Hybrid Apps Hybrid Apps sind eine Mischung aus Web-App und nativer App. Ziel ist es die Vor- und Nachteile der nativen- und der Web-Apps auszugleichen. Hybrid Frameworks setzten i. d. R. auf Web-Technologien und ermöglichen es plattformübergreifende Apps zu entwickeln die für den Anwender nicht von nativen Apps zu unterscheiden sind. Vereinfacht bietet ein Hybrid-Framework einen Container für eine Web-App, wobei bestimmte plattformspezifischen Funktionen mithilfe von JavaScript (oder anderen Web-Sprachen) für den Entwickler bereitgestellt werden. So ist es möglich, dass die App beispielsweise auch auf den Kalender der jeweiligen Plattform zugreifen, oder das Gerät vibrieren lassen kann, was bei reinen Web-Apps nicht möglich ist. Hybrid-Apps werden zu nativen Paketen kompiliert und können somit über die plattformeigenen App-Stores angeboten werden. Die Basis der Hybrid-Technologie ist meist der sog. WebView, also ein in die native Anwendung eingebetteter Browser, der die Darstellung der Web-App übernimmt (vgl. Abbildung 2.2). Es gibt aber auch Frameworks die native UI-Komponenten erzeugen und somit nicht direkt auf Web-Apps basieren. Da die Entwicklung im Bereich der Web-Apps momentan sehr schnell vorran geht, und immer mehr Funktion die bisher nativen Apps vorbehalten waren, auch für Web-Apps zu Verfügung stehen, kann man davon ausgehen dass die Hybrid-Apps als Übergangslösung langfristig von reinen Web-Apps abgelöst werden. So hat Apple beispielsweise mit dem letzten Update von ios die Unterstützung von neuen HTML5-Funktionen deutlich ausgebaut und es ist jetzt beispielsweise möglich auf die Beschleunigungssensoren zuzugreifen (vgl. mobilexweb [42]).

38 22 KAPITEL 2. APPS - MOBILE APPLIKATIONEN Abbildung 2.2: Hybrid-App Architektur (Wrapper-Framework) (Quelle: Eigene Abbildung)

39 Kapitel 3 Cross-Plattform App-Entwicklung Nachdem die Bedeutung der Apps im letzten Kapitel ausführlich betrachtet wurde, beschäftigt sich dieses Kapitel mit den verschiedenen Möglichkeiten der App-Implementierung: Als Grundlage wird dabei die Entwicklung von Web- Apps auf Basis von HTML5 genauer betrachtet. Des Weiteren behandelt dieser Abschnitt eine Reihe von Frameworks, die die Web-App-Entwicklung vereinfachen, oder die Umsetzung in Form einer nativen App ermöglichen. Da mobile Web-Technologien in dieser Arbeit als Grundlage dienen sollen, wird dieser Bereich in diesem Kapitel sehr detailliert betrachtet. 3.1 Mobile Web-Entwicklung Web-Apps HTML Herkunft und Definition Die Hypertext Markup Language (HTML, dt. Hypertext - Auszeichnungssprache), oft kurz als Hypertext bezeichnet, ist eine textbasierte Auszeichnungssprache zur Strukturierung von Inhalten wie Texten, Bildern und Hyperlinks in Dokumenten. HTML-Dokumente sind die Grundlage des World Wide Web und werden von einem Webbrowser dargestellt. Neben den vom Browser angezeigten Inhalten einer Webseite enthält HTML zusätzliche Angaben in Form von Metainformationen, die z. B. über die im Text verwendete Sprache oder den Autor Auskunft geben oder den Inhalt des Textes zusammenfassen. Die Auszeichnungssprache wird vom World Wide Web Consortium (W3C) weiterentwickelt. Aktuell trägt HTML die Versionsnummer HTML5 befindet sich in der Entwicklung. Parallel existiert die Extensible Hypertext Markup Language (XHTML). Wikipedia [67] 23

40 24 KAPITEL 3. CROSS-PLATTFORM APP-ENTWICKLUNG Noch vor wenigen Jahren wurden mobile Webseiten aufgrund der eingeschränkten Leistungsfähigkeit und Verbindungsgeschwindigkeit auf Basis abgespeckter HTML-Versionen (z. B. WML : Wireless Markup Language) realisiert. Heutzutage sind mobile Webseiten hauptsächlich mit HTML, CSS und JavaScript realisiert, also auf Basis der selben Technologien, die auch bei der Desktop - Web-Entwicklung im Einsatz sind. Durch HTML5 gibt es zahlreiche bedeutende Neuerungen, die gerade im Bereich der App-Entwicklung vom Bedeutung sind. Die Geschichte und Definition von HTML5 ist relativ unübersichtlich, weshalb die der nächste Abschnitt einen Einblick geben soll: HTML wird vom W3C, dem World Wide Web Consortium einer unabhängigen Arbeitsgruppe entwickelt und die aktuelle Version 4.01 wurde am verabschiedet. Parallel existiert mit XHTML seit Januar 2000 eine Neuimplementierung von HTML auf Basis von XML. Die aktuelle Version XHTML 1.1 wurde am 31. Mai 2001 veröffentlicht. Da einige Organisationen mit der Entwicklung von HTML und XHTML durch das W3C nicht zufrieden waren, wurde 2004 die Arbeitsgruppe WHATWG 1 gegründet. Diese setzt sich auf Mitarbeitern verschiedener Firmen (u.a. Apple, Mozilla, Opera) und Organisationen zusammen und beschäftigt sich mit der Zukunft von HTML und Web-Anwendungen. (vgl. Wikipedia [67]) The Web Hypertext Application Technology Working Group - (WHATWG) is a growing community of people interested in evolving the Web. It focuses primarily on the development of HTML and APIs needed for Web applications. The WHATWG was founded by individuals of Apple, the Mozilla Foundation, and Opera Software in 2004, after a W3C workshop. Apple, Mozilla and Opera were becoming increasingly concerned about the W3C s direction with XHTML, lack of interest in HTML and apparent disregard for the needs of real-world authors. So, in response, these organisations set out with a mission to address these concerns and the Web Hypertext Application Technology Working Group was born. WHATWG [64] Die WHATWG hat sich unter anderem mit Web-Forms, also neuen Formularen für das Web und der Standardisierung von Web-Applications beschäftigt. Nachdem W3C und WHATWG lange Zeit parallel gearbeitet hatten wurde im Oktober 2006 die Zusammenarbeit beschlossen: Somit ist HTML5 eine Zusammenführung von HTML, XHTML und Web-Applications unter einer Organisation (W3C HTML Working Group) (vgl. WHATWG [64]) 1 WHATWG: Web Hypertext Application Technology Group

41 3.1. MOBILE WEB-ENTWICKLUNG WEB-APPS 25 Abbildung 3.1: HTML-Entwicklung Es ist sehr wichtig HTML5 nicht als ein großes Ganzes zu sehen, sondern als eine Sammlung von Technologien: HTML (Markup) Die eigentliche Auszeichnungssprache JavaScript-API Zahlreiche Schnittstellen (z. B. canvas) Web-Application Spezifikation z. B. Offline-Apps (Manifest) HTML5 is a new version of HTML4, XHTML1, and DOM Level 2 HTML addressing many of the issues of those specifications while at the same time enhancing (X)HTML to more adequately address Web applications. Besides defining a markup language that can be written in both HTML (HTML5) and XML (XHTML5) it also defines many APIs that form the basis of the Web architecture. Some of these APIs were known as "DOM Level 0" and were never documented before. Yet they are extremely important for browser vendors to support existing Web content and for authors to be able to build Web applications. WHATWG [64] Die Bezeichnung HTML5 wird oft für Technologien verwendet, die gar nicht Teil der Spezifikation sind sondern separat veröffentlicht werden: CSS3 Die neue Version der Cascading-Stylesheets Bestimmte JavaScript-APIs Geolocation Web SQL-Database / Indexed DB WebSockets

42 26 KAPITEL 3. CROSS-PLATTFORM APP-ENTWICKLUNG Zum Zeitpunkt dieser Arbeit ist HTML5 noch im Working-Draft-Status, wobei viele Funktionen bereits in Browsern implementiert sind und besonders mobile Browser eine umfangreiche Unterstützung bieten. Wann HTML5 komplett verabschiedet wird und ab wann die Implementierung abgeschlossen sein wird, ist nicht genau festgelegt Die WHATWG äußert sich auf die Frage nach dem Stand von HTML5 wie folgt: Different parts of the specification are at different maturity levels. Some sections are already relatively stable and there are implementations that are already quite close to completion, and those features can be used today (e.g. <canvas>). But other sections are still being actively worked on and changed regularly, or not even written yet. WHATWG [64] Der Reifegrad der Spezifikationen ist also sehr unterschiedlich, wobei einige wichtige Komponenten (z. B. Canvas) bereits als relativ stabil zu betrachten sind. Um den Umfang der Implementierung dieser neuen Funktionen zu testen, gibt es verschiedene HTML5-Tests, die je nach Umfang und Optimierung unterschiedliche Ergebnisse liefern Technologie und Verbreitung Dieser Abschnitt bietet eine kurze Übersicht über die Neuerungen der HTML5- Spezifikation und verwandter Spezifikationen. Abbildung 3.2: HTML5 - Spezifikation (Quelle: Eigene Abbildung) Die folgende Tabelle bietet eine Übersicht über den Stand der Implementierung: Der hierfür verwendete Test bietet lediglich Auskunft inwieweit die APIs

43 3.1. MOBILE WEB-ENTWICKLUNG WEB-APPS 27 vorhanden sind. Eine Bewertung der Qualität oder Performance ist nicht Bestandteil des Tests. Die Bewertung ist je Plattform getrennt und erfolgt in Form einer Punktzahl: So bedeutet beispielsweise 14/14 bei Web-Applications, dass 14 Teilbereiche der Spezifikation implementiert sind. Wie man anhand der folgenden Tabelle 3.1 sehen kann, ist die HTML5-Spezifikation sowohl unter ios, als auch unter Android relativ umfassend implementiert. Einzig Local Devices und Microdata sind noch nicht Bestandteil der mobilen Browser. Spec/OS ios 4.2 Android 2.2 Parser (1/11) (1/11) Web-Applications (14/14) + (10/14) Elements + (18/30) + (17/30) Forms + (31/38) + (32/38) User Interaction + (20/25) + (20/25) Video + (22/27) + (22/27) Audio + (20/20) + (20/20) Canvas + (20/20) + (20/20) Microdata (0/10) (0/10) Local Devices (0/20) (0/20) GESAMT Tabelle 3.1: HTML5-Verbreitung (Quelle: Eigene Tabelle / Daten: Leenheer [35])

44 28 KAPITEL 3. CROSS-PLATTFORM APP-ENTWICKLUNG HTML5-Spezifikation Parser: HTML Parsing Rules Web-Applications Application-Cache: Offline-fähige Webseiten (Manifest-File) Elements: Neue Struktur-Elemente Forms Section Elements (z. B. <section>, <nav>, <article>) Grouping Elements Text-level-semantics Content-Editable: Editierbare Bereiche definieren Input-Element-Types (z. B. search, tel, url, ) Input-Element-Attributes (z. B. autocomplete, placeholder) Form-Validation: Integrierte JavaScript-Validierung User-Interaction Drag and Drop Undo history: Browser-History-Verwaltung durch JavaScript Session history: Verwaltung der Navigation per JavaScript (z. B. bei AJAX wichtig) Text selection: Interface zur Textauswahl Video: Integration von Videos (je nach Browser: MPEG-4, H264, Ogg Theora, WebM) Audio: Integration von Audio (je nach Browser: PCM, MP3, AAC, Ogg Vorbis, WebM Canvas: Zeichen-API (2D, Text) Microdata: Integration maschinen-lesbarer Informationen Local Devices: Zugriff auf angeschlosse Geräte (z. B. Webcam)

45 3.1. MOBILE WEB-ENTWICKLUNG WEB-APPS 29 Folgende Teilbereiche sind besonders für mobile Web-Apps von Bedeutung und werden daher noch einmal ausführlich behandelt: Application-Cache: Durch ein so genanntes MANIFEST eine Textdatei mit Pfadangaben zu Dateien kann man definieren, welche Dateien lokal (beim Client) abgelegt werden sollen: Eine Web-App ist damit auch verfügbar, wenn keine Datenverbindung zum Internet besteht, wobei Dateien die auf dem Server aktualisiert wurden automatisch auch lokal aktualisiert werden. Forms: Formulare wurden stark überarbeitet: Es gibt viele neue Feld-Typen, wie E- mail, Url oder Tel. Außerdem wurden die Attribute der Formular-Felder überarbeitet um beispielsweise eine Automatische-Vervollständigung der Feld-werte (Autocomplete) zu ermöglichen. Diese Punkte spielen besonders bei MIDs mit Software-Tastatur eine Rolle, da sich diese an das Feld anpasst und bei einem Zahlenfeld beispielsweise nur Zahlen zeigt um dem Anwender die Eingabe zu erleichtern. Video und Audio: Bisher war es nicht möglich ein Video direkt in ein HTML-Dokument einzubinden, weshalb sich Adobe Flash im Internet als Video-Player etablieren konnte. Durch HTML5 ist es möglich Video und Audio direkt einzubinden, wie es bisher nur bei Bildern möglich war (img-tag). Da Flash auf mobilen Geräten teilweise gar nicht (ios) oder nur mit schlechter Performance läuft, ist die native Multimedia-Integration eine sehr bedeutende Neuerung. Problematisch ist momentan noch die Wahl des Codecs, da es noch keine einheitliche Linie der Browser-Hersteller gibt.

46 30 KAPITEL 3. CROSS-PLATTFORM APP-ENTWICKLUNG Es gibt einige Spezifikationen die unabhängig veröffentlicht werden, jedoch oft mit HTML5 in Verbindung gebracht werden. Viele dieser Spezifikationen sind besonders für Web-Apps von Bedeutung. Abbildung 3.3: HTML5 - Verwandte Spezifikationen (Quelle: Eigene Abbildung) Wie man anhand der nachfolgenden Tabelle sieht 3.2, sind die verwandten Spezifikationen nicht ganz so ausführlich implementiert, wie die HTML5- Spezifikation an sich. Besonders WebGL, die Files-API und WebWorkers sind noch nicht in die mobilen Browser integriert. Generell zeigt sich bei den verwandten Spezifikationen ein abweichender Stand der Implementierung: So bietet ios bereits mehr Schnittstellen als Android, da der Browser von Android weniger APIs der Communications-API bereitstellt. Spec/OS ios 4.2 Android 2.2 Geolocation + (10/10) + (10/10) WebGL - (0/10) - (0/10) Communication + (25/25) - (5/25) Files - (0/10) - (0/10) Storage + (15/20) + (15/25) Workers - (0/10) - (0/10) GESAMT Tabelle 3.2: Verbreitung verwandter Spezifikationen (Quelle: Eigene Tabelle / Daten: Leenheer [35])

47 3.1. MOBILE WEB-ENTWICKLUNG WEB-APPS 31 HTML5: Verwandte Spezifikationen Geolocation: Zugriff auf die Geo-Koordinaten des Gerätes per GPS WebGL: 3D-Grafik-Schnittstelle auf Basis von Canvas Communication: Diverse Kommunikationsschnittstellen, z. B. WebSockets - Socketverbindung per JavaScript Server-Send-Events WebSockets Cross-Document-Messaging Channel-Messaging Files: Zugriff auf das Datei-System per JavaScript Storage: Speicherzugriff per JavaScript WebSQL (SQL-Datenbank persistent) LocalStorage (Key-Value-Storage persistent) SessionStorage (Key-Value-Storage) Workers: Ausgelagerte JavaScript Prozesse - Parallele Ausführungen mehrerer Skripte

48 32 KAPITEL 3. CROSS-PLATTFORM APP-ENTWICKLUNG JavaScript und DOM JavaScript The standard name for JavaScript is ECMAScript, because it is defined by the ECMA (an international, private nonprofit standards organization). There are three well-known dialects on the market: JavaScript (trademark of Sun, licensed now to the Mozilla Foundation), ActionScript (trademark of Adobe), and JScript (trademark of Microsoft). At the base, they are the same language, and everyone adds new behavior. Firtman [13] Mit der Veröffentlichung der Vorversion des Netscape Navigators 2.0 am 18. September 1995 wurde JavaScript damals noch als LiveScript zum ersten Mal der Öffentlichkeit vorgestellt. Nachdem Netscape und Sun im Dezember eine Zusammenarbeit ankündigten um Java-Applets direkt mit Live-Script steuerbar zu machen, wurde die Sprache in JavaScript umbenannt. Microsoft unterstützt JavaScript in Form von JScript seit der Version 3.0 des Internet- Explorers, wodurch der sogenannte Browser-Krieg das Wettrüsten der unterschiedlichen Browser-Hersteller um die Gunst der Benutzer seinen Anfang fand. Ein wichtiger Schritt war die Standardisierung von JavaScript als ECMAScript (ECMA-262) durch die ECMA (European Computer Manufacturers Association) in Zusammenarbeit mit Netscape. Seit April ist ECMAScript eine ISO-Norm: ISO/IEC 16262:1998 Information technology ECMAScript language specification. (vgl. Wikipedia [68]) JavaScript existiert in Form mehrerer Implemetierung. In der nachfolgenden Tabelle 3.3 sind die wichtigsten JavaScript-Engines aufgelistet. Name Herkunft Browser SpiderMonkey Mozilla Netscape, Firefox TraceMonkey Mozilla Firefox 3.5 V8 Google Chrome, Chrome mobile SquirrelFish Apple Safari, Safari mobile MS JavaScript-Engine Microsoft Internet Explorer Tabelle 3.3: Verbreitete JavaScript Engines (Quelle: Eigene Tabelle - vgl. Wikipedia [68]) Performance ist bei JavaScript gerade in Verbindung mit den neuen HTML- 5-Schnittstellen ein wichtiges Thema, weshalb sich die Entwicklung in dieser Richtung in letzter Zeit stark verbessert hat. (vgl. Abb. 3.4)

49 3.1. MOBILE WEB-ENTWICKLUNG WEB-APPS 33 Abbildung 3.4: JavaScript Benchmark SunSpider (Quelle: Microsoft [37]) Ein wichtiger Meilenstein des Web 2.0 ist die AJAX-Technik (Asynchrones JavaScript und XML), welche dynamischen Nachladen von Inhalten erlaubt. Erst seitdem Webseiten zur Laufzeit verändert werden können ohne dass es eines Roundtrips bedarf, nähern sich Web-Anwendungen immer mehr den Desktop-Anwendungen an. In den letzten Jahren haben auch JavaScript- Frameworks immer mehr an Bedeutung gewonnen, da sie eine plattformübergreifende Lösung für Entwickler bieten und viele JavaScript-Konstrukte vereinfachen und abstrahieren. Einige bedeutende Frameworks sind beispielsweise Mootools, jquery, Dojo und ExtJS JSON JSON (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write. It is easy for machines to parse and generate. It is based on a subset of the JavaScript Programming Language json.org [31] JSON ist ein von Douglas Crockford spezifiertes, auf JavaScript-basiertes Format zum Datenaustausch. Dabei hat JSON aufgrund der Notation weniger Overhead als XML und es existieren Implementierung für fast jede Programmiersprache.

50 34 KAPITEL 3. CROSS-PLATTFORM APP-ENTWICKLUNG JSON ist besonders bei AJAX-Requests weit verbreitet und hat inzwischen XML als X in AJAX weitestgehend ersetzt. Da JSON immer valides JavaScript ist, lässt sich mit einem einfachen eval ein JavaScript-Objekt erzeugen. Aufgrund von Sicherheitsrisiken sollte man aber dennoch auf einen Parser zurückgreifen um möglichen Schadcode zu enttarnen DOM (Document Object Model) The Document Object Model is a platform- and language-neutral interface that will allow programs and scripts to dynamically access and update the content, structure and style of documents. The document can be further processed and the results of that processing can be incorporated back into the presented page. W3C [59] Das DOM bietet eine ist eine Schnittstelle auf HTML oder XML-Dokumente, die es ermöglicht den Inhalt, die Struktur und den Stil eines Dokuments dynamisch zu ändern. Die Implementierung der plattform- und sprachenunabhängigen DOM-Spezifikation ist eine Sammlung von Klassen, Methoden und Attributen. Seit 1998 ist DOM ein Standard des W3C. (vgl. W3C [59]) CSS3 CSS is the language for describing the presentation of Web pages, including colors, layout, and fonts. It allows to adapt the presentation to different types of devices, such as large screens, small screens, or printers. CSS is independent of HTML and can be used with any XML-based markup language. The separation of HTML from CSS makes it easier to maintain sites, share style sheets across pages, and tailor pages to different environments. This is referred to as the separation of structure (or: content) from presentation. W3C [57] Cascading Stylesheets (CSS) bestimmen das Aussehen von Webseiten und sorgen für eine saubere Trennung der Auszeichnung (HTML) und der Stil-Formate (CSS-Regeln). CSS 1.0 wurde 1996 in Form einer Recommendation veröffentlicht und ist in nahezu allen Browsern vollständig implementiert. CSS 2.0 folgte 1996, wobei die Implemetierung bis heute nicht in allen Browsern in vollem Umfang erfolgt ist. Seit 2000 wird an CSS3 gearbeitet, wobei diese Spezifikation modular aufgebaut ist und die Entwicklung der Teilbereiche einem eigenen Zyklus folgt.

51 3.2. FRAMEWORKS Frameworks Es gibt zahlreiche Frameworks mit unterschiedlichen Ansätzen und Zielplattformen: Web-Application-Frameworks erleichtern die Programmierung von Web- Apps und stellen Hilfsfunktionen und vorgefertige UI-Elemente bereit. Wobei sogenannte Hybrid-Frameworks die Erstellung von nativen Apps ermöglichen, die teilweise auf Web-Apps aufsetzen. Andere Frameworks bieten eine eigene API auf Basis einer Web-Sprache, um native Apps zu entwickeln. Man kann diese Frameworks somit grob in 3 Kategorien einteilen, wobei die Abgrenzung teilweise fließend verläuft: Web-Application-Framework (Web-App-Framework Ziel: Web-App) Web-Application Frameworks basieren auf reinen Web-Standards in Form von HTML5, JavaScript und CSS3. Das Ergebnis solcher Frameworks ist eine HTML5-standardkonforme Web-App, die über eine Website oder einen Web- App-Store verbreitet werden kann. Zum Funktionsumfang gehören dabei meist zahlreiche UI-Komponenten und JavaScript-Hilfsfunktionen (z. B. für die Datenbeschaffung) Cross-Compiler-Framework (Hybrid-Framework Ziel: Native App) Cross-Compiler-Frameworks setzen meist auf eine populäre Web-Sprache wie beispielsweise JavaScript oder Ruby, um mit dieser die gesamte Applikation zu entwickeln. Zusätzliche Technologien wie HTML oder CSS werden nicht benötigt. Ziel dieser Frameworks ist es die Programmiersprache der nativen App-Entwicklung durch eine bekannte Web-Sprache zu ersetzen und einen plattformübergreifenden Compiler bereitzustellen. Die finale App wird dann kompiliert und ist nur als native App nutzbar. Ein Einsatz der App in Form einer Web-App ist nicht möglich, da es sich bei der API nicht um einen Standards handelt, sondern Framework-spezifische Schnittstellen verwendet werden. Wrapper-Framework (Hybrid-Framework Ziel: Native App)) Wrapper-Frameworks sind als Ergänzung für bestehende Web-Apps zu verstehen. Sie binden Web-Apps mithilfe eines WebViews einem Browserfenster in eine native App ein. Somit ist es möglich eine Web-App zu einer nativen App zu kompilieren ohne etwas am Quelltext der Web-App zu ändern. Zusätzlich ermöglicht beispielsweise PhoneGap den Zugriff auf native Systemfunktionen per JavaScript-Schnittstellen um eine Web-App noch besser an die Plattformen anzupassen und Funktionen zu nutzen, die über HTML5 momentan noch nicht verfügbar sind.

52 36 KAPITEL 3. CROSS-PLATTFORM APP-ENTWICKLUNG Web-Application-Frameworks Sencha Touch Sencha Touch, the first HTML5 mobile JavaScript framework that allows you to develop mobile web apps that look and feel native on iphone and Android touchscreen devices, has just hit the big 1.0. Sencha [51] Sencha Touch basiert auf HTML5, CSS3 und JavaScript. Wobei die Entwicklung der Oberfläche, als auch der Logik in JavaScript erfolgt, und es für verschiedene UI-Komponenten JavaScript-Klassen gibt, die schließlich HTML generieren. Die Oberfläche lässt sich mit CSS sehr gut anpassen und das Einfügen eigener CSS-Klassen ist jederzeit möglich. Da Sencha Touch auf dem JavaScript-Framework ExtJS basiert, gibt es eine umfangreiche Funktionssammlung um die Anwendungsentwicklung zu erleichtern: Die Datenbeschaffung erfolgt beispielsweise per AJAX oder JSONP. Außerdem gibt es zahlreiche UI-Komponenten, die optisch an die mobilen Geräte angepasst wurden. Die erstellen Apps sind standardkonform nach HTML5 und CSS3, wodurch ein Deployment in Form einer Web-App jederzeit möglich ist. Die Anwendungsentwicklung erfolgt programmatisch, so dass sämtliche Elemente und die passende Logik mit JavaScript entwickelt werden und kein HTML oder CSS geschrieben werden muss. Sencha-Touch lässt sich auch mit anderen Frameworks kombinieren (vgl. Sencha [51]) jquery Mobile A unified user interface system across all popular mobile device platforms, built on the rock-solid jquery and jquery UI foundation. Its lightweight code is built with progressive enhancement, and has a flexible, easily themeable design. jquery mobile [41] jquery Mobile setzt auf dem bekannten JavaScript-Framework jquery auf und ist momentan erst im Alpha-Stadium. Da die Community des jquery- Frameworks sehr groß ist und es zahlreiche Sponsoren (u.a. Nokia, BlackBerry, Palm) für das junge Projekt gibt, ist es wahrscheinlich, dass es in naher Zukunft eine wichtige Rolle spielen wird. Dabei setzt die mobile Version komplett auf Web-Standards auf Basis von HTML, CSS und JavaScript. Neben zahlreichen UI-Komponenten und Event- Handling für die Touch-Bedienung gibt es auch Effekte und Hilfsfunktionen für Ajax-Requests. jquery Mobile setzt im Gegensatz zu Sencha Touch stark auf einen deklarativen Ansatz: D. h. die Programmierung erfolgt innerhalb des HTML-Markups, wodurch entsprechende JavaScript-Methoden angesteuert werden (vgl. jquery mobile [41]).

53 3.2. FRAMEWORKS Cross-Compiler-Frameworks Appcelerator Titanium Mobile Titanium translates your hard won web skills into native applications that perform and look just like they were written in Objective-C [iphone and ipad] or Java [Android]. With over 300 APIs, a thriving developer community, and the support you need, you can build applications that are more social, local, media rich, interactive, and extensible. Appcelerator [1] Titanium Appcelerator Mobile setzt mit einer eigenen IDE ganz auf JavaScript und unterstützt im Moment Android, ios und BlackBerry-OS. Die komplette App wird in JavaScript geschrieben und zur Laufzeit auf die nativen API- Schnittstellen abgebildet: Somit ist die ganze Logik, aber auch die Oberfläche komplett in JavaScript geschrieben Es wird kein HTML oder CSS für die Darstellung benötigt wird. Diese Architektur bietet eine bessere Performance als bei reinen Web-Apps auf HTML-CSS-Basis, wobei das Deployment nur über die plattformspezifischen Wege möglich ist und ein Veröffentlichung in Form einer mobilen Webseite nicht möglich ist. Titanium Appcelerator Mobile setzt somit nicht auf HTML5 auf, sondern arbeitet mit einer eigenen API, die zwar auf Basis der Apache-Lizenz frei verfügbar, jedoch nach einem eigenen Standard arbeitet. (vgl. Appcelerator [1]) Rhodes Rhodes is an open source framework to rapidly build native apps for all major smartphone operating systems (iphone, Windows Mobile, RIM, Symbian and Android). These are true native device applications (NOT mobile web apps) which work with synchronized local data and take advantage of device capabilities such as GPS, PIM contacts and calendar, camera, native mapping, push, barcode, signature capture, and Bluetooth. Rhomobile [47] Rhodes setzt auf Ruby als Programmiersprache und unterstützt neben Android, ios und BlackBerry auch Windows Mobile und Symbian. Mit wichtigen Features wie Synchronisation, einem ORM (Object Relational Mapper) und des Model-View-Controller Paradigmas bietet Rhodes eine großen Funktionsumfang. Wie auch bei Titanium ist der Rhodes-Kern als Open-Source verfügbar.die

54 38 KAPITEL 3. CROSS-PLATTFORM APP-ENTWICKLUNG API ist eine Eigenentwicklung somit basiert Rhodes nicht auf offenen Standards. Damit ergeben sich auch dieselben Nachteile: Rhodes-Apps können nicht als Web-App deployed werden und sind an die Vertriebsformen der jeweiligen Plattformen gebunden (vgl. Rhomobile [47] Wrapper-Frameworks PhoneGap PhoneGap is an open source development framework for building cross-platform mobile apps. Build apps in HTML and JavaScript and still take advantage of core features in iphone/ipod touch, ipad, Google Android, Palm, Symbian and Blackberry SDKs. PhoneGap [45] PhoneGap unterscheidet sich von Rhodes und Titanium, da es sich nicht um ein komplettes Application-Framework handelt, sondern vielmehr um einen Wrapper, der eine bestehende Web-App als native App verfügbar macht und native Schnittstellen auf Basis von JavaScript repliziert. PhoneGap bietet für nahezu jede Plattform ein vorgefertigtes Projekt für die passende IDE: Für iphone-apps gibt es eine Xcode-Vorlage, wobei für Android ein Eclipse-Projekt zum Download steht. Diese Projekt-Templates stellen die minimale Struktur der App in Form eines Web-Views dar, in welchen die Web- App eingebunden wird. Zusätzlich gibt es eine JavaScript API, die zahlreiche native Schnittstellen zur Verfügung stellt. So ist es möglich per JavaScript auf die Kamera der Geräte zuzugreifen ohne Objective-C, bzw. Java zu schreiben. Diese Projekte lassen sich dann als native Apps exportieren und über die jeweiligen Vertriebswege veröffentlichen (vgl. PhoneGap [45]).

55 Kapitel 4 Bewertung Nach der Ausführung der App-Typen und Frameworks, werden diese nun zur besseren Vergleichbarkeit mithilfe eines Bewertungsverfahrens gegenübergestellt. Diese Bewertung kann dabei helfen, die geeigneten Ansätze für Projekte zu wählen und sich einen objektiven Überblick über die Vor- und Nachteile der Ansätze zu verschaffen. 4.1 Kriterienkatalog Um die verschiedenen Ansätze der plattformübergreifenden App-Entwicklung zu bewerten ist es wichtig messbare Kriterien festzulegen, anhand derer dann die Einschätzung erfolgen kann. Diese Kriterien setzen sich sowohl aus technischen, als auch aus betriebswirtschaftlichen Punkten zusammen. Insgesamt gibt es fünf Kategorien, in welche sich die Kriterien einordnen lassen: Technisch: Welche technischen Möglichkeiten bietet ein Ansatz? Entwicklung: Wie läuft die Entwicklung ab (IDE, Dokumentation)? Usability: Wie hoch ist die Usability der App für den Benutzer? Sicherheit: Wie sicher ist ein gewählten Ansatz? Marketing: In welcher Form erfolgt die Distribution, Welche Einnahme- Quellen gibt es? Diese Hauptkategorien sind an die wichtigsten Entscheidungen bei der App- Entwicklung angelehnt und sollen als Entscheidungsgrundlage für die Wahl des zu verwendenden Ansatzes dienen. 39

56 40 KAPITEL 4. BEWERTUNG Um eine übersichtliche und nachvollziehbare Bewertung zu ermöglichen, gliedert sich diese in drei Stufen: Zeichen Bedeutung Kriterium wird erfüllt Kriterien wird teilweise erfüllt + Kriterium wird nicht erfüllt Tabelle 4.1: Einteilung der Kriterien Um die Bewertung der Kriterien möglichst nachvollziehbar und messbar zu gestalten, sind die drei Stufen für jede Kategorie separat spezifiziert. Die Einschätzung erfolgt im Rahmen dieser Arbeit für die drei App-Arten: Native-App, Web-App, Hybrid-App. Eine detaillierte Einschätzung anhand konkreter Frameworks ist machbar, jedoch im Rahmen der Arbeit nicht umgesetzt. Die Einschätzung erfolgt somit pauschal je App-Art. Sofern sich Frameworks innerhalb einer App-Art in ihrer Bewertung stark voneinander unterscheiden, so ist eine aufgeschlüsselte Bewertung in Form einer Liste angegeben. Eine Gewichtung des Kritierenkatalogs ist im Rahmen dieser Arbeit nicht realisiert. Je nach Anforderungen der App-Entwicklung lässt sich aber eine grobe Gewichtung ableiten, die anhand der Aufschlüsselung leicht anwendbar ist. Abbildung 4.1: Kriterienkatalog: Legende (Quelle: Eigene Abbildung)

57 4.2. KRITERIEN Kriterien Technisch Unterstützte Plattformen Web-Browser + Alle wichtigen Mobile- und Desktop-Browser werden unterstützt Alle wichtigen Mobile-Browser werden unterstützt Keine Browser-Unterstützung Feature-Phones + UMTS und GPRS Feature-Phones werden unterstützt UMTS-Feature-Phones werden unterstützt Keine Unterstützung von Feature-Phones Smartphones + Android, ios, BlackBerry und weitere werden unterstützt Mindestens eine Smartphone-Plattform wird unterstützt Smartphones werden nicht unterstützt Tablets + Die wichtigen Tablet-Plattformen werden unterstützt (ios, Android) Mindestens eine Tablet-Plattform wird unterstützt Keine Tablet-Unterstützung Tabelle 4.2: Kriterienkatalog: Plattformunterstützung Die Anzahl der unterstützten Plattformen ist bei der plattformübergreifenden Entwicklung auf den ersten Blick das wichtigste Kriterium. Dabei denkt man bei Apps meistens an Smartphones und Tablets, allerdings sind Feature- Phones und der Web-Browser nicht zu vernachlässigen: So verfügen aktuelle Feature-Phones meist über einen ausgereiften Browser, welcher Web-Apps unterstützt und uneingeschränktes Surfen ermöglicht. Mindestens ein Web- Browser ist auf sehr vielen Geräten installiert, dieser dient als Plattform für Web-Apps und ist damit als universelle Plattform der App-Entwicklung von großer Bedeutung. (vgl. Kapitel 4.2) Die Eröffnung des Chrome-Web-Stores (Google) im Dezember 2010 zeigt wie wichtig die Kategorie der Web-Apps, und damit der Browser als Plattform ist: Dabei handelt es sich um eine Sammlung von Web-Apps die sich im Chrome- Browser direkt installieren lassen: Einmal kann man Hosted Apps einreichen, also mobile Webseiten, die dann in Form einer Verlinkung installiert werden.

58 42 KAPITEL 4. BEWERTUNG Abbildung 4.2: Kriterienkatalog: Plattformunterstützung (Quelle: Eigene Abbildung) Die zweite Möglichkeit sind gepackte Apps, die zusätzlich noch Zugriff auf die Google Chrome Extension APIs haben und lokal beim Benutzer abgelegt werden. Zusätzlich bietet Google die Möglichkeit kostenpflichtige Apps anzubieten. (vgl.google [18])

59 4.2. KRITERIEN Plattform-Ressourcen Hardware + Kamera, GPS, Beschleunigungssensor und mehr werden unterstützt Mindestens eine Hardware-Komponente wird unterstützt Kein Hardware-Zugriff möglich Software + Zugriff auf Kontakte, den Kalender und Benachrichtigungen Mindestens eine Software Komponente wird unterstützt Kein Zugriff auf Software-Ressourcen Tabelle 4.3: Kriterienkatalog: Plattform-Ressourcen Abbildung 4.3: Kriterienkatalog: Plattform-Ressourcen (Quelle: Eigene Abbildung) Der Zugriff auf Hard- bzw. Software-Ressourcen hat je nach Art der App eine stark unterschiedliche Gewichtung: Bei Spielen ist es oft wichtig Zugriff auf die Sensoren der Plattform zu haben, Business-Anwendungen setzen dabei mehr auf Software-Schnittstellen und brauchen beispielsweise Zugriff auf das Adressbuch oder den Kalender. Die Metrik fordert dabei Hard- bzw. Software-Schnittstellen die bei der App- Entwicklung oft verwendet werden, um das Kriterium komplett zu erfüllen. Mit mindestens einer Hard- bzw. Softwarekomponente ist zumindest teilweise Zugriff auf die Plattform möglich was zu einer mittleren Wertung führt. Kein Zugriff führt zu einer negativen Bewertung.

60 44 KAPITEL 4. BEWERTUNG Prinzipiell bieten native Apps den kompletten Zugriff auf Hard- und Software- Schnittstellen (+). Hybrid-Apps haben ebenfalls einen relativ umfangreichen Zugriff, da die nativen Schnittstellen über entsprechende Wrapper repliziert werden (Hardware: +, Software: ). Bei Web-Apps ist der Hardware-Zugriff momentan nur teilweise möglich: So ist ein Zugriff auf den GPS-Sensor bereits problemlos möglich und Apple bietet seit ios 4.2 Zugriff auf den Beschleunigungs- und Lagesensor. Auch wenn mit der Local-Devices-API (HTML5) bald mehr Zugriff möglich sein soll, ist momentan beispielsweise noch kein Zugriff auf die Kamera möglich. Software- Schnittstellen sind bei Web-Apps momentan noch nicht verfügbar, allerdings ist es möglich Benachrichtigungen auf JavaScript-Basis selbst zu implementieren (Hardware:, Software: ) Performance + Flüssige Bedienung, Schnelle Animationen Flüssige Bedienung, Akzeptable Animationen Ruckelnde Bedienung, Keine Animationen Tabelle 4.4: Kriterienkatalog: Performance Abbildung 4.4: Kriterienkatalog: Performance (Quelle: Eigene Abbildung) Performance spielt bei Apps eine entscheidende Rolle: Die Bedienung durch den Touchscreen sollte schnell und flüssig ablaufen, Hintergrundprozesse sollten die Geschwindigkeit einer App nicht beeinträchtigen.

61 4.2. KRITERIEN 45 Die Messbarkeit der Geschwindigkeit ist dabei nicht ohne weiteres möglich, da immer auch eine Abhängigkeit zur verwendeten Hardware, also dem jeweiligen Gerät besteht. Eine ausführliche Messung mit mehreren Geräten und Plattform-Versionen ist daher im Rahmen dieser Arbeit nicht realisierbar. Die Messung der Performance erfolgt anhand der Oberfläche auf den mir zur Verfügung stehenden Geräten: Samsung Galaxy S (Android 2.2) iphone 3GS, iphone 4, ipad (ios 4.2) Die Performance nativer Apps ist unabhängig von der verwendeten nativen Plattform (ios, Android) immer am besten, da die nativen Schnittstellen auf die Plattform optimiert sind und keine Abstraktion nötig ist. (+) Hybrid-Apps unterscheiden sich in ihrer Performance sehr stark, je nachdem welches Framework eingesetzt wird: Wenn die Oberfläche durch native Komponenten generiert wird, ist die Performance annähernd so gut wie bei nativen Apps (Titanium Appcelerator Mobile). Setzt das Hybrid-Framework auf eine gewrappte Web-App (PhoneGap), so leitet sich die Performance von der verwendeten Web-App ab ( ). Titanium Appcelerator: Native Komponenten (+) Rhodes: Native Komponenten (+) PhoneGap: Web-App Komponenten ( ) Sencha Touch: Web-Komponenten ( ) jquery mobile: Web-Komponenten ( ) Bei Web-Apps hängt es sehr stark davon ab wie komplex die Oberfläche gestaltet wurde und ob es sich um sauberen CSS, HTML und JavaScript-Code handelt. Setzt man bei den Web-Apps zusätzlich auf ein UI-Framework (z. B. Sencha Touch), so hat man Komponenten die den nativen ähneln, jedoch eine etwas schlechtere Performance liefern. Insgesamt ist die Performance bei Web- Apps sehr abhängig vom verwendeten Browser, der wiederum von der nativen Plattform und der verwendeten Hardware abhängt ( ). PhoneGap bietet eine sehr offene Architektur und es ist möglich durch Erweiterungen auch auf native Komponenten zuzugreifen. So lässt sich beispielsweise die Hauptnavigation mit nativen UI-Elemente realisieren, wobei der eigentliche Inhalt in Form einer Web-App aufgebaut ist. Da diese Erweiterungen nicht für jede Plattform in selbem Maße zu Verfügung stehen, werden diese im Rahmen der Bewertung vernachlässigt.

62 46 KAPITEL 4. BEWERTUNG Offline-Ressourcen + Umfangreicher Offline-Support (Daten und Dateien) Teilweise Offline-Support (Daten) Kein Offline-Support Tabelle 4.5: Kriterienkatalog: Offline Ressourcen Abbildung 4.5: Kriterienkatalog: Offline Ressourcen (Quelle: Eigene Abbildung) Die Offline-Fähigkeit einer App lässt sich in zwei Bereiche gliedern, die jeweils besonders wichtig sind die Entwicklung von Apps: Es sollte möglich sein den Quelltext, bzw. die ausführbare App direkt auf der Plattform abzulegen: Somit kann diese auch gestartet werden, falls keine Verbindung zum Internet besteht. Des Weiteren sollte es möglich sein auch Daten lokal abzulegen: Einerseits kann man eine App somit auch offline nutzbar machen und ggf. Daten bei Verbindungsaufbau synchronisieren, andererseits kann ein Offline-Speicher auch für das Caching verwendet werden, um die Apps performanter zu machen. Anwendungs-Code Die Offline-Fähigkeit der Applikation an sich ist sowohl bei nativen Apps, als auch bei Hybrid-Apps von Haus aus gegebenen: So sind alle Dateien in Form einer gepackten App lokal auf dem Gerät abgelegt (+). Web-Apps hingegen sind erst seit HTML5 in der Lage über ein so genanntes Manifest-File eine Definition zu liefern, welche Dateien lokal abgelegt werden sollen ( ).

63 4.2. KRITERIEN 47 Auszug auf dem roomieplanet-mobile Manifest Algorithmus 4.1 Cache Manifest 1 CACHE MANIFEST 2 CACHE: 3. / r e s o u r c e s / themes / images / d e f a u l t / t i p. png 4. / r e s o u r c e s / themes / images / d e f a u l t / check. png NETWORK: 7. / mobile. php 8 h t t p : //roomiepla.net/data/ 9 10 # Hash : 8 a 3af7f1936f4225f12eb0667b194c09 Datenhaltung Die lokale Ablage von Daten ist bei nativen Apps eine zwingende Voraussetzung und somit auch in vollem Umfang möglich (+). Hybrid-Apps können entweder über Wrapper auf die Datenspeicher der nativen Plattform zugreifen oder über die Speichermöglichkeiten von HTML5- verwandten Spezifikationen zurückgreifen (+). Web-Apps können über folgende neu eingeführten APIs Daten lokal ablegen (HTML5-verwandte Spezifikationen): LocalStorage Persistenter Key-Value-Speicher SessionStorage Persistenter Key-Value-Speicher (über die Dauer einer Session) Indexed DB, (WebSQL) Datenbanken LocalStorage roomieplanet mobile (Safari Web-Developer Tools): Abbildung 4.6: Tools) LocalStorage roomieplanet mobile (Safari Web-Developer (Quelle: Eigene Abbildung)

64 48 KAPITEL 4. BEWERTUNG Multimedia + Umfangreiche Video und Audio Unterstützung Video oder Audio Unterstützung (eingeschränkt) Kein Multimedia Support Tabelle 4.6: Kriterienkatalog: Multimedia Abbildung 4.7: Kriterienkatalog: Multimedia (Quelle: Eigene Abbildung) Die Bewertung ist im Rahmen dieser Arbeit auf die Anzahl der unterstützten Formate beschränkt, die Performance wird nicht berücksichtigt. Die Unterstützung von Multimedia ist bei nativen Apps sehr umfangreich möglich, was bedeutet dass sehr viele Formate unterstützt werden (+). Bei Hybrid-Apps kann je nach Framework auf die nativen oder die Web- App Schnittstellen zugegriffen werden (+). Web-Apps unterstützen Audio und Video durch die <audio> und <video> Tags der HTML5-Spezifikation. Je nach Browser und Plattform unterscheidet sich allerdings die Anzahl und Art der unterstützten Formate. Insgesamt ist die Unterstützung im Moment als gut anzusehen, da viele wichtige Codecs implementiert sind (+). HTML5 - Multimedia-Formate ios 4.2 Audio: WAV, AIF, MP3, AAC-LC, HE-AAC Video: MPEG-4, H.264 Android 2.3 Audio: WAV, Ogg Vorbis, MIDI, MP3, AMR, HE-AAC, AAC-LE Video: MPEG-4, H264, H263 (Quelle: Google [17], Apple [6])

65 4.2. KRITERIEN Benachrichtigungen + Push-Messages und weitere Benachrichtigungen sind möglich Eingeschränkte Unterstützung für Benachrichtigungen Keine Benachrichtigungen möglich Tabelle 4.7: Kriterienkatalog: Benachrichtigungen Abbildung 4.8: Kriterienkatalog: Benachrichtigungen (Quelle: Eigene Abbildung) Benachrichtigungen spielen besonders bei Apps eine Rolle, die den Anwender auf dem Laufenden halten möchten. Mit Push-Benachrichtigungen ist dies sehr einfach realisierbar (+), gibt es andere Arten der Benachrichtigung, so ist das Kriterium zumindest teilweise erfüllt ( ). Bei nativen Apps gibt es je nach Plattform unterschiedliche Arten der Benachrichtigung. Bei ios und Android gibt es die Möglichkeit so genannte Push-Benachrichtigungen an die Anwender zu schicken: Auch wenn die App im Hintergrund nicht läuft, lassen sich so Nachrichten an den Anwender schicken. Auch Benachrichtigungen über Textmeldung innerhalb der Anwendung sind möglich, wobei diese durch akustisches oder haptisches Feedback unterstützt werden können (Ton, Vibration) (+). Hybrid-Apps bieten ebenfalls die Möglichkeit diese Push-Nachrichten der nativen Apps zu nutzen. Weitere Möglichkeiten der Benachrichtigung sind abhängig vom verwendeten Framework, allerdings sind Textmeldungen meist über die native UI oder zumindest eine ähnliche UI implementiert. Akustisches und haptisches Feedback sind möglich (+). Web-Apps bieten keine Unterstützung für Push-Benachrichtigungen, auch wenn momentan bereits an einer ähnlichen Lösung gearbeitet wird. Normale Benachrichtigungen sind über die Browser-Elemente per JavaScript möglich. Zusätzlich bieten UI-Frameworks wie Sencha Touch mit CSS und HTML generierte Benachrichtigungselemente, die per JavaScript gesteuert werden ( ).

66 50 KAPITEL 4. BEWERTUNG Lizenzierung + Frei von Lizenzen, Open Source Lizenz (kommerz. Nutzung erlaubt) Duale Lizenzierung Open Source und kommerzielle Lizenzierung Proprietäre Lösung Tabelle 4.8: Kriterienkatalog: Lizenzierung Abbildung 4.9: Kriterienkatalog: Lizenzierung (Quelle: Eigene Abbildung) Die Lizenzierung spielt neben den Entwicklungskosten besonders dann eine Rolle, wenn ein Framework an die eigenen Bedürfnisse angepasst werden soll. Die Bewertungs-Skala geht daher von möglichst freier Nutzung (+) hin zur proprietären Lösung (-), die weniger Möglichkeiten für eigene Anpassungen bietet. Reine Web-Apps basieren auf offenen Standards und sind daher frei von Lizenzen (+). Native Apps sind an die jeweiligen Bedingungen der Plattform gebunden und meist proprietär ( ). Die Lizenzierung spielt besonders bei den Hybrid-Apps eine Rolle: (+) Lizenzen: Hybrid Frameworks PhoneGap, Rhodes, jquery Mobile: MIT (+) Sencha Touch: Duale Lizenzierung (Zurzeit kostenlos auch für die kommerzielle Nutzung) ( ) Appcelerator Titanium: Apache Public License v2 (+)

67 4.2. KRITERIEN Entwicklung Community + Große Community, viele Ressourcen (Blogs, Wikis, Foren) Normale Community, einige Ressourcen Kleine Community, wenige Ressourcen Tabelle 4.9: Kriterienkatalog: Community Abbildung 4.10: Kriterienkatalog: Community (Quelle: Eigene Abbildung) Eine große Community erleichtert den Entwicklungsprozess: Wikis und Foren bieten kostenlose Hilfestellung und eine große Community bedeutet meist auch ausgereiftere und besser getestete Software. Je größer die Community, desto besser die Bewertung. Die Community der nativen App-Entwicklung sind i. d. R. relativ groß und es existieren neben offiziellen Dokumentation auch zahlreiche Bücher, Foren und Tutorials. Die Größe der Communites unterscheidet sich bei Hybrid-Frameworks teilweise stark: Sencha Touch: Großes Forum (+) PhoneGap: Aktive Google-Gruppe, Wiki (+) Rhodes: Zugang erst nach Registrierung ( ) Titanium Appcelerator: Eigenes Community System ( ) jquery mobile: Alpha-Phase, daher nicht relevant Die Web-Community ist sehr groß und neben Grundlagen-wissen über Web- Technologien sind auch aktuelle Themen wie HTML5 bereits sehr gut vertreten.

68 52 KAPITEL 4. BEWERTUNG Tools + IDE-Support (z. B. Eclipse) Keine IDEs, aber Tools verfügbar Keine Tools oder IDEs verfügbar Tabelle 4.10: Kriterienkatalog: Tools Abbildung 4.11: Kriterienkatalog: Tools (Quelle: Eigene Abbildung) Eine gute Unterstützung durch Tools erleichtert die Software-Entwicklung erheblich. Eine Integration von Debuggern und Dokumentation hilft die Übersicht zu bewahren und vereint mehrere Prozesse an einer zentralen Stelle. Umso besser die Tool-Unterstützung, desto besser die Bewertung. Native Anwendungsentwicklung basiert meist auf einem SDK mit eigener IDE Oft handelt es sich auch um ein Plugin für Eclipse, oder eine IDE auf Basis von Eclipse (+). Hybrid-Apps sind sehr unterschiedlich gestrickt und daher ist auch die Tool- Unterstützung unterschiedlich: (+) PhoneGap: Erstellt native Projekte Nutzung der Plattform eigenen IDE (XCode, Eclipse, etc.) Titanium Appcelerator: Eigene IDE Rho Mobile: Eigene IDE Sencha Touch und jquery mobile basieren auf Web-Technologien und die möglichen Tools sind generell für Entwicklung von Web-Anwendungen geeignet. So gibt es zahlreiche Editoren und IDEs für HTML und JavaScript, jedoch ist das Debugging und die IDE-Integration der Frameworks oft nicht optimal, was zu einer mittleren Wertung führt ( ).

69 4.2. KRITERIEN Wiederverwendbarkeit + Der Großteil des Quelltexts kann wieder verwendet werden (plattformübergreifend) Teile des Quelltexts können wieder verwendet werden (plattformübergreifend) Quelltext kann nicht wieder verwendet werden, oder nur für dieselbe Plattform Tabelle 4.11: Kriterienkatalog: Wiederverwendbarkeit Abbildung 4.12: Kriterienkatalog: Wiederverwendbarkeit (Quelle: Eigene Abbildung) Wiederverwendbarkeit ist im Rahmen des Kritierenkatalogs prinzipiell die Möglichkeit bestimmte Quelltext-Abschnitte für Projekte auf weiteren Plattformen zu nutzen. Je portabler der Quelltext ist, desto besser ist die Bewertung der Wiederverwendbarkeit (Code-Re-Use) Hybrid-Apps auf Basis eines Web-View-Containers (PhoneGap) bieten hinsichtlich der Wiederverwendbarkeit einen großen Vorteil: Der komplette Quelltext einer Web-App kann als Grundlage einer Hybrid-App dienen und durch Vererbung und Überschreiben von Methoden lässt sich mit einer einheitlichen Code-Base arbeiten, die sowohl für Hybrid- als auch für die Web-App verwendet werden kann (+). Eine Hybrid-App läuft theoretisch auf mehreren Plattformen mit identischem Quelltext, jedoch unterscheiden sich Geräte in Ausstattung und Ressourcen, wodurch teilweise Anpassungen je Plattform nötig werden (0). Native App: Quelltext ist an eine Plattform gebunden ( ) Hybrid-App: Der Quelltext kann teilweise wiederverwendet werden ( ) Web-Apps: Der Quelltext kann als Grundlage einer Hybrid-App genutzt werden (Web-Container) (+)

70 54 KAPITEL 4. BEWERTUNG Dokumentation + Umfangreiche Dokumentation: Aktuelle Tutorials, Manual, Bücher Durchschnittliche Dokumentation: Manual Keine, schlechte oder veraltete Dokumentation Tabelle 4.12: Kriterienkatalog: Dokumentation Abbildung 4.13: Kriterienkatalog: Dokumentation (Quelle: Eigene Abbildung) Eine gute Dokumentation ist eine wichtige Voraussetzung für die Softwareentwicklung und daher relevant für die Bewertung. Die Dokumentation ist bei nativen Apps meist sehr gut (+). Die Dokumentation der Hybrid-Apps ist stark abhängig vom jeweils verwendeten Framework, aber im Schnitt als mittelmäßig anzusehen ( ): Sencha Touch: Gute API-Dokumentation, Aktuelles User-Forum (+) PhoneGap: Schlechte API-Dokumentation, Große Google-Gruppe ( ) Rhodes: Zugriff zur Dokumentation erst nach Registrierung ( ) jquery mobile: Alpha-Phase daher noch nicht relevant Web-Apps sind sehr gut dokumentiert: Auch wenn erst langsam mehr Bücher zu diesem Thema erscheinen ist davon auszugehen dass es in nächster Zeit sehr umfangreiche Literatur und Dokumentation geben wird.

71 4.2. KRITERIEN Usability Look & Feel + Natives User Interface Erwartungskonform Quasi-natives User Interface Erwartungskonform Nicht intuitive und ungewohnte Oberfläche Tabelle 4.13: Kriterienkatalog: Look & Feel Abbildung 4.14: Kriterienkatalog: Look & Feel (Quelle: Eigene Abbildung) Apps werden durch einen Touchscreen bedient und Oberfläche, sowie Bedienelemente unterscheiden sich von den herkömmliche Komponenten der Desktop-Anwendungen. Die native App-Entwicklung bietet eine große Palette an Komponenten, die sich bereits etabliert haben und für Nutzer eine gewisse Erwartungskonformität bieten. Je ähnlicher die verwendeten Komponenten den nativen Komponenten sind, desto besser ist die Bedienbarkeit und somit die Wertung. Jede native Plattform bietet Standard-UI-Komponenten, die für den Anwender leicht zu verstehen sind. Durch die Verbreitung dieser nativen Oberflächen ist das Verhalten der Komponenten bei Anwendern bereits bekannt, auch die Bedienung neuer Apps ist somit intuitiv und schnell erlernbar (+). Hybrid-Apps setzten je nach Framework auf die nativen Komponenten auf (Titanium Appcelerator, Rhodes), oder nutzen eigene UI-Komponenten, die sich meist an den nativen orientieren (Sencha Touch, jquery mobile) ( ). Titanium Appcelerator: Einsatz nativer UI-Komponenten (+) Rhodes: Native UI-Komponenten (+) Sencha Touch: Eigene UI-Komponenten ( )

72 56 KAPITEL 4. BEWERTUNG jquery Mobile: Eigene UI-Komponenten ( ) PhoneGap: Basierend auf Web-App, Nutzung nativer Komponenten möglich Wenn Web-Apps ohne den Einsatz von Frameworks realisiert werden, so müssen auch die mobilen UI-Komponenten selbst implementiert werden. Standard- Web-Elemente (Checkbox, Radiobuttons, etc.) eignen sich nur bedingt für die mobile Nutzung mit Touchscreens. Nutzt man hingegen ein Web-App-Framework wie Sencha Touch oder jquery mobile, so sind die wichtigsten UI-Elemente bereits vorgefertigt ( ). Da man im Regelfall auf ein Framework zurückgreifen wird, sind Web-Apps im Rahmen dieser Auswertung als quasi-nativ gewertet ( ). Abbildung 4.15: Native UI-Komponenten (iphone) (Quelle: Eigene Abbildung)

73 4.2. KRITERIEN Sicherheit Verschlüsselung + Vollständige Verschlüsselung der Daten und der Verbindung möglich Verschlüsselung der Verbindung oder der Daten möglich Keine Verschlüsselung möglich Tabelle 4.14: Kriterienkatalog: Verschlüsselung Abbildung 4.16: Kriterienkatalog: Verschlüsselung (Quelle: Eigene Abbildung) Der Sicherheitsfaktor spielt je nach App-Art eine unterschiedliche Rolle. Generell sollte es aber möglich sein Apps durch mehrere Verfahren abzusichern und sowohl Daten, als auch Verbindungen zu verschlüsseln. Native Apps lassen sich einfach verschlüsseln und auch die Datenübertragung kann über eine verschlüsselte Verbindung erfolgen (+). Hybrid-Apps bieten je nach Framework unterschiedliche Möglichkeiten der Verschlüsselung, eine verschlüsselte Datenübertragung oder die Datenverschlüsselung ist aber meist möglich ( ). Web-Apps bieten die Möglichkeit einer verschlüsselten Datenübertragung per SSL. Da Web-Apps direkt im Browser ausgeführt werden, ist der Quelltext jederzeit lesbar. Eine Verschlüsselung der lokalen Daten ist aber möglich (LocalStorage, WebSQL). Außerdem sind die lokalen Datenspeicher der HTMLverwandten Spezifikationen (LocalStorage, WebSQL) gegen den Zugriff von anderen Domains aus abgeschirmt, es ist also nicht möglich auf die Daten einer fremden Web-App zuzugreifen. Insgesamt fehlt es aber in diesem Bereich noch an verbindlichen Standards und Implementierungen, weshalb die Web- Apps nur eine mittlere Bewertung erhalten ( ).

74 58 KAPITEL 4. BEWERTUNG Remote-Wartung + Echtzeit-Monitoring der App, Remote-Deaktivierung möglich App-Monitoring möglich Keine Remote-Kontrolle über die Apps Tabelle 4.15: Kriterienkatalog: Remote-Wartung Abbildung 4.17: Kriterienkatalog: Remote-Wartung (Quelle: Eigene Abbildung) Um die Funktionstüchtigkeit und Sicherheit einer App zu garantieren, ist die Möglichkeit der Fernwartung für den Kriterienkatalog relevant. Im Fehlerfall sollte es möglich sein, diesen schnell zu analysieren und zu beheben. In kritischen Fällen ist auch die Deaktivierung aus der Ferne eine wichtige Option, die je nach Art der App von großer Bedeutung sein kann (z. B. Kritischer Fehler in einer Banking-App). Je besser die Möglichkeiten der Fernwartung für den Entwickler sind, desto besser ist die Bewertung. Native Apps lassen sich meist nur in kleinerem Umfang überwachen. So ist die Fehleranalyse und ein schnelles eingreifen oft nicht leicht realisierbar. Die Deaktivierung einer App ist ohne Verzögerung meist nicht möglich. ( ) Hybrid-Apps unterliegen den Bedingungen der jeweiligen Plattform und die Bewertung richtet sich somit nach der nativen Plattform ( ). Web-Apps lassen sich in Form von Webseiten sehr einfach überwachen und die Fehleranalyse ist in Echtzeit möglich. Die Deaktivierung einer App ist jederzeit möglich und tritt sofort in Kraft (+).

75 4.2. KRITERIEN Marketing Werbung + In-App-Ads werden unterstützt, Integrierte Lösungen verfügbar In-App-Ads werden unterstützt Keine Unterstützung für In-App-Ads Tabelle 4.16: Kriterienkatalog: Werbung Abbildung 4.18: Kriterienkatalog: Werbung (Quelle: Eigene Abbildung) Um eine App zu finanzieren gibt es die Möglichkeit innerhalb einer App Werbung zu schalten. Für viele App-Entwickler ist diese Art der Monetarisierung eine gute Alternative zu kostenpflichtigen Version, weshalb einer Betrachtung der Möglichkeiten im Rahmen der Bewertung von Interesse ist. Native und hybride Apps können Werbe-Elemente integrieren: Dabei gibt es je nach Plattform mehrere Anbieter (z. B. AdMob. AdSense). Apple (iads) und Google (Mobile Ads) haben inzwischen eigene Werbe-Plattformen entwickelt, die direkt in die App integriert werden können (+) (vgl. Apple [3], Google [19]). Web-Apps können auf die bestehenden Möglichkeiten des Web-Marketing zurückgreifen. Es gibt zahlreiche Anbieter, jedoch ist die Integration in die App aufwendiger als bei nativen Apps, da es je nach Framework und Layout umständlich sein kann Werbung einzubinden ( ).

76 60 KAPITEL 4. BEWERTUNG Distribution Möglichkeiten für Firmen + Auto. Deployment und Zusatzfunktionen Auto. Deployment Keine zusätzlichen Möglichkeiten für Firmen Zentraler App Marktplatz + Verbreitung über mehrere App-Marktplätze möglich Verbreitung über genau einen App-Marktplatz möglich Keine Verbreitung über App-Marktplätze möglich Unabhängige Verbreitung + Unabhängige Distribution (Datei, Link) Unabhängige Verteilung plattformgebunden möglich Keine unabhängige Verteilung möglich Tabelle 4.17: Kriterienkatalog: Distribution Möglichkeiten für Firmen Wenn man Apps für eine Firma entwickelt, ist es besonders wichtig, diese auch unkompliziert an alle Mitarbeiter ausliefern zu können. Zusätzliche Sicherheitsfeatures und Wartungsmöglichkeiten sind ein weiterer Pluspunkt, der besonders im Firmenumfeld eine höhere Bedeutung hat. Native App: + Hybrid-App: + Web-App: Zentraler App-Marktplatz Apps werden hauptsächlich über die Plattform-eigenen Marktplätze verbreitet (z. B. Apple: AppStore, Google: Android Market), weshalb erst der Zugang zu diesen Marktplätzen einen Zugang zum Massenmarkt ermöglicht. Manche native Plattform (ios) erlaubt auch nur einen einzigen kontrollierten Marktplatz, so dass der Zugang die einzige Möglichkeit ist, die App überhaupt anbieten zu können. Auch wenn die meisten nativen Plattformen mehrere Marktplätze zulassen, sind diese Alternativen meist nicht sehr verbreitet. Native App: Hybrid-App: + Web-App:

77 4.2. KRITERIEN 61 Abbildung 4.19: Kriterienkatalog: Distribution (Quelle: Eigene Abbildung) Unabhängige Verbreitung Eine unabhängige Verbreitung ist gegeben, wenn man die Möglichkeit hat, eine App in Form einer Datei zu verbreiten. Somit lässt sich diese über eine Webseite, mehrere Marktplätze oder beispielsweise auch per verteilen. Bei nativen, und damit auch bei hybriden Apps ist dies abhängig von der Plattform: ios: Nur über den AppStore ( ) Android: Beliebige Verteilung als Datei, verschiedene Marktplätze ( ) BlackBerry: Beliebige Verteilung, verschiedene Marktplätze ( ) Web-Apps können in Form einer Webseite (also per Link) direkt über das Web verbreitet werden, ohne dass es einer Installation bedarf. Sowohl Google, als auch Apple bieten eine Auflistung solcher Web-App Seiten an. Eine Verteilung in Form einer gepackten Datei ist momentan nicht standardisiert, jedoch bietet Googles Chrome Web-Store eine Möglichkeit Web-Apps als Datei anzubieten (momentan nur für Google Chrome) (+).

78 62 KAPITEL 4. BEWERTUNG Monetarisierung + Sichere Zahlungsabwicklung, Freie Preisgestaltung, Ad-Support Sichere Zahlungsabwicklung, Freie Preisgestaltung Vermarktung nur über eigene Systeme möglich (z. B. Abo, Ads) Tabelle 4.18: Kriterienkatalog: Monetarisierung Abbildung 4.20: Kriterienkatalog: Monetarisierung (Quelle: Eigene Abbildung) Um eine App kostenpflichtig anzubieten benötigt man eine sichere Zahlungsabwicklung und eine Lizenzverwaltung. Zentrale Marktplätze bieten diesen Service, wobei dafür ein fester Anteil des Verkaufspreises als Provision an den Marktplatz-Betreiber zu zahlen ist. Obwohl bei einer Abwicklung über eigene Systeme geringere Abgaben zu zahlen sind und die Freiheiten der Implementierung größer sind, so werden die meisten Apps bei großen Marktplätzen verkauft, weshalb eine separate Abwicklung für viele potentielle Kunden verwirrend sein könnte Deshalb gibt es eine negative Bewertung in diesem Falle. Native Apps werden hauptsächlich über einen zentralen Marktplatz vertrieben: Dort gibt es in der Regel eine sichere Zahlungsabwicklung und freie Preisgestaltung für die Entwickler. Je nach Marktplatz wird ein bestimmter Prozentsatz des App-Preises an den Marktplatz-Anbieter abgeführt (meist 70:30 Entwickler : Marktplatz-Anbieter) (+). Hybrid-Apps werden genau wie die nativen Apps vertrieben und es gelten dieselben Bedingungen (+). Web-Apps werden in Form einer Webseite vertrieben und zentrale Marktplätze sind noch die Ausnahmen (siehe Chrome Web Store). Die Zahlungsabwicklung ist somit selbst zu regeln und die Prüfung der Lizenzen muss selbst implementiert werden. Vorteilhaft ist jedoch dass es dabei keine Abgaben gibt, wie sie bei zentralen Marktplätzen die Regel sind.

79 4.2. KRITERIEN Einschränkungen + Keine Einschränkungen (Keine Prüfung) Einschränkungen vorhanden Einschränkungen vorhanden (Prüfung nötig) Tabelle 4.19: Kriterienkatalog: Einschränkungen Abbildung 4.21: Kriterienkatalog: Einschränkungen (Quelle: Eigene Abbildung) Ein großer Nachteil bei Apps, die hauptsächlich über zentrale Marktplätze vertrieben werden, ist die Bindung an einen Anbieter und die damit verbundenen Bestimmungen. So ist es bei manchen Marktplätzen nicht möglich eine App ohne vorherige Prüfung durch den Marktplatz-Betreiber zu veröffentlichen (Apple AppStore). Diese Bestimmungen bedeuten teilweise erhebliche Einschränkungen für den App-Entwickler und sind daher wichtig für die Bewertung. Je weniger Einschränkungen eine Plattform bietet, desto besser ist die Bewertung. Bei den zentralen Marktplätzen der nativen Plattformen gibt es Richtlinien die eine App erfüllen muss um aufgenommen zu werden. Apple setzt sogar ein Prüfverfahren ein, welches jede App durchlaufen muss, bevor diese im hauseigenen AppStore aufgenommen wird. Dieses Prüfverfahren muss auch nach jedem Update durchlaufen werden und verzögert Veröffentlichungen und Updates ( ). Hybrid-Apps sind abhängig von der nativen Plattform und es gelten dieselben Bestimmungen ( ). Web-Apps sind prinzipiell frei von solchen Richtlinien. Es gelten dieselben Bestimmungen wie für Webseiten - diese unterscheiden sich von Land zu Land. Wenn man eine Web-App auf einen Server lädt, ist diese sofort verfügbar. Auch Updates sind sofort wirksam und die lokalen Kopien in den Browsern der Anwender werden automatisch aktualisiert (+).

80 Kapitel 5 Implementierung Nach Analyse und Bewertung, soll nun anhand einer exemplarischen Implementierung die Reife der plattformübergreifenden App-Entwicklung untersucht werden. Als Grundlage dient hierbei die bestehende Web-Anwendung Roomieplanet, welche um eine mobile Version erweitert werden soll. Zielplattformen der App sind dabei ios, Android und BlackBerry. 5.1 Motivation Roomieplanet wird zunehmend mobil genutzt, zusätzlich steigt die Verbreitung von MIDs bei der Hauptzielgruppe der Studenten momentan sehr schnell. Obwohl die bisherige Roomieplanet-Version für den Desktop optimiert wurde, so ist diese auf den meisten mobilen Geräten ohne Probleme nutzbar. Allerdings ist die Bedienung und die Darstellung nicht optimal und eine mobile Version soll diese Defizite ausgleichen. Der Funktionsumfang ist dabei vorerst auf diejenigen Funktionen beschränkt, die besonders unterwegs von Bedeutung sind. Abbildung 5.1: Roomieplanet Modulübersicht 64

81 5.2. IST-ANALYSE Ist-Analyse Roomieplanet Abbildung 5.2: Roomieplanet - Logo Roomieplanet ist eine Web-Anwendung für Wohngemeinschaften, die an der Hochschule Augsburg im Rahmen einer Projektarbeit entstanden ist. Die bestehende Web-Anwendung bietet dabei Möglichkeiten zur Verwaltung von Finanzen, Terminen, Einkäufen und einen Putzplan. Roomieplanet ist unter erreichbar und nach einer Registrierung kostenlos nutzbar. Abbildung 5.3: Roomieplanet Desktop Momentan wird Roomieplanet von sechs Studenten weiterentwickelt. Neben der Verbesserungen bestehender Module, wird an weiteren Funktionen und neuen Modulen gearbeitet.

82 66 KAPITEL 5. IMPLEMENTIERUNG Verwendete Technik Die bestehende Web-Anwendung also die Desktop-Version von roomieplanet basiert auf HTML, CSS und JavaScript. Als Back-End dient PHP auf einem Apache-Webserver und eine MySQL Datenbank Vorhandene Schnittstellen Das Front-End setzt stark auf AJAX, weshalb eine HTTP/JSON-API serverseitig zur Verfügung gestellt wird. Diese API lässt sich mit einigen Anpassungen auch für die mobile Version nutzen. Die Authentisierung erfolgt dabei per PHP-Session. 5.3 Roomieplanet Mobile Anforderungsanalyse Abbildung 5.4: Roomieplanet mobile Use Case Diagramm (Quelle: Eigene Abbildung)

83 5.3. ROOMIEPLANET MOBILE 67 Die mobile Version von roomieplanet soll nicht den gesamten Funktionsumfang der Desktop-Version umfassen, sondern besonders diejenigen Funktionen bieten, die unterwegs besonders wichtig sind (siehe Abbildung 5.4): Nr. Bezeichnung Beschreibung Akteure 1 Anmeldung Der Benutzer kann sich mit Benutzer -Adresse und Passwort am roomieplanet-system anmelden 2 Einkäufe Der Benutzer kann Einkäufe auflisten, Benutzer verwalten hinzufügen und als eingekauft markieren 3 Finanzen Der Benutzer kann sich eine Übersicht Benutzer verwalten über die Finanzen auflisten lassen und Ausgaben/Überweisungen anlegen 4 Termine Der Benutzer kann sich die kommenden Benutzer auflisten 5 Neuigkeiten auflisten zehn Termine auflisten lassen Der Benutzer kann sich die letzten 15 Neuigkeiten auflisten lassen. Tabelle 5.1: Use-Case Anwendungsfälle Benutzer Neben den Use-Cases gibt es weitere technische Anforderungen, die bei der App-Entwicklung zu berücksichtigen sind: Die mobile App soll mindestens ios und Android als Zielplattformen unterstützen Die mobile App soll direkt über das Web erreichbar sein. Über eine serverseitige Browser-Weiche soll je nach Browser und Client die richtige Version geladen werden Die mobile App soll außerdem über die plattform-spezifischen Markplätze vertrieben werden Insgesamt soll es nur eine Codebase geben (Wartung!) Die mobile App soll durch eine erwartungskonforme UI einfach zu bedienen sein

84 68 KAPITEL 5. IMPLEMENTIERUNG Technologieauswahl App-Typ Bei der Technologieauswahl kam das in Kapitel 4 beschriebene Bewertungsverfahren noch nicht zum Einsatz, da dieses erst durch Erfahrungen während der Implementierung entstanden ist. Die Anforderungen an die App sind so klar definiert, dass die Art der Implementierung daraus resultiert: Einerseits soll die App direkt über das Web erreichbar sein, weshalb sich die Realisierung als Web-App anbietet. Andererseits soll es möglich sein diese auch über die plattform-spezifischen Marktplätze anzubieten, was zusätzlich für eine Hybrid- App spricht. Um der Forderung nach einer gemeinsamen Code-Base gerecht zu werden, muss die Hybrid-App auf dem Quelltext der Web-App basieren und diese in einem nativen Container bereitstellen Verwendete Frameworks Um die Entwicklung der Web-App zu vereinfachen und eine quasi-native Oberfläche zu schaffen, wird ein Web-Application-Framework eingesetzt: Mit zahlreichen vorgefertigten UI-Komponenten und vielen Hilfsfunktionen für die Datenbeschaffung bietet sich hierbei Sencha Touch als HTML5 Application Framework an. Im Gegensatz zu anderen UI-Frameworks wie jquery mobile, handelt es sich bei Sencha Touch um ein Framework, welches sich an der nativen App-Entwicklung anlehnt. Andere Frameworks setzen oft auf die deklarative Definition der UI und Logik innerhalb des HTML-Markups, was besonders für angepasste Versionen bestehender Web-Seiten von Vorteil ist. Will man aber eine eigenständige App programmieren, so ist es einfacher sämtliche UI-Komponenten und die Logik in Form von Objekten zu erstellen. Die Programmierung beschränkt sich somit größtenteils auf JavaScript und das HTML-Markup wird im Hintergrund durch Sencha Touch generiert. Anpassungen an HTML und CSS sind dabei aber weiterhin möglich, jedoch nicht zwingend nötig. Um die App auch für die Marktplätze der nativen Plattformen verfügbar zu machen, wird die Web-App mithilfe von PhoneGap zu einer nativen App für jede unterstützte Plattform. Dabei bietet PhoneGap einen Web-View-Container, in welchen die Web-App abgelegt wird. Zusätzlich bietet PhoneGap weitere Schnittstellen der nativen Plattformen, die Web-Apps normal nicht nutzen können. Der größte Vorteil dieses Ansatzes ist der hohe Grad der Wiederverwendbarkeit der Quelltexts. Eine bestehende Web-App kann ohne Änderungen in Form eines PhoneGap Projekts zu einer nativen App kompiliert werden. Zusätzlich kann man durch Vererbung auch Zusatzfunktionen innerhalb der PhoneGap-App realisieren, ohne die bestehende Code-Base direkt zu verändern.

85 5.3. ROOMIEPLANET MOBILE Serverseitige API Um die zusätzliche serverseitige Implementierung möglichst gering zu halten, wird die bestehende AJAX-API genutzt und um zusätzliche Funktionen ergänzt und angepasst. Die Datenbeschaffung der mobilen App wird mit AJAX realisiert, wobei sämtliche Anfragen an eine bestimmte URL gesendet werden ( Per GET-Parameter kann man der API die gewünschte Funktion übermitteln, die dann ausgeführt wird und einen JSON-String als Antwort zurück liefert UI-Konzept Das Grundlayout der App gliedert sich in drei Bereich: Header: Titel des aktuellen Views und ggf. ein Button für Aktionen Body: Der eigentliche Inhalt des Views - identifiziert durch eine eindeutige ID Footer: Die Navigation in Form eines TabPanels, also einer Leiste mit Icons für jede View Abbildung 5.5: Roomieplanet UI-Konzept (Quelle: Eigene Abbildung) Die TabBar zeigt durch eine farbliche Markierung an, welche View momentan aktiv ist. Außerdem sind dort Benachrichtigungen hinterlegt, wie beispielsweise die Anzahl der offenen Einkäufe der Einkaufsliste. Sencha Touch übernimmt

86 70 KAPITEL 5. IMPLEMENTIERUNG das Rendering der Komponenten und steuert die Navigation. Der Inhalt wird dynamisch in die jeweiligen Views geladen, welche durch eindeutige IDs angesprochen werden können. Die Ausrichtung und Größe der Elemente passt sich automatisch an den zur Verfügung stehenden Platz an, wodurch die App sowohl in der Horizontalen, als auch in der Vertikalen genutzt werden kann. Abbildung 5.6: Roomieplanet mobile UI (Quelle: Eigene Abbildung) Abbildung 5.7: Roomieplanet mobile (Querformat) (Quelle: Eigene Abbildung)

87 5.4. IMPLEMENTIERUNG - WEB-APP Implementierung - Web-App Struktur - Sencha Touch Sencha Touch besteht aus einer Sammlung von CSS-Stylesheets, darin verlinkten Bildern und der eigentlichen JavaScript Bibliothek. Die Web-App ist in einer einzigen HTML-Datei definiert, in welche die JavaScript Bibliothek und die Stylesheets eingebunden sind. Wenn man sich auf die Standard-Komponenten beschränkt, ist es nicht nötig die CSS Dateien anzupassen Die Anwendungsentwicklung erfolgt damit komplett auf JavaScript-Basis. Grundstruktur - Sencha Touch HTML-Datei: index.html Stylesheet: sencha_touch.css JavaScript-Bibliothek: sencha_touch.js Nachdem die Grundstruktur vorhanden ist, kann die eigentliche Anwendungsentwicklung beginnen - Sencha macht keinerlei Vorgaben für die Aufteilung des Codes, es bleibt dem Entwickler überlassen wie die Anwendung aufgebaut wird. Aus Gründen der Wartbarkeit und Übersicht wird bei der folgenden Implementierung versucht Datenbeschaffung, Darstellung und Ablauflogik möglichst getrennt zu halten. Die bestehende HTML-Datei (index.html) wird um weiteren JavaScript- Code ergänzt, welcher aus Gründen der Übersichtlichkeit in mehrere Dateien untergliedert ist: index.js: Initialisierung (Sencha-Touch Instanzierung) roomieplanet.js: Roomieplanet-Klasse (Methoden zur Datenbeschaffung und Steuerung) templates.js: HTML-Grundgerüste für die Views (Templates mit Platzhaltern) forms.js: Alle Formulare und dazugehörige Callback-Funktionen helpers.js: Hilfsfunktionen und Debugging-Funktionen shoppinglist.js: Die Shoppinglist-Klasse (Methoden der Einkaufsliste) Das Modul Einkaufen ist in eine eigene Klasse auslagert (shoppinglist.js), da dieses Modul sehr ausführlich implementiert ist und auf eine lokale SQL- Datenbank zugreift. Die übrigen Module (Bezahlen, Termine, Neues) sind alle innerhalb der Roomieplanet-Klasse realisiert (vgl. Abbildung 5.8).

88 72 KAPITEL 5. IMPLEMENTIERUNG Abbildung 5.8: Roomieplanet-Mobile Komponentendiagramm (Quelle: Eigene Abbildung)

89 5.4. IMPLEMENTIERUNG - WEB-APP Initialisierung und Ablauf In der index.js-datei wird durch ein Konfigurationsobjekt eine Instanz von Sencha Touch erzeugt (Algorithmus 5.1 Zeile 2). Sobald das Framework fertig initialisiert ist, wird ein Event ( onready ) getriggert (Zeile 7), woraufhin das Grundlayout generiert wird. Dieses Grundgerüst bestehend auf vier Views (Tabs: Neues, Bezahlen, Einkaufen, Termine) und der Navigation (Zeile 10-37) ist zunächst noch ohne Inhalte. Nachdem die Oberfläche komplett geladen wurde, werden die Tabs im nächsten Schritt mit Inhalten gefüllt. Um die Datenbeschaffung kümmert sich die Roomeplanet-Klasse, die in Zeile 44 instanziert wird: Dort wird zunächst geprüft ob der Anwender bereits angemeldet ist und eine gültige Session gestartet wurde. Sollte diese nicht bestehen, wird das Anmeldeformular eingeblendet. Wenn der Anwender erfolgreich angemeldet ist, erfolgt die Datenbeschaffung in Form mehrerer paralleler AJAX-Requests an den Server, die Inhalte für die jeweiligen Tabs im JSON- Form zurück liefern. Mit diesen Daten werden dann komplette HTML-Gerüste generiert, die per Sencha-Touch in die jeweiligen Tabs eingefügt werden (vgl. Abbildung 5.9, 5.10). Dabei hat jedes Tab eine eindeutige ID, um Inhalte eindeutig zuordnen zu können. Abbildung 5.9: Roomieplanet mobile Initialisierung (Quelle: Eigene Abbildung)

90 74 KAPITEL 5. IMPLEMENTIERUNG Algorithmus 5.1 Sencha Touch Initialisierung 1 // SENCHA SETUP 2 Ext. setup ({ 3 icon : resources/icon.png, 4 phonestartupscreen : resources/img/phone_startup.png, 5 glossonicon : false, 6 f u l l s c r e e n : true, 7 onready : function ( ) { 8 // MAIN LAYOUT 9 // Bottom Tabs ( Navigation) 10 var tabpanel = new Ext. TabPanel ({ 11 tabbar : { 12 id : maintabpanel, 13 dock : bottom, 14 layout : { 15 pack : center 16 } 17 }, 18 f u l l s c r e e n : true, 19 layout : fit, 20 ui : light, 21 cardswitchanimation : tabanims, 22 d e f a u l t s : { 23 s c r o l l : vertical 24 }, 25 items : [ 26 { 27 id : feed, 28 html : d e f a u l t InitHtml, 29 i c o n C l s : feed, 30 c l s : tabcard, 31 dockeditems : [ { } ] 34 }, ] 37 }) ; // roomieplanet - class 40 roomie. i n i t ( ) ; 41 } 42 }) ;

91 5.4. IMPLEMENTIERUNG - WEB-APP 75 Abbildung 5.10: Roomieplanet mobile Datenbeschaffung (Quelle: Eigene Abbildung)

92 76 KAPITEL 5. IMPLEMENTIERUNG Datenbeschaffung und Offline-Caching Im ersten Schritt wird geprüft ob der Browser eine Verbindung zum Internet hat: Dazu wird das Attribut navigator.isonline genutzt, welches den aktuellen Verbindungsstatus des Browsers dokumentiert. Sollte des Browser offline sein, so werden die Daten für die entsprechende View direkt über LocalStorage (Offline-Speicher) geladen und dem Template- Renderer übergeben (vgl. Algorithmus 5.2 Zeile 3-7). Wenn der Browser online ist, so wird ein AJAX-Request ausgeführt um die aktuellen Daten vom Server zu laden (Zeile 11). Ist der Request erfolgreich, so werden die aktuellen Daten in den Offline-Cache geschrieben (LocalStorage) und anschließend an den Template-Helper übergeben (Zeile 18, 21). Sollte der Request fehlschlagen, so wird eine Fehlermeldung in der entsprechenden View angezeigt. Die TemplateHelper-Funktion (Aufruf in Zeile 7, 21) spielt dabei eine wichtige Rolle: Diese Funktion nimmt strukturierte Daten im JSON-Format und generiert dann auf Basis eines Templates (vgl. 5.3) fertiges HTML. Dieser HTML-Ausschnitt wird dann in das passende DIV-Element eingefügt. (vgl. Abbildung 5.11) Algorithmus 5.2 Roomieplanet Datenbeschaffung 1 //#### FEED ####// 2 this. getfeed = function ( delay ) { 3 i f (! this. i s O n l i n e ( ) ) { 4 // load offline data 5 var data = this. g e t O f f l i n e D a t a ( feed ) ; 6 // load template 7 s e l f. templatehelper ( data,... ) ; 8 } 9 else { 10 // live data 11 Ext. Ajax. r e q u e s t ({ s u c c e s s : function ( response, opts ) { 14 // decode to jsonobject 15 data=ext. decode (... ) ; 16 // store data offline 17 i f ( data ) { 18 s e l f. s e t O f f l i n e D a t a ( feed, data ) ; 19 } 20 // apply data to the theme 21 s e l f. templatehelper ( data,... ) ; 22 } 23 }) ; 24 }

93 5.4. IMPLEMENTIERUNG - WEB-APP 77 Algorithmus 5.3 Sencha Touch Template 1 var feedtpl = new Ext. XTemplate ([ 2 <ul id =" feed_list " class =" boxed ">, 3 { value }, 4 </ul > 5 ]); Abbildung 5.11: Datenbeschaffung Web-App (Quelle: Eigene Abbildung)

94 78 KAPITEL 5. IMPLEMENTIERUNG HTML5 Funktionen Nachdem der grundlegende Ablauf der App beschrieben wurde, werden in diesem Abschnitt die HTML5-spezifischen Funktionen ausführlicher beschrieben Offline Web Applications Um eine Web-App offline nutzbar zu machen, muss die Anwendung selbst lokal abgelegt werden. Diese Funktionalität, betitelt als Offline Web Applications ist Teil des HTML5-Standards und besteht aus mehreren Events, Application- Caches und einem sogenannten MANIFEST FILE (vgl. WHATWG [63]). Im ersten Schritt definiert man sämtliche Dateien, die man für die Ausführung der App braucht, in einer Textdatei namens MANIFEST. Diese Datei besteht aus drei Kategorien, in welche man Datei-Referenzen einteilen kann: CACHE: Dateien die gecached werden sollen FALLBACK: Fallbacks für Dateien, die nicht geladen werden können NETWORK: Dateien die nicht gecached werde sollen (z.b. Der AJAX- Endpunkt: mobile.php) Um den Aufwand gering zu halten lässt sich die Erstellung der MANIFEST- Datei automatisieren: Ein PHP Directory-Iterator listet sämtliche Dateien im Verzeichnis der Web-App auf und generiert die Liste, der zu cachenden Dateien. Der NETWORK-Bereich ist innerhalb des Scripts fest vorgegeben und beinhaltet lediglich den serverseitigen AJAX-Handler (mobile.php). Damit die MANIFEST-Datei nach Änderungen vom Browser neu geladen wird, befindet sich am Ende der Datei noch ein Kommentar mit der Prüfsumme (MD5) aller zu cachender Dateien. Im nächsten Schritt muss die index.html eine Referenz auf die MANIFEST- Datei erhalten: Algorithmus 5.4 HTML5 - Manifest 1 <html manifest =" manifest. php "> Ruft man nun die Web-App im Browser auf, so werden im Hintergrund alle benötigten Dateien heruntergeladen und in einem Application Cache abgelegt. Nun kann man die Web-App per URL auch aufrufen, wenn keine Verbindung zum Internet besteht. Um eine bessere Übersicht zu bekommen was im Hintergrund passiert und das Debugging zu verbessern, lassen sich die verschiedenen Events und Konstanten der Offline Web Applications nutzen: Über window.applicationcache

95 5.4. IMPLEMENTIERUNG - WEB-APP 79 hat man Zugriff auf das ApplicationCache Objekt, an das mehrere Events gekoppelt werden, die wiederum Infos in die Browser-Console schreiben. (vgl. Abbildung 5.12) Abbildung 5.12: Application-Cache Debugging (Quelle: Eigene Abbildung) Abbildung 5.6 zeigt die Ausgabe des ApplicationCache - Debuggers: 1. Zeile: Prüfen ob es Änderungen am Manifest gab 2. Zeile: Änderungen gefunden Download starten 3. Zeile: Dateien herunterladen (61 Dateien werden lokal abgespeichert) 4. Zeile: Update bereit Download vollständig 5. Zeile: Swap-Cache-Event wurde ausgelöst Ein Neuladen der Seite zeigt die neue Version Persistenter Speicher LocalStorage LocalStorage ist ein einfacher Key-Value-Speicher, der persistent im Browser abgelegt wird. Dabei stehen Methoden zur Verfügung die das persistente Speichern von String ermöglichen: setitem(), getitem(),removeitem(),clear(). Die Roomieplanet-Datenbeschaffung liefert strukturierte Datenobjekte im JSON-Format zurück, jedoch lassen sich über die LocalStorage-Spezifikation lediglich Strings ablegen. Um diese Einschränkung zu umgehen und das Speichern von JSON-Objekten zu ermöglichen, werden zwei Hilfsfunktionen implementiert: setobject(in DOMString key, in Object): Legt beliebige JavaScript-Objekte lokal ab (identifiziert durch einen eindeutigen String)

96 80 KAPITEL 5. IMPLEMENTIERUNG getobject(in DOMString key): Liest JavaScript-Objekte lokal aus (identifiziert durch einen eindeutigen String) Algorithmus 5.5 HTML5 Storage Erweiterung 1 // HTML5 Storage prototype extensions 2 Storage. prototype. s e t O b j e c t = function ( key, value ) { 3 this. setitem ( key, JSON. s t r i n g i f y ( value ) ) ; 4 } 5 6 Storage. prototype. getobject = function ( key ) { 7 return JSON. parse ( this. getitem ( key ) ) ; 8 } Diese Funktionen werden durch Vererbung bzw. den JavaScript Prototype- Mechanismus an das LocalStorage Objekt angehängt: Dabei wird bei setobject und getobject jeweils serialisiert bzw. deserialisiert. Um eine grundlegende Offline-Funktionalität zur Verfügung zu stellen, werden sämtliche JSON-Objekte die vom Server geladen werden direkt im lokalen Speicher abgelegt. Alle Views lassen sich damit auch darstellen, falls keine Verbindung zum Server besteht: Normalerweise werden sämtliche Views direkt mit den Daten vom Server generiert. Falls keine Verbindung besteht werden die lokal abgelegten Daten verwendet. (vgl. Abbildung 5.11) Lokale Datenbank Web-SQL Die Web-Database-Spezifikation ist im Moment an einem Wendepunkt, wie folgendes Zitat verdeutlicht: This document was on the W3C Recommendation track but specification work has stopped. The specification reached an impasse: all interested implementors have used the same SQL backend (Sqlite), but we need multiple independent implementations to proceed along a standardisation path. W3C [61] Allerdings ist die Web-SQL Datenbank auf SQlite Basis immer noch stark verbreitet auf mobilen Geräten und ios, als auch Android unterstützen diese im Moment noch. Als erster Browser hat Mozillas Firefox mit der Indexed DB die neue Spezifikation des W3C umgesetzt (vgl. W3C [58]). Im Rahmen dieser Arbeit wurde die Web-SQL-Spezifikation genutzt, da diese momentan noch weit verbreitet ist und die Zukunft der Spezifikation zum Zeitpunkt der Arbeit nicht klar war. Aus diesem Grund wird dieses Kapitel nicht vertieft, sondern lediglich die grundsätzliche Implementierung beschrieben.

97 5.4. IMPLEMENTIERUNG - WEB-APP 81 Die bisherige Implementierung der Module bietet lediglich eingeschränkte Offline-Funktionalität, da es nur möglich ist den Stand der letzten Synchronisierung zu betrachten. Im Offline-Modus werden alle Funktionalitäten deaktiviert, die eine Synchronisierung erfordern würden (z.b. Ausgaben anlegen). Die Einkaufsliste soll als einziges Modul sowohl online, als auch offline dieselbe Funktionalität bieten: Einkäufe auflisten, Einkauf hinzufügen, Einkauf als erledigt markieren. Dazu wird eine lokale relationale Datenbank genutzt, die sämtliche Daten hält und mit der Datenbank auf dem Server synchronisiert wird. (siehe Quelltext 5.6, Abbildung 5.13) Algorithmus 5.6 HTML5 WebSQL Verbindungsaufbau 1 // database 2 c o n f i g var db ; 3 var shortname = shoppinglist ; 4 var v e r s i o n = 1.0 ; 5 var displayname = roomieplanet - shoppinglist ; 6 var maxsize = 65536; 7 db = opendatabase ( shortname, version, displayname, maxsize ) ; Die Einkaufsliste ist über eine eigene Klasse realisiert, die den Datenbankzugriff übernimmt und alle wichtigen Funktionen bietet. Die integrierten Entwickler-Tools der WebKit-Browser zeigen den aktuellen Datenbankinhalt (vgl. Abbildung 5.13). Abbildung 5.13: WebSQL - Entwickler-Tools (Quelle: Eigene Abbildung) Geolocation Um Ausgaben oder Einträge auf der Pinnwand mit einer Ortsangabe zu versehen, kommt die Geolocation-Spezifikation zum Einsatz: Über navigator.geolocation kann man die Koordinaten des Gerätes abrufen (vgl. Algorithmus 5.7). Der Benutzer bekommt dann über den Browser eine Meldung, ob er der Webseite erlauben möchte den Standort zu bestimmten. Wenn dieser zustimmt, so werden die Koordinaten über den eingebauten GPS-Empfängern sofern vorhanden bestimmt und über eine JavaScript- Funktion asynchron zurückgeliefert. Um aus den Koordinaten eine Adresse zu

98 82 KAPITEL 5. IMPLEMENTIERUNG bestimmen, nutzt Roomieplanet mobile zusätzlich die Reverse Geocoding API von Google. Algorithmus 5.7 HTML5 Geolocation 1 // check if geolocation is available 2 i f ( n a v i g a t o r. g e o l o c a t i o n ) { 3 // pcb = positivecallback ( if geolocation works) 4 // ncb = negative Callback ( in case of error) 5 n a v i g a t o r. g e o l o c a t i o n. g e t C u r r e n t P o s i t i o n (pcb,ncb) ; 6 } 5.5 Implementierung - Hybrid-App Motivation Die Implementierung von Roomieplanet in Form einer Web-App bietet schon sehr viele Möglichkeiten für mobile Anwender, jedoch ist es nicht möglich Web- Apps direkt zu installieren: Web-Apps sind offline-fähig und diese können über eine URL auch dann gestartet werden, wenn keine Verbindung zum Internet besteht. Eine aktive Installation ist dabei meinst nur in Form eines Lesezeichens mit Icon möglich. Native Plattformen wie ios oder Android bieten zentrale App-Marktplätze, über welche die Apps hauptsächlich bezogen werden. Es ist also wichtig Apps auch über diese Kanäle anzubieten um möglichst viele Anwender zu erreichen. Zusätzlich gibt es einzelne Funktionen die man noch in die bestehende Web-App integrieren könnte, um diese noch besser auf die nativen Plattformen anzupassen (z. B. Kamera-Zugriff, Native Benachrichtigungen). All diese Punkte lassen sich über die Integration eines Hybrid- Frameworks lösen PhoneGap PhoneGap ist ein Open-Source-Framework, welches federführend vom kanadischen Softwarehaus Nitobi entwickelt wird. Um Web-Apps auf native Plattformen zu bringen bietet PhoneGap vorgefertigte Projekte für die plattformspezifischen SDKs. Diese Projekte bestehen auf dem Gerüst einer nativen App, welche nur aus einem einzigen UI-Element dem sogenannten WebView besteht: Ein Web-View-Element ist ein eingebettetes Browserfenster innerhalb einer nativen App, in welches die Web-App geladen wird. Neben dieser Möglichkeit, Web-Apps in Form einer nativen App zu verpacken, bietet PhoneGap noch einen weiteren Mehrwert: Viele native Schnittstellen werden von Phone- Gap mithilfe einer JavaScript-Schnittstelle repliziert, um diese auch direkt für

99 5.5. IMPLEMENTIERUNG - HYBRID-APP 83 Abbildung 5.14: PhoneGap Logo Web-Apps zur Verfügung zu stellen. Es ist somit beispielsweise möglich per JavaScript die Kamera der Geräte anzusteuern (vgl.phonegap [45]) Web-App Integration Um eine Web-App in eine native App zu konvertieren, muss man zuerst die nativen SDKs installieren und konfigurieren. PhoneGap unterstützt zum Zeitpunkt der Arbeit die folgenden Plattformen: ios, Android, Palm WebOS, Symbian OS und BlackBerry OS. Die Implementierung von Roomieplanet mobile beschränkt sich vorerst auf Android und ios. Nachdem man die Projekte in Xcode für ios, bzw. Eclipse ADT für Android importiert hat, muss der Quelltext der Web-App eingebunden werden: Dazu muss man die Web-App mit sämtlichen Dateien in die folgenden Verzeichnisse kopieren: ios: /www Android: /assets/www/ Bei der Hybrid-App wird die index.html automatisch von PhoneGap aufgerufen, wenn die App gestartet wird. Im nächsten Schritt muss die PhoneGap Bibliothek eingebunden werden um auf PhoneGap-spezifische Funktionen zugreifen zu können. Dazu fügt man die Datei phonegap.js ein, die bereits im WWW-Verzeichnis liegt: Algorithmus 5.8 PhoneGap Einbinden der Bibliothek 1 <script type="text/javascript" src="phonegap.js"></ script> Die Web-App wartet bei Initialisierung von Sencha Touch auf das DOM- Ready Event, allerdings muss bei der Hybrid-App auf ein anderes Event namens ondeviceready gewartet werden, weshalb man in den index.html eine weitere kleine Ergänzung machen muss (vgl. Algorithmus 5.9).