Mobile Cross Plattformen

von - Antworten

Apple brachte 2007 das iPhone auf den Markt, und revolutionierte damit die Entwicklung und Vermarktung von mobilen Apps. Andere Mobilplattformen wie Symbian und Windows Mobile waren darauf nicht gut vorbereitet und verschwanden mehr und mehr von der Bildfläche. Apple hatte lange Zeit den größten Marktanteil im Bereich mobile Apps.

In den letzten Jahren drängten zunehmend neue und verbesserte Mobilplattformen auf den Markt und machen Apple seine Anteile streitig – Android (73.6%), iOS (16.9%), Windows Phone (6.1%) und Blackberry (0.5%). Für die App Entwicklung heißt das, dass Apps für unterschiedliche Plattformen erstellt werden müssen. Somit steigen Aufwand und Kosten für eine App, denn der Sourcecode kann nur schwer bis gar nicht zwischen den Plattformen geteilt werden.

Um die Kosten zu senken und die Entwicklungszeit zu verkürzen, gibt es viele Lösungsansätze im Bereich Mobile Cross Plattformen mit dem Ziel eine App plattformübergreifend zu entwickeln. Die Ansätze können grob in Web basierte und native Cross Plattformen unterteilt werden.

Web basierte Cross Plattformen

Web basierte Cross Plattformen machen sich die Eigenschaft zunutze, das alle Smartphones Webtechnologien nutzen. Mittels HTML5, CSS und Javascript kann eine sogenannte Web App schnell und einfach für alle Mobilplattformen umgesetzt werden.

Auf dem ersten Blick scheint dieser Lösungsansatz sehr zufriedenstellend zu sein. Er birgt aber auch große Nachteile. Web Apps bedeuten immer Kompromisse im UI Bereich, die Offlinefähigkeit ist eingeschränkt wie auch der Zugriff auf Gerätefunktionen. Die Performance ist gering bis mittel, eben nicht zu vergleichen mit „echten“, d.h. nativen Apps.

Web basierte Cross Plattform Tools sind beispielsweise Appcelerator Titanium, AppFurnace, IUI, AMPchroma und PhoneGap.

Native Cross Plattformen

Native Cross Plattformen kapseln den Zugriff auf die Mobilplattformen für den Entwickler. Es gibt einen abstrakten Layer, welcher die plattformspezifischen Aufrufe übernimmt. Dadurch kann ein Feature oberhalb des Layers einmal entwickelt werden und trotzdem auf mehreren Mobilplattformen laufen. Unterhalb des Layers wird plattformspezifischer Code verwendet.

Dieser Lösungsansatz versucht die Nachteile des Web basierten Ansatzes zu verhindern, indem er „echten“, d.h. nativen Zugriff auf die Mobilplattformen gewährleistet. Die Apps können durchaus komplexer sein, da man hardwarenäher und auch performanter entwickeln kann.

In diesem Artikeln haben wir vier native Cross Plattformen untersucht:

Codename One

Xamarin

Corona

Marmalade

Cross Plattform: Codename One

Codename One ist eine Java basierte Plattform, welche erst 2012 auf den Markt kam. Codename One unterstützt iOS, Android, Windows Phone 8 und Blackberry. Als Entwicklungsumgebung eignen sich Eclipse und Netbeans mit speziellen Plugins, die einen UI Designer und einen Simulator enthalten.

Codename One bietet gute UI Toolkits basierend auf Java Swing, welche aber plattformspezifisch sind. Zum Beispiel die iOS Tabbar und Android Tabbar sind den Mobilplattform Styles nachgebildet.

Um die App auf Geräten laufen lassen zu können, wird der Sourcecode zum Codename One Buildserver geschickt und dort für die entsprechende Mobilplattform kompiliert. Am Ende kann man die erstellten, binären Installationspakete bequem per QR-Code scannen und herunterladen bzw. installieren. Debuggen auf einem Gerät ist aber nicht möglich.

Für die Nutzung des Buildservers und technische Unterstützung benötigt man eine Lizenz. Eine Codename One PRO Lizenz kostet $79 monatlich.

Cross Plattform: Xamarin

Xamarin ist eine C# basierte Plattform. Man benötigt das Xamarin Studio unter MAC OS oder Visual Studio unter Windows. Zusätzlich müssen Android SDK und iOS SDK installiert werden, um den Sourcecode kompilieren und die Emulatoren nutzen zu können. Xamarin unterstützt Android und iOS auf Windows und MAC.

Im Bereich UI verwendet Xamarin jeweils die nativen SDKs. Das bedeutet, dass die UI je Plattform geschrieben werden muss und damit echt nativ ist. Der UI unabhängige Sourcecode (Datenhaltung und Logik) wird aber gemeinsam von allen Mobilplattformen genutzt.

Da Xamarin native SDKs und Emulatoren verwendet, gibt es nur wenige Überraschungen bei Tests mit Emulatoren gegenüber Tests auf Geräten. Als Ergänzung bietet Xamarin eine TestCloud, um die Apps remote auf unterschiedlichen Geräten testen zu können.

Eine Xamarin Business Lizenz kostet $999 pro Jahr.

Cross Plattform: Corona

Corona ist eine LUA Skript basierte Plattform. Es gibt keine umfangreiche IDE, aber einen Editor und Emulator. Corona unterstützt iOS und Android.

Corona bietet einige UI Komponenten, wie Tabbar und Tabellen. Diese UI Komponenten sind plattformunabhängig. Es ist möglich, direkt im Skript native Funktionen aufzurufen.

