Des Rätsels Lösung. In die Tiefe. Marcus Ross Cross-Plattform-Apps mit PhoneGap entwickeln

Transkript

1 Werkzeuge :53 Marcus Ross Cross-Plattform-Apps mit PhoneGap entwickeln Des Rätsels Lösung Bei der Entwicklung von mobilen Anwendung können Anspruch und Wirklichkeit weit auseinanderliegen. Welcher IT-Leiter oder Entwickler möchte schon für eine einzelne App mehrere Entwicklungsprojekte für diverse mobile Plattformen auf die Beine stellen? Und welcher Geschäftsführer möchte das bezahlen? Für dieses Problem bietet PhoneGap eine Lösung. Vereinfacht lässt sich die Arbeitsweise von PhoneGap so erklären: Eine App, die mit dem Framework erstellt wurde, ruft den Webbrowser der Smartphone-Zielplattform auf und lässt eine Webanwendung lokal darin ablaufen. Dabei unterdrückt PhoneGap alles, was an den Browser erinnert, also dessen Rahmen und alle Bedienelemente wie Internetadresszeile oder Menüs. Auf den ersten Blick hat man es also nur mit einem Browser im Vollbildmodus zu tun, darin verpackt die mobile Applikation bestehend aus HTML, JavaScript und CSS. Damit aber auch der Zugriff auf die Hardware wie Kamera, Adressbuch oder anderes wie bei einer normalen Anwendung funktioniert, lädt die App in den anzuzeigenden HTML-Seiten eine JavaScript-Bibliothek. Die laufende Browserkomponente fängt dabei die PhoneGap- Aufrufe der eigenen JS-Bibliothek ab und überführt sie in native Aufrufe der jeweiligen Plattform. Das Ergebnis erhält die Anwendung per JavaScript Callback zurück. In die Tiefe Bei genauerer Betrachtung lässt sich feststellen, dass PhoneGap aus zwei wesentlichen Bausteinen besteht. Der erste ist die Bibliothek cordova.js (die JavaScript Seite), mit der die in JavaScript, HTML5 und CSS geschriebene Webapplikation arbeitet. Nachdem sie in die Anwendung eingebunden ist, stellt sie eine API für plattformunabhängige Zugriffe auf Komponenten des Smartphones zur Verfügung. Die JavaScript- Bibliothek interagiert auch mit dem zweiten Baustein von PhoneGap/Apache Cordova[1], der sogenannten Native Engine. Sie existiert in verschiedenen Implementierungen, jeweils einer pro Zielplattform, und ermöglicht die Abfragen von Sensoren des jeweiligen Betriebssystems. Wenn die enthaltenen Möglichkeiten zum Zugriff auf die Hardware per Native Engine nicht ausreichen, gibt es die Option, sie durch Plug-ins zu

2 erweitern. Dabei gilt für jede Ergänzung: Es wird sowohl eine JavaScript-Datei als auch eine plattformabhängige Klasse benötigt. Erstere stellt den Aufruf der Funktion in PhoneGap dar. Damit ihn das jeweilige Smartphone-System umsetzen kann, wird noch eine Implementierung des Plug-ins in der Native Engine benötigt. Durch die oben beschriebene Architektur ist es PhoneGap möglich, prinzipiell jedes System zu unterstützen, dass eine Webbrowser- Komponente besitzt. Aktuell lässt sich PhoneGap in der Version 3.0 offiziell mit ios, Android Blackberry (10), Windows Phone 7 und 8, Windows 8 und Tizen verwenden. Auf den Downloadseiten der Apache Foundation stehen noch einige weitere zur Verfügung wie WebOs oder Bada. Es gibt darüber hinaus ersten Code für den Support von Firefox OS und Ubuntu mobile, die dieses Jahr noch komplett unterstützt werden sollen. PhoneGap installieren War noch vor kurzer Zeit für jede Plattform einiges an Aufwand zu leisten, beschränkt sich nun die Installation von PhoneGap auf die Zeile $ sudo npm install -g phonegap Da PhoneGap seit Version 3.0 offiziell Node Packaged Modules nutzt, ist nur ein node.js-server nötig. Zur Entwicklung muss darüber hinaus das jeweilige Hersteller-SDK für die Plattform installiert sein. Als Beispiel sollen an dieser Stelle Apples ios und Googles Android SDK dienen. Bei Apple reicht das Beziehen von XCode aus dem AppStore. Dabei sollte man nicht vergessen, den ios-simulator und das Xcode-Kommandozeilen-Tool nachträglich über das Preferences- Menü zu installieren. Für Android sind die Build-Tools und ein Android-SDK notwendig, wobei sich am besten auf das von Google angebotene Installer-Paket[2] zurückgreifen lässt. Sind diese Voraussetzungen erfüllt, ist alles für einen Test bereit. Mit $ phonegap create meine-erste-app lässt sich eine erste Anwendung erstellen und es wird ein Verzeichnis samt notwendiger Struktur angelegt. Nach dem Wechsel in das Verzeichnis,

