Fakultät Informatik Institut für Systemarchitektur, Professur Rechnernetze

Bachelorarbeit UNTERSUCHUNG PLATTFORMÜBERGREIFENDER ENTWICKLUNGSANSÄTZE FÜR DEN ZUGRIFF AUF EIN INNOVATIVES INFORMATIONSSYSTEM MIT TABLETS

Markus Wutzler Mat.-Nr.: 3587961

Betreut durch: Dr. Marius Feldmann und: Dr. Thomas Springer Eingereicht am 24. Juli 2012

ERKLÄRUNG

Ich erkläre, dass ich die Kapitel 1, 3 und 6, sowie die Abschnitte 2.2, 2.4, 4.3 und 5.2 der vorliegen- den Arbeit selbstständig, unter Angabe aller Zitate und nur unter Verwendung der angegebenen Literatur und Hilfsmittel angefertigt habe. Der Abschnitt 2.4 ist eine gemeinsame Ausarbeitung von Martin Weißbach und mir. Die Absätze zu iOS in Abschnitt 5.2.5 wurden inhaltlich von Martin Weißbach zugearbeitet. Alle nicht aufgeführten Abschnitte stammen ebenfalls von Martin Weiß- bach [Wei12] und unterliegen seiner Selbstständigkeitserklärung.

Dresden, 24. Juli 2012

v

DANKSAGUNG

Eine Analyse und Bewertung plattformübergreifender Entwicklungsansätze ist nicht ohne Anwen- dungsfall möglich. Die Konzeption eines fiktiven Anwendungsfalls birgt zudem die Gefahr, dass Analyse und Bewertung zu engstirnig ausgelegt sind und eventuell zu verfälschten Ergebnissen führen.

Daher möchte ich mich zunächst bei unserem externen Kooperationspartner, der Communote GmbH, bedanken, die uns einen realistischen und umfangreichen Anwendungsfall zur Verfügung gestellt hat, sodass sehr viele Anforderungen und Kriterien für die Evaluierung der Entwicklungs- ansätze aufgestellt werden konnten. Dies hat eine sehr umfangreiche Betrachtung und Bewer- tung der Frameworks ermöglicht.

Zudem möchte ich mich bei meinen Betreuern Dr.-Ing. Marius Feldmann und Dr.-Ing. Thomas Springer bedanken, die uns kontinuierlich unterstützt haben, eine umfangreiche Analyse und Be- wertung der Frameworks anzufertigen, aber auch für den fachlichen Beistand zum Thema der Arbeit und zum Anfertigen von wissenschaftlichen Arbeiten.

Des Weiteren bedanke ich mich bei meinem Kommilitonen Martin Weißbach für die effektive Zusammenarbeit, vor allem was die Evaluierung der verschiedenen Entwicklungsansätze betrifft.

Für die grammatikalische und syntaktische Durchsicht möchte ich mich bei Ivonne W. bedanken, die diese Arbeit nicht nur einmal korrigiert hat. Abschließend möchte ich mich auch bei meiner Freundin Sarah H. bedanken, die mich während dieser Arbeit in jeglicher Hinsicht unterstützt und häufig auf mich verzichtet hat.

vii

INHALTSVERZEICHNIS

1 Einleitung 1

1.1 Motivation ...... 1

1.2 Zielstellung ...... 1

1.3 Aufbau der Arbeit ...... 2

2 Anforderungsanalyse 3

2.1 Anwendungsfall ...... 3

2.2 Möglichkeiten eines Tablets ...... 5

2.3 Status Quo ...... 6

2.4 Anforderungen & Evaluationskriterien ...... 7

2.4.1 Funktionale Anforderungen ...... 7

2.4.2 Nicht-funktionale Anforderungen ...... 9

2.4.3 Weitere Kriterien ...... 9

3 Grundlagen und Stand der Technik 11

3.1 Klassifikation mobiler Anwendungen ...... 11

3.2 Vorbetrachtung ...... 12

3.3 jQuery Mobile ...... 15

3.4 Sencha Touch ...... 16

3.5 Apache Cordova (PhoneGap) ...... 18

3.6 Ergebnis ...... 19

ix 4 Konzeption 23

4.1 Allgemeine Konzeption ...... 23

4.2 Backend ...... 24

4.2.1 REST-Client ...... 24

4.2.2 Model ...... 25

4.2.3 Externe Module ...... 25

4.3 Grafische Oberfläche ...... 26

4.3.1 Gesamtansicht & Navigation ...... 26

4.3.2 Informationsstrom ...... 27

4.3.3 Technische Konzeption ...... 28

5 Bewertung 31

5.1 Backend ...... 31

5.2 Grafische Oberfläche ...... 34

5.2.1 Model-View-Controller ...... 34

5.2.2 Grafische Komponenten ...... 34

5.2.3 Entwicklung ...... 36

5.2.4 Einhaltung der User-Interface-Guidelines ...... 38

5.2.5 Native Entwicklung ...... 39

6 Zusammenfassung & Ausblick 41

A Tabellen 43

B Abbildungen 45

C Literatur 53

x Inhaltsverzeichnis 1 EINLEITUNG

Die Verbreitung mobiler Endgeräte wie Smartphones oder Tablets nimmt in den letzten Jahren stetig zu, was zur Folge hat, dass auch der Markt für mobile Betriebssysteme wächst. Bisher dominieren Apples iOS und Android diesen Markt. Allerdings sind auch andere Anbieter bestrebt, auf diesem Markt (wieder) Fuß zu fassen, darunter vor allem Microsoft mit Windows Phone 8 und Research In Motion mit dem Blackberry Betriebssystem.

Dieser Markt ist für Softwareanbieter sehr interessant, da Anwendungen auf Grund der Porta- bilität der Geräte dem Nutzer jederzeit zur Verfügung stehen. Entwickler stehen jedoch vor der Herausforderung, wie die verschiedenen Plattformen mit möglichst wenig Aufwand unterstützt werden können, da die Marktanteile derzeit noch zu stark variieren, um sich lediglich auf eine Plattform zu konzentrieren.

1.1 MOTIVATION

Der Aufwand, jede Plattform separat zu entwickeln, ist für kleinere Unternehmen oder private Entwickler kaum zu bewältigen. Eine Alternative dazu ist, sofern der Anwendungsfall es zulässt, eine mobile Webseite, die über den Browser, nahezu unabhängig vom Gerät, aufgerufen wer- den kann. Funktionsumfang und Bedienkomfort sind gegenüber herkömmlichen Apps allerdings meist eingeschränkt. Benötigt wird ein Kompromiss, der eine ressourcenschonende, plattform- übergreifende Entwicklung bietet, aber nicht auf die Möglichkeiten und den Komfort einer nativen App verzichtet.

1.2 ZIELSTELLUNG

Mittlerweile existiert eine Vielzahl solcher plattformübergreifenden Entwicklungsansätze und es entstehen weiterhin neue Frameworks, da dieser Markt noch viel Potenzial bietet. Das Ziel dieser Arbeit ist es, die Vor- und Nachteile verschiedener plattformunabhängiger Entwicklungsansätze zu betrachten und einen Vergleich zur nativen Entwicklung zu ziehen.

Auf Basis einer Vorevaluierung soll ein Framework gewählt werden, für welches ein vollständiger Softwareentwicklungsprozess durchgeführt wird, um Erkenntnisse hinsichtlich des Entwicklungs- und Wartungsprozesses sowie der Plattformunabhängigkeit zu gewinnen. Die Evaluierung dieser

1 Erkenntnisse ermöglicht eine Einschätzung der langfristigen Eignung des Frameworks bezüglich der plattformunabhängigen Entwicklung.

Ein weiterer Schwerpunkt liegt auf den erweiterten Möglichkeiten, die Tablets gegenüber einem Smartphone haben, unter anderem, wie die zur Verfügung stehende Bildschirmfläche optimal ausgenutzt oder wie mit verschiedenen Gesten gearbeitet werden kann. Zusätzlich soll betrach- tet werden, inwiefern die unterschiedlichen Frameworks, die seit Android 4 vorhandenen User- Interface-Guidelines einhalten.

Kernziele dieser Arbeit sind:

• Bewertung verschiedener Ansätze zur mobilen Entwicklung auf Basis konkreter Anforde- rungsbestimmungen hinsichtlich der Eignung für eine weiterführende Entwicklung

• Bewertung eines ausgewählten Ansatzes hinsichtlich des Entwicklungs- und Wartungspro- zesses, der Plattformunabhängigkeit und der Einhaltung der User-Interface-Guidelines

1.3 AUFBAU DER ARBEIT

Das nächste Kapitel beinhaltet eine Anforderungsanalyse auf Grundlage eines ausgewählten An- wendungsfalls. Zunächst wird dieser genauer erläutert und die besonderen Möglichkeiten des Tablets dargelegt. Anschließend wird auf bestehende Alternativen zum Anwendungsfall und die Notwendigkeit einer App eingegangen. Abschließend folgt die Definition der Anforderungen und Evaluationskriterien. Das dritte Kapitel betrachtet die Grundlagen und den Stand der Technik. Hier inbegriffen ist die Vorbetrachtung einiger Frameworks, die Detailbetrachtung für die Vorauswahl, sowie die Entscheidung für das letztendlich gewählte Framework, welches im vierten Kapitel de- tailliert auf alle genannten Ziele hin evaluiert wird. Im fünften Kapitel werden die Erkenntnisse bewertet. Das sechste Kapitel fasst diese Erkenntnisse nochmals zusammen und gibt einen Ausblick auf die Zukunft.

2 Kapitel 1 Einleitung 2 ANFORDERUNGSANALYSE

In diesem Kapitel werden die Anforderungen an die umzusetzende Applikation sowie der aktuelle Stand der bereits existierenden Anwendung vorgestellt.

Zu Beginn wird ein Überblick über den Anwendungsfall gegeben, welcher die grundlegenden Funktionen der App beinhaltet. Anschließend wird auf die besonderen Möglichkeiten eines Ta- blets eingegangen, die bei der Konzeption und Entwicklung beachtet werden sollten. Danach schließt sich eine Betrachtung des aktuellen Standes der bisherigen Anwendung an, um Vor- und Nachteile sowie die Möglichkeiten und Grenzen des verwendeten Frameworks zu evaluie- ren. Abschließend werden alle wichtigen funktionalen und nicht-funktionalen Anforderungen an die Anwendung aufgelistet und beschrieben. Zusätzlich werden Bewertungskriterien für die Fra- meworks festgelegt, welche eine Betrachtung unabhängig vom umzusetzenden Anwendungsfall ermöglichen sollen.

2.1 ANWENDUNGSFALL

Die mobile Anwendung orientiert sich an einer bereits bestehenden Kommunikationsplattform, Communote, eine Eigenentwicklung des industriellen Partners dieser Arbeit. Wichtige Funktio- nen der bereits bestehenden Plattform sollen selbstverständlich auch auf dem mobilen Endgerät verfügbar sein und werden im Folgenden vorgestellt. Für einen besseren Überblick sind in Abbil- dung 2.1 auf Seite 4 die wichtigsten Anwendungsfälle zusammengefasst.

Hauptsächlich ist es mit der Anwendung möglich, Nachrichten – sogenannte Notes – zu schreiben und zu lesen. Notes sind in Themen eingeordnet, zu denen ein Nutzer entweder lesenden Zugriff hat oder nicht. Auf Basis dieser Berechtigungen sollen auf dem mobilen Client nur solche Nach- richten angezeigt werden, die der Nutzer auch lesen darf. Die Liste der aktuellen Nachrichten ist standardmäßig in drei Gruppen unterteilt: In der ersten Gruppe werden alle aktuellen Nachrich- ten angezeigt. Da Nutzer in Nachrichten mithilfe eines Kürzels erwähnt werden können, werden in der zweiten Gruppe nur die Nachrichten angezeigt, die an den entsprechenden Nutzer adres- siert sind. Communote stellt eine Lösung bereit, anderen Nutzern Direktnachrichten, die nicht öffentlich sichtbar sind, zu schicken. Diese Nachrichten sollen in der dritten Gruppe dargestellt werden. Wie in der bestehenden Version der Kommunikationsplattform, ist es auch auf dem Cli- ent möglich, Nachrichten als lesenswert zu kennzeichnen beziehungsweise sie in eine Merkliste aufzunehmen.

3 Visual Paradigm for UML Community Edition [not for commercial use] Use Case

Write Note Read Note extension points Remember Note Reply to Note Like Note

<>

<> Like Note Show User List

Remember Note Show Topic List extension points Show Topic Description

<> Show Topic Description

Text Document Upload Share from Device Camera

Image Upload File Upload User

<> <> Share Foto extension points Share from Device Camera Share from File System

<> Filter Notes Share from File System

<> Filter Topics Create Filter <>

Share GeoLocation Information

Abbildung 2.1: Anwendungsfalldiagramm des umzusetzenden Anwendungsfalls

4 Kapitel 2 Anforderungsanalyse Der Nutzer der mobilen Anwendung hat die Möglichkeit, sich eine Liste aller bestehenden The- men inklusive Themenbeschreibung anzeigen zu lassen. Wie bereits erwähnt, sind die Themen nur für bestimmte Nutzer beziehungsweise Nutzergruppen lesbar. Dementsprechend kann der Anwender natürlich nur die Themen in dieser Liste angezeigt bekommen, für die er eine Lesebe- rechtigung besitzt.

Es ist möglich, dass Nutzer ein Thema lesen jedoch in diesem nicht schreiben dürfen. Dies wird bei der Möglichkeit des Nutzers, auf bestimmte Nachrichten zu antworten oder neue Nachrichten in Themen zu schreiben, berücksichtigt. Dem jeweiligen Anwender wird im mobilen Client eben- falls eine Benachrichtigung angezeigt, wenn er in einer neuen Nachricht Nutzer adressiert, die für das betreffende Thema keine Zugriffsrechte besitzen. Das erfolgreiche Verfassen einer Nachricht wird in diesem Fall jedoch nicht blockiert.

Die mobile Anwendung ist in der Lage, Dokumente oder Bilder direkt an eine neue Nachricht anzu- hängen. Im Falle von Bildanhängen, können diese auch direkt mit der Gerätekamera geschossen und angehangen werden, ohne die Anwendung zu verlassen. Da sehr viele mobile Endgeräte ein GPS-Modul besitzen, unterstützt die Anwendung das Anhängen von Ortsinformationen an eine neue Note, wenn dies vom Anwender ausdrücklich erlaubt worden ist.

Um auf die Daten des Communote-Systems zuzugreifen, wird ein bereits existierender WebSer- vice genutzt. Da für die Kommunikation mit dem WebService eine Internetverbindung zur Verfü- gung stehen muss, wird der Fehlerbehandlung bei Netzwerkproblemen besondere Beachtung geschenkt. Die Anwendung stellt daher Mittel zur Verfügung, um geschriebene Nachrichten temporär zu speichern, sollten diese durch eine fehlende Netzwerkverbindung nicht direkt ab- geschickt werden können. Der Nutzer kann global einstellen, ob auf diese Weise gespeicherte Nachrichten automatisch versandt werden sollen, sobald wieder eine Netzwerkverbindung be- steht oder ob der Nutzer das geplante Abschicken noch bestätigen möchte. Nachrichten können auch aus dieser Warteliste gelöscht werden. Des Weiteren ist es möglich, Nachrichten separat als Entwürfe zu speichern und später weiter zu bearbeiten oder zu versenden. Themen, Nutzer und Nachrichten werden ebenfalls temporär auf dem Endgerät gesichert, um einen geeigneten Offline-Betrieb der Anwendung zu gewährleisten.

2.2 MÖGLICHKEITEN EINES TABLETS

Das Informationssystem stellt sowohl eine Webanwendung, als auch ein Widget zur Integra- tion in andere Systeme bereit, welches beispielsweise bisher auch auf Mobiltelefonen genutzt wurde. Die berechtigte Frage ist daher, was die Notwendigkeit einer eigenständigen Anwendung begründet.

Ein Tablet bietet durchaus genügend Platz, die Webanwendung im Browser zu nutzen. Allerdings ist diese Anwendung auf Desktop-Browser optimiert, sodass die Bedienelemente teilweise zu klein sind, um sie zu nutzen. Zudem kommen die mobilen Browser mit dem massiven Einsatz von JavaScript nur schwer zurecht, da die meisten Seiten für die Darstellung auf Desktop-Rechnern statt berührungssensitiven Bildschirmen ausgelegt sind. Das Widget ist funktional nur auf das Le- sen und Schreiben von Nachrichten beschränkt und in keinster Weise für den Einsatz auf Tablets optimiert.

Berührungsempfindliche Geräte reagieren mit anderen Ereignissen auf die Bedienung als ein Desktop-Rechner, was dazu führt, dass das Verhalten meist fehlerhaft ist. Ein typisches Pro- blem tritt in der aktuellen Webanwendung auf: Der Text einer Information kann nicht markiert und kopiert werden, da die Webanwendung das Klickereignis mit eigenen Funktionen belegt hat. Dies hat auf dem Desktop-Rechner keine Auswirkung, das Tablet muss diese Ereignisse jedoch übersetzen, wodurch aus dem „touchstart“ für den Beginn der Markierung ein Klickereignis wird. Auf dem iPad kommt noch eine technische Einschränkung hinzu, denn es können keine Anhänge

2.2 Möglichkeiten eines Tablets 5 hochgeladen werden. Dies könnte sich in iOS 6, welches das Hochladen von Bildern erlaubt, ändern.

Prinzipiell ist ein Tablet geeignet, alle Funktionen der Webanwendung zu übernehmen. Dazu ist es in erster Linie notwendig, eine geeignete Oberfläche zu entwerfen, sodass eine komfortable Bedienung möglich ist. Diese sollte möglichst einfach strukturiert und übersichtlich sein. Ent- scheidende Hinweise zur Entwicklung einer solchen Oberfläche liefern die plattformspezifischen Human Interface Guidelines von Apple [App12e] und Android (ab Version 4) [And12a]. Insbeson- dere sollte die Nutzung eines Tablets keinen Geschwindigkeitsverlust gegenüber der Nutzung der klassischen Webanwendung bedeuten. Die größere Bildschirmfläche sollte auch genutzt werden, um schnelle Kontextwechsel zu ermöglichen. Damit sind Wechsel zwischen unterschiedlichen In- formationsströmen beziehungsweise anderen Bereichen der Anwendung gemeint.

Bei der Konzeption sollte ebenfalls auf die Verwendung von Gesten geachtet werden. Dabei kann einerseits auf klassische Gesten, beispielsweise das Auseinanderziehen zweier Finger zum Ver- größern, andererseits auch auf neue, eigene Gesten gesetzt werden. Eine klassische Geste, vor allem unter iOS, ist der Swipe, also das Seitwärtswischen. Sie wurde unter iOS seit jeher genutzt, um einen Listeneintrag zu löschen. Mittlerweile werden damit viele weitere Kontextaktionen er- möglicht1. Im Rahmen des Anwendungsfalls könnten beispielsweise die Kontextaktionen zum Bewerten und Favorisieren einer Information angeboten werden. Auf dem Tablet wäre zudem der Wechsel der Informationsströme schneller zu realisieren, wenn dieser durch eine Geste un- terstützt wird.

Insbesondere besitzen die meisten Tablets eine umfangreichere Multi-Touch-Unterstützung als Smartphones, sodass viele Gesten mehrfach interpretiert werden können, je nachdem, wie viele Finger verwendet werden.

2.3 STATUS QUO

Dieser Abschnitt widmet sich der Vorstellung der bereits existierenden Anwendung des in dieser Arbeit umzusetzenden Anwendungsfalls. Da bereits viel Entwicklungsaufwand in die bisherige Applikation investiert wurde und dementsprechende Erfahrungen über den Aufwand und die Rea- lisierbarkeit bestimmter Anforderungen bestehen, soll im Folgenden eine Vergleichsgrundlage für die Bewertung der neuen Entwicklungsansätze geschaffen werden.

