Eclipse magazin 4_12_cross_plattform_mobile_development_friese

12 www.eclipse-magazin.deeclipse magazin 4.12

Cross-Platform Mobile DevelopmentTitelthema

von Peter Friese

Dank des plattformunabhängigen Aufbaus sollte Eclipse sich als integrierte Entwicklungsumgebung für die platt-formübergreifende Entwicklung von mobilen Anwen-dungen eigentlich sehr gut eignen. So wundert es auch nicht, dass eine beachtliche Anzahl an Tools und Frame-works existiert, die in der einen oder anderen Form von Eclipse Gebrauch machen. Einige sehr weit verbreitete Frameworks sind allerdings erst spät in ihrem zugege-benermaßen noch nicht sehr langen Produktzyklus zu Eclipse gewechselt.

Mobile Apps – eine TaxonomieUm einen besseren Überblick zu gewährleisten, wollen wir die verschiedenen Tools und Frameworks nach ih-ren architektonischen Prinzipien gliedern. Letztendlich ist auch die beste Entwicklungsumgebung nur ein Werk-zeug, das beim ef�zienten Umgang mit dem entspre-chenden Framework helfen soll. Ausschlaggebend für die Auswahl einer Implementierungstechnologie sollten daher immer die konkreten Anforderungen des jeweili-

gen (Kunden-)Projekts sein. Bei den Implementierungs-techniken für mobile Anwendungen unterscheiden wir die folgenden grundsätzlichen Architekturvarianten:

• Native Implementierung• Mobile Website/Server-side Web• Web-Apps mit nativem Look and Feel/Client-side Web• Hybrid-Apps• Interpretierte Apps• Terminal-Apps• Cross-Compiling/Generativer Ansatz

Zunächst ist ein kurzer Blick auf die einzelnen Archi-tekturvarianten hilfreich, um die spätere Bewertung der Tools besser einordnen zu können.

Native ImplementierungDie native Implementierung von mobilen Anwendungen fällt augenscheinlich nicht in das Raster der plattform-übergreifenden Entwicklung, allerdings soll sie hier nicht unerwähnt bleiben, denn es gilt zwei wichtige Aspekte festzuhalten: Die native Implementierung von mobilen

Plattformübergreifende Entwicklung von mobilen Anwendungen mit Eclipse

Form follows Function Studien sprechen von mittlerweile mehr als 100 Tools und Frameworks für die platt-formübergreifende Entwicklung von mobilen Anwendungen. Grund genug, sich einmal anzuschauen, was die Eclipse-Community zu diesem Thema zu bieten hat.

ptr

Typewritten Text

FA-236, 2012

13www.eclipse-magazin.de eclipse magazin 4.12

TitelthemaCross-Platform Mobile Development

Anwendungen geht vordergründig mit hohem Aufwand einher, da die App für jede Plattform fast vollständig neu entwickelt werden muss. Man sollte allerdings beachten, dass dies nur für das Frontend gilt – denn das Backend bleibt gleich und kann von allen Frontends aus genutzt werden. Oft ist das Backend bereits vorhanden und muss lediglich um eine geeignete Schnittstelle ergänzt werden. Ein zweiter Aspekt, der unscheinbar wirkt, aber gerade im mobilen Umfeld extrem wichtig ist: Nur native Imple-mentierungen können die Möglichkeiten der jeweiligen Plattform vollständig und dabei gleichzeitig ressourcen-schonend ausnutzen. Dies ist ein nicht zu unterschätzen-der Aspekt, gerade angesichts der selbst auf modernen Handsets immer noch vergleichsweise eingeschränkten Ressourcensituation.

Native Anwendungen werden in der für die jeweilige Plattform gesetzten/vorgesehenen Programmiersprache verfasst, vom Compiler in Binärcode bzw. Bytecode übersetzt und können auf nahezu alle APIs der Plattform zugreifen. Das Deployment erfolgt über den jeweiligen Marktplatz der Plattform, was dem Entwickler einen erstklassigen Kanal für die Vermarktung und Moneta-risierung seiner App an die Hand gibt. Für datengetrie-bene Apps, die über das Internet (oder Intranet) auf ein oder mehrere Backendsystem(e) zugreifen, ergibt sich ein Architekturschaubild wie in Abbildung 1.

Mobile Website/Server-side WebMobile Websites sind eigentlich ganz normale Websites, allerdings sind sie für mobile Geräte bzw. kleine Bild-schirme und die Bedienung mit dem Finger optimiert. Mittels CSS Media Queries kann eine Website so pro-grammiert werden, dass je nach Browser bzw. Betriebs-system unterschiedliche und an die jeweilige Au�ösung angepasste CSS Styles verwendet werden. Durch ge-schickten Einsatz von HTML und CSS können Layouts erstellt werden, die sich der jeweiligen Bildschirmau�ö-sung anpassen (Stichwort „Responsive Design“). Es gibt eine große Anzahl an HTML/CSS-Frameworks, die sich diesem Thema widmen, Bootstrap von Twitter [1] und Foundation von zurb [2] sind nur zwei Beispiele.

