Native Cross-Plattform-Apps mit Tabris

Zwei Fliegen mit einer Klappe
Kommentare

Tabris ist das erste Java-Toolkit zur Cross-Plattform-Entwicklung von nativen mobilen Applikationen. Es kombiniert native User Experience mit maßgeschneiderten nativen Bedienelementen und Funktionen. Doch was heißt hier überhaupt nativ?

Ein akutes Problem der heutigen Entwicklung von mobilen Applikationen stellt die Vielfalt der vorhandenen Plattformen dar. Diese sind ein Traum für Endanwender, die auf eine riesige Auswahl an Hardware und Software zugreifen können, jedoch ein Alptraum für Entwickler. Denn sobald eine App für mehr als eine Plattform entwickelt werden soll, stehen die Entwickler vor einem Berg von Herausforderungen. Eine der größten Herausforderungen stellt das benötige Know-how dar. Auch wenn „nur“ die beiden marktführenden Plattformen, iOS und Android, in Betracht gezogen werden, bedeutet das Folgendes:

  • Zwei Programmiersprachen müssen beherrscht werden: Java und Objective-C.
  • Zwei Plattformen mit unterschiedlichen APIs müssen gemeistert werden.
  • Ein (oder zwei) Anwendungsdesign(s), die beide Plattformen berücksichtigen, müssen konzipiert werden.

Zusammengefasst kann gesagt werden, dass der Aufwand für eine mobile Anwendung annähernd mit der Anzahl der zu unterstützenden Plattformen wächst, wenn für jede Plattform separat „nativ“ entwickelt wird. Eine Alternative zu dieser Vorgehensweise stellen Cross-Plattform-Toolkits dar. Hier gibt es derzeit zwei Lager: Zum einen sind dies HTML5-basierte Toolkits, zum anderen Toolkits auf Basis von Cross-Plattform-Kompilierung oder -Interpretation von nativen Bedienelementen und Funktionen.
Die erste Kategorie wird klar von PhoneGap dominiert, wobei zur Darstellung des UIs auf HTML zurückgegriffen wird. Der unbestreitbare Charme dieser Lösung ist die Geschwindigkeit, mit der eine einfache App entwickelt werden kann. In jüngster Zeit hat der Trend zu HTML5 jedoch an Drive verloren, nicht zuletzt wegen unzufriedener Endnutzer und prominenter Fehlschläge wie z. B. von Facebook.
HTML5 kann bei der App-Entwicklung leicht zu einer Last werden, wenn es um die User Experience geht. Mobile Anwendungen sind im Gegensatz zu Webanwendungen normalerweise mit sehr ausgefeilten Bedienelementen (Widgets) ausgestattet. HTML5-Toolkits wie jQuery Mobile bieten zwar ähnliche Features wie die Betriebssystem-Widgets an, benötigen hierzu je Widget aber eine Komposition mehrerer Elemente. Dies führt bei komplexeren Benutzerschnittstellen zu einer Vielzahl an DOM-Elementen, was sich negativ auf die Performance der App auswirken kann. Widget-orientiert oder nicht, die meisten HTML5-UIs können bei der User Experience nicht überzeugen, weil sich die Anwendung in der Regel wie ein Fremdkörper anfühlt. Diese Fremdartigkeit reicht vom Look and Feel der Widgets über ungewohnte Navigationskonzepte bis hin zu den verwendeten Animationen.
Die zweite Kategorie von Cross-Plattform-Toolkits nutzt die Widgets des Betriebssystems und vermeidet so Probleme mit dem Look and Feel. Apps, die mit solch einer Technologie erstellt wurden, sind in Bezug auf ihr Aussehen immer näher am Original als HTML5-UIs. Jedoch gibt es auch bei diesen Lösungen unterschiedliche Herausforderungen.
Für eine gelungene native App müssen nicht nur Widgets mit nativen Mitteln dargestellt werden, auch die Navigation sollte mit den Plattformkonzepten in Einklang stehen. Wenn eine App nativ entwickelt wird, stehen dem Entwickler die jeweiligen Plattformkonzepte zur Gestaltung der Anwendung zur Verfügung. Für iOS ist dies das ViewController-Prinzip und für Android sind es Activities und die ActionBar. Bei den wenigsten Cross-Plattform-Toolkits werden diese Konzepte abstrahiert und auf einen Nenner gebracht!
Genau an diesem Punkt setzt Tabris an. Grundsätzlich fällt Tabris in die zweite Kategorie der Cross-Plattform-Toolkits. Es abstrahiert native Bedienelemente und deren Funktionalität mit einem Java-API. Darunter fallen einfache Elemente wie z. B. Buttons oder Textfelder, aber auch komplexere Elemente wie ein Tree/List oder ein Swipe Widget. Neben den Bedienelementen stellt es auch Java-APIs zur Steuerung der Gerätekamera oder zur Abfrage von Geolocation-Informationen bereit. Ein weiteres, wesentliches Feature von Tabris ist die Abstraktion nativer Navigationskonzepte, genannt Tabris UI.
Das Tabris UI ist sehr einfach gehalten und besteht aus lediglich zwei Kernkomponenten. Diese sind die Typen Page und Action. Die Aufgabe dieser Typen kann am besten anhand eines Screenshots erklärt werden (Abb. 1).

