Effiziente mobile Entwicklung trotz unterschiedlicher Programmiersprachen

Entwicklung für unterschiedliche mobile Plattformen

Die Diversität mobiler Plattformen führt zu erheblichen Aufwänden, wenn man gezwungen ist, die gleiche Funktionalität in unterschiedlichen Programmiersprachen zu realisieren, zu testen, auszurollen und über Jahre hinweg zu warten. Und trotzdem möchte niemand auf die Vorteile mobiler Geräte im Ausseneinsatz verzichten, deren Sensoren wertvolle Dienste leisten. 

Wie kann mobile Entwicklung für mehrere unterschiedliche mobile Plattformen effizient gestaltet werden? BSI hat im Winter 2011/2012 verschiedene Möglichkeiten analysiert und im Rahmen eines Proof of Concept auf die Machbarkeit hin überprüft. Nach Evaluation unterschiedlicher Optionen haben wir uns für die Umsetzung einer Architektur aus Web-Technologien (HTML5, JavaScript, CSS) für die Applikationslogik und das Frontend entschieden. Für die Hardware-Integration wurde Apache Cordova als Container verwendet, welcher den Zugriff der Applikation auf die Hardware entkoppelt und damit eine einheitliche Schnittstelle erlaubt.

Um den Erkenntnisgewinn zu maximieren haben wir uns das Leben für den PoC extra schwer gemacht: Als Plattformen kamen neben Apple und Android-Geräten auch ein Windows-Phone-zum Einsatz. Dies ganz bewusst, denn Apache Cordova verwendet zur Darstellung der Seite den Browser des Betriebssystems und Windows Phone verwendet mit dem Internet Explorer eine deutlich andere Browser Engine als Android und iOS (WebKit).

Zusätzlich wollten wir nicht nur die Kamera des Mobilgerätes integrieren, sondern auch eine Schnittstelle eigene Hardware-Integration für einen Bluetooth Scanner realisieren.

Der PoC war ein Erfolg. Wir konnten mit unserem Ansatz bereits 2011 aufzeigen, dass wir multidevicefähig programmieren können ohne den Entwicklungsaufwand für jedes Gerät vervielfachen zu müssen.

Update 26.1.2015: Die massive Weiterentwicklung der vergangenen Jahren im Bereich der Web-Technologien und die Etablierung von HTML5, JavaScript und CSS als valable Technologien für Geschäftsapplikationen bestätigen unseren vor drei Jahren gewählten Ansatz.

Die Herausforderung

Wie lassen sich Android und Windows Phone mit derselben Basisapplikation ansteuern? In Kooperation mit einem Kunden entwickelte BSI eine starke Antwort unter Nutzung von HTML5, Cordova und den passenden Plugins. Das Beispiel beweist, dass man aus der «Falle» nativer Apps ausbrechen und funktional anspruchsvolle, offline-fähige Enterprise-Applikationen erstellen kann, welche nicht nur auf einem bestimmten Gerät laufen. Und damit auf einfache Weise Kosten sparen kann.

Bericht von der Werkbank

Die Präsentationsschicht wurde mit HTML5 und entsprechenden Frameworks realisiert. Für die Widgets haben wir jQuery mobile und Sencha Touch geprüft. Letztendlich haben wir uns gegen Sencha Touch entschieden: Der Internet Explorer von Windows Phone 7.5 wird in Version 1.x nicht richtig unterstützt, und die Lizenzierung für kommerzielle Projekte scheint eher volatil zu sein. Dies war für unser Projekt keine Option. Der Vorteil von Sencha Touch ist die bessere Trennung zwischen UI und Applikationslogik, was die Wartbarkeit der Programme verbessert. Für weitere Projekte werden wir sicher Sencha Touch nochmals evaluieren. Da die Applikation offline-fähig sein muss, war es wichtig, dass die Business-Logik auf dem Device lokal vorliegt. Für eine App, die möglichst plattform-unabhängig sein muss, heisst das natürlich: JavaScript. Mit den richtigen Caching-Einstellungen funktioniert die HTML5-Website auch im Offline-Modus. (Dass der Cache auf Windows Phone nicht funktioniert, ist leider eine Problematik des Betriebssystems.)

Client-seitige Architektur
Wirkt kompliziert, funktioniert aber trotzdem: Client-seitige Architektur der Lösung
Applikationsvergleich Android Windows
Same but different: Die gleiche Applikation auf Android Tablet und Windows Phone – Single-Sourcing und Multi-Device im Praxistest

HTML5 – powered by Cordova

Bereits heute integriert HTML5 Standards, um Teile der Hardware direkt anzusprechen. Für uns war das nicht genug, da Barcode-Erkennung und elektronische Unterschriften erforderlich waren. Über HTML5 und JavaScript hinaus benötigten wir einen Container, der aus der Web-App heraus den Zugriff auf die Hardware und das Ausführen ermöglicht. Das Apache Cordova Projekt (entstanden aus Phonegap) ermöglicht genau dies: Cordova stellt ein JavaScript-Interface zur Verfügung, um auf native Komponenten zuzugreifen, und zwar für iOS, Android, Windows Phone und weitere mobile Betriebssysteme. Vorausgesetzt, die App ist lokal installiert (die Applikation kann aber auch auf einem Server gehostet sein). Und natürlich müssen für jedes OS native Plugins entwickelt werden, wobei aber keine komplette Implementierung nötig ist: Oft können bereits bestehende native Libraries eingebunden werden. Für die Barcode-Erkennung verwendeten wir etwa die zxing-Library.

Zwei Wege für das Deployment

Im Zusammenspiel mit dem Browser der Endgeräte eröffnet Cordova zwei Möglichkeiten für das Deployment des Codes: Die ganze Applikation kann zu einer App geschnürt und komplett auf den Client übertragen werden. Oder es wird nur Cordova mit den erforderlichen Plugins installiert, wobei die Applikation wie üblich vom Webserver geholt und lokal ausgeführt wird. Einstellungen des HTML-Cache ermöglichen es hierbei, die Applikation auch dann lokal zu halten, wenn keine Internetverbindung verfügbar ist. Das hat den zusätzlichen Vorteil, dass die App nur dann deployt werden muss, wenn neue Plugins oder neue Features von Cordova benötigt werden. Welcher der beiden Lösungswege der optimale ist, hängt von den Projektzielen ab.

Eclipse Scout Server im Backend

Für die Stamm- und Bewegungsdaten setzten wir einen normalen Eclipse Scout Server ein: Dieser verarbeitet die AJAX-Requests des Clients mit den enthaltenen JSON-Objekten. Das Mapping zwischen einem JSON und einem Java Objekt wurde automatisiert und mithilfe von der Java Library «google-gson» umgesetzt. Die lokalen Daten des Endgeräts werden ganz einfach im Speicher des Browsers (local storage) als JSON-Strings abgelegt und gelegentlich – bei aktiver Verbindung zum Server – an das Backend übermittelt. In der Gegenrichtung werden Stammdaten als JSON-Strings übermittelt und im lokalen Speicher abgelegt. Dadurch stehen sie auch im Offline-Fall zur Verfügung.