Das Look and Feel mobiler Websites ist dank HTML völlig frei gestaltbar – dies kann Segen und Fluch zugleich sein. Einerseits haben Designer so völlige Freiheit und kön-nen das Design einer mobilen Website sehr einfach dem Corporate Design des Auftraggebers anpassen. Anderer-seits wird für den Benutzer sofort deutlich, dass es sich hier nicht um eine App, sondern eine Website handelt. Smart-phone-User sind insbesondere beim Aussehen der von ih-nen eingesetzten Apps recht anspruchsvoll und erwarten, dass eine App die von der jeweiligen Plattform propagier-ten UI-Metaphern aufgreift – dies sollte man bei der Ent-wicklung von UIs mit Webtechnologien stets bedenken.

Smartphones verfügen über moderne Browser, die ih-ren großen Brüdern auf dem Desktop in puncto Funk-tionsumfang und Leistungsfähigkeit nahezu ebenbürtig sind. Darüber hinaus können sie einige der Sensoren von Smartphones auswerten, so z. B. das GPS oder den Gy-

rosensor. Allerdings sind bei Weitem nicht alle Senso-ren über HTML oder JavaScript ansprechbar und auch APIs wie das Adressbuch, die Kamera und die lokale Mediensammlung sind (derzeit noch) nicht nutzbar, was sich sicherlich in den nächsten Jahren mit der stetigen Weiterentwicklung der mobilen Browser noch ändern wird. Architektonisch entsprechen mobile Websites also herkömmlichen Websites (Abb. 2).

Client-side WebIm Gegensatz zu traditionellen Webseiten/dem Server-side Web wird die Aufbereitung des UI sowie ein Teil der Verarbeitungslogik bei diesem Ansatz nicht im Back end bzw. von einem Webserver erledigt, sondern auf dem Frontend ausgeführt. Durch eine geschickte Kombination von HTML, CSS3 und JavaScript können so Benutzer-ober�ächen geschaffen werden, die nativen Ober�ächen sehr ähnlich sehen und sich sogar teilweise täuschend echt anfühlen. Ein 100 % natives Look and Feel herzustellen geht allerdings mit einem erheblichen Aufwand einher – insbesondere die Emulation von Inertia-basiertem Scrol-ling stellt eine ziemliche Herausforderung dar. Da diese Anwendungen im Browser ausgeführt werden, spart man sich bei der Entwicklung eine Menge Arbeit, denn die App muss nur einmal – nämlich für den (mobilen) Brow-ser – entwickelt werden. Wie dies im Detail funktioniert, erklärt Jonathan Stark in seinem Buch „iPhone Apps with HTML, CSS and JavaScript“ [3]. Die im Buch beschrie-benen Techniken bilden das Fundament von jQTouch, einem Plug-in für jQuery/zepto.js, das die Entwicklung von browserbasierten Apps vereinfacht. Ähnliche Frame-works gibt es mittlerweile wie Sand am Meer, die bekann-testen sind jQuery Mobile [4] (nicht zu verwechseln mit jQTouch), Sencha Touch [5], iUi.js [6] und Wink Tool-

Abb. 1: Architektur nativer Anwendun-gen

Abb. 2: Server-side Web



kit [7]. Auch wenn sich die Programmiermodelle teilweise erheblich unterscheiden, haben alle diese Frameworks ei-nes gemeinsam: Sie greifen einzig und alleine auf die Mög-lichkeiten des Browsers zurück. Daher bleibt nicht nur ein erheblicher Teil der Hardwarefeatures des Smartphones ungenutzt, auch der Zugriff auf viele interessante APIs wie z. B. das Adressbuch, die lokale Musikdatenbank oder den Kalender des Smartphones ist außer Reichweite. Im Laufe der Zeit werden die Browserhersteller gemeinsam mit den Smartphoneherstellern immer mehr Schnittstellen zu den Sensoren und auch zu den APIs zugänglich machen – aber das wird noch einige Zeit dauern.

Architektonisch ist diese Variante durchaus ähnlich zu einer nativen Implementierung – immerhin läuft die App lokal auf dem Smartphone ab und die Kommu-nikation mit dem Backend erfolgt über ein geeignetes Transportprotokoll über das Internet. Doch hier hören die Gemeinsamkeiten auch schon auf. Während bei der nativen Umsetzung der Programmcode direkt als Binär-code ausgeführt wird, und die Ober�äche der App mit-hilfe der entsprechenden nativen UI Libraries dargestellt