3 $ cd create meine-erste-app besteht die Möglichkeit, die jeweiligen Plattformen mit $ phonegap run <plattform> aufzurufen. Hier kann zum Beispiel android oder ios stehen. Das Kommandozeilenprogramm sucht dann automatisch nach dem jeweiligen SDK-Pfad und kompiliert die App. Durch den run-parameter wird außerdem die Bereitstellung auf ein angeschlossenes Smartphone oder der Start des Emulators durchgeführt. Da der Aufruf von phonegap create bereits eine Struktur nebst Demo-Code erstellt hat, lässt sich die Anwendung nun via $ phonegap run ios für ios oder $ phonegap run android für Android testen. Nach einer kurzen Wartezeit sollte im Emulator das Ergebnis erscheinen. (Abb. 1)

4 Emulatorreaktion auf den run-befehl in der Version für ios und Android. (Abb.1) Grüße an den Rest des Planeten Nach dem Überprüfen der Installation lässt sich mit dem Entwickeln beginnen. Der Zugriff auf die Hardware findet wie schon beschrieben über JavaScript statt. Daher eignet sich die einfache Device-API am besten als Einstiegspunkt. Über sie meldet PhoneGap, auf welchem Gerät es gerade läuft, nebst Details wie der Version des Betriebssystems oder der von PhoneGap. Mit der Kommandozeile des Frameworks lässt sich zunächst ein Projekt erstellen, diesmal mit etwas detaillierterem Aufruf: $ phonegap create deviceinfoapp --name "DeviceInfoApp" --id "de.heisedeveloper.deviceinfoapp" Erfahrene App-Entwickler haben sich sicherlich schon gefragt, wie die App-ID gesetzt werden kann. Sie wird dazu genutzt, eine App über eine einzigartige Kennung zu identifizieren. Hier eine kurze Konvention für die Namensvergabe: In der Regel wird die App-ID mit der Reverse- Domain-Name-Notation beschrieben. Im vorliegenden Fall also de.heisedeveloper.deviceinfoapp. Damit kann es mehrere Anbieter des selben App-Namens DeviceInfoApp geben, aber die App-ID ist dabei immer verschieden. Auch der Name der Anwendung, der später unter dem App- Icon zu lesen ist, lässt sich als Parameter mitgeben. Beides ist im gerade gezeigten Aufruf zu sehen.

