cross-mobile-apps.de · zu gewährleisten. Mobile Webbrowser bieten mit HTML5 und CSS3 zahlrei-che...

BachelorarbeitStudienrichtung Wirtschaftsinformatik

Michael Jaser

Evaluation, Bewertung und Implementierung

verschiedener Cross-Platform Development

Ansätze für Mobile Internet Devices auf Basis

von Web-Technologien

Erstprüfer: Prof. Dr.-Ing. Schöler

Zweitprüfer: Prof. Dr. Rohrmair

Abgabe der Arbeit: 21.03.11

Hochschule Augsburg

University of Applied Sciences

Baumgartnerstraße 16

D 86161 Augsburg

Telefon +49 821 5586-0

Fax +49 821 5586-3222

http://www.hs-augsburg.de

[email protected]

Verfasser der Bachelorarbeit:

Michael-Jaser

Carl-von-Ossietzky-Str.11

82380 Peißenberg

Telefon: 08803 1012

[email protected]

Fakultät für Informatik

Telefon: +49 821 5586-3450

Fax: +49 821 5586-3499

ErklärungHiermit 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

Hochschule AugsburgFakultät für Informatik

Bachelorarbeit Wirtschaftsinformatik

Evaluation, Bewertung und Implementierungverschiedener Cross-Platform Development

Ansätze für Mobile Internet Devices auf Basisvon Web-Technologien

Michael Jaser

11.03.2011

Erstprüfer

Prof. Dr.-Ing. SchölerFakultät für InformatikHochschule Augsburg

Zweitprüfer

Prof. Dr. RohrmairFakultät für InformatikHochschule Augsburg

Firmen-Betreuer

Oliver KrügerChristian KirschIBM Deutschland

Michael Jaser:Evaluation, Bewertung und Implementierung verschiedenerCross-Platform Development Ansätze für Mobile InternetDevices auf Basis von Web-Technologien

Bachelorarbeit WirtschaftsinformatikHochschule Augsburg

Bearbeitungszeitraum: 18. November 2010 - 21. März 2011

Kurzfassung

Mobile Anwendungen (Apps) gewinnen jeden Tag mehr an Bedeutung: Lautdem Marktforschungsunternehmen Gartner Inc. wird sich die Anzahl der App-Downloads von 4 Milliarden heutzutage, auf ca. 21,6 Milliarden im Jahr 2013vervierfachen (vgl. Gartner [14]). Im Gegensatz zu den drei wichtigen Plattfor-men (Windows, Linux, Mac OS X) der herkömmlichen Anwendungsentwick-lung, gibt es bei mobilen Geräten deutlich mehr Betriebssysteme. Neben iOS(iPhone, iPad) und Android gibt es fünf weitere Plattformen die auf mobilenGeräten zum Einsatz kommen. Durch diese Fragmentierung der mobilen Platt-formen ist die plattformübergreifende App-Entwicklung ein viel versprechen-der Ansatz um die Entwicklungskosten gering zu halten und die Wartbarkeitzu gewährleisten. Mobile Webbrowser bieten mit HTML5 und CSS3 zahlrei-che neue Möglichkeiten für Entwickler: Mit so genannte “Web-Apps” lassensich standard-konforme Anwendungen entwickeln, die den Großteil der mobi-len Plattformen erreichen. Um diese Web-Apps zu nativen Apps zu konver-tieren und weitere Funktionalität bereitzustellen, gibt es so genannte Hybrid-Frameworks, die ebenfalls auf Web-Technologien basieren. Diese Arbeit be-schäftigt ich mit den verschiedenen Möglichkeiten der App-Entwicklung aufBasis von Web-Technologien.

Abstract

Mobile applications are becoming more important every day: According toGartner [14], app downloads will quadruple from around 4 billion today, toabout 22 billion downloads in 2013. In contrast to the PC with its three do-minant platforms, the mobile ecosystem is even more fragmented. Besides An-droid and iOS there are five other major platforms. Therefore cross-platformmobile application development is becoming more and more important to re-duce development costs and keeping apps maintainable. Mobile web apps offera great way to build standards-based apps running on most modern mobileplatforms. To leverage features of the platform and to extend those web apps,hybrid frameworks can be used to create native apps with more capabilitiesthan web apps, but still using web standard technologies to implement theseapps.

I

Inhaltsverzeichnis

Abbildungsverzeichnis VII

Tabellenverzeichnis IX

Abkürzungsverzeichnis XI

1 Mobile Internet Devices 31.1 Begriffsklärung . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 Geräte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2.1 Smartphones . . . . . . . . . . . . . . . . . . . . . . . . 51.2.2 Tablets . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.3 Plattformen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.3.1 Apple - iOS . . . . . . . . . . . . . . . . . . . . . . . . . 71.3.2 Open Handset Alliance – Android . . . . . . . . . . . . . 71.3.3 RIM – BlackBerry . . . . . . . . . . . . . . . . . . . . . 81.3.4 Symbian Foundation – Symbian . . . . . . . . . . . . . . 81.3.5 Microsoft – Windows Mobile/Windows Phone 7 . . . . . 91.3.6 HP Palm - webOS . . . . . . . . . . . . . . . . . . . . . 10

1.4 Markt und Absatz . . . . . . . . . . . . . . . . . . . . . . . . . 111.4.1 Smartphones . . . . . . . . . . . . . . . . . . . . . . . . 111.4.2 Tablets . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.5 Plattformverbreitung . . . . . . . . . . . . . . . . . . . . . . . . 13

2 Apps - mobile Applikationen 152.1 Begriffserklärung und Markt . . . . . . . . . . . . . . . . . . . . 152.2 Entwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.3 App-Typen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.3.1 Native Apps . . . . . . . . . . . . . . . . . . . . . . . . . 182.3.2 Web Apps . . . . . . . . . . . . . . . . . . . . . . . . . . 192.3.3 Hybrid Apps . . . . . . . . . . . . . . . . . . . . . . . . 21

III

3 Cross-Plattform App-Entwicklung 233.1 Mobile Web-Entwicklung – Web-Apps . . . . . . . . . . . . . . . 23

3.1.1 HTML5 . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.1.1.1 Herkunft und Definition . . . . . . . . . . . . . 233.1.1.2 Technologie und Verbreitung . . . . . . . . . . 26

3.1.2 JavaScript und DOM . . . . . . . . . . . . . . . . . . . . 323.1.2.1 JavaScript . . . . . . . . . . . . . . . . . . . . . 323.1.2.2 JSON . . . . . . . . . . . . . . . . . . . . . . . 333.1.2.3 DOM (Document Object Model) . . . . . . . . 34

3.1.3 CSS3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.2 Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.2.1 Web-Application-Frameworks . . . . . . . . . . . . . . . 363.2.1.1 Sencha Touch . . . . . . . . . . . . . . . . . . 363.2.1.2 jQuery Mobile . . . . . . . . . . . . . . . . . . 36

3.2.2 Cross-Compiler-Frameworks . . . . . . . . . . . . . . . . 373.2.2.1 Appcelerator Titanium Mobile . . . . . . . . . 373.2.2.2 Rhodes . . . . . . . . . . . . . . . . . . . . . . 37

3.2.3 Wrapper-Frameworks . . . . . . . . . . . . . . . . . . . . 383.2.3.1 PhoneGap . . . . . . . . . . . . . . . . . . . . . 38

4 Bewertung 394.1 Kriterienkatalog . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.2 Kriterien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.2.1 Technisch . . . . . . . . . . . . . . . . . . . . . . . . . . 414.2.1.1 Unterstützte Plattformen . . . . . . . . . . . . 414.2.1.2 Plattform-Ressourcen . . . . . . . . . . . . . . 434.2.1.3 Performance . . . . . . . . . . . . . . . . . . . . 444.2.1.4 Offline-Ressourcen . . . . . . . . . . . . . . . . 464.2.1.5 Multimedia . . . . . . . . . . . . . . . . . . . . 484.2.1.6 Benachrichtigungen . . . . . . . . . . . . . . . . 494.2.1.7 Lizenzierung . . . . . . . . . . . . . . . . . . . 50

4.2.2 Entwicklung . . . . . . . . . . . . . . . . . . . . . . . . . 514.2.2.1 Community . . . . . . . . . . . . . . . . . . . . 514.2.2.2 Tools . . . . . . . . . . . . . . . . . . . . . . . 524.2.2.3 Wiederverwendbarkeit . . . . . . . . . . . . . . 534.2.2.4 Dokumentation . . . . . . . . . . . . . . . . . . 54

4.2.3 Usability . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

IV

4.2.3.1 Look & Feel . . . . . . . . . . . . . . . . . . . . 554.2.4 Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.2.4.1 Verschlüsselung . . . . . . . . . . . . . . . . . . 574.2.4.2 Remote-Wartung . . . . . . . . . . . . . . . . . 58

4.2.5 Marketing . . . . . . . . . . . . . . . . . . . . . . . . . . 594.2.5.1 Werbung . . . . . . . . . . . . . . . . . . . . . 594.2.5.2 Distribution . . . . . . . . . . . . . . . . . . . . 604.2.5.3 Monetarisierung . . . . . . . . . . . . . . . . . 624.2.5.4 Einschränkungen . . . . . . . . . . . . . . . . . 63

5 Implementierung 645.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645.2 Ist-Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.2.1 Roomieplanet . . . . . . . . . . . . . . . . . . . . . . . . 655.2.2 Verwendete Technik . . . . . . . . . . . . . . . . . . . . 665.2.3 Vorhandene Schnittstellen . . . . . . . . . . . . . . . . . 66

5.3 Roomieplanet Mobile . . . . . . . . . . . . . . . . . . . . . . . . 665.3.1 Anforderungsanalyse . . . . . . . . . . . . . . . . . . . . 665.3.2 Technologieauswahl . . . . . . . . . . . . . . . . . . . . 68

5.3.2.1 App-Typ . . . . . . . . . . . . . . . . . . . . . 685.3.2.2 Verwendete Frameworks . . . . . . . . . . . . . 685.3.2.3 Serverseitige API . . . . . . . . . . . . . . . . . 69

5.3.3 UI-Konzept . . . . . . . . . . . . . . . . . . . . . . . . . 695.4 Implementierung - Web-App . . . . . . . . . . . . . . . . . . . . 71

5.4.1 Struktur - Sencha Touch . . . . . . . . . . . . . . . . . . 715.4.2 Initialisierung und Ablauf . . . . . . . . . . . . . . . . . 735.4.3 Datenbeschaffung und Offline-Caching . . . . . . . . . . 765.4.4 HTML5 Funktionen . . . . . . . . . . . . . . . . . . . . 78

5.4.4.1 Offline Web Applications . . . . . . . . . . . . . 785.4.4.2 Persistenter Speicher – LocalStorage . . . . . . 795.4.4.3 Lokale Datenbank – Web-SQL . . . . . . . . . . 805.4.4.4 Geolocation . . . . . . . . . . . . . . . . . . . . 81

5.5 Implementierung - Hybrid-App . . . . . . . . . . . . . . . . . . 825.5.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 825.5.2 PhoneGap . . . . . . . . . . . . . . . . . . . . . . . . . 825.5.3 Web-App Integration . . . . . . . . . . . . . . . . . . . . 835.5.4 Zusatzfunktionen . . . . . . . . . . . . . . . . . . . . . . 84

V

5.6 Erfahrungsbericht . . . . . . . . . . . . . . . . . . . . . . . . . 865.6.1 Testgeräte und Plattformen . . . . . . . . . . . . . . . . 865.6.2 Reifegrad der Frameworks . . . . . . . . . . . . . . . . . 86

5.6.2.1 Sencha Touch . . . . . . . . . . . . . . . . . . . 865.6.2.2 PhoneGap . . . . . . . . . . . . . . . . . . . . . 87

Literaturverzeichnis C

VI

Abbildungsverzeichnis

1.1 Smartphone – Apple iPhone 4 . . . . . . . . . . . . . . . . . . . 51.2 Tablet – Samsung Galaxy Tab . . . . . . . . . . . . . . . . . . . 61.3 iOS-Logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.4 Android-Logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.5 BlackBerry-Logo . . . . . . . . . . . . . . . . . . . . . . . . . . 81.6 Symbian-Logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.7 Windows Phone 7 Logo . . . . . . . . . . . . . . . . . . . . . . . 91.8 HP Palm webOS Logo . . . . . . . . . . . . . . . . . . . . . . . 101.9 Smartphone-Absatz (Bitkom 11/2010) . . . . . . . . . . . . . . 111.10 Tablet Absatz (weltweit) . . . . . . . . . . . . . . . . . . . . . 121.11 Smartphone Plattformverteilung . . . . . . . . . . . . . . . . . . 131.12 Smartphone - Wachstum . . . . . . . . . . . . . . . . . . . . . 14

2.1 Entwicklerumfrage: Mobile Entwicklung . . . . . . . . . . . . . . 172.2 Hybrid-App Architektur (Wrapper-Framework) . . . . . . . . . 22

3.1 HTML-Entwicklung . . . . . . . . . . . . . . . . . . . . . . . . . 253.2 HTML5 - Spezifikation . . . . . . . . . . . . . . . . . . . . . . . 263.3 HTML5 - Verwandte Spezifikationen . . . . . . . . . . . . . . . 303.4 JavaScript Benchmark SunSpider . . . . . . . . . . . . . . . . . 33

4.1 Kriterienkatalog: Legende . . . . . . . . . . . . . . . . . . . . . 404.2 Kriterienkatalog: Plattformunterstützung . . . . . . . . . . . . . 424.3 Kriterienkatalog: Plattform-Ressourcen . . . . . . . . . . . . . . 434.4 Kriterienkatalog: Performance . . . . . . . . . . . . . . . . . . . 444.5 Kriterienkatalog: Offline Ressourcen . . . . . . . . . . . . . . . . 464.6 LocalStorage – roomieplanet mobile (Safari Web-Developer Tools) 474.7 Kriterienkatalog: Multimedia . . . . . . . . . . . . . . . . . . . . 484.8 Kriterienkatalog: Benachrichtigungen . . . . . . . . . . . . . . . 494.9 Kriterienkatalog: Lizenzierung . . . . . . . . . . . . . . . . . . . 50

VII

4.10 Kriterienkatalog: Community . . . . . . . . . . . . . . . . . . . 514.11 Kriterienkatalog: Tools . . . . . . . . . . . . . . . . . . . . . . . 524.12 Kriterienkatalog: Wiederverwendbarkeit . . . . . . . . . . . . . . 534.13 Kriterienkatalog: Dokumentation . . . . . . . . . . . . . . . . . 544.14 Kriterienkatalog: Look & Feel . . . . . . . . . . . . . . . . . . . 554.15 Native UI-Komponenten (iPhone) . . . . . . . . . . . . . . . . . 564.16 Kriterienkatalog: Verschlüsselung . . . . . . . . . . . . . . . . . 574.17 Kriterienkatalog: Remote-Wartung . . . . . . . . . . . . . . . . 584.18 Kriterienkatalog: Werbung . . . . . . . . . . . . . . . . . . . . . 594.19 Kriterienkatalog: Distribution . . . . . . . . . . . . . . . . . . . 614.20 Kriterienkatalog: Monetarisierung . . . . . . . . . . . . . . . . . 624.21 Kriterienkatalog: Einschränkungen . . . . . . . . . . . . . . . . 63

5.1 Roomieplanet – Modulübersicht . . . . . . . . . . . . . . . . . . 645.2 Roomieplanet - Logo . . . . . . . . . . . . . . . . . . . . . . . . 655.3 Roomieplanet – Desktop . . . . . . . . . . . . . . . . . . . . . . 655.4 Roomieplanet mobile – Use Case Diagramm . . . . . . . . . . . 665.5 Roomieplanet UI-Konzept . . . . . . . . . . . . . . . . . . . . . 695.6 Roomieplanet mobile UI . . . . . . . . . . . . . . . . . . . . . . 705.7 Roomieplanet mobile (Querformat) . . . . . . . . . . . . . . . . 705.8 Roomieplanet-Mobile Komponentendiagramm . . . . . . . . . . 725.9 Roomieplanet mobile – Initialisierung . . . . . . . . . . . . . . . 735.10 Roomieplanet mobile – Datenbeschaffung . . . . . . . . . . . . . 755.11 Datenbeschaffung – Web-App . . . . . . . . . . . . . . . . . . . 775.12 Application-Cache Debugging . . . . . . . . . . . . . . . . . . . 795.13 WebSQL - Entwickler-Tools . . . . . . . . . . . . . . . . . . . . 815.14 PhoneGap – Logo . . . . . . . . . . . . . . . . . . . . . . . . . . 83

VIII

Tabellenverzeichnis

2.1 App-Absatz: Downloads und Umsatz . . . . . . . . . . . . . . . 162.3 Vergleich nativer Entwicklungsplattformen . . . . . . . . . . . . 18

3.1 HTML5-Verbreitung . . . . . . . . . . . . . . . . . . . . . . . . 273.2 Verbreitung verwandter Spezifikationen . . . . . . . . . . . . . . 303.3 Verbreitete JavaScript Engines . . . . . . . . . . . . . . . . . . . 32

4.1 Einteilung der Kriterien . . . . . . . . . . . . . . . . . . . . . . 404.2 Kriterienkatalog: Plattformunterstützung . . . . . . . . . . . . . 414.3 Kriterienkatalog: Plattform-Ressourcen . . . . . . . . . . . . . . 434.4 Kriterienkatalog: Performance . . . . . . . . . . . . . . . . . . . 444.5 Kriterienkatalog: Offline Ressourcen . . . . . . . . . . . . . . . 464.6 Kriterienkatalog: Multimedia . . . . . . . . . . . . . . . . . . . . 484.7 Kriterienkatalog: Benachrichtigungen . . . . . . . . . . . . . . . 494.8 Kriterienkatalog: Lizenzierung . . . . . . . . . . . . . . . . . . . 504.9 Kriterienkatalog: Community . . . . . . . . . . . . . . . . . . . 514.10 Kriterienkatalog: Tools . . . . . . . . . . . . . . . . . . . . . . . 524.11 Kriterienkatalog: Wiederverwendbarkeit . . . . . . . . . . . . . . 534.12 Kriterienkatalog: Dokumentation . . . . . . . . . . . . . . . . . 544.13 Kriterienkatalog: Look & Feel . . . . . . . . . . . . . . . . . . . 554.14 Kriterienkatalog: Verschlüsselung . . . . . . . . . . . . . . . . . 574.15 Kriterienkatalog: Remote-Wartung . . . . . . . . . . . . . . . . 584.16 Kriterienkatalog: Werbung . . . . . . . . . . . . . . . . . . . . . 594.17 Kriterienkatalog: Distribution . . . . . . . . . . . . . . . . . . . 604.18 Kriterienkatalog: Monetarisierung . . . . . . . . . . . . . . . . . 624.19 Kriterienkatalog: Einschränkungen . . . . . . . . . . . . . . . . 63

5.1 Use-Case Anwendungsfälle . . . . . . . . . . . . . . . . . . . . 67

IX

Abkürzungsverzeichnis

AJAX . . . Asynchronous JavaScript And XML

CSS . . . . . . Cascading Stylesheets

DOM . . . . Document Object Model

HTML . . Hypertext Markup Language

iOS . . . . . . Apple iOS - Betriebssystem für mobile Endgeräte

JSON . . . JavaScript Object Notation

MID . . . . . Mobile Internet Device - (engl. portables internetfähiges Gerät).

PHP . . . . . PHP: Hypertext Preprocessor

XML . . . . Extensible Markup Language

XI

Einleitung

Mobile Internet Devices (MIDs) 1 gewinnen immer mehr an Bedeutung. SeitEinführung des iPhones 2007 und der Veröffentlichung des Android Smart-phone-Betriebssystems 2008 hat sich der mobile Markt stark verändert: LautBitkom wird im Jahr 2011 bereits jedes dritte verkaufte Handy ein Smartphonesein und der Gesamtmarkt für Tablets wird laut Gartner von 19,5 MillionenGerä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 sichdabei um kleine Programme die meist über eine zentrale Stelle bezogen werdenkönnen und oft nur für eine bestimmte Aufgabe geschaffen sind. Somit lassensich MIDs beliebig erweitern und den eigenen Bedürfnissen anpassen. ZumStand der Arbeit gibt es bereits über 250.000 Apps für das iPhone von Appleund über 100.000 Apps für Android. Booz & Company prognostiziert bis 2013ein jährliches App-Wachstum von bis zu 73 % (vgl. Booz and Company [10]).Die Entwicklung dieser Apps stellt sich aber als relativ aufwendig dar, weiles für jedes Betriebssystem eine eigene Entwicklungsumgebung und spezielleSchnittstellen gibt, also eine App für jede Plattform separat implementiert wer-den muss. Durch die hohe Fragmentierung bei den mobile Geräten ist es aberfür die meisten Apps sehr wichtig, möglichst viele Plattformen – und somit An-wender – zu erreichen. Um plattformübergreifende Apps zu entwickeln, bietetsich im Moment einzig der Browser – auf Basis der WebKit-Browser-Engine– als einheitliche Basis. Aktuelle Web-Technologien, insbesondere HTML53,CSS34 und JavaScript bieten eine Vielzahl neuer Möglichkeiten für mobile An-wendungen: So lassen sich auf Smartphones und Tablets angepasste, mobileWebseiten entwickeln, die auch offline nutzbar sind und durch Einsatz zusätz-licher Frameworks dem Look&Feel nativer Apps nahe kommen. Obwohl mitHTML5 deutlich mehr Zugriff auf Ressourcen der Geräte verfügbar ist als mitHTML4 (z. B. Sensoren, Geolocation), so sind einige Komponenten weiterhinden nativen Apps vorenthalten (z.B. Kamera). Außerdem unterscheidet sich

