App-Entwicklung mit Sencha Touch

RIA goes Mobile
Kommentare

Wer nicht für jede mobile Plattform eine eigene native App entwickeln möchte, kommt an Webapplikationen für Smartphones nicht vorbei. Rich Internet Applications (RIA) bieten den von nativen Apps gewohnten Bedienungskomfort und sind nach dem Start gegen Netzabbrüche gefeit, da der Client lokal auf dem Endgerät abläuft. Auch der Entwickler profitiert von diesem Ansatz, denn RIA-Frameworks wie Sencha Touch bieten hohe Qualität und Produktivität in Kombination mit einem Programmiermodell, das einfach Spaß macht. Dieser Artikel beschreibt das Konzept und die Implementierung einer Sencha Touch App und bietet einen leichten Einstieg in die Arbeit mit dem Framework.

Das Mobile Web wächst explosionsartig. Nach neuesten Statistiken wird schon im Jahr 2013 die Zahl der mobilen Internetnutzer die der stationären übertreffen. Künftig werden viele Nutzer vielleicht sogar überhaupt keine Desktop-Rechner mehr nutzen. Will man also seine Anwender mit Applikationen und Services erreichen, so gilt es, mobile Plattformen zu berücksichtigen. Aber welche Plattform soll es sein? iOS oder Android, Windows Phone oder Symbian? Es scheint an der Zeit, eine Architektur zu entwickeln, die all diese Systeme unterstützt. Denn nur so kann man wirklich alle Anwender erreichen. Die native App ist in diesem Fall keine Lösung, denn eine native App ist immer – mit allen Vor- und Nachteilen – auf eine spezifische Plattform zugeschnitten. Sieht man von speziellen Anforderungen wie Echtzeitperformance und umfangreicher lokaler Datenablage ab, ist eine native App auch gar nicht notwendig, denn eine alternative Architektur, die alle Plattformen unterstützt, ist längst zur Hand: das Web. Allerdings sind Webanwendungen in den letzten Jahren in Verruf geraten: Sie sind umständlich zu bedienen, stören den Benutzer durch Ladezeiten und häufigen kompletten Seitenaufbau und haben Schwierigkeiten mit der Verwaltung großer Datenmengen durch das Frontend. Ja, genau – eine Standardwebanwendung kann einer nativen App nicht das Wasser reichen. Dazu braucht man eine Webanwendung, die sich wie eine native Anwendung bedienen lässt, eine leichte Integration mit Medien aller Art erlaubt und mit der auch auf lokale Devices der Plattform zugegriffen werden kann. Genau diese Eigenschaften haben Rich Internet Applications (RIA).

Rahmenwerke

Das Kürzel RIA wird häufig mit Flash und Flex, zwei Technologien aus dem Hause Adobe, verknüpft [1]. Längst gibt es aber viele andere Frameworks, die schon deswegen interessanter als Flex sind, weil sie auch auf den Produkten der Firma Apple laufen. Die meisten dieser Frameworks basieren auf JavaScript. Das bietet große Vorteile, da JavaScript in jeden Browser eingebaut ist und somit keine Plug-ins (wie z. B. bei Flex) notwendig sind. Darüber hinaus halten gerade die mobilen Browser wie Chrome und Safari, die auf der Rendering Engine WebKit [2] basieren, eine sehr gute JavaScript- und HTML5-Unterstützung [3] bereit und punkten durch neue Engines wie V8 auch mit einer hervorragenden Performance bei der Ausführung von JavaScript-Code. Also bieten sich JavaScript-basierte Frameworks für mobile RIAs geradezu an. Die bekanntesten und am weitesten gediehenen dieser Frameworks sind Sencha Touch [4] und jQuery Mobile [5]. Dieser Artikel stellt Sencha Touch anhand eines ausführlichen Beispiels vor. Aus Platzgründen gehen wir nicht auf den Serverteil ein und verweisen auf die im entsprechenden Kasten „RIA-Architektur mit Ext JS und Jersey“ und in [6] ausführlich beschriebene sowie in Abbildung 1 illustrierte Architektur.

Abb. 1: RIA-Architektur mit Ext JS und Jersey

RIA-Architektur mit Ext JS und Jersey