5 Es sollte nun ein Verzeichnis mit dem Namen deviceinfoapp existieren. Im für Entwickler wichtigsten Ordner www, hinterlegt PhoneGap alle für die App notwendigen Dateien. Momentan sollten sich in ihm bereits einige Demodaten befinden: Ein js-verzeichnis für JavaScript-Code, eine Datei index.html sowie ein CSS-Ordner. Forscht man etwas weiter, findet sich noch ein icon.png, das das App-Icon repräsentiert, und einen Image-Ordner. Für Tests steht darüber hinaus das Verzeichins spec mit der Datei spec.html bereit. Hier lässt sich Code mit einem mitgelieferten Framework wie Jasmine testen. Um nun die Device API nutzen zu können, ist zunächst der in der index.html vorhandene Code mit dem folgenden zu ersetzen (zur vereinfachten Darstellung wurde Inline-JavaScript genutzt): <!DOCTYPE html> <html> <head> <title>gerätedaten-beispiel</title> <script type="text/javascript" charset="utf-8" src="phonegap.js"></script> <script type="text/javascript" charset="utf-8"> // Warten auf Cordova document.addeventlistener("deviceready", ondeviceready, false); // Cordova ist geladen. function ondeviceready() { var element = document.getelementbyid('deviceproperties'); element.innerhtml = 'Device Name: ' + device.name + '<br />' + 'Device Cordova: ' + device.cordova + '<br />' + 'Device Platform: ' + device.platform + '<br />' + 'Device UUID: ' + device.uuid + '<br />' + 'Device Version: ' + device.version + '<br />'; } </script> </head> <body> <p id="deviceproperties">laden der Gerätedaten...</p> </body>

6 </html> Durch diesen Code wird zunächst PhoneGaps JavaScript-Bibliothek geladen. Bei der Arbeit mit Versionen vor PhoneGap 3.0 wäre statt der phonegap.js folgender Aufruf von Nöten: <script type="text/javascript" charset="utf-8" src="cordova js"> </script> Gleich nach dem Laden wird ein DOM-konformer Event Listener registriert. document.addeventlistener("deviceready", ondeviceready, false); Es folgt die Reaktion auf das Ereignis deviceready und der Aufruf der Funktion ondevice-ready. Mit letzterem lässt sich sicherstellen, dass PhoneGap komplett geladen ist, weshalb es sich empfiehlt, ihn in alle Anwendungen einzufügen. Das Ereignis (Event) erzeugt PhoneGap selbst. Wie schon erwähnt enthält PhoneGap sowohl eine native Codebasis als auch eine JavaScript-Bibliothek. Während der native Codeteil initialisiert wird, kann es sein, dass der JavaScript-Teil bereits komplett geladen und ausgeführt ist. Dabei könnte es passieren, dass der Nutzer per JavaScript auf Funktionen zugreift, deren nativer Codeteil noch nicht bereit ist, um die Aufrufe umzuwandeln und sie an die Plattform zu senden. Um diesem Timing-Problem zuvorzukommen, wird das Event deviceready von PhoneGap tatsächlich erst dann an den Browser geschickt, wenn auch der native Teil vollständig bereit steht. Das Warten auf das Event dient also als Vorsichtsmaßnahme. var element = document.getelementbyid('deviceproperties'); Das Element mit der ID deviceproperties im HTML-Dokument sorgt für die Anzeige der ermittelten Gerätedaten. Der Zugriff auf diese erfolgt eine Zeile danach. Nach der Umstellung auf PhoneGap 3 müssen erst alle verwendeten APIs registriert werden. (Abb.2) 'Device Platform: ' + device.platform