1Mobile Internet Devices: Portable Geräte zwischen 3” und 10”2App ist die Kurzform von “Application” (engl. für Anwendung).3Hypertext Markup Language: Web-Auszeichnungssprache4Cascading Stylesheets: Sprache zur Definition der Darstellung von HTML

1

2

die Distribution bei Web-Apps im Vergleich zu den nativen Apps: Web-Appswerden automatisch lokal abgelegt, ohne dass eine aktive Installation erforder-lich ist. Bei nativen Apps hingegen erfolgt die Distribution hauptsächlich überplattform-spezifische zentrale Marktplätze, über welche Anwender ihre Appshauptsä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 undmehr Zugriff auf Plattform-Ressourcen zu bieten, gibt es sogenannte “HybridFrameworks”: Je nach Framework ist es somit möglich, native Apps zu imple-mentieren, die auf mehreren Plattform lauffähig sind und sich für den Anwen-der hinsichtlich der Distribution nicht von nativen Apps unterscheiden.

Diese Arbeit beschäftigt sich mit den verschiedenen Ansätzen der plattfor-mübergreifenden App Entwicklung auf Basis von Web-Technologien: Im erstenAbschnitt wird zunächst einmal die Gerätekategorie definiert und eine Progno-se der zukünftigen Entwicklungen abgegeben. Das zweite Kapitel beschäftigtsich mit den Apps und dazugehörigen betriebswirtschaftlichen Aspekten. Dar-auf folgt eine Analyse der plattformübergreifenden App-Entwicklung mit einerBeschreibung aktueller Web-Technologien (HTML5, CSS3) und wichtiger Fra-meworks. Um diese Ansätze besser einschätzen zu können, werden diese imvierten Kapitel hinsichtlich zahlreicher Kriterien evaluiert. Abschließend wer-den zwei Ansätze in Form von Prototypen implementiert, um den Reifegradaufzuzeigen und Erfahrungen der plattformübergreifenden Entwicklung zu do-kumentieren.

Kapitel 1

Mobile Internet Devices

1.1 Begriffsklärung

Der Begriff des “Mobile Internet Device” ist nicht einheitlich spezifiziert unddie Definition unterschiedet sich je nach Quelle in einigen Punkten. So be-schreibt Texas Instruments die Kernbestandteile eines MIDs in “außergewöhn-licher Multimedia-Funktionalität und einer umfangreichen Web-Unterstützungmit großen dynamischen Bildschirmen”, wobei die Größe des Gerätes nicht nä-her definiert ist (vgl. Instruments [28]). Der britische Chip-Hersteller ARMliegt mit seiner Definition nahe an der von Texas Instruments wobei mit einerlangen 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 Bildschirm-diagonale dessen Hauptaufgabe in der Unterhaltung und hoher Konnektiviätliegt. (vgl. Intel [29])

Um eine einheitliche Definition zu finden, ist ein Mobile Internet Device imRahmen 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 neueSparte der Tablets wie z.B. das iPad Untergruppen der Mobile Internet De-vices. Auch wenn manche Quellen Mobile Internet Devices anhand der Tele-fonfunktionalität von Smartphones abgrenzen, sind Smartphones im Rahmen

3

4 KAPITEL 1. MOBILE INTERNET DEVICES

dieser Arbeit als Teilgruppe der Mobile Internet Devices anzusehen, insbeson-dere da sich inzwischen einheitliche Plattformen für Smartphones und Tabletsetablieren und die Gerätekategorien teilweise verschmelzen.Folgende Geräte sind nach obiger Definition nicht Teil der Mobile InternetDevices, da es sich um Geräte ohne mobile Plattformen handelt und die Be-dienung i. d. R. nicht per Touchscreen erfolgt:

• Feature Phones: Handys die bereits einige Zusatzfunktionen haben, abernoch 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 (keinmobiles Betriebssystem)

1.2. GERÄTE 5

1.2 Geräte

1.2.1 Smartphones

Abbildung 1.1: Smartphone – Apple iPhone 4(Quelle: Wikipedia [65])