wird, wird im Falle einer Web-App der Code für das Darstellen der Ober�äche durch den JavaScript-Inter-preter des Browsers ausgeführt (Abb. 3).

Hybrid-AppsDer Zugriff auf die Hardware des Smartphones ist ins-besondere wünschenswert, weil viele Apps erst durch die Nutzung der speziellen Sensoren Sinn machen oder be-sonders reizvoll werden. Um einer clientseitigen Web-App Zugriff auf die Hardwarefunktionen des Smart phones zu verschaffen, muss der Browser in eine native App einge-bettet werden. Mittels einer „Request Interception“ ge-nannten Technik können dann per JavaScript getätigte Aufrufe abgefangen und auf nativen Code umgelenkt werden. Umgekehrt kann nativer Code mittels JavaScript Injection Zugriff auf die Struktur des HTML-Codes, der im Browser läuft, erhalten. Durch diese zweiseitige Kom-munikation wird eine Bridge zwischen dem im Browser laufenden JavaScript-Code und der nativen App geschaf-fen, die es in JavaScript geschriebenen Applikationen erlaubt, auf die nativen Fähigkeiten des Smartphones zu-zugreifen. Ein bekannter Protagonist dieses Ansatzes ist PhoneGap. Zur Darstellung der genauen Funktionsweise von PhoneGap reicht dieser Artikel nicht aus, doch die Architekturgra�k (Abb. 4) veranschaulicht das Prinzip des geschilderten Zusammenspiels.

Interpretierte AppsBei interpretierten Apps handelt es sich um native Apps, die eine Schnittstelle bieten, mit deren Hilfe die Fähig-keiten der nativen App mittels einer Skriptsprache ge-steuert werden kann. Dieser Ansatz �ndet nicht nur für datenorientierte Apps Verwendung, sondern erfreut sich auch im Spieleumfeld großer Beliebtheit. Die möglichen Freiheitsgrade werden durch das dem Entwickler von der nativen App zur Verfügung gestellte API vorgege-ben bzw. limitiert. Das API kann vom Entwickler dann in einer plattformübergreifend vorhandenen Skriptspra-che angesprochen werden. Üblicherweise kommt hier JavaScript zum Einsatz, aber auch Lua [8] erfreut sich einiger Beliebtheit. Idealerweise muss die App tatsächlich nur einmal geschrieben werden und ist dann auf allen Plattformen verfügbar, für die es eine Implementierung der nativen App/des Hybrid APIs gibt. Da das User Inter-face und der Zugriff auf die speziellen Sensoren und na-tiven APIs des Smartphones vom Hersteller einer solchen Lösung nativ implementiert wurden, ist die Performance solcher interpretierter Apps fast genauso gut wie die rein nativer Apps. Das Zusammenspiel der einzelnen Kompo-nenten dieses Ansatzes ist in Abbildung 5 zu sehen.

Terminal-AppsDieser Ansatz greift ein Verfahren auf, das aus anderen Bereichen bereits bekannt ist. Die Geschäftslogik wird auf einem zentralen Server ausgeführt, die Clients dienen nur als Anzeigeprogramm (Stichwort „Dumb Terminal“). Anders als bei einer mobilen Website werden also nur die tatsächlich anzuzeigenden Daten übertragen. Durch die

Abb. 5: In-terpretierte

Apps

Abb. 3: Client-side

Web

Abb. 4: Hybrid-

Apps

www.btdays.de

6. – 8. November 2012 | The Westin Grand München Arabellapark

Where IT Aligns With BusinessDie Business Technology Days bieten als Konferenz einen einzigartigen Rahmen für alle Architekten, IT-Leiter & Projektmanager, die sich mit der Modernisie-rung von Prozessen und Strukturen im Unternehmen

beschäftigen. Sie adressieren mit ihren Special Days gleichermaßen die Business- und Managementaspek-te von Enterprise-Architekturen, SOA, BPM und Cloud Computing.

Softwarearchitektur Cloud Computing Case Studies

ProjektmanagementBPMNEnterprise-Architektur

SOA-PraxisGovernanceBusiness Process Management

Präsentiert von: Veranstalter:

JETZT VORMERKEN!

Medienpartner:



Verwendung einer nativen App als Anzeigeprogramm wird ein natives Look and Feel erreicht, und auch die Performance der Benutzerober�äche ist somit sehr gut. Bei den Gestaltungsmöglichkeiten für das UI ist man bei diesem Ansatz zunächst einmal durch die Mächtigkeit des zugrunde liegenden Frameworks eingeschränkt. Da dieser Ansatz vor allem für die Umsetzung von datenin-tensiven Apps gedacht ist, die einen stark schematischen Charakter aufweisen, ist dies nicht unbedingt von Nach-teil, sondern kann im Gegenteil auch zu einer homogenen und stringenten User Experience führen.