Vor der Auswahl von Sencha Touch konnten wir umfangreiche Erfahrungen mit dem Vorläufer Ext JS in mehreren Projekten des Gesundheitswesens sammeln [6]. Die Anwendungen bieten für Krankenhäuser, Pflegedienste und Krankenkassen sektorübergreifenden Zugriff auf gemeinsame Projekt- und Abrechnungsdaten in der so genannten „Integrierten Versorgung“ [7].

Wie Sencha Touch ist auch Ext JS ein auf JavaScript basierendes RIA-Framework. Der Client einer RIA existiert zur Laufzeit vollständig im Browser, sodass ein Nachladen ganzer Seiten oder anderer Bestandteile des GUI vom Server entfällt. Die bei Webanwendungen übliche Zerlegung des GUI-Flows in einzelne, aufeinanderfolgende Seiten entfällt. Eine Kommunikation zwischen Client und Server gibt es nur dann, wenn der Client Daten vom Server benötigt oder wenn er Geschäftslogik auf dem Server anstoßen will. Zusätzlich bietet das Framework eine umfangreiche Bibliothek an Widgets und GUI-Elementen mit einem sehr gut dokumentierten API. Gerade diese Bibliothek hebt Ext JS auch von Konkurrenten wie jQuery [8] oder Vaadin [9] ab und erlaubt es, Anwendungen zu bauen, die mit Komfort und Nutzungserlebnis einer nativen Anwendung nahe kommen.

Für die Client-Server-Kommunikation bietet es sich an, auf REST Web Services mit JSON als Transportprotokoll zurückzugreifen, da Ext JS von Haus aus beides unterstützt. Für einen in Java realisierten Server kann z. B. das Framework Jersey [10] die Bereitstellung der Web Services übernehmen. Jersey implementiert den JAX-RS-Standard für RESTful Web Services und erlaubt es, durch simple Annotationen Java-Klassen in Serviceklassen umzuwandeln. Eine Alternative stellt z. B. Apache CXF dar.

Die so aufgebaute serviceorientierte Architektur (SOA) hat viele Vorteile. Client und Server lassen sich parallel entwickeln und testen. Über die Services gibt es eine saubere Schnittstelle zur Geschäftslogik. Das GUI wird deskriptiv in JavaScript beschrieben und hält den Java-Code sauber. So wird einer Vermischung von Präsentations- und Geschäftslogik vorgebeugt und die Wiederverwendung insgesamt erleichtert.

Fragen über Fragen

Kundenveranstaltungen mit Vorträgen und Workshops, wie z. B. das A:gon-Solutions-IT-Forum [11], sind aufwändig und kostspielig in der Durchführung. Umso wichtiger ist es, dass man mit Format, Inhalt und Organisation die Bedürfnisse und Interessen der Besucher richtig adressiert. Dazu sollte man die Kunden selbst fragen. Für diese Zielstellung ist eine App auf einem mobilen Endgerät ideal, denn man kann den Besucher bitten, gleich während der Veranstaltung vor Ort oder auf dem Nachhauseweg sein Feedback abzugeben. 

Im Wesentlichen sollen dem Nutzer einige Fragen gestellt werden, die dieser dann mit wenigen „Taps“ beantwortet. Jede Frage und die dazu möglichen Antworten umfassen jeweils eine Page der App, füllen also das GUI des Smartphones vollständig aus. Bei den meisten Fragen ist ein vierfach abgestuftes Ranking gefragt (Abb. 2), bei manchen Fragen auch eine Mehrfachauswahl. Auf der letzten Seite soll der Nutzer noch seinen Namen eingeben. Die Client-Server-Kommunikation gestaltet sich denkbar einfach: Beim Start der App werden die lokal benötigten Dateien vom Browser geladen und am Ende wird das Ergebnis per Web Service zum Server der Anwendung übermittelt. Ein Zwischenspeichern ist nicht vorgesehen, da die benötigte Zeit sehr kurz ist und die App jederzeit wieder gestartet werden kann.

Abb. 2: Die App stellt eine Frage

Aufmacherbild: smartphone; social media, communication in the global computer networks. von Shutterstock / Urheberrecht: 3DStyle [ header = Seite 2: Situation erkannt ]

Situation erkannt