“Ein Smartphone ["smA:tf@Un] ist ein Mobiltelefon mit besondersleistungsfähigem Prozessor, welches den Funktionsumfang eines Mo-biltelefons um den eines Personal Digital Assistants (PDA) erwei-tert. Fortschrittliche Smartphones können über zusätzliche Pro-gramme (sogenannte Apps) vom Anwender individuell mit neuenFunktionen aufgerüstet werden”Smartphone [52]

Auch der Begriff “Smartphone” ist nicht einheitlich definiert und die Entwick-lung ist so rasant, dass man unter einem Smartphone in zwei Jahren deutlichmehr erwarten wird als zum Zeitpunkt dieser Arbeit. Die Abgrenzung zu den“Feature Phones” ist fließend und lässt sich stark vereinfacht wie folgt beschrei-ben: Ein Featurephone ist hauptsächlich ein Telefon und bietet zusätzlicheFunktionen, wie beispielsweise einen Kalender oder einen Taschenrechner. EinSmartphone ist auch ein Telefon, bietet darüber hinaus aber weitere Funk-tionen – z. B. E-mail, Kalender und Browser–, die durch sog. Apps beliebigerweitert werden können. Der signifikanteste Unterschied ist die Geräteplatt-form: So sind Featurephones oft mit einem eigenen Betriebssystem je Serieausgestattet und daher sind auch Programme meist auf bestimmte Geräteoder zumindest Hersteller angepasst. Bei Smartphones wird in der Regel einePlattform eingesetzt die auf mehreren Geräten läuft (z.B. Android, iOS) undzentral weiterentwickelt wird, wobei Featurephones meist ein eingeschränktesproprietäres Betriebssystem haben und zusätzliche Software, wenn überhauptmeist auf Basis von Java oder BREW entwickelt wird (vgl. Lee [34]).


Abbildung 1.2: Tablet – Samsung Galaxy Tab(Quelle: Samsung [50])

1.2.2 Tablets

“Ein Tablet-Computer (engl. tablet – Schreibtafel, US-engl. tablet– Notizblock), ist ein tragbarer, flacher Computer, der vollständigim Gehäuse eines Touchscreen untergebracht ist und per Fingeroder seltener per Stift bedient werden kann. Diese Geräte basie-ren meist auf einer proprietären Hardwarearchitektur mit einemEmbedded-Betriebssystem, welches vom Nutzer nicht ausgetauschtwerden kann.”[56]

Tablets sind eine relativ neue Gerätekategorie, die durch Apples iPad und zahl-reiche Tablets anderer Hersteller momentan einen regelrechten Boom erleben.Wichtig ist hierbei die Unterscheidung zwischen Tablet-Computer und TabletPC: So sind Tablet PCs meist normale Laptops auf Basis einer x86 Architektur,die sich per Stift bedienen lassen, wobei die Bedienung bei Tablet-Computernmeist über einen Touchscreen erfolgt und als Betriebssystem überwiegend em-bedded Systeme, wie iOS oder Android eingesetzt werden (vgl. Mag [36]). ImRahmen der Arbeit ist mit “Tablet” ein Tablet-Computer gemeint, also einportables Gerät mit einer mobilen Plattform.

1.3. PLATTFORMEN 7

1.3 Plattformen

1.3.1 Apple - iOS

Abbildung 1.3: iOS-Logo(Quelle: Apple [5])

Das proprietäre Betriebssystem iOS wurde am 9. Januar 2007 von Appleunter dem Namen iPhone OS vorgestellt. Es handelte sich dabei um ein auf dasiPhone angepasstes Betriebssystem, das auf Mac OS X basiert und dieses füreine Touch-Bedienung optimiert. Nachdem das Betriebssystem auch auf demiPod und dem iPad eingesetzt wird, hat Apple das Betriebssystem am 7. Juni2010 in iOS umbenannt. Die aktuelle Version zum Zeitpunkt dieser Arbeit ist4.2.1 (vgl.iOS [30]). iOS wird nur auf Apple-Geräten eingesetzt und ist bis aufeinige Open-Source Komponenten ein geschlossenes System.Native Anwendungen für iOS werden in Objective-C geschrieben und sind aus-schließlich über Apples “AppStore” erhältlich, sofern diese Apples Richtlinienentsprechen und freigegeben wurden. Mit xCode ist eine komplette Entwick-lungsumgebung mit IDE und Simulator erhältlich (vgl. Apple [2]).

1.3.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 anderenMitgliedern der Open Handset Alliance ein Betriebssystem namens Android.Dieses basiert auf dem Linux-Kernel 2.6 und ist ein quelloffenes Betriebssys-tem für Mobile Internet Devices. Momentan ist Android die mobile Plattformmit dem größten Wachstum und neben Smartphones sind inzwischen auch


Tablet-Computer mit Android auf dem Markt. (vgl.Wikipedia [69]). Das enor-me 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:200.000 Android-Smartphones würden nun täglich verkauft. Dasbedeute eine Verdoppelung innerhalb von nur zwei Monaten.” Hei-se [21]

Android ist Open Source, native Anwendungen werden in Java geschrieben,wobei mit “Android ADT” (Android Development Tools) eine Entwicklungs-umgebung in Form eines Eclipse-Plugins zur Verfügung steht. Anwendungenkönnen über den “Android Market” vertrieben werden, es ist aber auch möglichandere zentrale App-Portale zu nutzen oder die App per Download anzubieten(vgl. Open Handset Alliance [43]).

1.3.3 RIM – BlackBerry

Abbildung 1.5: BlackBerry-Logo(Quelle: RIM [49]

Alle BlackBerry-Geräte der kanadischen Firma RIM (Research in Moti-on) nutzen ein eigenes proprietäres Betriebssystem. Die Bedienung war langedurch ein Daumenrad gelöst, wobei aktuellen Geräten inzwischen auch mit ei-nem Touchscreen ausgestattet sind. RIM bietet für BlackBerry-Smartphonesumfangreiche Client-Server-Software und ist besonders im Businessbereich sehrverbreitet. Im September 2010 hat RIM einen Tablet-Computer namens “Play-book” 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 ge-schrieben und die Distribution erfolgt hauptsächlich über RIMs “App World”,wobei auch andere Kanäle möglich sind (vgl. RIM [48]).

1.3.4 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-

1.3. PLATTFORMEN 9

Abbildung 1.6: Symbian-Logo(Quelle: Symbian [54])

menschluss mehrerer Unternehmen, entwickelt und ist als Open Source verfüg-bar. Dieses Betriebssystem wurde u. a auf Smartphones von Nokia, Siemensund Sony Ericsson eingesetzt, allerdings haben sowohl Samsung als auch SonyEricsson im September 2010 angekündigt keine Geräte mehr mit Symbian aus-zuliefern (vgl. Symbian [55]). Wie es um die Zukunft der Plattform steht, istdaher fraglich, was folgendes Zitat verdeutlicht:

“Auch wenn Nokia betont, Symbian sei nicht tot, so macht derSchritt doch eines deutlich: Symbian als Betriebssystem wird künf-tig keine große Rolle spielen. So werden die Smartphones der N-Serie künftig nicht mehr damit bestückt, sondern mit MeeGo aus-geliefert. Damit rückt Qt als geräte- und plattformübergreifendeEntwicklungsplattform in den Mittelpunkt. Symbian ist also nichttot, wird aber vermutlich aus Entwickler- und Nutzersicht unwich-tig.” Ihlenfeld [25]

Anwendungen für Symbian werden üblicherweise in C/C++ geschrieben, wobeidie Möglichkeit besteht, Web-Anwendungen direkt auf die Symbian Plattformzu bringen. Apps können auf unterschiedlichen Wegen angeboten werden undneben diversen Stores (z.B. Ovi Store) ist es auch möglich diese direkt perDownload anzubieten. Für Entwickler gibt es eine Entwicklungsumgebung mitEmulator (vgl. Symbian [53]).

1.3.5 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 ba-sierte auf Windows CE 3.0. Microsofts Betriebssystem für Handhelds undPocket PCs ist momentan in der Version 6.5.3 angekündigt und wird immer


noch auf einigen Geräten eingesetzt, wobei die Bedienung bei Windows Mobileper Stift erfolgt und die Bedienelemente an das klassische Windows angelehntsind. Seit Oktober 2010 ist der Nachfolger unter der Bezeichnung “WindowsPhone 7” auf dem Markt. Es handelt sich dabei um eine Neuentwicklung diebesonders auf die Bedienung per Touchscreen und Multitouch ausgelegt ist(vgl. Mobile [40]).Anwendungen für Windows Mobile bzw. Phone 7 werden auf Basis von .NEToder Silverlight entwickelt und als IDE wird Visual Studio und ein entsprechen-des SDK (Software Development Kit) angeboten. Apps werden in der Regelüber den Windows Mobile Marketplace verteilt, wobei es auch die Möglichkeitgibt diese bei anderen Markets anzubieten (vgl. Microsoft [38]).

1.3.6 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 FirmaPalm vorgestellt. Das Betriebssystem ist auf die Bedienung per Touchscreenausgelegt, bietet seit der ersten Version Multitasking und setzt bei der Anwen-dungsentwicklung auf Web-Technologien wie HTML5, CSS und JavaScript.Nachdem Palm von HP aufgekauft wurde, war anfangs nicht klar was mitwebOS passieren würde, aber im Oktober 2010 kündigte HP webOS in derVersion 2.0 an, wobei die neue Version sowohl auf den alten, noch von Palmentwickelten, als auch auf neuen von HP entwickelten Geräten eingesetzt wer-den kann. (vgl. webOS [62])Anwendungen für webOS sind auf Basis von Web-Technologien geschriebenund mit “Mojo” steht eine plattformeigene JavaScript-API für Entwickler zurVerfügung, wobei die Apps über verschiedene Kanäle angeboten werden undkeine Bindung an einen zentralen Markt besteht (vgl. HP [22])

1.4. MARKT UND ABSATZ 11

1.4 Markt und Absatz

1.4.1 Smartphones

Der Smartphone-Absatz steigt in den letzten Jahren kontinuierlich und es istzu 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 drit-te verkaufte Handy ein Smartphone sein, wobei der Durchschnittspreis derSmartphones bei 226 Euro, der Preis normaler Handys bei 116 Euro liegt. DerSmartphone-Absatz in Deutschland wird für das Jahr 2011 auf ca. 10 MillionenGeräte prognostiziert, wobei der Umsatz im Vergleich zum Vorjahr um 35 %auf 2,2 Milliarden € steigen wird. Der Smartphone-Markt ist momentan starkumkämpft und jeder Hersteller versucht möglichst schnell neue Geräte auf denMarkt zu bringen (vgl. Bitkom [9]).

“Die Verbreitung von Smartphones liegt weltweit allerdings nochauf einem sehr niedrigen Niveau, nur etwa jeder Achte besitzt einsolches Gerät. In Deutschland sind es dagegen mehr als 40 Pro-zent, was die Deutschen zu den Vorreitern in der Adoption vonSmartphones macht.” Infratest [27]

Wie dieses Zitat aus dem Jahr 2008 beweist, war die Smartphoneverbreitungin Deutschland bereits vor zwei Jahren schon sehr hoch. Wenn man das ak-tuellen Wachstum in der Branche betrachtet kann man davon ausgehen, dassdie Verbreitung von Smartphones weiter gestiegen ist.


1.4.2 Tablets

Der weltweite Markt für Tablets wird laut Gartner von 19,5 Millionen Gerätenim Jahre 2010 um 181 % auf 54,8 Millionen Geräte im Jahre 2011 wachsenund 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 zahl-reiche Tablets anderer Hersteller angekündigt und es sind inzwischen mehrereGeräte erhältlich. Neben Ausnahmen wie dem WeePad auf Basis von MeeGo– einem offenen Betriebssystems auf Linux Basis – setzen die meisten Tabletsauf Android. Google selbst rät davon ab Android vor Version 3.0 auf Tabletseinzusetzen, da alle aktuellen Versionen noch nicht auf die neue Gerätekatego-rie angepasst ist. Die meisten Tablets auf Android Basis sind daher momentanmit einem Mobilfunk-Modul ausgestattet und kleiner als das iPad um denBestimmungen für Googles “Android-Market” gerecht zu werden (vgl. Beavis[8]). Dieser Schritt vieler Hersteller verdeutlicht wie wichtig der Markt der Ta-blets momentan ist und nahezu jeder Hersteller der Elektronik-Branche hatinzwischen ein Tablet auf dem Markt, oder zumindest in Planung.

Abbildung 1.10: Tablet Absatz (weltweit)(Quelle: Gartner [15])

1.5. PLATTFORMVERBREITUNG 13

1.5 Plattformverbreitung

Abbildung 1.11: Smartphone Plattformverteilung(Quelle: Gartner [16])

Momentan sind Symbian, Android, iOS und RIM-BlackBerry am Absatzgemessen die vier wichtigsten Betriebssysteme für Smartphones. Die Vertei-lung hat sich in den letzten Quartalen aber stark verändert und so werden sichnach aktuellen Prognosen Android, iOS und BlackBerry als die wichtigstenPlattformen etablieren, wobei Symbian nach dem Ausstieg von Samsung undSony Ericsson immer mehr Marktanteile verlieren dürfte. Für die Marktantei-le bei den Tablet-Computern gibt es momentan noch keine aussagekräftigenZahlen, da es sich um einen sehr jungen Markt handelt, es ist aber zu erwar-ten 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ßeMasse an neuen Tablets mit Android als Betriebssystem wieder gut zu machen.Bezieht man Tablets, kleine MIDs wie Apples iPod Touch oder Mischformenwie Dells Streak in die Plattformverteilung mit ein, so dürfte der Marktanteilvon Android und iOS weitaus größer sein und es ist abzuwarten wie sich derMarkt in diesem Bereichen weiterentwickelt.


“Any Plattform that fails to innovate quickly — either through avibrant multi-player ecosystem or clear vision of a single controllingentity — will lose developers, manufacturers, potential partnersand ultimately users.” Cozza [11]

Abbildung 1.12: Smartphone - Wachstum(Quelle: Gartner [16])

Gewinnen werden die Plattformen, die sich schnell weiterentwickeln und sichdurch Innovation von der Konkurrenz absetzen. Um als Plattform bestehenzu können, muss diese nicht nur einen Gerätetyp unterstützen, sondern vonGröße und Ausstattung weitgehend unabhängig einsetzbar sein, um möglichstalle Gerätekategorien und Mischformen abzudecken.

Kapitel 2

Apps - mobile Applikationen

Nachdem die Mobile Internet Devices definiert sind, beschäftigt sich dieses Ka-pitel mit den Apps: Dabei geht es um die Definition und die zukünftige Ent-wicklung der Apps, aber auch um die möglichen Arten einer Implementierung.Obwohl die Anzahl an Apps stetig steigt und unter betriebswirtschaftlichenGesichtspunkten sehr interessant ist, so ist die Fragmentierung der MIDs eingroßen Problem der App-Entwicklung.

2.1 Begriffserklärung und Markt

“App” – die Kurzform für Application (engl. Anwendung) – ist die Bezeichnungfür ein Stück Software bzw. ein Programm. Obwohl der Begriff “App” keines-wegs auf mobile Anwendungen beschränkt ist, hat er sich besonders dort welt-weit durchgesetzt, wobei Apple sicherlich eine gewisse Vorreiter-rolle gespielthat: So sind Apps für Apple-Geräte über den sog. “AppStore” zu beziehen undder Slogan “There is an app for that” ist ein eingetragenes Markenzeichen vonApple. Inzwischen bezeichnen alle Anbieter mobile Anwendungen als App undder Begriff ist weit verbreitet. (vgl. Winfuture [70])

Mobile Apps sind im Gegensatz zu Desktop-Anwendungen meist nur für einenbestimmten Aufgabenbereich geschaffen und auf diesen zugeschnitten und op-timiert. So hat man auf einem Laptop ein ganzes Office-Paket mit Funktionenfür Textverarbeitung, Tabellenkalkulation und Präsentationen. Auf dem iPadwährend gibt es für jeden dieser drei Bereiche eine eigene App. Es gibt Appsfür fast alle Bereiche des Lebens und neben Standard-Apps für das Wetteroder die Börse, sind auch viele skurrile Apps verfügbar.

15

16 KAPITEL 2. APPS - MOBILE APPLIKATIONEN

2009 2010 2013Downloads (in Mio.) 2.516 4.507 21.646

Gesamtumsatz (in Mio.) 4.237,80 6.770,40 29.479,30

Tabelle 2.1: App-Absatz: Downloads und Umsatz(Quelle: Gartner [14])

Der App-Markt wächst auf allen Plattformen rasant und jeden Tag wer-den zahlreiche neue Apps entwickelt. Das Wachstum in diesem Bereich wirdim Laufe der nächsten Jahre noch deutlich steigen, wobei sich die Anzahl derDownloads allein von 2009 auf 2010 fast verdoppelt hat. Eine proportionaleRelation zwischen Downloadzahlen und dem Umsatz ist allerdings nicht gege-ben, da momentan ca. 80 % der Apps kostenlos angeboten werden und dieseQuote laut Gartner-Prognose bis 2013 auf 87 % steigen wird. Oft werden auch“Lite”-Versionen von Apps angeboten, eine Art Demo um potentielle Kundenvom Nutzen der Vollversion zu überzeugen. (vgl. Gartner [14])

Kostenlose Apps können auch Einnahmen bringen: Durch Werbung innerhalbder Apps kann auch mit kostenlosen Apps Gewinn erzielt werden und es gibtz. B. mit iAd von Apple oder mobile Ads von Google fertige Lösungen die Ent-wickler integrieren können. Laut Gartner werden mit werbe-finanzierten Apps2013 bereits 25 % des gesamten App-Umsatzes erzielt. (vgl. Gartner [14])

Eine weitere Möglichkeit mit Gratis-Apps Gewinn zu machen ist das so ge-nannte “In-App-Purchasing”: Die App an sich ist kostenlos, aber innerhalb derApp kann man sich Erweiterungen, wie beispielsweise weitere Spiel-Level kau-fen. Viele Magazine wie z. B. der Spiegel nutzen ähnliche Modelle und bieteneine kostenlose App an, wobei jede digitale Ausgabe separat gekauft werdenmuss. (vgl. Gartner [14])

Die Preise für Apps unterscheiden sich weltweit: In Europa liegt der Durch-schnittspreis der bestverkauften Apps bei ca. 3€, wobei der Preis in Nord-amerika (1,70 €) und in Asien (2 €) geringer ist. Es gibt auch zwischen denPlattformen preislich deutliche Unterschiede: Mit über 5 € sind Apps für Win-dows Mobile im Vergleich am teuersten, wobei Apps für Windows Phone 7 imSchnitt auf dem preislichen Level der Mitbewerber liegt. So liegt der Durch-schnittspreis aller kostenpflichtiger Android-, iOS- und BlackBerry-Apps bei 2bis 3 €. Apps aus dem webOS-Store, Nokias Ovi-Store und Windows PhonesMarketplace liegen im Schnitt um die 1,50 €. (vgl. Distimo [12])

2.2. ENTWICKLUNG 17

2.2 Entwicklung

Die Entwicklung von Apps hat sich vom Nischenbereich zu einem der wich-tigsten Wachstumsmärke entwickelt.

“According to the survey, more than half of all IT professionals –55 percent – expect mobile software application development fordevices such as iPhone and Android, and even tablet PCs like iPadand PlayBook, will surpass application development on all othertraditional computing platforms by 2015.” IBM [24]

So besagt eine Studie von IBM - DeveloperWorks: 55 % aller befragten IT-Experten sind der Meinung dass die Entwicklung von Software für mobileEndgeräte 2015 wichtiger sein wird als die herkömmliche Anwendungsentwick-lung.

Abbildung 2.1: Entwicklerumfrage: Mobile Entwicklung(Quelle: IBM [24])

Die Entwicklung von Apps ist je nach Gerätetyp und Plattform sehr unter-schiedlich und sowohl Programmiersprache, Entwicklungsumgebung und Pro-zesse unterscheiden sich stark. Deshalb muss man Apps momentan für jedePlattform separat entwickeln und da es keine einheitliche API gibt, ist auchdie Code-Wiederverwendbarkeit sehr eingeschränkt. Die Verbreitung der MIDssteigt stetig und der Bedarf nach Apps steigt in selbem Maße. Daher beschäf-tigt sich der nächsten Abschnitt mit den Möglichkeiten der plattformübergrei-fenden App-Entwicklungen und den verschiedenen Ansätzen.


2.3 App-Typen

2.3.1 Native Apps

Native Apps sind auf die jeweilige Plattform angepasste Anwendungen, dieüber APIs und Bibliotheken Zugriff auf die Hardware haben und direkt aufden Geräten installiert werden können. Die Programmierung erfolgt in dervon der Plattform vorgegebenen Sprache und die Distribution der App erfolgtmeist über eine zentrale Stelle. (z. B. Apple AppStore, Google Market)Der Großteil der verfügbaren Apps sind nativ und weitere Ansätze sind nochnicht 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 KosteniOS Objective-C Xcode 99$ / Jahr

Android Java (C, C++) Eclipse (ADT) 25$ einmaligBlackBerry Java JDE 20$ / AppSymbian C++ Eclipse 50$webOS JavaScript Eclipse z.Z. kostenlos

Windows Mobile .NET, C, C++ Visual Studio 99$ / JahrTabelle 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 derApp zusammengefasst. dabei ist das prozentuale Verhältnis der Gewinnteilungzwischen Entwickler und dem jeweils größten zentralen Marktplatz bei allenPlattformen 70:30.

2.3. APP-TYPEN 19

2.3.2 Web Apps

Web-Apps sind (mobile) Webseiten, die auf Basis von Web-Technologien wieHTML, CSS und JavaScript entwickelt werden. Der Begriff Web-App ist abernicht auf mobile Webseiten beschränkt und so sind im Prinzip alle Anwendun-gen im Web als “Web-App” zu sehen. Obwohl es keine genaue Definition gibt,wird der Begriff hauptsächlich im Zusammenhang mit HTML5 genannt. Dabeihandelt es sich um offline-fähige Webseiten, die an mobile Geräte angepasstsind und sich an nativen Apps orientieren. Die technische Grundlage ist dabeidie selbe wie bei normalen Webseiten, jedoch wird durch die Verwendung vonHTML-5-Funktionen eine bessere Plattform-Integration erreicht. (z. B. durchortsbezogene Dienste und die Integration von Sensoren)

Da die Browser auf Smartphones erst seit wenigen Jahren HTML, CSS undJavaScript unterstützen und zuvor angepasste Sprachen wie WML zum Ein-satz kamen, ist die Web-App-Entwicklung noch relativ jung. Doch im Ver-gleich zur herkömmlichen Web-Entwicklung gibt es auf mobilen Plattformeneinen entscheidenden Vorteil: Ein großer Kritikpunkt der Desktop-Browser istdie Fragmentierung durch verschiedene Browser-Engines, wodurch es für Web-Entwickler relativ schwer ist Desktop-Web-Apps einheitlich zu gestalten unddie Funktion browserübergreifend in vollem Umfang zu gewährleisten. AlleStandard Browser der verbreiteten mobilen Plattformen setzen im Moment aufdie Browser-Engine “WebKit” auf. Somit hat sich eine Art Standard entwickelt,der es für mobile Web-App Entwickler deutlich erleichtert plattformübergrei-fend mobil zu entwickeln.

Bisher waren Web-Apps relativ eingeschränkt und wichtige Funktionen fehlten,wodurch das Einsatzgebiet stark eingeschränkt war. Durch HTML5 eröffnensich für Entwickler viele neue Möglichkeiten und so ist es inzwischen möglicheine Web-App offline-fähig zu machen oder den Standort des Gerätes per GPSzu ermitteln. Das Einsatzgebiet von Web-Apps wird dadurch deutlich erweitertund komplexe Anwendungen sind inzwischen realisierbar. Durch den Einsatzvon zusätzlichen Frameworks wie z. B. Sencha Touch oder jQuery mobile istes deutlich einfacher eine Web-App an das Look&Feel native Apps anzupas-sen und durch UI-Komponenten, Animationen und zahlreiche Hilfsklassen sindWeb-Apps inzwischen in manchen Bereichen von nativen Apps kaum zu un-terscheiden.

Web-Apps werden in Form einer Webseite angeboten und die “Installation”erfolgt automatisch, wobei die App für den Anwender nicht als solche wahr-genommen wird. Außerdem sind offline-fähige Web-Apps noch nicht sehr ver-breitet, so dass kaum jemand versuchen wird eine Webseite aufzurufen, so-lange keine Internetverbindung besteht. Es gibt aber bereits Pläne für Web-


App-Stores die solche Web-Apps in gepackter Form anbieten, so dass es fürAnwender verständlicher wird und die Unterschiede zur nativen App immergeringer werden. Der größte Nachteil ist im Moment der eingeschränkte Zugriffauf Hardware- oder Software-Funktionen der Geräteplattform. So ist es nichtmöglich die Kamera der Geräte anzusteuern oder auf den Kalender zuzugrei-fen. Erste Entwicklungen in diese Richtung sind aber bereits im Gange undes ist zu erwarten dass Web-Apps bald deutlich mehr Möglichkeiten bieten alszum 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 gegebenen-falls Grafiken. Der Zugriff etwa auf Sensoren, Netzwerk- Interfacesoder Audio/Video ist damit aber nicht möglich, weil JavaScriptdie Schnittstellen zu diesen Betriebssystemfunktionen fehlen. Da-mit das funktioniert, braucht es einen Mittler, der die FunktionenJavaScript-seitig bereitstellt. “Lau [33]

Diese Aussage ist nur bedingt korrekt und inzwischen ist der Zugriff auf Senso-ren möglich, jedoch noch sehr eingeschränkt. Web-Apps lassen sich aber durchFramework ergänzen, welche diese Schnittstellen zur Verfügung stellen. Es gibtverschiedene dieser sog. “Hybrid-Frameworks”, die teilweise Web-Apps direkterweitern, oder in Form eines kompletten Applikations-Frameworks auf be-stimmte Web-Technologien (wie z. B. JavaScript) aufsetzen. Eine Auswahl derwichtigsten Frameworks wird im nächsten Kapitel genauer betrachtet.

2.3. APP-TYPEN 21

2.3.3 Hybrid Apps

Hybrid Apps sind eine Mischung aus Web-App und nativer App. Ziel ist es dieVor- und Nachteile der nativen- und der Web-Apps auszugleichen.

Hybrid Frameworks setzten i. d. R. auf Web-Technologien und ermöglichen esplattformübergreifende Apps zu entwickeln die für den Anwender nicht vonnativen Apps zu unterscheiden sind. Vereinfacht bietet ein Hybrid-Frameworkeinen Container für eine Web-App, wobei bestimmte plattformspezifischenFunktionen mithilfe von JavaScript (oder anderen Web-Sprachen) für den Ent-wickler bereitgestellt werden. So ist es möglich, dass die App beispielsweiseauch auf den Kalender der jeweiligen Plattform zugreifen, oder das Gerät vi-brieren lassen kann, was bei reinen Web-Apps nicht möglich ist. Hybrid-Appswerden zu “nativen” Paketen kompiliert und können somit über die platt-formeigenen App-Stores angeboten werden. Die Basis der Hybrid-Technologieist meist der sog. “WebView”, also ein in die native Anwendung eingebetteterBrowser, der die Darstellung der Web-App übernimmt (vgl. Abbildung 2.2).Es gibt aber auch Frameworks die native UI-Komponenten erzeugen und somitnicht direkt auf Web-Apps basieren.

Da die Entwicklung im Bereich der Web-Apps momentan sehr schnell vorrangeht, und immer mehr Funktion die bisher nativen Apps vorbehalten waren,auch für Web-Apps zu Verfügung stehen, kann man davon ausgehen dass dieHybrid-Apps als Übergangslösung langfristig von reinen Web-Apps abgelöstwerden. So hat Apple beispielsweise mit dem letzten Update von iOS die Un-terstützung von neuen HTML5-Funktionen deutlich ausgebaut und es ist jetztbeispielsweise möglich auf die Beschleunigungssensoren zuzugreifen (vgl. mo-bilexweb [42]).


Abbildung 2.2: Hybrid-App Architektur (Wrapper-Framework)(Quelle: Eigene Abbildung)

Kapitel 3

Cross-Plattform App-Entwicklung

Nachdem die Bedeutung der Apps im letzten Kapitel ausführlich betrachtetwurde, beschäftigt sich dieses Kapitel mit den verschiedenen Möglichkeiten derApp-Implementierung: Als Grundlage wird dabei die Entwicklung von Web-Apps auf Basis von HTML5 genauer betrachtet. Des Weiteren behandelt dieserAbschnitt eine Reihe von Frameworks, die die Web-App-Entwicklung vereinfa-chen, oder die Umsetzung in Form einer nativen App ermöglichen. Da mobileWeb-Technologien in dieser Arbeit als Grundlage dienen sollen, wird dieserBereich in diesem Kapitel sehr detailliert betrachtet.

3.1 Mobile Web-Entwicklung – Web-Apps

3.1.1 HTML5

3.1.1.1 Herkunft und Definition

“Die Hypertext Markup Language (HTML, dt. Hypertext - Aus-zeichnungssprache), oft kurz als Hypertext bezeichnet, ist eine text-basierte Auszeichnungssprache zur Strukturierung von Inhalten wieTexten, Bildern und Hyperlinks in Dokumenten. HTML-Dokumentesind die Grundlage des World Wide Web und werden von einemWebbrowser dargestellt. Neben den vom Browser angezeigten In-halten einer Webseite enthält HTML zusätzliche Angaben in Formvon Metainformationen, die z. B. über die im Text verwendeteSprache oder den Autor Auskunft geben oder den Inhalt des Texteszusammenfassen. Die Auszeichnungssprache wird vom World Wi-de Web Consortium (W3C) weiterentwickelt. Aktuell trägt HTMLdie Versionsnummer 4.01. HTML5 befindet sich in der Entwick-lung. Parallel existiert die Extensible Hypertext Markup Language(XHTML).” Wikipedia [67]

23

24 KAPITEL 3. CROSS-PLATTFORM APP-ENTWICKLUNG

Noch vor wenigen Jahren wurden mobile Webseiten aufgrund der eingeschränk-ten Leistungsfähigkeit und Verbindungsgeschwindigkeit auf Basis abgespeckterHTML-Versionen (z. B. WML : Wireless Markup Language) realisiert. Heut-zutage sind mobile Webseiten hauptsächlich mit HTML, CSS und JavaScriptrealisiert, also auf Basis der selben Technologien, die auch bei der “Desktop”-Web-Entwicklung im Einsatz sind. Durch HTML5 gibt es zahlreiche bedeuten-de Neuerungen, die gerade im Bereich der App-Entwicklung vom Bedeutungsind. 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 unab-hängigen Arbeitsgruppe – entwickelt und die aktuelle Version 4.01 wurde am24.12.1999 verabschiedet.

Parallel existiert mit XHTML seit Januar 2000 eine Neuimplementierung vonHTML 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 durchdas W3C nicht zufrieden waren, wurde 2004 die Arbeitsgruppe WHATWG1

gegründet. Diese setzt sich auf Mitarbeitern verschiedener Firmen (u.a. Apple,Mozilla, Opera) und Organisationen zusammen und beschäftigt sich mit derZukunft von HTML und Web-Anwendungen. (vgl. Wikipedia [67])

“The Web Hypertext Application Technology Working Group -(WHATWG) is a growing community of people interested in evol-ving the Web. It focuses primarily on the development of HTMLand APIs needed for Web applications. The WHATWG was foun-ded by individuals of Apple, the Mozilla Foundation, and OperaSoftware in 2004, after a W3C workshop. Apple, Mozilla and Operawere becoming increasingly concerned about the W3C’s directionwith XHTML, lack of interest in HTML and apparent disregardfor the needs of real-world authors. So, in response, these organi-sations set out with a mission to address these concerns and theWeb Hypertext Application Technology Working Group was born.”WHATWG [64]

Die WHATWG hat sich unter anderem mit Web-Forms, also neuen Formula-ren für das Web und der Standardisierung von Web-Applications beschäftigt.Nachdem W3C und WHATWG lange Zeit parallel gearbeitet hatten wurdeim Oktober 2006 die Zusammenarbeit beschlossen: Somit ist HTML5 eineZusammenführung von HTML, XHTML und Web-Applications unter einerOrganisation (W3C HTML Working Group) (vgl. WHATWG [64])

1WHATWG: Web Hypertext Application Technology Group

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, sondernals 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 2HTML addressing many of the issues of those specifications whileat the same time enhancing (X)HTML to more adequately addressWeb applications. Besides defining a markup language that canbe written in both HTML (HTML5) and XML (XHTML5) it alsodefines many APIs that form the basis of the Web architecture.Some of these APIs were known as "DOM Level 0" and were neverdocumented before. Yet they are extremely important for browservendors to support existing Web content and for authors to be ableto build Web applications.” WHATWG [64]

Die Bezeichnung HTML5 wird oft für Technologien verwendet, die gar nichtTeil 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


Zum Zeitpunkt dieser Arbeit ist HTML5 noch im Working-Draft-Status, wobeiviele Funktionen bereits in Browsern implementiert sind und besonders mobi-le Browser eine umfangreiche Unterstützung bieten. Wann HTML5 komplettverabschiedet wird und ab wann die Implementierung abgeschlossen sein wird,ist nicht genau festgelegt – Die WHATWG äußert sich auf die Frage nach demStand von HTML5 wie folgt:

“Different parts of the specification are at different maturity levels.Some sections are already relatively stable and there are imple-mentations that are already quite close to completion, and thosefeatures can be used today (e.g. <canvas>). But other sections arestill being actively worked on and changed regularly, or not evenwritten yet.” WHATWG [64]

Der Reifegrad der Spezifikationen ist also sehr unterschiedlich, wobei einigewichtige Komponenten (z. B. Canvas) bereits als relativ stabil zu betrachtensind. Um den Umfang der Implementierung dieser neuen Funktionen zu tes-ten, gibt es verschiedene HTML5-Tests, die je nach Umfang und Optimierungunterschiedliche Ergebnisse liefern.

3.1.1.2 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 Implementie-rung: Der hierfür verwendete Test bietet lediglich Auskunft inwieweit die APIs


vorhanden sind. Eine Bewertung der Qualität oder Performance ist nicht Be-standteil des Tests. Die Bewertung ist je Plattform getrennt und erfolgt in Formeiner Punktzahl: So bedeutet beispielsweise “14/14” bei Web-Applications, dass14 Teilbereiche der Spezifikation implementiert sind. Wie man anhand der fol-genden Tabelle 3.1 sehen kann, ist die HTML5-Spezifikation sowohl unter iOS,als auch unter Android relativ umfassend implementiert. Einzig Local Devicesund Microdata sind noch nicht Bestandteil der mobilen Browser.

Spec/OS iOS 4.2 Android 2.2Parser − (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 146 142

Tabelle 3.1: HTML5-Verbreitung(Quelle: Eigene Tabelle / Daten: Leenheer [35])


HTML5-Spezifikation

• Parser : HTML Parsing Rules

• Web-Applications

– Application-Cache: Offline-fähige Webseiten (Manifest-File)

• Elements : Neue Struktur-Elemente

– Section Elements (z. B. <section>, <nav>, <article>)

– Grouping Elements

– Text-level-semantics

– Content-Editable: Editierbare Bereiche definieren

• Forms

– Input-Element-Types (z. B. search, tel, url, email)

– 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. beiAJAX wichtig)

– Text selection: Interface zur Textauswahl

• Video: Integration von Videos (je nach Browser: MPEG-4, H264, OggTheora, WebM)

• Audio: Integration von Audio (je nach Browser: PCM, MP3, AAC, OggVorbis, WebM

• Canvas: Zeichen-API (2D, Text)

• Microdata: Integration maschinen-lesbarer Informationen

• Local Devices: Zugriff auf angeschlosse Geräte (z. B. Webcam)


Folgende Teilbereiche sind besonders für mobile Web-Apps von Bedeutung undwerden daher noch einmal ausführlich behandelt:

Application-Cache:Durch ein so genanntes “MANIFEST” – eine Textdatei mit Pfadangaben zuDateien – kann man definieren, welche Dateien lokal (beim Client) abgelegtwerden sollen: Eine Web-App ist damit auch verfügbar, wenn keine Datenver-bindung zum Internet besteht, wobei Dateien die auf dem Server aktualisiertwurden 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 über-arbeitet um beispielsweise eine Automatische-Vervollständigung der Feld-werte(Autocomplete) zu ermöglichen. Diese Punkte spielen besonders bei MIDs mitSoftware-Tastatur eine Rolle, da sich diese an das Feld anpasst und bei einemZahlenfeld beispielsweise nur Zahlen zeigt um dem Anwender die Eingabe zuerleichtern.

Video und Audio:Bisher war es nicht möglich ein Video direkt in ein HTML-Dokument ein-zubinden, weshalb sich Adobe Flash im Internet als Video-Player etablierenkonnte. Durch HTML5 ist es möglich Video und Audio direkt einzubinden, wiees 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 dienative Multimedia-Integration eine sehr bedeutende Neuerung. Problematischist momentan noch die Wahl des Codecs, da es noch keine einheitliche Linieder Browser-Hersteller gibt.


Es gibt einige Spezifikationen die unabhängig veröffentlicht werden, jedochoft mit HTML5 in Verbindung gebracht werden. Viele dieser Spezifikationensind 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 verwand-ten Spezifikationen nicht ganz so ausführlich implementiert, wie die HTML5-Spezifikation an sich. Besonders WebGL, die Files-API und WebWorkers sindnoch nicht in die mobilen Browser integriert. Generell zeigt sich bei den ver-wandten Spezifikationen ein abweichender Stand der Implementierung: So bie-tet iOS bereits mehr Schnittstellen als Android, da der Browser von Androidweniger APIs der Communications-API bereitstellt.

Spec/OS iOS 4.2 Android 2.2Geolocation + (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 50 30

Tabelle 3.2: Verbreitung verwandter Spezifikationen(Quelle: Eigene Tabelle / Daten: Leenheer [35])


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 meh-rerer Skripte


3.1.2 JavaScript und DOM

3.1.2.1 JavaScript

“The standard name for JavaScript is ECMAScript, because it isdefined by the ECMA (an international, private nonprofit stan-dards organization). There are three well-known dialects on themarket: JavaScript (trademark of Sun, licensed now to the Mozil-la 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 ers-ten Mal der Öffentlichkeit vorgestellt. Nachdem Netscape und Sun im Dezem-ber eine Zusammenarbeit ankündigten um Java-Applets direkt mit Live-Scriptsteuerbar zu machen, wurde die Sprache in JavaScript umbenannt. Microsoftunterstützt JavaScript in Form von JScript seit der Version 3.0 des Internet-Explorers, wodurch der sogenannte “Browser-Krieg” – das “Wettrüsten” derunterschiedlichen Browser-Hersteller um die Gunst der Benutzer – seinen An-fang fand.

Ein wichtiger Schritt war die Standardisierung von JavaScript als ECMAS-cript (ECMA-262) durch die ECMA (European Computer Manufacturers As-sociation) in Zusammenarbeit mit Netscape. Seit April ist ECMAScript eineISO-Norm: ISO/IEC 16262:1998 Information technology – ECMAScript lan-guage specification. (vgl. Wikipedia [68])

JavaScript existiert in Form mehrerer Implemetierung. In der nachfolgendenTabelle 3.3 sind die wichtigsten JavaScript-Engines aufgelistet.

Name Herkunft BrowserSpiderMonkey Mozilla Netscape, FirefoxTraceMonkey Mozilla Firefox 3.5

V8 Google Chrome, Chrome mobileSquirrelFish 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 dieserRichtung in letzter Zeit stark verbessert hat. (vgl. Abb. 3.4)


Abbildung 3.4: JavaScript Benchmark SunSpider(Quelle: Microsoft [37])

Ein wichtiger Meilenstein des Web 2.0 ist die AJAX-Technik (Asynchro-nes JavaScript und XML), welche dynamischen Nachladen von Inhalten er-laubt. Erst seitdem Webseiten zur Laufzeit verändert werden können ohnedass es eines Roundtrips bedarf, nähern sich Web-Anwendungen immer mehrden Desktop-Anwendungen an. In den letzten Jahren haben auch JavaScript-Frameworks immer mehr an Bedeutung gewonnen, da sie eine plattformüber-greifende Lösung für Entwickler bieten und viele JavaScript-Konstrukte ver-einfachen und abstrahieren. Einige bedeutende Frameworks sind beispielsweiseMootools, jQuery, Dojo und ExtJS.

3.1.2.2 JSON

“JSON (JavaScript Object Notation) is a lightweight data-interchangeformat. It is easy for humans to read and write. It is easy for machi-nes to parse and generate. It is based on a subset of the JavaScriptProgramming Language” json.org [31]

JSON ist ein von Douglas Crockford spezifiertes, auf JavaScript-basiertes For-mat zum Datenaustausch. Dabei hat JSON aufgrund der Notation wenigerOverhead als XML und es existieren Implementierung für fast jede Program-miersprache.


JSON ist besonders bei AJAX-Requests weit verbreitet und hat inzwischenXML – als X in AJAX – weitestgehend ersetzt. Da JSON immer valides Ja-vaScript ist, lässt sich mit einem einfachen “eval” ein JavaScript-Objekt erzeu-gen. Aufgrund von Sicherheitsrisiken sollte man aber dennoch auf einen Parserzurückgreifen um möglichen Schadcode zu enttarnen.

3.1.2.3 DOM (Document Object Model)

“The Document Object Model is a platform- and language-neutralinterface that will allow programs and scripts to dynamically accessand update the content, structure and style of documents. The do-cument can be further processed and the results of that processingcan 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 dy-namisch zu ändern. Die Implementierung der plattform- und sprachenunab-hängigen DOM-Spezifikation ist eine Sammlung von Klassen, Methoden undAttributen. Seit 1998 ist DOM ein Standard des W3C. (vgl. W3C [59])

3.1.3 CSS3

“CSS is the language for describing the presentation of Web pages,including colors, layout, and fonts. It allows to adapt the presen-tation to different types of devices, such as large screens, smallscreens, or printers. CSS is independent of HTML and can be usedwith any XML-based markup language. The separation of HTMLfrom CSS makes it easier to maintain sites, share style sheets acrosspages, and tailor pages to different environments. This is referredto as the separation of structure (or: content) from presentation.”W3C [57]

Cascading Stylesheets (CSS) bestimmen das Aussehen von Webseiten und sor-gen für eine saubere Trennung der Auszeichnung (HTML) und der Stil-Formate(CSS-Regeln). CSS 1.0 wurde 1996 in Form einer Recommendation veröffent-licht und ist in nahezu allen Browsern vollständig implementiert. CSS 2.0 folgte1996, wobei die Implemetierung bis heute nicht in allen Browsern in vollemUmfang erfolgt ist. Seit 2000 wird an CSS3 gearbeitet, wobei diese Spezifikati-on modular aufgebaut ist und die Entwicklung der Teilbereiche einem eigenenZyklus folgt.

3.2. FRAMEWORKS 35

3.2 Frameworks

Es gibt zahlreiche Frameworks mit unterschiedlichen Ansätzen und Zielplatt-formen: Web-Application-Frameworks erleichtern die Programmierung vonWeb-Apps und stellen Hilfsfunktionen und vorgefertige UI-Elemente bereit. Wobeisogenannte Hybrid-Frameworks die Erstellung von nativen Apps ermöglichen,die teilweise auf Web-Apps aufsetzen. Andere Frameworks bieten eine eigeneAPI auf Basis einer Web-Sprache, um native Apps zu entwickeln. Man kanndiese Frameworks somit grob in 3 Kategorien einteilen, wobei die Abgrenzungteilweise fließend verläuft:

Web-Application-Framework (Web-App-Framework – Ziel: Web-App)Web-Application Frameworks basieren auf reinen Web-Standards in Form vonHTML5, JavaScript und CSS3. Das Ergebnis solcher Frameworks ist eineHTML5-standardkonforme Web-App, die über eine Website oder einen Web-App-Store verbreitet werden kann. Zum Funktionsumfang gehören dabei meistzahlreiche UI-Komponenten und JavaScript-Hilfsfunktionen (z. B. für die Da-tenbeschaffung)

Cross-Compiler-Framework (Hybrid-Framework – Ziel: Native App)Cross-Compiler-Frameworks setzen meist auf eine populäre Web-Sprache wiebeispielsweise JavaScript oder Ruby, um mit dieser die gesamte Applikationzu entwickeln. Zusätzliche Technologien wie HTML oder CSS werden nichtbenötigt. Ziel dieser Frameworks ist es die Programmiersprache der nativenApp-Entwicklung durch eine bekannte Web-Sprache zu ersetzen und einenplattformübergreifenden Compiler bereitzustellen. Die finale App wird dannkompiliert und ist nur als native App nutzbar. Ein Einsatz der App in Formeiner Web-App ist nicht möglich, da es sich bei der API nicht um einen Stan-dards handelt, sondern Framework-spezifische Schnittstellen verwendet wer-den.

Wrapper-Framework (Hybrid-Framework – Ziel: Native App))Wrapper-Frameworks sind als Ergänzung für bestehende Web-Apps zu verste-hen. 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 Appzu kompilieren ohne etwas am Quelltext der Web-App zu ändern. Zusätzlichermöglicht beispielsweise PhoneGap den Zugriff auf native Systemfunktionenper JavaScript-Schnittstellen um eine Web-App noch besser an die Plattfor-men anzupassen und Funktionen zu nutzen, die über HTML5 momentan nochnicht verfügbar sind.


3.2.1 Web-Application-Frameworks

3.2.1.1 Sencha Touch

“Sencha Touch, the first HTML5 mobile JavaScript framework thatallows you to develop mobile web apps that look and feel native oniPhone and Android touchscreen devices, has just hit the big 1.0.”Sencha [51]

Sencha Touch basiert auf HTML5, CSS3 und JavaScript. Wobei die Entwick-lung der Oberfläche, als auch der Logik in JavaScript erfolgt, und es für ver-schiedene UI-Komponenten JavaScript-Klassen gibt, die schließlich HTML ge-nerieren. Die Oberfläche lässt sich mit CSS sehr gut anpassen und das Einfügeneigener CSS-Klassen ist jederzeit möglich.

Da Sencha Touch auf dem JavaScript-Framework ExtJS basiert, gibt es ei-ne umfangreiche Funktionssammlung um die Anwendungsentwicklung zu er-leichtern: Die Datenbeschaffung erfolgt beispielsweise per AJAX oder JSONP.Außerdem gibt es zahlreiche UI-Komponenten, die optisch an die mobilen Ge-räte angepasst wurden. Die erstellen Apps sind standardkonform nach HTML5und CSS3, wodurch ein Deployment in Form einer Web-App jederzeit möglichist. Die Anwendungsentwicklung erfolgt programmatisch, so dass sämtlicheElemente und die passende Logik mit JavaScript entwickelt werden und keinHTML oder CSS geschrieben werden muss. Sencha-Touch lässt sich auch mitanderen Frameworks kombinieren (vgl. Sencha [51]).

3.2.1.2 jQuery Mobile

“A unified user interface system across all popular mobile deviceplatforms, built on the rock-solid jQuery and jQuery UI foundation.Its lightweight code is built with progressive enhancement, and hasa flexible, easily themeable design.” jQuery mobile [41]

jQuery Mobile setzt auf dem bekannten JavaScript-Framework jQuery aufund ist momentan erst im Alpha-Stadium. Da die Community des jQuery-Frameworks sehr groß ist und es zahlreiche Sponsoren (u.a. Nokia, BlackBer-ry, Palm) für das junge Projekt gibt, ist es wahrscheinlich, dass es in naherZukunft eine wichtige Rolle spielen wird.Dabei setzt die mobile Version komplett auf Web-Standards auf Basis vonHTML, CSS und JavaScript. Neben zahlreichen UI-Komponenten und Event-Handling für die Touch-Bedienung gibt es auch Effekte und Hilfsfunktionenfür Ajax-Requests. jQuery Mobile setzt im Gegensatz zu Sencha Touch starkauf einen deklarativen Ansatz: D. h. die Programmierung erfolgt innerhalbdes HTML-Markups, wodurch entsprechende JavaScript-Methoden angesteu-ert werden (vgl. jQuery mobile [41]).

3.2. FRAMEWORKS 37

3.2.2 Cross-Compiler-Frameworks

3.2.2.1 Appcelerator Titanium Mobile

“Titanium translates your hard won web skills into native applicati-ons that perform and look just like they were written in Objective-C[iPhone and iPad] or Java [Android]. With over 300 APIs, a thri-ving developer community, and the support you need, you can buildapplications that are more social, local, media rich, interactive, andextensible.“ Appcelerator [1]

Titanium Appcelerator Mobile setzt mit einer eigenen IDE ganz auf JavaScriptund unterstützt im Moment Android, iOS und BlackBerry-OS. Die kompletteApp wird in JavaScript geschrieben und zur Laufzeit auf die nativen API-Schnittstellen abgebildet: Somit ist die ganze Logik, aber auch die Oberflächekomplett in JavaScript geschrieben – Es wird kein HTML oder CSS für dieDarstellung benötigt wird.

Diese Architektur bietet eine bessere Performance als bei reinen Web-Appsauf HTML-CSS-Basis, wobei das Deployment nur über die plattformspezifi-schen Wege möglich ist und ein Veröffentlichung in Form einer mobilen Web-seite nicht möglich ist. Titanium Appcelerator Mobile setzt somit nicht aufHTML5 auf, sondern arbeitet mit einer eigenen API, die zwar auf Basis derApache-Lizenz frei verfügbar, jedoch nach einem eigenen Standard arbeitet.(vgl. Appcelerator [1])

3.2.2.2 Rhodes

“Rhodes is an open source framework to rapidly build native ap-ps for all major smartphone operating systems (iPhone, WindowsMobile, RIM, Symbian and Android). These are true native deviceapplications (NOT mobile web apps) which work with synchroni-zed local data and take advantage of device capabilities such asGPS, 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 Andro-id, iOS und BlackBerry auch Windows Mobile und Symbian. Mit wichtigenFeatures wie Synchronisation, einem ORM (Object Relational Mapper) unddes Model-View-Controller Paradigmas bietet Rhodes eine großen Funktions-umfang.

Wie auch bei Titanium ist der Rhodes-Kern als Open-Source verfügbar.Die


API ist eine Eigenentwicklung – somit basiert Rhodes nicht auf offenen Stan-dards. Damit ergeben sich auch dieselben Nachteile: Rhodes-Apps können nichtals Web-App deployed werden und sind an die Vertriebsformen der jeweiligenPlattformen gebunden (vgl. Rhomobile [47].

3.2.3 Wrapper-Frameworks

3.2.3.1 PhoneGap

“PhoneGap is an open source development framework for buildingcross-platform mobile apps. Build apps in HTML and JavaScriptand still take advantage of core features in iPhone/iPod touch,iPad, Google Android, Palm, Symbian and Blackberry SDKs.” Pho-neGap [45]

PhoneGap unterscheidet sich von Rhodes und Titanium, da es sich nicht umein komplettes Application-Framework handelt, sondern vielmehr um einenWrapper, der eine bestehende Web-App als “native App” verfügbar macht undnative Schnittstellen auf Basis von JavaScript repliziert.

PhoneGap bietet für nahezu jede Plattform ein vorgefertigtes Projekt für diepassende IDE: Für iPhone-Apps gibt es eine Xcode-Vorlage, wobei für Androidein Eclipse-Projekt zum Download steht. Diese Projekt-Templates stellen dieminimale Struktur der App in Form eines Web-Views dar, in welchen die Web-App eingebunden wird. Zusätzlich gibt es eine JavaScript API, die zahlreichenative Schnittstellen zur Verfügung stellt. So ist es möglich per JavaScript aufdie Kamera der Geräte zuzugreifen ohne Objective-C, bzw. Java zu schrei-ben. Diese Projekte lassen sich dann als native Apps exportieren und über diejeweiligen Vertriebswege veröffentlichen (vgl. PhoneGap [45]).

Kapitel 4

Bewertung

Nach der Ausführung der App-Typen und Frameworks, werden diese nun zurbesseren Vergleichbarkeit mithilfe eines Bewertungsverfahrens gegenüberge-stellt. Diese Bewertung kann dabei helfen, die geeigneten Ansätze für Projektezu wählen und sich einen objektiven Überblick über die Vor- und Nachteile derAnsätze zu verschaffen.

4.1 Kriterienkatalog

Um die verschiedenen Ansätze der plattformübergreifenden App-Entwicklungzu bewerten ist es wichtig messbare Kriterien festzulegen, anhand derer danndie Einschätzung erfolgen kann. Diese Kriterien setzen sich sowohl aus tech-nischen, als auch aus betriebswirtschaftlichen Punkten zusammen. Insgesamtgibt 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 deszu verwendenden Ansatzes dienen.

39

40 KAPITEL 4. BEWERTUNG

Um eine übersichtliche und nachvollziehbare Bewertung zu ermöglichen,gliedert sich diese in drei Stufen:

Zeichen Bedeutung− Kriterium wird erfüllt2 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 zugestalten, 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 anhandkonkreter Frameworks ist machbar, jedoch im Rahmen der Arbeit nicht um-gesetzt. Die Einschätzung erfolgt somit pauschal je App-Art. Sofern sich Fra-meworks innerhalb einer App-Art in ihrer Bewertung stark voneinander unter-scheiden, so ist eine aufgeschlüsselte Bewertung in Form einer Liste angegeben.

Eine Gewichtung des Kritierenkatalogs ist im Rahmen dieser Arbeit nicht rea-lisiert. Je nach Anforderungen der App-Entwicklung lässt sich aber eine grobeGewichtung ableiten, die anhand der Aufschlüsselung leicht anwendbar ist.

Abbildung 4.1: Kriterienkatalog: Legende(Quelle: Eigene Abbildung)

4.2. KRITERIEN 41

4.2 Kriterien

4.2.1 Technisch

4.2.1.1 Unterstützte Plattformen

Web-Browser+ Alle wichtigen Mobile- und Desktop-Browser werden unterstützt2 Alle wichtigen Mobile-Browser werden unterstützt− Keine Browser-Unterstützung

Feature-Phones+ UMTS und GPRS Feature-Phones werden unterstützt2 UMTS-Feature-Phones werden unterstützt− Keine Unterstützung von Feature-Phones

Smartphones+ Android, iOS, BlackBerry und weitere werden unterstützt2 Mindestens eine Smartphone-Plattform wird unterstützt− Smartphones werden nicht unterstützt

Tablets+ Die wichtigen Tablet-Plattformen werden unterstützt (iOS, Android)2 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übergreifen-den Entwicklung auf den ersten Blick das wichtigste Kriterium. Dabei denktman bei Apps meistens an Smartphones und Tablets, allerdings sind Feature-Phones und der Web-Browser nicht zu vernachlässigen: So verfügen aktuel-le Feature-Phones meist über einen ausgereiften Browser, welcher Web-Appsunterstützt und uneingeschränktes Surfen ermöglicht. Mindestens ein Web-Browser ist auf sehr vielen Geräten installiert, dieser dient als Plattform fürWeb-Apps und ist damit als universelle Plattform der App-Entwicklung vongroßer Bedeutung. (vgl. Kapitel 4.2)

Die Eröffnung des Chrome-Web-Stores (Google) im Dezember 2010 zeigt wiewichtig 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.


Abbildung 4.2: Kriterienkatalog: Plattformunterstützung(Quelle: Eigene Abbildung)

Die zweite Möglichkeit sind gepackte Apps, die zusätzlich noch Zugriff aufdie Google Chrome Extension APIs haben und lokal beim Benutzer abgelegtwerden. Zusätzlich bietet Google die Möglichkeit kostenpflichtige Apps anzu-bieten. (vgl.Google [18])

4.2. KRITERIEN 43

4.2.1.2 Plattform-Ressourcen

Hardware+ Kamera, GPS, Beschleunigungssensor und mehr werden unterstützt2 Mindestens eine Hardware-Komponente wird unterstützt− Kein Hardware-Zugriff möglich

Software+ Zugriff auf Kontakte, den Kalender und Benachrichtigungen2 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 Appeine stark unterschiedliche Gewichtung: Bei Spielen ist es oft wichtig Zugriffauf die Sensoren der Plattform zu haben, Business-Anwendungen setzen dabeimehr auf Software-Schnittstellen und brauchen beispielsweise Zugriff auf dasAdressbuch 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 teilweiseZugriff auf die Plattform möglich was zu einer mittleren Wertung führt. KeinZugriff führt zu einer negativen Bewertung.


Prinzipiell bieten native Apps den kompletten Zugriff auf Hard- und Software-Schnittstellen (+).

Hybrid-Apps haben ebenfalls einen relativ umfangreichen Zugriff, da die nati-ven Schnittstellen über entsprechende Wrapper repliziert werden (Hardware:+, Software: 2 ).

Bei Web-Apps ist der Hardware-Zugriff momentan nur teilweise möglich: Soist ein Zugriff auf den GPS-Sensor bereits problemlos möglich und Apple bie-tet seit iOS 4.2 Zugriff auf den Beschleunigungs- und Lagesensor. Auch wennmit der Local-Devices-API (HTML5) bald mehr Zugriff möglich sein soll, istmomentan beispielsweise noch kein Zugriff auf die Kamera möglich. Software-Schnittstellen sind bei Web-Apps momentan noch nicht verfügbar, allerdingsist es möglich Benachrichtigungen auf JavaScript-Basis selbst zu implementie-ren (Hardware: 2 , Software: −).

4.2.1.3 Performance

+ Flüssige Bedienung, Schnelle Animationen2 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 durchden Touchscreen sollte schnell und flüssig ablaufen, Hintergrundprozesse soll-ten die Geschwindigkeit einer App nicht beeinträchtigen.

4.2. KRITERIEN 45

Die Messbarkeit der Geschwindigkeit ist dabei nicht ohne weiteres mög-lich, da immer auch eine Abhängigkeit zur verwendeten Hardware, also demjeweiligen Gerät besteht. Eine ausführliche Messung mit mehreren Gerätenund Plattform-Versionen ist daher im Rahmen dieser Arbeit nicht realisierbar.Die Messung der Performance erfolgt anhand der Oberfläche auf den mir zurVerfü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 nativenPlattform (iOS, Android) immer am besten, da die nativen Schnittstellen aufdie Plattform optimiert sind und keine Abstraktion nötig ist. (+)

Hybrid-Apps unterscheiden sich in ihrer Performance sehr stark, je nachdemwelches Framework eingesetzt wird: Wenn die Oberfläche durch native Kom-ponenten generiert wird, ist die Performance annähernd so gut wie bei nativenApps (Titanium Appcelerator Mobile). Setzt das Hybrid-Framework auf ei-ne gewrappte Web-App (PhoneGap), so leitet sich die Performance von derverwendeten Web-App ab (2).

• Titanium Appcelerator: Native Komponenten (+)

• Rhodes: Native Komponenten (+)

• PhoneGap: Web-App Komponenten (2)

• Sencha Touch: Web-Komponenten (2)

• jQuery mobile: Web-Komponenten (2)

Bei Web-Apps hängt es sehr stark davon ab wie komplex die Oberfläche ge-staltet wurde und ob es sich um sauberen CSS, HTML und JavaScript-Codehandelt. 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 eineetwas schlechtere Performance liefern. Insgesamt ist die Performance bei Web-Apps sehr abhängig vom verwendeten Browser, der wiederum von der nativenPlattform und der verwendeten Hardware abhängt (2).

PhoneGap bietet eine sehr offene Architektur und es ist möglich durch Erwei-terungen auch auf native Komponenten zuzugreifen. So lässt sich beispielsweisedie Hauptnavigation mit nativen UI-Elemente realisieren, wobei der eigentlicheInhalt in Form einer Web-App aufgebaut ist. Da diese Erweiterungen nicht fürjede Plattform in selbem Maße zu Verfügung stehen, werden diese im Rahmender Bewertung vernachlässigt.


4.2.1.4 Offline-Ressourcen

+ Umfangreicher Offline-Support (Daten und Dateien)2 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 je-weils besonders wichtig sind die Entwicklung von Apps: Es sollte möglich seinden Quelltext, bzw. die ausführbare App direkt auf der Plattform abzulegen:Somit kann diese auch gestartet werden, falls keine Verbindung zum Internetbesteht. Des Weiteren sollte es möglich sein auch Daten lokal abzulegen: Ei-nerseits kann man eine App somit auch offline nutzbar machen und ggf. Datenbei Verbindungsaufbau synchronisieren, andererseits kann ein Offline-Speicherauch für das Caching verwendet werden, um die Apps performanter zu machen.

Anwendungs-CodeDie Offline-Fähigkeit der Applikation an sich ist sowohl bei nativen Apps, alsauch bei Hybrid-Apps von Haus aus gegebenen: So sind alle Dateien in Formeiner gepackten App lokal auf dem Gerät abgelegt (+).Web-Apps hingegen sind erst seit HTML5 in der Lage über ein so genanntesManifest-File eine Definition zu liefern, welche Dateien lokal abgelegt werdensollen (2).

4.2. KRITERIEN 47

Auszug auf dem roomieplanet-mobile Manifest

Algorithmus 4.1 Cache Manifest

1 CACHE MANIFEST2 CACHE:3 . / r e s o u r c e s / themes / images / d e f a u l t / t i p . png4 . / r e s o u r c e s / themes / images / d e f a u l t / check . png5 . . .6 NETWORK:7 . / mob i l e . php8 ht tp : //roomiepla.net/data/910 # Hash : 8 a3a f7 f1936 f4225 f12eb0667b194c09

DatenhaltungDie lokale Ablage von Daten ist bei nativen Apps eine zwingende Vorausset-zung und somit auch in vollem Umfang möglich (+).Hybrid-Apps können entweder über Wrapper auf die Datenspeicher der na-tiven Plattform zugreifen oder über die Speichermöglichkeiten von HTML5-verwandten Spezifikationen zurückgreifen (+). Web-Apps können über folgen-de neu eingeführten APIs Daten lokal ablegen (HTML5-verwandte Spezifika-tionen):

• LocalStorage – Persistenter Key-Value-Speicher

• SessionStorage – Persistenter Key-Value-Speicher (über die Dauer einerSession)

• Indexed DB, (WebSQL) – Datenbanken

LocalStorage – roomieplanet mobile (Safari Web-Developer Tools):

Abbildung 4.6: LocalStorage – roomieplanet mobile (Safari Web-DeveloperTools)

(Quelle: Eigene Abbildung)


4.2.1.5 Multimedia

+ Umfangreiche Video und Audio Unterstützung2 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ütz-ten Formate beschränkt, die Performance wird nicht berücksichtigt.

Die Unterstützung von Multimedia ist bei nativen Apps sehr umfangreichmö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 “<vi-deo>” Tags der HTML5-Spezifikation. Je nach Browser und Plattform unter-scheidet sich allerdings die Anzahl und Art der unterstützten Formate. Insge-samt ist die Unterstützung im Moment als gut anzusehen, da viele wichtigeCodecs 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])

4.2. KRITERIEN 49

4.2.1.6 Benachrichtigungen

+ Push-Messages und weitere Benachrichtigungen sind möglich2 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 Anwen-der auf dem Laufenden halten möchten. Mit Push-Benachrichtigungen ist diessehr einfach realisierbar (+), gibt es andere Arten der Benachrichtigung, so istdas Kriterium zumindest teilweise erfüllt (2).

Bei nativen Apps gibt es je nach Plattform unterschiedliche Arten der Be-nachrichtigung. Bei iOS und Android gibt es die Möglichkeit so genanntePush-Benachrichtigungen an die Anwender zu schicken: Auch wenn die App imHintergrund nicht läuft, lassen sich so Nachrichten an den Anwender schicken.Auch Benachrichtigungen über Textmeldung innerhalb der Anwendung sindmöglich, wobei diese durch akustisches oder haptisches Feedback unterstütztwerden können (Ton, Vibration) (+).

Hybrid-Apps bieten ebenfalls die Möglichkeit diese Push-Nachrichten dernativen Apps zu nutzen. Weitere Möglichkeiten der Benachrichtigung sindabhängig vom verwendeten Framework, allerdings sind Textmeldungen meistüber die native UI oder zumindest eine ähnliche UI implementiert. Akustischesund haptisches Feedback sind möglich (+).

Web-Apps bieten keine Unterstützung für Push-Benachrichtigungen, auchwenn momentan bereits an einer ähnlichen Lösung gearbeitet wird. NormaleBenachrichtigungen sind über die Browser-Elemente per JavaScript möglich.Zusätzlich bieten UI-Frameworks wie Sencha Touch mit CSS und HTML ge-nerierte Benachrichtigungselemente, die per JavaScript gesteuert werden (2).


4.2.1.7 Lizenzierung

+ Frei von Lizenzen, Open Source Lizenz (kommerz. Nutzung erlaubt)2 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 eineRolle, wenn ein Framework an die eigenen Bedürfnisse angepasst werden soll.Die Bewertungs-Skala geht daher von möglichst freier Nutzung (+) hin zur pro-prietären Lösung (-), die weniger Möglichkeiten für eigene Anpassungen bietet.

Reine Web-Apps basieren auf offenen Standards und sind daher frei vonLizenzen (+).

Native Apps sind an die jeweiligen Bedingungen der Plattform gebundenund 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 kom-merzielle Nutzung) (2)

• Appcelerator Titanium: Apache Public License v2 (+)

4.2. KRITERIEN 51

4.2.2 Entwicklung

4.2.2.1 Community

+ Große Community, viele Ressourcen (Blogs, Wikis, Foren)2 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 Fo-ren bieten kostenlose Hilfestellung und eine große Community bedeutet meistauch 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ß undes existieren neben offiziellen Dokumentation auch zahlreiche Bücher, Forenund Tutorials.Die Größe der Communites unterscheidet sich bei Hybrid-Frameworks teilweisestark:

• Sencha Touch: Großes Forum (+)

• PhoneGap: Aktive Google-Gruppe, Wiki (+)

• Rhodes: Zugang erst nach Registrierung (−)

• Titanium Appcelerator: Eigenes Community System (2)

• 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 vertre-ten.


4.2.2.2 Tools

+ IDE-Support (z. B. Eclipse)2 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-Entwicklungerheblich. Eine Integration von Debuggern und Dokumentation hilft die Über-sicht zu bewahren und vereint mehrere Prozesse an einer zentralen Stelle. Umsobesser 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 Basisvon Eclipse (+).

Hybrid-Apps sind sehr unterschiedlich gestrickt und daher ist auch die Tool-Unterstützung unterschiedlich: (+)

• PhoneGap: Erstellt native Projekte – Nutzung der Plattform eigenenIDE (XCode, Eclipse, etc.)

• Titanium Appcelerator: Eigene IDE

• Rho Mobile: Eigene IDE

Sencha Touch und jQuery mobile basieren auf Web-Technologien und die mög-lichen Tools sind generell für Entwicklung von Web-Anwendungen geeignet. Sogibt es zahlreiche Editoren und IDEs für HTML und JavaScript, jedoch ist dasDebugging und die IDE-Integration der Frameworks oft nicht optimal, was zueiner mittleren Wertung führt (2).

4.2. KRITERIEN 53

4.2.2.3 Wiederverwendbarkeit

+ Der Großteil des Quelltexts kann wieder verwendet werden(plattformübergreifend)

2 Teile des Quelltexts können wieder verwendet werden(plattformübergreifend)

− Quelltext kann nicht wieder verwendet werden, oder nur für dieselbePlattform

Tabelle 4.11: Kriterienkatalog: Wiederverwendbarkeit

Abbildung 4.12: Kriterienkatalog: Wiederverwendbarkeit(Quelle: Eigene Abbildung)

Wiederverwendbarkeit ist im Rahmen des Kritierenkatalogs prinzipiell dieMöglichkeit bestimmte Quelltext-Abschnitte für Projekte auf weiteren Platt-formen zu nutzen. Je portabler der Quelltext ist, desto besser ist die Bewertungder Wiederverwendbarkeit (Code-Re-Use)

Hybrid-Apps auf Basis eines Web-View-Containers (PhoneGap) bieten hin-sichtlich der Wiederverwendbarkeit einen großen Vorteil: Der komplette Quell-text einer Web-App kann als Grundlage einer Hybrid-App dienen und durchVererbung und Überschreiben von Methoden lässt sich mit einer einheitlichenCode-Base arbeiten, die sowohl für Hybrid- als auch für die Web-App verwen-det werden kann (+).Eine Hybrid-App läuft theoretisch auf mehreren Plattformen mit identischemQuelltext, 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 (2)

• Web-Apps: Der Quelltext kann als Grundlage einer Hybrid-App genutztwerden (Web-Container) (+)


4.2.2.4 Dokumentation

+ Umfangreiche Dokumentation: Aktuelle Tutorials, Manual, Bücher2 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 Softwa-reentwicklung 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 verwen-deten Framework, aber im Schnitt als mittelmäßig anzusehen (2):

• Sencha Touch: Gute API-Dokumentation, Aktuelles User-Forum (+)

• PhoneGap: Schlechte API-Dokumentation, Große Google-Gruppe (2)

• 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ücherzu diesem Thema erscheinen ist davon auszugehen dass es in nächster Zeit sehrumfangreiche Literatur und Dokumentation geben wird.

4.2. KRITERIEN 55

4.2.3 Usability

4.2.3.1 Look & Feel

+ Natives User Interface – Erwartungskonform2 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 Be-dienelemente unterscheiden sich von den herkömmliche Komponenten der Desk-top-Anwendungen. Die native App-Entwicklung bietet eine große Palette anKomponenten, die sich bereits etabliert haben und für Nutzer eine gewisse Er-wartungskonformität bieten. Je ähnlicher die verwendeten Komponenten dennativen Komponenten sind, desto besser ist die Bedienbarkeit und somit dieWertung.

Jede native Plattform bietet Standard-UI-Komponenten, die für den Anwen-der leicht zu verstehen sind. Durch die Verbreitung dieser nativen Oberflächenist das Verhalten der Komponenten bei Anwendern bereits bekannt, auch dieBedienung 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, diesich meist an den nativen orientieren (Sencha Touch, jQuery mobile) (2).

• Titanium Appcelerator: Einsatz nativer UI-Komponenten (+)

• Rhodes: Native UI-Komponenten (+)

• Sencha Touch: Eigene UI-Komponenten (2)


• jQuery Mobile: Eigene UI-Komponenten (2)

• PhoneGap: Basierend auf Web-App, Nutzung nativer Komponenten mög-lich

Wenn Web-Apps ohne den Einsatz von Frameworks realisiert werden, so müs-sen auch die mobilen UI-Komponenten selbst implementiert werden. Standard-Web-Elemente (Checkbox, Radiobuttons, etc.) eignen sich nur bedingt für diemobile Nutzung mit Touchscreens.

Nutzt man hingegen ein Web-App-Framework wie Sencha Touch oder jQuerymobile, so sind die wichtigsten UI-Elemente bereits vorgefertigt (2).

Da man im Regelfall auf ein Framework zurückgreifen wird, sind Web-Appsim Rahmen dieser Auswertung als “quasi-nativ” gewertet (2).

Abbildung 4.15: Native UI-Komponenten (iPhone)(Quelle: Eigene Abbildung)

4.2. KRITERIEN 57

4.2.4 Sicherheit

4.2.4.1 Verschlüsselung

+ Vollständige Verschlüsselung der Daten und der Verbindung möglich2 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 abzusi-chern und sowohl Daten, als auch Verbindungen zu verschlüsseln.

Native Apps lassen sich einfach verschlüsseln und auch die Datenübertragungkann über eine verschlüsselte Verbindung erfolgen (+).

Hybrid-Apps bieten je nach Framework unterschiedliche Möglichkeiten derVerschlüsselung, eine verschlüsselte Datenübertragung oder die Datenverschlüs-selung ist aber meist möglich (2).

Web-Apps bieten die Möglichkeit einer verschlüsselten Datenübertragung perSSL. Da Web-Apps direkt im Browser ausgeführt werden, ist der Quelltextjederzeit lesbar. Eine Verschlüsselung der lokalen Daten ist aber möglich (Lo-calStorage, WebSQL). Außerdem sind die lokalen Datenspeicher der HTML-verwandten Spezifikationen (LocalStorage, WebSQL) gegen den Zugriff vonanderen Domains aus abgeschirmt, es ist also nicht möglich auf die Daten ei-ner fremden Web-App zuzugreifen. Insgesamt fehlt es aber in diesem Bereichnoch an verbindlichen Standards und Implementierungen, weshalb die Web-Apps nur eine mittlere Bewertung erhalten (2).


4.2.4.2 Remote-Wartung

+ Echtzeit-Monitoring der App, Remote-Deaktivierung möglich2 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, istdie Möglichkeit der Fernwartung für den Kriterienkatalog relevant. Im Fehler-fall sollte es möglich sein, diesen schnell zu analysieren und zu beheben. Inkritischen Fällen ist auch die Deaktivierung aus der Ferne eine wichtige Opti-on, die je nach Art der App von großer Bedeutung sein kann (z. B. KritischerFehler in einer Banking-App).

Je besser die Möglichkeiten der Fernwartung für den Entwickler sind, destobesser ist die Bewertung.

Native Apps lassen sich meist nur in kleinerem Umfang überwachen. So istdie Fehleranalyse und ein schnelles eingreifen oft nicht leicht realisierbar. DieDeaktivierung einer App ist ohne Verzögerung meist nicht möglich. (2)

Hybrid-Apps unterliegen den Bedingungen der jeweiligen Plattform und dieBewertung richtet sich somit nach der nativen Plattform (2).

Web-Apps lassen sich in Form von Webseiten sehr einfach überwachen unddie Fehleranalyse ist in Echtzeit möglich. Die Deaktivierung einer App ist je-derzeit möglich und tritt sofort in Kraft (+).

4.2. KRITERIEN 59

4.2.5 Marketing

4.2.5.1 Werbung

+ In-App-Ads werden unterstützt, Integrierte Lösungen verfügbar2 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 AppWerbung zu schalten. Für viele App-Entwickler ist diese Art der Monetari-sierung eine gute Alternative zu kostenpflichtigen Version, weshalb einer Be-trachtung der Möglichkeiten im Rahmen der Bewertung von Interesse ist.

Native und hybride Apps können Werbe-Elemente integrieren: Dabei gibt es jenach Plattform mehrere Anbieter (z. B. AdMob. AdSense). Apple (iAds) undGoogle (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 zu-rückgreifen. Es gibt zahlreiche Anbieter, jedoch ist die Integration in die Appaufwendiger als bei nativen Apps, da es je nach Framework und Layout um-ständlich sein kann Werbung einzubinden (2).


4.2.5.2 Distribution

Möglichkeiten für Firmen+ Auto. Deployment und Zusatzfunktionen2 Auto. Deployment− Keine zusätzlichen Möglichkeiten für Firmen

Zentraler App Marktplatz+ Verbreitung über mehrere App-Marktplätze möglich2 Verbreitung über genau einen App-Marktplatz möglich− Keine Verbreitung über App-Marktplätze möglich

Unabhängige Verbreitung+ Unabhängige Distribution (Datei, Link)2 Unabhängige Verteilung plattformgebunden möglich− Keine unabhängige Verteilung möglich

Tabelle 4.17: Kriterienkatalog: Distribution

Möglichkeiten für FirmenWenn man Apps für eine Firma entwickelt, ist es besonders wichtig, dieseauch unkompliziert an alle Mitarbeiter ausliefern zu können. Zusätzliche Si-cherheitsfeatures und Wartungsmöglichkeiten sind ein weiterer Pluspunkt, derbesonders im Firmenumfeld eine höhere Bedeutung hat.

• Native App: +

• Hybrid-App: +

• Web-App: 2

Zentraler App-MarktplatzApps werden hauptsächlich über die Plattform-eigenen Marktplätze verbreitet(z. B. Apple: AppStore, Google: Android Market), weshalb erst der Zugang zudiesen Marktplätzen einen Zugang zum Massenmarkt ermöglicht. Manche na-tive Plattform (iOS) erlaubt auch nur einen einzigen kontrollierten Marktplatz,so dass der Zugang die einzige Möglichkeit ist, die App überhaupt anbietenzu können. Auch wenn die meisten nativen Plattformen mehrere Marktplätzezulassen, sind diese Alternativen meist nicht sehr verbreitet.

• Native App: 2

• Hybrid-App: +

• Web-App: −

4.2. KRITERIEN 61

Abbildung 4.19: Kriterienkatalog: Distribution(Quelle: Eigene Abbildung)

Unabhängige VerbreitungEine 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 eineWebseite, mehrere Marktplätze oder beispielsweise auch per E-mail verteilen.Bei nativen, und damit auch bei hybriden Apps ist dies abhängig von derPlattform:

• iOS: Nur über den AppStore (−)

• Android: Beliebige Verteilung als Datei, verschiedene Marktplätze (2)

• BlackBerry: Beliebige Verteilung, verschiedene Marktplätze (2)

Web-Apps können in Form einer Webseite (also per Link) direkt über das Webverbreitet werden, ohne dass es einer Installation bedarf. Sowohl Google, alsauch Apple bieten eine Auflistung solcher Web-App Seiten an. Eine Verteilungin Form einer gepackten Datei ist momentan nicht standardisiert, jedoch bietetGoogles Chrome Web-Store eine Möglichkeit Web-Apps als Datei anzubieten(momentan nur für Google Chrome) (+).


4.2.5.3 Monetarisierung

+ Sichere Zahlungsabwicklung, Freie Preisgestaltung, Ad-Support2 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 Zah-lungsabwicklung und eine Lizenzverwaltung. Zentrale Marktplätze bieten die-sen Service, wobei dafür ein fester Anteil des Verkaufspreises als Provisionan den Marktplatz-Betreiber zu zahlen ist. Obwohl bei einer Abwicklung übereigene Systeme geringere Abgaben zu zahlen sind und die Freiheiten der Imple-mentierung größer sind, so werden die meisten Apps bei großen Marktplätzenverkauft, weshalb eine separate Abwicklung für viele potentielle Kunden ver-wirrend sein könnte – Deshalb gibt es eine negative Bewertung in diesem Falle.

Native Apps werden hauptsächlich über einen zentralen Marktplatz vertrie-ben: Dort gibt es in der Regel eine sichere Zahlungsabwicklung und freie Preis-gestaltung für die Entwickler. Je nach Marktplatz wird ein bestimmter Pro-zentsatz 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 geltendieselben Bedingungen (+).

Web-Apps werden in Form einer Webseite vertrieben und zentrale Markt-plätze sind noch die Ausnahmen (siehe Chrome Web Store). Die Zahlungsab-wicklung ist somit selbst zu regeln und die Prüfung der Lizenzen muss selbstimplementiert werden. Vorteilhaft ist jedoch dass es dabei keine Abgaben gibt,wie sie bei zentralen Marktplätzen die Regel sind.

4.2. KRITERIEN 63

4.2.5.4 Einschränkungen

+ Keine Einschränkungen (Keine Prüfung)2 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ätzevertrieben werden, ist die Bindung an einen Anbieter und die damit verbun-denen Bestimmungen. So ist es bei manchen Marktplätzen nicht möglich eineApp ohne vorherige Prüfung durch den Marktplatz-Betreiber zu veröffentli-chen (Apple AppStore). Diese Bestimmungen bedeuten teilweise erheblicheEinschränkungen für den App-Entwickler und sind daher wichtig für die Be-wertung. Je weniger Einschränkungen eine Plattform bietet, desto besser istdie Bewertung.

Bei den zentralen Marktplätzen der nativen Plattformen gibt es Richtliniendie eine App erfüllen muss um aufgenommen zu werden. Apple setzt sogar einPrüfverfahren ein, welches jede App durchlaufen muss, bevor diese im haus-eigenen “AppStore” aufgenommen wird. Dieses Prüfverfahren muss auch nachjedem Update durchlaufen werden und verzögert Veröffentlichungen und Up-dates (−).

Hybrid-Apps sind abhängig von der nativen Plattform und es gelten die-selben Bestimmungen (−).

Web-Apps sind prinzipiell frei von solchen Richtlinien. Es gelten dieselbenBestimmungen 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 Browsernder Anwender werden automatisch aktualisiert (+).

Kapitel 5

Implementierung

Nach Analyse und Bewertung, soll nun anhand einer exemplarischen Imple-mentierung die Reife der plattformübergreifenden App-Entwicklung untersuchtwerden. Als Grundlage dient hierbei die bestehende Web-Anwendung Roomie-planet, welche um eine mobile Version erweitert werden soll. Zielplattformender App sind dabei iOS, Android und BlackBerry.

5.1 Motivation

Roomieplanet wird zunehmend mobil genutzt, zusätzlich steigt die Verbreitungvon MIDs bei der Hauptzielgruppe der Studenten momentan sehr schnell. Ob-wohl die bisherige Roomieplanet-Version für den Desktop optimiert wurde, soist diese auf den meisten mobilen Geräten ohne Probleme nutzbar. Allerdingsist die Bedienung und die Darstellung nicht optimal und eine mobile Versionsoll diese Defizite ausgleichen. Der Funktionsumfang ist dabei vorerst auf die-jenigen Funktionen beschränkt, die besonders unterwegs von Bedeutung sind.

Abbildung 5.1: Roomieplanet – Modulübersicht

64

5.2. IST-ANALYSE 65

5.2 Ist-Analyse

5.2.1 Roomieplanet

Abbildung 5.2: Roomieplanet - Logo

Roomieplanet ist eine Web-Anwendung für Wohngemeinschaften, die ander Hochschule Augsburg im Rahmen einer Projektarbeit entstanden ist. Diebestehende Web-Anwendung bietet dabei Möglichkeiten zur Verwaltung vonFinanzen, Terminen, Einkäufen und einen Putzplan. Roomieplanet ist unterwww.roomieplanet.de erreichbar und nach einer Registrierung kostenlos nutz-bar.

Abbildung 5.3: Roomieplanet – Desktop

Momentan wird Roomieplanet von sechs Studenten weiterentwickelt. Ne-ben der Verbesserungen bestehender Module, wird an weiteren Funktionen undneuen Modulen gearbeitet.

66 KAPITEL 5. IMPLEMENTIERUNG

5.2.2 Verwendete Technik

Die bestehende Web-Anwendung – also die Desktop-Version von roomieplanet– basiert auf HTML, CSS und JavaScript. Als Back-End dient PHP auf einemApache-Webserver und eine MySQL Datenbank.

5.2.3 Vorhandene Schnittstellen

Das Front-End setzt stark auf AJAX, weshalb eine HTTP/JSON-API server-seitig zur Verfügung gestellt wird. Diese API lässt sich mit einigen Anpassun-gen auch für die mobile Version nutzen. Die Authentisierung erfolgt dabei perPHP-Session.

5.3 Roomieplanet Mobile

5.3.1 Anforderungsanalyse

Abbildung 5.4: Roomieplanet mobile – Use Case Diagramm(Quelle: Eigene Abbildung)

5.3. ROOMIEPLANET MOBILE 67

Die mobile Version von roomieplanet soll nicht den gesamten Funktionsum-fang der Desktop-Version umfassen, sondern besonders diejenigen Funktionenbieten, die unterwegs besonders wichtig sind (siehe Abbildung 5.4):

Nr. Bezeichnung Beschreibung Akteure1 Anmeldung Der Benutzer kann sich mit

E-mail-Adresse und Passwort amroomieplanet-System anmelden

Benutzer

2 Einkäufeverwalten

Der Benutzer kann Einkäufe auflisten,hinzufügen und als eingekauft markieren

Benutzer

3 Finanzenverwalten

Der Benutzer kann sich eine Übersichtüber die Finanzen auflisten lassen undAusgaben/Überweisungen anlegen

Benutzer

4 Termineauflisten

Der Benutzer kann sich die kommendenzehn Termine auflisten lassen

Benutzer

5 Neuigkeitenauflisten

Der Benutzer kann sich die letzten 15Neuigkeiten auflisten lassen.

Benutzer

Tabelle 5.1: Use-Case Anwendungsfälle

Neben den Use-Cases gibt es weitere technische Anforderungen, die bei derApp-Entwicklung zu berücksichtigen sind:

• Die mobile App soll mindestens iOS und Android als Zielplattformenunterstützen

• Die mobile App soll direkt über das Web erreichbar sein. Über eine ser-verseitige Browser-Weiche soll je nach Browser und Client die richtigeVersion geladen werden

• Die mobile App soll außerdem über die plattform-spezifischen Markplät-ze vertrieben werden

• Insgesamt soll es nur eine Codebase geben (Wartung!)

• Die mobile App soll durch eine erwartungskonforme UI einfach zu bedie-nen sein


5.3.2 Technologieauswahl

5.3.2.1 App-Typ

Bei der Technologieauswahl kam das in Kapitel 4 beschriebene Bewertungs-verfahren noch nicht zum Einsatz, da dieses erst durch Erfahrungen währendder Implementierung entstanden ist. Die Anforderungen an die App sind soklar definiert, dass die Art der Implementierung daraus resultiert: Einerseitssoll die App direkt über das Web erreichbar sein, weshalb sich die Realisierungals Web-App anbietet. Andererseits soll es möglich sein diese auch über dieplattform-spezifischen Marktplätze anzubieten, was zusätzlich für eine Hybrid-App spricht. Um der Forderung nach einer gemeinsamen Code-Base gerecht zuwerden, muss die Hybrid-App auf dem Quelltext der Web-App basieren unddiese in einem nativen “Container” bereitstellen.

5.3.2.2 Verwendete Frameworks

Um die Entwicklung der Web-App zu vereinfachen und eine quasi-native Ober-fläche zu schaffen, wird ein Web-Application-Framework eingesetzt: Mit zahl-reichen vorgefertigten UI-Komponenten und vielen Hilfsfunktionen für die Da-tenbeschaffung bietet sich hierbei Sencha Touch als “HTML5 Application Fra-mework” an. Im Gegensatz zu anderen UI-Frameworks wie jQuery mobile,handelt es sich bei Sencha Touch um ein Framework, welches sich an der na-tiven App-Entwicklung anlehnt. Andere Frameworks setzen oft auf die dekla-rative Definition der UI und Logik innerhalb des HTML-Markups, was be-sonders für angepasste Versionen bestehender Web-Seiten von Vorteil ist. Willman aber eine eigenständige App programmieren, so ist es einfacher sämtli-che UI-Komponenten und die Logik in Form von Objekten zu erstellen. DieProgrammierung beschränkt sich somit größtenteils auf JavaScript und dasHTML-Markup wird im Hintergrund durch Sencha Touch generiert. Anpas-sungen an HTML und CSS sind dabei aber weiterhin möglich, jedoch nichtzwingend nötig.

Um die App auch für die Marktplätze der nativen Plattformen verfügbar zumachen, wird die Web-App mithilfe von PhoneGap zu einer nativen App für je-de unterstützte Plattform. Dabei bietet PhoneGap einen Web-View-Container,in welchen die Web-App abgelegt wird. Zusätzlich bietet PhoneGap weitereSchnittstellen der nativen Plattformen, die Web-Apps normal nicht nutzenkönnen. Der größte Vorteil dieses Ansatzes ist der hohe Grad der Wiederver-wendbarkeit der Quelltexts. Eine bestehende Web-App kann ohne Änderungenin Form eines PhoneGap Projekts zu einer nativen App “kompiliert” werden.Zusätzlich kann man durch Vererbung auch Zusatzfunktionen innerhalb derPhoneGap-App realisieren, ohne die bestehende Code-Base direkt zu verän-dern.

5.3. ROOMIEPLANET MOBILE 69

5.3.2.3 Serverseitige API

Um die zusätzliche serverseitige Implementierung möglichst gering zu halten,wird die bestehende AJAX-API genutzt und um zusätzliche Funktionen er-gänzt und angepasst. Die Datenbeschaffung der mobilen App wird mit AJAXrealisiert, wobei sämtliche Anfragen an eine bestimmte URL gesendet werden(http://mobile.roomieplanet.de/mobile.php). Per GET-Parameter kann mander API die gewünschte Funktion übermitteln, die dann ausgeführt wird undeinen JSON-String als Antwort zurück liefert.

5.3.3 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 eindeu-tige ID

• Footer: Die Navigation in Form eines TabPanels, also einer Leiste mitIcons für jede View

Abbildung 5.5: Roomieplanet UI-Konzept(Quelle: Eigene Abbildung)

Die TabBar zeigt durch eine farbliche Markierung an, welche View momentanaktiv ist. Außerdem sind dort Benachrichtigungen hinterlegt, wie beispielswei-se die Anzahl der offenen Einkäufe der Einkaufsliste. Sencha Touch übernimmt


das Rendering der Komponenten und steuert die Navigation. Der Inhalt wirddynamisch in die jeweiligen Views geladen, welche durch eindeutige IDs an-gesprochen werden können. Die Ausrichtung und Größe der Elemente passtsich automatisch an den zur Verfügung stehenden Platz an, wodurch die Appsowohl 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)

5.4. IMPLEMENTIERUNG - WEB-APP 71

5.4 Implementierung - Web-App

5.4.1 Struktur - Sencha Touch

Sencha Touch besteht aus einer Sammlung von CSS-Stylesheets, darin verlink-ten Bildern und der eigentlichen JavaScript Bibliothek. Die Web-App ist in ei-ner einzigen HTML-Datei definiert, in welche die JavaScript Bibliothek und dieStylesheets eingebunden sind. Wenn man sich auf die Standard-Komponentenbeschränkt, ist es nicht nötig die CSS Dateien anzupassen – Die Anwendungs-entwicklung 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 Anwendungs-entwicklung beginnen - Sencha macht keinerlei Vorgaben für die Aufteilungdes Codes, es bleibt dem Entwickler überlassen wie die Anwendung aufgebautwird. Aus Gründen der Wartbarkeit und Übersicht wird bei der folgenden Im-plementierung versucht Datenbeschaffung, Darstellung und Ablauflogik mög-lichst getrennt zu halten.

Die bestehende HTML-Datei (index.html) wird um weiteren JavaScript-Code ergänzt, welcher aus Gründen der Übersichtlichkeit in mehrere Dateienuntergliedert ist:

• index.js : Initialisierung (Sencha-Touch Instanzierung)

• roomieplanet.js : Roomieplanet-Klasse (Methoden zur Datenbeschaffungund Steuerung)

• templates.js : HTML-Grundgerüste für die Views (Templates mit Platz-haltern)

• 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 alleinnerhalb der Roomieplanet-Klasse realisiert (vgl. Abbildung 5.8).


Abbildung 5.8: Roomieplanet-Mobile Komponentendiagramm(Quelle: Eigene Abbildung)


5.4.2 Initialisierung und Ablauf

In der index.js-Datei wird durch ein Konfigurationsobjekt eine Instanz vonSencha Touch erzeugt (Algorithmus 5.1 Zeile 2). Sobald das Framework fertiginitialisiert ist, wird ein Event (“onReady”) getriggert (Zeile 7), woraufhin dasGrundlayout 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 geladenwurde, werden die Tabs im nächsten Schritt mit Inhalten gefüllt.

Um die Datenbeschaffung kümmert sich die Roomeplanet-Klasse, die inZeile 44 instanziert wird: Dort wird zunächst geprüft ob der Anwender bereitsangemeldet ist und eine gültige Session gestartet wurde. Sollte diese nicht be-stehen, wird das Anmeldeformular eingeblendet. Wenn der Anwender erfolg-reich angemeldet ist, erfolgt die Datenbeschaffung in Form mehrerer parallelerAJAX-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üstegeneriert, 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 ein-deutig zuordnen zu können.

Abbildung 5.9: Roomieplanet mobile – Initialisierung(Quelle: Eigene Abbildung)


Algorithmus 5.1 Sencha Touch – Initialisierung

1 //SENCHA SETUP2 Ext . setup ({3 icon : ’resources/icon.png’ ,4 phoneStartupScreen : ’resources/img/phone_startup.png’ ,5 g lossOnIcon : false ,6 f u l l s c r e e n : true ,7 onReady : function ( ) {8 //MAIN LAYOUT9 //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 u i : ’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 : de fau l t In i tHtml ,29 i conCl s : ’feed’ ,30 c l s : ’tabCard’ ,31 dockedItems : [ {32 . . .33 } ]34 } ,35 . . .36 ]37 }) ;3839 //roomieplanet -class40 roomie . i n i t ( ) ;41 }42 }) ;


Abbildung 5.10: Roomieplanet mobile – Datenbeschaffung(Quelle: Eigene Abbildung)


5.4.3 Datenbeschaffung und Offline-Caching

Im ersten Schritt wird geprüft ob der Browser eine Verbindung zum Internethat: Dazu wird das Attribut “navigator.isOnline“ genutzt, welches den aktuel-len Verbindungsstatus des Browsers dokumentiert.

Sollte des Browser offline sein, so werden die Daten für die entsprechendeView direkt über LocalStorage (Offline-Speicher) geladen und dem Template-Renderer übergeben (vgl. Algorithmus 5.2 Zeile 3 - 7). Wenn der Browseronline ist, so wird ein AJAX-Request ausgeführt um die aktuellen Daten vomServer zu laden (Zeile 11). Ist der Request erfolgreich, so werden die aktuel-len Daten in den Offline-Cache geschrieben (LocalStorage) und anschließendan den Template-Helper übergeben (Zeile 18, 21). Sollte der Request fehl-schlagen, so wird eine Fehlermeldung in der entsprechenden View angezeigt.Die TemplateHelper-Funktion (Aufruf in Zeile 7, 21) spielt dabei eine wich-tige Rolle: Diese Funktion nimmt strukturierte Daten im JSON-Format undgeneriert dann auf Basis eines Templates (vgl. 5.3) fertiges HTML. DieserHTML-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 ( de lay ) {3 i f ( ! this . i sOn l i n e ( ) ) {4 //load offline data5 var data = this . g e tOf f l i n eData (’feed’ ) ;6 //load template7 s e l f . templateHelper ( data , . . . ) ;8 }9 else {10 //live data11 Ext . Ajax . r eques t ({12 . . .13 su c c e s s : function ( response , opts ) {14 //decode to jsonObject15 data=Ext . decode ( . . . ) ;16 //store data offline17 i f ( data ) {18 s e l f . s e tO f f l i n eData (’feed’ , data ) ;19 }20 //apply data to the theme21 s e l f . templateHelper ( data , . . . ) ;22 }23 }) ;24 }


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)


5.4.4 HTML5 Funktionen

Nachdem der grundlegende Ablauf der App beschrieben wurde, werden in die-sem Abschnitt die HTML5-spezifischen Funktionen ausführlicher beschrieben.

5.4.4.1 Offline Web Applications

Um eine Web-App offline nutzbar zu machen, muss die Anwendung selbst lokalabgelegt 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]). Imersten Schritt definiert man sämtliche Dateien, die man für die Ausführungder App braucht, in einer Textdatei namens MANIFEST. Diese Datei bestehtaus 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 imVerzeichnis der Web-App auf und generiert die Liste, der zu cachenden Da-teien. Der NETWORK-Bereich ist innerhalb des Scripts fest vorgegeben undbeinhaltet lediglich den serverseitigen AJAX-Handler (mobile.php). Damit dieMANIFEST-Datei nach Änderungen vom Browser neu geladen wird, befindetsich am Ende der Datei noch ein Kommentar mit der Prüfsumme (MD5) allerzu 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 allebenötigten Dateien heruntergeladen und in einem Application Cache abgelegt.Nun kann man die Web-App per URL auch aufrufen, wenn keine Verbindungzum Internet besteht.

Um eine bessere Übersicht zu bekommen was im Hintergrund passiert unddas Debugging zu verbessern, lassen sich die verschiedenen Events und Kon-stanten der Offline Web Applications nutzen: Über window.applicationCache


hat man Zugriff auf das ApplicationCache Objekt, an das mehrere Events ge-koppelt 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 Seitezeigt die neue Version

5.4.4.2 Persistenter Speicher – LocalStorage

LocalStorage ist ein einfacher Key-Value-Speicher, der persistent im Browserabgelegt wird. Dabei stehen Methoden zur Verfügung die das persistente Spei-chern von String ermöglichen: setItem(), getItem(),removeItem(),clear().

Die Roomieplanet-Datenbeschaffung liefert strukturierte Datenobjekte imJSON-Format zurück, jedoch lassen sich über die LocalStorage-Spezifikationlediglich Strings ablegen. Um diese Einschränkung zu umgehen und das Spei-chern von JSON-Objekten zu ermöglichen, werden zwei Hilfsfunktionen imple-mentiert:

• setObject(in DOMString key, in Object): Legt beliebige JavaScript-Objektelokal ab (identifiziert durch einen eindeutigen String)


• getObject(in DOMString key): Liest JavaScript-Objekte lokal aus (iden-tifiziert durch einen eindeutigen String)

Algorithmus 5.5 HTML5 – Storage Erweiterung

1 //HTML5 Storage prototype extensions2 Storage . prototype . s e tObjec t = function ( key , va lue ) {3 this . s e t I tem ( key , JSON. s t r i n g i f y ( va lue ) ) ;4 }56 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 setObjectund getObject jeweils serialisiert bzw. deserialisiert.

Um eine grundlegende Offline-Funktionalität zur Verfügung zu stellen, wer-den sämtliche JSON-Objekte die vom Server geladen werden direkt im loka-len Speicher abgelegt. Alle Views lassen sich damit auch darstellen, falls keineVerbindung zum Server besteht: Normalerweise werden sämtliche Views direktmit den Daten vom Server generiert. Falls keine Verbindung besteht werdendie lokal abgelegten Daten verwendet. (vgl. Abbildung 5.11)

5.4.4.3 Lokale Datenbank – Web-SQL

Die Web-Database-Spezifikation ist im Moment an einem Wendepunkt, wiefolgendes Zitat verdeutlicht:

“This document was on the W3C Recommendation track but spe-cification work has stopped. The specification reached an impasse:all interested implementors have used the same SQL backend (Sqli-te), but we need multiple independent implementations to proceedalong a standardisation path.” W3C [61]

Allerdings ist die Web-SQL Datenbank auf SQlite Basis immer noch starkverbreitet auf mobilen Geräten und iOS, als auch Android unterstützen dieseim Moment noch. Als erster Browser hat Mozillas Firefox mit der “IndexedDB” die neue Spezifikation des W3C umgesetzt (vgl. W3C [58]).

Im Rahmen dieser Arbeit wurde die Web-SQL-Spezifikation genutzt, dadiese momentan noch weit verbreitet ist und die Zukunft der Spezifikation zumZeitpunkt der Arbeit nicht klar war. Aus diesem Grund wird dieses Kapitelnicht vertieft, sondern lediglich die grundsätzliche Implementierung beschrie-ben.


Die bisherige Implementierung der Module bietet lediglich eingeschränkteOffline-Funktionalität, da es nur möglich ist den Stand der letzten Synchro-nisierung zu betrachten. Im Offline-Modus werden alle Funktionalitäten deak-tiviert, die eine Synchronisierung erfordern würden (z.B. Ausgaben anlegen).Die Einkaufsliste soll als einziges Modul sowohl online, als auch offline diesel-be Funktionalität bieten: Einkäufe auflisten, Einkauf hinzufügen, Einkauf alserledigt markieren.

Dazu wird eine lokale relationale Datenbank genutzt, die sämtliche Da-ten hält und mit der Datenbank auf dem Server synchronisiert wird. (sieheQuelltext 5.6, Abbildung 5.13)

Algorithmus 5.6 HTML5 – WebSQL Verbindungsaufbau

1 //database2 con f i g var db ;3 var shortName = ’shoppinglist’ ;4 var ve r s i on = ’1.0’ ;5 var displayName = ’roomieplanet - shoppinglist’ ;6 var maxSize = 65536;7 db = openDatabase ( shortName , ver s ion , displayName , maxSize ) ;

Die Einkaufsliste ist über eine eigene Klasse realisiert, die den Daten-bankzugriff übernimmt und alle wichtigen Funktionen bietet. Die integriertenEntwickler-Tools der WebKit-Browser zeigen den aktuellen Datenbankinhalt(vgl. Abbildung 5.13).

Abbildung 5.13: WebSQL - Entwickler-Tools(Quelle: Eigene Abbildung)

5.4.4.4 Geolocation

Um Ausgaben oder Einträge auf der Pinnwand mit einer Ortsangabe zu ver-sehen, kommt die Geolocation-Spezifikation zum Einsatz:

Über navigator.geolocation kann man die Koordinaten des Gerätes abru-fen (vgl. Algorithmus 5.7). Der Benutzer bekommt dann über den Browsereine Meldung, ob er der Webseite erlauben möchte den Standort zu bestimm-ten. Wenn dieser zustimmt, so werden die Koordinaten über den eingebautenGPS-Empfängern – sofern vorhanden – bestimmt und über eine JavaScript-Funktion asynchron zurückgeliefert. Um aus den Koordinaten eine Adresse zu


bestimmen, nutzt Roomieplanet mobile zusätzlich die Reverse Geocoding APIvon Google.

Algorithmus 5.7 HTML5 – Geolocation

1 //check if geolocation is available2 i f ( nav igator . g e o l o c a t i on ) {3 //pCB = positiveCallback (if geolocation works)4 //nCB = negative Callback (in case of error)5 nav igator . g e o l o c a t i on . ge tCurrentPos i t i on (pCB,nCB) ;6 }

5.5 Implementierung - Hybrid-App

5.5.1 Motivation

Die Implementierung von Roomieplanet in Form einer Web-App bietet schonsehr 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 übereine URL auch dann gestartet werden, wenn keine Verbindung zum Internetbesteht. Eine aktive “Installation” ist dabei meinst nur in Form eines Lese-zeichens mit Icon möglich. Native Plattformen wie iOS oder Android bietenzentrale App-Marktplätze, über welche die Apps hauptsächlich bezogen wer-den. Es ist also wichtig Apps auch über diese Kanäle anzubieten um möglichstviele Anwender zu erreichen. Zusätzlich gibt es einzelne Funktionen die mannoch in die bestehende Web-App integrieren könnte, um diese noch besserauf die nativen Plattformen anzupassen (z. B. Kamera-Zugriff, Native Benach-richtigungen). All diese Punkte lassen sich über die Integration eines Hybrid-Frameworks lösen.

5.5.2 PhoneGap

PhoneGap ist ein Open-Source-Framework, welches federführend vom kanadi-schen Softwarehaus Nitobi entwickelt wird. Um Web-Apps auf native Plattfor-men zu bringen bietet PhoneGap vorgefertigte Projekte für die plattformspe-zifischen SDKs. Diese Projekte bestehen auf dem Gerüst einer nativen App,welche nur aus einem einzigen UI-Element – dem sogenannten WebView – be-steht: Ein Web-View-Element ist ein eingebettetes Browserfenster innerhalbeiner nativen App, in welches die Web-App geladen wird. Neben dieser Mög-lichkeit, Web-Apps in Form einer nativen App zu verpacken, bietet PhoneGapnoch einen weiteren Mehrwert: Viele native Schnittstellen werden von Phone-Gap mithilfe einer JavaScript-Schnittstelle repliziert, um diese auch direkt für

5.5. IMPLEMENTIERUNG - HYBRID-APP 83

Abbildung 5.14: PhoneGap – Logo

Web-Apps zur Verfügung zu stellen. Es ist somit beispielsweise möglich perJavaScript die Kamera der Geräte anzusteuern (vgl.PhoneGap [45]).

5.5.3 Web-App Integration

Um eine Web-App in eine native App zu konvertieren, muss man zuerst dienativen SDKs installieren und konfigurieren. PhoneGap unterstützt zum Zeit-punkt der Arbeit die folgenden Plattformen: iOS, Android, PalmWebOS, Sym-bian OS und BlackBerry OS. Die Implementierung von Roomieplanet mobilebeschränkt sich vorerst auf Android und iOS.

Nachdem man die Projekte in Xcode für iOS, bzw. Eclipse ADT für Andro-id importiert hat, muss der Quelltext der Web-App eingebunden werden: Dazumuss man die Web-App mit sämtlichen Dateien in die folgenden Verzeichnissekopieren:

• iOS: /www

• Android: /assets/www/

Bei der Hybrid-App wird die index.html automatisch von PhoneGap aufge-rufen, wenn die App gestartet wird. Im nächsten Schritt muss die PhoneGapBibliothek eingebunden werden um auf PhoneGap-spezifische Funktionen zu-greifen zu können. Dazu fügt man die Datei phonegap.js ein, die bereits imWWW-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 na-mens “onDeviceReady” gewartet werden, weshalb man in den index.html eineweitere kleine Ergänzung machen muss (vgl. Algorithmus 5.9).


Algorithmus 5.9 PhoneGap – Initialisierung

1 function onDeviceReady ( ) {2 //init roomie-app3 runApp ( ) ;4 }

Nach diesen Anpassungen ist die Hybrid-App bereits komplett funktions-tüchtig: Die bestehende Web-App läuft nun als native App innerhalb einesWebView-Containers. Es ist jetzt möglich diese auch über die nativen Markt-plätze zu verbreiten, so dass es für Anwender hinsichtlich Installation undUpdates keinen Unterschied zu nativen Apps gibt.

5.5.4 Zusatzfunktionen

Neben der Möglichkeit Web-Apps in eine native App einzubetten, bietet Pho-neGap Zugriff auf native Plattform-Funktionen, die für Web-Apps norma-lerweise nicht verfügbar sind. Dazu werden die nativen Funktionen über ei-ne JavaScript-Schnittstelle bereitgestellt, die dann zur Laufzeit entsprechen-de native Funktionen aufruft. Dabei ist die API immer möglichst an Web-Spezifikationen angelehnt, so dass Funktionen auch direkt in der Web-Appgenutzt werden können, sobald diese auch dort implementiert sind. PhoneGapbietet somit eine standardkonforme Entwicklung, schon bevor die Spezifikatio-nen im Browser implementiert sind.

Für Roomieplanet sollen folgende Erweiterungen realisiert werden:

• Verbesserte Benachrichtigungen

– Native Dialoge (z.B. Alert)

– Haptisches Feedback (Vibration)

– Akustisches Signale (Beep)

• Integration der Kamera

– Bilder in Neuigkeiten integrieren

• Nutzung der Sensoren: Aktualisierung durch Schütteln

• Speichern der Login-Daten

Die Integration von weiteren Funktionen ist dabei auf zwei Arten gelöst: Klei-nere Änderungen – wie z.B. die nativen Dialoge – sind direkt über Bedingungen(IF) im Quelltext eingebunden (vgl. Algorithmus5.12).

5.5. IMPLEMENTIERUNG - HYBRID-APP 85

Algorithmus 5.10 PhoneGap – Integrierte Erweiterungen

1 //Basic alert box2 this . a l e r t = function ( t i t l e , message , buttonLabel ) {3 //if phonegap4 i f ( nav igator . n o t i f i c a t i o n ) {5 nav igator . n o t i f i c a t i o n . a l e r t (message , t i t l e , ’OK’ ) ;6 }7 else {8 Ext .Msg . a l e r t ( t i t l e , message ) ;9 }10 }

Größere Änderungen am bestehenden Code sind durch Vererbung bzw.Überschreiben von bestehenden Methoden gelöst: Dazu sind diese Methodenin einer eigenen Datei namens “pg.js” definiert, welche in der “index.html” desPhoneGap Projekts eingebunden wird (vgl. 5.11).

Algorithmus 5.11 PhoneGap – Einbinden der Erweiterungen

1 <script type="text/javascript" src="pg.js"></ script>

Die Methoden, die in der pg.js Datei definiert sind überschreiben UI-Elementeund Klassenmethoden um zusätzliche Funktionen bereitzustellen (vgl. Algo-rithmus 5.12).

Algorithmus 5.12 PhoneGap – Erweiterungen durch Vererbung

1 // #### MAIN - LOGIN ####//2 roomie . l o g i n = function ( email , password , c a l l b a ck ) {3 . . .4 //save loginData for automatic login (only phonegap)5 i f ( j son . s t a tu s ) {6 roomie . loggedIn = true ;7 l o c a l S t o r a g e . set I tem (’email’ , emai l ) ;8 l o c a l S t o r a g e . set I tem (’password’ , password ) ;9 }10 . . .11 }

Durch Vererbung lassen sich Änderungen an der Web-App direkt in dieHybrid-App übernehmen, da die aktuelle Version der Web-App einfach in dasPhoneGap-Projekt kopiert werden kann. Die Ergänzungen der Hybrid-Appsind somit getrennt vom eigentliche Quelltext der Web-App, was die Wartungdeutlich erleichtert und den Update-Prozess beschleunigt.


5.6 Erfahrungsbericht

Diese Kapitel behandelt Erfahrung, die während der Implementierung gesam-melt wurden. Dabei ist zu beachten dass die Erfahrungen stark abhängig vonden Testgeräten und den verwendeten Versionen der Frameworks sind. Dasgesamte Gebiet der Web-Apps bzw. der Hybrid-Apps ist sehr neu – sowohlHTML5, als auch darauf basierende Frameworks werden momentan sehr aktivweiterentwickelt und es handelt sich gerade bei den Frameworks noch um sehrfrühe Versionen. Alle Erfahrungen beziehen sich auf die zum Zeitpunkt der Ar-beit aktuellen Versionen. Außerdem ist zu beachten dass die Plattformen auchsehr aktiv entwickelt werden und neben den Geräten wird auch die Softwareder Plattformen ständig verbessert.

5.6.1 Testgeräte und Plattformen

Die Implementierung wurde auf den folgenden Geräten getestet:

• iPhone 3GS (iOS)

• iPhone 4 (iOS)

• iPad (iOS)

• Samsung Galaxy S (Android)

Während des Entwicklungszeitraums gab sowohl für iOS, als auch für Andro-id jeweils mindestens ein Betriebssystem-Update. Insgesamt wurde bei beidenPlattformen die Unterstützung für HTML5 deutlich verbessert: So wurde beiiOS der Zugriff auf die Beschleunigungssensoren ermöglicht (device-API) undbei Android die Software-Tastatur an die neuen Formularfeld-Typen angepasst(z.B. Typ: number – zeigt Zahlen-Tastatur). Bei beiden Plattformen wird au-ßerdem ständig die JavaScript-Performance verbessert.

5.6.2 Reifegrad der Frameworks

5.6.2.1 Sencha Touch

Zu Beginn der Implementierung war Sencha Touch noch im Beta-Stadium(Version 0.93 – August 2010). Inzwischen hat Sencha Touch die Beta-Phaseverlassen und die aktuelle Version ist 1.01 wurde am 24. November 2010 ver-öffentlicht.

Im Laufe der Entwicklung wurde die API stark überarbeitet und mit jedemUpdate des Frameworks waren zahlreiche Anpassungen am bestehenden Codeder App nötig. Insgesamt wurde die Sencha-Bibliothek der Web-App sechs mal

5.6. ERFAHRUNGSBERICHT 87

angepasst, wobei jede Version viele Neuerungen, jedoch auch manchmal neueProbleme mit sich brachte.

Die aktuelle Version von Sencha Touch (1.01) bietet ein komplettes MVC-Konzept, viele vordefinierte UI-Elemente und Methoden zur Datenbeschaffungund Integration von HTML5-Funktionen. Die Reifegrad unterscheidet sich al-lerdings je nach Plattform immer noch sehr stark: Die Oberfläche und zugehö-rige Animationen sind unter iOS sehr flüssig und gut bedienbar. Das Layoutpasst sich dynamisch an die Größe des Bildschirms (iPhone/iPad) und dieLage des Gerätes an (Hochformat/Querformat). Unter Android sind die Ani-mationen bei vielen Geräten nicht flüssig und teilweise sind Interaktionen desBenutzers sehr träge. Generell ist die Web-App momentan unter iOS flüssigerzu bedienen als unter Android. Die letzten Updates von Sencha Touch habendie Android-Unterstützung jedoch deutlich verbessert und die Unterschiede derPlattformen wurden mit den letzten Updates des Android-Betriebssystems im-mer geringer. Die aktuelle Version von Sencha Touch hat eine ausgereifte APIund sehr gute Unterstützung für iOS. Der Produktiveinsatz ist somit für iOSuneingeschränkt und für Android bei deaktivierten Animation zu empfehlen.Es ist zu erwarten dass Sencha Touch in naher Zukunft eine sehr gute Un-terstützung beider Plattformen bieten wird und Nachteile unter Android baldder Vergangenheit angehören werden. Außerdem soll demnächst eine Unter-stützung von BlackBerry und Windows Phone 7 folgen. (vgl. Inc. 26)

5.6.2.2 PhoneGap

Für die Implementierung der Web-App wurde PhoneGap in der Version 0.93verwendet, welche am 22.12.2010 veröffentlicht wurde. PhoneGap wird im Mo-ment wieder sehr aktiv weiterentwickelt und nach längeren Release-Zyklen imletzten Jahr, wurde die Entwicklung wieder beschleunigt. Die Version 1.0 solllaut Roadmap Ende März erscheinen und viele neue Schnittstellen bereitstel-len. (vgl. PhoneGap 46)

Das Verpacken einer Web-App als native App für iOS oder Android istmomentan uneingeschränkt für den Produktiveinsatz zu empfehlen. Was diezusätzlichen PhoneGap-Schnittstellen betrifft, so ist je nach Plattform nochein deutlicher Unterschied zwischen Umfang und Reifegrad festzustellen. Ob-wohl PhoneGap insgesamt sechs Plattformen unterstützt, so sind die meistenSchnittstellen nur unter iOS und Android verfügbar und für den produktivenEinsatz geeignet. Die offene Architektur von PhoneGap bietet die Möglichkeitdie JavaScript-API zu erweitern und somit weitere native Systemfunktionenverfügbar zu machen. Es ist also auch möglich sehr plattform-nahe Routinennativ zu programmieren und dann über PhoneGap per JavaScript verfügbar zumachen. Allerdings muss diese Implementierung dann für jede, zu unterstüt-zende Plattform separat geschrieben werden. Neben den offiziellen PhoneGap-Schnittstellen existieren im Web zahlreiche Plugins unterschiedlichen Reifegra-


des, die teilweise plattform-spezifisch, aber auch plattformübergreifend zusätz-liche Funktionen bereitstellen. Da PhoneGap momentan aktiv weiterentwickeltwird und die plattformübergreifende App-Entwicklung an Bedeutung gewinnt,ist davon auszugehen, dass PhoneGap in naher Zukunft stark an Reife gewin-nen wird. Ein Produktiveinsatz des Frameworks sollte damit ohne Problememöglich sein.

Fazit

Die App-Entwicklung auf HTML5-Basis steht noch am Anfang: So ist dieHTML5-Spezifikation selbst noch nicht endgültig verabschiedet, was Ände-rungen an der Implementierung erfordern kann: So wird beispielsweise dieWebSQL-Spezifikation zugunsten der Indexed-DB nicht mehr aktiv weiterent-wickelt, was Anpassungen an bestehenden Web-Apps zur Folge hat. AndereTeilbereiche von HTML5 gelten aber schon als sehr ausgereift (z.B. LocalSto-rage) – diese können also durchaus schon produktiv eingesetzt werden. LangeZeit war unklar wann HTML5 endgültig verabschiedet wird – zeitweise war dasJahr 2022 im Gespräch –, doch am 12.Februar 2011 hat das W3C die “WorkingCharta” – eine Art Roadmap – aktualisiert und für Klarheit gesorgt: Der letzte“Call” (Möglichkeit Änderungswünsche einzubringen) soll bereits im Mai 2011erfolgen, womit eine endgültige “Recommondation” (finaler Standard) 2014veröffentlicht werden soll. (vgl. W3C [60])

Obwohl die endgültige Version von HTML5 also erst in 3 Jahren erschei-nen soll, werden die meisten Browser-Hersteller weiterhin deutlich früher dieImplementierungen der Spezifikationen umsetzten und somit neue Möglichkei-ten für Web-Entwickler schaffen. Alle großen mobilen Plattformen setzen sehrstark auf den neuen Standard und selbst Microsofts Windows Phone 7 – mo-mentan noch ohne HTML5-Unterstützung – soll mit dem kommenden Updateeinen neuen Browser bekommen, der auf dem Internet Explorer 9 basiert undumfangreiche HTML5-Unterstützung bietet. (vgl. Kaufmann [32])

Auch bei den Plattformen hat sich etwas getan: Durch die Kooperation vonNokia und Microsoft – in Zukunft werden Nokia Smartphones mit WindowsPhone 7 ausgeliefert –, wird der Marktanteil von Symbian weiterhin sinken.Ob MeeGo– ursprünglich als neue Nokia-Plattform angedacht – neben dieserKooperation als Alternative-Plattform noch bestand hat, wird sich zeigen.

Der Tablet-Boom und weiterhin steigende Verkaufs-zahlen bei Smartpho-nes sorgen für eine hohe Verbreitung von MIDs in allen Bereichen. Die App-Entwicklung wird also in den kommenden Jahren noch mehr von Bedeutung,wobei eine plattformübergreifende Umsetzung für die meisten App-Herstellereinen hohen Stellenwert hat. Wichtige Zielplattformen sind dabei iOS, Andro-id, BlackBerry und gegebenenfalls Windows Phone 7. Dabei sind auch Plattfor-men selbst wiederum fragmentiert: Bedingt durch unterschiedliche Versionen

89


(Update-Zyklen), eingesetzter Hardware und Hersteller-spezifische Anpassun-gen ergibt sich eine Geräte- und Plattform-vielfalt, die die App-Entwicklungdeutlich erschwert.

Der Browser als Plattform für Web-Apps ist heutzutage schon relativ ausge-reift. Durch schnellere JavaScript-Engines, erweiterte HTML5-Unterstützungund den Einsatz von CSS3 werden mobile Browser noch deutlich schnellerund ausgereifter sein. Neue Spezifikationen bieten außerdem Zugriff auf wei-tere Plattform-Ressourcen (z.B. Kamera, Kontakte), so dass Web-Apps im-mer mehr Möglichkeiten bieten, die bis dato nativen Apps vorbehalten waren.Auf dieser Grundlage aufbauend, werden zahlreiche Web-App- FrameworksEntwickler zusätzlich unterstützen und eine professionelle App-Entwicklungermöglichen.

Um Web-Apps über native Marktplätze zu verbreiten und Schnittstellenzu nutzen, die Browser momentan noch nicht implementiert haben, bietet sichPhoneGap an. Wie die aktuelle Roadmap zeigt, werden zukünftig weitere Spe-zifikationen des W3C in Form von Schnittstellen umgesetzt, die eine Web-Appinnerhalb eines Projektes nutzen kann. Man kann PhoneGap somit als Über-gangslösung ansehen um Schnittstellen schon heute zu nutzen, die Browsererst in Zukunft unterstützen werden. Da sich diese Schnittstellen an die W3C-Standards halten, kann bestehender PhoneGap-Code auch für eine normaleWeb-App genutzt werden, sobald Browser diese Schnittstellen zur Verfügungstellen.

Insgesamt bietet die plattformübergreifende App-Entwicklung aus Basisvon Web-Technologien sehr viele Möglichkeiten. Ob man eine App nativ, hy-brid oder auf Web-Basis implementiert hängt stark davon ab, welchen Nutzendie App bieten soll. Prinzipiell ist es momentan sinnvoll eine Web-App zurealisieren, wenn man nicht sehr stark auf Plattform-Ressourcen zugreift undkeine allzu große Performance benötigt. So sollten beispielsweise Spiele weiter-hin nativ entwickelt werden, da dort die Performance noch deutlich besser ist.Allerdings werden sowohl Performance, als auch der Zugriff auf nativen Res-sourcen bei Web-Apps sehr schnell verbessert, was die Einsatzmöglichkeitenständig erweitert. Einen gewissen Vorsprung was neue Sensoren oder Schnitt-stellen betrifft, werden native Apps allerdings weiterhin haben. Wenn eine Appalso auf die neuesten Möglichkeiten der jeweiligen Plattformen Zugriff möchte,so ist eine native Implementierung weiterhin vorzuziehen.

Anhang

Auf der beiliegenden CD befindet sich der Quelltext der entwickelten Apps.Die Web-App kann dabei auf jeden beliebigen Webserver abgelegt werden. Umdie Hybrid-Apps zu testen, benötigt man die entsprechenden SDKs von Googleund Apple. Die Installationsanleitung und weitere Informationen zum Zugangzu roomieplanet-mobile, finden sich in der Readme.txt

B

Literaturverzeichnis

[1] Appcelerator: Titanium Mobile Application Develop-ment. – URL http://www.appcelerator.com/products/titanium-mobile-application-development/. – Zugriffsdatum:17.11.2010

[2] Apple: Apple Developer. – URL http://developer.apple.com. – Zu-griffsdatum: 05.02.2011

[3] Apple: Apple iAd. – URL http://advertising.apple.com/developers/. – Zugriffsdatum: 16.12.2010

[4] Apple: Apple WebApps. – URL http://www.apple.com/webapps/. –Zugriffsdatum: 11.11.2010

[5] Apple: iOS Logo. – URL http://de.wikipedia.org/w/index.php?title=Datei:IOS.png&filetimestamp=20100701201347. – Zugriffsda-tum: 28.02.2011

[6] Apple: Safari HTML5 Audio and Video Guide.– URL http://developer.apple.com/library/safari/#documentation/AudioVideo/Conceptual/Using_HTML5_Audio_Video/AudioandVideoTagBasics/AudioandVideoTagBasics.html%23//apple_ref/doc/uid/TP40009523-CH2-SW1. – Zugriffsdatum:20.12.2010

[7] ARM: Mobile Computing - Netbooks, Smartbooks, Tablets and eReaders.– URL http://www.arm.com/markets/mobile/computing.php. – Zu-griffsdatum: 09.09.2010

[8] Beavis, Gareth: Google: ’Android not optimised fortablets’. 9 2010. – URL http://www.techradar.com/news/phone-and-communications/mobile-phones/google-android-not-optimised-for-tablets--715550. – Zugriffsda-tum: 22.11.2010

C

http://www.appcelerator.com/products/titanium-mobile-application-development/

http://www.appcelerator.com/products/titanium-mobile-application-development/

http://developer.apple.com

http://advertising.apple.com/developers/

http://advertising.apple.com/developers/

http://www.apple.com/webapps/

http://de.wikipedia.org/w/index.php?title=Datei:IOS.png&filetimestamp=20100701201347

http://de.wikipedia.org/w/index.php?title=Datei:IOS.png&filetimestamp=20100701201347

http://developer.apple.com/library/safari/#documentation/AudioVideo/Conceptual/Using_HTML5_Audio_Video/AudioandVideoTagBasics/AudioandVideoTagBasics.html%23//apple_ref/doc/uid/TP40009523-CH2-SW1




http://www.arm.com/markets/mobile/computing.php

http://www.techradar.com/news/phone-and-communications/mobile-phones/google-android-not-optimised-for-tablets--715550



D LITERATURVERZEICHNIS

[9] Bitkom: Bitkom Studie: Smartphone-Markt. 11 2010. – URLhttp://www.bitkom.org/files/documents/BITKOM-Presseinfo_Smartphone-Markt_15_11_2010.pdf. – Zugriffsdatum: 29.11.2010

[10] Booz and Company: App-Downloads generieren im Jahr 2013Umsatzvolumen von 17 Milliarden Euro weltweit. 07 2010. – URLhttp://www.booz.com/de/home/Presse/Pressemitteilungen/pressemitteilung-detail/48203889. – Zugriffsdatum: 22.11.2010

[11] Cozza, Roberta: Gartner Says Worldwide Mobile Phone Sales Grew 35Percent in Third Quarter 2010. 11 2010. – URL http://www.gartner.com/it/page.jsp?id=1466313. – Zugriffsdatum: 18.11.2011

[12] Distimo: Distimo Report November 2010. 11 2010. – URL http://www.distimo.com/publications/. – Zugriffsdatum: 25.11.2010

[13] Firtman, Maximiliano: Programming the Mobile Web. 1. O’Reilly, 82010

[14] Gartner: Gartner Says Consumers Will Spend 6.2 Billion in MobileApplication Stores in 2010. 1 2010. – URL http://www.gartner.com/it/page.jsp?id=1282413. – Zugriffsdatum: 02.01.2010

[15] Gartner: Gartner Says Worldwide Media Tablet Sales on Pace to Reach19.5 Million Units in 2010. 10 2010. – URL http://www.gartner.com/it/page.jsp?id=1452614. – Zugriffsdatum: 28.11.2010

[16] Gartner: Worldwide Smartphone Sales to End Users by Operating Sys-tem in 3Q10. 11 2010. – URL http://www.gartner.com/it/page.jsp?id=1466313. – Zugriffsdatum: 27.11.2010

[17] Google: Android Supported Media Formats. – URL http://developer.android.com/guide/appendix/media-formats.html. – Zugriffsdatum:06.12.2010

[18] Google: Google Chrome Web Store. – URL http://code.google.com/intl/de-DE/chrome/webstore/docs/index.html#licensingapi. – Zu-griffsdatum: 29.12.2010

[19] Google: Google Mobile Ads. – URL http://www.google.com/mobileads/publisher_home.html. – Zugriffsdatum: 03.03.2011

[20] Google: Chrome Web Store. 11 2010. – URL https://chrome.google.com/webstore/. – Zugriffsdatum: 02.12.2010

http://www.bitkom.org/files/documents/BITKOM-Presseinfo_Smartphone-Markt_15_11_2010.pdf

http://www.bitkom.org/files/documents/BITKOM-Presseinfo_Smartphone-Markt_15_11_2010.pdf

http://www.booz.com/de/home/Presse/Pressemitteilungen/pressemitteilung-detail/48203889

http://www.booz.com/de/home/Presse/Pressemitteilungen/pressemitteilung-detail/48203889

http://www.gartner.com/it/page.jsp?id=1466313


http://www.distimo.com/publications/

http://www.distimo.com/publications/







http://developer.android.com/guide/appendix/media-formats.html

http://developer.android.com/guide/appendix/media-formats.html

http://code.google.com/intl/de-DE/chrome/webstore/docs/index.html#licensingapi

http://code.google.com/intl/de-DE/chrome/webstore/docs/index.html#licensingapi

http://www.google.com/mobileads/publisher_home.html

http://www.google.com/mobileads/publisher_home.html

https://chrome.google.com/webstore/

https://chrome.google.com/webstore/

LITERATURVERZEICHNIS E

[21] Heise: Google: 200.000 Androiden pro Tag. 11 2010.– URL http://www.heise.de/newsticker/meldung/Google-200-000-Androiden-pro-Tag-1051145.html. – Zugriffsda-tum: 09.11.2010

[22] HP: Home - HP Palm Developer Center. – URL http://developer.palm.com/. – Zugriffsdatum: 12.02.2011

[23] HP: web OS Logo. – URL http://de.wikipedia.org/w/index.php?title=Datei:HP_webOS_Logo.svg&filetimestamp=20101103124732. –Zugriffsdatum: 28.02.2011

[24] IBM: IBM Survey: IT Professionals Predict Mobile and Cloud Tech-nologies Will Dominate Enterprise Computing By 2015. – URL http://www-03.ibm.com/press/us/en/pressrelease/32674.wss. – Zugriffs-datum: 25.11.2010

[25] Ihlenfeld, Jens: Symbian ist tot, es lebe Symbian. – URL http://www.zeit.de/digital/mobil/2010-11/nokia-symbian?page=2. – Zugriffs-datum: 25.11.2010

[26] Inc., Sencha: Sencha Touch Release Notes. 2 2011. – URL http://dev.sencha.com/deploy/touch/release-notes.html. – Zugriffsda-tum: 15.02.2011

[27] Infratest, TNS: Fehlende Begeisterung für die Nutzung von Smart-phones. 3 2008. – URL http://www.tns-infratest.com/presse/presseinformation.asp?prID=595. – Zugriffsdatum: 24.11.2010

[28] Instruments, Texas: Smartphone and Mobile Internet Device So-lutions. 7 2008. – URL http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?templateId=6123&navigationId=12795&contentId=36404. – Zugriffsdatum: 22.11.2010

[29] Intel: Choosing a Mobile Device. 11 2010. – URLhttp://www.intel.com/learn/practical-advice/wireless/choosing-a-mobile-device. – Zugriffsdatum: 22.11.2010

[30] iOS, Wikipedia: Apple iOS - Wikipedia, Die freie Enzyklopä-die. – URL http://de.wikipedia.org/w/index.php?title=Apple_iOS&oldid=81148282. – Zugriffsdatum: 05.11.2010

[31] json.org: JSON. – URL http://www.json.org. – Zugriffsdatum:06.12.2010

http://www.heise.de/newsticker/meldung/Google-200-000-Androiden-pro-Tag-1051145.html

http://www.heise.de/newsticker/meldung/Google-200-000-Androiden-pro-Tag-1051145.html

http://developer.palm.com/

http://developer.palm.com/

http://de.wikipedia.org/w/index.php?title=Datei:HP_webOS_Logo.svg&filetimestamp=20101103124732

http://de.wikipedia.org/w/index.php?title=Datei:HP_webOS_Logo.svg&filetimestamp=20101103124732

http://www-03.ibm.com/press/us/en/pressrelease/32674.wss

http://www-03.ibm.com/press/us/en/pressrelease/32674.wss

http://www.zeit.de/digital/mobil/2010-11/nokia-symbian?page=2

http://www.zeit.de/digital/mobil/2010-11/nokia-symbian?page=2

http://dev.sencha.com/deploy/touch/release-notes.html

http://dev.sencha.com/deploy/touch/release-notes.html

http://www.tns-infratest.com/presse/presseinformation.asp?prID=595

http://www.tns-infratest.com/presse/presseinformation.asp?prID=595

http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?templateId=6123&navigationId=12795&contentId=36404



http://www.intel.com/learn/practical-advice/wireless/choosing-a-mobile-device

http://www.intel.com/learn/practical-advice/wireless/choosing-a-mobile-device

http://de.wikipedia.org/w/index.php?title=Apple_iOS&oldid=81148282

http://de.wikipedia.org/w/index.php?title=Apple_iOS&oldid=81148282

http://www.json.org

F LITERATURVERZEICHNIS

[32] Kaufmann, ZDNET J.: Windows Phone 7: IE9 und Multitas-king kommen im zweiten Halbjahr. – URL http://www.zdnet.de/news/mobile_wirtschaft_windows_phone_7_ie9_und_multitasking_kommen_im_zweiten_halbjahr_story-39002365-41548773-1.htm. –Zugriffsdatum: 18.02.2011

[33] Lau, Oliver: c’t - App Autonomie. 7 2010

[34] Lee, Nicole: The 411: Feature phones vs. smartphones. 3 2010. – URLhttp://www.cnet.com/8301-17918_1-10461614-85.html. – Zugriffsda-tum: 10.10.2010

[35] Leenheer, Niels: HTML5 Test. – URL http://www.html5test.com. –Zugriffsdatum: 08.12.2010

[36] Mag, PC: Definition: Tablet Computer. 11 2010. – URLhttp://www.pcmag.com/encyclopedia_term/0,2542,t=tablet+computer&i=52520,00.asp. – Zugriffsdatum: 20.11.2010

[37] Microsoft: WebKit SunSpider. – URL http://ie.microsoft.com/testdrive/benchmarks/sunspider/default.html. – Zugriffsda-tum: 06.12.2010

[38] Microsoft: Windows Phone Developer Center. – URL http://msdn.microsoft.com/de-de/windowsphone/default.aspx. – Zugriffsdatum:12.02.2011

[39] Microsoft: Windows Phone Logo. – URL http://de.wikipedia.org/w/index.php?title=Datei:Windows_Phone_Logo.svg. – Zugriffsdatum:28.02.2011

[40] Mobile, Wikipedia W.: Windows Mobile - Wikipedia. – URLhttp://de.wikipedia.org/w/index.php?title=Microsoft_Windows_Mobile&oldid=81713580. – Zugriffsdatum: 22.11.2010

[41] mobile jQuery: jQuery Mobile. – URL http://jquerymobile.com/. –Zugriffsdatum: 06.02.2011

[42] mobilexweb: Safari on iOS 4.2. – URL http://www.mobilexweb.com/blog/safari-ios-accelerometer-websockets-html5. – Zugriffs-datum: 06.12.2010

[43] Open Handset Alliance: Android Developers. – URL http://developer.android.com/index.html. – Zugriffsdatum: 02.02.2011

http://www.zdnet.de/news/mobile_wirtschaft_windows_phone_7_ie9_und_multitasking_kommen_im_zweiten_halbjahr_story-39002365-41548773-1.htm



http://www.cnet.com/8301-17918_1-10461614-85.html

http://www.html5test.com

http://www.pcmag.com/encyclopedia_term/0,2542,t=tablet+computer&i=52520,00.asp

http://www.pcmag.com/encyclopedia_term/0,2542,t=tablet+computer&i=52520,00.asp

http://ie.microsoft.com/testdrive/benchmarks/sunspider/default.html

http://ie.microsoft.com/testdrive/benchmarks/sunspider/default.html

http://msdn.microsoft.com/de-de/windowsphone/default.aspx

http://msdn.microsoft.com/de-de/windowsphone/default.aspx

http://de.wikipedia.org/w/index.php?title=Datei:Windows_Phone_Logo.svg

http://de.wikipedia.org/w/index.php?title=Datei:Windows_Phone_Logo.svg

http://de.wikipedia.org/w/index.php?title=Microsoft_Windows_Mobile&oldid=81713580

http://de.wikipedia.org/w/index.php?title=Microsoft_Windows_Mobile&oldid=81713580

http://jquerymobile.com/

http://www.mobilexweb.com/blog/safari-ios-accelerometer-websockets-html5

http://www.mobilexweb.com/blog/safari-ios-accelerometer-websockets-html5

http://developer.android.com/index.html

http://developer.android.com/index.html

LITERATURVERZEICHNIS G

[44] Open Handset Alliance: Android Logo. 02 2011. –URL http://de.wikipedia.org/w/index.php?title=Datei:Android_robot.svg&filetimestamp=20101218193452. – Zugriffs-datum: 10.02.2011

[45] PhoneGap: PhoneGap. – URL http://www.phonegap.com/. – Zugriffs-datum: 02.03.2011

[46] PhoneGap: PhoneGap Roadmap. – URL http://wiki.phonegap.com/w/page/28291160/roadmap-planning. – Zugriffsdatum: 15.02.2011

[47] Rhomobile: Rhomobile - Rhodes. – URL http://rhomobile.com/products/rhodes/

[48] RIM: BlackBerry - BlackBerry Developer Zone. – URL http://us.blackberry.com/developers/. – Zugriffsdatum: 24.11.2010

[49] RIM: BlackBerry Logo. – URL http://de.wikipedia.org/w/index.php?title=Datei:Blackberry.svg&filetimestamp=20071015151414http://de.wikipedia.org/w/index.php?title=Datei:Blackberry.svg&filetimestamp=20071015151414. – Zugriffsda-tum: 05.02.2011

[50] Samsung: Samsung Galaxy Tab. – URL http://galaxytab.samsungmobile.de/index.php?id=21. – Zugriffsdatum: 14.03.2011

[51] Sencha: Sencha Touch. – URL http://www.sencha.com/products/touch/. – Zugriffsdatum: 17.11.2010

[52] Smartphone, Wikipedia: Smartphone - Wikipedia, Die freie En-zyklopädie. – URL http://de.wikipedia.org/w/index.php?title=Smartphone&oldid=81581370. – Zugriffsdatum: 18.11.2010

[53] Symbian: Symbian developer community. – URL http://developer.symbian.org/. – Zugriffsdatum: 12.02.2011

[54] Symbian: Symbian Logo. – URL http://de.wikipedia.org/w/index.php?title=Datei:Symbian_Foundation_Logo.svg&filetimestamp=20100922181217. – Zugriffsdatum: 28.02.2011

[55] Symbian, Wikipedia: Symbian - Wikipedia. – URL http://de.wikipedia.org/w/index.php?title=Symbian-Plattform&oldid=81635279. – Zugriffsdatum: 22.11.2010

[56] Tablet-Computer, Wikipedia: Tablet-Computer - Wikipedia, Die freieEnzyklopädie. – URL http://de.wikipedia.org/w/index.php?title=Tablet-Computer&oldid=81287626. – Zugriffsdatum: 18.11.2010

http://de.wikipedia.org/w/index.php?title=Datei:Android_robot.svg&filetimestamp=20101218193452

http://de.wikipedia.org/w/index.php?title=Datei:Android_robot.svg&filetimestamp=20101218193452

http://www.phonegap.com/

http://wiki.phonegap.com/w/page/28291160/roadmap-planning

http://wiki.phonegap.com/w/page/28291160/roadmap-planning

http://rhomobile.com/products/rhodes/

http://rhomobile.com/products/rhodes/

http://us.blackberry.com/developers/

http://us.blackberry.com/developers/

http://de.wikipedia.org/w/index.php?title=Datei:Blackberry.svg&filetimestamp=20071015151414http://de.wikipedia.org/w/index.php?title=Datei:Blackberry.svg&filetimestamp=20071015151414




http://galaxytab.samsungmobile.de/index.php?id=21

http://galaxytab.samsungmobile.de/index.php?id=21

http://www.sencha.com/products/touch/

http://www.sencha.com/products/touch/

http://de.wikipedia.org/w/index.php?title=Smartphone&oldid=81581370

http://de.wikipedia.org/w/index.php?title=Smartphone&oldid=81581370

http://developer.symbian.org/

http://developer.symbian.org/

http://de.wikipedia.org/w/index.php?title=Datei:Symbian_Foundation_Logo.svg&filetimestamp=20100922181217



http://de.wikipedia.org/w/index.php?title=Symbian-Plattform&oldid=81635279



http://de.wikipedia.org/w/index.php?title=Tablet-Computer&oldid=81287626

http://de.wikipedia.org/w/index.php?title=Tablet-Computer&oldid=81287626

H LITERATURVERZEICHNIS

[57] W3C: HTML AND CSS. – URL http://www.w3.org/standards/webdesign/htmlcss.html. – Zugriffsdatum: 06.12.2010

[58] W3C: Indexed Database API. – URL http://www.w3.org/TR/IndexedDB/. – Zugriffsdatum: 08.02.2011

[59] W3C: W3C - DOM. – URL http://www.w3.org/DOM/. – Zugriffsdatum:06.12.2010

[60] W3C: W3C Extends HTML Working Charter: HTML5 Last Call in May2011 and Recommendation in 2014. – URL http://www.w3.org/News/2011.html#entry-9015. – Zugriffsdatum: 18.02.2011

[61] W3C: Web SQL Database. – URL http://www.w3.org/TR/webdatabase/. – Zugriffsdatum: 08.02.2011

[62] webOS, Wikipedia: webOs - Wikipedia. – URL http://en.wikipedia.org/w/index.php?title=WebOS&oldid=397934826. – Zu-griffsdatum: 22.11.2010

[63] WHATWG: 6.6 Offline Web applications - HTML5. – URLhttp://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html#offline. – Zugriffsdatum: 07.01.2011

[64] WHATWG: WHATWG WIKI. – URL http://wiki.whatwg.org/wiki/FAQ#What_is_the_WHATWG.3F. – Zugriffsdatum: 06.12.2010

[65] Wikipedia: Apple iPhone. – URL http://de.wikipedia.org/wiki/Apple_iPhone. – Zugriffsdatum: 14.03.2011

[66] Wikipedia: Blackberry - Wikipedia. – URL http://de.wikipedia.org/w/index.php?title=BlackBerry&oldid=81618003. – Zugriffsda-tum: 22.11.2010

[67] Wikipedia: HTML - Wikipedia. – URL http://de.wikipedia.org/w/index.php?title=Hypertext_Markup_Language&oldid=81612652. –Zugriffsdatum: 01.12.2010

[68] Wikipedia: JavaScript - Wikipedia. – URL http://de.wikipedia.org/w/index.php?title=JavaScript&oldid=81712183. – Zugriffsda-tum: 06.12.2010

[69] Wikipedia: Android (Betriebssystem) - Wikipedia, Die freie Enzy-klopädie. 2010. – URL http://de.wikipedia.org/w/index.php?title=Android_(Betriebssystem)&oldid=81503121. – Zugriffsdatum:17.11.2010

[70] Winfuture: Apple lässt "There’s an app for thatßchützen. – URL http://winfuture.de/news,58730.html. – Zugriffsdatum: 10.02.2011

http://www.w3.org/standards/webdesign/htmlcss.html

http://www.w3.org/standards/webdesign/htmlcss.html

http://www.w3.org/TR/IndexedDB/

http://www.w3.org/TR/IndexedDB/

http://www.w3.org/DOM/

http://www.w3.org/News/2011.html#entry-9015

http://www.w3.org/News/2011.html#entry-9015

http://www.w3.org/TR/webdatabase/

http://www.w3.org/TR/webdatabase/

http://en.wikipedia.org/w/index.php?title=WebOS&oldid=397934826

http://en.wikipedia.org/w/index.php?title=WebOS&oldid=397934826

http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html#offline

http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html#offline

http://wiki.whatwg.org/wiki/FAQ#What_is_the_WHATWG.3F

http://wiki.whatwg.org/wiki/FAQ#What_is_the_WHATWG.3F

http://de.wikipedia.org/wiki/Apple_iPhone

http://de.wikipedia.org/wiki/Apple_iPhone

http://de.wikipedia.org/w/index.php?title=BlackBerry&oldid=81618003

http://de.wikipedia.org/w/index.php?title=BlackBerry&oldid=81618003

http://de.wikipedia.org/w/index.php?title=Hypertext_Markup_Language&oldid=81612652

http://de.wikipedia.org/w/index.php?title=Hypertext_Markup_Language&oldid=81612652

http://de.wikipedia.org/w/index.php?title=JavaScript&oldid=81712183

http://de.wikipedia.org/w/index.php?title=JavaScript&oldid=81712183

http://de.wikipedia.org/w/index.php?title=Android_(Betriebssystem)&oldid=81503121

http://de.wikipedia.org/w/index.php?title=Android_(Betriebssystem)&oldid=81503121

http://winfuture.de/news,58730.html

http://winfuture.de/news,58730.html

cross-mobile-apps.de · zu gewährleisten. Mobile Webbrowser bieten mit HTML5 und CSS3 zahlrei-che...

Documents

Transcript of cross-mobile-apps.de · zu gewährleisten. Mobile Webbrowser bieten mit HTML5 und CSS3 zahlrei-che...