7 Der hier gezeigte Aufruf von device.platform stammt aus der PhoneGap-API. Sie erstellt ein device-objekt im globalen Namensraum. Je nach Plattform gibt die API die Werte Android, BlackBerry, ios oder Tizen zurück. Die Eigenschaften des device-objektes umfassen device.name (Name des Gerätes, zum Beispiel "Danielas iphone"), device.cordova (aktuell genutzte Version von PhoneGap, zum Beispiel 3.0.), device.platform (Plattform, auf der die App gerade läuft, zum Beispiel iphone), device.uuid (der Universally Unique Identifier des Gerätes - bei ios ist es eine 16 Byte lange Zahl, bei Android ein 64-Bit-Integer, bei Windows Phone ein Hash-Wert aus Geräte-ID und Benutzer-ID, bei BlackBerry die neunstellige Gerätenummer) und device.version (aktuelle Betriebssystemversion des Gerätes, zum Beispiel 5.1.). Das oben aufgeführte Codebeispiel ist nun nur noch per phonegap run ios beziehungsweise phonegap run android zu starten. In den älteren Versionen von PhoneGap ließe sich schon jetzt ein Erfolg verzeichnen. Die aktuelle Version quittiert den Aufruf allerdings nur mit "Lade Gerätedaten"(Abb. 2), denn durch eine Umstellung bei PhoneGap mit der Version 3.0 muss jede verwendete API erst registriert werden. Das gilt auch für die sogenannte Core-API. Mit dieser Änderung hält das Framework die Basis-Anwendung schlank, da unnützer Code nicht länger geladen werden muss. Damit das Beispiel wie erhofft läuft, ist also via phonegap local plugin add das entsprechende Core-Plug-in hinzuzufügen. Wie man dem Aufruf entnehmen kann, bezieht die Anwendung die Codebasis der Device-API aus einem Git-Repository. Damit ist sichergestellt, dass immer die aktuellste Version eingebunden ist beziehungsweise eine zuvor ausgewählte. Eine der wichtigsten Änderungen mit Version 3.0 ist, dass die App nach dem Laden des Plug-ins erneut zu bauen ist. Danach sollte ein Ergebnis wie in Abb. 3 zu sehen sein. Damit ist die erste kleine App auch schon erzeugt. Doch was ist mit dem App-Namen? Und wie lassen sich App-Icons definieren? Antwort auf alle diese Fragen finden sich in der Datei config.xml, die ebenfalls im www-verzeichnis zu finden ist.

8 App mit geladenen Plug-ins für ios und Android (Abb.3) Mehr Details? - config.xml! Neben der Möglichkeit, den Name der App oder die ID zu ändern, bietet diese Datei noch mehr Einstellungsmöglichkeiten. So zum Beispiel eine Anordnung für App-Icons oder Splashscreens, die je nach Format angegeben werden. Das AppIcon für ein Android-Gerät mit hoher Displayauflösung lässt sich beispielsweise mit <icon gap:density="hdpi" gap:platform="android" src="res/icon/android/icon-72-hdpi.png" /> festlegen, während der Entwickler den Splashscreen für ein ipad mit Retina-Display mit dem Befehl <gap:splash gap:platform="ios" height="960" src="res/screen/ios/screen-iphone-portrait-2x.png" width="640" /> definieren kann. Dabei sieht man auch gleich, wofür der Ordner res genutzt wird. Die config.xml[3] legt aber nicht nur Metadaten wie den Autor oder die Beschreibung fest, im preference-bereich wird auch über

9 plattformabhängige Konfiguration entschieden. Zum Beispiel lässt sich die minimale Android-Version per <preference name="android-minsdkversion" value="7"/> oder die Erscheinungsart des ios-statusbalken mittels <preference name="ios-statusbarstyle" value="black-opaque" /> festlegen. Für die eine vollständige Liste aller Konfigurationsmöglichkeiten sei die Online-Dokumentation[4] empfohlen. Wichtig ist außerdem, dass Datenverbindungen mit einem JavaScript-XmlHttpRequest oder dem PhoneGap eigenen Filetransfer unbedingt durch ein Whitelisting in der config.xml erlaubt werden müssen. Wäre in der App zum Beispiel ein Dateidownload vom Server dev.heise.de vorgesehen, würde dieser sonst so lange verweigert, bis man die Konfigurationsdatei um den Eintrag <access origin=" /> ergänzte. Damit lässt sich die hinterlegte Domain für den Zugriff durch die App freischalten. Der Stern am Schluss bewirkt, dass jeder Pfad im Verzeichnis freigegeben ist. Bitte recht freundlich Die Kamera ist nach wie vor eins der Top-Features eines jeden Smartphones. Sie in Anwendungen einzubauen, liegt also nah. Obwohl es nur einen Methodenaufruf für die Kamera gibt, navigator.camera.getpicture(successcb, failcb, {option}); sind die Möglichkeiten mit diesem vielfältig. Beim Aufruf werden drei Parameter übergeben, im Erfolgsfall erfolgt ein success-callback. Bei einem Fehler oder Abbruch kommt ein fail-callback zum Einsatz. <!DOCTYPE html> <html> <head> <title>capture Photo</title> <script type="text/javascript" charset="utf-8"

