Mobile HTML5-Anwendungen in Java plattformunabhängig entwickeln

GWT wird mobil

Daniel Kurka

Anwendungen auf mobilen Endgeräten werden immer gefragter. Soll eine Anwendung auf mobilen Endgeräten nutzbar sein, ist meist die erste Frage: nativ oder Web? Die Argumente für und wider die jeweiligen Ansätze hat jeder bereits zu Genüge gehört: Native Anwendungen sind performanter, und man kann auf Telefonfunktionen wie die Kamera zugreifen. Allerdings muss für jede Plattform ein eigenes Entwicklerteam her. Webanwendungen hingegen können plattformübergreifend und damit von einem einzigen Team entwickelt werden. Das Web bietet zudem mehr Zukunftssicherheit. Die Kehrseite: Telefonfunktionen können nicht genutzt werden, und Webanwendungen gelten teilweise als inperformant. Aber: Ist das wirklich noch der aktuelle Stand der Dinge?

Dieser Artikel stellt die aktuellen Entwicklungen dar und zeigt, warum HTML5-Anwendungen weiter an Bedeutung gewinnen werden. Es wird ein Ansatz vorgestellt, mit dem nativ aussehende und plattformübergreifende Anwendungen in Java erstellt werden können, die nativen Anwendungen in nichts nachstehen. Um die aktuellen Entwicklungen richtig einordnen zu können, wird zunächst auf die Anfänge des Webs und die Ursprünge von App Stores zurückgeblickt.

Anfänge der Apps

Kurz nach dem ersten Release des iOS SDKs im Sommer 2008 hatten bereits viele Nutzer das Maximum von 148 Apps erreicht. Apple stellte schnell fest, dass Nutzer deutlich mehr Apps auf ihren Telefonen haben wollten, und führte das so genannte Folder-Konzept ein. Dadurch wurde die Anzahl der Apps auf ca. 2100 erhöht. Bei solch einer Menge finden Nutzer allerdings nur noch schwer die gewünschte App.

Anfänge des Webs

Yahoo ließ das Web durch Redakteure durchsuchen und Inhalte in einen Katalog eintragen. Dieser Katalog war für Nutzer die Basis der Suche. Google hatte erkannt, dass dieser Ansatz nicht haltbar sein würde, wenn die Anzahl der Webseiten weiterhin so drastisch zunehmen würde, und fand eine Möglichkeit, Inhalte automatisch zu finden und zu bewerten. Durch die Bewertung der Inhalte war es Google möglich, jedem Nutzer gezielt passende Inhalte anzubieten. Durch diese neue Art der Suche setzte Google sich innerhalb kürzester Zeit gegenüber Yahoo durch.

App – Quo vadis?

Der App Store ähnelt dem Yahoo-Katalog: Nutzer müssen Inhalte manuell finden und auswählen, auf ihrem Telefon verwalten und updaten. Ein typisches Beispiel: Wenn man heute in einer fremden Stadt an eine Bushaltestelle kommt und die Abfahrtzeit des nächsten Busses herausbekommen möchte, so muss man zunächst den Namen des Verkehrsbetreibers herausfinden. Dann sucht man nach dem Namen des Verkehrsbetreibers in einem App Store, um sich eine App zu installieren – all das nur, um an die benötigte Information zu kommen. Diese App braucht man aber wenige Tage später nicht mehr. Dadurch werden auf Smartphones heute immer mehr Apps angesammelt, die eigentlich gar nicht gebraucht werden. Telefone sind voll unnützer Anwendungen, und die wichtigen Anwendungen lassen sich nur noch schwierig finden. Wäre es nicht viel besser, wenn die passende Anwendung automatisch vorgeschlagen würde, wenn man an eine Bushaltestelle käme, sodass man sie gar nicht erst installieren muss?

Was heute bereits als störend oder lästig empfunden wird, wird in naher Zukunft unzumutbar sein. Da die Kosten für CPUs immer stärker zurückgehen, wird in Zukunft vieles durch digitale Interaktion stattfinden. Es wird selbstverständlich werden, mit seinem Telefon zu bezahlen, sein Auto zu öffnen, den Fernseher zu bedienen oder den Senf nach seinem Verfallsdatum zu fragen. In dieser Art von unendlichen Interaktionen sind Webseiten Apps klar überlegen. Wer hat heute schon Tausende von Anwendungen auf seinem Desktop-PC installiert? Das Modell von Apps kann hier nicht skalieren. Mit Webseiten hingegen kann Funktionalität sofort benutzt werden, ohne damit Telefone mit Installationen zu belasten. Möchte ich eine Anwendung nicht mehr nutzen, gehe ich einfach nicht mehr auf die Webseite.