Die aktuelle Communote-Applikation basiert auf dem Framework Rhodes von Rhomobile, auf welches in [Wei12, S. 6] noch einmal genauer eingegangen wird. Es werden bereits sehr viele Anwendungsfälle, die auch von der möglichen Neuentwicklung der Anwendung umgesetzt wer- den sollen, realisiert. So ist das Lesen, Schreiben und Beantworten von Nachrichten, als zentrale Schwerpunkte des Anwendungsfalls, implementiert. Auch das Anzeigen von Diskussionen so- wie das native Filtern nach Erwähnungen beziehungsweise Direktnachrichten an den Nutzer ist im Funktionsumfang der Applikation enthalten. Eine Übersicht aller Themen, für die der Nutzer Leserechte besitzt, ist ebenfalls verfügbar, da neue Nachrichten nur zu Themen verfasst werden dürfen, die der Nutzer wenigstens lesen kann. Ohne diese Liste von Themen könnte eine neue Nachricht keinem Thema zugeordnet und dementsprechend nicht erstellt werden.

Das Framework, auf welchem diese Anwendung basiert, wird detailliert in [Wei12, S. 6] vorge- stellt, weshalb an dieser Stelle nicht näher auf Vor- oder Nachteile in Bezug auf die Umsetzung des Anwendungsfalls eingegangen wird. Während der Entwicklung tauchten jedoch wiederholt Schwierigkeiten bei der plattformübergreifenden Entwicklung auf, da bestehender Quelltext an einigen, zum Teil signifikanten Stellen, unter Android zu anderen Ergebnissen führte als unter