Ein Benutzer einer Mobilanwendung befindet sich in einer besonderen Nutzungssituation: Er sitzt nämlich nicht ungestört in seinem ruhigen Büro und hat beliebig viel Zeit. Nein, wenn man aktuellen Meinungsumfragen Glauben schenkt, sind manche Nutzer mit ihrem Smartphone im Bad unterwegs, fahren Fahrrad oder sitzen auf der Tribüne im Fußballstadion. Daher muss die Bedienung einer mobilen Anwendung sehr einfach und narrensicher sein. Außerdem muss der Nutzer seine Aktionen jederzeit wiederholen und korrigieren können.

Beim Design unserer App haben wir deshalb auf kleine Checkboxen und unübersichtliche Auswahllisten verzichtet. Auch Scrolling ist nicht geplant. Alle Buttons sind besonders groß und eindeutig beschriftet (Abb. 2). Der Benutzer kann per Swipe oder per Navigationsbutton jederzeit zwischen den einzelnen Seiten hin- und herwechseln (Abb. 3) und einmal gewählte Antworten ändern. Sogar ein Restart der ganzen App ist mit einem „Tap“ möglich. Der schwierigste Bedienvorgang ist die Eingabe des Namens. Tatsächlich ist aber der Name für die Auswertung nur von sekundärer Bedeutung, und auch die Abgabe von anonymem Feedback soll möglich sein. Falls der Benutzer also keinen Namen eingibt oder nur Initialen oder einen Alias, spielt das letztlich keine Rolle.

Abb. 3: Der Dialogfluss in der App

In Touch mit Sencha

Sencha Touch basiert auf der populären und weit verbreiteten RIA-Bibliothek Ext JS. Beide Frameworks verwenden ausschließlich leichtgewichtige und offene Webstandards wie HTML5 und JavaScript. Das grundlegende Design und das ausgereifte Programmiermodell [12] von Ext JS wurden übernommen, ebenso die Struktur der GUI-Klassen und deren Funktionen. Die Bibliothek wurde komplett überarbeitet und speziell für die Ausführung auf mobilen Browsern adaptiert. Insbesondere wurde eine umfangreiche Unterstützung für Swipe- („Wischen“) und Touch-Events hinzugefügt. Man merkt es Sencha an, dass bereits mehrere Jahre intensiver Entwicklungsarbeit in dieses Framework investiert wurden. Bereits in der aktuell vorliegenden Version 1.1 ist es ausgereift und vollständig und bietet einen sehr aufgeräumten Klassenbaum, der dem Nutzer die Orientierung erleichtert. Auch die guten Integrationsmöglichkeiten für AJAX, Web Services und die Transportprotokolle XML und JSON wurden von Ext JS übernommen. Die Arbeit mit dem Framework geht einem Entwickler mit JavaScript-Erfahrung sehr leicht von der Hand. Das Programmiermodell bewährt sich auch im mobilen Umfeld, und mit wenigen Zeilen Code kann man sehr mächtige Oberflächen implementieren.

Die Spezialisierung auf mobile Browser bringt es mit sich, dass Sencha-Anwendungen nicht mehr auf Firefox oder IE lauffähig sind. Wer seine Apps lokal testen will, tut also gut daran, Safari oder Chrome [13] zu installieren. Unsere Erfahrung zeigt, dass die Darstellung und auch das Verhalten der App in Chrome und Safari dem Original bereits sehr nahe kommen. Insbesondere um aber auch die Bedienbarkeit zu prüfen, ist ein Test mit echten mobilen Geräten ohne Alternative. Ein ungelöstes Problem ist nach wie vor das Debugging der App auf dem mobilen Gerät. Auf dem Desktop kann man dazu die Developer Tools [14] von Safari verwenden, denn Firefox ist in diesem Fall ja ausgeschlossen.

Idealerweise nutzt man zum Testen Geräte unterschiedlicher Hersteller und sowohl Tablets als auch Smartphones. Als weitere Testwerkzeuge bieten sich die diversen Emulatoren der Handyhersteller an (eine Liste findet sich in [15]). All diese Systeme sind aber sperrig zu bedienen und im Vergleich mit echten Smartphones eher langsam, sodass das Arbeiten mit ihnen keine Freude bereitet.