Trotzdem sind Apps heute noch sehr beliebt und werden auch nicht vollständig aussterben. Es wird auch weiterhin einige Apps geben, die so wichtig sind, dass sie auf dem Telefon installiert werden. Stellt sich die Frage, wie man Software heute herstellen kann, die in einem solchen Umfeld gut funktioniert.

[ header = Teil 2 ]

Technologie-Stack

Mit dem Ansatz, der nun vorgestellt wird, kann man in Java performante Anwendungen schreiben, mit denen aus derselben Codebasis sowohl plattformübergreifende Apps als auch Webseiten erstellt werden können. Folgende Werkzeuge kommen dabei zum Einsatz: PhoneGap, GWT, gwt-PhoneGap und mgwt [1]. PhoneGap bietet die Möglichkeit, HTML5-Anwendungen auf vielen Plattformen auszuführen, ohne dabei auf die Features von nativen Anwendungen verzichten zu müssen. GWT eignet sich dafür, performante HTML5-Anwendungen zu erstellen. In GWT fehlen aber mobile Oberflächenelemente und die Interaktion mit PhoneGap. Diese Lücke schließen die beiden Open-Source-Projekte mgwt und gwt-PhoneGap.

PhoneGap

Vergleicht man native App-Entwicklung mit Webentwicklung, so fällt auf, dass deren Vor- und Nachteile einander komplementär gegenüberstehen: Während native Apps über ein gute Performance verfügen, alle Telefonfunktionen nutzen können und über App Stores verteilt werden, muss die Anwendung für jede Plattform neu geschrieben werden. Webanwendungen dagegen funktionieren einheitlich auf verschiedenen Plattformen, da sie das Web als Basis nutzen. Sie können gute Performance haben – hierzu später mehr – aber sie können nicht auf alle Telefonfunktionen zugreifen. Zusätzlich bietet das Web als Plattform Zukunftssicherheit, denn z. B. könnte Apple mit einem kommenden Release vieles im iOS SDK verändern, während der Browser weiterhin alle Webseiten anzeigen kann. Dadurch können einmal erstellte Webanwendungen sehr lange genutzt werden, was gerade im Geschäftsumfeld wünschenswert ist.

Mit PhoneGap werden die Vorteile beider Ansätze nutzbar, ohne dass man die jeweiligen Nachteile hinnehmen müsste. PhoneGap ist ein so genannter Hybrid: eine Webanwendung und eine native Anwendung zugleich. Dabei bietet PhoneGap über viele Plattformen ein einheitliches und zukunftssicheres API an, mit dem über Webtechnologien auf Telefonfunktionen zugegriffen werden kann. Eine PhoneGap-Anwendung besteht aus einem Webteil und einem nativen Teil. Im Webteil, der lediglich aus einem Browser besteht, befindet sich die HTML5-Anwendung in Form von HTML, CSS und JavaScript-Dateien. Im nativen Teil befinden sich so genannte PhoneGap-Plug-ins, die verschiedene Gerätefunktionen für den Webteil zur Verfügung stellen, wie z. B. die Kamera und das Adressbuch. Diese Plug-ins sind keine Browser-Plug-ins, sondern nativ geschriebener Code für die jeweilige Plattform. Da PhoneGap aber auch eine native Anwendung ist, kann man selber ebenfalls beliebige Plug-ins schreiben. Der native Teil von PhoneGap unterscheidet sich nicht von einer konventionellen App. Das bedeutet, dass man z. B. unter iOS beliebigen Objective-C-Code einer Anwendung hinzufügen kann. Es gibt bereits heute Hunderte von spezialisierten Plug-ins, die z. B. SMS schreiben oder sich mit PayPal integrieren können.

Um nun mit PhoneGap gute Apps zu schreiben, braucht man noch ein Werkzeug, um performante HTML5-Anwendungen zu erstellen. Denn Performance ist auf mobilen Endgeräten wesentlich wichtiger als auf Desktopcomputern. Im Gegensatz zu Desktopcomputern sind Prozessoren auf mobilen Geräten weniger leistungsfähig, die Geräte laufen auf Batterie, und Netzwerkverbindungen sind oft langsam. Nutzer erwarten trotzdem, dass Anwendungen nicht nur gut aussehen, sondern sich auch schnell anfühlen und dabei wenige Ressourcen verbrauchen.

Das Google Web Toolkit (GWT)

GWT ist ein Werkzeug, mit dem sich in Java performante Webanwendungen entwickeln lassen. Der GWT-Compiler kompiliert dabei den Java-Code in JavaScript und nimmt im Zuge dessen viele Optimierungen vor, die manuell in JavaScript sehr aufwändig bis unmöglich wären. GWT spielt bei vielen Google-Produkten eine wichtige Rolle und ist seit 2006 frei verfügbar. GWT ist zwar sehr gut darin, JavaScript-Anwendungen zu optimieren, für die Entwicklung mobiler Apps fehlt allerdings wichtige Funktionalität. gwt-PhoneGap und mgwt ergänzen GWT um genau diese fehlenden Anteile.

gwt-PhoneGap

gwt-PhoneGap stellt, basierend auf der PhoneGap-JavaScript-Schnittstelle, eine Java-Schnittstelle zur Verfügung, die einfach aus GWT genutzt werden kann. Dadurch wird es aus Java möglich, auf alle Device-Features, wie z. B. die Kamera und das Adressbuch, plattformübergreifend zuzugreifen. Zusätzlich kann gwt-PhoneGap das komplette PhoneGap-API im Browser emulieren. Dadurch können PhoneGap-Anwendungen mit GWT komplett in einem Desktopbrowser entwickelt werden, und es werden alle Werkzeuge zum Erstellen und Debuggen nutzbar. Das Projekt ist in der aktuellen Version 1.7 unter Apache-2.0-Lizenz verfügbar.

mgwt

mgwt ergänzt GWT um fehlende Teile für mobile Entwicklung, wie z. B. angepasste Oberflächenelemente, Animationen und Gestenerkennung. mgwt wurde 2009 mit dem Anspruch begonnen, eine Oberflächenbibliothek zu schaffen, die in Aussehen und Performance nativen Anwendungen entspricht. Das Projekt steht unter Apache-2.0-Lizenz und ist in der aktuellen Version 1.1 verfügbar.

In mgwt gibt es für jedes unterstütze Device angepasste Themes, sodass mgwt-Anwendungen jeweils wie ihre Zielplattform aussehen. mgwt legt großen Wert darauf, das Rad nicht neu zu erfinden, sondern bestehende GWT-Paradigmen sinnvoll für mobile Devices umzusetzen. Dazu gehören z. B. eine Integration in GWT MVP und eine Integration in das GWT-Eventsystem. Die gesamte Bibliothek ist sehr stark an GWT angelehnt, sodass erfahrene GWT-Entwickler schnell mit mgwt beginnen können. mgwt unterstützt alle relevanten mobilen Browser für Smartphones und Tablets unter iOS, Android und BlackBerry. Für die Entwicklung werden außerdem auf dem Desktop verschiedene Webkit-Browser wie Safari und Chrome unterstützt. Wenn man sich schnell einen Überblick über vorhandene Oberflächenelemente und Performance verschaffen möchte, empfiehlt sich ein Besuch des Showcases unter [2]. Dort werden viele mgwt-Elemente dargestellt, wie z. B. Buttons, Suchfelder, Slider, Progress Bars, Tab Bars oder Pull-to-Refresh-Panels. Im Showcase kann man sehr gut erkennen, dass Animationen nicht nur unter iOS flüssig und schnell ablaufen, sondern überall, sogar auf älteren Android-Geräten. Der komplette Sourcecode der Showcase-Anwendungen steht unter [3] zur Verfügung.

mgwt legt viel Wert auf Details: Möchte ein User z. B. eine Telefonnummer in einer Anwendung eingeben, so erwartet er eine Zifferntastatur. mgwt bietet verschiedene Input-Elemente, die passende Tastaturen beinhalten und dabei mit dem GWT-Editor-Framework kompatibel sind. Außerdem implementieren mgwt-Oberflächenelemente wichtige GWT Interfaces (wie z. B. HasFocus) und sind somit sehr einfach in einem MVP-Kontext nutzbar.

Performance

Anwendungen dürfen sich nicht langsam oder träge anfühlen, weil sie in HTML5 realisiert sind. mgwt betrachtet Performance als ein wesentliches Feature. Wenn man über Performance redet, gibt es zwei wichtige Bereiche, die man betrachten muss: Start-up- und Runtime-Performance. Die Runtime-Performance gibt im Wesentlichen wieder, wie lange es dauert, bis ein Nutzer das erste Mal etwas mit einer App bzw. Webseite machen kann. Sie spielt eine wichtige Rolle, da sie wiedergibt, wie sich eine App in der Benutzung anfühlt.

