Titelthema                                                                   Cross-Platform Mobile Development            ...
Cross-Platform Mobile Development                                                                             TitelthemaAn...
Titelthema                                                                      Cross-Platform Mobile Development    Abb. ...
Titelthema                                                                        Cross-Platform Mobile Development  Abb. ...
Cross-Platform Mobile Development                                                                       Titelthemavon Phon...
Titelthema                                                                      Cross-Platform Mobile Development   Abb. 8...
Cross-Platform Mobile Development                                                                    TitelthemaSimulator d...
Titelthema                                                                                             Cross-Platform Mobi...
Nächste SlideShare
Wird geladen in …5
×

Eclipse magazin 4_12_cross_plattform_mobile_development_friese

700 Aufrufe

Veröffentlicht am

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

Veröffentlicht in: Technologie
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
700
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
42
Aktionen
Geteilt
0
Downloads
7
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Eclipse magazin 4_12_cross_plattform_mobile_development_friese

  1. 1. Titelthema Cross-Platform Mobile Development 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. von Peter Friese gen (Kunden-)Projekts sein. Bei den Implementierungs- techniken für mobile Anwendungen unterscheiden wir Dank des plattformunabhängigen Aufbaus sollte Eclipse die folgenden grundsätzlichen Architekturvarianten: sich als integrierte Entwicklungsumgebung für die platt- formübergreifende Entwicklung von mobilen Anwen- • Native Implementierung dungen eigentlich sehr gut eignen. So wundert es auch • Mobile Website/Server-side Web nicht, dass eine beachtliche Anzahl an Tools und Frame- • Web-Apps mit nativem Look and Feel/Client-side Web works existiert, die in der einen oder anderen Form von • Hybrid-Apps Eclipse Gebrauch machen. Einige sehr weit verbreitete • Interpretierte Apps Frameworks sind allerdings erst spät in ihrem zugege- • Terminal-Apps benermaßen noch nicht sehr langen Produktzyklus zu • Cross-Compiling/Generativer Ansatz Eclipse gewechselt. Zunächst ist ein kurzer Blick auf die einzelnen Archi- Mobile Apps – eine Taxonomie tekturvarianten hilfreich, um die spätere Bewertung der Um einen besseren Überblick zu gewährleisten, wollen Tools besser einordnen zu können. wir die verschiedenen Tools und Frameworks nach ih- ren architektonischen Prinzipien gliedern. Letztendlich Native Implementierung ist auch die beste Entwicklungsumgebung nur ein Werk- Die native Implementierung von mobilen Anwendungen zeug, das beim effizienten Umgang mit dem entspre- fällt augenscheinlich nicht in das Raster der plattform- chenden Framework helfen soll. Ausschlaggebend für übergreifenden Entwicklung, allerdings soll sie hier nicht die Auswahl einer Implementierungstechnologie sollten unerwähnt bleiben, denn es gilt zwei wichtige Aspekte daher immer die konkreten Anforderungen des jeweili- festzuhalten: Die native Implementierung von mobilen12 eclipse magazin 4.12 FA-236, 2012 www.eclipse-magazin.de
  2. 2. Cross-Platform Mobile Development TitelthemaAnwendungen geht vordergründig mit hohem Aufwand Abb. 1: Architektureinher, da die App für jede Plattform fast vollständig neu nativerentwickelt werden muss. Man sollte allerdings beachten, Anwendun-dass dies nur für das Frontend gilt – denn das Backend genbleibt gleich und kann von allen Frontends aus genutztwerden. Oft ist das Backend bereits vorhanden und musslediglich um eine geeignete Schnittstelle ergänzt werden.Ein zweiter Aspekt, der unscheinbar wirkt, aber geradeim mobilen Umfeld extrem wichtig ist: Nur native Imple-mentierungen können die Möglichkeiten der jeweiligenPlattform vollständig und dabei gleichzeitig ressourcen-schonend ausnutzen. Dies ist ein nicht zu unterschätzen-der Aspekt, gerade angesichts der selbst auf modernen Abb. 2: Server-sideHandsets immer noch vergleichsweise eingeschränkten WebRessourcensituation. Native Anwendungen werden in der für die jeweiligePlattform gesetzten/vorgesehenen Programmierspracheverfasst, vom Compiler in Binärcode bzw. Bytecodeübersetzt und können auf nahezu alle APIs der Plattformzugreifen. Das Deployment erfolgt über den jeweiligenMarktplatz der Plattform, was dem Entwickler einenerstklassigen 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 einoder mehrere Backendsystem(e) zugreifen, ergibt sich rosensor. Allerdings sind bei Weitem nicht alle Senso-ein Architekturschaubild wie in Abbildung 1. ren über HTML oder JavaScript ansprechbar und auch APIs wie das Adressbuch, die Kamera und die lokaleMobile Website/Server-side Web Mediensammlung sind (derzeit noch) nicht nutzbar, wasMobile Websites sind eigentlich ganz normale Websites, sich sicherlich in den nächsten Jahren mit der stetigenallerdings sind sie für mobile Geräte bzw. kleine Bild- Weiterentwicklung der mobilen Browser noch ändernschirme und die Bedienung mit dem Finger optimiert. wird. Architektonisch entsprechen mobile Websites alsoMittels CSS Media Queries kann eine Website so pro- herkömmlichen Websites (Abb. 2).grammiert werden, dass je nach Browser bzw. Betriebs-system unterschiedliche und an die jeweilige Auflösung Client-side Webangepasste CSS Styles verwendet werden. Durch ge- Im Gegensatz zu traditionellen Webseiten/dem Server-schickten Einsatz von HTML und CSS können Layouts side Web wird die Aufbereitung des UI sowie ein Teil dererstellt werden, die sich der jeweiligen Bildschirmauflö- Verarbeitungslogik bei diesem Ansatz nicht im Backendsung anpassen (Stichwort „Responsive Design“). Es gibt bzw. von einem Webserver erledigt, sondern auf demeine große Anzahl an HTML/CSS-Frameworks, die sich Frontend ausgeführt. Durch eine geschickte Kombinationdiesem Thema widmen, Bootstrap von Twitter [1] und von HTML, CSS3 und JavaScript können so Benutzer-Foundation von zurb [2] sind nur zwei Beispiele. oberflächen geschaffen werden, die nativen Oberflächen Das Look and Feel mobiler Websites ist dank HTML sehr ähnlich sehen und sich sogar teilweise täuschend echtvöllig frei gestaltbar – dies kann Segen und Fluch zugleich anfühlen. Ein 100 % natives Look and Feel herzustellensein. Einerseits haben Designer so völlige Freiheit und kön- geht allerdings mit einem erheblichen Aufwand einher –nen das Design einer mobilen Website sehr einfach dem insbesondere die Emulation von Inertia-basiertem Scrol-Corporate Design des Auftraggebers anpassen. Anderer- ling stellt eine ziemliche Herausforderung dar. Da dieseseits wird für den Benutzer sofort deutlich, dass es sich hier Anwendungen im Browser ausgeführt werden, spart mannicht um eine App, sondern eine Website handelt. Smart- sich bei der Entwicklung eine Menge Arbeit, denn diephone-User sind insbesondere beim Aussehen der von ih- App muss nur einmal – nämlich für den (mobilen) Brow-nen eingesetzten Apps recht anspruchsvoll und erwarten, ser – entwickelt werden. Wie dies im Detail funktioniert,dass eine App die von der jeweiligen Plattform propagier- erklärt Jonathan Stark in seinem Buch „iPhone Apps withten UI-Metaphern aufgreift – dies sollte man bei der Ent- HTML, CSS and JavaScript“ [3]. Die im Buch beschrie-wicklung von UIs mit Webtechnologien stets bedenken. benen Techniken bilden das Fundament von jQTouch, Smartphones verfügen über moderne Browser, die ih- einem Plug-in für jQuery/zepto.js, das die Entwicklungren großen Brüdern auf dem Desktop in puncto Funk- von browserbasierten Apps vereinfacht. Ähnliche Frame-tionsumfang und Leistungsfähigkeit nahezu ebenbürtig works gibt es mittlerweile wie Sand am Meer, die bekann-sind. Darüber hinaus können sie einige der Sensoren von testen sind jQuery Mobile [4] (nicht zu verwechseln mitSmartphones auswerten, so z. B. das GPS oder den Gy- jQTouch), Sencha Touch [5], iUi.js [6] und Wink Tool-www.eclipse-magazin.de eclipse magazin 4.12 13
  3. 3. Titelthema Cross-Platform Mobile Development Abb. 3: wird, wird im Falle einer Web-App der Code für dasClient-side Web Darstellen der Oberfläche durch den JavaScript-Inter- preter des Browsers ausgeführt (Abb. 3). Hybrid-Apps Der 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 Smartphones zu verschaffen, muss der Browser in eine native App einge- bettet werden. Mittels einer „Request Interception“ ge- Abb. 4: nannten Technik können dann per JavaScript getätigte Hybrid- Aufrufe abgefangen und auf nativen Code umgelenkt Apps 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 Architekturgrafik (Abb.  4) veranschaulicht das Prinzip Abb. 5: In-terpretierte des geschilderten Zusammenspiels. Apps Interpretierte Apps Bei 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 findet 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 kit [7]. Auch wenn sich die Programmiermodelle teilweise in einer plattformübergreifend vorhandenen Skriptspra- erheblich unterscheiden, haben alle diese Frameworks ei- che angesprochen werden. Üblicherweise kommt hier nes gemeinsam: Sie greifen einzig und alleine auf die Mög- JavaScript zum Einsatz, aber auch Lua [8] erfreut sich lichkeiten des Browsers zurück. Daher bleibt nicht nur ein einiger Beliebtheit. Idealerweise muss die App tatsächlich erheblicher Teil der Hardwarefeatures des Smartphones nur einmal geschrieben werden und ist dann auf allen ungenutzt, auch der Zugriff auf viele interessante APIs Plattformen verfügbar, für die es eine Implementierung wie z. B. das Adressbuch, die lokale Musikdatenbank oder der nativen App/des Hybrid APIs gibt. Da das User Inter- den Kalender des Smartphones ist außer Reichweite. Im face und der Zugriff auf die speziellen Sensoren und na- Laufe der Zeit werden die Browserhersteller gemeinsam tiven APIs des Smartphones vom Hersteller einer solchen mit den Smartphoneherstellern immer mehr Schnittstellen Lösung nativ implementiert wurden, ist die Performance zu den Sensoren und auch zu den APIs zugänglich machen solcher interpretierter Apps fast genauso gut wie die rein – aber das wird noch einige Zeit dauern. nativer Apps. Das Zusammenspiel der einzelnen Kompo- Architektonisch ist diese Variante durchaus ähnlich nenten dieses Ansatzes ist in Abbildung 5 zu sehen. zu einer nativen Implementierung – immerhin läuft die App lokal auf dem Smartphone ab und die Kommu- Terminal-Apps nikation mit dem Backend erfolgt über ein geeignetes Dieser Ansatz greift ein Verfahren auf, das aus anderen Transportprotokoll über das Internet. Doch hier hören Bereichen bereits bekannt ist. Die Geschäftslogik wird auf die Gemeinsamkeiten auch schon auf. Während bei der einem zentralen Server ausgeführt, die Clients dienen nur nativen Umsetzung der Programmcode direkt als Binär- als Anzeigeprogramm (Stichwort „Dumb Terminal“). code ausgeführt wird, und die Oberfläche der App mit- Anders als bei einer mobilen Website werden also nur die hilfe der entsprechenden nativen UI Libraries dargestellt tatsächlich anzuzeigenden Daten übertragen. Durch die14 eclipse magazin 4.12 www.eclipse-magazin.de
  4. 4. Titelthema Cross-Platform Mobile Development Abb. 6: des EclipseRT-Projekts tummeln sich etliche Runtime-Generierte Apps 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. PhoneGap PhoneGap 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 PhoneGap mittlerweile ein Open-Source-Pro- jekt unter dem Dach der Apache Foundation – unter dem Verwendung einer nativen App als Anzeigeprogramm Namen Apache Cordova [9]. wird ein natives Look and Feel erreicht, und auch die Architektonisch stellt PhoneGap einen Wrapper dar, Performance der Benutzeroberfläche ist somit sehr gut. der die nativen Möglichkeiten der jeweiligen mobilen Bei den Gestaltungsmöglichkeiten für das UI ist man bei Plattform für HTML5-Applikationen verfügbar macht. diesem Ansatz zunächst einmal durch die Mächtigkeit In unserer Taxonomie handelt es sich also um hybride des zugrunde liegenden Frameworks eingeschränkt. Da Apps. Die von PhoneGap unterstützte Liste von Platt- dieser Ansatz vor allem für die Umsetzung von datenin- formen ist beeindruckend: neben den Schwergewichten tensiven Apps gedacht ist, die einen stark schematischen iOS und Android werden auch BlackBerry und Win- Charakter aufweisen, ist dies nicht unbedingt von Nach- dows Phone unterstützt und auch so illustre Kandidaten teil, sondern kann im Gegenteil auch zu einer homogenen wie Bada, Symbian und WebOS fehlen nicht [10]. und stringenten User Experience führen. PhoneGap-Anwendungen verfügen per se nicht über ein natives Look and Feel, da PhoneGap kein UI-Toolkit Cross-Compiling enthält und auch die UI-Elemente der jeweiligen Plattfor- „Write once, run everywhere“ – dieser Wahlspruch sollte men nicht ansteuert. Das Design der Oberfläche bleibt den Lesern des Eclipse Magazins bekannt vorkommen. also jedem einzelnen Entwickler selbst überlassen, wobei Java setzt diesen Anspruch je nach Bereich mehr oder gerne auf UI-Toolkits wie jQTouch, jQuery Mobile und weniger gut um. Die Grundidee ist jedoch immer die glei- Sencha Touch zurückgegriffen wird. Die resultierenden che: Man schafft zunächst eine geeignete Abstraktions- UIs haben ein stark von iOS geprägtes Look and Feel, schicht, die dann auf den gewünschten Zielplattformen was für Android-Apps noch einigermaßen akzeptabel ist, implementiert wird. Im Fall von Java sind dies die JVM für alle anderen Plattformen aber fehl am Platze wirkt. sowie die darauf aufbauenden Bibliotheken. Hier erzeugt Aufgrund der hohen Popularität von PhoneGap gibt der Compiler Bytecode, der dann von der JVM auf der es mittlerweile eine große Bandbreite an Tools, die die entsprechenden Plattform ausgeführt wird. Im Umfeld Entwicklung mit PhoneGap unterstützen. Von Plug-ins der mobilen Entwicklung gibt es Tools, die über diesen für Texteditoren wie TextMate [11] über Add-ins für Ansatz noch hinausgehen und Code einer Hochsprache kommerzielle Tools wie Adobe Dreamweaver bis hin zu in Binärcode für die jeweiligen Zielplattformen erzeugen, Plug-ins für IDEs wie Xcode und Eclipse ist alles dabei. ohne dass ein Interpreter für die Ausführung des Codes Derzeit gibt es leider keine offizielle Unterstützung benötigt wird. Im Vergleich zu den o. g. anderen Ansät- seitens PhoneGap/Adobe für ein Eclipse-basiertes Tool, zen gibt es allerdings nur eine überschaubare Anzahl von aber im Wiki wird beschrieben, wie ein einfaches Phone- Tools, die diesen Ansatz verfolgen. Architektonisch sieht Gap-Projekt in Eclipse aufgesetzt wird [12]. Von Mobile dieser Ansatz wie in Abbildung 6 aus. Developer Solutions gibt es ein Plug-in, das das Aufset- zen eines PhoneGap-Projekts mittels Wizard vereinfacht Eclipse-basierte Tools [13]. Dieser ist der Kern des Plug-ins, zusätzlich wird der Wenden wir uns nun konkreten Tools zu. Eclipse weist JavaScript-Editor aus dem JSDT installiert. Ein Editor einige Eigenschaften auf, die es als Werkzeug für die platt- für HTML-Seiten muss nachträglich per Hand instal- formübergreifende Entwicklung prädestinieren: Eclipse liert werden, z. B. der Web Page Editor aus dem Eclipse (die IDE) ist für alle Betriebssysteme verfügbar, die für Webtools Project. die Entwicklung von mobilen Anwendungen relevant Leider wird das Debugging von PhoneGap-Apps der- sind (insbesondere Windows und Mac OS X). Außerdem zeit nicht unterstützt – weder unter Android, noch unter ist es in Java geschrieben und leicht erweiterbar, sodass iOS oder einer der anderen Plattformen. Darüber hinaus Anbieter von mobilen Plattformen mit überschaubarem existiert auch keine Unterstützung für das Deployment Aufwand eine integrierte Entwicklungsumgebung für ihr von PhoneGap-Projekten auf andere Plattformen – die ge- jeweiliges Tool entwickeln können. samte Eclipse-basierte PhoneGap-Unterstützung ist der- Doch Eclipse ist schon lange nicht mehr nur eine Platt- zeit ausschließlich für Android ausgelegt. Ähnlich stellt form für Entwicklungsumgebungen – unter dem Dach sich das Bild übrigens unter Xcode dar: Im Lieferumfang16 eclipse magazin 4.12 www.eclipse-magazin.de
  5. 5. Cross-Platform Mobile Development Titelthemavon PhoneGap gibt es zwar ein Xcode-Plug-in,das beim Anlegen von (Xcode-)Projekten fürPhoneGap hilft, aber keine Unterstützung fürandere Plattformen bietet. Wer dennoch mit PhoneGap plattformüber-greifend entwickeln will, sollte sich PhoneGapBuild anschauen [14] – ein von Adobe angebo-tener Cloud-basierter Dienst, der eine Phone-Gap-basierte Anwendung für die PlattformeniOS, Android, Windows Phone, BlackBerry,webOS und Symbian baut und anschließendzum Download bereitstellt.Appcelerator TitaniumUrsprünglich für die Entwicklung von Desk-topanwendungen mittels Webtechnologienvorgesehen, hat sich Titanium von Appcelera-tor im Laufe der vergangenen Jahre zu einerPlattform für die Entwicklung von mobilenAnwendungen mithilfe von Webtechnologien Abb. 7: Titanium Studio mit aktiver Debug-Sessionfortentwickelt. Durch eine Reihe von strategi-schen Aufkäufen hat Appcelerator sukzessive Lücken in der Android-Emulator werden von Titanium direkt ange-der eigenen Plattform gestopft und bietet nunmehr neben steuert, hier funktioniert sogar das Debugging der App.dem reinen SDK und der (zugekauften) Eclipse-basierten Anders sieht es beim Deployment auf ein echtes DeviceIDE ein Modul für die Erfassung von Nutzerstatistiken aus. Titanium erstellt beim Deployment auf ein nativessowie eine eigene Cloud mit Diensten wie Push Notifi- Device zunächst das jeweilige App-Archiv (Android: eincations, Adaptern für soziale Netzwerke, Ratings etc. Im APK, iPhone: ein IPA), woraufhin es dann auf das DeviceRahmen dieses Artikels werden wir uns jedoch nur auf kopiert wird. Für Android kommt hier das ADB-Kom-das SDK und die IDE konzentrieren. mandozeilen-Tool zum Einsatz, für iOS wird der Weg Mit Titanium SDK entwickelte Apps fallen in die Ka- über iTunes gewählt. Weder unter Android noch untertegorie der interpretierten Apps. Kernbestandteil des iOS steht hier eine Debugger-Integration zur Verfügung,Titanium SDK ist eine Laufzeitbibliothek, die als Abs- was ziemlich schade ist, da es bei der Fehlersuche ofttraktionsschicht für den Zugriff auf mobile Geräte dient. wichtig ist, direkt auf dem Gerät zu debuggen.Die Entwicklung von Titanium-basierten Apps erfolgt inJavaScript: der vom Entwickler geschriebene Code wird RAP Mobilevon einer JavaScript Engine ausgeführt und spricht die RAP dürfte vielen Lesern des Eclipse Magazins bereitsvon Appcelerator zur Verfügung gestellte Abstraktions- bekannt sein. RAP ersetzt das Standard Widget Tool-bibliothek für die jeweilige Zielplattform an. Diese Bib- kit (SWT) durch das RAP Widget Toolkit (RWT), dasliothek ruft dann die jeweiligen nativen APIs auf. Durch größtenteils schnittstellenkompatibel ist. Durch diesendieses Verfahren wird erreicht, dass mit Titanium entwi- „Trick“ ist es möglich, RAP-Anwendungen wie normaleckelte Apps wie native Anwendungen aussehen und prin- Eclipse-RCP-Anwendungen zu schreiben – wenn manzipiell Zugriff auf alle vom jeweiligen mobilen Gerät zur einige Dinge beachtet [15]. RAP-Anwendungen sindVerfügung gestellten APIs und Hardwarefeatures zugrei- browserbasierte Web-Apps, die mittels des RAP Proto-fen können. Derzeit werden iOS und Android unterstützt. kols [16] mit dem Server kommunizieren. Das Rende-Für BlackBerry gibt es rudimentären Support, allerdings ring der Oberflächen im Browser wird vollständig vonist die Zukunft dieses Strangs nach wie vor unklar. Win- RAP übernommen. Abgesehen von einem eventuell ge-dows Phone 7 wird derzeit nicht unterstützt. wünschten Styling per CSS müssen Entwickler sich also Bis Anfang 2011 gab es für Titanium keine wirklich nicht mit Webtechnologien auskennen, sondern könnenernstzunehmende IDE – ein kleines Tool zur Verwaltung die Anwendung vollständig in Java schreiben. Für dievon Projekten war alles, was dem Entwickler an die Hand Gestaltung der Oberflächen kann der exzellente Win-gegeben wurde. Dies hat sich mit dem Aufkauf von Apta- dowBuilder (mittlerweile ebenfalls ein Eclipse-Projektna im Januar 2011 geändert. Seitdem verfügt Appcelera- [17]) verwendet werden (Abb. 8 und 9).tor mit Titanium Studio (Abb. 7) über eine Eclipse-basierte Mit RAP Mobile wird dieser Ansatz in die mobile WeltIDE, die neben den bereits von Aptana bekannten Tools übertragen, die Anwendung wird vollständig in Java ge-zur Entwicklung von Web-Apps nun auch gute Tools für schrieben und auf dem Server ausgeführt. Auf dem mobi-die Entwicklung von mobilen Apps enthält. len Endgerät wird eine minimale native App gestartet, die Das Deployment zu Testzwecken wird von Titanium sich mit dem Server verbindet und vom Server übertrage-recht gut unterstützt: Sowohl der iOS-Simulator als auch ne Daten darstellt. Die Anzeige der Daten erfolgt dabeiwww.eclipse-magazin.de eclipse magazin 4.12 17
  6. 6. Titelthema Cross-Platform Mobile Development Abb. 8: Adobe Flash BuilderRAP Mobile Flash 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 offiziell „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 Powerflasher 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 mithilfe von nativen Komponenten. Das RAP-Protokoll auf dem oben vorgestellten Muster „Interpretierte Apps“: unterstützt nicht nur die Übertragung von Daten, sondern Der vom Entwickler in ActionScript geschriebene Code auch von Widgets, Layouts und Kommandos, sodass die wird in Bytecode übersetzt und dann von der AIR Run- Serveranwendung Look and Feel sowie das Verhalten der time ausgeführt. Die Flex Library dient dabei der Abstrak- Applikation vollständig steuern kann. Benutzereingaben tion der Unterschiede der jeweiligen nativen Plattformen. werden zum Server übertragen, dort verarbeitet und in Flash Builder (Abb. 10) ist eine echte IDE. Neue Flex- entsprechende Kommandos übersetzt, die dann wieder Projekte können mittels eines Wizards angelegt werden, zum mobilen Client übertragen werden. hierbei werden neben dem Projektnamen auch schon die Als Entwicklungsumgebung für RAP Mobile kommt gewünschten Zielplattformen (iOS, Android, BlackBer- eine reguläre Eclipse-Distribution zum Einsatz. Nach dem ry Tablet OS) abgefragt und konfiguriert. Die für die Herunterladen des Demoprojekts [18] muss die enthalte- jeweiligen App Stores notwendigen Zertifikate können ne Target Platform aktiviert werden, um die Arbeit mit über die Projekteigenschaften hinterlegt werden und RAP Mobile zu ermöglichen. Das Demoprojekt enthält werden beim Build automatisch berücksichtigt. einige interessante Beispiele, angefangen beim obligatori- Wie man es von einer Eclipse-basierten IDE erwartet, schen „Hello World“ über einfache Dateneingabeoberflä- verfügt Flash Builder über einen vernünftigen Quellcode- chen bis hin zu grafisch aufwändigen Dashboards [19]. editor, der die von Eclipse bekannten Annehmlichkeiten Derzeit (Stand: Ende April, Anm. d. Red.) befindet wie Syntax Highlighting, Code Completion, eine Out- sich RAP Mobile noch in einer geschlossenen Betapha- line und dergleichen mehr mitbringt. Ebenfalls integriert se. Im Laufe des Jahres soll es eine öffentliche Betapha- ist eine Anbindung an die Flex-Dokumentation, sodass se geben, dann wird auch das Lizenz- und Preismodell die Bedeutung der meisten Klassen und Methoden in der bekanntgegeben. Alles in allem ein vielversprechender AS Doc View in Erfahrung gebracht werden können. Ansatz, insbesondere für Java-Entwickler. 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 Oberflä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 Auflö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-Abb. 9: RAP Mobile – UIs können mit WindowBuilder bearbeitet werden ne Möglichkeit, den jeweiligen Emulator bzw.18 eclipse magazin 4.12 www.eclipse-magazin.de
  7. 7. Cross-Platform Mobile Development TitelthemaSimulator der Zielplattform zu nutzen. Es istalso 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 AndroidDevice noch direkt aus Flash Builder erfolgenkann und ähnlich wie bei Verwendung des An-droid ADT funktioniert [23], erfolgt das De-ployment einer App auf ein iOS Device überiTunes: Flash Builder exportiert hierzu eine.ipa-Datei, die dann mittels iTunes auf dasZielgerät kopiert werden muss [24]. Ziemlichumständlich und leider auch sehr langsam.Selbst für einfache Apps kostet dieser Vorgangschon mal ein paar Minuten Zeit. Erfreulicherweise unterstützt Flash BuilderKommandozeilen-Builds, sodass einer Conti-nuous Integration nichts im Wege steht. Aller-dings läuft der Kommandozeilen-Builder nurunter Windows und Mac OS X [25]. Abb. 10: Flash BuilderApplauseBei Applause [26] handelt es sich um einEclipse-basiertes Tool zur Generierung vonmobilen Apps (Abb. 11). Struktur und Verhal-ten der Apps werden in einer Xtext-basiertenDSL spezifiziert, die dann von einem Codege-nerator in native Apps für iOS, Android undWindows Phone übersetzt werden. Neue Pro-jekte können mithilfe eines Wizards angelegtwerden. Die Spezifikation der App erfolgt ineinem Xtext-basierten Editor. Applause selbstverfügt nicht über einen Debugger – hier mussder Entwickler auf die jeweiligen Tools derZielplattform zurückgreifen. Derzeit gibt esnoch keine Unterstützung für einen platt-formübergreifenden Build, der sich in eineCI-Umgebung integrieren ließe. Mit Applause erstellte Applikationen ge-hören in die Kategorie der generierten Apps.Für die Kategorie der datengetriebenen Appseignet sich dieser Ansatz recht gut, allerdingsist er nur bedingt für die Umsetzung von sehrindividuellen Apps geeignet. Sollte der mitge- Abb. 11: Applause IDElieferte Generator nicht den eigenen Ansprüchen genü- verwunderlich, dass es tatsächlich einige Tools gibt, diegen, kann er durch eine eigene Implementierung ersetzt Eclipse als Basistechnologie nutzen, wie z. B. RAP undwerden. Applause. Andere nutzen Eclipse „nur“ als IDE. Da viele Die aktuelle Version von Applause ist vor allem als der Tools aus der Webentwicklerszene stammen, ist esMachbarkeitsstudie zu verstehen, die nächste Version kaum verwunderlich, dass entweder kein oder nur ru-soll sowohl hinsichtlich der Erweiterbarkeit der DSL als dimentärer IDE-Support geboten wird oder erst nach-auch der Generatoren weiterentwickelt werden. träglich hinzugefügt wurde. Tools wie Sencha Touch wiederum enthalten gar eine eigene, selbstgeschriebeneFazit IDE (hier Sencha Architect) oder gehen wie jQuery Mo-Die Vielzahl der derzeit am Markt befindlichen Frame- bile davon aus, dass man entweder nur einen Texteditorworks zur plattformübergreifenden Entwicklung von oder eine auf Webdesign spezialisierte IDE wie Dream-mobilen Anwendungen spiegelt sich auch in der Land- weaver verwendet. Auch das Thema Cloud IDE spielt beischaft für Entwicklungsumgebungen wider. Angesichts einigen Frameworks eine Rolle – so ist z. B. Trigger.io nurder Innovationskraft der Eclipse-Community ist es nicht als Cloud-Lösung verfügbar.www.eclipse-magazin.de eclipse magazin 4.12 19
  8. 8. Titelthema Cross-Platform Mobile Development Die Wahl der richtigen Plattform für ein (plattform- [6] http://www.iui-js.org/ übergreifendes) mobiles Projekt ist eine Entscheidung, die [7] http://www.winktoolkit.org/ hauptsächlich von der Art der umzusetzenden App ab- [8] http://www.lua.org/ hängt. Plattformübergreifendes Entwickeln ist kein Wert [9] http://incubator.apache.org/cordova/ in sich, sondern unterliegt wie so vieles andere auch dem [10] http://phonegap.com/about/features Designgrundsatz „Form follows Function“ – die Form [11] https://github.com/imhotep/PhoneGap.tmbundle folgt der Funktion. Die Vielfalt der verfügbaren Lösun- gen kann man daher getrost als Bereicherung ansehen. [12] http://bit.ly/gLTJoy Eine detaillierte Auseinandersetzung mit den einzelnen [13] http://www.mobiledevelopersolutions.com/ hier vorgestellten Ansätzen ist unter [27] zu finden. [14] http://build.phonegap.com/ [15] http://wiki.eclipse.org/RAP/FAQ#Single_Sourcing Peter Friese arbeitet als Principal Consultant für Zühlke Enginee- [16] http://wiki.eclipse.org/RAP/Protocol ring. Seine Schwerpunkte liegen auf der modellgetriebenen Soft- wareentwicklung, der plattformübergreifenden Entwicklung von [17] http://www.eclipse.org/windowbuilder/ mobilen Anwendungen (u. a. für iOS, Android, Windows Phone 7 [18] https://github.com/eclipsesource/rap-mobile-demos und Mobile Web) sowie Eclipse als Plattform. Peter bloggt auf http://www.peterfriese.de und twittert unter @peterfriese. [19] http://rapmobile.eclipsesource.com/demos/ [20] http://blogs.apache.org/flex/ Links & Literatur [21] http://fdt.powerflasher.com/ [22] http://bit.ly/JA7F2A [1] http://twitter.github.com/bootstrap/ [23] http://adobe.ly/mRyJx7 [2] http://foundation.zurb.com/ [24] http://adobe.ly/k03nBY [3] Stark, Jonathan: „Building iPhone Apps with HTML, CSS, and JavaScript“, O‘Reilly Media, 2010 [25] http://adobe.ly/Icz7RV [4] http://jquerymobile.com/ [26] http://applause.github.com/ [5] http://www.sencha.com/products/touch [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, iOS, Android, iOS, Android iOS, Android, iOS, Android, WP7 BlackBerry, webOS, (BlackBerry) BlackBerry Bada, Symbian Sprache JavaScript JavaScript Java ActionScript/MXML DSL Abstraktionsschicht Wrapper, webbasiert Bridge API zwischen Command-basierter Bridge API (Flex + AIR keine JavaScript und nativer Ansatz Runtime) zwischen Plattform ActionScript und nativer Plattform Debugger nein ja ja ja nein IDE rudimentär, nicht ja, Eclipse-basiert ja, Eclipse ja, Eclipse-basiert ja, Eclipse-basiert plattformübergreifend IDE-Plattformen Mac OS X, Windows Mac OS X, Windows Mac OS X, Windows, Mac OS X, Windows Mac OS X, Windows Linux Hilfe/Support online online/in Eclipse Ausführlich für SWT Ausführliches nein integriert vorhanden, RAP Hilfesystem Mobile selbst noch wenig dokumentiert Qualität Look and Feel webbasiert/abhängig nativ nativ Flex/kann gestylt nativ vom verwendeten werden UI-Framework Performance ausreichend gut sehr gut gut sehr gutTabelle 1: Vergleich der Tools und Frameworks20 eclipse magazin 4.12 www.eclipse-magazin.de

×