Mobile

In diesem Beitrag wird die Architektur der hybriden App aus dem letzten Beitrag durch den Einsatz des Frameworks RequireJS verbessert. Da wir das Projekt schon auf dem Module-Pattern aufgebaut hatten, sind nur noch wenige Modifikationen notwendig, um dynamisches Laden der Module zu ermöglichen.

Dieses dynamische Laden kann zu erheblichen Performance-Verbesserungen führen. Außerdem lassen sich Abhängigkeiten zwischen den Modulen mit dem Framework require.js leichter verwalten. Auch wird durch den Einsatz von r.js (Ein NodeJS-Modul) eine Optimierung des Source-Codes möglich gemacht (Minification). Dieser Punkt ist aber nicht mehr Gegenstand dieses Artikels.

Wir hatten uns in diesem Artikel eine super-simple App mit einer Zeile Source-Code gebaut, die allerdings nur in wenigen Einsatzfällen professionellen Ansprüchen genügt, vielleicht als ePaper-Reader oder als App für ein einfaches News-Medium - zum Beispiel ein Blog - wobei allerdings Responsive Design vorausgesetzt wurde.

Die Lade-Anzeige der Seite wurde mit einfachen CSS-Bord-Mitteln realisiert, was durchaus schon die Usability beträchtlich erhöhen kann. Aber wahrscheinlich will man sehr schnell etwas mehr Komfort und einige spannende Features implementieren.

Ein Spinner für die Lade-Anzeige sieht schon sehr viel professioneller aus und wie wäre es mit einem Kompass für das Impressum, so dass man mobil auf der Anfahrtskarte auch die Richtung erkennen kann, in die man laufen muss? Ich selbst hätte schon häufiger dafür Bedarf gehabt, vor allem, wenn ein Kunde mitten in der Stadt wohnt und das Navi im Parkhaus zurückgelassen werden musste.

Oder man will seinen Nutzern die Möglichkeit geben, ein Photo hochzuladen? Ein solches Feature ist vielleicht der erste Schritt zu einem erfolgreichen Geschäftsmodell.

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.

Die Erstellung eines Launcher-Logos für die eigene mit NetBeans generierte hybride Web-App ist etwas hakelig. Die Dokumentation von Cordova diesbezüglich lässt an Klarheit zu wünschen übrig und unsere Debug-Möglichkeiten sind in solchen Fällen sehr beschränkt.

Wir werden später noch Möglichkeiten kennenlernen, wie man Icons für verschiedene Zwecke für hypbride Apps sinnvoll organisiert. In diesem Beitrag wird eine schnelle Alternative vorgestellt, die ohne viel Theorie den Spaß am Entwickeln durch ein schönes Launcher-Icon erhöht, ohne dafür in die Tiefe gehen zu müssen.

Wer als Entwickler von mobilen Endgeräten auf einen lokalen Web-Server zugreifen möchte, muss die hosts-Datei seines Endgeräts modifizieren. Dies ist etwas schwieriger, als bei einem normalen Windows- oder Linux-PC. Im folgenden wird die Vorgehensweise für Emulatoren und Endgeräte gezeigt.

Für einige im nächsten Jahr geplante Beiträge in diesem Weblog soll an dieser Stelle schon auf die Android Debug Bridge (adb) aufmerksam gemacht werden, da dieses Tool eine wichtige Rolle spielt, wenn hybride Apps Zugriff auf einen lokalen Entwicklungs-Web-Server benötigen.

Wer mit seinem gerooteten Handy oder einem Android-Emulator per Console kommunizieren will, wie mit einem Linux-Rechner, was im Entwicklungsprozess häufiger erforderlich ist, der benötigt adb.

Grundsätzlich ist adb im Android-SDK enthalten, allerdings muss das Tool dort etwas tricky konfiguriert werden für den komfortablen Einsatz.

Ein Tool, welches die Produktivität bei der Entwicklung hybrider Web-Apps erheblich verbessert, ist der Chrome-Ripple-Emulator.

Das Testen mit dem Android-SDK-Emulator kostet viel Zeit für das Build sowie das Launchen der Anwendung im Emulator. Die Android-Emulatoren bieten allerdings den Vorteil, das sie das Testen für viele verschiedene Betriebssystem-Versionen und Endgeräte-Typen ermöglichen, weshalb das SDK im Entwicklungsprozess nicht überflüssig wird.

Der Ripple-Emulator dagegen eignet sich für die effiziente Programmierung der App als solche, solange neue Funktionalitäten während eines Entwicklungszyklus aufgebaut und vorläufig getestet werden.

Vor allem auch die Sensorik von mobilen Endgeräten kann mit dem Ripple-Emulator viel besser getestet werden, als mit dem SDK-Emulator.

NetBeans ist eine hervorragende IDE, um hybride Web-Apps zu entwicklen. Was hybride Web-Apps sind, wurde in diesem Beitrag dargestellt.

Hier wird nun beschrieben, welche Installationsvoraussetzungen erfüllt sein müssen und wie man einen Basis-Workflow mit NetBeans einrichtet, um eine einfache Hello-World-App in Betrieb zu nehmen.

In weiteren Artikeln wird gezeigt, wie man diesen Workflow so optimiert, dass man fast die gleiche Performance erreicht, wie bei der Eintwicklung einer statischen Webseite.

In diesem Beitrag geht es hauptsächlich um die Vor- und Nachteile hybrider Web-Apps aus der Entwicklungsperspektive. Mit hybrid ist das aus der Anwendungsentwicklung bekannte Prinzip "Write once, compile anywhere" gemeint.

Native Apps benötigen für jedes Betriebssystem jeweils eine eigene Entwicklung. Hybride Apps werden in Html5, CSS3 und Javascript realisiert und benötigen für die Auslieferung an verschiedene Betriebssysteme (Android, iOS, Windows, ...) nur noch einen Betriebssystem-spezifischen Wrapper, der zudem automatisch generiert werden kann, z.B. mit Cordova, das früher bekannt war unter dem Namen PhoneGap.

Der Entwicklungsaufwand von hybriden Apps ist deshalb gegenüber dem für native Apps wesentlich geringer (vgl. Abb. 1).

Wer Apps für mobile Endgeräte entwickelt, wird sich das Software-Development-Kit von Android (SDK) installieren. Analoge Systeme für iOS gibt es natürlich, werden hier aber zunächst nicht diskutiert, da sich das Android-Betriebssystem für erste Schritte am besten eignet. Da wir nur hybride Apps entwickeln, benötigen wir nicht das Android-Studio mit der speziellen Eclipse-Java-IDE, sondern nur die Stand-alone SDK-Tools.