Start-up-Performance

Start-up-Performance hängt von mehreren Faktoren ab. Um eine Anwendung zu starten, müssen zunächst alle Dateien (JavaScript, CSS, HTML) heruntergeladen werden. Auf mobilen Geräten spielen dabei Latenz und Übertragungsgeschwindigkeit eine wichtige Rolle. Gibt es in einer Webseite viele kleine Dateien, können hier schnell hohe Wartezeiten entstehen.

Nachdem alle Dateien heruntergeladen worden sind, müssen diese geparst und ausgeführt werden. Wenn eine Anwendung hier nicht passend optimiert ist, können auf einer langsamen Verbindung dadurch schnell mehrere Minuten bis zum Start vergehen.

GWT erzeugt durch seine Optimierungen sehr kleine Anwendungen und hat bereits von Haus aus einen sehr guten Lademechanismus, der auch in langsamen Netzwerken schnellstmögliche Ladezeiten garantiert. GWT-Anwendungen kommen nach dem ersten Laden der Anwendung in der Regel bereits aus dem Cache. Außerdem kann die Größe des initialen Downloads durch so genanntes Codesplitting verändert werden: Die JavaScript-Dateien werden auf mehrere Dateien und somit mehrere Downloads aufgeteilt. Durch sinnvolles Codesplitting kann der Nutzer die Anwendung schon benutzen, während der Rest der Anwendung im Hintergrund heruntergeladen wird.

Mit mobilen Endgeräten kann es aber auch passieren, dass man kurzfristig gar keine Verbindung hat. Aus diesem Grund gibt es mit mgwt die Möglichkeit eines Offline-Starts. mgwt erzeugt im Compile-Prozess automatisiert ein HTML5-Offline-Manifest. Das bedeutet, dass die Anwendung sofort lokal startet und nur, falls der Client online ist, nach einem Update gesucht wird. Damit kann man mgwt-Anwendungen auch nutzen, wenn man z. B. im Flugzeug sitzt, und muss nie auf einen Download warten.

Im Vergleich zu anderen mobilen HTML5-Frameworks hat mgwt eine sehr geringe Downloadgröße. Um eine Anwendung in ihrer Größe gering zu halten, gibt es kein einfaches Mittel. Es ist immer die Summe vieler kleiner und richtiger Entscheidungen. Im Folgenden werden einige dieser Entscheidungen dargestellt.

[ header = Teil 3 ]

Keine Grafiken

Auch bei komplexen Oberflächenelementen kommt mgwt fast immer ohne Hintergrundgrafiken aus (es gibt z. B. Buttons mit Icons). Zum Styling von Oberflächenelementen wird CSS3 genutzt. CSS ist viel kleiner als eine Hintergrundgrafik und kann durch den Browser sogar schneller angezeigt werden.

Minimales Markup

Es gibt UI-Frameworks, die leider dazu neigen, sehr viele DOM-Elemente zu erzeugen. Bei einer hohen Anzahl an DOM-Elementen werden gerade mobile Browser langsam, und Anwendungen fühlen sich damit träge an. mgwt-Oberflächenelemente versuchen immer, mit der minimalen Anzahl an DOM-Elementen auszukommen. Dies führt zu geringerer Downloadgröße und großen Performancegewinnen zur Laufzeit.

Dead Code Removal

GWT kompiliert Code immer für ein bestimmtes Ziel. Dies kann ein Browser oder im Fall von mgwt ein Device sein. Das bedeutet, dass nur Code, der für die jeweilige Anwendung und das jeweilige Device relevant ist, im JavaScript für dieses Device landet. Verwendet eine Anwendung ein bestimmtes Widget nicht, so ist dieser Code nicht in der Anwendung enthalten. Werden bestimmte Funktionen eines Widgets nicht genutzt, sind diese ebenfalls nicht enthalten. Ebenso ist das Styling für z. B. ein Android-Gerät nicht im Kompilat für ein iPhone enthalten. Stylings, die nicht verwendet werden, werden ebenfalls entfernt. Dies führt zu signifikanter Größenreduktion.

Resource Bundles und Themes

In GWT gibt es die so genannten Resource Bundles. Diese bieten die Möglichkeit, CSS und andere Ressourcen dem Compiler bekannt zu machen, sodass dieser Optimierungen vornehmen kann. Er kann z. B. feststellen, dass eine bestimmte CSS-Klasse nicht genutzt wird und diese entfernen. Gleiches gilt für Icons und andere Ressourcen. mgwt Themes basieren auf GWT Resource Bundles, um diese Optimierungen für mgwt-Anwendungen nutzbar zu machen. mgwt Themes sind einfach anpassbar, wodurch mgwt Widgets jedes beliebige Aussehen annehmen können.