Abb. 1: Zwei Kernkomponenten und ihre Aufgabe

Auf dem Bild wird dieselbe Anwendung auf einem iOS- und einem Android-Gerät dargestellt. Der eigentliche Inhalt der Anwendung ist identisch. Lediglich die Integration in den plattformüblichen Rahmen unterscheidet sich. Der Rot markierte Bereich stellt eine Page dar. Sie ist eine Art Behälter für Bedienelemente. Der Grün markierte Bereich repräsentiert zwei Actions. Konzeptionell stellt eine Action eine Benutzerinteraktion dar, die in Relation zur Anwendung oder zu einer Page steht.
Damit mit diesen Typen eine komplette Anwendung entstehen kann, müssen sie miteinander verbunden werden können. Die erste Verbindung ist der so genannte Flow. Er beschreibt eine Kette von Pages, die lose aneinander gehängt werden können. Damit ein solcher Flow entstehen kann, muss eine Page eine Rolle annehmen. Mögliche Rollen sind Top-Level Page und normale Page. Eine Top-Level Page markiert den Start eines Flows und kann auch nur dort vorkommen. Eine normale Page kann einmal oder mehrmals innerhalb des Flows vorkommen, jedoch nicht am Start. Dies lässt sich einfach anhand von Abbildung 2 erklären.

Abb. 2: Beispiel für einen Applikations-Flow

Das Schaubild beschreibt einen typischen Applikations-Flow. Die Anwendung besteht hier z. B. aus drei Top-Level Pages und mehreren normalen Pages. Ein Benutzer kann nun zwischen den einzelnen Pages navigieren, z. B. über das Betätigen einer Action. Wichtig an dieser Stelle ist, dass Flows in unterschiedlicher Reihenfolge durchlaufen werden können, wie im folgenden Beispiel erläutert wird.
Angenommen, es soll eine „Bücher-Shop-App“ entwickelt werden. Hier ist das zentrale Element der Anwendung ein Buch. Der Benutzer muss also einfach zwischen verschiedenen Büchern navigieren können. Ein Feature, das Amazon zu einigem extra Umsatz verholfen hat, ist das Collaborative Filtering – „Kunden, die dieses Buch gekauft haben, haben auch … gekauft“. Mit dieser Funktionalität kann ein Benutzer von Buch zu Buch navigieren. Die Länge dieser Navigationskette ist dabei nicht beschränkt. Was jedoch gefordert wird, ist, dass eine Rückwärtsnavigation verfügbar ist. Damit ist entweder die Navigation zum letzten Buch oder zurück zur Startseite gemeint.
Diese Art von Navigation ermöglicht der Flow des Tabris UIs. Ein Flow kann eine beliebige, nicht vorgeschriebene Tiefe haben. Eine Rückwärtsnavigation ist jederzeit möglich. Dies erfordert allerdings, dass der Start eines Flows fest definiert ist. Im Bücherbeispiel wäre das z. B. eine Liste der Bestsellerbücher.
Das zweite Konzept, die Action, steht ebenfalls in Verbindung mit den Pages. Typischerweise kapselt eine Action eine Anwendungsfunktionalität. Im Bücherbeispiel könnte dies das Hinzufügen eines Buchs zum Warenkorb oder eine Suche sein. Diese beiden Beispiele beschreiben auch direkt die möglichen Action Scopes: eine Action hat entweder einen Page- oder globalen Gültigkeitsbereich. Sie ist also mit einer Page oder der ganzen Anwendung verbunden. Eine Suche ist ein Beispiel für eine globale Action, da sie von überall in der Anwendung erreichbar sein sollte. Im Gegensatz dazu soll das Hinzufügen eines Buchs zum Warenkorb natürlich nur zur Verfügung stehen, wenn man sich auch auf einer Bücher-Page befindet. Ein kompletter Anwendungs-Flow für einen Buchshop könnte aussehen wie in Abbildung 3.

Abb. 3: Anwendungs-Flow eines Buchshops