Die Implementierungsarbeit mit Sencha stützt sich durchgängig auf die objektorientierten und funktionalen Fähigkeiten von JavaScript. Objekte werden mit new erzeugt und mit einem JSON-Konfigurationsobjekt [16] initialisiert (Listing 1). Variablen können auf Funktionen verweisen, die häufig anonym definiert werden, was sehr kompakten Code ermöglicht. Typisch für Sencha ist die Verwendung von Arrays wie items, um Kindobjekte in einer GUI-Hierarchie einzufügen – also z. B. Eingabeelemente, die in einem Panel angezeigt werden sollen. An dieser Stelle findet sich ein Unterschied zu Ext JS: Es gibt kein Array mit dem Namen buttons. Häufig lässt sich daher Sencha Code nicht 1:1 auf Ext JS übertragen.

var App = new Ext.Application({  
    name    : 'FeedbackApp',
    defaultUrl  : 'index.html',
    launch    : function () {
      FeedbackApp.ViewportClass = Ext.extend(Ext.Panel, {
        fullscreen: true,
        items: [ carousel ] // carousel defined elsewhere
      });
      this.viewport = new FeedbackApp.ViewportClass();
    }
});

[ header = Seite 3: Aufbauphase ]

Aufbauphase

Die Architektur unserer App folgt der Empfehlung von Sencha und besteht daher zunächst aus einer Instanz der Klasse Ext.Application (Listing 1). Beim Anlegen der Instanz übergeben wir u. a. für die Property name den Wert FeedbackApp. Im Hintergrund werden durch das Framework daraus eine globale Variable mit Namen FeedbackApp und verschiedene Namespaces definiert, unter anderem FeedbackApp, FeedbackApp.views, FeedbackApp.models und FeedbackApp.controllers. Die Benennung der Namespaces zeigt, dass Sencha Unterstützung für das Design-Pattern MVC (Model View Controller) mitbringt. Die Nutzung der MVC-Funktionen lohnt sich vor allem für stark datenlastige Apps, die auch viel Datenaustausch zwischen Client und Server durchführen. Beides ist bei uns nicht der Fall, weshalb wir an dieser Stelle auf die vollständige Nutzung von MVC verzichten. Wir implementieren jedoch nachfolgend alle unsere GUI-Objekte im Namespace Feedback.views.

Die Methode launch der Klasse Ext.Application bildet den Einstiegspunkt der Anwendung. Das Framework ruft diese Methode nur einmal auf, nämlich sobald die betreffende Seite komplett vom Browser geladen wurde. Daher überschreiben wir diese Methode und hinterlegen dort sämtlichen Initialisierungscode. Zunächst benötigen wir einen Viewport, d. h. ein Objekt, das als Rahmen für alle andern GUI-Elemente dient. Wir implementieren ihn als Instanz der Klasse Ext.Panel und setzen die Property fullscreen auf „true“. Sodann weisen wir ihn den Variablen FeedbackApp.Viewport zu. Alle weiteren anzuzeigenden GUI-Elemente werden jetzt als Kinder dem Viewport hinzugefügt.

Als oberstes Element erzeugen wir eine Instanz von Ext.Carousel und fügen sie als Kind in den Viewport ein. Diese Klasse erlaubt das Navigieren durch „Swipe“, d. h. der Benutzer kann zwischen den enthaltenen Seiten durch das Streichen über das Display wechseln. Diese Option ermöglichen wir dem Benutzer durch das Carousel zusätzlich zur Buttonnavigation. Es ist leider nicht möglich, mit einem Carousel nur einen Teilbereich des Bildschirms navigierbar zu machen. Jedes Swipe Event ersetzt die komplette Page durch eine neue.

Insgesamt müssen wir drei verschiedene Seitentypen implementieren: Startseite (Landing Page), Fragenseite und Abschlussseite (für die Namenseingabe). Die Fragenseiten, die jeweils eine Frage darstellen und mögliche Antworten präsentieren, haben eine generische Struktur: Sie werden als Klasse nur einmal implementiert und dann mehrfach erzeugt, wobei Unterschiede über Parameter gesteuert werden.

Für diese Seiten implementieren wir jeweils eine Klasse, die sich von Ext.Panel ableitet. Dazu verwenden wir die Framework-Methode Ext.extend, mit der wir sowohl Attribute und deren Werte als auch Methoden und einen Konstruktor implementieren können (Listing 2). Werte, die später bei der Instanziierung der Klassen übergeben werden sollen – wie z. B. die darzustellende Frage – müssen als Parameter des Konstruktors genannt werden. Listing 2 zeigt dies anhand des Fragetextes, der sich in config.text verbirgt und der einem Sub Panel über dessen HTML Property übergeben wird. Das config-Objekt wird auch an den Konstruktor des RatingPanel weitergegeben, das die Buttons für die Antworten enthält, damit auch die möglichen Antworten parametriert werden können.

FeedbackApp.views.QuestionsPanel = Ext.extend(Ext.Panel, {    
    constructor: function(config) {
      var rating = new FeedbackApp.views.RatingPanel(config);
      this.items = [
        { xtype: 'panel', margin: "10 5 5 10", html: config.text }
        { xtype: 'panel', margin: "5 5 5 5", items: [ rating ] }
      ];
      this.title = config.title;
      FeedbackApp.views.QuestionsPanel.superclass.constructor.call(this, config);
    }
});

Schließlich haben wir also für jede Page der App eine Klasse, die wir einmal oder – im Falle der Fragenseite – mehrfach instanziieren. Die so erzeugten Panel-Objekte fügen wir dann über den schon bekannten Mechanismus der items als Kindobjekte in das Carousel ein.

Es gibt einige Objekte, die mehrfach in der GUI vorkommen, wie z. B. das Info-Panel (in dem sich der Infobutton befindet) oder auch das Image-Panel, das zur Darstellung des Unternehmenslogos in der linken oberen Ecke dient. Um Codeduplizierung zu verhindern, implementieren wir auch für diese Objekte entsprechende Klassen und fügen dann jeweils eine andere Instanz in die verschiedenen Seiten ein. Listing 3 zeigt den Code für das Image-Panel. Das Logo wird dabei einfach über die HTTP Property per img-Element eingefügt. Um sicherzustellen, dass der Browser das Bild auch rechtzeitig geladen hat, wird in der index.html dieses Bild ebenfalls eingefügt – dort aber mit der Höhe 0 Pixel, um es unsichtbar zu machen.

FeedbackApp.views.AgonImagePanel = Ext.extend(Ext.Panel, {
    layout: 'fit',
    html: '<img height="28px" src="icons/agon-sw.gif" />'
}); 

Knöpfchen drücken

Unsere App ist nun nahezu fertig. Es fehlt nur noch das wichtigste Element, nämlich die Buttons, mit denen der Benutzer die Antworten auf die Fragen auswählen soll. Dazu implementieren wir auf Basis der Sencha-Klasse Ext.Button eine separate Klasse RatingButton, bei der wir nur noch geringe Anpassungen machen müssen. Unser RatingButton soll größer sein als normale Buttons. In der x-Richtung soll er sich maximal ausdehnen, während wir für die Höhe einen Wert von 50 Pixeln wählen. Er soll sich grün färben, wenn der Benutzer ihn anwählt, und wieder grau werden, wenn er abgewählt wird. Damit simulieren wir eine CheckBox, bleiben aber bei der bequemen Bedienbarkeit eines normalen Buttons. Listing 4 zeigt den Sourcecode. Das gewünschte Verhalten erreichen wir, indem wir als Handler eine Funktion implementieren, die den aktuellen Status des Buttons im Attribut selected speichert und entsprechend dessen Wert die Farbe des Buttons setzt. Dazu nutzen wir die bereits in Sencha vorhandene CSS-Klasse x-button-confirm, die den Button grün einfärbt.

FeedbackApp.RatingButton = Ext.extend(Ext.Button, {
    ui: 'round', height:'50px', selected: false,
    handler: function() {
      if (this.selected == false) { this.select(); } else { this.deselect(); }
    },
    deselect: function() {
      this.el.removeCls('x-button-confirm'); this.selected = false;
    },
    select: function() {
      this.el.addCls('x-button-confirm'); this.selected = true;
    }
}); 

Die Texte für die Buttons werden dem Panel, das die Buttons enthält, im Konstruktor übergeben. Dieser iteriert dann über alle Elemente und setzt die entsprechenden Texte, sodass die Erzeugung einer kompletten Frageseite sich dann so generisch gestaltet wie in Listing 5 zu sehen.