Cross-Compiling„Write once, run everywhere“ – dieser Wahlspruch sollte den Lesern des Eclipse Magazins bekannt vorkommen. Java setzt diesen Anspruch je nach Bereich mehr oder weniger gut um. Die Grundidee ist jedoch immer die glei-che: Man schafft zunächst eine geeignete Abstraktions-schicht, die dann auf den gewünschten Zielplattformen implementiert wird. Im Fall von Java sind dies die JVM sowie die darauf aufbauenden Bibliotheken. Hier erzeugt der Compiler Bytecode, der dann von der JVM auf der entsprechenden Plattform ausgeführt wird. Im Umfeld der mobilen Entwicklung gibt es Tools, die über diesen Ansatz noch hinausgehen und Code einer Hochsprache in Binärcode für die jeweiligen Zielplattformen erzeugen, ohne dass ein Interpreter für die Ausführung des Codes benötigt wird. Im Vergleich zu den o. g. anderen Ansät-zen gibt es allerdings nur eine überschaubare Anzahl von Tools, die diesen Ansatz verfolgen. Architektonisch sieht dieser Ansatz wie in Abbildung 6 aus.

Eclipse-basierte ToolsWenden wir uns nun konkreten Tools zu. Eclipse weist einige Eigenschaften auf, die es als Werkzeug für die platt-formübergreifende Entwicklung prädestinieren: Eclipse (die IDE) ist für alle Betriebssysteme verfügbar, die für die Entwicklung von mobilen Anwendungen relevant sind (insbesondere Windows und Mac OS X). Außerdem ist es in Java geschrieben und leicht erweiterbar, sodass Anbieter von mobilen Plattformen mit überschaubarem Aufwand eine integrierte Entwicklungsumgebung für ihr jeweiliges Tool entwickeln können.

Doch Eclipse ist schon lange nicht mehr nur eine Platt-form für Entwicklungsumgebungen – unter dem Dach

des EclipseRT-Projekts tummeln sich etliche Runtime-Komponenten, die sich die grundlegenden Konzepte der Plattform zu Nutze machen. Und so wundert es nicht, dass es Eclipse-basierte Runtime-Komponenten für mo-bile Anwendungen gibt.

PhoneGapPhoneGap ist vielleicht das bekannteste Framework für die plattformübergreifende Entwicklung von Mobile-Anwendungen. Ursprünglich von der Firma Nitobi entwi-ckelt, die im Oktober letzten Jahres von Adobe aufgekauft wurde, ist Phone Gap mittlerweile ein Open-Source-Pro-jekt unter dem Dach der Apache Foundation – unter dem Namen Apache Cordova [9].

Architektonisch stellt PhoneGap einen Wrapper dar, der die nativen Möglichkeiten der jeweiligen mobilen Plattform für HTML5-Applikationen verfügbar macht. In unserer Taxonomie handelt es sich also um hybride Apps. Die von PhoneGap unterstützte Liste von Platt-formen ist beeindruckend: neben den Schwergewichten iOS und Android werden auch BlackBerry und Win-dows Phone unterstützt und auch so illustre Kandidaten wie Bada, Symbian und WebOS fehlen nicht [10].

PhoneGap-Anwendungen verfügen per se nicht über ein natives Look and Feel, da PhoneGap kein UI-Toolkit enthält und auch die UI-Elemente der jeweiligen Plattfor-men nicht ansteuert. Das Design der Ober�äche bleibt also jedem einzelnen Entwickler selbst überlassen, wobei gerne auf UI-Toolkits wie jQTouch, jQuery Mobile und Sencha Touch zurückgegriffen wird. Die resultierenden UIs haben ein stark von iOS geprägtes Look and Feel, was für Android-Apps noch einigermaßen akzeptabel ist, für alle anderen Plattformen aber fehl am Platze wirkt.

Aufgrund der hohen Popularität von Phone Gap gibt es mittlerweile eine große Bandbreite an Tools, die die Entwicklung mit PhoneGap unterstützen. Von Plug-ins für Texteditoren wie TextMate [11] über Add-ins für kommerzielle Tools wie Adobe Dreamweaver bis hin zu Plug-ins für IDEs wie Xcode und Eclipse ist alles dabei.

Derzeit gibt es leider keine of�zielle Unterstützung seitens PhoneGap/Adobe für ein Eclipse-basiertes Tool, aber im Wiki wird beschrieben, wie ein einfaches Phone-Gap-Projekt in Eclipse aufgesetzt wird [12]. Von Mobile Developer Solutions gibt es ein Plug-in, das das Aufset-zen eines PhoneGap-Projekts mittels Wizard vereinfacht [13]. Dieser ist der Kern des Plug-ins, zusätzlich wird der JavaScript-Editor aus dem JSDT installiert. Ein Editor für HTML-Seiten muss nachträglich per Hand instal-liert werden, z. B. der Web Page Editor aus dem Eclipse Webtools Project.

Leider wird das Debugging von PhoneGap-Apps der-zeit nicht unterstützt – weder unter Android, noch unter iOS oder einer der anderen Plattformen. Darüber hinaus existiert auch keine Unterstützung für das Deployment von PhoneGap-Projekten auf andere Plattformen – die ge-samte Eclipse-basierte PhoneGap-Unterstützung ist der-zeit ausschließlich für Android ausgelegt. Ähnlich stellt sich das Bild übrigens unter Xcode dar: Im Lieferumfang

Abb. 6: Generierte

Apps



von PhoneGap gibt es zwar ein Xcode-Plug-in, das beim Anlegen von (Xcode-)Projekten für PhoneGap hilft, aber keine Unterstützung für andere Plattformen bietet.

Wer dennoch mit PhoneGap plattformüber-greifend entwickeln will, sollte sich PhoneGap Build anschauen [14] – ein von Adobe angebo-tener Cloud-basierter Dienst, der eine Phone-Gap-basierte Anwendung für die Plattformen iOS, Android, Windows Phone, BlackBerry, webOS und Symbian baut und anschließend zum Download bereitstellt.

Appcelerator TitaniumUrsprünglich für die Entwicklung von Desk-topanwendungen mittels Webtechnologien vorgesehen, hat sich Titanium von Appcelera-tor im Laufe der vergangenen Jahre zu einer Plattform für die Entwicklung von mobilen Anwendungen mithilfe von Webtechnologien fortentwickelt. Durch eine Reihe von strategi-schen Aufkäufen hat Appcelerator sukzessive Lücken in der eigenen Plattform gestopft und bietet nunmehr neben dem reinen SDK und der (zugekauften) Eclipse-basierten IDE ein Modul für die Erfassung von Nutzerstatistiken sowie eine eigene Cloud mit Diensten wie Push Noti�-cations, Adaptern für soziale Netzwerke, Ratings etc. Im Rahmen dieses Artikels werden wir uns jedoch nur auf das SDK und die IDE konzentrieren.

Mit Titanium SDK entwickelte Apps fallen in die Ka-tegorie der interpretierten Apps. Kernbestandteil des Titanium SDK ist eine Laufzeitbibliothek, die als Abs-traktionsschicht für den Zugriff auf mobile Geräte dient. Die Entwicklung von Titanium-basierten Apps erfolgt in JavaScript: der vom Entwickler geschriebene Code wird von einer JavaScript Engine ausgeführt und spricht die von Appcelerator zur Verfügung gestellte Abstraktions-bibliothek für die jeweilige Zielplattform an. Diese Bib-liothek ruft dann die jeweiligen nativen APIs auf. Durch dieses Verfahren wird erreicht, dass mit Titanium entwi-ckelte Apps wie native Anwendungen aussehen und prin-zipiell Zugriff auf alle vom jeweiligen mobilen Gerät zur Verfügung gestellten APIs und Hardwarefeatures zugrei-fen können. Derzeit werden iOS und Android unterstützt. Für BlackBerry gibt es rudimentären Support, allerdings ist die Zukunft dieses Strangs nach wie vor unklar. Win-dows Phone 7 wird derzeit nicht unterstützt.

Bis Anfang 2011 gab es für Titanium keine wirklich ernstzunehmende IDE – ein kleines Tool zur Verwaltung von Projekten war alles, was dem Entwickler an die Hand gegeben wurde. Dies hat sich mit dem Aufkauf von Apta-na im Januar 2011 geändert. Seitdem verfügt Appcelera-tor mit Titanium Studio (Abb. 7) über eine Eclipse-basierte IDE, die neben den bereits von Aptana bekannten Tools zur Entwicklung von Web-Apps nun auch gute Tools für die Entwicklung von mobilen Apps enthält.

Das Deployment zu Testzwecken wird von Titanium recht gut unterstützt: Sowohl der iOS-Simulator als auch

der Android-Emulator werden von Titanium direkt ange-steuert, hier funktioniert sogar das Debugging der App. Anders sieht es beim Deployment auf ein echtes Device aus. Titanium erstellt beim Deployment auf ein natives Device zunächst das jeweilige App-Archiv (Android: ein APK, iPhone: ein IPA), woraufhin es dann auf das Device kopiert wird. Für Android kommt hier das ADB-Kom-mandozeilen-Tool zum Einsatz, für iOS wird der Weg über iTunes gewählt. Weder unter Android noch unter iOS steht hier eine Debugger-Integration zur Verfügung, was ziemlich schade ist, da es bei der Fehlersuche oft wichtig ist, direkt auf dem Gerät zu debuggen.