10 src="phonegap.js"></script> <script type="text/javascript" charset="utf-8"> // Warten, bis Cordova geladen ist // document.addeventlistener("deviceready", ondeviceready, false); // Cordova ist bereit // function ondeviceready() { capturephoto(); } function capturephoto() { navigator.camera.getpicture(onsuccess, onfail, { quality: 50, destinationtype: Camera.DestinationType.FILE_URI }); } function onsuccess(imageuri) { var image = document.getelementbyid('myimage'); image.src = imageuri; } function onfail(message) { alert('fehler: ' + message); } </script> </head> <body> <button onclick="capturephoto();">foto erstellen</button> <br> <img id="myimage" src="" />

11 </body> </html> Im oben gezeigten Codebeispiel wird nach dem obligatorischen ondeviceready-event die eigentlichen Bilderfassung mit der Funktion capturephoto() aufgerufen. Hier findet sich auch die Funktion navigator.camera.getpicture(). Im option-objekt ist eine Komprimierung des Bilder um 50 Prozent eingestellt und als Rückgabewert soll der Pfad des erstellten Bildes dienen. Im Falle der erfolgreichen Bildaufnahme löst das Programm die onsuccess-funktion als Callback aus und bekommt den Pfad der Bilddatei übergeben. Das vorliegende Beispiel übernimmt diesen dann einfach für die Anzeige des Bildes als src-attribut in das img-tag. Im Fehlerfall wird eine einfache Nachricht mit entsprechender Meldung ausgegeben. Führt man beispielsweise den Code im Emulator ohne Kamera aus, meldet das Programm "keine Kamera vorhanden". Spezielle Funktionen wie das Einstellen der Bildqualität oder Nachbearbeitung lassen sich in einem options-objekt festlegen und so konfigurieren. Damit bildet das Objekt den dritten Parameter, der unter anderem folgende Werte annehmen kann: quality: Hier wird ein Wert zwischen 1 und 100 erwartet. Er gibt an, wie stark das Bild komprimiert werden soll. destinationtype: Mit dieser Option lässt sich festlegen, ob der Pfad des Bildes oder eine Repräsentation als base64-codierten String für den Rückgabewert dienen soll. Eine Rückgabe als Binärstrom ist nicht vorgesehen. Dafür wäre der Bildpfad weiterzuverarbeiten und per Dateioperationen darauf zuzugreifen. Camera.DestinationType = { // base64 encoded String DATA_URL : 0, // Bildpfad als URI FILE_URI : 1 }; allowedit: Diese Option ermöglicht den Bearbeitungsdialog nach der Aufnahme. Hier lässt sich das Bild beschneiden und seine Größe verändern eben alles, was der Hersteller des Smartphones anbietet. Soll die Nachbearbeitung zugelassen werden, ist die Variable auf "true" zu setzen. PictureSourceType: Der Wert besagt, welche Quelle für das Bild zu nutzen ist. Hierbei ist nicht nur die Kamera gemeint. Es lässt sich auch auf eine Fotogalerie oder Albenauswahl zugreifen. Der getpicture-aufruf steht so als Möglichkeit zur Bildauswahl zur Verfügung. Camera.PictureSourceType = { PHOTOLIBRARY : 0, CAMERA : 1,

12 }; SAVEDPHOTOALBUM : 2 Damit die API-Aufrufe auch funktionieren, ist das Camera-Core-Plug-in erforderlich. Es wird mit phonegap local plugin add eingebunden und schon lässt sich mit dem obigen Codebeispiel experimentieren. Neben den bis jetzt vorgestellten APIs gibt es noch eine ganze Menge zusätzlicher[5]. Davon sind einige, wie die Geolocation-API, mit zu HTML5 kompatiblen Aufrufen ausgestattet, die für alle Plattformen harmonisiert sind. Das heißt, sollte ein Smartphone solche Anfragen nicht verarbeiten, da es vielleicht nur Drafts auf dem verwendeten System sind, wird PhoneGap sie trotzdem in dieser Syntax ausführen. Damit bildet es an vielen Stellen eine Brücke für einen einheitlichen HTML5-Standard. Das die Zeit nicht stehen bleibt, sieht man sehr schön an Themen wie der Batterie-API. Noch von einiger Zeit war dessen Abfrage PhoneGap vorbehalten, nun schickt sich die W3C an, die Funktion in HTML5 als Candidate Recommendation direkt in die Browser zu integrieren. Das große Ziel von PhoneGap ist es folglich, in der Zukunft nicht mehr benötigt zu werden alles sollte durch den HTML-Standard zugänglich sein. Ob es allerdings jemals so weit kommt, ist fraglich. Einmal durch den Lifecycle Der Lebenszyklus einer Smartphone-App umfasst alle Phasen, in denen sich eine Applikation zu einem bestimmten Zeitpunkt befindet. Er beginnt beim Start der App und endet bei ihrem Schließen und ermöglicht dem Entwickler, bei bestimmten Ereignissen zu reagieren, zum Beispiel beim Pausieren oder erneuten Starten einer App aus dem Hintergrund. Hier kann es sinnvoll sein, den Status der Anwendung oder die Menüposition zu speichern. PhoneGap signalisiert diese Events dabei per HTML-Eventlistener. Es entfallen daher Objekte und Methoden. Für Webentwickler ergibt sich demnach keine Umstellung, nur die Event-Namen sind andere. Im folgenden werden die einzelnen Events mit einem kleinen Beispiel vorgestellt. Das onready-event beim Starten der App ist aus den bisherigen Codeauszügen bekannt, es fehlen also noch pause und resume. Das pause-ereignis tritt immer ein, wenn das System die App in den Hintergrund bringt, beispielsweise als Reaktion auf das Drücken des Home-Buttons des iphones. Aber auch das Wechseln zwischen Anwendungen unter Android bewirkt ein Anhalten der Applikation. Sind in diesem Moment wichtige Daten zu speichern oder der Applikationsstatus zu sichern, lässt sich das Event hierfür nutzen. Die Registrierung ist dabei die gleiche wie bei herkömmlichen HTML-Events und lässt sich per

13 document.addeventlistener("pause", IhreCallbackFunktion, false) durchführen. Sollte das Ereignis eintreffen, wird die Funktion IhreCallbackFunktion ausgeführt. Der dritte Teil im Lebenszyklus einer Applikation ist das resume-event. Es wird gemeldet, wenn eine Applikation aus dem Hintergrund tritt. Wichtig dabei ist, dass sich die Anwendung nur im Hintergrund befand und nicht neu gestartet wurde. Folgendes Beispiel enthält alle drei Events: <!DOCTYPE html> <html> <head> <title>cordova-resume-beispiel</title> <script type="text/javascript" charset="utf-8" src="phonegap.js"></script> <script type="text/javascript" charset="utf-8"> // Warten, bis Cordova vollständig geladen ist // document.addeventlistener("deviceready", ondeviceready, false); // Cordova ist geladen. // function ondeviceready() { document.addeventlistener("resume", onresume, false); document.addeventlistener("pause", onpause, false); } // Resume-Event verarbeiten // function onresume() { } // Pause-Event behandeln // function onpause() {

14 } </script> </head> <body></body> </html> Und nach dem Entwickeln? Nach der Entwicklung stellt sich meist die Frage, wie sich die Anwendung in die App-Marktplätze der Anbieter befördern lässt. Nach einem erfolgreichen $ phonegap build <Plattform> sind zunächst entweder ein APK oder XCode-Projekt zum Signieren und Senden nötig. Diese Dateien befinden sich im Ordner plattforms des PhoneGap-Projektes. Dort gibt es Unterverzeichnisse für android, ios und gegebenenfalls weitere Zielsysteme, in denen die erstellten nativen Projekte liegen. Bei ios bedeutet das ein XCode-Projekt, das sich normal weiter nutzen lässt. Im Android-Ordner finden sich hingegen im bin- Verzeichnis APK-Dateien. Mit ihnen stehen die normalen Distributionswege der jeweiligen Plattformen frei. Und was ist mit der Feature XYZ? Oft wird die Frage aufgeworfen, ob PhoneGap auch eine Datenbanken erstellt oder die neuen UI-Komponenten von ios beherrscht. Die Antwort ist in allen Fällen, selbst wenn es um Dinge wie Facebook-Integration, geht: So lange es eine normale Webanwendung kann, kann es auch eine mit PhoneGap erstellte App. Da sie einen Browser aufruft, ist sie in der Lage, alle möglichen JavaScript- Bibliotheken zu nutzen. Egal ob es um das Erstellen von Diagrammen mit Highcharts.js oder touch-optimierte Oberfläche mit jquerymobile geht. Die Frage nach der Datenbank (websql) ist auch einfach geklärt: Wenn die Plattform es unterstützt, lassen sich wie gewohnt sqlite-datenbanken erstellen. Sicherlich ist die Performance einer App mit PhoneGap nicht die einer nativen Anwendung. Allerdings haben auftretende Performanceprobleme häufig mehr mit dem Programmierstil und den verwendeten Zusatz-Bibliotheken zu tun als mit dem Framework. Ein einfaches Beispiel ist hier das Laden von Zeilen im Framework jquery-mobile. Hier wird das zähe Scrollen gerne auf PhoneGap geschoben, allerdings braucht das Rendern von Einträge immer seine Zeit und eine Implementierung von LazyLoading wäre sicherlich besser gewesen. Also lässt sich nicht jedes Performance-Problem auf PhoneGap schieben.

15 PhoneGap hilft an vielen Stellen, aber nicht überall. Der Entwickler muss sich beispielsweise selbst entscheiden, ob die Oberfläche für jede Plattform neu zu erstellen ist oder die Wahl lieber auf ein generell gültiges, mobiles UI fallen soll. Für solche Vorhaben stehen diverse HTML/CSS-Bibliotheken wie jquerymobile, Sencha-Touch, Topcoat, Twitter Bootstrap und Ratchet zur Verfügung. Auch das Erstellen von Charts oder Entwickeln von performantem JavaScript-Code ist nicht die Aufgabe des Frameworks. Fazit PhoneGap kann helfen, datengetriebene Apps für mehrere mobile Plattformen zu erstellen. Der Ansatz, HTML und JavaScript zum App-Bau zu nutzen, bietet Einsteigern schnelle Ergebnisse und Profis eine solide Basis für größere Projekte. Der Schritt auf Version 3.0 hat PhoneGap nicht geschadet. Es gibt zwar ein paar Brüche in API und Nutzung, allerdings werden diese durch die Verbesserungen der Plug-in-Schnittstelle und das einfache Installieren mittels Node-Modul aufgewogen. Auch die eigentliche Speichergröße der Anwendung nimmt durch die Umstellung ab. Lässt man die Benutzeroberfläche und ein Backend für die Daten nicht unbeachtet, kann sich PhoneGap als Grundlage für die Entwicklung von Cross-Plattform-Anwendungen als nützlich erweisen. Marcus Ross ist Dipl.-Informatik-Betriebswirt und arbeitet als freier IT-Berater und Trainer mit den Schwerpunkten Datenbanken und Webportale. Seit 2010 widmet er sich dem Thema der mobilen Cross-Plattform-Entwicklung und ist zudem PhoneGap-Comitter. PhoneGap oder Apache Cordova In der Berichterstattung taucht der Name PhoneGap oft synonym zu Apache Cordova auf. Eigentlich sollte die Frage nach der richtigen Bezeichnung einfach zu klären sein. Denn: Apache Cordova ist schlicht der neue Name vom PhoneGap-Code. In Zukunft ist also damit zu rechnen, dass dieser Name weitere Verbreitung findet, auch wenn der Entwicklergemeinde "PhoneGap" noch lange erhalten bleiben wird. Die Geschichte hinter der Namensentwicklung war ungefähr wie folgt: Das Unternehmen Nitobi wurde 1998 in Vancouver, Kanada, gegründet. An ihrem Anfang standen rund 15 Personen, die sehr früh die Mächtigkeit von JavaScript erkannten und schon vor dem iphone an Ideen arbeiteten, um das mobile Web voranzubringen. Ihr Ziel war es, die Einfachheit der Webapplikationsentwicklung mit mobilen Geräten zu verbinden. Das Projekt, das sie dazu initiierten, nannten sie PhoneGap. Am Anfang tat PhoneGap nicht mehr, als Webseiten, die in einem lokalen Ordner lagen, auf mobilen Geräten anzuzeigen. Damit konnten Webentwickler plötzlich einfache Apps (Eventkalender, Produktinfos, Anleitungen) erstellen. Am 3. Oktober 2011 sorgte ein Blogpost von Nitobi für Aufregung in der Open-Source-Community, in dem es bekannt gab, von Adobe übernommen worden zu sein. Ziel der Übernahme war es vermutlich, die Erzeugnisse des Unternehmens als Ersatz für Flash in Adobe-Produkten zu verwenden. Schnell kam die Befürchtung auf, dass PhoneGaps Open-Source-Status nicht länger sicher sei. Durch die Übergabe an die Apache Software Foundation machte Adobe diese Ängste allerdings schnell zu nichte. Seit Version 1.4 läuft das Projekt nun also dort unter dem Namen Apache Cordova.

16 Adobe arbeitet jedoch mit eigenen Entwicklern weiterhin am Projekt mit und stellt neuen Code bereit. Für seinen in der Cloud arbeitenden Build-Service PhoneGap Build und die Website[6] für Dokumentation und Beispiele verwendet das Unternehmen jedoch immer noch den alten Namen. Auch das im Verlauf des Artikels verwendete phonegap-kommandozeilen-tool ist nur ein Aufsatz für das eigentliche cordova-cli von Apache. PhoneGap ist also eine Art Distribution, vergleichbar mit den verschiedenen Linux-Versionen auf dem Markt. Adobe sponsert das Projekt und so hat es bereits Einzug in Produkte wie Adobes Dreamweaver gehalten. Doch das große Engagement hat zur Folge, dass der Name PhoneGap weiterhin dominant ist, weshalb er im Folgenden hauptsächlich Verwendung findet. Liste der Core-Plug-ins Da die Online-Dokumentation[7] hier noch etwas hinter dem aktuellen Stand des Projektes her ist, hier nun eine Auflistung der Core-Plug-ins inklusive ihrere Repositories. Device Information: $ cordova plugin add Netzwerk: $ cordova plugin add Batterie Status: $ cordova plugin add Accelerometer, compass, and geolocation: $ cordova plugin add $ cordova plugin add $ cordova plugin add Camera, media capture, and media playback: $ cordova plugin add $ cordova plugin add $ cordova plugin add Access files on device or network: $ cordova plugin add

17 $ cordova plugin add Notifications via dialog box or vibration: $ cordova plugin add $ cordova plugin add Contacts: $ cordova plugin add Globalization: $ cordova plugin add Splash Screen: $ cordova plugin add In-app browser: $ cordova plugin add Debug console: $ cordova plugin add Zusätzlich sind auch Erweiterungen wie ein Barcode-Scanner zu bekommen. Diese finden Sie auf GitHub[8]. Allerdings sei hier gewarnt: Die neue Plug-in-Struktur bedingt, dass die existierenden Erweiterungen erst noch zu portieren sind. In einigen Monaten dürfte hier mehr zu sehen sein, erste Ports von bestehenden Plug-ins sind jedoch schon jetzt verfügbar. URL dieses Artikels: Links in diesem Artikel: [1] [2] [3] [4] [5] [6] [7]

18 [8] Copyright 2013 Heise Zeitschriften Verlag Content Management by InterRed International: The H, The H Security, The H Open Source