Die Abbildungen 1 bis 3 zeigen dieselbe mgwt-Anwendung auf dem iPhone, auf dem iPad und einem Android-Smartphone.

Abb. 1: mgwt auf dem iPhone

Abb. 2: mgwt auf dem iPad

Abb. 3: mgwt unter Android

Runtime-Performance

Ist eine App gestartet, sollte sie sich in der Benutzung angenehm anfühlen und Informationen schnell bereitstellen. Damit sich Anwendungen schnell anfühlen, muss ihr Layout schnell sein. Manche mobile HTML5-Frameworks nutzen JavaScript, um ihr Layout zu erstellen. Dies funktioniert in der Regel folgendermaßen: Es wird ein Resize Listener registriert, der das neue Layout berechnet. Daraufhin wird das DOM aktualisiert, und der Browser zeichnet einen neuen Bildschirminhalt. Das führt dazu, dass zum Beispiel beim Drehen des Geräts jedes Mal das Layout in JavaScript neu berechnet werden muss. Diese Vorgänge dauern so lange, dass es in der Anwendung deutlich sichtbar ist. Um eine schnelle Darstellung zu erreichen, muss das Layout nicht in JavaScript, sondern in nativem Code stattfinden. Dies können Webanwendungen erreichen, dadurch, dass ihr komplettes Layout in CSS deklariert wird. CSS3 bietet mit dem Flexible-Box-Model genau das passende Werkzeug. Müssen mgwt-Anwendungen erneut gezeichnet werden, so geschieht dies sehr schnell, da der Browser in nativem Code bereits alle Regeln berechnen kann.

Für Übergänge zwischen verschiedenen Screens werden auf mobilen Geräten Animationen verwendet. Einige JavaScript-Frameworks nutzen einen Timer, um Animationen anzuzeigen. Damit aktualisieren sie das DOM fortlaufend, woraufhin der Browser neu zeichnet. Dieser Ansatz ist gerade auf mobilen Geräten nicht zu empfehlen, da sehr viel Akkuleistung benötigt wird. Denn dadurch, dass der Browser kein Wissen über die gesamte Animation erhält, kann er nicht optimieren. Realisiert man die Animation hingegen mit CSS3, so wird die Animation deklariert. Das bedeutet, dass dem Browser das Wissen über die gesamte Animation zur Verfügung gestellt wird und er dadurch die Animation optimiert ausführen kann. Mit CSS3 kann dem Browser z. B. mitgeteilt werden: „Bewege ein Element um 400 Pixel in zwei Sekunden“. Hier hat der Browser Optimierungsspielraum und kann diese Anweisung performant umsetzen. Wird eine Animation auf diese Art passend deklariert, wird z. B. unter iOS eine Kachel des aktuellen DOM gezeichnet, und die Kachel wird danach durch die Grafikkarte verschoben. Das DOM muss dadurch nicht neu gezeichnet werden, und die Performance ist identisch zu Animationen, die nativ implementiert sind.

Fazit

Dieser Artikel gibt einen kurzen Einblick in die Entwicklung von mobilen Apps mit GWT. Es ist wichtig zu verstehen, dass Apps nicht das Zukunftsmodell sind, sondern nur der Übergang in die Welt voller digitaler Interaktionen. Genau wie das Web auf Desktopcomputern Programme abgelöst hat, wird es auch auf mobilen Endgeräten Apps ersetzen. Deswegen ist es heute wichtig, für Apps und mobile Webseiten Lösungen zu haben, die nicht doppelten Aufwand erfordern.

Mit den vorgestellten Technologien können App und Webseite aus der gleichen Codebasis entstehen. mgwt ermöglicht es, HTML5-Anwendungen zu entwickeln, die in den Punkten Performance, Aussehen und Bedienkomfort nicht von nativen Anwendungen zu unterscheiden sind. Dabei sind diese Anwendungen plattformunabhängig und in Java entwickelt, wodurch sie eine hohe Zukunftssicherheit bieten.

Für existierende GWT-Projekte, die auf mobile Geräte portiert werden sollen, ist mgwt besonders interessant, da es die gleichen Prinzipen verfolgt wie GWT. Sind Anwendungen in guter Architektur implementiert, können sie durch mgwt mit wenig Aufwand auf alle mobilen Plattformen übertragen werden.

Geschrieben von
Daniel Kurka
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.