RAP MobileRAP dürfte vielen Lesern des Eclipse Magazins bereits bekannt sein. RAP ersetzt das Standard Widget Tool-kit (SWT) durch das RAP Widget Toolkit (RWT), das größtenteils schnittstellenkompatibel ist. Durch diesen „Trick“ ist es möglich, RAP-Anwendungen wie normale Eclipse-RCP-Anwendungen zu schreiben – wenn man einige Dinge beachtet [15]. RAP-Anwendungen sind browserbasierte Web-Apps, die mittels des RAP Proto-kols [16] mit dem Server kommunizieren. Das Rende-ring der Ober�ächen im Browser wird vollständig von RAP übernommen. Abgesehen von einem eventuell ge-wünschten Styling per CSS müssen Entwickler sich also nicht mit Webtechnologien auskennen, sondern können die Anwendung vollständig in Java schreiben. Für die Gestaltung der Ober�ächen kann der exzellente Win-dowBuilder (mittlerweile ebenfalls ein Eclipse-Projekt [17]) verwendet werden (Abb. 8 und 9).

Mit RAP Mobile wird dieser Ansatz in die mobile Welt übertragen, die Anwendung wird vollständig in Java ge-schrieben und auf dem Server ausgeführt. Auf dem mobi-len Endgerät wird eine minimale native App gestartet, die sich mit dem Server verbindet und vom Server übertrage-ne Daten darstellt. Die Anzeige der Daten erfolgt dabei

Abb. 7: Titanium Studio mit aktiver Debug-Session



mithilfe von nativen Komponenten. Das RAP-Protokoll unterstützt nicht nur die Übertragung von Daten, sondern auch von Widgets, Layouts und Kommandos, sodass die Serveranwendung Look and Feel sowie das Verhalten der Applikation vollständig steuern kann. Benutzereingaben werden zum Server übertragen, dort verarbeitet und in entsprechende Kommandos übersetzt, die dann wieder zum mobilen Client übertragen werden.

Als Entwicklungsumgebung für RAP Mobile kommt eine reguläre Eclipse-Distribution zum Einsatz. Nach dem Herunterladen des Demoprojekts [18] muss die enthalte-ne Target Platform aktiviert werden, um die Arbeit mit RAP Mobile zu ermöglichen. Das Demoprojekt enthält einige interessante Beispiele, angefangen beim obligatori-schen „Hello World“ über einfache Dateneingabeober�ä-chen bis hin zu gra�sch aufwändigen Dashboards [19].

Derzeit (Stand: Ende April, Anm. d. Red.) be�ndet sich RAP Mobile noch in einer geschlossenen Betapha-se. Im Laufe des Jahres soll es eine öffentliche Betapha-se geben, dann wird auch das Lizenz- und Preismodell bekanntgegeben. Alles in allem ein vielversprechender Ansatz, insbesondere für Java-Entwickler.

Adobe Flash BuilderFlash Builder ist Adobes kommerzielle Entwicklungsum-gebung für Flex-Applikationen. Flex ist ein Framework, das auf Adobe AIR und Flash aufsetzt und für die Ent-wicklung von UI-basierten datengetriebenen Clients ent-wickelt wurde. Ursprünglich unter dem Namen Adobe Flex vermarktet, ist Flex nun ein Apache-Projekt und heißt of�ziell „Apache Flex“ [20]. Da die AIR Runtime und das Flex SDK frei verfügbar sind, können Flex-Ap-plikationen auch mit anderen Tools erstellt werden. FDT von Power�asher ist ein weiteres Tool für die Entwicklung von Flex/Flash-Apps, das ebenfalls Eclipse-basiert ist [21].

Mit Adobe Flash Builder erstellte Mobile Apps basieren auf dem oben vorgestellten Muster „Interpretierte Apps“: Der vom Entwickler in ActionScript geschriebene Code wird in Bytecode übersetzt und dann von der AIR Run-time ausgeführt. Die Flex Library dient dabei der Abstrak-tion der Unterschiede der jeweiligen nativen Plattformen.

Flash Builder (Abb. 10) ist eine echte IDE. Neue Flex-Projekte können mittels eines Wizards angelegt werden, hierbei werden neben dem Projektnamen auch schon die gewünschten Zielplattformen (iOS, Android, BlackBer-ry Tablet OS) abgefragt und kon�guriert. Die für die jeweiligen App Stores notwendigen Zerti�kate können über die Projekteigenschaften hinterlegt werden und werden beim Build automatisch berücksichtigt.