Um die App auf Geräten laufen lassen zu können, wird der Sourcecode zum Corona Buildserver geschickt und dort für die entsprechende Mobilplattform kompiliert. Debuggen ist generell nicht möglich, weder auf dem Emulator noch auf den Geräten.

Eine Corona PRO Lizenz kostet $50 pro Monat und eine Enterprise Lizenz kostet $85 pro Monat.

Cross Plattform: Marmalade

Marmalade ist eine C/C++ basierte Plattform. Sie nutzt zudem auch HTML5 und Lua Skript. Marmalade unterstützt iOS, Android, Blackberry undWindows Phone 8. Die IDE ist unter MAC OS in Xcode integriert, dadurch kann der native Emulator verwendet werden.

Marmalade bietet nur einfache UI Komponenten, wie Label und Button, aber komplexeren Komponenten wie Tabellen, Navigationsbars oder Tabbars.

Eine Marmalade Indie Lizenz kostet $499 pro Jahr und eine Plus Lizenz kostet $1499 pro Jahr.

Vergleich der vier Cross Plattformen

  1. Codename One
  2. Xamarin
  3. Corona
  4. Marmalade

Pros:

  • one code, run everywhere
  • good debug/test
  • Java
  • very good IDE
  • iPhone/iPad
  • native UI
  • 3rd Party library possible (C#)
  • use native simulators
  • TestCloud
  • one code, run everywhere
  • Corona Enterprise:call any Objective-C or Java library from within Corona
  • Offline build
  • html5hybridApp
  • very good performance
  • gaming
  • iOS on Windows possible

Cons:

  • not the real native UI feeling
  •  build on server only
  • no 3rd party library
  • different UI view between simulator and device
  • View&Controller is platform dependent (separated coding required)
  • Lua script not yet popular
  • UI not really good
  • Revenue limit
  • license cost high – not good as native UI

Projektbeispiel „Trashbusters“

Wir haben anhand des Beispielprojekts „Trashbusters“ eine native Cross Plattform getestet. Trashbusters“ ist eine ortsbasierte App für iOS und Android, in der man Müllhotspots in einer Stadt melden kann. Die Hauptanforderungen waren:

Kamerazugriff, um ein Bild des Müllbergs aufzunehmen. Das Bild kann eventuell auch aus der Gallery ausgewählt werden.

GPS Nutzung, um den Standort des Müllhotspots festzuhalten.

Netzwerkzugriff, um alle Informationen zu einem Server übertragen und sammeln zu können.

Die eingetragenen Müllhotspots mit Bild und Ort auf einer Karte darstellen.

Da die App eine Tabellenansicht, eine Tabbar und eine Navigationsbar haben sollte, erschienen Corona und Marmalade nicht passend für das Projekt. Unter Xamarin muss der Bereich UI je Plattform entwickelt werden, so dass der Aufwand steigt. Wir haben uns also für Codename One entschieden.

Fazit

Das große Ziel der mobilen Cross Plattform Entwicklung ist es eine App gleichzeitig für verschiedene Mobilplattformen erstellen und so Apps schnell und kostengünstig auf den Markt bringen zu können. Der Entwickler muss nicht alle nativen Sprachen bzw. Mobilplattformen kennen und beherrschen, um diese Aufgabe zu erfüllen. Das Konzept lautet „one code, run everywhere“. Es wird einmal entwickelt und läuft auf allen Geräten. Das Konzept ist sinnvoll und zukunftsweisend, aber die Cross Plattformen können zur Zeit noch nicht die nativen SDKs ersetzen.

Die nativen Cross Plattformen (Ausnahme Xamarin) haben eigene, nachgebildete UI Komponenten, die zwar ähnlich den nativen Komponenten aussehen, sich aber trotzdem unterschiedlich verhalten können. Die Zeit des Testens auf verschiedenen Geräten wird nicht gespart, sondern im Gegenteil eher erschwert. In unserem Beispielprojekt kam es zu großen Unterschieden zwischen Tests mit dem Emulator und Tests auf Geräten.

Manche native Cross Plattformen bieten keine Debug Möglichkeit. Dadurch dauert die Fehlersuche beim Testen und Bugfixing länger gegenüber nativer Entwicklung. Wenn eine Cross Plattform ein natives SDK Feature nicht unterstützt, muss die fehlende Funktion selbst geschrieben oder das Projekt sogar eingeschränkt bis verworfen werden. Bestenfalls kennt man vor dem Einsatz einer Cross Plattform alle unterstützten und auch nicht unterstützten Features.

Ein weiterer großer Zeitfresser ist das Kompilieren des Sourcecodes auf einem Buildserver. Es dauert zwischen einigen Sekunden bis mehreren Minuten. Ein Buildserver birgt zudem die Gefahr, dass der eigene Sourcecode nicht geheim und im eigenen Haus bleibt. Man verliert die Hoheit über den Sourcecode und den Kompilierprozess. Man kann nicht sicherstellen, dass das erstellte App Paket keinen fremden, unsicheren Code enthält. Für viele App Projekte ist so eine Cross Plattform also völlig ungeeignet.

Ob eine native Cross Plattform eingesetzt werden kann oder nicht, hängt von vielen Faktoren ab. Unsere Erfahrung aus dem Beispielprojekt zeigt, dass die native Cross Plattform Entwicklung keinen Zeitgewinn gegenüber der nativen Entwicklung für zwei Plattformen darstellt. Im Bereich UI sehen wir die größten Schwierigkeiten zufriedenstellende Ergebnisse zu erhalten.

Autoren: Jeanette Kelling und Pai Peng von der mobile melting GmbH (mobile-melting.de)

Ihre Meinung

© 2016 Info Bonus – Das Artikelverzeichnis