1 Einleitung
1.1 Wieso Cross-Plattform-Entwicklung?
1.2 Für wen dieses Buch geschrieben ist
1.3 Wie Sie dieses Buch lesen sollten
1.4 Beispiele für PhoneGap-Projekte
1.5 Danksagung
2 Erste Schritte mit PhoneGap
2.1 Die Geschichte von PhoneGap
2.2 Lizenzrechtliches
2.3 Wie funktioniert PhoneGap?
2.3.1 High-Level-Architektur
2.4 Was kann PhoneGap?
2.5 Was kann PhoneGap nicht?
2.6 Was funktioniert auf welcher Plattform?
2.7 PhoneGap 2 vs. PhoneGap 3
2.8 PhoneGap für Android installieren
2.9 Projektskelett
2.9.1 index.html
2.9.2 index.js
2.9.3 cordova-2.3.0.js
2.9.4 main.js
2.10 Anwendung testen
2.10.1 Test im Emulator
2.10.2 Test am realen Endgerät
2.11 Anwendung ausliefern
2.12 Zusammenfassung
3 PhoneGap und die Entwicklungsumgebungen der unterstützten Plattformen
3.1 Android
3.2 bada
3.2.1 Voraussetzungen
3.2.2 Installation der Entwicklungsumgebung
3.2.3 Applikation testen
3.2.4 Anwendung ausliefern
3.2.5 deviceReady unter bada
3.3 BlackBerry
3.3.1 Voraussetzungen
3.3.2 Installation der Entwicklungsumgebung
3.3.3 Applikation testen
3.3.4 Applikation ausliefern
3.4 iOS
3.4.1 Voraussetzungen
3.4.2 Installation der Entwicklungsumgebung
3.4.3 Projekt erstellen
3.5 Qt
3.5.1 Voraussetzungen
3.5.2 Applikation testen
3.5.3 Applikation ausliefern
3.6 Windows (Phone)
3.6.1 Voraussetzungen
3.6.2 Entwickeln für Windows Phone 7
3.6.3 Projektskelett erstellen
3.6.4 Anwendung testen
3.7 Fazit
4 Testen und Debuggen
4.1 weinre
4.1.1 weinre-Architektur
4.1.2 weinre à la PhoneGap
4.1.3 Benchmarks mit weinre
4.1.4 Die weinre-Konsole
4.1.5 Lokale weinre-Instanz
4.2 Ripple (emulate.phonegap.com)
4.2.1 Ripple-Einstellungen
4.2.2 Chrome Developer Tools
4.3 Webkit Introspection
4.4 Unit-Tests
4.5 Fazit
5 Oberflächen für Cross-Plattform-Apps
5.1 Wieso Templates oder Frameworks verwenden?
5.2 jQuery (Mobile)
5.2.1 jQuery-Mobile-Kompatibilität
5.2.2 jQuery Mobile beschaffen
5.2.3 jQuery Mobile und PhoneGap gemeinsam
5.2.4 $, Selektoren und mehr jQuery
5.2.5 Selektoren
5.2.6 Effekte
5.2.7 Events
5.2.8 AJAX
5.2.9 jQuery Mobile
5.2.10 Feintuning für jQuery Mobile
5.3 Entwurf von Handyapplikationen
5.3.1 Handys sind keine PCs
5.3.2 Von der intelligenten GUI
5.3.3 Mobilität beachten
5.3.4 User lesen nicht
5.3.5 Testen am User
5.3.6 Kampf der »Feature-itis«
5.4 Fazit
6 Die PhoneGap-API
6.1 Wie funktioniert das?
6.2 Welche Namespaces gibt es?
6.2.1 Accelerometer
6.2.2 Camera
6.2.3 Capture
6.2.4 Compass
6.2.5 Connection
6.2.6 Contacts
6.2.7 Device
6.2.8 Events
6.2.9 File
6.2.10 Geolocation
6.2.11 Globalization
6.2.12 InAppBrowser
6.2.13 Media
6.2.14 Notification
6.2.15 SplashScreen
6.2.16 Storage
6.3 Plattformspezifische Überlegungen
6.4 Weitere Informationen
6.5 Fazit
7 Kommandozeilenwerkzeuge – CLIs
7.1 node.js installieren
7.2 PlugMan
7.3 Cordova CLI
7.3.1 Projekt erstellen
7.3.2 Projekt kompilieren und ausführen
7.3.3 Module einpflegen
7.3.4 Plattformspezifische Elemente
7.4 PhoneGap CLI
7.5 Fazit
8 Medien einsetzen – Audio und Video mit PhoneGap
8.1 Camera
8.1.1 Foto aufnehmen und anzeigen
8.1.2 Fortgeschrittene Optionen
8.1.3 Bilder editieren unter iOS
8.1.4 Aufräumen unter iOS
8.1.5 Benötigte Permissions
8.2 Capture
8.2.1 Benötigte Permissions
8.3 Media
8.3.1 Media-Objekt erstellen
8.3.2 Ereignisse bearbeiten
8.3.3 Objekt freigeben
8.3.4 Töne aufnehmen
8.3.5 Benötigte Permissions
8.4 Fazit
9 Datenspeicherung mit PhoneGap
9.1 Welche API wozu?
9.2 Datenbanken
9.2.1 Datenbank erstellen
9.2.2 Transaktionen zur Tabellenerstellung
9.2.3 Transaktionen mit Daten
9.2.4 Mehr SQL
9.2.5 Version aktualisieren
9.2.6 Erforderliche Permissions
9.3 Dateien und Ordner
9.3.1 Dateisystem enumerieren
9.3.2 Ordner erstellen
9.3.3 Dateien lesen und schreiben
9.3.4 Up- und Downloads
9.3.5 Exkurs: Arbeit mit Zustandsautomaten
9.3.6 Erforderliche Permissions
9.4 Local Storage
9.4.1 Indizierung und semipersistente Speicherung
9.4.2 Erforderliche Permissions
9.5 Fazit
10 Plug-ins – native Erweiterungen in PhoneGap
10.1 JavaScript als Einsprungpunkt
10.2 Plug-in-Spezifikation
10.3 Allgemeine Hinweise
10.4 Android
10.5 BlackBerry Classic
10.6 BlackBerry 10
10.7 iOS
10.8 Windows Phone
10.9 Fazit
11 Einsatz der Sensoren mit Canvas
11.1 Seiten, Seiten, Seiten
11.2 Push oder Pull?
11.3 Accelerometer
11.3.1 Permissions
11.4 Kompassinformationen
11.4.1 Permissions
11.5 Geräteinformationen und Verbindungen
11.5.1 Permissions
11.6 Geolocation
11.6.1 Permissions
11.7 Fazit
12 UI Helpers
12.1 Events
12.1.1 Eventregistrierung
12.1.2 deviceReady
12.1.3 pause
12.1.4 resume
12.1.5 resign/active
12.1.6 offline
12.1.7 online
12.1.8 backbutton
12.1.9 Weitere Buttons
12.1.10 Batterieereignisse
12.1.11 Notwendige Permissions
12.2 Notification
12.2.1 Einfache MessageBox mit alert
12.2.2 MessageBox mit mehreren Buttons
12.2.3 Eingabedialog
12.2.4 Pieptöne
12.2.5 Vibrationsalarm
12.2.6 Notwendige Permissions
12.3 Globalisierung von Zahlen & Co.
12.3.1 Informationen beschaffen
12.3.2 Erstellung von Strings
12.3.3 Parsen von Strings
12.3.4 Notwendige Permissions
12.4 In-App-Browser
12.4.1 Events des In-App-Browsers
12.4.2 CSS und JavaScript injizieren
12.5 Splashscreen
12.5.1 Splashscreen unter Android
12.5.2 Splashscreen unter iOS
12.5.3 Splashscreen an und aus
12.6 Fazit
13 PhoneGap Build
13.1 Was ist PhoneGap Build?
13.2 Lizenzrechtliches
13.3 Erste Schritte mit Build
13.3.1 config.xml
13.3.2 Archivstrukturelles
13.3.3 Ernten der Resultate
13.4 Signieren mit Build
13.5 Build Debug!
13.6 Selbstdeployende Apps
13.7 Native Plug-ins
13.7.1 Analytics
13.7.2 BarcodeScanner
13.7.3 ChildBrowser
13.7.4 FacebookConnect
13.7.5 GenericPush
13.7.6 Plug-in Marke Eigenbau?
13.8 Die Build-API
13.9 Fazit
A OOP mit JavaScript
A.1 Prototyp vs. Klasse
A.2 »Klassen in JS«
A.2.1 Prototyp denkt mit
A.2.2 Unsichtbare Funktionalität
A.2.3 Objekte klonen und »vererben«
A.3 Eventsysteme
A.4 MVC
A.5 Data Binding
A.6 Automatisierte Akzeptanztests
A.7 Weitere Informationen
A.8 Fazit
Stichwortverzeichnis
Die Entwicklung der Programmiersprache JavaScript ist zweifellos eine der größten Erfolgsgeschichten der modernen Informatikgeschichte. Ursprünglich als Werkzeug zum besseren Animieren von Webseiten vorgesehen, eroberte die Sprache im Laufe der Jahre immer mehr und mehr Anwendungsfelder, die einst klassischen Sprachen wie C++ und Java vorbehalten waren.
Spätestens seit dem Erscheinen des iPhones der ersten Generation wurde klar, dass HTML5 und JavaScript auch zur Entwicklung von Anwendungen für Mobilcomputer taugen – anfangs war das Erfolgsgerät von Apple sogar ausschließlich durch seinen Webbrowser programmierbar.
Leider zeigte die von Desktop-Browsern hinreichend bekannte Problematik der nicht standardisierten Schnittstellen auch am Handy ihre Zähne. Jeder Hersteller zimmerte seine eigene API zusammen, die mit den Angeboten der anderen Hersteller inkompatibel war. Aufgrund der großen Marktbreite entstanden schon bald diverse Frameworks, die die verschiedenen Plattformen zu »einen« suchten. PhoneGap ist das mit Abstand erfolgreichste Resultat dieser Entwicklung – seine genauere Betrachtung ist die Aufgabe der folgenden Seiten.
Für PhoneGap spricht neben der extremen Aktivität der dahinterstehenden Community auch, dass das Produkt Eigentum der sehr finanzstarken Adobe Systems Corporation ist. Aus diesem Grund fehlt es den Entwicklern nicht an Ressourcen – ein Vorteil, der sich insbesondere bei der enormen Anzahl der unterstützten Plattformen manifestiert.
In diesem Kapitel wollen wir uns einen kleinen Überblick über die momentane Situation verschaffen. Auch gehen wir ein wenig darauf ein, wie Sie das vorliegende Buch optimal zu Ihrem eigenen Vorteil nutzen.
Für das Verständnis der folgenden Kapitel sind die hier abgedruckten Ausführungen nicht von eminenter Bedeutung. Trotzdem ist es hilfreich, ein wenig »über den Tellerrand« hinauszusehen – gehen wir es an.
Kaum ein Bereich der IT ist so unübersichtlich wie die Mobilcomputerindustrie. Selbst für Analysten mit zehnjähriger Diensterfahrung gibt es immer wieder überraschende, verwirrende oder schlichtweg undurchschaubare Vorfälle.
Auch wenn sich die Betriebssystemlandschaft mittlerweile ein wenig bereinigt hat – anders als im Bereich der Workstations gibt es im Mobilcomputerbereich (noch) keinen klaren Marktführer, der alle anderen Plattformen verdrängt.
Das Messen der Marktanteile von Betriebssystemen für Smartphones ist eine Wissenschaft für sich. Die in Abbildung 1.1 gezeigte Entwicklung ist mit Sicherheit nicht auf das Zehntelprozent genau, gibt aber nach Meinung des Autors einen guten Überblick über die Marktbewegungen.
Bild 1.1: Die Marktanteile ändern sich rasend schnell (bearbeitet nach
http://en.wikipedia.org/wiki/File:World_Wide_Smartphone_Sales_Share.png).
Geübten Wirtschaftlern fällt sofort auf, dass sich die Positionen der einzelnen Marktteilnehmer ungewöhnlich schnell ändern. Es kommt außerhalb des Mobilcomputermarkts nur sehr selten vor, dass ein Marktführer binnen weniger Monate so gut wie komplett von der Bildfläche verschwindet und durch ein anderes System ersetzt wird. Übrigens ist der Absturz von Symbian nicht das erste derartige Ereignis in der Industrie – auch Palm OS starb einen relativ schnellen und sehr schmerzhaften Tod.
Im selben Zeitraum ist eine Vielzahl neuer Plattformen auf den Markt gekommen. Das liegt unter anderem daran, dass sich die Hersteller von Handcomputern durch das Forcieren eines hauseigenen Betriebssystems Vorteile im Konkurrenzkampf erhoffen.
Der wichtigste Effekt eines proprietären Systems ist die Investitionssicherheit beziehungsweise gesteigerte Kundenbindung. Wer sein ThinkPad satt hat, kauft sich ein Elitebook. Beide laufen unter Windows, die auf dem Lenovo-Computer installierten Anwendungsprogramme lassen sich (in der Regel) auch am neuen Rechner weiterverwenden.
Im Mobilbereich ist die Lage völlig anders. Wenn ein Hersteller erfolgreich ein proprietäres Betriebssystem samt eigenem Ökosystem auf den Markt bringt, entkommt ihm der unzufriedene User nicht mehr ohne Weiteres.
Der Grund dafür ist die Vielzahl von Applikationen, Spielen und sonstigen Inhalten. Die im Samsung App Seller Office oder im Nokia Ovi Store gekaufte Lizenz von TouchCalc lässt sich (selbst bei einem hoch kooperativen Entwickler) unmöglich unter Windows Phone 8 verwenden oder auf den iTunes App Store bringen – der Autor ist selbst im Bereich der Anwendungsentwicklung tätig und hatte das Problem schon mehrfach.
Daraus folgt eine enorme »Klebrigkeit«. Wer im Fall eines Herstellerwechsels seine gesamte Musik und alle Apps verliert, verzeiht zähneknirschend so manche Frechheit – in Cupertino gibt es ein Unternehmen, das unter anderem davon lebt.
Mindestens ebenso nützlich ist eine proprietäre Plattform beim Ausnutzen der neudeutsch als Convergence bezeichneten Effekte. Dabei handelt es sich um das Zusammenwachsen von verschiedenartigen Geräten – klassisch ist das Übertragen von am Telefon aufgenommenen Fotos in Richtung des Fernsehgeräts. Allerdings sind, zumindest im universitären Bereich, schon ganz andere Konzepte »unterwegs« – so ist zum Beispiel eine Waschmaschine denkbar, die das zeitkritische Trocknen von bügelfreien Hemden erst auf Anweisung per Smartphone anwirft.
Auch an dieser Stelle sind all jene Hersteller empfindlich im Vorteil, die eine eigene Plattform haben. Wer eine Waschmaschine der ACME Corp. hat und diese fernsteuern möchte, braucht ein Smartphone aus demselben Haus.
Convergence ist im Übrigen keine Zukunftsmusik. Abbildung 1.2 entstand auf einem Presseevent in Wien – der Anlass war die Ankündigung einer Kooperation zwischen dem Netzbetreiber Hutchison (Drei) und LG. Das Unübliche daran war, dass sich die beiden Firmen nicht auf eine Kooperation im Bereich der Handys einigten … hier ging es um den Vertrieb von TV-Geräten.
Bild 1.2: Hutchison und LG verkaufen gemeinsam Fernsehgeräte.
In Summe lässt sich also postulieren, dass im Mobilcomputerbereich »der Bär steppt« und dass es immer wieder etwas Neues zu tun und/oder zu sehen gibt. Diese Volatilität ist für Pressejournalisten hilfreich, da sie immer wieder Stoff für neue Sensationsberichte bietet. Leider hat man als Entwickler eher wenig davon: Wenn ein Betriebssystem untergeht, muss meist auch ein Gutteil der eigenen Software dran glauben.
Allein aus diesem Grund ist es sinnvoll, die eigenen Applikationen möglichst plattformunabhängig zu gestalten. Seit Jahren greifen Entwickler zum Erreichen dieses hehren Ziels auf eine Vielzahl von Methoden zurück, die teilweise sehr kompliziert sind und die Codebasis der erstellten Applikation wesentlich »verfetten«.
Zudem erfüllt die derzeitige Marktlage erstmals das Gesetz vom Duopol – es gibt zwei große Plattformen, die den Markt untereinander aufteilen. Aus dieser Sicht wäre es eine gewagte (aber durchaus wirtschaftlich begründbare) Prognose, dass sich die Verteilung der Betriebssysteme nicht mehr wesentlich ändert.
Aus dieser Situation folgt, dass einige Systeme im Laufe der Zeit vom Markt verschwinden werden. Die Benutzer von derartigen Geräten flüchten zwangsweise in Richtung anderer Plattformen – aus der Erfahrung ist bekannt, dass diese Flucht sehr langsam erfolgt.
Der Grund dafür liegt unter anderem in der auf 24 Monate angelegten Vertragsbindung der diversen Handyanbieter. Jedes zweite Jahr bekommt der durchschnittliche User ein neues Telefon geschenkt – warum also vorher upgraden?
Während des »Todes« einer Plattform treten hochinteressante Effekte auf. Da immer mehr Entwickler die Wartung ihrer Produkte für das System aufgeben, sehen sich die verbleibenden User mit einer immer geringeren Auswahl an Produkten konfrontiert. Dadurch wird es für Entwickler immer leichter, die Aufmerksamkeit dieser User zu gewinnen.
Menschen sind Gewohnheitstiere. Aus diesem Grund besteht eine hohe Wahrscheinlichkeit, dass die migrierenden User sich ihrer »alten Freunde« erinnern (siehe Abbildung 1.3). Für diese User konkurriert Ihre App nicht mit den 500.000 anderen Produkten in den Stores von Apple und Google – solange der Produktname gleich bleibt, sind Sie der Primus inter Pares.
Das hat längerfristig ziemlich interessante Effekte im Bereich der Userbindung. Sowohl Google als auch Apple »bevorzugen den Habenden« – in der Praxis bedeutet das, dass Entwickler mit hohen Userzahlen und guten Bewertungen leichter an Feature Spaces kommen als unerprobte Anbieter.
Bild 1.3: Die Beschreibung spricht User an, die von Symbian zu bada wechseln.
Natürlich ist es ökonomischer Unsinn, nur aus diesem Grund eine komplette und aufwendige Portierung anzustoßen. Wenn es sich dabei aber nur um eine Rekompilation handelt, sieht die Sache anders aus – und genau das leisten Cross-Plattform-Frameworks wie PhoneGap.
Wie Sie schon an der Einleitung bemerken, wendet sich dieses Werk nicht nur an handcomputererfahrene Entwickler. Natürlich ist auch für diese Zielgruppe jede Menge an interessanten Inhalten dabei – es ist aber nicht unbedingt erforderlich, Erfahrung im Bereich der Programmierung von Mobil-Apps zu haben.
Da PhoneGap auf JavaScript aufsetzt, ist es in jedem Fall sinnvoll, gute Kenntnisse in der Anwendung dieser Programmiersprache zu haben. Wer – wie der Autor – bisher eher mit C++ beziehungsweise Java arbeitet, findet im Anhang »OOP mit JavaScript« einige wertvolle Hinweise zum effizienten Einsatz.
Viel wichtiger ist in der Praxis das Mitbringen von ausreichenden Kenntnissen im Bereich der Erstellung von ansprechenden Webseiten. PhoneGap-Applikationen sind im Prinzip nichts anderes als Webpages mit interaktivem Code im Hintergrund – aus diesem Grund ist es dem Framework nicht wirklich möglich, Ihnen bei der Erstellung der grafischen Elemente zur Hand zu gehen.
Allerdings ist Webdesign eines der bestdokumentierten Themen im Bereich der Informatik. Literatur ist ohne Probleme erhältlich, Hunderte Grafiker warten nur darauf, für (oft überraschend) wenig Geld wunderbare Entwürfe zu liefern.
Dabei kommt Ihnen die soeben erwähnte Eigenschaft des Frameworks sehr entgegen. Es ist nämlich nicht notwendig, Ihrem Designer Zugriff auf die Programmlogik zu gewähren. Stattdessen kommt der in Abbildung 1.4 gezeigte Workflow zum Einsatz.
Bild 1.4: Entwickler und Designer bearbeiten separate Teile des Produkts.
Der Webdesigner bearbeitet ausschließlich die Layoutdaten, die in den HTML-Dateien liegen. Mit den die Programmlogik enthaltenden JavaScript-Files hat er nichts zu tun – diese verbleiben auf Ihrer Maschine und sind zum Erstellen der Designs nicht erforderlich.
Ähnlich wie bei QML profitieren Sie auch hier vom Wegfallen des fehlerträchtigen und höchst lästigen »Übersetzungsschritts« zwischen dem Design und der praktischen Applikation.
Dank immer schneller werdender Produktzyklen gibt es kaum einen Mobilcomputerprogrammierer, der über zu viel Freizeit klagt. Aus diesem Grund ist dieses Buch so aufgebaut, dass Sie es nicht zur Gänze lesen müssen. Allerdings spricht nichts dagegen, es zu tun.
Wenn Sie mit JavaScript noch keine Erfahrung haben, sollten Sie nach der Lektüre dieses Kapitels sofort mit dem Anhang zur objektorientierten Programmierung in JavaScript beginnen. Die dort vorgestellten Patterns erleichtern Ihnen die Arbeit mit den Codebeispielen – außerdem verhindern sie das Erstellen von unwartbarem Spaghetticode.
Zum »Schnellstart« empfiehlt es sich, Kapitel 2, »Erste Schritte mit PhoneGap«, sowie die Beschreibung der einzelnen Namespaces in Kapitel 6, »Die PhoneGap-API«, zu lesen. Danach wissen Sie genug über die Grundlagen von PhoneGap, um erste Entscheidungen zur Struktur Ihrer Anwendungen zu treffen.
Wenn Sie PhoneGap 3.0 verwenden, sollten Sie unbedingt das Kapitel 7 zu den Kommandozeilenwerkzeugen (CLIs) lesen.
Wenn Sie bisher keine Erfahrung mit der Entwicklung von mobilen Apps mit HTML und CSS haben, empfiehlt sich eine sorgfältige Beschäftigung mit dem Kapitel 5, »Oberflächen für Cross-Plattform-Apps«, das sich auch mit geeigneten Templates und Frameworks beschäftigt. Diese ersparen Ihnen unter Umständen sehr viel Arbeitszeit und sorgen für ein passables Aussehen der Applikation.
Da jedes Betriebssystem eigene »Parameter« hat, lesen Sie dazu selektiv Kapitel 3 zur Konfiguration der jeweiligen Entwicklungsumgebungen und Kapitel 10 zu nativen Plugins.
Oftmals werden die Funktionen eines Produkts erst dann verständlich, wenn man einige Beispiele für die damit erreichbaren Resultate sieht.
Die folgenden Beispielanwendungen entstammen allesamt der »Usecase-Sammlung« des PhoneGap-Projekts. Aus Platzgründen konnten hier nur einige interessante Apps ausgewählt werden – die volle Liste findet sich unter http://phonegap.com/case.
Die von LogiTech angebotenen Medienverteiler aus der SqueezeBox-Serie sind seit einiger Zeit auf dem Markt – sie erfreuen sich enormer Beliebtheit.
Weniger bekannt ist, dass die in Abbildung 1.5 gezeigte Steueranwendung fast komplett auf PhoneGap basiert. Nur die Kommunikation zwischen Endgerät und Telefon erfolgt durch nativen Code, der über ein Plug-in in die Programmierumgebung eingebunden wurde.
Interessant ist auch, dass der Entwickler im Interview (siehe http://phonegap.com/case/2011/07/20/turn-on-tune-in-turn-up-logitechs-squeezebox-controller-app-turns-phones-and-tablets-into-remote-controls/) besonders auf das GUI-Framework Sencha Touch hinweist. Und ein weiteres Thema ist die Verwendung von Desktop-Browsern zum Debugging.
Bild 1.5: LogiTech nutzt PhoneGap für eine Gerätesteuerungsapplikation (Bildquelle: http://phonegap.com/case/2011/07/20/turn-on-tune-in-turn-up-logitechs-squeezebox-controller-app-turns-phones-and-tablets-into-remote-controls/).
Die von der amerikanischen Spiele-Website IGN entwickelte App ist ein klassisches Beispiel für eine App, die für die Realisierung mit PhoneGap prädestiniert ist.
Bild 1.6: Auch IGN nutzt PhoneGap (Bildquelle: http://phonegap.com/case/2011/07/29/check-in-and-dominate-phonegap-score-with-ign-for-playing-well-with-others/).
Die Aufgabe des Programms ist vergleichsweise simpel: Es erlaubt Spielern, ihre in diversen Titeln erspielten Ergebnisse in soziale Netzwerke zu stellen. Dazu ist kein nativer Code erforderlich, deshalb konnte die Entwicklung komplett in JavaScript erfolgen.
Übrigens kam auch hier Sencha als GUI-Stack zum Einsatz.
Der kanadische Anbieter von Zahlungsdiensten benutzte PhoneGap, um eine in Objective-C geschriebene Anwendung für iOS zu ersetzen. Dabei kam ein hauseigener GUI-Stack zum Einsatz, der das Anpassen der Anwendung an die diversen Kunden wesentlich erleichtert (Stichwort CSS).
Besonders interessant ist im Fall von HyperWallet, dass das Unternehmen auch die mobile Webseite aus der PhoneGap-Codebasis heraus generiert.
Bild 1.7: PhoneGap ist auch für M-Payment-Applikationen geeignet (Bildquelle: http://phonegap.com/case/2011/06/03/hyperwallet-adds-mobile-apps-to-the-mix-with-phonegap/).
Am Ende der Einleitung eines Buchs sollte die Danksagung nicht fehlen – es gibt kaum ein Buch, an dessen Erstellung wirklich nur der Autor allein beteiligt war.
Erst durch Ihr Vertrauen, lieber Leser, bekam meine Arbeit einen Sinn. Deshalb gebührt der erste Platz auf dieser Liste Ihnen. Ihr Kauf zeigt Wertschätzung in meine Arbeit, ich hoffe, dass das vorliegende Werk Ihre Wünsche voll und ganz zufriedenstellt.
Meine Lebensgefährtin verdient besonderen Dank dafür, dass sie mir den Rücken während der Arbeiten an diesem Buch stets freigehalten hat – sei es durch das Abwimmeln lästiger Besuche oder das Anliefern von Nahrungsmitteln und Dokumenten. Deshalb: milujem ťa, Macky! Srdečná vďaka...
Fast genauso wichtig war mein langjähriger Wegbegleiter Markus Stäuble vom Franzis Verlag. Es ist immer wieder eine große Freude, mit einem Experten dieses Kalibers zusammenzuarbeiten – ohne sein Feedback und seine Hilfe (Stichwort: Apple) wäre dieses Werk nie so komplett, wie es ist.
Ohne Herrn Dipl.-Ing. Hubert Illibauer wäre ich heute nicht da, wo ich bin. Danke dafür, dass Sie da waren, als ich allein war.
Zu guter Letzt sei allen Partnern und Kunden der Tamoggemon gedankt. Ohne das Vertrauen all dieser Personen wäre das Unternehmen heute nicht da, wo es steht. Egal ob als Käufer einer Applikation oder als Bezieher von Dienstleistungen – diese Passage gehört nur ihnen. Danke, danke, danke!