Wie man es von einer Eclipse-basierten IDE erwartet, verfügt Flash Builder über einen vernünftigen Quellcode-editor, der die von Eclipse bekannten Annehmlichkeiten wie Syntax Highlighting, Code Completion, eine Out-line und dergleichen mehr mitbringt. Ebenfalls integriert ist eine Anbindung an die Flex-Dokumentation, sodass die Bedeutung der meisten Klassen und Methoden in der AS Doc View in Erfahrung gebracht werden können. Flex-UIs können entweder programmatisch (mittels Ac-

tionScript) oder deklarativ (mit MXML [22]) erstellt werden. Flash Builder enthält einen visuellen UI-Designer, der zur Erstellung der Ober�ächen genutzt werden kann.

Erfreulicherweise integriert sich Flash Buil-der auch in die Debugger-Infrastruktur, sodass das Debugging von Flex-Apps ohne Weiteres funktioniert. Das Setzen von Breakpoints, schrittweises Durchlaufen des Codes, die Ins-pektion von Variablen, sogar das Ändern von Variablenwerten funktioniert.

Flash Builder verfügt über einen desktop-basierten Emulator, der in der Lage ist, Flex-basierte Applikationen auf dem Desktop auszuführen. Dieser Emulator dient vor allem dazu, das Layout der App zu überprüfen und kann zu diesem Zweck die Au�ösungen einer ganzen Reihe von mobilen Geräten emulieren. Für ernsthafte Funktionstests reicht dies je-doch nicht aus, insbesondere da der Emulator die Hardware der jeweiligen mobilen Geräte nicht emuliert. Leider bietet Flash Builder kei-ne Möglichkeit, den jeweiligen Emulator bzw. Abb. 9: RAP Mobile – UIs können mit WindowBuilder bearbeitet werden

Abb. 8: RAP Mobile



verwunderlich, dass es tatsächlich einige Tools gibt, die Eclipse als Basistechnologie nutzen, wie z. B. RAP und Applause. Andere nutzen Eclipse „nur“ als IDE. Da viele der Tools aus der Webentwicklerszene stammen, ist es kaum verwunderlich, dass entweder kein oder nur ru-dimentärer IDE-Support geboten wird oder erst nach-träglich hinzugefügt wurde. Tools wie Sencha Touch wiederum enthalten gar eine eigene, selbstgeschriebene IDE (hier Sencha Architect) oder gehen wie jQuery Mo-bile davon aus, dass man entweder nur einen Texteditor oder eine auf Webdesign spezialisierte IDE wie Dream-weaver verwendet. Auch das Thema Cloud IDE spielt bei einigen Frameworks eine Rolle – so ist z. B. Trigger.io nur als Cloud-Lösung verfügbar.

Simulator der Zielplattform zu nutzen. Es ist also unausweichlich, die App auf ein echtes Ge-rät zu deployen. Je nach Zielplattform gestal-tet sich dies mehr oder weniger umständlich. Während das Deployment auf ein Android Device noch direkt aus Flash Builder erfolgen kann und ähnlich wie bei Verwendung des An-droid ADT funktioniert [23], erfolgt das De-ployment einer App auf ein iOS Device über iTunes: Flash Builder exportiert hierzu eine .ipa-Datei, die dann mittels iTunes auf das Zielgerät kopiert werden muss [24]. Ziemlich umständlich und leider auch sehr langsam. Selbst für einfache Apps kostet dieser Vorgang schon mal ein paar Minuten Zeit.

Erfreulicherweise unterstützt Flash Builder Kommandozeilen-Builds, sodass einer Conti-nuous Integration nichts im Wege steht. Aller-dings läuft der Kommandozeilen-Builder nur unter Windows und Mac OS X [25].

ApplauseBei Applause [26] handelt es sich um ein Eclipse-basiertes Tool zur Generierung von mobilen Apps (Abb. 11). Struktur und Verhal-ten der Apps werden in einer Xtext-basierten DSL spezi�ziert, die dann von einem Codege-nerator in native Apps für iOS, Android und Windows Phone übersetzt werden. Neue Pro-jekte können mithilfe eines Wizards angelegt werden. Die Spezi�kation der App erfolgt in einem Xtext-basierten Editor. Applause selbst verfügt nicht über einen Debugger – hier muss der Entwickler auf die jeweiligen Tools der Zielplattform zurückgreifen. Derzeit gibt es noch keine Unterstützung für einen platt-formübergreifenden Build, der sich in eine CI-Umgebung integrieren ließe.

Mit Applause erstellte Applikationen ge-hören in die Kategorie der generierten Apps. Für die Kategorie der datengetriebenen Apps eignet sich dieser Ansatz recht gut, allerdings ist er nur bedingt für die Umsetzung von sehr individuellen Apps geeignet. Sollte der mitge-lieferte Generator nicht den eigenen Ansprüchen genü-gen, kann er durch eine eigene Implementierung ersetzt werden.

Die aktuelle Version von Applause ist vor allem als Machbarkeitsstudie zu verstehen, die nächste Version soll sowohl hinsichtlich der Erweiterbarkeit der DSL als auch der Generatoren weiterentwickelt werden.