In den Screenshots wird dieselbe Anwendung für Android und iOS dargestellt. Die App besteht aus drei Top-Level Pages: All Books, Popular und Favorites. Jede dieser Top-Level Pages stellt eine Liste von Büchern dar. Durch die Auswahl eines der Bücher wird es in einer Detailansicht dargestellt. Von dort gelangt man entweder zu weiteren Büchern oder in eine Lesevorschau. Der Code dieser Anwendung ist auf GitHub verfügbar.

Aufmacherbild: Green Long Legged Fly von Shutterstock / Urheberrecht: Bruce MacQueen

[ header = Widgets ]

Widgets

Nachdem wir uns ausführlich mit den Navigationskonzepten des Tabris UI befasst haben, wollen wir uns auch noch mit den Widgets beschäftigen, die den eigentlichen Teil der Applikation ausmachen. Tabris setzt dabei auf das API des bewährten Cross-Plattform-Widget-Toolkits SWT (Standard Widget Toolkit). SWT ist leichtgewichtig, weit verbreitet, Open Source und es gibt mit JFace ein leistungsfähiges MVC-Framework. Die Listenansicht für den oben dargestellten Bookstore kann z. B. mit wenigen Zeilen Code implementiert werden (Listing 1).

public class BooksListPage implements Page {

  public void create( Composite parent, final UIContext context ) {
    TreeViewer viewer = new TreeViewer( parent, SWT.V_SCROLL );
    viewer.setContentProvider( new BooksContentProvider() );
    viewer.setLabelProvider( new BooksLabelProvider() );
    addBookSelectionListener( context, viewer );
    ...


public class BooksContentProvider implements ITreeContentProvider {

  public Object[] getElements( Object inputElement ) {
    return books.toArray();
  }
  ...

public class BooksLabelProvider implements ITableLabelProvider {

  public String getColumnText( Object element, int columnIndex ) {
    String result = null;
    if( columnIndex == 0 ) {
      if( element instanceof Book ) {
        result = ( ( Book )element ).getTitle();
  ...

Neben der Prägnanz des API sind die Verfügbarkeit von Dokumentation, Beispielen und Unterstützung in der Eclipse-Community weitere Vorteile der Nutzung von SWT. Der Umgang mit großen Datenmengen, die Modularisierung der Anwendung mit OSGi und die Integration von modellbasierten Benutzerschnittstellen gehören so zum Standardrepertoire von Tabris.
Die einfache Integration mit etablierten Java-Technologien wird durch die zugrunde liegende Architektur ermöglicht. Die Thin-Client-Architektur von Tabris ist durchaus vergleichbar mit einem Webserver und einem Webbrowser. Die Logik einer Webanwendung wird auf der Serverseite ausgeführt. Das dazugehörige UI wird in HTML ausgeliefert und in einem Webbrowser gerendert. Bei Tabris wird die Anwendungslogik ebenfalls auf einem Server, z. B. einem JEE-Application-Server, ausgeführt. Ein nativer Client, beispielsweise ein Tablet, ist mit dem Server verbunden und empfängt die Repräsentation des UI in Form von JSON. Doch anstelle eines HTML-basierten UI, rendern die Tabris-Clients native Widgets und erzeugen so eine plattformspezifische User Experience.
Die mobilen Clients benötigen, wie Webanwendungen, immer eine Verbindung zum Server. Für manche Applikationen ist das eine nicht akzeptable Einschränkung, für andere kann dies aber ein relevanter Vorteil sein. Daten werden nämlich immer nur zur Erzeugung der Oberfläche übertragen. Die Clients führen keinerlei Anwendungslogik aus, sie dienen lediglich der Darstellung des UIs. Dies bedeutet zudem, dass keine sensiblen Anwendungsdaten oder Algorithmen auf den mobilen Endgeräten gespeichert werden und so implizit vor Diebstahl oder anderweitigem Verlust geschützt sind.
Ein zusätzlicher, interessanter Vorteil der Architektur und des darunter liegenden offenen Kommunikationsprotokolls ist die einfache Anbindung von weiteren Clients. So existieren z. B. neben den mobilen Clients auch ein Open-Source-Web- und Desktopclient. Eigene Clients, beispielsweise basierend auf Windows CE oder für limitierte Embedded-Geräte wie Registrierkassen, lassen sich mit einem reduzierten Widget-Set einfach umsetzen und ermöglichen dadurch neue Anwendungs- und Migrationspfade.
Tabris steht ab April in Version 1.0 zur Verfügung. Die Serverbestandteile sowie der Web- und Desktopclient stehen unter der Eclipse Public License und können frei in kommerziellen Produkten eingesetzt werden. Lediglich die mobilen Clients stehen unter einer kommerziellen Lizenz. Zum persönlichen Testen und Evaluieren der vielfältigen Möglichkeiten von Tabris können mobile Clients auf der Projektwebseite heruntergeladen werden.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -