Es war letztes Jahr im September oder Oktober als sich bei mir der Gedanke verdichtete einmal eine App zu schreiben. Ich meine „hey“, ist auf jeden Fall schon irgendwie cool so eine eigene App zu haben. Bis dahin fehlte mir einfach nur die zündende Idee für das Thema der App. Doch nach der Anschaffung einer Segeljolle im selben Jahr war klar: Es würde eine Segel-App werden :-). Mac und iPhone waren vorhanden, also schnell mal Xcode angeworfen und mit einem Tutorial in der Hand losgelegt. Ich habe schliesslich früher (in einem anderen Entwicklerleben) mal C++ programmiert, da kann ja ObjectiveC auch nicht das Problem sein. Nun ja, was soll ich sagen, es folgte eine gewisse Ernüchterung ;-).
Das ist im allgemeinen – und so auch hier – der richtige Momenet noch einmal kurze inne zu halten und zu überlegen. Zum Einen wollte ich die App gerne sowohl für iOS als auch für Android anbieten. Das heisst die App hätte ohnehin ein zweites Mal in Java geschrieben werden müssen, was den Aufwand – wir reden hier über ein Freizeitprojekt – nochmal um einiges in die Höhe getrieben hätte. Zum Anderen geht es in der App hauptsächlich um die Aufbereitung und Repräsentation von Wissen, also eigentlich ziemlich genau das wofür HTML früher einmal gedacht war (für die jüngeren Leser: das war vor dem ganzen Web 2.0/3.0/4.0-Kram ;)). Ich hatte schon öfter von der App-Entwicklung mit Hilfe von HTML5/CSS und JavaScript gehört und das immer so ein wenig als Spielkram abgetan. Doch jetzt fing ich an mich intensiver mit der Materie zu beschäftigen und stiess dabei relativ schnell auf Phone Gap.
Moment mal: Warum wird hier von Phone Gap geredet wo in der Überschrift doch was von Cordova steht? Kurz gesagt: Phone Gap ist mittlerweile eine Cordova-Distribution wenn man so sagen will. Hier gibt es weitere Details dazu. Kurz nach dem Start meines Projekts habe ich dieses relativ problemlos von Phone Gap auf Cordova portiert.
Die API – Oder „Was ist möglich?“
Also Phone Gap aka Cordova! Zunächst einmal muss man hier sagen, dass die Dokumentation echt sehr gut und umfangreich ist . Natürlich wollte ich auch nicht erst zu einem späten Zeitpunkt merken, dass gewisse Dinge gar nicht umzusetzen sind. Das hängt natürlich immer vom Einzelfall der zu entwickelnden App ab. Allerdings bieten JavaScript zusammen mit einer langen Liste an unterstützen APIs hier schon wirklich eine Menge Möglichkeiten. Die APIs im Einzelnen:
- Accelerometer – Abgreifen von Bewegungen in den einzelnen Achsen.
- Camera – Zugriff auf die Kamera-Applikation.
- Capture – Zugriff auf die Möglichkeiten zur Aufnahme von Bildern, Videos und Audio.
- Compass – Ermitteln der Richtung in die das Gerät zeigt.
- Connection – Informationen über Status der WiFi- und Mobilfunkverbindungen.
- Contacts – Zugriff auf die Kontakte.
- Device – Zugriff auf Geräteinformationen.
- Events – Zugriff auf native Events.
- File – Zugriff auf das native Dateisystem.
- Geolocation – Zugriff auf GPS-Informationen.
- Globalization – Informationen und Operationen bezogen auf die Sprache des Benutzers.
- InAppBrowser – Öffnen einer neuen Browser-Instanz.
- Media – Aufnehmen und Abspielen von Audio-Dateien.
- Notification – Benachrichtigungen (audio, visuell, taktil).
- Splashscreen – Anzeigen oder Verstecken des Splashscreens.
- Storage – Persistente Datenspeicherung auf dem Gerät.
Wie man sieht ist die API-Liste lang und lässt kaum Wünsche übrig. Für eine eher triviale App wie meine Segel-App (die hier nochmal verlinkt werden muss :-)) ohnehin nicht, aber sicherlich lohnt sich auch bei vielen anderen Anwendungsfällen ein genauer Blick bzw. eine Evaluierung von Cordova.
Das Grundprinzip – Kommandozeile und generierte Projekte
Bei Cordova läuft die Steuerung komplett über Kommandozeilen-Befehle , was ich persönlich sehr sympathisch finde. Über die Kommandozeile wird z.B.:
- Ein neues Cordova-Projekt angelegt.
- Verschiedene unterstützte Plattformen zu einem Projekt hinzugefügt.
- Plattformspezifische Features konfiguriert.
- Ein Build gestartet welches die plattform-spezifischen Projekte neu generiert.
Der letzte Punkt ist ein recht entscheidender! Es werden letzten Endes die kompletten Projekte für die entsprechenden Plattformen und die zugehörigen Entwicklungsumgebungen generiert. Das heisst für iOS ein Xcode-Projekt und für Android ein Android Development Tools (manche nennen es auch Eclipse ;)) Projekt. Diese Tools werden dann auch benötigt, um ggf. Emulatoren, Simulatoren oder auch den Upload-Prozess in den App-Store zu starten. Dies heisst auch, dass man trotz Cordova zwingend einen Mac mit Xcode benötigt, wenn man eine iOS-App entwickeln möchte.
Der Arbeitsablauf in der Entwicklung ist hiermit am Ende trotzdem sehr einfach. Man editiert seine HTML5/CSS/JavaScript-Dateien in einem Editor seiner Wahl. Dann startet man das Cordova-Build, um danach z. B. in Xcode den Simulator auf der neuen Version zu starten.
Rein technisch sind die aus Cordova generierten Projekte trivial. Es wird meist nur eine 2Hauptklasse“ erzeugt, in der dann ein entsprechendes WebPane angezeigt wird. Aber trotzdem ist die Arbeitserleichterung hier gigantisch, da man ja sonst das Ganze Packaging etc. (unterschiedlich für die verschiedenen Plattformen) von Hand machen müsste. Manche Features wie das Anzeigen eigener Splashscreen-Dateien lassen sich auch einfach realisieren, indem in den entsprechenden Projekt-Verzeichnissen des Cordova-Projekts die Platzhalter-Dateien überschrieben werden.
Alles in Allem ist das Arbeiten so sehr angenehm und einfach. Allerdings muss man sich trotzdem in einige Besonderheiten der plattform-spezifischen IDEs einarbeiten. Insbesondere bei Apple mit Provisioning-Profiles etc. kann dies schon ein wenig Zeit in Anspruch nehmen, die einem auch Cordova nicht abnehmen kann.
Das Design – Es ist eine APP und keine Webseite
Schreibt man eine Anwendung mit Cordova und damit letzten Endes in HTML5/CSS besteht schnell die Gefahr, dass die App am Ende eher wie eine Web-Seite und weniger wie eine „echte“ App aussieht. Dieses Problem mag verschärft werden, wenn parallel ohnehin eine Webseite zur App entwickelt wird. Zu Beginn meines Projekts habe ich mich für Twitter Bootstrap als HTML/CSS-Framework entschieden. Im Laufe der Zeit habe ich dann immer weiter das CSS in Hinblick auf die App getuned und mit JQuery Mobile dann auch bald ein weiteres Mobile-Framework hinzugenommen.
Rückblickend – und für neue Projekte – wäre es hier vermutlich besser gewesen auf ein Framework wie Sencha Touch zu setzen. Hierdurch ist es möglich wesentlich näher an das native Look & Feel der verschiedenen App-Platformen heran zu kommen. Natürlich steigt damit auch der Einarbeitungsaufwand weiter an.
Build und Test – Der Emulator des Grauens
Wie weiter oben ja schon beschrieben gehört natürlich auch der regelmäßige Test der App zum Entwicklungszyklus. Da es dabei oft auf die Optik ankommt ist hier weniger Testautomatisierung gefragt, als ein scharfer Blick auf die App im Emulator, Simulator oder auf einem echten Device.
Dies ist eigentlich nicht spzifisch für die App-Entwicklung mit Cordova sondern ist allgemeingültig. Da man jedoch mit Cordova vermutlich häufiger plattformübergreifend entwickelt gibt es hier die klare Empfehlung bei den meisten Tests erstmal die iOS-Variante im Xcode-Simulator durchzuführen. Dieser ist ohne Übertreibung ungefähr um den Faktor 30 bis 50 schneller als der ADT-Emulator. Dies liegt natürlich auch in den unterschiedlichen Konzepten (Simulator vs. Emulator) begründet. Für Android teste ich eigentlich immer direkt auf dem Device und nur in Ausnahmefällen, d. h. wenn ich etwas für ein bestimmtes Gerät testen muss, tue ich mir einen Emulatorlauf an.
App Store / Play Store – Die letzte Hürde
Auch hierzu wurde ja weiter oben schon einiges geschrieben. An dieser Stelle kann ich nur sagen: Zum Glück gibt es StackOverflow! Habe mich letzen Endes durch die diversen „Store-Probleme“ gegoogelt und bin dabei fast immer auf StackOverflow fündig geworden.
Wird für Android im ADT erstmalig eine APK-Datei erzeugt, so muss hier ein Schlüssel generiert werden für den man wiederum ein Passwort angeben muss. Dieses Passwort ist extrem wichtig! Denn ohne dieses Passwort kann der Schlüssel nicht mehr benutzt werden und ohne den Schlüssel ist ein Update der App im Play Store unmöglich. Siehe auch hier .
Dies hat aber letzten Endes nichts mehr mit Cordova zu tun und ist auch nichts, was Cordova einem abnehmen kann.
Fazit – Es hat Spass gemacht und macht noch immer Spass
Cordova gehört definitiv zu den Dingen die – würde es nicht bereits existieren – erfunden werden müsste. Alles ist durchdacht und funktioniert ohne große Probleme. Läuft doch mal was nicht findet man dank Google im Allgemeinen schnell die passende Lösung. Das Designen der App mit HTML5 und CSS macht Spass und wird durch verschiedene Frameworks unterstützt. Funktionen von diesen kann man auch nachträglich Stück für Stück „nachrüsten“. Ich würde mal sagen bei „gut gemachten“ Cordova-Apps sieht man keinen Unterschied zu entsprechenden nativen Apps.
Keep hacking, have fun 🙂
War dieser Beitrag hilfreich?
Weitere Beiträge
von Thomas Jaspers
22.2.2019 Dein Job bei codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Weitere Artikel in diesem Themenbereich
Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog-Autor*in
Thomas Jaspers
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.