var question3Panel = new FeedbackApp.views.QuestionsPanel({
  title : 'Frage 3', 
  text : 'Wie bewerten sie Verpflegung und Catering?',
  texts : ['Sehr gut', 'Gut', 'Weniger gut', 'Schlecht']
}); 

[ header = Seite 4: Erfahrungspunkte ]

Erfahrungspunkte

Der Client unserer App ist nun fertig und kann ausgeführt werden. Dazu kopieren wir das gesamte Verzeichnis in das /webapps/-Verzeichnis eines Tomcat. Die Struktur der Webapplikation ist so gewählt, dass auf oberster Ebene lediglich die Einstiegsdatei index.html zu finden ist. Darunter liegt das Verzeichnis /app/, in dem sich alle weiteren JavaScript-Dateien befinden, die aus index.html heraus geladen werden. Das Framework Sencha ist im Ordner /touch/ zu finden. Abbildung 4 stellt die Struktur der Verzeichnisse dar.

Abb. 4: Verzeichnisstruktur der App

Rufen wir nun mit dem mobilen Browser unseren URL (im Testfall http://localhost:8080/feedback) auf, so erscheint die Landing Page der App (Abb. 5). Beim Test funktioniert die App sehr gut und sieht sowohl auf iOS als auch auf Android nahezu identisch aus – die Abweichungen sind marginal. Leider scheint Sencha die Größe der Message Box unter Android nach dem ersten Aufruf nicht mehr zu ändern, sodass Text abgeschnitten wird, wenn die zweite Box längeren Text enthält als die erste. Man muss also aufpassen, dass man das Fenster beim ersten Mal bereits groß genug wählt – im Zweifel durch Einfügen einiger Leerzeilen. Auf Smartphones in vertikaler Orientierung sowie auf Tablets sieht die App bereits sehr gut aus und lässt sich durchgängig flüssig bedienen. Ein Durchlauf ist in wenigen Sekunden möglich.

Abb. 5: Die Startseite der App

Noch nicht berücksichtigt ist die Landscape-Orientierung bei Smartphones. Wird das Telefon horizontal gekippt (Abb. 6), bleibt in der Höhe nicht mehr genügend Platz für alle vier Buttons der Antworten. Um das zu korrigieren, verwenden wir einen Mechanismus von Sencha, mit dem man Layouts abhängig von der Orientierung des Bildschirms darstellen kann. Dazu wird bei der Application Instanz die Property profiles gesetzt (Listing 6). Hier definieren wir separate Namen für jedes Profil, das wir separat handhaben wollen. Für jedes Profil wird eine Funktion implementiert, die einen Boolean zurückgibt und somit auswertet, ob dieses Profil gerade aktuell ist. Sencha garantiert allerdings nicht, dass immer nur eine der Funktionen „true“ zurückliefert – für die korrekte Logik muss man also selber sorgen.

Die Profile können nun bei beliebigen Objekten abgefragt werden. Dazu implementiert man jeweils eine Methode mit der Signatur setProfile(profile). Über den Parameter kann man dann das aktuelle Profil abfragen und entsprechend darauf reagieren.

profiles: {
    portraitPhone: function() {
        return Ext.is.Phone && Ext.orientation == 'portrait';
    },
    landscapePhone: function() {
        return Ext.is.Phone && Ext.orientation == 'landscape';
    },
    portraitTablet: function() {
        return !Ext.is.Phone && Ext.orientation == 'portrait';
    },
    landscapeTablet: function() {
        return !Ext.is.Phone && Ext.orientation == 'landscape';
    }
} 

Abb. 6: Horizontale Darstellung

Der nächste Level

Den Serverteil unserer App implementieren wir mit Java und nutzen Jersey, um einen Web Service zur Verfügung zu stellen. Diesen Web Service ruft unser Sencha-Client nach Eingabe des Namens auf und übergibt ihm die Werte der selektierten Buttons und den Namen des Benutzers. Der Server speichert diese Daten in einer Datenbanktabelle, die anschließend manuell ausgewertet werden kann. Jetzt ist die App vollständig einsatzbereit. Vor jedem Kundenevent müssen nur noch die Fragen und Antworten angepasst werden, was zurzeit noch den Eingriff in den Sourcecode bedeutet. Hier könnte man sich vorstellen, in Zukunft eine kleine Administrationsoberfläche zu entwickeln, die dann aber nicht auf einem Smartphone laufen sollte.

Eine zusätzliche sinnvolle Erweiterung ist die Kombination mit dem Framework PhoneGap [17]. PhoneGap erlaubt den Zugriff verschiedener Devices des mobilen Geräts per JavaScript. So kann man z. B. beim Drücken bestimmter Buttons Vibrationsfeedback geben oder die aktuelle Position des Benutzers per Geolocation auslesen.

Wie funktioniert PhoneGap?

PhoneGap ist eine Open-Source-Software, die es ermöglicht, mobile Webapplikationen als native App auszuliefern und auszuführen. Der Ansatz dabei ist, die Webanwendung mit der Runtime eines Browsers so zu verbinden, dass beim Start der App der Browser aktiviert und die Webanwendung als dessen Startseite aufgerufen wird. PhoneGap verwendet dazu eine spezielle Version des mobilen Browsers Safari. Da der Browser auf der mobilen Plattform als native Anwendung gestartet wird, kann der Browser wie jede andere native App auf die Devices des Smartphones zugreifen (z. B. Adressbuch und Beschleunigungssensor). Über speziell entwickelte und gut dokumentierte JavaScript-APIs [18] kann die mit dem Browser ausgelieferte Webanwendung dann auf die nativen Devices zugreifen.

Für die Entwicklung bringt PhoneGap ein Build-Werkzeug mit, das die Webanwendung „kompiliert“ und so zusammen mit der Browser-Runtime eine neue native App baut. Eine Alternative stellt der Build in der Cloud dar, den PhoneGap seit 2011 anbietet.

Mit diesem Ansatz ist PhoneGap ohne Wettbewerb und die einzige Möglichkeit, Webanwendungen auf über sieben mobilen Plattformen nativ auszuliefern. Das funktioniert deshalb so gut, weil unter anderem RIM, Microsoft, IBM und Adobe das Projekt unterstützen. Nach den Aussagen der Entwickler ist es das Ziel von PhoneGap, sich selbst überflüssig zu machen. Dahinter steht die Idee, dass in Zukunft mehr und mehr native Funktionen auch per HTML5 – und somit von einer „normalen“ Webanwendung – verwendbar sein werden. Bis dahin wird man des Öfteren noch PhoneGap bemühen müssen.

In einer weiteren Version wird auch die Anpassung des GUI an den Corporate-Identity-Standard von A:gon [11] auf der Agenda stehen. Sencha erleichtert das Erstellen eigener so genannter „Themes“ durch die Trennung in frameworkspezifische und App-spezifische Klassen. Eine Neuerung ist der Einsatz des Präprozessors SASS [19] zur Generierung der CSS-Dateien, was eine prägnantere und klarere Formulierung der Styles ermöglicht.

Sencha steht kurz vor der Veröffentlichung der Version 2, die gegen Ende 2011 erwartet wird. Mit der neuen Version sollen die Klassensysteme und Frameworkeigenschaften von Ext JS und Sencha 4 vereinheitlicht werden. Denn im Moment ist es nicht möglich, den Sourcecode einer Sencha-App unter Nutzung von Ext JS als Webapplikation zu betreiben. Das Ziel muss es aber sein, mit einer Codebasis möglichst alle Kanäle bedienen zu können.

Das Beste zum Schluss: Sencha Touch ist zurzeit auch bei Nutzung in Unternehmen kostenfrei. Es fallen weder Download- noch Lizenzgebühren an. Der dafür gebotene Umfang ist riesig und die Qualität besser als bei manchem Kaufprodukt. Abgesehen von den genannten Stolpersteinen und Verbesserungsmöglichkeiten hat sich Sencha für uns als stabile Basis für die App erwiesen. Nicht nur ist die Produktivität sehr hoch und das Ergebnis kann sich sehen lassen. Zusätzlich macht die Arbeit mit dem Framework einfach Spaß, denn das Programmiermodell ist durchdacht, und im Web finden sich viele Ressourcen und eine gute Dokumentation. Daher kann jedem, der eine mobile Webapplikation plant, Sencha Touch nur wärmstens empfohlen werden.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -