Ist PhoneGap der (mobile) Zauberstab?
Kommentare

Manchmal hat man keine andere Wahl, als mehrere mobile Anwendungen für eine Reihe von Betriebssystemen zu schreiben – iOS, Android, vielleicht Windows Phone und möglicherweise noch mehr. Ohne Umschweife sei gesagt, dass das meistens bedeutet, die Anstrengungen und das Budget mit der Anzahl der angeforderten Anwendungen zu multiplizieren. Gibt es hier irgendeinen Ausweg? Leider können Ihnen hier weder ein Zauberer noch ein Zauberstab helfen. Sie müssen sich durchkämpfen und Ihre Strategie verbessern, um den Aufwand zu minimieren; wenn Sie ihn nicht einfach über die Zeit verteilen wollen.

PhoneGap kommt mit dem Versprechen der Wiederverwendbarkeit daher: Die mobile Anwendung einmal schreiben und sie auf sieben unterschiedliche Plattformen portieren. Auch wenn dieses Versprechen im Wesentlichen erfüllt wird, bin ich mir nicht sicher, ob PhoneGap wirklich das Geheimrezept für mobile Apps ist. In einem kürzlich begonnenen Multi-App-Projekt hatten wir PhoneGap zunächst begeistert aufgegriffen, aber mit demselben Enthusiasmus nach dem ersten Proof of Concept wieder fallen lassen.

Alle mobilen Plattformen unterscheiden sich voneinander: Jede mobile Plattform hat ihr eigenes SDK, ihre eigene Programmiersprache und ein eigenes Programmierparadigma, spezielle Entwicklungstools und manchmal sogar ein eigenes Betriebssystem. Allerdings stellen die meisten mobilen Anwendungen lediglich das Frontend eines bestimmten Backends dar. Es ist nicht erforderlich, das Backend für jeden mobilen Client neu zu schreiben; die eigentliche Mühe bei der mobilen Entwicklung für mehrere Plattformen ist das Erstellen des Frontends. Und diese Mühe hat auch viel mit Kosten zu tun. Manche Unternehmen ziehen es deshalb vor, nur das Backend im eigenen Haus zu entwickeln und die Entwicklung der Frontends auf verschiedene Firmen auszulagern. Dadurch parallelisieren sie die Entwicklung in gewissem Umfang und sparen sich zumindest die Ausbildung ihrer eigenen Entwickler. Außerdem bleibt das Fachwissen innerhalb des Unternehmens. Das erweist sich manchmal als gute Lösung, doch funktioniert es längst nicht für jeden.

Seit Einführung von iPhone und Android ist man in der Industrie bestrebt, kostengünstigere Lösungen für die plattformübergreifende Anwendungsentwicklung zu finden. Derzeit ist PhoneGap in aller Munde als das ideale Tool, um eine mobile Anwendung einmal zu schreiben und sie auf eine Vielzahl von Plattformen zu portieren – und das in einem Bruchteil der Zeit, die es sonst dauert, wenn man dieselbe Anwendung von Grund auf neu schreibt. In diesem Artikel möchte ich die Architektur beleuchten und erläutern, wie eine PhoneGap-Anwendung tatsächlich arbeitet. Es ist hierbei nicht notwendig eine echte Anwendung zu schreiben, um Stärken und Schwächen der Lösung herauszustellen.

Zurückhaltung ist angesagt

Ursprünglich ein Start-up, ist PhoneGap vor einem Jahr von Adobe übernommen worden. PhoneGap ist ein Open-Source-Framework, mit dem sich mobile Anwendungen für bis zu sieben verschiedene Plattformen mithilfe von HTML, CSS und JavaScript erstellen lassen.

In diesem Sommer hat PhoneGap die Version 2.0 erreicht und kann insgesamt als ein nahezu reifes Produkt betrachtet werden. Unter einem „reifen“ Produkt verstehe ich ein Produkt, das für ein bestimmtes Projekt funktionieren kann oder auch nicht, aber es in kein Produkt, dass erst dann funktioniert, wenn noch ein paar extra Features hinzugefügt wurden. Sie sollten PhoneGap ausprobieren und sehen, ob es die Anwendungen liefert, die Ihrem spezifischen Projekt auf die Sprünge helfen können.

Zögern Sie nicht länger, die Zeit ist reif, um Erfahrungen mit PhoneGap zu sammeln. Doch seien Sie nicht allzu überrascht, wenn es nicht dem entspricht, was Sie sich erhofft haben.

PhoneGap vs. Apache Cordova

Bevor es losgeht, sind noch einige Namensverwirrungen um PhoneGap zu klären. Wenn Sie eine Suche nach PhoneGap ausführen, landen Sie schließlich bei Apache Cordova. In welcher Beziehung stehen beide? Als Teil der Open-Source-Initiative hat Adobe der Apache Software Foundation den PhoneGap-Code gespendet. Um Markennamenprobleme zu vermeiden, wurde der von Apache verwaltete und erweiterte Code in „Apache Cordova“ umbenannt. Was also ist PhoneGap heute? Es ist einfach die primäre und bekannteste Distribution des Open-Source-Moduls namens Apache Cordova, mit dem Sie jetzt native, mobile Anwendungen mithilfe des Webentwicklungsparadigmas erstellen können. Unter [1] finden Sie die ganze Geschichte. Am besten kann man es vielleicht so betrachten: Cordova verhält sich zu PhoneGap fast genauso wie WebKit zu Chrome oder Safari.

PhoneGap verstehen

PhoneGap ist also um eine einfache, aber intelligente Idee herum aufgebaut: Man erstellt eine lokale HTML-Anwendung mithilfe von CSS, um Seiten zu formatieren, und JavaScript (einschließlich externer Bibliotheken wie zum Beispiel jQuery), um Verhalten und Logik hinzuzufügen. Dann verpackt PhoneGap dies als native Anwendung für eine Vielzahl von mobilen Plattformen. Ja, Sie haben richtig gelesen: Ihr Satz von Client-HTML-Seiten kann zu einer nativen iPhone- oder Android-App werden. Mit „Client-HTML-Seiten“ meine ich statische HTML-Seiten, die nicht von einem Webserver heruntergeladen werden, sondern möglicherweise in der Lage sind, Daten von einem Remote-Server via AJAX abzurufen. Im Jargon dieser Tage könnte man sagen, dass eine PhoneGap-Anwendung eine mobile Single Page Application (SPA) ist, die lediglich für eine spezifische Plattform wie zum Beispiel iOS, Android oder Windows gepackt wurde.

Klingt irgendwie magisch, oder? Der Erfahrung nach wird aber Zauberei in Software nicht unterstützt. Doch laufen bei Softwaremagie ganz ähnlich wie in Zaubershows einige intelligente Tricks hinter dem Vorhang ab. In dieser Hinsicht bildet PhoneGap keine Ausnahme. Sehen wir uns die interne Struktur einer PhoneGap-Anwendung an.

[ header = Ist PhoneGap der (mobile) Zauberstab? – Teil 2 ]

Von SPA zu Packaging

Ich habe schon darauf hingewiesen, dass PhoneGap eine SPA in eine native Anwendung verpackt. Auch wenn dies im Großen und Ganzen gut beschreibt, was passiert, ist es technisch nicht ganz korrekt. Zuallererst schreibt ein PhoneGap-Entwickler eine SPA und verwendet dabei alles, was er braucht, damit die Anwendung erwartungsgemäß funktioniert: jQuery und Plug-ins, Knockout sowie eine mobilspezifische Bibliothek wie zum Beispiel jQuery Mobile, Sencha oder auch jqTouch.

Bei der Entwicklung der SPA binden Sie eine PhoneGap-Skriptdatei ein, um Zugriff auf gerätespezifische Fähigkeiten zu erhalten. Der Zugriff auf das Gerät macht den wesentlichen Unterschied zwischen dem Kern einer PhoneGap-Anwendung und einer reinen mobilen Site aus. Die PhoneGap-Skriptdatei bietet eine Programmierschnittstelle zu einigen der Gerätefeatures – unter anderem Vibration, Kamera, Bildschirm, Beschleunigungsmesser, Geolocation, Dateisystem, Medien und Kontakte. Ihre SPA kann alle ihr zugänglichen Daten nutzen. Das sind Daten, die sie via AJAX und JSON erreicht sowie sämtliche Daten, die über die PhoneGap-Brücke zum zugrundeliegenden Gerät erreichbar sind. Gut und schön, aber immer noch eine SPA. Der nächste Schritt ist das Packaging.

Bislang haben Sie Ihre SPA mit Ihrer bevorzugten IDE erstellt – ob es sich nun um Notepad++, WebStorm, Visual Studio, Eclipse oder irgendeine andere handelt. Nun müssen Sie ein neues Projekt für jede mobile Plattform anlegen, die Sie bedienen möchten. Nehmen wir an, dass Sie vor allem auf iOS Wert legen. Sie rüsten sich mit Mac, Xcode und dem iOS SDK aus und erstellen ein neues Projekt. Als Nächstes installieren Sie PhoneGap für iOS [2]. Der wichtigste Bestandteil des Downloads ist die Komponente, die die Brücke vom iOS SDK zur PhoneGap-Skriptdatei realisiert. Abbildung 1 veranschaulicht die Architektur.

  Abb. 1: Eine Brücke von gerätespezifischen Features zu HTML-Seiten realisieren

Die Downloadseite von PhoneGap bietet unterschiedliche Binärkomponenten für jede unterstützte Plattform: iOS, Android, Windows Phone, BlackBerry, Symbian, WebOS und Bada.

Alles dreht sich um WebView

Der Trick bei PhoneGap besteht darin, dass die gesamte SPA als Ressource zum plattformspezifischen Projekt hinzugefügt und zur Laufzeit in ein Vollbild WebView-Widget geladen wird. Die öffentliche Schnittstelle der nativen Bibliothek wird (wie in Abb. 1 gezeigt) im Browserhost veröffentlicht und skriptfähig gemacht. Dafür ist die PhoneGap-Bibliothek zuständig. Der gesamte Mechanismus ähnelt der Art und Weise wie Skripting in Webbrowsern funktioniert. Darüber hinaus bietet PhoneGap ein vernünftiges Maß an Erweiterbarkeit in dem Sinne, dass Sie Ihre eigenen Erweiterungen erstellen und sie für die eingebettete SPA veröffentlichen können.

PhoneGap erlaubt Ihnen den Zugriff auf die nativen Features des Geräts, doch verläuft dieser Zugriff über eine feststehende Schnittstelle. Wenn Sie auf nicht eingebundene (oder nicht in Ihrem Sinne eingebundene) Features zugreifen müssen, ist es erforderlich, nativen Code zu schreiben (d. h. Objective C oder MonoTouch für iOS, Java für Android) und Ihr eigenes natives PhoneGap-Plug-in zu erstellen.

Das Projekt verwalten

PhoneGap kommt mit dem Versprechen, dass Sie Code nur einmal schreiben müssen und ihn dann mit geringem Aufwand auf sieben unterschiedliche Plattformen portieren können. Zweifellos geschieht dies auch, doch glaube ich, dass eine derartige Aussage eine Reihe wichtiger Punkte unter den Tisch fallen lässt:

  • Man muss für jede Zielplattform ein eigenes Projekt anlegen und verwalten. Es ist nicht damit getan, eine Zielplattform aus einer Drop-down-Liste auszuwählen und auf AUSFÜHREN zu klicken.
  • Jede Änderung, die Sie an der SPA vornehmen, müssen Sie manuell in jedem Projekt replizieren. Außerdem sind höchstwahrscheinlich Anpassungen am HTML und am Skript erforderlich, was mit den Browsing-Fähigkeiten bestimmter Gerätefamilien zusammenhängt (Safari Mobile kann sich geringfügig von Internet Explorer Mobile unterscheiden). Wenn Sie im HTML ein neues Feature eingefügt haben, können Sie nicht einfach Dateien ersetzen, ohne andere Änderungen zu verlieren. Die Synchronisierung ist in der Praxis keine einfache Sache.

Um dieses Problem zu entschärfen, bietet PhoneGap neuerdings an, PhoneGap Build (derzeit in der Betaversion) einzubinden; ein Compile-Service in der Cloud. Dazu müssen Sie lediglich den Quellcode Ihrer SPA hochladen und eine Zielplattform auswählen: Die Cloud erzeugt dann automatisch Ihre Binärdateien, die Sie unmittelbar auf einem Entwicklungsgerät installieren können.

Bereit für den großen Auftritt?

Insgesamt dürfte meiner Ansicht nach die Antwort auf diese Frage lauten: „Ja es ist bereit, aber unter Umständen nicht ausgerechnet für Sie.“ PhoneGap als eigenständiges Framework für die Entwicklung mobiler Anwendungen via SPAs funktioniert und wird ständig verbessert. Denken Sie auch daran, dass sich die Teams normalerweise auf eine oder zwei parallele Versionen konzentrieren, sodass der Zusatzaufwand, Projekte für zwei Exemplare derselben Codebasis zu verwalten und synchronisiert zu halten, in Flickschusterei ausartet.

Das wirkliche Problem, das Ihnen bei PhoneGap begegnet, hat mit PhoneGap an sich gar nichts zu tun. Eine PhoneGap-Anwendung, die Sie einmal auf einem Gerät bereitgestellt haben, läuft über die WebView-Komponente, die das Framework mitbringt. Die SDK-spezifische WebView-Komponente basiert auf dem standardmäßigen Layout-Modul des Browsers. Wenn dieses Modul fehlerhaft ist oder einfach nicht wie vorgesehen arbeitet, stecken Sie in einer Sackgasse. Darüber hinaus setzt PhoneGap voraus, dass Sie eine HTML-Anwendung erstellen, und HTML-Anwendungen zeigen in der Regel eine andere User Experience als native, mobile Anwendungen. Ist das für Sie akzeptabel? Falls nicht, können Sie versuchen, Ihre SPA mithilfe von Ad-hoc-HTML-Frameworks wie zum Beispiel jQuery Mobile oder Sencha mit Touch-Erweiterungen aufzubauen. Diese Bibliotheken beherrschen typische Elemente mobiler Benutzeroberflächen (u. a. Gestures), doch ist die Performance üblicherweise auf den meisten Geräten schlecht, da die Komplexität des UI doch zu groß ist, um durch Ad-hoc-Tutorials mal eben vermittelt zu werden.

Wie üblich lautet die ideale Antwort „Es hängt davon ab“– Sofern es für Sie nicht infrage kommt, sich nur an Benutzer mit High-End-Smartphones zu richten.

Hat Dir dieser Artikel gefallen?

Diese Kolumne und viele weitere interessante Beiträge findest du in unserem Magazin Windows Developer. Hier kannst du die Windows Developer Ausgabe 12.2012 mit Dino Espositos Kolumne bestellen.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -