Eine hybride Web-App für ein Blog oder ein ähnliches Medium zu entwicklen, ist mit Cordova - dem früheren PhoneGap - und NetBeans sehr einfach. NetBeans und das integrierte Cordova-Plugin generieren per Scaffolding alle erforderlichen Ressourcen, so dass wir nur eine einzige Zeile Source-Code benötigen, um unsere App zu realisieren.
Haben wir unser Blog nach den Prinzipien des Responsive Design entwickelt, funktioniert unsere App nicht nur technisch, sondern auch optisch sofort.
Natürlich werden wir in dieser puren Version ein paar Features vermissen, die die intuitive Benutzung unseres Mediums unterstützen, etwa um dem User ein Feedback zu geben, ob ein Link auf dem Touch-Display tatsächlich gedrückt wurde.
Mit zwei zusätzlichen CSS-Regeln können wir hier erste Hilfe leisten, so dass zumindest bei nicht extrem langsamen mobilen Endgeräten ein insgesamt schon recht beeindruckendes Ergebnis entsteht.
Neues Cordova-Projekt anlegen
Als erstes legen wir mit NetBeans ein neues Cordova-Projekt an (New Project / HTML5 / Cordova Application). Wie man ein solches Projekt funktionstüchtig macht, habe ich in diesem Artikel ausführlich beschrieben (Installationsvoraussetzungen, Projekt einrichten).
Für diejenigen, die sich schon etwas auskennen, hier die Anleitung noch einmal in Kurzform:
- einen Emulator mit dem Android-SDK starten,
- NetBeans: New Project / HTML5 / Cordova Application klicken,
- einen Application Name wählen (z.B. bei mir BlogCodeKiste),
- ansonsten in den Folgemasken nichts besonderes auswählen,
- New Project abschließen mit Finish,
- ein erstes Build ausführen (Projektordner / rechte Maustaste / build). Der Prozess dauert etwas, da sich das System Ressourcen aus dem Netz und vom Android-SDK besorgt. Bei Problemen findet man Lösungshinweise im oben verlinkten Artikel von mir. Der Abschluss war erfolgreich, wenn im NetBeans-Log-Window ein grünes Build successfull erscheint.
- in NetBeans oben in der Menuleiste unter dem grünen Android-Männchen-Symbol als Target Cordova (Android Emulator) einstellen.
- im Ordner <projekt> / platforms / android die Datei AndroidManifest.xml anpassen. In dieser Datei in dieser Zeile ( <uses-sdk android:minSdkVersion="10" android:targetSdkVersion="19" /> die Android-Api-Levels auf die Level der selbst erstellten Emulatoren abstimmen. Beispiel: Wenn der gestartete Emulator den Level 8 hat, dann sollte minSdkVersion auf 8 und targetSdkVersion z.B. auf 17 stehen. Für beide Levels sollten im Android-SDK-Manager die Android SDK Build-tools installiert worden sein.
- im gleichen Ordner <projekt> / platforms / android die Datei project.properties anpassen. Dort sollte der gleiche Level eingestellt werden, wie für targetSdkVersion. Bei mir z.B. target=android-17,
- jetzt kann man in NetBeans versuchen, ein Run auszuführen (Projektordner / rechte Maustaste / run),
- bei mir unter NetBeans 8.0.2 mit Cordova 4.2 funktioniert das leider nicht. Wer andere Versionen verwendet, dem helfen vielleicht die Problemlösungshinweise in meinem verlinkten Artikel oben. Ich helfe mir mit folgendem Trick:
- im Ordner <projekt> / platforms / android / cordova das run-Skript starten in einer Windows-Console mit run --emulator. Damit läuft das run-Skript meistens durch. Bei mir hängt sich aber auch dieses Skript manchmal auf, vor allem, wenn ich es zum ersten Mal starte. Ich versuche es dann einfach nochmal. Beim zweiten Mal wird dann das apk auf dem Emulator installiert und die App gelaunched.
Das ist sehr viel Installations- und Einrichtungskram, bis das neue Projekt endlich auf dem Emulator läuft, aber da muss man durch. Bei Erfolg präsentiert sich das neu angelegte Projekt wie in Abb. 1 dargestellt, aber die kennen wir schon aus meinem oben verlinkten Artikel.
Abb. 1: Neu angelegte hybride App im Android-Emulator
Mit einer Zeile Code ist man dabei
Jetzt kommt der einfachste Teil dieses kleinen Projekts: unser Source-Code. Der besteht nämlich nur aus einer einzigen Zeile:
window.open('http://code-kiste.hauertmann.com', '_self');Diesen fügen wir unten in unsere index.html-Datei unseres Projekts ein, bzw. tauschen dort die entsprechenden Zeilen und schon müsste beim nächsten Build & Run unsere App im Emulator funktionieren.
Damit man die Übersicht behält, hier die komplette nicht sehr umfangreiche Datei <projekt> / www / index.html:
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<meta name="format-detection" content="telephone=no" />
<meta name="msapplication-tap-highlight" content="no" />
<!-- WARNING: for iOS 7, remove the width=device-width and height=device-height attributes. See
https://issues.apache.org/jira/browse/CB-4323 -->
<meta name="viewport" content="user-scalable=no, initial-scale=1, maximum-scale=1, minimum-
scale=1, width=device-width, height=device-height, target-densitydpi=device-dpi" />
<link rel="stylesheet" type="text/css" href="css/index.css" />
<title>Blog Code Kiste</title>
</head>
<body>
<div class="app">
<h1>Blog Code Kiste</h1>
<div id="deviceready" class="blink">
<p class="event listening">Connecting to Device</p>
<p class="event received">Device is Ready</p>
</div>
</div>
<script type="text/javascript" src="cordova.js"></script>
<script type="text/javascript" src="js/index.js"></script>
<!--script>window.open('http://yetispeed.codekiste.de//','_self');</script-->
<script>window.open('http://code-kiste.hauertmann.com','_self');</script>
</body>
</html>Abb.2: index.html im Ordner <project> / www für eine rudimentäre App für dieses Weblog
Darin enthalten ist auch das Snippet für die lokale Entwicklungsumgebung, allerdings ausgeixt. Bei mir läuft das lokale System unter der Adresse http://yetispeed.codekiste.de.
Wer das Ganze auf der lokalen Entwicklungsumgebung ausprobieren (und weiterentwickeln) will, der muss vorher die Hosts-Datei auf dem Emulator ändern. Wie man das macht, habe ich in diesem Artikel beschrieben.
Abb. 3: Die Weblog-App im Emulator
Verbesserung des Feedbacks bei User-Interaktion
Die App funktioniert jetzt. Man wird aber schnell feststellen, dass es ziemlich stört, vor allem auf langsamen Geräten, wenn man einen Link betätigt und man Sekunden warten muss, bis eine neue Seite geladen wird, ohne dass man dies z.B. durch einen Progressbar oder einen Spinner angezeigt bekommt.
Der Aufruf über den Browser hatte ja zumindest den Vorteil, dass man die Url-Leiste sieht, die ja in der Regel einen Progressbar für den Ladefortschritt enthält. Diese Url-Leiste verunstaltet zwar unser Design optisch, was auch ein Grund für die Entwicklung einer App sein kann, aber man hatte zumindest ein User-Feedback.
Um dieses Feedback auch für unsere Blog-App zumindest ansatzweise wieder herzustellen, behelfen wir uns mit zwei einfachen CSS-Regeln.
/*
* Important for simple user feedback on mobile touch screens
*/
a {
text-decoration: none;
}
a:hover {
text-decoration: underline;
}
a:active {
text-decoration: underline;
}Wir verhindern bei allen Links zunächst einmal das underline und setzen dies nur für die Zustände hover und activ. Wir müssen in unserem Blog-Design, dann natürlich Alternativen für die Darstellung von Links finden, was nicht schwer sein sollte.
Damit erreichen wir kurz nach dem Berühren eines Links auf dem Touch-Screen, dass der Link mittels Unterstreichung als geklickt bestätigt wird. Längere Wartezeiten für das Laden einer neuen Seite werden hierdurch erträglicher.
Dies ist eine einfache und billige Lösung. Für einen Spinner muss man sehr viel mehr Aufwand betreiben. Wie man das macht, wird in folgenden Artikeln beschrieben.
Jetzt fehlt nur noch das Launcher-Icon
Vielleicht das wichtigste Feature für eine native App ist das Launcher-Icon. Zumindest aus Marketing-Gesichtspunkten. Denn dieses ermöglicht erst das komfortable Aufrufen der Web-Anwendung.
Es ist schwer, Nutzer von mobilen Endgeräten dazu zu bewegen, umständlich eine Url in eine Browser-Leiste einzugeben. Auf dem Handy ist man es gewohnt, eine Anwendung vom Desktop aus mit einem Klick zu starten. Deshalb sollte man auf den Aspekt Launcher-Icon durchaus einiges an Überlegung investieren.
Wie man auf ganz einfache Weise - nämlich durch Kopieren von Icons in die richtigen Cordova-Projekt-Ordner - seine App mit einem Launcher-Icon ausstattet, habe ich in diesem Artikel beschrieben. Deshalb beschränke ich mich an dieser Stelle darauf, noch einmal auf diese praktische Seite hinzuweisen, auf der man eine vorhande Launcher-Grafik, die man z.B. aus dem Logo der Seite ableiten kann, in alle benötigten Formate für die App konvertieren kann, wobei zusätzlich ein paar simple grafische Effekt spendiert werden. Für den Anfang sollte das reichen.
Das Ergebnis kann dann wie in Abb. 3 aussehen. Das wirkt doch schon richtig professionell, nicht wahr?
Abb. 3: Das Launcher-Icon für das Weblog auf dem Android-Desktop
Das ganze funktioniert natürlich genauso, wenn man statt des Emulators ein mobiles Endgerät verwendet. Dann muss man als Target Cordova (Android Device) in NetBeans einstellen bzw. in der Windows-Console run --device eingeben.
Fazit
Das Beispiel zeigt, dass man für ein News-Medium oder ein anderes Text-orientiertes Web-Portal, welches nach den Prinzipien des Responsive Designs gebaut wurde, schon mit sehr wenig Aufwand eine native App realisieren kann.
Im Grunde wird nur der interne Browser von Android verwendet. Die App selbst startet mit dem Launcher-Icon den internen Browser und setzt dessen Url auf die gewünschte Webseite.
Für manche Web-Medien ist diese Lösung ausreichend. Verzichtet wird auf die Nutzung der Sensorik des Handys, aber für das Lesen einer Web-Seite reicht die Technik vollkommen aus. Dies ist die denkbar billigste Art, eine native bzw. hybride App für seine Webseite zu realisieren.
Für etwas mehr Feedback - etwa für die Realisierung eines Spinners für die Ladezustandsanzeige der Seite - benötigt man schon sehr viel mehr Know-How.
Außerdem lassen sich Anwendungen denken, in denen auch normale responsive Portale die Sensorik und Geolocation-Features von mobilen Endgeräten nutzen möchten. Denkbar sind z.B. Stadtführer, die auf einer Karte die aktuelle Position anzeigen, was so durchaus noch mit reinem Html5 und Javascript geht.
Will man aber zusätzlich einen Kompass integrieren, wie man dies von modernen puren nativen Apps her gewohnt ist, benötigt man Zugriff auf die Handy-Sensorik über den Cordova-Wrapper.
Eine andere interessante Möglichkeit wäre es, Fotos von Usern direkt auf das eigene Portal hochladen zu können.
Wie man dies alles realisieren kann, ist Gegenstand weiterer Artikel demnächst in diesem Blog.