1Eine sehr umfangreiche Interpretation dieser Geste wurde in der Tweetbot-App (http://www.tapbots.com) umge- setzt. Dabei wird auch die Wischrichtung genutzt um unterschiedliche Aktionen anzubieten.

6 Kapitel 2 Anforderungsanalyse iOS. Generell muss an dieser Stelle zusammengefasst werden, dass die Anwendung unter iOS deutlich stabiler und zuverlässiger arbeitet als unter Android.

Die Anwendung sieht weder aus wie eine native App noch fühlt sie sich bei der Nutzung wie eine solche an. Beide Fakten sind dem verwendeten Framework geschuldet und können aufgrund dessen Architektur nicht abgestellt werden. Der einzige Vorteil an dieser Stelle ist, dass die Anwendung auf allen Plattformen identisch aussieht und mit vergleichsweise wenig Aufwand ein einheitliches Design der Nutzerschnittstelle entworfen werden kann.

2.4 ANFORDERUNGEN & EVALUATIONSKRITERIEN

Für die Evaluierung der verschiedenen Frameworks werden Unterscheidungskriterien benötigt. Diese resultieren aus den funktionalen und nicht-funktionalen Anforderungen des Anwendungs- falls sowie zusätzlichen Anforderungen, unabhängig vom Anwendungsfall, welche direkt an das Framework gestellt werden. Zudem wird für die einzelnen Kriterien angegeben, wie sie überprüf- bar sind, beispielsweise anhand der Dokumentation.

2.4.1 Funktionale Anforderungen

Die folgenden funktionalen Anforderungen erweitern den Status Quo, wobei wichtige Anforde- rungen nochmals aufgeführt sind.

Fotoanhänge Eine geeignete Schnittstelle zum Erstellen von Fotoaufnahmen mit einer integrier- ten Kamera (sofern verfügbar) sowie das Laden eines Bildes, beispielsweise aus einer Ga- lerie, ist vorhanden. Das Bild liegt nach Abschluss der Aktion als verarbeitbares Format vor. Überprüfbar: Dokumentation / Frameworkbeschreibung

Dateianhänge Ähnlich zu den Fotoanhängen soll die Möglichkeit bestehen, anderweitige Da- teien (PDF, Textdokumente, etc.) zu laden, dabei sollten plattformspezifische Aspekte be- achtet werden, beispielsweise, dass unter Apples iOS kein Durchsuchen des Dateisystems möglich ist, sondern ein Dateiaustausch immer aus der Datei selbst heraus erfolgt (Öffnen in. . . ). Unter Android hingegen kann dafür auf den Intent ACTION_SEND reagiert werden [And12d], über den jegliche Daten zwischen verschiedenen Anwendungen ausgetauscht werden können. Überprüfbar: Dokumentation / Frameworkbeschreibung

Geolocation Nachrichten sollen mit geografischen Koordinaten oder einer textuellen Ortsangabe versehen werden können. Überprüfbar: Dokumentation / Frameworkbeschreibung

Teilen anwendungsfallspezifischer Inhalte Speziell unter Android besteht die Möglichkeit, In- halte aus der App heraus an andere Apps weiterzugeben. Bezogen auf den Anwendungsfall sollen Nachrichten an andere Apps, beispielsweise soziale Netzwerke, weitergegeben wer- den. Dies ist theoretisch auch unter iOS möglich, setzt aber eine explizite Adressierung anderer Apps voraus, und bedarf keiner zusätzlichen Implementierung. Allerdings muss die empfangende App diese Methode unterstützen und die Schnittstelle bekannt sein. Überprüfbar: Dokumentation / Frameworkbeschreibung

2.4 Anforderungen & Evaluationskriterien 7 Rich-Text-Editor Der Anwendungsfall bietet auf anderen (nicht mobilen) Plattformen die Mög- lichkeit, Nachrichten mit Formatierung zu versehen. Die mobile Applikation soll dies eben- falls, wenn auch in abgeschwächter Weise, unterstützen. Überprüfbar: Implementierung

Tastaturanpassung Nachrichten werden häufig mit einem @-Zeichen an bestimmte Empfänger adressiert oder durch ein #-Zeichen mit Schlagwörtern versehen. Diese Zeichen sind auf den Tastaturen der mobilen Endgeräte meist gut versteckt und nur umständlich zu errei- chen. Daher soll die Tastatur so angepasst werden, dass diese Zeichen (@, #) beim Schrei- ben einer Nachricht permanent zur Verfügung stehen. Überprüfbar: Implementierung

Benachrichtigungen Bisher wurden Anwender auf mobilen Endgeräten lediglich per E-Mail über neue Nachrichten informiert, was den Nutzer jedoch selten animiert, die dazugehörige App zu verwenden, um darauf zu reagieren, vor allem dann, wenn zum Antworten auch direkt auf die E-Mail geantwortet werden kann. Es sollen daher neuartige Benachrichtigungsmög- lichkeiten, welche durch die mobilen Geräte zur Verfügung gestellt werden, der Plattform entsprechend verwendet werden, um den Anwender zu motivieren, die App zu verwen- den. Dazu sollen Benachrichtigungen, beispielsweise durch sogenannte Badges (Hinweise an den Anwendungssymbolen in der Anwendungsübersicht) oder in zentralen Benachrichti- gungsübersichten dargestellt werden. Überprüfbar: Dokumentation / Frameworkbeschreibung

Persistierung Zugangsdaten müssen permanent gespeichert werden, damit der Anwender sie nicht bei jedem Start der Anwendung neu eingeben muss. Zudem sollen beispielsweise für die Offline-Verwendung Nachrichten, Themen und Personen persistiert werden. Überprüfbar: Dokumentation / Frameworkbeschreibung

Verschlüsselung Die Zielgruppe sind vor allem Firmen. Im geschäftlichen Umfeld werden oft ver- trauliche Inhalte besprochen, weshalb eine Verschlüsselung (mindestens der Zugangsdaten) unausweichlich ist. Eine weitere sicherheitsrelevante Anforderung ist die Verschlüsselung der Kommunikationswege. Die Anwendung muss SSL-gesicherte Verbindungen unterstüt- zen, sollte bei fehlerhaften SSL-Zertifikaten jedoch nicht den Gebrauch der Anwendung ver- hindern. Überprüfbar: Implementierung

App-Auslagerung Android bietet die Möglichkeit, Apps, statt auf dem internen Speicher, bei- spielsweise auf einer Speicherkarte, zu sichern. Dies soll auch für die App und ihre Daten- bank ermöglicht werden. Überprüfbar: Implementierung

Internationalisierung Die Anwendung muss in mehreren Sprachen (mindestens Deutsch und Englisch) verfügbar sein. Für die Internationalisierung soll ein möglichst flexibler, generischer und austauschbarer Ansatz gewählt werden, sodass die Sprachkonfigurationen an zentraler Stelle verwaltet werden können. Überprüfbar: Dokumentation / Frameworkbeschreibung

Zugriff auf Kontakte Der Anwender soll die Möglichkeit haben, aus der App heraus seine Kon- takte einzuladen, damit diese sich ebenfalls am Informationssystem anmelden und beteili- gen können. Überprüfbar: Dokumentation / Frameworkbeschreibung

8 Kapitel 2 Anforderungsanalyse 2.4.2 Nicht-funktionale Anforderungen

Natives Look & Feel Anwender sind mit ihrem Gerät vertraut und erwarten von bestimmten grafischen Elementen ein bestimmtes Verhalten. Um dies zu gewährleisten, sollen UI- Elemente verwendet werden, die dem Anwender bekannt sind. Weiterhin sollen auch ver- schiedene, gerätetypische Gesten unterstützt werden. Überprüfbar: Implementierung

Ladezeit & Reaktionszeit Die Ladezeit bezeichnet die Zeitspanne vom Starten der Anwendung bis zu ihrer regulären Verwendung, sie sollte möglichst gering sein. Gleiches gilt für die Reaktionszeit, welche die Zeitspanne vom Beginn der Nutzerinteraktion bis zu ihrer tatsäch- lichen Darstellung oder Ausführung bezeichnet. Überprüfbar: Implementierung

Akzeptanz im AppStore Die App muss den Richtlinien der jeweiligen Vertriebsplattformen ent- sprechen. Insbesondere auf die Einhaltung der User-Interface-Guidelines soll geachtet wer- den. Überprüfbar: Dokumentation / Frameworkbeschreibung, letztlich jedoch nur durch Einrei- chen im AppStore

Speicherverbrauch Sowohl der Speicherbedarf der Applikation als auch der Speicherplatz wäh- rend der Nutzung sollte möglichst gering sein. Insbesondere soll die Anwendung über eine mobile Netzwerkverbindung zu laden sein. (Zum Vergleich Status Quo. . . ) Überprüfbar: Implementierung

2.4.3 Weitere Kriterien

Entwicklung Das Kriterium Entwicklung umfasst diverse Aspekte. Allgemein gilt es, eine mög- lichst geringe Einarbeitungs- und Entwicklungszeit zu erreichen. Das wird beispielsweise durch verbreitete Programmiersprachen, bekannte Entwicklungsumgebungen und eine ein- fache Integration der Frameworks in letztere, unterstützt. Überprüfbar: Implementierung

Support & Dokumentation Die Einarbeitung und Entwicklung wird ebenfalls durch einen guten Support oder eine umfangreiche Dokumentation verbessert. Für die Bewertung wird unter anderem betrachtet, wie aktiv Support und Community den Entwickler unterstützen. Kurze Reaktionszeiten und hilfreiche Antworten führen zu einer besseren Bewertung. Ebenso wird die Detailliertheit der Dokumentation beurteilt, denn eine ausführliche Dokumentation minimiert Supportanfragen. Überprüfbar: Dokumentation, Aussagen der Community, Inanspruchnahme des Supports

Lizenz Die Lizenzen der unterschiedlichen Frameworks sollen hinsichtlich ihrer Beschränkungen und Kosten evaluiert werden. Überprüfbar: Lizenzbeschreibung des Frameworks

Plattform- und Geräteunabhängigkeit Der Kern dieser Arbeit ist es, die Plattform- und Gerä- teunabhängigkeit zu bewerten. Dies lässt sich vor allem aus der Wiederverwendung der einzelnen Fragmente für Programmlogik und grafische Oberflächenelemente ableiten. Op- timal wäre ein gemeinsamer Kern, der die gesamte funktionale Programmlogik enthält. Für die grafische Oberfläche wäre es ideal, dass ebenfalls ein gemeinsamer Kern, beispiels- weise durch eine Beschreibungssprache, existiert, der dann vom Framework automatisiert in ein passendes Layout mit plattformspezifischem Aussehen und Verhalten übersetzt wird. Überprüfbar: Implementierung

2.4 Anforderungen & Evaluationskriterien 9 Aktualität & Kompatibilität Zwei weitere Kriterien sind die Aktualität und Kompatibilität der Fra- meworks gegenüber verschiedenen Betriebssystemen und Versionen. Dabei ist es wichtig zu betrachten, ob entwickelte Apps zeitnah auf einer neuen Betriebssystemversion laufen und weiterhin auf alten Versionen unterstützt werden. Für die Aktualität spielen die Release- und Updateintervalle eine große Rolle, wobei an dieser Stelle nicht nur auf Quantität, son- dern auch auf Qualität und insbesondere auf Fehlerbehebungen, geachtet werden muss. Überprüfbar: Aktualität: Dokumentation / Frameworkbeschreibung; Kompatibilität: Imple- mentierung

Damit wurden, auf Basis des Anwendungsfalles, der Analyse der bisherigen Zugriffsmöglichkei- ten für das Informationssystem sowie der Analyse der spezifischen Möglichkeiten eines Tablets, die wichtigsten Anforderungen und Kriterien zur Evaluierung der verschiedenen plattformüber- greifenden Entwicklungsansätze festgelegt. Sie dienen im folgenden Kapitel als Grundlage für die Analyse und Bewertung der einzelnen Frameworks.

10 Kapitel 2 Anforderungsanalyse 3 GRUNDLAGEN UND STAND DER TECHNIK

Zunächst ist es notwendig, die verschiedenen Klassifikationen plattformübergreifender Frame- works vorzustellen. Anschließend wird ein Überblick über vorhandene Frameworks gegeben. Diese Frameworks wurden auf Basis der wichtigsten Kriterien aus [Fal12] und [Jon12] ausge- wählt.

Eines dieser Kriterien ist die Abdeckung der verschiedenen Plattformen, insbesondere sollen App- les iOS und Android unterstützt werden. Des Weiteren sind wesentliche funktionale Anforderun- gen, wie beispielsweise die Unterstützung von geografischen Sensoren (Geolocation), bei dieser Auswahl bereits beachtet worden.

Aufbauend auf dieser Analyse werden einige Frameworks im Detail vorgestellt und bezüglich der Eignung für den Anwendungsfall bewertet. Abschließend wird eines davon ausgewählt und einem Softwareentwicklungsprozess unterzogen, damit eingeschätzt werden kann, ob das Fra- mework für die effiziente plattformübergreifende Entwicklung geeignet ist.

3.1 KLASSIFIKATION MOBILER ANWENDUNGEN

Die Übersicht in Grafik 3.1 zeigt die Einteilung mobiler Anwendungen in verschiedene Klassen. Plattformübergreifende mobile Applikationen gehören vor allem in die Bereiche Mobile Weban- wendungen und hybride beziehungsweise interpretierte Anwendungen. Eine detaillierte Auf- schlüsselung der Kriterien für die einzelnen Klassen gibt Tabelle A.2 im Anhang auf Seite 44.

Mobile Webanwendungen sind im Wesentlichen Internetseiten, die auf mobile Endgeräte op- timiert worden sind. Von Vorteil ist die vergleichsweise schnelle Entwicklung und hohe Verfügbarkeit auf verschiedenen Plattformen. Allerdings wird permanent eine Datenver- bindung vorausgesetzt und die gerätespezifischen Funktionalitäten, wie beispielsweise die Kamerafunktion, können unter Umständen nicht genutzt werden. Hybride Anwendungen sind eine Kombination aus mobiler Internetseite und nativer Anwen- dung. Das jeweilige Framework stellt eine Browserkomponente als Container für eine mo- bile Webseite bereit. Dabei werden die Vorteile beider Varianten kombiniert und die Nach- teile der mobilen Internetseite ausgeschaltet. Ein weiterer Vorteil ist die Minimierung des

11 Native Anwendungen

Mobile Web- Hybride anwendungen Anwendungen Mobile Anwendungen Interpretierte Anwendungen

Generierte Anwendungen

Abbildung 3.1: Klassifikation von Entwicklungsansätzen mobiler Anwendungen, nach [Mro12,

Folie 6], modifiziert

Datentransfers, da nur noch Rohdaten und nicht mehr die gesamte Seite übertragen wer- den müssen. Zudem kann besser auf das Gerät und seine Daten (beispielsweise Kontakte)

zugegriffen werden.

Interpretierte Anwendungen werden in einer Programmiersprache (oder einer Kombination aus verschiedenen Programmiersprachen) für alle Plattformen entwickelt. Die plattformspezifi-

sche Übersetzung erfolgt zur Laufzeit. Generierte Anwendungen ähneln den interpretierten Anwendungen. Sie unterscheiden sich darin, dass generierte Anwendungen bereits zur Kompilierzeit übersetzt werden.

Im Gegensatz zur vorgeschlagenen Klassifikation in [Mro12], wurden hier die hybriden Anwen- dungen den mobilen Webanwendungen untergeordnet, während die interpretierten Anwendun- gen eine eigene Klasse bilden. Die Gemeinsamkeiten hybrider und mobiler Webanwendungen sind wesentlich größer, als die hybrider und interpretierter Anwendungen. Hybride Anwendun- gen kapseln die mobile Webanwendung, während interpretierte Anwendungen nicht zwingend an die Verwendung von Webelementen gebunden sind. In dieser Arbeit liegt der Schwerpunkt auf den Frameworks zur Entwicklung hybrider Anwendungen, während in [Wei12] Frameworks zur Erstellung interpretierter Anwendungen analysiert werden.

3.2 VORBETRACHTUNG

Im Folgenden wird eine Auswahl an existierenden Frameworks genauer analysiert, um daraus eine Vorauswahl für die prototypische Umsetzung zu treffen. Dies geschieht vor allem auf Basis der im letzten Kapitel vorgestellten Anforderungskriterien. Dazu werden Dokumentation und Bei- spielprojekte beziehungsweise Quelltextbeispiele der jeweiligen Frameworks untersucht. Sollten zwischen verschiedenen Frameworks aus funktionaler Sicht keine Unterschiede bestehen, so werden auch die Verbreitung und die Zukunftschancen der Frameworks mit in die Bewertung aufgenommen. Eine prototypische Umsetzung ist in dieser Phase nicht vorgesehen.

Apache Cordova ist die Fortführung des PhoneGap-Projekts als Open-Source-Projekt. Es dient zur Realisierung von hybriden Apps und ist nach Mono, welches in [Wei12] analysiert wird, das am zweithäufigsten eingesetzte Framework [Jon12]. Lediglich appMobi und Rhodes (Details in [Wei12]) bieten ähnliche Ansätze, haben aber entscheidende Nachteile.

12 Kapitel 3 Grundlagen und Stand der Technik appMobi ermöglicht die Entwicklung hybrider Apps in ähnlicher Weise zu Apache Cordova, al- lerdings nur für Android und iOS. Es existiert eine eigene Entwicklungsumgebung und eine umfangreiche Schnittstellensammlung für den Systemzugriff. In Verbindung mit einem UI- Framework (bevorzugt wird das zugehörige jqMobi) können Apps in gleicher Weise wie mittels Apache Cordova entwickelt werden. Dabei sind die Schnittstellen wesentlich umfangreicher als bei Cordova. Beispielsweise können sehr einfach „Push-Notifications“ eingebunden werden. Diese Benachrichtigungen sind jedoch ebenso, wie alle weiteren Zusatzfunktionen, die nicht auch in Cordova enthalten sind, an den kostenpflichtigen Cloud-Service von appMobi gebunden. Dieser schlägt (ab September 2012) mit 25 US-Cent je aktivem Nutzer im Monat zu Buche [app12]. Nach [Jon12, S. 34] verwenden etwa 16% der Entwickler dieses Framework, was jedoch nicht bedeutet, dass es für den produktiven Einsatz bestimmt ist. Auf Seite 37 der Studie wird noch erwähnt, dass „nur etwa 7% der Entwickler [diese Framework] als nächstes Werkzeug“ wählen würden. Hinzu kommt, dass das UI-Framework jqMobi zwar eine fertige Oberfläche für berührungs- sensitive Geräte generiert, diese aber kein natives Look and Feel besitzt. Application Craft ist eine cloudbasierte Entwicklungsplattform. Im Unterschied zu anderen Fra- meworks werden keine clientseitigen Installationen benötigt, die gesamte Entwicklung fin- det im Browser statt und bedarf lediglich einer Internetverbindung, um an einem beliebigen Ort zu entwickeln. Dabei steht eine vollwertige Entwicklungsumgebung, bestehend aus einem Quelltexteditor, einem (grafischen) Editor für die grafische Oberfläche, einem De- bugger und Versionsmanagement, zur Verfügung. Ziel des Anbieters ist es, die entstandenen Anwendungen über die eigenen, serverseitigen Dienste zu einer fertigen Anwendung zu packen und zu verteilen. Alternativ kann, in Ver- bindung mit Apache Cordova, eine hybride App entwickelt werden. Für die Entwicklung der App selbst wird HTML5 in Verbindung mit dem jQuery Mobile UI-Framework verwendet, welches später separat vorgestellt wird. Zusammenfassend ist Application Craft nicht wesentlich mehr als eine umfangreiche, cloud- basierte Entwicklungsumgebung, in der die grafische Oberfläche per Drag and Drop zu- sammengesetzt werden kann. Die Vor- und Nachteile von jQuery Mobile werden später noch vorgestellt. Dazu kommen die serverseitigen Deploymöglichkeiten, erweiterte Sy- stemschnittstellen stehen nur in Verbindung mit Apache Cordova zur Verfügung. iUI ist ein UI-Framework in JavaScript zur Gestaltung von HTML-Seiten. Dabei wird der HTML- Quelltext mit verschiedenen Annotationen (beispielsweise CSS-Klassen) versehen. Die Ent- wicklung gestaltet sich dadurch recht einfach, allerdings ist das Framework nicht sehr mäch- tig, was vor allem für die Entwicklung von Tablet-Apps ein Nachteil ist. Das Framework unterstützt keine Bedienkonzepte eines Tablets und orientiert sich auch sonst sehr stark an Bedienkonzepten des iPhones. Dadurch wird kein natives Feeling erreicht, vor allem nicht unter Android. Ursache dafür ist vor allem ein ungewohntes Scrollverhalten, denn die obe- ren und unteren Steuerleisten scrollen beim Bewegen der Seite mit. Die Gestaltung der Oberfläche kann für iOS und Android als annähernd nativ bezeichnet werden, wobei das Android-Design der Version 2.x entspricht. Unterschiedliche Designs werden durch unter- schiedliche Stylesheets erreicht. Neben der einfachen Entwicklung bietet das Framework wenig Positives. Vor allem die mangelhaften Bedienkonzepte, insbesondere für Tablets, sprechen gegen eine prototypi- sche Umsetzung. JQ Touch ist ebenfalls ein UI-Framework in JavaScript für Android und iOS. Das Framework ba- siert auf Zepto.js, einer optimierten jQuery-Version für Webkit. Die Entwicklung erfolgt durch Kombination von HTML und JavaScript. Eine verfügbare Demo-Anwendung zeigt je- doch verschiedene kleinere Fehler, beispielsweise beim Scrollen. Die Gestaltung der Ober- fläche erfolgt über Stylesheets, wobei ein iOS-Design mitgeliefert wird. Über Bedienkon- zepte für Tablets kann keine Aussage getroffen werden, da es zu diesem Framework kei- nerlei hilfreiche Dokumentation des Entwicklers gibt, obwohl das Projekt bereits seit 2009 existiert. Eine weitere Betrachtung findet deshalb nicht statt.

3.2 Vorbetrachtung 13 jQuery Mobile ist eine Erweiterung des jQuery-Frameworks und wird von deren Entwicklern vorangetrieben. Die Entwicklung erfolgt wie bei JQ Touch in Kombination von HTML, Java- Script und CSS. Gegenüber den anderen UI-Frameworks, die auf gleichem Prinzip arbeiten, hat es den entscheidenden Vorteil, dass eine Unterstützung für Windows Phone zusätzlich zu den gängigen Webkit-Plattformen besteht. Ansonsten sind Vor- und Nachteile ähnlich wie bei den bereits genannten UI-Frameworks. Jo HTML5 Mobile App Framework ist ebenfalls ein UI-Framework zur Erstellung mobiler An- wendungen. Die Entwicklung erfolgt dabei objektbasiert in JavaScript und bedarf kaum HTML-Kenntnissen. Nach Entwicklerangaben werden iOS, Android und das Blackberry Play- book unterstützt. Die grafische Oberfläche ist für berührungssensitive Geräte ausgelegt, allerdings entspricht sie in ihrer Farbgebung keiner der gängigen Plattformen. Sie erinnert optisch vielmehr an Anwendungen, die noch vor der Jahrtausendwende entstanden sind, soll aber durch CSS-Anpassungen beliebig geändert werden können. Das Bedienkonzept orientiert sich sehr stark am iPhone und ist nicht für Tablets geeignet. Ein kritisches Pro- blem sind Unregelmäßigkeiten im Scrollverhalten, welche dem Entwickler bekannt sind. Im günstigsten Fall sehen die Animationen beim Scrollen schlecht aus, im ungünstigsten Fall, wird das Layout der Seite zerstört. Einerseits kann durch den modularen Aufbau zwar sehr schnell entwickelt werden, anderer- seits sind die Bedienkonzepte mangelhaft, es entsteht kein natives Look and Feel und das Scrollverhalten ist oft fehlerhaft. Letztlich kommt noch hinzu, dass das Entwicklerteam mit hauptsächlich zwei Personen sehr klein und die Zukunft des Projekts schwer einzuschätzen ist. GWT Das Google Web Toolkit ermöglicht die Entwicklung von Webanwendungen mittels Java, ähnlich zu Swing oder Eclipse SWT. Obwohl das Konzept sehr vielversprechend ist, konnte es sich auf dem mobilen Markt bisher nicht durchsetzen, was vor allem daran liegt, dass mobile Endgeräte regulär nicht unterstützt werden. Diverse Entwicklergruppen haben ver- schiedene Erweiterungen vorgenommen, um GWT auch für mobile Endgeräte einsetzen zu können. Dadurch entstehen jedoch viele Abhängigkeiten, welche bei Einstellung eines Teilprojekts dazu führen können, dass die Anwendung nicht mehr weiter entwickelt wer- den kann. Unterstützt werden Android und iOS, in Verbindung mit der Erweiterung mgwt kann für beide Plattformen ein sehr natives Look and Feel erreicht werden. Eine zusätzli- che Erweiterung (gwt-phonegap), ermöglicht die Einbettung in Apache Cordova. Kritisch ist dennoch die starke Fragmentierung der einzelnen Frameworkbestandteile, einzelne wurden bereits seit 2010 nicht mehr aktualisiert. Sencha Touch ist in erster Linie ein JavaScript-Framework, das sich jedoch nicht auf die Gene- rierung und Gestaltung der Oberfläche beschränkt. Zusätzlich werden verschiedene Mittel für Datenhaltung und Persistierung mitgeliefert. Außerdem steht ein umfangreiches Model- View-Controller-Prinzip zur Verfügung. Dieses umfangreiche Framework erschien erst kürz- lich in einer neuen Version (2.0), die vor allem durch Geschwindigkeitssteigerungen über- zeugen soll. Nach [Jon12, S. 34] ist es mit 30% eines der meist verwendeten Frameworks und wird laut [Jon12, S. 8] von knapp 10% der Entwickler produktiv eingesetzt. qooxdoo ist ein Framework, welches kaum Unterschiede zu Sencha Touch beziehungsweise deren Basis-Framework ExtJS aufweist. Auch qooxdoo verfolgt das Ziel, komplexe Weban- wendungen nach dem MVC-Prinzip entwickeln zu können. Teilweise entsteht der Eindruck, dass es sich um dasselbe Framework handelt, vor allem bei Betrachtung der Detailimple- mentierungen. Dennoch gibt es Vor- und Nachteile gegenüber Sencha Touch. Ein Vorteil ist die wesentlich einfachere Gestaltung von Tablet-Oberflächen. Seit der neuesten Version wird die Unterteilung in Master- und Detail-Ansicht unterstützt, was dem Bedienkonzept des iPads entspricht. Die Verwendung scheint wesentlich einfacher als die gerätespezifischen Profile unter Sencha Touch, ist dafür aber nicht sehr feingranular. Von Nachteil sind diverse Fehler, die unregelmäßig auftreten, darunter beispielsweise leere Seiten. Für Sencha Touch spricht auch die Lizensierung: qooxdoo steht unter LGPL oder EPL bereit, während Sencha neben GPL eine eigene kommerzielle Lizenz anbietet, die allerdings kostenfrei ist.

14 Kapitel 3 Grundlagen und Stand der Technik Zur Entwicklung hybrider Apps ist der Einsatz von Apache Cordova unerlässlich. Alternativen, wie appMobi, Application Craft oder Rhodes, bieten zwar durchaus interessante Erweiterungen, welche jedoch meist mit Mehrkosten und vor allem einer direkten Bindung an den Anbieter ver- bunden sind. Derartige Abhängigkeiten können im Falle einer Einstellung des Projekts zur voll- ständigen Neuentwicklung der Anwendung führen und das sollte vermieden werden. Zudem ist die Verlagerung der Entwicklung in die Cloud, wie es bei Application Craft der Fall ist, für viele Un- ternehmen aus Datenschutzgründen nicht denkbar. Durch die Verwendung von Apache Cordova lassen sich diese Abhängigkeiten ohne Verzicht auf wichtige Funktionen vermeiden.

Bei den einfachen UI-Frameworks iUI, JQ Touch, jQuery Mobile sowie Jo HTML5 sind die Unter- schiede recht gering. Der Entwicklungsaufwand ist auf Grund fehlender beziehungsweise man- gelhafter Implementierung für Datenanbindung und -haltung wesentlich höher im Vergleich zu Sencha Touch oder qooxdoo. Durch starke Plattformunabhängigkeit überzeugt besonders jQuery Mobile, welches als einziges Unterstützung für Windows Phone bietet. Eine prototypische Um- setzung des Anwendungsfalls soll daher Aufschluss über die Eignung von jQuery Mobile (in Ver- bindung mit Apache Cordova) für plattformübergreifende Entwicklung geben.

Das Google Web Toolkit bietet einen durchaus interessanten Ansatz zur Entwicklung von (mobi- len) Webanwendungen, doch die starke Fragmentierung der notwendigen Bibliotheken und die damit verbundenen Abhängigkeiten gefährden eine langfristig stabile Projektentwicklung. Die Unterschiede zwischen Sencha Touch und qooxdoo sind hingegen dermaßen gering, dass die Entscheidung durchaus dem Zufall überlassen werden könnte. Dennoch soll die prototypische Umsetzung mit Sencha Touch vorgenommen werden, da die verfügbaren Demonstrationsanwen- dungen deutlich weniger Fehler aufweisen und die kommerzielle Lizenz für Unternehmen deut- lich überschaubarer ist als etwa LGPL oder EPL. Dazu kommt, dass in einer früheren Projektarbeit bereits überzeugende Ergebnisse in Verbindung mit Sencha Touch erreicht werden konnten. Die größte Schwachstelle war die Reaktionszeit der grafischen Oberfläche, welche in der Version 2.0 wesentlich kürzer sein soll.

3.3 JQUERY MOBILE jQuery Mobile1 ist eine Erweiterung des jQuery2 JavaScript-Frameworks. Es wurde daraufhin optimiert, eine angepasste Oberfläche für berührungssensitive Geräte bereitzustellen. Es handelt sich dabei jedoch um ein reines UI-Framework, was zur Folge hat, dass für eine Verbreitung über plattformtypische Vertriebswege zusätzlicher Aufwand (beispielsweise durch Einbettung in Apache Cordova) notwendig ist.

Das bedeutet ebenfalls, dass plattformnahe Funktionen, wie Kamerafunktionen, Zugriff auf Kon- takte oder Geolocation, nur dann verfügbar sind, wenn sie von einem einbettendem Framework zur Verfügung gestellt werden. Die Analyse hat jedoch gezeigt, dass alle UI-Frameworks, außer Sencha Touch 2, ein derartiges Framework benötigen.

Eine prototypische Implementierung, bestehend aus jQuery Mobile in Apache Cordova, hat noch weitere kritische Aspekte aufgezeigt. Sie besteht aus einem sehr einfach gehaltenen Anwen- dungsfall, der einen Informationsstrom und zugehörige Details darstellt und das Schreiben einer Nachricht ermöglicht. Die Standardoberfläche bietet dem Anwender kein natives Look and Feel. Die plattformuntypische Farbgebung kann durchaus positiv gewertet werden, da sie umgestaltet werden kann und die Umsetzung eines eigenen Corporate Designs leicht ermöglicht. Kritischer wird es beispielsweise bei Formularelementen, deren Formen sich keiner gängigen Oberfläche der verschiedenen Plattformen zuordnen lassen. Ebenso ist das Verhalten bei Interaktionen, so- wohl für iOS als auch für Android, durchaus untypisch. Lediglich das Scrollverhalten ist das beste unter den getesteten Frameworks.

1http://jquerymobile.com 2http://jquery.com

3.3 jQuery Mobile 15 Ein weiterer Negativpunkt ist die Umsetzung einer Oberfläche, welche für Tablets geeignet ist. Verschiedene Profile oder Layouts für unterschiedliche Geräte(-typen) sind von jQuery Mobile nicht vorgesehen. Es können lediglich Blocklayouts genutzt werden, um den Platz sinnvoll auszu- nutzen, allerdings bedarf beispielsweise der iOS-typische Splitview (Grafik B.5, S. 49) einer sehr komplexen JavaScript- und Stylesheetanpassung, sodass der Aufwand in keiner Relation zum Nutzen steht.

Es bleibt nur die Möglichkeit, mehrere Designs parallel zu gestalten und das für die jeweilige Platt- form passende einzubinden. Dies gestaltet sich besonders unter Android schwierig, da entweder verschiedene Apps ausgeliefert oder die Oberflächen zur Laufzeit geladen werden müssen. Spe- ziell Letzteres ist schwierig unter Android, da zur Laufzeit nur sehr schwer erkannt werden kann, ob es sich um ein Tablet oder ein Smartphone handelt.

Für die Umsetzung der Anwendungslogik stehen, abgesehen von einem optimierten Netzwerk- zugriff, keine besonderen Funktionen bereit. Das Laden, Manipulieren und Verwalten von Daten muss ebenso in Eigenregie bewältigt werden wie die Bindung der Daten an die grafische Ober- fläche. Das Hochladen von Bild- beziehungsweise Dateianhängen ist nur sehr eingeschränkt, im aktuellen Anwendungsfall überhaupt nicht möglich. jQuery Mobile trägt daran allerdings keine Schuld, denn JavaScript kann nur schlecht mit Binärdaten umgehen, da die Netzwerkanfragen nur auf Zeichenketten basieren und Binärdaten dadurch auf Empfängerseite falsch interpretiert wer- den können. Eine Lösung ist die Übertragung einer zuvor kodierten Binärdatei. Mittels Base64- Kodierung können Binärdaten in reinen ASCII-Code umgewandelt werden, sodass eine Übertra- gung via XMLHttpRequest möglich ist. Die serverseitige Implementierung unterstützt dieses Verfahren derzeit jedoch noch nicht.

Alles in allem ist jQuery Mobile ein sehr gutes Framework, um bestehende Webseiten für be- rührungssensitive Geräte zu optimieren, was vor allem daran zu erkennen ist, dass es sich um eine Art Annotationen für HTML handelt. Für die Entwicklung von Apps, speziell für Tablet-Apps, ist dieses Framework jedoch ungeeignet, da es keine tiefergehenden Bedienkonzepte unterstützt oder diese nur mit viel Aufwand realisiert werden können.

3.4 SENCHA TOUCH

Einen gänzlich anderen Ansatz wählt Sencha Touch3. Erst kurz vor Beginn der Arbeit erschien die Version 2.0 dieses Frameworks. Entwickelt wird hauptsächlich in JavaScript, wobei in Sencha Touch, welches auf dem ExtJS Framework basiert, objektorientiert gearbeitet wird.

Eine Besonderheit von Sencha Touch ist die Möglichkeit, ohne ein weiteres Framework, wie bei- spielsweise Apache Cordova, auszukommen. Seit der Version 2.0 können Sencha Apps direkt für Android und iOS nativ gepackt werden. Dazu steht auch eine Schnittstelle für gerätespezifi- sche Aktionen, wie Kamera oder Geolocation bereit. [Avi12] Allerdings ist diese Schnittstelle arg limitiert und (derzeit) nicht erweiterbar. Bezogen auf den Anwendungsfall, ist diese Schnittstelle nicht ausreichend, sodass weiterhin ein zusätzliches Framework notwendig ist.

In diesem Fall ist es Apache Cordova, da die Entwickler von Sencha Touch bereits einige wesent- liche Implementierungen dafür vorgenommen haben, sodass man die Sencha API nutzen kann und nicht direkt auf Apache Cordova zurückgreifen muss.

Sencha Touch bietet ein ausgeklügeltes Model-View-Controller-Prinzip:

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

16 Kapitel 3 Grundlagen und Stand der Technik Views werden aus verschiedenen Komponenten (Containern und zugehörigen Elementen, bei- spielsweise Formularelemente) in JavaScript zusammengesetzt. Dabei kann auf Vererbung zurückgegriffen werden, um eigene Komponenten (beispielsweise Listen mit kontextspezi- fischem Layout) zu entwickeln und diese dann an beliebiger Stelle einzusetzen. Der Grad an Wiederverwendbarkeit ist dadurch sehr hoch. Aus dieser Zusammensetzung von Kom- ponenten wird letztlich HTML generiert, was den Entwickler jedoch kaum tangiert, da er selbst nicht damit arbeiten muss.

Controller nutzen dafür die DOM-Struktur der generierten HTML-Seiten sehr intensiv. Zum Bei- spiel werden damit Komponenten und Elemente der Seite für die Weiterverwendung im Controller referenziert. Gegebenenfalls können diese Komponenten automatisch generiert werden, wenn sie nicht existieren. Diese Referenzen werden einerseits genutzt, um mit den zugehörigen Komponenten zu interagieren (Werte abfragen oder manipulieren, Einstel- lungen vornehmen), andererseits werden darüber Ereignisse an die Komponenten gebun- den (beispielsweise die Berührung eines Listeneintrags). Der Vorteil ist, dass Controller nicht direkt an Views gebunden sind, sondern durchaus nur eine Komponente steuern. Die Granularität ist dem Entwickler überlassen. Zudem unterstützen die Controller in Sencha Touch die besonderen Funktionen der Browserhistorie von HTML5 und können aus den jeweiligen Routen die entsprechenden Seiten generieren.

Model Das Datenmodell von Sencha-Applikationen bietet initial sehr umfangreiche Möglichkei- ten. Es können, ähnlich zu anderen Programmiersprachen, wie beispielsweise Java, Da- tentypen festgelegt und gleichzeitig Validierungsmethoden angegeben werden. Weiterhin besteht die Möglichkeit, einen sogenannten Proxy an das Modell zu binden, der für die Abfrage der Daten, etwa über eine REST-API, zuständig ist. Die Ergebnisse der Abfrage werden automatisch in die angegebenen Datenformate konvertiert. Jede Modellinstanz be- sitzt zudem Methoden, um Daten über diesen Proxy zu lesen oder zu schreiben. Die mit etwas Aufwand verbundenen XMLHttpRequests übernimmt das Framework selbstständig.

Ein weiterer Pluspunkt ist die Gestaltung durch Cascading Stylesheets. Im Gegensatz zu jQuery Mobile werden von den Entwicklern bereits fertige Designs für iOS, Android und Blackberry mit ausgeliefert und zumindest für iOS und Android sehen diese Designs den nativen Umgebungen sehr ähnlich, wobei dies für iOS noch stärker gilt, denn für Android. Gleiches gilt für das Bedien- konzept und -verhalten auf beiden Plattformen. Lediglich die Unterstützung des „Zurück“-Buttons unter Android ist nur umständlich über die HTML5 Location-History zu lösen. Einziger Minuspunkt an dieser Stelle für beide Plattformen, die Geschwindigkeit beim Scrollen ist langsamer als für die Plattform gewöhnlich, unter Android systembedingt jedoch wesentlich langsamer als unter iOS. Das Übertragen von Binärdaten ist, aus gleichen Gründen wie bei jQuery Mobile, nicht möglich.

Die prototypische Umsetzung macht sonst einen sehr stabilen Eindruck. Der umgesetzte Anwen- dungsfall ermöglicht das Anzeigen mehrerer Informationsströme, einer Personen- und Themen- übersicht sowie das Verfassen von Nachrichten.

Zusammengefasst ist Sencha Touch 2 ein sehr gutes Framework, das in Verbindung mit Apache Cordova allen Anforderungen des Anwendungsfalls, abgesehen von der Reaktionszeit, gerecht wird. Es eignet sich sehr gut für die schnelle und kostengünstige Entwicklung von kleineren, einfachen Anwendungen für verschiedene Plattformen, sollte bevorzugt aber als mobile Webseite und nicht als hybride App ausgeliefert werden, da die Reaktionszeiten auf Grund der aktivierten JavaScript-Compiler besser sein können.

3.4 Sencha Touch 17 3.5 APACHE CORDOVA (PHONEGAP)

Es wurde bereits mehrfach angesprochen und soll nun genauer analysiert werden: Apache Cor- dova4, bislang bekannt als PhoneGap. Die Entwicklerfirma und das Produkt PhoneGap wurden im November 2011 von Adobe aufgekauft. Die Projektbasis (früher als Projekt „Callback“ bezeich- net) bleibt weiterhin Open Source und bildet „das, was WebKit für Chrome oder Safari ist“ - so die Entwickler. Zum Zeitpunkt dieser Arbeit unterscheiden sich PhoneGap und Cordova nur im Namen. [Ler12]

Cordova ist ein Framework zur Realisierung von hybriden Apps. In erster Linie wird ein Browser bereitgestellt, der ähnlich mächtig zum herkömmlichen Browser ist, aber ohne Navigationsleisten und andere Dinge auskommt. Die Schnittstellen (Kamera, Geolocation, etc.) sind jedoch gleich oder werden bei Bedarf durch Cordova ersetzt und erweitert.

Der wohl größte Vorteil ist die einfache Entwicklung in Verbindung mit Cordova. Die Anwendung selbst kann nahezu vollständig innerhalb eines herkömmlichen Desktop-Browsers entwickelt wer- den und muss lediglich für die finalen Abstimmungen und Tests auf dem Endgerät ausgeführt werden. Dazu kommt die Vielzahl an unterstützten Plattformen. Neben Android und iOS werden auch Blackberry, Windows Phone, Web OS, Palm und Bada unterstützt. Spezielle Anpassungen sind dabei nur für die unterschiedlichen Browser notwendig, ähnlich zu den browserspezifischen Anpassungen für Desktop-Browser.

Ein weiterer Vorteil ist die Einbettung des Frameworks in die plattformspezifische Entwicklungs- umgebung. Damit ist es das einzige unter den betrachteten Frameworks, was nahezu unabhän- gig von neuen Versionen und Veränderungen der Herstellersoftware ist. Zusätzlich kann Cordova durch eigene Plugins erweitert werden, um beispielsweise native UI-Elemente zu nutzen oder Hintergrundoperationen auszuführen. Es existiert bereits eine Vielzahl an frei verfügbaren Plug- ins, die zur Integration in Cordova genutzt werden können, beispielsweise zur Realisierung von In-App-Käufen unter iOS.

Bei der prototypischen Umsetzung wurden jedoch auch einige Probleme festgestellt. Auf Grund der schnelleren Simulationsumgebung für iOS wurde die App zuerst dafür entwickelt und an- schließend auf Android portiert. Dort ließ sie sich erst überhaupt nicht starten. Ursache dafür ist die wesentlich kompliziertere Konfiguration gegenüber iOS. Während unter iOS lediglich die entwickelte Webseite im Projektordner abgelegt werden muss und die meisten Einstellungen be- reits korrekt sind, so muss unter Android die komplette Projektkonfiguration selbst übernommen werden.

Ein zusätzliches und vor allem sehr häufig auftretendes Problem unter Android sind Zeitüber- schreitungen beim Laden der eingebetteten Seite. Verstärkt wird dieses Phänomen durch das Laden von externen Inhalten (beispielsweise CSS-Dateien von einem entfernten Server), unab- hängig von der verfügbaren Netzwerkverbindung. Unerklärlich ist auch das unterschiedliche Ver- halten von Android-Emulator und physischen Endgeräten. Während die Anwendung im Emulator einwandfrei funktioniert, startet die Anwendung auf dem Endgerät gar nicht oder hat mit den bereits erwähnten Timeouts zu kämpfen, obwohl eine WiFi-Verbindung besteht.

Die beiden UI-Frameworks Sencha Touch und jQuery Mobile haben das Problem des Datentrans- fers von der Clientapplikation zum Server verdeutlicht. Apache Cordova bietet aus diesem Grund eine eigene Implementierung für den Transfer von Binärdaten in beide Richtungen. Prototypi- sche Umsetzungen dieser Schnittstellen haben jedoch keinen Erfolg gezeigt. Hauptursache ist, dass diese Netzwerkanfrage nicht weiter beeinflusst werden kann und deshalb ganz bestimmte Voraussetzungen an die serverseitige Implementierung stellt.

Die größte Schwierigkeit ist jedoch das Debugging von Anwendungen. Praktisch steht nur die JavaScript-Konsolenausgabe zur Verfügung. Ein genaues Analysieren der DOM-Struktur sowie

4http://incubator.apache.org/cordova, auch http://www.phonegap.com

18 Kapitel 3 Grundlagen und Stand der Technik das Setzen von Breakpoints ist nicht möglich. Ein wenig Abhilfe schafft der Einsatz des Remote- Debuggers wein.re (Web Inspector Remote). Damit können immerhin die DOM-Struktur analy- siert und die interaktive JavaScript-Konsole genutzt werden. Breakpoints können dennoch nicht gesetzt werden. Daher sollte, wie eingangs erwähnt, die Entwicklung hauptsächlich im Desktop- Browser vorgenommen werden.

3.6 ERGEBNIS

Auf Basis der theoretischen Betrachtungen und prototypischen Umsetzungen der letzten Kapitel sowie aus [Wei12] muss nun das Framework ausgewählt werden, das sowohl den geringsten Entwicklungsaufwand als auch die größtmögliche Plattformunabhängigkeit bietet. Dabei dürfen funktionale und nicht-funktionale Kriterien nicht außer Acht gelassen werden.

Folgende Frameworks wurden in beiden Arbeiten detailliert betrachtet:

• jQuery Mobile

• Sencha Touch

• Apache Cordova

• MoSync

• Rhomobile (Rhodes)

• Appcelerator Titanium

Das UI-Framework jQuery Mobile überzeugt durch seine Flexibilität bezüglich der Plattformen. Es ist das einzige UI-Framework, das Unterstützung für Windows Phone anbietet. Dies ist zwar kein wesentlicher Bestandteil der Betrachtung, doch auch die Zukunft der Frameworks spielt eine nicht zu unterschätzende Rolle. Der entscheidende Nachteil ist, dass eine Umsetzung für Tablets sehr aufwendig in der Entwicklung ist, weil dafür keine Unterstützung vom Framework geboten wird. Dazu kommen zwingend notwendige Anpassungen der grafischen Oberfläche, die wie- derum mehr Entwicklungsaufwand verursachen, weil diese für alle Plattformen nahezu separat durchgeführt werden müssen.

MoSync könnte sich ebenfalls durch seine Plattformunabhängigkeit hervorheben. Diese besteht jedoch nur in der Theorie, da aktuelle Betriebssysteme wie iOS 5 oder Android ab Version 3 nicht offiziell unterstützt werden. Dabei stehen mit iOS 6 und Android 5 schon die Nachfolger der aktuellsten Versionen bereit.

Ähnliches gilt für Rhomobile, denn auch dieses Framework unterstützt theoretisch alle wichti- gen Plattformen. Die prototypische Umsetzung hat jedoch gezeigt, dass beispielsweise eine framework-eigene Implementierung der Tab-Leiste ein fehlerhaftes Verhalten unter Android auf- weist. Dieser Fehler muss plattformspezifisch behoben werden und hat Einschränkungen im Bedienkomfort zur Konsequenz. Hinzu kommt noch, dass verschiedene Technologien direkt im Quelltext miteinander kombiniert werden und für wenig Übersicht sorgen. Außerdem besteht die Struktur jeder erzeugten App aus mehreren Tabs, was die Gestaltung stark einschränkt. Für die Gestaltung der grafischen Oberfläche wird jQuery Mobile eingesetzt, dessen Nachteile bereits erläutert wurden.

Übrig geblieben sind die beiden Favoriten der jeweiligen Arbeiten: Appcelerator Titanium und Apache Cordova in Kombination mit Sencha Touch 2 (nachfolgend als ein Framework betrachtet). Die theoretische Betrachtung der beiden Frameworks liefert keine gravierenden Unterschiede,

3.6 Ergebnis 19 jedes Framework hat seine eigenen kleinen Vor- und Nachteile, welche vom anderen wieder aus- geglichen werden. Die prototypische Umsetzung lässt zudem keine Wünsche offen, was die Funktionalität angeht. Bei der Betrachtung des Entwicklungsaufwands hat Sencha Touch jedoch eindeutig Vorlauf, da es mit weniger Aufwand die gleiche Funktionalität auf alle verfügbaren Platt- formen bringt. Dies ist zugleich der Nachteil von Appcelerator Titanium. Die Entwicklung der grafischen Oberfläche muss nötigenfalls für jede Plattform separat durchgeführt werden. Dafür reagiert die Applikation wesentlich schneller und fühlt sich etwas nativer an.

Als Zwischenfazit kann festgehalten werden, dass eine optimale Lösung, bestehend aus größt- möglicher Plattformunabhängigkeit kombiniert mit hohem Bedienkomfort sowie geringstem Ent- wicklungsaufwand, nicht existiert. Entweder müssen Einschränkungen im Bedienkomfort oder ein höherer Entwicklungsaufwand in Kauf genommen werden.

Letzte Aufschlüsse sollte eine praktische Evaluierung der verschiedenen prototypischen Umset- zungen liefern. Diese wurde im Rahmen der Zwischenpräsentation durchgeführt. Dazu wurden, auf Basis der bisherigen Erkenntnisse und ohne vorher bekannt zu geben, welches Framework sich hinter der jeweiligen Implementierung verbirgt, die prototypischen Umsetzungen den anwe- senden Zuschauern zur eigenen Nutzung überlassen. Vier Prototypen konnten getestet werden, darunter jeweils eine native Umsetzung für iOS und Android, jQuery Mobile, Appcelerator Tita- nium und Apache Cordova in Kombination mit Sencha Touch 2. Zunächst wurde den Zuschauern ein Zeitfenster von etwa zehn Minuten eingeräumt, in welchem sie die verschiedenen Implemen- tierungen auf unterschiedlichen Geräten testen und ihre Erfahrungen untereinander austauschen konnten. Anschließend wurden in einer gemeinsamen Diskussion die Vor- und Nachteile der ein- zelnen Prototypen nochmals zusammengefasst und aufgelöst, welches Framework sich hinter welcher Implementierung verbirgt.

Die Ergebnisse dieser Evaluierung sind teilweise überraschend. Die prototypische Umsetzung mittels jQuery Mobile schneidet wie erwartet am schlechtesten ab. Sencha Touch liefert unter iOS ein solides Bild, allerdings treten unter Android sehr lange Reaktionszeiten auf. Die Überra- schung: Appcelerator Titanium erhält bessere Bewertungen in Bezug auf das Look and Feel als die nativen Umsetzungen auf den jeweiligen Plattformen.

Die sinnvollste Lösung ist die Fortführung der Entwicklung mit Appcelerator Titanium. Dies be- deutet zwar einen höheren Entwicklungsaufwand, was jedoch durch wesentlich bessere Bedien- barkeit relativiert wird. Die prototypischen Umsetzungen mittels Sencha Touch können nicht be- schleunigt werden. Letztlich sorgt die daraus resultierende schlechte Bedienung unter Android zum Ausscheiden von Apache Cordova in Kombination mit Sencha Touch.

Abschließend werden in Tabelle 3.1 auf den folgenden zwei Seiten noch einmal die wesentlichen Kriterien der hier vorgestellten Frameworks in einer Übersicht zusammengetragen, sodass deren Vor- und Nachteile schnell verglichen werden können.

20 Kapitel 3 Grundlagen und Stand der Technik Tabelle 3.1: Anforderungs- und Evaluationskriterien

Kriterium Titanium Cordova + Sencha Cordova + jQuery Rhodes MoSync Touch Mobile Fotoanhänge (Kamera, Bilder) + + ◦ ◦ ◦ Dateianhänge + + + ◦ + Geolocation + + + + + Eigene Inhalte teilen + ◦ ◦ -- Gestenunterstützung + ◦ ◦ ◦ + Verwendung nativer + ◦ - - + UI-Elemente Look and Feel nativ annähernd nativ - - nativ Reaktionszeit sehr schnell schnell schnell akzeptabel schnell Rich-Text-Editor - ◦ --- alt. Tastaturanpassung ◦ -- ◦ Signalisierung von Nachrichten + ◦ ◦ -- Hintergrundprozesse (Android) + + + ◦ ◦ Persistierung + ◦ ◦ ◦ + Verschlüsselung ◦ ◦ ◦ + - I18n + ◦ - ◦ ◦ Kontaktezugriff + + + - - Datenkomprimierung ◦ - - + + Datenübertragung + + + ◦ + . Ergebnis 3.6 App-Auslagerung (Android) + + + + + Umsetzung ist: + sehr gut möglich ◦ möglich, aber aufwendig - nicht möglich 21 22 Tabelle 3.1: Anforderungs- und Evaluationskriterien aie rnlgnudSaddrTechnik der Stand und Grundlagen 3 Kapitel Kriterium Titanium Cordova + Sencha Cordova + jQuery Rhodes MoSync Touch Mobile Akzeptanz im Appstore XXXXX Einarbeitungsaufwand gering gering gering neutral neutral / hoch Entwicklungsaufwand mäßig gering hoch hoch mäßig Detailliertheit der ++ ++/++ ++/+ - ◦ Dokumentation Aktivität der Community ++ ++/++ ++/++ + ◦ Antwortzeiten des Supports in der Regel kostenpflichtig und abhängig von gewählter Variante Release- und Updatezyklen kurz kurz kurz lang lang Kompatibilität mit ++ ++ ++ ◦ - verschiedenen Betriebssystemversionen5 Lizenzbedingungen APL APL / eigene6 APL / MIT, GPL MIT GPL Lizenzkosten frei frei frei frei frei Entwicklungsumgebung ++ ++ (nativ) ++ (nativ) - - Programmiersprachen JavaScript / JavaScript / HTML5 JavaScript / HTML5 Ruby / HTML / Ja- C++ / HTML5 / Ja- Module nativ vaScript vaScript Kompatibilität + ++ ++ + - Plattform- und + ++ + - - Geräteunabhängigkeit ++ sehr gut + gut ◦ ausreichend - schlecht

5insbesondere Unterstützung der aktuellsten Versionen (iOS 5, Android 4) 6Sencha Touch verfügt über eine kostenfreie, kommerzielle Lizenz 4 KONZEPTION

Das Titanium-Framework von Appcelerator wird für die weitere Entwicklung der Anwendung ver- wendet. Die bisherige prototypische Umsetzung der Anwendung diente vor allem der Evaluie- rung des Frameworks und war weniger auf eine effiziente plattformübergreifende Entwicklung hin optimiert.

Für die weitere Entwicklung wurde ein Konzept benötigt, das sowohl den gestellten Anforderun- gen an die Anwendung selbst, wie auch der Umsetzung einer größtmöglichen Plattformunab- hängigkeit gerecht wird. Die folgenden Abschnitte dieses Kapitels sollen das zugrunde liegende Konzept genauer vorstellen und seine Umsetzung mittels Titanium genauer beleuchten und be- werten.

4.1 ALLGEMEINE KONZEPTION

Das Ziel dieser Arbeit ist die Bewertung plattformübergreifender Entwicklungsansätze für Smart- phones. Diese Zielstellung war bereits ein zentrales Kriterium bei der Betrachtung und Bewer- tung der Frameworks und muss nun ebenfalls in der Konzeption der Anwendung berücksichtigt werden. Nicht alle Anforderungen lassen sich plattformunabhängig umsetzen, sodass getrennte Entwicklungszweige notwendig werden. Speziell im Bereich der Nutzerschnittstelle werden sol- che plattformspezifischen Entwicklungszweige unumgänglich sein, wobei die Konzeption der An- wendung eine möglichst große Plattformunabhängigkeit mit den nativen Mitteln des gewählten Frameworks garantieren soll.

Es ist daher notwendig, die Anwendung grob in zwei Teile zu teilen. Bei dem ersten Teil handelt es sich um das sogenannte Backend, welches nach außen geschlossen auf allen Plattformen und Geräten funktionieren soll und die gesamte Anwendungslogik beinhaltet. So sind die Persistie- rung von Daten und die Kommunikation über Netzwerkzugriffe Funktionen, die der Anwendung durch das Backend zur Verfügung gestellt werden. Plattformspezifische Entwicklungen sind so in das Backend zu integrieren, dass die Schnittstelle zur der restlichen Anwendung plattformun- abhängig angesprochen werden kann. Das Frontend hingegen stellt das User-Interface dar und übernimmt Aufgaben zur Navigation innerhalb der Anwendung. Der Anspruch an das Konzept ist eine möglichst generische Gestaltung der Nutzerschnittstelle, sodass Komponenten zur Laufzeit dynamisch geladen werden können, um entsprechenden plattformspezifischen Anforderungen in der Implementierung gerecht zu werden. Titanium bietet hierfür Möglichkeiten, um den Ent- wickler bei der Umsetzung dieses Ansatzes zu unterstützen, weshalb sich diese bereitgestellten Möglichkeiten in der Konzeption wiederfinden.

23 Die nachfolgenden Abschnitte stellen die gewählten Design-Konzepte detailliert vor. Schwer- punkte sind sowohl die Planung der Anwendung, wie auch Schwierigkeiten, die während der Umsetzung auftraten und eventuell eine Umplanung notwendig machten.

4.2 BACKEND

Communote stellt serverseitig eine REST-Schnittstelle zur Kommunikation bereit. Die mobile Anwendung muss mit dieser Schnittstelle kommunizieren, um die geforderten Aufgaben zu erfül- len. Ein zentraler Bestandteil des Backends ist daher die Implementierung eines REST-Clients, der die Schnittstelle angemessen abstrahiert und die Funktionalitäten der Anwendung zur Verfügung stellt. Da die REST-Schnittstelle Communotes Entwicklungszyklen unterworfen ist, ist es not- wendig, den Client so auszugestalten, dass spätere Anpassungen an der REST-API mit möglichst wenig Aufwand umgesetzt werden können und außerdem zur Laufzeit dynamisch eine Client- Version zur Kommunikation ausgewählt werden kann. Speziell letzteres ist notwendig, da parallel unterschiedliche REST-Versionen auf den verschiedenen Servern verwendet werden können.

4.2.1 REST-Client

Die Vorgabe des industriellen Partners ist die Unterstützung verschiedener REST-Versionen, ab einer bestimmten Version. Es ist klar, dass sich nicht die komplette Schnittstelle innerhalb eines Entwicklungszyklus ändern wird. Allerdings können die Änderungen sehr unterschiedliche Aus- prägungen aufweisen. So könnten sich beispielsweise die Bezeichner von Ressourcen ändern oder gleiche Anfragen an unterschiedliche Versionen verschiedene Ergebnisse zurückliefern. Die erste Grundidee ist die Verwendung der zu unterstützenden Mindestversion als Basis, auf der jede weitere Version aufbaut. Der zweite Grundgedanke ist die Abstraktion der zurückgelieferten Daten zu Klassen, die über verschiedene Versionen hinweg gleich bleiben können beziehungs- weise nur erweitert werden müssen.

Wie in Abbildung B.3 auf Seite 47 dargestellt, sieht die Architektur des Backends zwei große Komponenten vor: das Model und REST. Im Model sind Datentypen in Form von Klassen defi- niert, die die Rohinformationen abstrahieren und für die Anwendung verfügbar machen. Klassen im Model dienen in erster Linie einem einheitlichen Informationsaustausch und sind daher nicht in dem Maße der Versionierung unterworfen wie die Klassen in der REST-Komponente, welche den REST-Client der mobilen Anwendung repräsentiert. Diese Komponente besitzt mehrere Un- terkomponenten, wovon die Komponente Base die wichtigste ist, da diese die Funktionalitäten der mindestens zu unterstützenden REST-Version des Servers implementiert. In Zukunft werden der REST-Komponente neue Unterkomponenten hinzugefügt, die jeweils eine neue Version der Schnittstelle implementieren. Neuere Versionen der REST-Schnittstelle erben stets von der Vor- gängerversion und reimplementieren lediglich Funktionen oder Attribute, die sich im Vergleich zur vorherigen Version änderten.

Die Klassen der REST-Komponente übernehmen dabei nicht nur die Kommunikation mit dem Ser- ver, sondern überführen die zurückgelieferten Rohdaten ebenfalls in Datenstrukturen, die in der Model-Komponente definiert sind. In Abbildung B.2 auf Seite 46 sind diese Klassen durch den Zusatz Provider im Namen zu erkennen. Im Model enthaltene Klassen sind beiden Teilen der Ap- plikationen bekannt, wodurch für Methodenaufrufe einheitliche Parameter und Rückgabewerte definiert werden können, auch über mehrere REST-Versionen hinweg. Dies sichert eine konsi- stente Datenübertragung über die definierte Schnittstelle zwischen Frontend und Backend. Die Kommunikation mit dem Server selbst erfolgt mittels XMLHttpRequests, die in Titanium durch ein eigenes Objekt repräsentiert werden. Um nicht in jeder Provider-Klasse diese Objekte für jede Anfrage neu implementieren zu müssen, wird diese Generierung in eine eigene Klasse aus- gelagert, von der alle Provider-Klassen erben. Es handelt sich hierbei nicht um die Vererbung

24 Kapitel 4 Konzeption im klassischen objektorientierten Sinn, sondern um eine sogenannte parasitäre Vererbung, wel- che in dem Sprachumfang von JavaScript enthalten ist und nicht die Mächtigkeit der klassischen Vererbung besitzt. Diese Superklasse erstellt ebenfalls die URIs zur Abfrage bestimmter Res- sourcen und setzt diese automatisch in das Request-Objekt. Lediglich das Senden des Requests an den Server und die Behandlung der Antwort muss damit individuell durch die Provider imple- mentiert werden. Die Behandlung sämtlicher Server-Antworten in den Providern erfolgt aufgrund der asynchronen Kommunikation über sogenannte Callbacks. Dabei handelt es sich grundlegend um ein Delegate-Prinzip: Das Frontend liefert die Aufgaben, die nach dem Empfang der Behand- lung ausgeführt werden sollen an das Backend, welches die entsprechende Funktion schließlich anstößt.

Die REST-Version wird zur Laufzeit dynamisch bestimmt. Entsprechend wurden in der REST- Komponente Klassen bereitgestellt, die für eine bestimmte Version den passenden Client zurück- liefern (vgl. Abbildung B.2 auf Seite 46 Strategy-Klassen). Titanium bietet durch die Verwendung des CommonJS-Dialekts die Möglichkeit, diese Strategy-Klassen als eine Art Singleton zu im- plementieren, sodass jeweils nur eine Version des Clients im Speicher der Anwendung liegen kann.

4.2.2 Model

Wie bereits erwähnt, ist das Model nicht mit einem Modell der Anwendung zu verwechseln, sondern repräsentiert eine Kollektion von Klassen, die einen einheitlichen Informationsaustausch zwischen Frontend und Backend ermöglichen.

Die Hauptaufgabe des Models liegt in der Abstraktion der Ressourcen der REST-Schnittstelle. Alle wichtigen Ressourcen, die für die Erfüllung aller Aufgaben durch die App gebraucht werden, werden durch ein eigenes Datenobjekt repräsentiert. Diese Datenobjekte besitzen die gleichen Attribute wie die Ressource der REST-Schnittstelle. Auf diese Weise wird sichergestellt, dass das Frontend einheitliche Daten aus dem Backend geliefert bekommt und entsprechend sicher und weniger fehleranfällig auf die eigentlichen Ressourcen zugreifen kann. Zum anderen bekommt das Backend einheitliche Daten zum eventuellen Versand an die REST-Schnittstelle bereitgestellt. Durch diese Konvention wird ein gewisser Grad an Typsicherheit in die typfreie Umgebung von JavaScript eingebracht, was sowohl die Lesbarkeit des Quellcodes als auch dessen Wartbarkeit erhöht.

Des Weiteren stellt das Model für einige Ressourcen Methoden bereit, die durch das Frontend angestoßen werden können und durch das Model-Objekt ins Backend propagiert werden, um dort weiterverarbeitet werden zu können. Ein Beispiel ist hier das Favorisieren einer Nachricht. Diese Aktion wird rein logisch auf der Nachricht selbst durchgeführt und wird durch das Model entsprechend bereitgestellt. Die Instanz der jeweiligen Ressource übernimmt im Anschluss die Weiterleitung der Aktion in das Backend und liefert diesem alle notwendigen Daten.

4.2.3 Externe Module

Die Anwendung überträgt und speichert sicherheitskritische Daten. Bereits während der Betrach- tung der verschiedenen Frameworks wurde deutlich, dass keines der betrachteten Frameworks – mit Ausnahme von Rhomobile – zufriedenstellende native Lösungen bietet, um Daten sicher auf dem Endgerät zu speichern. Konkret ist die Speicherung der Zugangsdaten des Nutzers auf dem Endgerät notwendig, um ein ständiges Anmelden beim Start der Anwendung zu verhindern. So- wohl unter iOS wie auch unter Android wurden die Zugangsdaten in den Prototypen in Klartext, in unsicheren Teilen des Systems, also Bereichen, auf die von Außen zugegriffen werden konnte, gespeichert.

4.2 Backend 25 Der Funktionsumfang des Titanium-Frameworks musste daher mit plattformspezifischen, nativ entwickelten Modulen erweitert werden. Für iOS wurde ein Modul entwickelt, welches die Zu- gangsdaten des Nutzers in den sogenannten Keychains ablegt. Dabei handelt es sich um einen geschützten Bereich des Betriebssystems, in dem eben solche Zugangsdaten abgelegt werden sollen. Die Verschlüsselung der Daten übernimmt das Betriebssystem selbst. Android stellt kei- nen solchen Bereich innerhalb des Betriebssystems bereit, sodass für diese Plattform ein Modul entwickelt worden ist, welches die Zugangsdaten mithilfe der AES-Technik verschlüsselt und in den Anwendungsordnern des Systems speichert.

Da sowohl das Frontend als auch das Backend die Zugangsdaten des Nutzers für verschiedene Aufgaben benötigen, mussten auch diese Module plattformübergreifend in das Projekt integriert werden. Dazu wurde eine Adapter-Klasse geschrieben, die eine einheitliche Schnittstelle nach Außen bereitstellt und intern die Trennung der verschiedenen Plattformen übernimmt.

Da es sich bei der Speicherung von Zugangsdaten um sicherheitskritische Aspekte der Anwen- dung handelt, musste der zusätzliche Zeitaufwand in Entwicklung und Test der externen Module in Kauf genommen werden. Es stellte sich heraus, dass der Test der Module die meiste Zeit in Anspruch nahm. Vor allem unter iOS traten durch die Kombination des Titanium-Frameworks und der nativen Module unvorhergesehene Probleme auf, die nur mit viel Zeitaufwand zu bewältigen waren.

4.3 GRAFISCHE OBERFLÄCHE

An die grafische Oberfläche der Anwendung werden verschiedene Anforderungen gestellt. Ei- nerseits sollen plattformtypische Aspekte und Bedienkonzepte in die Gestaltung mit einbezogen werden, während andererseits die Redundanz des Quelltextes möglichst gering zu halten ist. Werden im Laufe der Wartungsphase Änderungen an der grafischen Oberfläche nötig, so sollen diese möglichst nur einmal und nicht für jede Plattform oder gar jeden Bereich der Anwendung vorgenommen werden.

Die Herausforderung ist folglich, ein Design zu entwerfen, das mit den Bedienkonzepten aller Plattformen konform ist und dennoch möglichst keine Redundanz aufweist. Hinzu kommt, dass wesentliche Elemente der grafischen Oberfläche sowohl auf dem Smartphone als auch dem Ta- blet verwendet werden sollen, um dort nicht ebenfalls separat Anpassungen vornehmen zu müs- sen.

Ein weiterer Aspekt ist die Flexibilität der grafischen Oberfläche bezüglich unterschiedlichen API- Versionen. Je nachdem, welche Funktionalitäten von Seiten der API bereitgestellt werden, soll die grafische Oberfläche zugehörige Elemente anzeigen oder ausblenden.

Bereits in der ersten Evaluierungsphase spielte das Thema grafische Oberfläche eine wichtige Rolle. Während der Schwerpunkt zuvor jedoch auf der Umsetzung eines nativen Designs lag, sollen in dieser Phase Erkenntnisse gewonnen werden, inwiefern Titanium mit nicht-nativen De- signs arbeiten kann und vor allem, ob dies die Entwicklung erleichtert oder schwieriger gestaltet.

4.3.1 Gesamtansicht & Navigation

Die Navigation ist eines der kritischsten Elemente der plattformübergreifenden Entwicklung. Die einzige Struktur, welche sowohl von Android als auch iOS unterstützt wird, ist eine Tableiste, welche vorwiegend für den Einsatz auf Smartphones geeignet ist, aber auch auf Tablets gele- gentlich zum Einsatz kommt. Diese ist auf Grund der zu erwartenden Anzahl von mindestens acht Einträgen jedoch inakzeptabel, da eine sinnvolle Verwendung sehr umständlich ist. Dazu kommt, dass es eigene Informationsströme (mit nutzerspezifischen Filtern) gibt, die vom Nutzer selbst zur Navigation hinzugefügt oder wieder entfernt werden können. Alternative Strukturen, die standardmäßig auf beiden Plattformen vorkommen, gibt es nicht. Sie müssen eigenständig entwickelt werden.

26 Kapitel 4 Konzeption Ein Ansatz, der in letzter Zeit immer häufiger Verbreitung auf meh- reren Plattformen findet, ist ein Menü, welches außerhalb des sicht- baren Bereichs platziert wird und per Berührung eines Buttons oder mittels einer Wischgeste in den sichtbaren Bereich geblendet wird. Dieser Entwurf steht mit keinem der plattformtypischen Bedienkon- zepte in Konflikt, denn es kann sowohl auf berührungsempfindlichen Geräten, speziell dem iPhone ohne zusätzliche Tasten, als auch Ge- räten mit Hardwaretastatur genutzt werden. Das Menü kann unter Android beispielsweise an den entsprechenden Hardware- oder Soft- warebutton des Betriebssystems gebunden werden.

Die Entscheidung für diese Art der Navigation für Smartphones wurde in einer internen Diskussion des externen Partners getroffen. Einen konzeptionellen Entwurf dieser Navigation zeigt die Grafik 4.1. Klarer Vorteil ist die Flexibilität bezüglich der Anzahl der Menüein- träge. Zudem ist diese Darstellung wesentlich übersichtlicher als die Abbildung 4.1: Navigation bereits erwähnte Tableiste.

Bei den Tablets hat sich ein geteilter Bildschirm („SplitView“,vgl. Grafik B.5 auf Seite 49) durch- gesetzt, der auf beiden Plattformen zu finden ist. Meist besteht diese Struktur aus einer listen- ähnlichen Übersicht im linken Bereich und einer Detailansicht auf der rechten Seite.

Theoretisch könnte das Menü, das bereits für das Smartphone vorgestellt wurde, in diesen listen- ähnlichen Bereich integriert werden. Allerdings müssen nahezu alle Bereiche, die durch die jewei- ligen Menüeinträge erreichbar sind, ebenfalls in dieser Liste untergebracht werden. Dies ist zwar technisch möglich, verhindert aber das schnelle Wechseln zwischen verschiedenen Bereichen der App, beispielsweise zwischen verschiedenen Informationsströmen. Daher ist es sinnvoll, dieses Konzept des zweigeteilten Bildschirms zu erweitern, indem das Menü des Smartphones mit der geteilten Ansicht des Tablets kombiniert wird. Daraus entsteht ein optisch dreigeteilter Bereich aus Menü, einer Liste (beispielsweise einer Nachrichten- oder Personenübersicht) und dem Be- reich für die Details (vgl. Grafik B.6 auf Seite 50). Damit die Navigation nicht unnötig viel Platz in Anspruch nimmt, soll sowohl eine kompakte (Grafik B.6), als auch eine ausführliche Darstellung (Grafik B.6) untergebracht werden. Letztere wird ähnlich dem Smartphone bei Bedarf weiter in den sichtbaren Bereich geblendet. Diese Ansicht bietet zudem die Möglichkeit, Anpassungen vorzunehmen, beispielsweise neue Informationsfilter und -ströme hinzuzufügen.

4.3.2 Informationsstrom

Ein wesentlicher Bestandteil der Anwendung ist die Darstellung von Informationsströmen. Die Navigation unterstützt, wie bereits erwähnt, bei der Filterung der Informationsströme, um einen besseren Überblick zu behalten. Des Weiteren ist es von großer Bedeutung, möglichst prägnant die wichtigsten Informationen einer einzelnen Nachricht oder eines Beitrags schnell zu erkennen.

Dazu müssen die wesentlichsten Informationen, wie Autor, Thema, eine eventuelle Adressierung an den Nutzer sowie Inhaltsschwer- punkte, bereits in der Informationsübersicht vorhanden sein.

Die Grafik 4.2 zeigt eine Konzeption, die bereits alle wichtigen In- formationen der Nachricht enthält. Die zwei Flaggen im rechten Teil Abbildung 4.2: signalisieren dem Nutzer, dass die Nachricht an ihn adressiert ist und Informationsstrom - er diese favorisiert hat. Hinzu kommen Informationen bezüglich der Übersicht Nachrichten innerhalb dieser Diskussion, wie viele Personen ihr Inter- esse für diese Nachricht bekunden und wie viele Anhänge diese Nachricht besitzt. Auch Autor, Thema und Inhalt sind auf den ersten Blick zu erkennen.

Jede Information besitzt zudem eine Detailansicht. Sie unterscheidet sich lediglich darin, dass der Inhalt in voller Länge wiedergegeben wird und das verschiedene Interaktionen, wie beispiels- weise antworten, durchgeführt werden können.

4.3 Grafische Oberfläche 27 4.3.3 Technische Konzeption

Nachdem die wesentlichen grafischen Anforderungen geklärt sind, bleibt die Frage, wie eine technische Umsetzung des Designs aussehen soll. Die wesentlichen Kriterien sind:

• Eine große gemeinsame Codebasis für die grafische Oberfläche.

• Plattformspezifische Anpassungen sollten möglichst gering sein.

• Designanpassungen (Schriftformatierungen, Farben, Positionen, etc.) sollen nur an einer Stelle geändert werden müssen.

Der Aspekt der Unterstützung verschiedener grafischer Oberflächen auf Basis der Version der API des Informationssystems wurde verworfen, da nicht jede Änderung der API eine Anpassung der Oberfläche erzwingt und sollte dies dennoch der Fall sein, ist in der Regel nur ein Teil des Designs anzupassen, sodass eine Versionierung zu aufwendig ist. Visual Paradigm for UML Community Edition [not for commercial use]

ui devicedependent

tablet handheld ui

menu menu tablet handheld

menu menu

notes

notes

Abbildung 4.3: Top-Level-Architektur (UI), ausführlich in Abbildung B.4 auf Seite 48

Die Abbildung 4.3 zeigt die konzeptionierte Top-Level-Architektur der grafischen Oberfläche. Zu erkennen sind ein Paket mit dem Namen „ui“ und eines mit dem Namen „devicedependent“. Letzteres existiert für jede Plattform und trägt in der Praxis den Namen dieser Plattform (Android = „android“ und iOS = „iphone“). Es handelt sich dabei um Projektordner, deren Inhalt während des Buildprozesses in das Projektstammverzeichnis verschoben wird, sodass die Ressourcen zur Laufzeit nicht plattformspezifisch geladen müssen [App12a]. Eine derartige automatisierte Trennung zwischen Tablet und Smartphone findet nicht statt. Für gerätespezifische Anpassungen sind die Teilpakete „tablet“ und „handheld“ vorgesehen.

Eine Einschränkung, soviel kann und muss vorweg genommen werden, ist die fehlende Unter- stützung für das Model-View-Controller-Prinzip seitens Titanium. Dieses kann nur unter Zuhilfe- nahme von Erweiterungen diverser Drittanbieter genutzt werden. Um die Abhängigkeiten des Projekts jedoch gering zu halten, wurde auf diese Erweiterung verzichtet, was verschiedene Ein- flüsse auf die Konzeption hat.

Die Klassen des plattformunabhängigen UI-Pakets haben im Wesentlichen zwei Aufgaben. Einer- seits generieren sie die Struktur der grafischen Oberfläche. In der Regel wird die Reihenfolge der Elemente festgelegt. Die tatsächlich verwendeten Elemente werden dabei über Factory-Klassen aus dem plattformspezifischen UI-Paket generiert. So ist es möglich, dass eine grafische Kompo- nente unter iOS ein Button ist, während unter Android dafür lediglich ein View verwendet wird. Die Reaktion auf ein Klickereignis kann im plattformspezifischen Bereich abgefangen werden. An- schließend kann die Komponente ein eigenes Ereignis ausführen, das die aufbereiteten Werte an

28 Kapitel 4 Konzeption den plattformunabhängigen Bereich zurückgibt. Dieser übernimmt als zweite wesentliche Auf- gabe die Aufgabe der Controller, vorrangig die Ablaufsteuerung (Navigation), aber auch das Laden oder Schreiben neuer Nachrichten.

Letzteres soll als Fallbeispiel die Interaktion zwischen plattformabhängigem und -unabhängigem Bereich verdeutlichen. Insbesondere geht es um die Auswahl eines Themas beim Verfassen einer Nachricht. Der plattformunabhängige View besitzt ein Element, das bei Klick die Themenübersicht öffnet. Das Öffnen geschieht zwar noch im unabhängigen Bereich, die grafischen Elemente wer- den jedoch bereits plattformspezifisch generiert. Unter iOS steht ein typisches Auswahlmenü („Picker“) zur Verfügung, während Android eine herkömmliche Liste („TableView“) lädt. Die In- teraktion innerhalb dieser Auswahl übernimmt der plattformspezifische Bereich. Wird ein Thema ausgewählt, löst die jeweilige grafische Komponente ein Ereignis aus, das unter beiden Platt- formen den gleichen Namen trägt und als Parameter das ausgewählte Thema enthält. Dieses Ereignis wird dann im plattformunabhängigen Bereich abgefangen. So kann das Thema ausge- wählt werden, ohne das Quelltextweichen verwendet werden müssen. (Grafik B.1 auf Seite 45)

4.3 Grafische Oberfläche 29

5 BEWERTUNG

In diesem Kapitel werden Erfahrungen mit Titanium, die bei der prototypischen Umsetzung wäh- rend der Entscheidungsfindung und der konkreten Umsetzung der Anwendung gesammelt wur- den, zusammengefasst, beschrieben und bewertet. Als Bewertungsgrundlage dient dabei die Konzeption der Anwendung aus Kapitel 4. Das Design der Anwendung erfolgte auf Grundlage der bisherigen Erfahrungen mit Titanium und der definierten Anforderungen an die Anwendung aus Abschnitt 2.4. Dementsprechend wird in diesem Kapitel vor allem ein Schwerpunkt auf die Umsetzung der Konzeption mithilfe des Titanium Frameworks gelegt.

Auch die Abschnitte dieses Kapitels werden ähnlich der Konzeption gegliedert. Im ersten Ab- schnitt wird daher die Umsetzung des Backends bewertet. Anschließend wird auf die Umsetzung des User-Interface eingegangen und diese evaluiert.

5.1 BACKEND

Das Hauptziel der Konzeption ist eine möglichst plattformübergreifende Umsetzung des Back- ends. Dazu zählt vor allem eine einheitliche, plattformunabhängige Schnittstelle des Backends zum Rest der Anwendung sowie die Zahl plattformspezifischer Implementierungen innerhalb des Backends, um alle Funktionen auf jeder unterstützten Plattform bereitzustellen.

Wie bereits in Kapitel 4 zur Konzeption der Anwendung deutlich wurde, ist eine Umsetzung des Anwendungsfalls ohne plattformspezifische Elemente nicht realisierbar. Vor allem in Bezug auf die sichere Speicherung von Nutzerinformationen offenbarte Titanium große Schwächen und machte eine zeitaufwändige, native Implementierung von Erweiterungen, den externen Modulen, not- wendig. Sowohl für Android als auch für iOS konnten bereits vorhandene Bibliotheken für die jeweilige Umsetzung genutzt werden, sodass der Aufwand unter Android weniger als 100 LOC1 und unter iOS weniger als 200 LOC beträgt. Von der Umsetzung dieser Module und der entspre- chenden Einbindung derer in das Backend abgesehen, waren allerdings nur wenige plattforms- pezifische Implementierungen notwendig. Solche gesonderten Anpassungen sind entweder Be- sonderheiten des Betriebssystems oder sonstigen Regularien der Plattform geschuldet. Die Da- tenbank, die die Anwendung nutzt, um Informationen temporär zu speichern, muss unter iOS beispielsweise explizit vom BackUp-Prozess in die Cloud oder auf den Computer ausgeschlossen werden, da die gesicherten Daten jederzeit aus dem Internet geladen werden können und damit

1Lines of Code - Zeilen an Quellcode

31 nach Apples Richtlinien nicht gesichert werden dürfen. Würde diese plattformspezifische Anwei- sung im Quellcode nicht erfolgen, hätte die Applikation durch einen Verstoß der Apple Review Guidelines keine Chance, für den AppStore freigeschaltet zu werden. Glücklicherweise weist Appcelerator in der Dokumentation des Titanium Frameworks auf diese Besonderheit unter iOS hin, sodass diese Beschränkung Apples nicht erst beim Einstellen in den Store durch den Review aufgedeckt wird.

Ein Beispiel auf Seiten plattformspezifischer Anpassungen aufgrund von Unterschieden zwischen den Betriebssystemen, ist die Abfrage von Ortsinformationen von den Sensoren des Endgeräts, welche in der Konzeption nicht betrachtet wurde, da dieser Anwendungsfall durch die beste- hende REST-Schnittstelle noch nicht unterstützt wird. Aufgrund der Erfahrungen mit Titanium aus der prototypischen Umsetzung der Anwendung, kann allerdings festgehalten werden, dass für die Abfrage der Ortsinformationen vom Gerät plattformspezifische Umsetzungen notwendig sein werden. Unter Android sind für den Zugriff auf die Sensoren spezielle Provider-Klassen notwen- dig, die die Sensoren während ihres Lebenszyklus überwachen und die entsprechenden Infor- mationen bereitstellen. Titanium greift dieses Prinzip bei der Initialisierung der entsprechenden Klassen für Android auf, weshalb an dieser Stelle plattformspezifisch gearbeitet werden muss. Da die gewonnenen Ortsinformationen während des Lebenszyklus der Framework-Klassen über ein Event-Listener-System propagiert werden können, kann die Verarbeitung der Ortsinformatio- nen wieder plattformübergreifend erfolgen, sodass sich eine entsprechende Schnittstelle ebenso plattformübergreifend in das Backend integrieren lässt, wie die bereits angesprochenen nativen Module. Die Lösung Appcelerators könnte an dieser Stelle einfacher sein, nämlich durch einen komplett plattformunabhängigen Ansatz, allerdings ist die gefundene Lösung durchaus mit wenig Aufwand umzusetzen, weshalb die API an dieser Stelle nicht negativ bewertet wird.

Ebenfalls ein wichtiger Bestandteil der Konzeption des Backends ist die Unterstützung mehrerer Versionen der REST-Schnittstelle des WebService durch die mobile Anwendung. Es wurde eine Architektur gewählt, die auf Vererbung von Methoden und Attributen aufbaut, um bei Iteratio- nen der REST-Schnittstelle nur erfolgte Änderungen neu implementieren zu müssen. JavaScript eignet sich für die Umsetzung eines solchen Ansatzes schlecht, da es nur eine parasitäre Ver- erbung in Form von Objekterweiterung beherrscht. Ein Überladen von Methoden funktioniert in der Kombination von Titanium und JavaScript überhaupt nicht, sodass einige Feinheiten des Entwurfsmusters abgeändert werden mussten.

Bei dem zugrunde liegenden Anwendungsfall handelt es sich um eine Kommunikationsplattform, die als eigenständige Applikation auf mobile Endgeräte portiert werden soll. Viele Anwendungen, die dem Nutzer als eine Kommunikationsplattform oder ein Informationsportal dienen, weisen den Anwender mittels Push-Benachrichtigungen auf neue Nachrichten beziehungsweise neue Informationen hin. Für den Anwendungsfall wäre eine solche Implementierung eines Push- Dienstes ebenfalls wünschenswert. Allerdings unterstützt die bestehende Anwendung Push- Benachrichtigungen serverseitig nicht. Daher findet sich eine solche Anbindung bisher nicht in der Konzeption der Applikation wieder und der Aufwand der Implementierung wurde nur rein theo- retisch betrachtet. Titanium liefert seit dem Release der SDK-Version 2.0 und dem kurz darauf erfolgten Update der Lizenzpreise zusätzliche Module – sogenannte native Extensions – aus, die Kunden von kostenpflichtigen Lizenzlösungen in ihren Anwendungen verwenden dürfen. Dazu zählt ebenfalls ein Modul von Urban Airship2, mit welchem sich Push-Benachrichtigungen in die Anwendung integrieren lassen. Die serverseitige Infrastruktur übernimmt die Firma Urban Airship ebenfalls. Soll Titanium weiterhin kostenfrei genutzt werden, ist eine eigenständige Entwicklung nativer Module notwendig, um Push-Benachrichtigungen zu ermöglichen. Der Arbeitsaufwand ist dabei nicht zu unterschätzen. Die nativen Module für das jeweilige mobile Betriebssystem sind vom zeitlichen Aufwand her zu vernachlässigen. Der größere Anteil an umzusetzenden Aufgaben wartet im serverseitigen Backend, da sowohl für Android wie auch iOS Dienste auf einem Server bereitgestellt werden müssen, die mit den Push-Diensten Apples und Androids zusammenarbei- ten und die Benachrichtigungen versenden.

2http://urbanairship.com/

32 Kapitel 5 Bewertung Die Konzeption der Anwendung wurde spezifisch auf die Stärken und Schwächen der JavaScript- Sprache hin erarbeitet. Die erste Frage, die gestellt werden muss, wenn man einen nativen Ansatz betrachtet, um einen Vergleich zu ziehen, ist, ob es möglich ist, die bereits vorhandene Konzeption des Backends zu übernehmen. Im Falle von iOS muss diese Frage relativ eindeutig mit ja beantwortet werden. Objective-C ist als objektorientierte Sprache mächtig genug, um ei- nige Eigenheiten von JavaScript kompensieren zu können. In der Konzeption werden sogenannte Callbacks verwendet, um durch die asynchrone Datenverbindung zurückgelieferte Daten verarbei- ten zu können, sobald diese verfügbar sind. Unter iOS stehen dafür sogenannte Blocks [App10] bereit, welche die selbe Aufgabe erledigen. Vor allem bei der Arbeit mit den Provider-Klassen, die die Netzwerkabfragen regeln, würden sich die Möglichkeiten der Blocks auszeichnen, da an dieser Stelle nicht auf Delegates – die aufgrund der Anlage als Singleton der Provider nicht geeig- net sind – oder ein Observer-Pattern ausgewichen werden muss. Speziell die Implementierung eines Observer-Patterns würde den Umfang des zu schreibenden Quellcodes erhöhen. Jede User-Interface Klasse müsste eine eigene Methode implementieren, die durch die Provider geru- fen werden müsste, sobald die Daten des asynchronen Requests zur Verfügung stehen. Wird in einer solchen User-Interface Klasse an mehreren Stellen ein asynchroner Datentransfer angesto- ßen, müsste voraussichtlich für jeden Request eine eigene zusätzliche Methode implementiert werden. Die Zahl der Code-Zeilen würde durch dieses Vorgehen steigen. Der Anstieg der Code- Komplexität ist hier jedoch kritischer zu bewerten. Die Unterstützung von Blocks unter Objective- C macht eine Implementierung möglich, die sehr ähnlich der unter JavaScript ist, weshalb die Konzeption nicht geändert werden müsste. Aufgrund der Charakteristika von Objective-C wäre mit einer größeren Zahl an Code-Zeilen zu rechnen. Gerade bei Überprüfungen für Verzweigun- gen oder Schleifen kann unter JavaScript mit sehr viel kürzeren Ausdrücken gearbeitet werden, da Datentypen erst zur Laufzeit aufgelöst werden. Da auch unter Objective-C die Model-Klassen implementiert werden müssten – die beinahe mit einer identischen Zahl an LOC implementiert werden könnten – könnte sich der ungetypte Ansatz von JavaScript sehr gut in eine native Lösung integrieren lassen. Der Mehraufwand wäre an dieser Stelle gering. Mit zusätzlichen expliziten Casts und anderen Anpassungen aufgrund der typisierten Syntax unter Objective-C sollte bei der Planung dennoch gerechnet werden.

Die arbeitsintensiven Klassen unter iOS sind die Implementierungen der Netzwerkkommunika- tion sowie die Handhabung von JSON als Server-Antwort zum Datentransfer. An dieser Stelle können frei verfügbare Bibliotheken genutzt werden, die allerdings zusammen einen Code-Um- fang von über 10.000 LOC besitzen. Müssten diese Klassen komplett selbst implementiert wer- den, wäre eine native Umsetzung nicht realisierbar, bezogen auf den Anwendungsfall und die Kapazitäten des industriellen Partners.

Android unterstützt Callbacks nicht in dem Umfang wie JavaScript und Objective-C. Die Konzep- tion müsste auch für Android im Grunde nicht angepasst werden, allerdings stiege der Code- umfang deutlich an, da jede Klasse, die einen Netzwerk-Zugriff anstößt, für jeden Request eine separate Methode implementieren muss, um die zurückgelieferten Daten zu verarbeiten. Vor allem die Fehlerbehandlung wird sich unter diesen Voraussetzungen schwierig gestalten, da ten- denziell mehr als eine Callback-Methode für das Backend zur Verfügung gestellt werden muss, um verschiedene Fehlerquellen sicher abzufangen und behandeln zu können. Für Android ist die Arbeit mit Observer-Pattern durchaus sinnvoll. Eine solche Umsetzung würde dann jedoch eine separate Konzeption erfordern.

Zusammenfassend ist Titanium durchaus für die Entwicklung komplexer mobiler Anwendungen geeignet, solange nicht mit grafischen Elementen gearbeitet werden muss. Der nachfolgende Ab- schnitt wird sich genauer mit diesem Thema befassen und Schwierigkeiten sowie Lösungsmög- lichkeiten aufzeigen und bewerten. Bei der Entwicklung mit Titanium treten lediglich Schwächen von JavaScript negativ hervor, die zum Teil durch das Framework selbst noch verstärkt werden. Besonders unter Android muss bei der Entwicklung besonders auf die verschiedenen JavaScript- Kontexte geachtet werden, die bei der Arbeit mit Fenstern entstehen. Titanium unterscheidet unter Android sogenannte Lightweight Windows und Heavyweight Windows. Zweitere stellen eine eigene Activity dar und erzeugen einen neuen JavaScript-Kontext, was dazu führt, dass vor- mals bekannte globale Deklarationen in dem neuen JavaScript-Kontext unbekannt sind. Es war daher sogar an mehreren Stellen notwendig, einen Import plattformspezifisch zu gestalten, um den Ansprüchen beider Plattformen mit möglichst wenig Aufwand gerecht zu werden. Dieses Verhalten ist der einzige große Kritikpunkt an Titanium, den man in Bezug auf die Entwicklung der Anwendungslogik vorbringen kann.

5.1 Backend 33 5.2 GRAFISCHE OBERFLÄCHE

In der ersten Evaluierungsphase konnte Titanium im Umgang mit nativen grafischen Elementen überzeugen. Diese zweite Evaluierungsphase hat jedoch zur Aufgabe, die Eignung Titaniums zur Umsetzung eines eigenen, in sich geschlossenen, Designs zu analysieren. Dazu wird die, im letzten Kapitel konzeptionierte, grafische Oberfläche einheitlich für Android und iOS umgesetzt.

Im Folgenden werden dazu verschiedene Aspekte der Umsetzung betrachtet. Zunächst steht das Model-View-Controller-Architekturmuster im Mittelpunkt. Anschließend wird auf die plattform- übergreifenden und plattformspezifischen grafischen Komponenten näher eingegangen. Danach wird die eigentliche Entwicklung in den Fokus der Analyse gesetzt. Beendet wird das Kapitel mit einem Vergleich zur nativen Entwicklung der grafischen Oberfläche.

5.2.1 Model-View-Controller

In der Konzeption wurde bereits eine wesentliche Schwachstelle von Titanium erwähnt und be- rücksichtigt. Das Framework bietet keine Unterstützung für das Model-View-Controller-Prinzip, also der strikten Trennung von Daten, grafischer Oberfläche und Steuerung. Dieser Mangel wird besonders deutlich, wenn es um die Darstellung vieler Daten, beispielsweise des Informations- stroms, geht.

Der Informationsstrom besteht im Wesentlichen aus einer Liste, einem sogenannten TableView. Dieser kann nicht an eine Menge von Daten gebunden werden, was zur Folge hat, dass alle Daten manuell in diese Liste eingefügt werden müssen. Das allein ist nicht weiter kritisch. Schwierig wird es, wenn Datensätze mehrfach existieren oder manipuliert werden. Ein einfaches Szenario ist das Mögen oder Bewerten einer Information, die in mindestens zwei Informationsströmen (auf Grund unterschiedlicher Filterung) vorkommt. Im MVC-Prinzip würde der Controller das Modell aktualisieren, welches wiederum die Aktualisierung aller Ansichten, die diesen Datensatz enthal- ten, zur Folge hätte. In Titanium muss dies manuell vorgenommen werden. Das verursacht einen erheblichen Mehraufwand in der Entwicklung oder die Verwendung von Drittanbietererweiterun- gen, die zusätzliche Abhängigkeiten schaffen, Lizenzen bedürfen und gegebenenfalls auch Kosten verursachen.

5.2.2 Grafische Komponenten

Titanium erweckt zu Beginn den Eindruck, eine Schnittstelle (API) für alle Plattformen zu bieten. Nach genauerer Betrachtung erscheinen allerdings auch plattformspezifische APIs für Android, iOS allgemein, iPhone und iPad. Dies ist ein klarer Vorteil, da es im Gegensatz zu anderen be- trachteten Frameworks die Verwendung plattformspezifischer, nativer Komponenten ermöglicht - logischerweise nur auf der entsprechenden Plattform.

Getrennt werden diese Elemente durch unterschiedliche Namensräume. Alle grafischen Kompo- nenten, beginnend mit Ti.UI ohne Angabe der Plattform (Ti.UI.iOS), sollten für alle Systeme zur Verfügung stehen. Das lässt die Dokumentation jedenfalls auf den ersten Blick vermuten. Dies ist jedoch falsch. Ti.UI.ButtonBar ist eine Komponente, die es (auch laut Dokumentation) nur unter iOS gibt. In der Übersicht wird das nicht ersichtlich.

Neben Komponenten, die es nur für bestimmte Plattformen gibt, sind auch einige Attribute und Methoden plattformübergreifender Komponenten nur für eine Plattform verfügbar. Das Attribut headerPullView der Komponente Ti.UI.TableView existiert nur für iOS. Dies ist logisch, da das zugehörige Verhalten, nämlich das Scrollen der Liste über den oberen Rand hinaus, nur unter iOS

34 Kapitel 5 Bewertung existiert. Doch auch hier mangelt es an der Dokumentation. Laut einem offiziellen Blogeintrag vom 31. Mai 2010 [Hay10] des CEO von Appcelerator, Jeff Haynie, konnte diese Funktionalität bereits in Titanium 1.4 genutzt werden. Dokumentiert ist dies erst seit der Version 2.1.0 vom 29. Juni 2012 [App12c].

Abgesehen von unterschiedlichen Schnittstellen oder unzureichend beziehungsweise gar nicht dokumentierten Elementen gibt es noch ein weiteres wesentliches Manko: Plattformübergrei- fende Elemente weisen auf unterschiedlichen Systemen kein identisches, teilweise nicht einmal ähnliches Verhalten auf. Dies ist vorwiegend den unterschiedlichen Architekturkonzepten der bei- den betrachteten Plattformen geschuldet, könnte an einigen Stellen allerdings besser von den Entwicklern des Frameworks umgesetzt werden.

Ein wesentlicher Unterschied beider Plattformen besteht im Umgang mit den Komponenten Ti.UI.Window und Ti.UI.View. Während die Window-Komponente im Wesentlichen auf iOS zu- rückzuführen ist, kommen Views auf beiden Plattformen vor. Die Window-Komponente kann unter Android entweder Teil einer Activity oder eine eigenständige Activity sein, wie in Abschnitt 5.1 bereits erwähnt wurde.

Apples iOS benötigt die Window-Komponente zwingend zur Umsetzung der plattformspezifi- schen Bedienkonzepte. Sie wird für die Tableiste, die NavigationGroup [App12b] und das SplitWin- dow auf dem iPad (Grafik B.5, S. 49) benötigt. Unter anderem unterstützt iOS die hierarchische Verwaltung von Window-Komponenten, sodass beispielsweise die Positionierung relativ zu über- geordneten Komponenten vorgenommen wird. Android hingegen unterstützt dies nicht. Dort ist jedes Window eigenständig und das zuletzt geöffnete befindet sich im Vordergrund. Hinzu kommt ein unterschiedliches Verhalten bezüglich Animationen. Welche Auswirkungen das hat, wird im nächsten Abschnitt erläutert.

Ein weiterer Nachteil ist die Unterstützung für die Bedienkonzepte der beiden Plattformen. Auf dem Smartphone liefert Titanium dabei durchaus gute Ergebnisse, da es auf die nativen Ele- mente des jeweiligen Systems zurückgreift. So kann mit Ti.UI.TabGroup eine native Tableiste auf beiden Systemen und mit plattformspezifischem Verhalten eingesetzt werden, ohne auf platt- formspezifischen Quelltext zurückgreifen zu müssen. Das ist jedoch die einzige Gemeinsamkeit von iOS und Android, was die Bedienkonzepte unter Android angeht. Die NavigationGroup, die zum iOS-Standardrepertoire gehört, wird von Titanium nicht auf Android übertragen. Dies mag daran liegen, dass es sich dabei nicht um ein typisches Bedienkonzept von Android handelt und dafür eigentlich der Zurück-Button gedacht ist. Allerdings findet dieses Konzept auch unter An- droidanwendungen immer mehr Verbreitung. Immerhin gibt es seitens Appcelerator ein Tutorial für die Realisierung einer plattformübergreifenden NavigationGroup beziehungsweise eines Navi- gationControllers [Whi11], da nicht das gesamte Verhalten von iOS adaptiert wird.

Noch schwieriger wird es im Bereich Tablets. Während das iPad sehr gut durch Titanium unter- stützt wird, beispielsweise durch plattformtypische Elemente wie den SplitView, also die geteilte Ansicht mit einer listenähnlichen Struktur links und einem Detailbereich auf der rechten Seite (Grafik B.5, S. 49), fehlt eine Unterstützung für Android-Tablets. Zwar können Anwendungen, die für Android entwickelt wurden, auf Tablets ausgeführt werden, spezielle Elemente, wie den SplitView für iOS, gibt es aber nicht. Genau genommen gibt es nicht einmal eine zuverlässige Er- kennung, ob es sich bei einem Android-Gerät um ein Tablet oder ein Smartphone handelt. Dabei ist eine Adaption dieses SplitViews durchaus denkbar, da es sich hierbei um ein sehr verbreitetes Konzept auch bei aktuellen Anwendungen für Android-Tablets handelt.

Ursache dafür ist vermutlich, dass Titanium im Kern auf die Android-API-Version 8 (Android 2.2) zurückgreift, was auch an der optischen Gestaltung der Anwendungen deutlich zu erkennen ist. Für eine sinnvolle Unterstützung von Tablets müsste auf die, seit Android 4 vorhandene, Frag- ment-Architektur zurückgegriffen werden, um einen möglichst hohen Wiederverwendungswert des Quelltextes und der einzelnen Komponenten zu erreichen. Allerdings werden von Android Support Libraries [And12f] zur Verfügung gestellt, die einige grafische Elemente auch für ältere API-Versionen anbieten. Hier spielt vermutlich die noch sehr geringe Verbreitung von Android- Tablets eine nicht unwesentliche Rolle.

5.2 Grafische Oberfläche 35 5.2.3 Entwicklung

Die erste Evaluierungsphase sollte neben der Auswahl eines Frameworks auch Erkenntnisse lie- fern, was bei dessen Verwendung in der Konzeption zu beachten ist. Dies ist teilweise gelungen, wie der vorletzte Abschnitt gezeigt hat. Dass während der Entwicklungsphase dennoch kleinere Probleme auftreten werden, war von vornherein klar. Allerdings trat auch ein Problem auf, das eine teilweise Neukonzeptionierung der Anwendung notwendig macht. Auf diese und andere Schwierigkeiten soll im Laufe dieses Abschnitts eingegangen werden.

Den zentralen Kern der grafischen Oberfläche bildet die Navigation, welche zu Beginn der Ent- wicklung umgesetzt wurde. Auf Grund der unterschiedlichen Konzeption für Tablet und Smart- phone, ist eine separate Umsetzung teilweise erforderlich.

Auf dem Smartphone besteht der Anwendungskern aus zwei Window-Komponenten. Eine dient als Container für die unterschiedlichen Bereiche der Applikation (Informationsströme, Personen- und Themenübersichten), während die andere das eigentliche Menü (Grafik 4.1, S. 27) beinhaltet. Das Menü befindet sich links außerhalb des sichtbaren Bereiches. Dieses wird bei Bedarf mittels Animation in den sichtbaren Bereich eingeblendet.

Hier entsteht bereits das schwerwiegendste Problem, das in der Entwicklungsphase aufgetreten ist. Wie bereits im letzten Abschnitt erwähnt, unterstützt Android keine hierarchische Verwaltung von Window-Komponenten, was zur Folge hat, dass alle Aktionen, die das Container-Window be- treffen, nicht sichtbar sind. Wesentlich kritischer ist jedoch die Tatsache, dass es unter Android, entgegen des dokumentierten Verhaltens [App12d], nicht möglich ist, eine Window-Komponente mit Animationen zu versehen, was in einem Minimalbeispiel nochmals abgesichert wurde. Das Umgehen dieser Problematik wäre mit entsprechendem Aufwand und einigen Workarounds si- cherlich möglich. In Anbetracht des frühen Entwicklungsstadiums ist an dieser Stelle eine neue Konzeptionierung der gesamten Navigationsstruktur, die dieses Verhalten berücksichtigt, langfri- stig sinnvoller.

Auf Basis dieser Erkenntnis wurde auch die Tabletvariante auf den Prüfstand gestellt, welche die gleichen Probleme aufweist. Die Grafiken B.6 und B.7 auf den Seiten 50 und 51 zeigen das zu animierende Menü auf dem Tablet. Rechts daneben befindet sich eine Listenansicht, die der NavigationGroup unter iOS nachempfunden ist, gefolgt von der Detailansicht. Auf Grund der gewünschten Animationen gibt es für Android nur eine Lösung: Es existiert eine Window- Komponente, die den gesamten Bildschirm einnimmt. Das Menü und die beiden Inhaltsbereiche sind jeweils als View-Komponente realisiert. Für die NavigationGroup unter iOS ist jedoch eine Window-Komponente als Container zwingend erforderlich.

Die Konsequenz ist eine separate Umsetzung der Navigation für jede Plattform und jedes Ge- rät, insgesamt also vier Umsetzungen. Ausschlaggebend ist, dass für das Tablet eine einheit- liche Umsetzung mindestens den gleichen Entwicklungsaufwand bedeutet, wie eine separate Entwicklung. Der Vorteil ist, dass bei einer separaten Entwicklung plattformspezifische Naviga- tionselemente besser genutzt werden können. Theoretisch wäre eine plattformübergreifende Umsetzung, auf Basis der Möglichkeiten von Android, möglich. Dies hätte jedoch zur Folge, dass das gesamte Controlling und die Animationen manuell umgesetzt werden müssten, was letztlich mehr Aufwand verursacht als die plattformspezifische Umsetzung. Vor allem unter iOS wird es dadurch nahezu unmöglich, ein natives Look and Feel für den Nutzer umzusetzen.

Zur Umsetzung eines einheitlichen Designs auf beiden Plattformen muss die Navigationsleiste, die zu den Standardelementen unter iOS gehört, für Android separat eingebunden werden. Es handelt sich dabei um eine View-Komponente, die mit den entsprechenden Elementen der Navi- gationsleiste versehen wird.

Der nächste wesentliche Bestandteil der Anwendung ist der Informationsstrom. Wie bereits erwähnt, handelt es sich dabei um eine TableView-Komponente. Ein Listeneintrag besteht aus

36 Kapitel 5 Bewertung einer TableViewRow-Komponente, die wie eine View-Komponente gestaltet werden kann. Es können Textbereiche, Bilder und vieles mehr hinzugefügt werden. Eine Besonderheit hier ist das unterschiedliche Verhalten von iOS und Android.

Das beginnt mit einem Fehler unter Android: Seit der Version 2.0 können in Titanium für Höhen- und Breitenangaben die Werte Ti.UI.FILL (auffüllen des Elternelements) und Ti.UI.SIZE (pass- genau zum Inhalt) verwendet werden. Unter Android führte die Angabe Ti.UI.SIZE für die Höhe eines Listeneintrags jedoch zu einem Fehler [Cyr12], der dazu führte, dass die Listenelemente die Höhe 0 haben und nicht sichtbar sind. Dieser Fehler ist mittlerweile in der Version 2.1.0 beho- ben, sorgte während der Entwicklung jedoch für einige Verwirrung, da derartige Fehler auch nicht nach Bekanntwerden in der Dokumentation erwähnt werden. Erst nach ausführlicher Recherche wurde die Ursache aufgedeckt.

Ein weiterer Unterschied ist der Umgang mit Bildern, speziell mit Bildern, die sich entfernt auf einem Server befinden. Für die Darstellung wird eine ImageView-Komponente benötigt. Unter iOS ist es möglich, dieser Komponente lediglich eine URL der Bildquelle mitzuliefern. Das Bild wird dann automatisch geladen, wenn der Eintrag sichtbar wird. Während des Ladevorgangs wird ein Platzhalter angezeigt. Es handelt sich hierbei um iOS-Standardverhalten, welches auch nativ in dieser Form vorzufinden ist. Android kann jedoch nicht mit externen Quellen umgehen, wes- halb hierfür eine gesonderte Implementierung notwendig ist. Dafür muss das Bild vom Server heruntergeladen werden. Erst dann kann es in der ImageView-Komponente dargestellt werden.

Zwei wichtige funktionale Anforderungen können nicht oder nur teilweise umgesetzt werden. Weder kann der bevorzugte Rich-Text-Editor, noch die Tastaturanpassung realisiert werden. Dass vor allem ersteres möglich ist, zeigt, neben diversen systemeigenen Anwendungen der Betriebs- systeme, die Evernote App3, die über einen derartigen Rich-Text-Editor verfügt. Eine Umsetzung wäre durchaus auch in Titanium möglich, ist allerdings mit der nativen Umsetzung als Modul für die gewünschten Plattformen verbunden. Der Aufwand dafür ist nur schwer abzuschätzen, da nach erster Recherche keinerlei Bibliotheken gefunden werden konnten, die diese Funktionalität realisieren. Allerdings ist davon auszugehen, dass der zu erwartende Aufwand die bisherigen Einsparungen der plattformübergreifenden Entwicklung mit Titanium ausgleicht. Die Umsetzung einer Tastaturanpassung als Alternative zum Rich-Text-Editor, damit die Zeichen @ und # schnel- ler eingegeben werden, können ist nur teilweise gelungen. Die Tastatur selbst kann unter iOS überhaupt nicht geändert werden, es kann lediglich eine aus verschiedenen Konfigurationen aus- gewählt werden. Android bietet hingegen die Möglichkeit, eine komplett eigene Tastatur zu ent- werfen, welche jedoch vom Nutzer explizit genutzt werden muss, entweder als Standardtastatur oder das Layout muss bei jeder Verwendung erneut eingestellt werden. Eine bessere Alternative bietet iOS. Dort kann über der Tastatur eine Leiste eingebunden werden, die zusätzliche Funktio- nen aufnehmen kann. Dort wurden zwei Tasten eingesetzt, die dem Text das jeweilige Zeichen hinzufügen, allerdings nur an das Ende des Textes, was keine ideale Lösung ist. Nativ hingegen ließe sich das Zeichen unter iOS an der aktuellen Cursorposition einfügen. Eine Übersicht über die derzeit umgesetzten Anforderungen gibt Tabelle A.1 im Anhang auf Seite 43.

Gut gelöst ist das Zusammenspiel zwischen plattformabhängigen und -unabhängigen Bereichen. Zwar würde eine vollwertige Vererbungsstrategie ermöglichen, einen gemeinsamen Rumpf für Controller und grafische Oberfläche zu entwerfen, der von der jeweiligen Plattform verfeinert wer- den kann, allerdings lässt sich das mit einigen Abstrichen auch ohne Vererbung realisieren. Dies soll am Beispiel des Informationsstroms verdeutlicht werden. Im plattformunabhängigen Bereich existiert dazu eine Klasse, welche die Controller-Logik übernimmt. Dazu gehören vor allem das Laden und Aktualisieren der Informationen und des Stroms. Die Generierung der grafischen Oberfläche wird ebenfalls in diesem Bereich angestoßen. Dazu werden die einzelnen grafischen Komponenten aus dem plattformspezifischen Bereich geladen. Dies gilt insbesondere für die Erzeugung der Listeneinträge. Diese werden über den REST-Client im Backend geladen. An- schließend wird für jede Information ein Listeneintrag im plattformspezifischen Bereich erzeugt.

3http://www.evernote.com

5.2 Grafische Oberfläche 37 Dadurch ist es möglich, auf die bereits erwähnten Eigenheiten der jeweiligen Systeme besser einzugehen.

Leider ist diese Strategie nicht überall anwendbar. Der in Abschnitt 4.3.3 vorgestellte Ansatz, der die Ansicht zum Verfassen einer Nachricht plattformübergreifend erzeugt, ist nicht umsetzbar. Ursache dafür sind Unterschiede der beiden betrachteten Betriebssysteme. Unter iOS sind alle Höhen- und Breitenangaben der grafischen Elemente bekannt, sodass explizit damit gerechnet und die grafische Oberfläche danach ausgerichtet werden kann. Die verschiedenen Auflösungen unter Android und die zahlreichen Eigenimplementierungen der grafischen Oberfläche durch die Hersteller, erzwingen unter Android ein anderes Vorgehen.

Es zeigt sich, dass der Verzicht auf Vererbung kein Nachteil für die grafische Oberfläche ist, wobei es durchaus Bereiche der Anwendung gibt, in denen dieses Vorgehen nicht funktioniert. Das Ver- fassen von Nachrichten kann auf dieses Weise nicht gelöst werden, weil zu viele Anpassungen notwendig sind, vor allem auch für Tablet und Smartphone. Diese Oberflächen werden daher se- parat für jede Plattform generiert. Letztendlich wird klar, dass eine einzige Implementierungen für alle Plattformen und Geräte nicht ausreicht, um diesen komplexen Anwendungsfall abzudecken. Vor allem Tablet und Smartphone bedürfen einer eigenen Umsetzung, aber auch für die beiden Betriebssysteme kann nicht durchweg gemeinsam entwickelt werden. Es wird jedoch deutlich, dass viele Komponenten, je stärker sie fragmentiert sind, desto häufiger, wiederverwendet wer- den können. Der Informationsstrom wird beispielsweise von allen Geräten und Plattformen ver- wendet und besitzt lediglich Anpassungen im Bereich der Generierung der Listeneinträge.

Eine Analyse des aktuellen Entwicklungsstands hat ergeben, dass die 26 plattformübergreifenden UI-Klassen den Großteil des Quelltextes beinhalten. Hinzu kommen für jede Plattform etwa 14 Klassen, die mehrheitlich, ähnlich einem Strategie-Architekturmuster, die plattformspezifischen grafischen Elemente generieren. Für beide Systeme existieren jedoch auch drei Klassen, die einen kompletten View generieren, da die plattformübergreifende Entwicklung zu ineffizient wäre. Das bedeutet, dass 50% des Quelltextes komplett plattformunabhängig sind und bis zu vier mal wieder verwendet, jeweils etwa 20% des Quelltextes generieren die plattformspezifischen UI- Elemente, die meistens zweimal genutzt werden, und nur die verbliebenen 10% sind Quelltext, der nicht wiederverwendet werden kann.

5.2.4 Einhaltung der User-Interface-Guidelines

Ob Fluch oder Segen für Entwickler, die User-Interface-Guidelines sind ein nicht zu vernachläs- sigender Bestandteil der Anwendungsentwicklung. Während Apple diese zusammen mit dem AppStore im Juli 2008 einführte [App12e], verfügt Android erst seit Beginn des Jahres 2012 über derartige Richtlinien und sind (derzeit) nur für die vierte Version des Betriebssystems verfügbar [And12a]. Die Einhaltung dieser Richtlinien ist wichtig, da eine Missachtung, speziell unter iOS, zum Ausschluss aus dem AppStore führen kann.

Vorweg ist zu erwähnen, dass Titanium dem Entwickler die Einhaltung dieser Richtlinien nicht abnimmt. Die Betrachtung soll in erster Linie einschätzen, ob dem Entwickler die Einhaltung er- möglicht und nicht verwehrt wird. Dabei spielt das Funktionsprinzip von Titanium, die Anwendung zur Laufzeit in plattformspezifischen Code zu übersetzen, eine entscheidende Rolle.

Unter iOS stehen alle wichtigen UI-Elemente und Bedienkonzepte, sowohl für das iPhone als auch für das iPad, zur Verfügung, sodass die Einhaltung der User-Interface-Guidelines vollständig an den Entwickler abgegeben wird. Dabei gibt es keinerlei Einschränkungen, die der Entwick- ler in Kauf nehmen muss, im Rahmen der Richtlinien bleiben alle Freiheiten erhalten. Apples iOS bietet den Entwicklern von Titanium zudem einen entscheidenden Vorteil: Das Design der Anwendungen ist über die verschiedenen Betriebssystemversionen hinweg konsistent.

38 Kapitel 5 Bewertung Diesen Vorteil kann Android nicht bieten. Jede Hauptversion kommt mit einem, wenn manch- mal auch nur leicht, anderen Design daher. Dazu kamen, bis einschließlich Android 3, herstel- lerspezifische Designs, die eine einheitliche Gestaltung zusätzlich erschwerten. Damit auch die älteren Android-Versionen (ab 2.2) unterstützt werden, die immer noch einen Anteil von etwa 80% [And12b] aller Android-Geräte ausmachen, greift Titanium auf den API-Level 8 zurück. Die Support-Bibliotheken [And12f], die Funktionen und grafische Elemente der neuesten Betriebs- systemversionen auch für ältere Systeme bereitstellen, werden leider nicht genutzt. Dies wirkt sich sichtbar auf die grafische Oberfläche aus, die auch auf neueren Versionen nach Android 2.x aussieht. Die Einhaltung der User-Interface-Guidelines ist daher zwiegespalten. Die Richtlinien existieren erst seit Android 4 und lassen sich etwas eingeschränkt auch auf Android 3 übertragen. Für Android 2 gibt es keine Richtlinien und die aktuellen lassen sich nicht auf Android 2 anwen- den. Anwendungen mit dem Design von Android 3 oder 4 lassen sich mittels Titanium jedoch nicht realisieren.

Für Titanium gilt daher, dass eine vollständige Einhaltung der User-Interface-Guidelines nicht mög- lich ist, da einerseits keine Richtlinien für Android 2 existieren, andererseits die Richtlinien für Android 3 beziehungsweise 4 nicht eingehalten werden. Zwar werden dem Entwickler, wie bei iOS, alle Freiheiten bezüglich des Designs der Anwendung überlassen, sind jedoch auf die Mög- lichkeiten von Android 2.2 beschränkt. Positiv zu erwähnen ist jedoch, dass die Auswirkungen der Missachtung dieser Richtlinien nicht zum Ausschluss aus den verschiedenen Vertriebsplattformen führen.

5.2.5 Native Entwicklung

Ein wesentliches Kriterium für den Einsatz von plattformübergreifenden Technologien ist die Zeit- beziehungsweise Arbeitsersparnis gegenüber der nativen Entwicklung. Dabei sollte in erster Li- nie erreicht werden, dass nicht für jede Plattform eine separate Oberfläche entwickelt werden muss. Dies konnte im vorletzten Abschnitt bereits gezeigt werden. Der Fokus dieses Abschnitts liegt auf der Einsparung bei Entwicklung auf einer Plattform, genauer gesagt darauf, ob es Ein- sparungen gibt, wenn eine Anwendung nur für iOS oder Android mit Titanium entwickelt wird.

Apple liefert für iOS sehr mächtige Entwicklerwerkzeuge, wozu unter anderem ein WYSIWYG4- Editor für die grafische Oberfläche gehört. Dieser Editor, der sogenannte InterfaceBuilder, ermög- licht das Design der Oberfläche und stellt die Schnittstellte zur Ablaufsteuerung bereit. Seit iOS 5 wird der InterfaceBuilder durch das sogenannte Storyboard ergänzt, welches die Navigation, Ablaufsteuerung und Ereignisroutinen der gesamten Anwendung realisieren kann. Im Vergleich dazu ist die Generierung der grafischen Oberfläche unter Titanium nur programmatisch möglich, was, je nach Komplexität des Anwendungsfalls, eine Verdoppelung bis Vervierfachung der Ent- wicklungszeit zur Folge hat. Ebenso steigt die Zahl der notwendigen Quelltextzeilen, wobei eine genaue Abschätzung schwierig ist, da Titanium im Gegensatz zu iOS kein MVC-Architekturmuster unterstützt und die Ergebnisse dadurch verfälscht werden. Die Gestaltung eines Views unter Ti- tanium kommt jedoch nur selten mit weniger als 100 Quelltextzeilen aus.

Diese Gestaltung der grafischen Oberfläche muss jeweils für iPhone und iPad vorgenommen wer- den. Unter diesem Aspekt ist die Entwicklung mit Titanium vermutlich aufwendiger. Allerdings funktioniert Storyboard nur dann, wenn sich strikt an die nativen Bedienkonzepte und die iOS Hu- man Interface Guidelines [App12e] gehalten wird. Da die Konzeption in diesem Fall aber einigen nativen Konzepten widerspricht, muss dies genauer untersucht werden.

Den schwierigsten Part bildet wieder einmal die Navigation. Das Menü, insbesondere der nicht sichtbare, animierte Bereich, ist kein nativer Bestandteil und muss daher manuell modelliert wer- den. Während der Recherche konnten weder Tutorials oder andere Anleitungen gefunden wer- den, sodass im Rahmen dieser Arbeit nicht erschöpfend evaluiert werden kann, ob dieser Ansatz

4What you see is what you get

5.2 Grafische Oberfläche 39 mit Storyboard realisierbar ist oder nicht. Eine Umsetzung ohne Storyboard, mit einzelnen Views und Controllern, ist dennoch möglich, wenngleich aufwendiger. Mittlerweile gibt es dafür fertige Bibliotheken beziehungsweise Beispielprojekte [Klu12; Pau12], welche diese Menüstruktur abbil- den. Die Analyse dieser Projekte hat ergeben, dass einige Anpassungen notwendig sind, da das Konzept der Anwendung eine hohe Mehrfachverwendung bestehender Views vorsieht, weshalb einige Bibliotheken nur eingeschränkt nutzbar sind.

Die Steuerung der einzelnen Views, also die Umsetzung der Navigation innerhalb der Anwen- dung, inklusive der Anbindung der Controller an das Backend, wird mit einem Aufwand von knapp 1000 Zeilen Quelltext abgeschätzt. Die Einarbeitung in das Speicherallokationsprinzip unter iOS wird zudem einen Einarbeitungsaufwand von mehr als zwei Projekttagen in Anspruch nehmen.

Die Entwicklung einer App für iOS, die mit eigener grafischer Oberfläche und eigenem Bedien- konzept arbeitet, bedeutet einen wesentlichen Mehraufwand für die Entwicklung, was sich auch mit den Erfahrungen anderer Entwickler deckt [Had11]. Titanium erleichtert die Arbeit in diesem Fall, obwohl nicht gänzlich auf eine teilweise separate Entwicklung für iPhone und iPad verzichtet werden kann.

Unter Android ändert sich der Aufwand, abhängig davon, welche Technologien eingesetzt und welche Geräte unterstützt werden sollen. Die größte Herausforderung für die native Umsetzung der grafischen Oberfläche unter Android sind die unzähligen Gerätevariationen. Mittlerweile wur- den zwar diverse Standards eingeführt, allerdings kann für jede Gerätekonfiguration eine separate Oberfläche gestaltet werden [And12c; And12e]. Die einzige Hürde in Titanium ist die Erkennung, ob es sich um ein Smartphone oder Tablet handelt. Anschließend kann das Design, wie auch unter iOS, sehr einfach umgesetzt werden, denn während nativ insgesamt wenigstens acht ver- schiedene Layouts zur Verfügung stehen sollten, reichen unter Titanium maximal vier (Tablet, Smartphone, jeweils Portrait und Landscape).

Auch wenn es Hürden bei der Umsetzung des Menüs unter Android gibt, so ist die Umsetzung in Titanium derzeit wesentlich einfacher. Ändern könnte sich das mit der zunehmenden Verbrei- tung von Android 4. Mit den eingeführten Fragmenten erhöht sich der Wiederverwendungsgrad der einzelnen grafischen Komponenten und die Tabletunterstützung wird verbessert. Derzeitig besteht der Nachteil noch darin, dass die grafischen Editoren für die Android-Oberfläche diese Fragmentierung, wenn überhaupt, noch nicht besonders gut unterstützen. Die Gestaltung muss daher manuell in XML vorgenommen werden. Zur Gestaltung kommen noch die Controller, de- ren Entwicklungsaufwand nativ etwas größer ist, da es sich teilweise schwierig gestaltet, auf die jeweiligen UI-Komponenten zuzugreifen. Abhilfe dafür schafft ein zusätzliches Framework, das sogenannte Annotationen für Android einführt. Mit AndroidAnnotations5 werden viele Operatio- nen automatisiert. Darunter fällt unter anderem der Zugriff auf grafische Komponenten, sowie die Reaktion auf deren Ereignisse, aber auch beispielsweise die Generierung eines REST-Clients für das Backend. Dadurch sind Einsparungen bis zu 50% gegenüber der herkömmlichen Program- mierweise möglich.

Das bedeutet, dass unter Verwendung der Fragmente, welche durch die Support-Bibliotheken [And12f] auch für Android 2.x zur Verfügung stehen, und Einbeziehung des AndroidAnnotations- Projekt, durchaus eine schnellere Entwicklung möglich ist. Dies würde durch einen effizienten grafischen Editor, ähnlich zu Storyboard für iOS, noch verstärkt. Der Einarbeitungsaufwand in die verschiedenen Technologien ist jedoch wesentlich höher als die Einarbeitung in Titanium.

Insgesamt zeigt sich, dass die separate, native Entwicklung beider Plattformen unter dieser Kon- zeption wesentlich mehr Entwicklungsaufwand in Anspruch nimmt, als eine plattformübergrei- fende Umsetzung mittels Titanium.

5http://androidannotations.org

40 Kapitel 5 Bewertung 6 ZUSAMMENFASSUNG & AUSBLICK

Ziel der Arbeit war es, ein Framework zu finden, das sich langfristig zur plattformunabhängigen Entwicklung mobiler Anwendungen eignet. In Kapitel 3 wurde dazu eine Auswahl an Frameworks vorgestellt und analysiert. Die Bewertung der Frameworks setzte sich im Wesentlichen aus drei Aspekten zusammen:

1. Plattformunabhängigkeit 2. Entwicklungs- und Wartungsaufwand 3. Einhaltung der User-Interface-Guidelines

Bei dieser Analyse lieferten sowohl Appcelerator Titanium als auch Apache Cordova in Verbindung mit Sencha Touch sehr gute Ergebnisse. Letztlich konnte sich Appcelerator Titanium, trotz eines höheren Entwicklungsaufwandes, auf Grund des besseren Nutzerempfindens durchsetzen.

Die weitere Evaluierung hat gezeigt, dass Titanium ein Framework ist, das sowohl für einfache als auch umfangreichere Anwendungsfälle, wie den hiesigen, geeignet ist. Dennoch lässt sich nicht alles umsetzen, was nativ möglich ist, wie beispielsweise der in den funktionalen Anforderungen gewünschte Rich-Text-Editor. Ursache dafür sind die vereinheitlichten Programmierschnittstellen, die einerseits die plattformübergreifende Entwicklung überhaupt erst ermöglichen, den Entwick- ler andererseits in seinen Möglichkeiten einschränken. Daher soll nachfolgend der Aspekt der Plattformunabhängigkeit noch einmal zusammengefasst werden, welcher jedoch stark mit dem Entwicklungs- und Wartungsaufwand korreliert, sodass diese Aspekte nicht gänzlich getrennt betrachtet werden können.

Ein entscheidender Kritikpunkt ist, dass es, abgesehen von sehr einfachen Anwendungsfällen, nicht möglich ist, die grafische Oberfläche für Android und iOS gänzlich ohne plattformspezifi- sche Anpassungen umzusetzen. Dabei stellt Appcelerator diverse Tutorials bereit, um plattform- übergreifende Ansätze zu realisieren. Ein Beispiel ist die plattformübergreifende Umsetzung der iOS-typischen NavigationGroup, welche in einem Tutorial [Whi11] erklärt wird. Hier stellt sich die Frage, warum dieser plattformunabhängige Ansatz nicht zu den Bordmitteln von Titanium gehört. Hinzu kommt das unterschiedliche Verhalten auf verschiedenen Plattformen bei gleicher Konfigu- ration. Dies ist vor allem kritisch, weil diese Unterschiede nur selten ausreichend dokumentiert sind. Allerdings muss positiv erwähnt werden, dass abgesehen vom grundlegenden Bedien- konzept, das unter Umständen für jede Plattform separat entwickelt werden muss, sehr viele

41 Komponenten und Views wiederverwendet werden können, sodass gegenüber der nativen Im- plementierung einiges an Entwicklungsaufwand, vor allem aber an Wartungsaufwand eingespart werden kann.

An dieser Stelle kann jedoch angesetzt werden, um eine bessere plattformübergreifende Ent- wicklung zu ermöglichen. Eine Möglichkeit ist die Konzeption einer Beschreibungssprache, die einheitlich für alle Plattformen die grafische Oberfläche und ihr Verhalten beschreibt. Daraus kann letztendlich der plattformspezifische Quelltext generiert werden, um die Oberfläche zu realisieren.

Der Mehraufwand für die Entwicklung der grafischen Oberfläche bleibt jedoch der einzige we- sentliche Kritikpunkt. Besonders hervorzuheben ist die Entwicklung der Programmlogik, die im Wesentlichen für Client-Server-Kommunikation, Datenverarbeitung und Persistierung zuständig ist. Dieses Backend muss für alle Plattformen und Geräte nur einmal umgesetzt werden, was den Entwicklungs- und Wartungsaufwand entscheidend minimiert.

Ein weiterer Vorteil ist die genutzte Programmiersprache. Sowohl für das Backend als auch für die grafische Oberfläche wird JavaScript eingesetzt, was die Einarbeitung in das Framework deut- lich erleichtert und verkürzt. Zudem kann die Entwicklung an vielen Stellen optimiert werden, da JavaScript beispielsweise die JSON-Verarbeitung deutlich besser beherrscht als Java oder Objective-C.

Rückblickend auf den Status Quo und die bisherige Umsetzung dieses Anwendungsfalls mittels Rhodes, müssen vor allem die Debugging-Möglichkeiten erwähnt werden. Besonders Titanium konnte diesbezüglich überzeugen. Breakpoints können innerhalb der Entwicklungsumgebung gesetzt werden und der Debugger hält exakt an dieser Stelle im JavaScript-Code an. Die Auswer- tung der Variablen ist zwar nicht so komfortabel wie im Webbrowser, aber dennoch einfacher als in Java oder Objective-C.

Die Einhaltung der User-Interface-Guidelines wird im Wesentlichen dem Entwickler überlassen. Unter iOS konnten zudem keine Einschränkungen für den Entwickler bezüglich der Gestaltung der grafischen Oberfläche festgestellt werden, sodass dieser für die Einhaltung der Richtlinien voll verantwortlich ist. Unter Android steht nur die grafische Oberfläche der Betriebssystemversion 2.x zur Verfügung, sodass die Richtlinien, die seit Android 4 existieren, nicht angewendet werden können. Der Entwickler ist damit allein für die grafische Gestaltung und Konzeption verantwort- lich. Zudem können nicht alle nativ verfügbaren Elemente genutzt werden, was vermutlich der Vielzahl an Betriebssystemversionen und der unterschiedlichen Verbreitung dieser geschuldet ist.

Letztlich bleibt noch die Frage zu klären, ob Titanium das Framework für die plattformübergrei- fende Entwicklung mobiler Anwendungen ist. Diese Frage lässt sich jedoch nicht allgemein be- antworten, ist die Antwort doch von sehr vielen Faktoren abhängig.

Feststellen lässt sich, dass Titanium ein Framework ist, mit dem schätzungsweise mehr als 95% aller Anwendungsfälle umgesetzt werden können. Einige, sehr spezifische, Anforderungen kön- nen mit diesem Framework nicht umgesetzt werden, wie diese Arbeit aufgezeigt hat. Für sehr einfache Anwendungsfälle ist der hier vorgestellte Einsatz von Titanium durchaus überdimensio- niert. Titanium sollte vor allem dann eingesetzt werden, wenn der Anwendungsfall mit einer mobilen Internetseite nicht oder nur schlecht realisiert werden kann. Dazu zählt auch das man- gelhafte Nutzerempfinden, welches in dieser Arbeit dazu führte, dass Titanium Sencha Touch vorgezogen wurde.

Alles in allem zeigt sich, dass Appcelerator Titanium ein Framework ist, welches die plattformüber- greifende Entwicklung sehr gut realisiert. Auch wenn die Entwicklung der grafischen Oberfläche nicht gänzlich plattformunabhängig ist, so gleichen ein geringerer Einarbeitungsaufwand und die optimierte Wartung diesen Mehraufwand der initialen Entwicklung wieder aus.

42 Kapitel 6 Zusammenfassung & Ausblick A TABELLEN

Tabelle A.1: Aktuell umgesetzte Anforderungen

Anforderung iOS Android Hinweis Fotoanhänge (Kamera) XX derzeit kein Upload wegen Dateianhänge ◦ ◦ fehlender API-Unterstützung Geolocation XX Teilen (Android) - ◦ Rich-Text-Editor - - nur nativ möglich Tastaturanpassungen X - iOS teilweise, Android nicht möglich Benachrichtigung - ◦ Persistierung XX Verschlüsselung XX Module notwendig Internationalisierung XX App-Auslagerung (Android) - ◦ Kontakte ◦ ◦ Natives Look & Feel XX Android-UI in Version 2.x Lade- & Reaktionszeit nativ nativ Xumgesetzt ◦ noch nicht umgesetzt - nicht umsetzbar

43 44 Tabelle A.2: Kriterien für die Klassifikation von Entwicklungsansät- nagATabellen A Anhang zen mobiler Anwendungen

Kriterium nativ webbasiert hybrid interpretiert generiert Programmiersprache nativ Websprachen Websprachen beliebig beliebig Laufzeitumgebung - Browser erweiterte Browserengine client-seitige VM (Interpreter) - Übersetzung in native Sprache1 - - - zur Laufzeit während Kompiliervorgang Verteilung via AppStore X - XXX 2 3 3 3 Systemzugriff X stark eingeschränkt X X X

1Es können auch native und Websprachen kombiniert werden. Ein Beispiel dafür ist das Framework Rhodes, welches in [Wei12] vorgestellt wird. 2Zugriff auf Daten (Kontakte, Bilder, etc.) und Sensoren (Geolocation, Kompass, etc.) des Geräts. 3teilweise eingeschränkt, meist erweiterbar durch eigene Module B ABBILDUNGEN

Visual Paradigm for UML Community Edition [not for commercial use] NoteCreationView FactoryClass iOS

User 1: open

2: createView

3: start choose topic 3.1: create topic chooser 3.1.1: create platform specific picker

3.1.2: add events 4: choose topic

4.1: fire item specific event

4.2: return topic via platformindependent event

Abbildung B.1: Beziehung zwischen plattformabhängigem und -unabhängigem Quelltext

45 46 Visual Paradigm for UML Community Edition [not for commercial use]

nagBAbbildungen B Anhang Model REST NoteList base <> NotesProvider <> 1 filter RequestProvider * +loadNotes(_filter, _callback) Filter +getNotes(_filter) : Array +getBaseUrl(secure, server, apiVersion, resource, filterParams) : String filter -filterId : int +getNote(noteId : int) : Note +getRequest(apiVersion, resource, filterParams) : HTTPClient -filterName : String +loadNote(noteId : int, _callback) : Note +getUserImageUrl(secure, server, apiVersion, userId, imageSize) : String -filterParams : String +postNote(note, _callback) : Note +getImageRequest(apiVersion, userId, imageSize) : HTTPClient -isStatic : boolean +deleteNote(noteId : int, _callback) +prepareFilter(filterParams) : Object +paramsToJSON() : String +likeNote(noteId : int, like : boolean, _callback) +jsonToParams(json : String) : void +favorNote(noteId : int, favor : boolean, _callback) +loadDiscussion(discussionId : int, _callback) * note Attachment <> -attachmentId Note UsersProvider attachments -fileName -id : int -fileType <> +loadUsers(_filter, _callback) -text : String * -contentLength TopicsProvider +loadUserImage(userId : int, _callback) -shortText +loadTopics(_filter, _callback) +getUserImage(userId : int) : Blob -isDirectMessage : boolean +getBinary() +getTopics(_filter) : Array +getUsers(_filter) : Array -userNoteProperties : Object +followTopic(topicId : int, _callback) +getUser(userId : int) : User bidn .:Backend B.2: Abbildung -creationDate : Date +followUser(noteId : int, _callback) -numberOfChildNotes : int Topic <> topic -tags -topicId : int AttachmentsProvider -rights : Object 1 -alias : String -numberOfLikes : int -title : String -discussion +follow(_callback) -parentNoteId : int -read : boolean -seen : boolean User AttachmentsProviderStrategy TopicsProviderStrategy UsersProviderStrategy NotesProviderStrategy +isSimple() : boolean author +getSimpleText() : String -userId : int +returnProvider() : AttachmentsProvider +returnProvider() : TopicsProvider +returnProvider() : UsersProvider +returnProvider() : NotesProvider +like(like : boolean, _callback) 1 -alias : String +favor(favor : boolean, _callback) -firstName : String +loadDiscussion(_callback) -lastName : String v2.2 +getUserImage() : ImageView +follow(_callback) NotesProvider TopicsProvider AttachmentsProvider UsersProvider usersToNotify *

PersistenceManager ApiSherlock +initDB() : void +getVersion() : String +deleteDB() : void +storeTimelineNotes(noteList : Array) <> +storeTopics(topicList : Array) FilterManager Credentials +storeUsers(userList : Array) +getFilterById(filterId : int) : Filter +storeFilters(filters) : void +getFilterByName(nameOfFilter : String) : Array +checkCredentials() : boolean +storeUserImage(userId : int, image : Blob) +getAllFilter() : Array +removeCredentials() : void +updateTopic(topic : Topic) : Topic +storeFilter(filter) : void +getUsername() : String +updateUser(user : User) : User +storeFilters(filters) : void +getPassword() : String <> +updateFilter(filter : Filter) : Filter +updateFilter(filter) : filter +getInstallation() : String +getTopic(topicId : int) : Topic +getServiceId() : String +getUser(userId : int) : User +getSSL() : Boolean +getTimelineNote(noteId : int) +getCredentials() : Array