FazitDie Vielzahl der derzeit am Markt be�ndlichen Frame-works zur plattformübergreifenden Entwicklung von mobilen Anwendungen spiegelt sich auch in der Land-schaft für Entwicklungsumgebungen wider. Angesichts der Innovationskraft der Eclipse-Community ist es nicht

Abb. 10: Flash Builder

Abb. 11: Applause IDE



Die Wahl der richtigen Plattform für ein (plattform-übergreifendes) mobiles Projekt ist eine Entscheidung, die hauptsächlich von der Art der umzusetzenden App ab-hängt. Plattformübergreifendes Entwickeln ist kein Wert in sich, sondern unterliegt wie so vieles andere auch dem Designgrundsatz „Form follows Function“ – die Form folgt der Funktion. Die Vielfalt der verfügbaren Lösun-gen kann man daher getrost als Bereicherung ansehen. Eine detaillierte Auseinandersetzung mit den einzelnen hier vorgestellten Ansätzen ist unter [27] zu �nden.

Peter Friese arbeitet als Principal Consultant für Zühlke Enginee-ring. Seine Schwerpunkte liegen auf der modellgetriebenen Soft-wareentwicklung, der plattformübergreifenden Entwicklung von mobilen Anwendungen (u. a. für iOS, Android, Windows Phone 7 und Mobile Web) sowie Eclipse als Plattform. Peter bloggt auf

http://www.peterfriese.de und twittert unter @peterfriese.

Links & Literatur

[1] http://twitter.github.com/bootstrap/

[2] http://foundation.zurb.com/

[3] Stark, Jonathan: „Building iPhone Apps with HTML, CSS, and JavaScript“, O‘Reilly Media, 2010

[4] http://jquerymobile.com/

[5] http://www.sencha.com/products/touch

[6] http://www.iui-js.org/

[7] http://www.winktoolkit.org/

[8] http://www.lua.org/

[9] http://incubator.apache.org/cordova/

[10] http://phonegap.com/about/features

[11] https://github.com/imhotep/PhoneGap.tmbundle

[12] http://bit.ly/gLTJoy

[13] http://www.mobiledevelopersolutions.com/

[14] http://build.phonegap.com/

[15] http://wiki.eclipse.org/RAP/FAQ#Single_Sourcing

[16] http://wiki.eclipse.org/RAP/Protocol

[17] http://www.eclipse.org/windowbuilder/

[18] https://github.com/eclipsesource/rap-mobile-demos

[19] http://rapmobile.eclipsesource.com/demos/

[20] http://blogs.apache.org/�ex/

[21] http://fdt.power�asher.com/

[22] http://bit.ly/JA7F2A

[23] http://adobe.ly/mRyJx7

[24] http://adobe.ly/k03nBY

[25] http://adobe.ly/Icz7RV

[26] http://applause.github.com/

[27] http://www.cross-platform.mobi

PhoneGap/MDS Titanium RAP Mobile Flash Builder Applause

Kosten

Preis kostenlos kostenlos/auf Anfrage unbekannt 699 US-Dollar kostenlos

Lizenz Apache License 2.0 kommerziell/Apache 2 unbekannt kommerziell EPL

Runtime-Lizenzen nicht erforderlich nicht erforderlich unbekannt nicht erforderlich nicht erforderlich

Entwicklung

Entwicklungsmodell Web/Wrapper Interpretiert/nativ Terminal/serverbasiert Interpretiert/nativ Generiert

Mobile Plattformen iOS, Android, WP7, BlackBerry, webOS, Bada, Symbian

iOS, Android, (BlackBerry)

iOS, Android iOS, Android, BlackBerry

iOS, Android, WP7

Sprache JavaScript JavaScript Java ActionScript/MXML DSL

Abstraktionsschicht Wrapper, webbasiert Bridge API zwischen JavaScript und nativer Plattform

Command-basierter Ansatz

Bridge API (Flex + AIR Runtime) zwischen ActionScript und nativer Plattform

keine

Debugger nein ja ja ja nein

IDE rudimentär, nicht plattformübergreifend

ja, Eclipse-basiert ja, Eclipse ja, Eclipse-basiert ja, Eclipse-basiert

IDE-Plattformen Mac OS X, Windows Mac OS X, Windows Mac OS X, Windows, Linux

Mac OS X, Windows Mac OS X, Windows

Hilfe/Support online online/in Eclipse integriert

Ausführlich für SWT vorhanden, RAP Mobile selbst noch wenig dokumentiert

Ausführliches Hilfesystem

nein

Qualität

Look and Feel webbasiert/abhängig vom verwendeten UI-Framework

nativ nativ Flex/kann gestylt werden

nativ

Performance ausreichend gut sehr gut gut sehr gut

Tabelle 1: Vergleich der Tools und Frameworks