RoboVM: Mit Java iOS-Applikationen erstellen
Seite 3: Konfiguration und Einsatzmöglichkeiten
Flieg kleiner Freund, flieg!
Hat man die zuvor genannten Punkte erfolgreich durchgeführt, kann man über eine Run-Definition, wie bei Eclipse üblich, die Startbedingungen definieren:
Es ist möglich, die App sowohl auf einem physischen Device zu testen, das mit dem Rechner verbunden ist, als auch über einen der mit der installierten Xcode-Version mitgelieferten Emulatoren.
Sollten sich Leser wundern, welche Bewandtnis es mit dem Intel-Code (erkennbar an den x86-Einstellungen in der Abbildung 4) in einem iPhone-Kontext hat: Die Erklärung liegt darin, dass Apples Emulatoren bereits seit der ersten Version keinen Kern zum Ausführen von Code für ARM-Architekturen enthalten beziehungsweise emulieren und anstelle dessen direkt den Code für einen Intel-Prozessor ausführen. Das ist zwar sowohl bei der Kompilierung als auch während der Programmausführung schnell, kann aber gegebenenfalls zu nicht erkennbaren Fehlern führen. Als Folge dessen ist die Applikation für den Einsatz auf einem physischen Gerät neu zu übersetzen.
Beim ersten Aufruf einer neuen Plattform werden vorab alle vorhandenen Bibliotheken übersetzt, was auf dem System des Autors mehrere Minuten dauerte. Die darauf folgenden Programmstarts werden innerhalb einer recht kurzen Zeit durchgeführt, da dann wirklich nur noch der geänderte und hinzugefügte Code übersetzt und gelinkt wird.
Der Aufruf des Programms geschieht weiterhin unter der Kontrolle von Eclipse und ihrer Debugging-Features. Leider waren große Teile der Debugger-Brücke in der vorliegenden Beta-Version nicht freigeschaltet, sodass sich der Autor kein Urteil über die entsprechenden Möglichkeiten bilden konnte.
Wofür nun das Ganze?
Sucht man im Internet geeignete Threads, findet man einige interessierte Entwickler, die sich in zwei Gruppen aufteilen. Eines haben sie gemeinsam – es existiert häufig bereits eine Android-Applikation, die nun auf iOS zu portieren ist.
Die erste Gruppe bilden Spiele-Entwickler, deren Chancen recht hoch sind, innerhalb kurzer Zeit eine erfolgreiche Portierung durchzuführen. Das lässt sich damit begründen, dass die meisten Features der Android-Umgebung bereits integriert sind und die Parallelentwicklung in Xcode und Eclipse gar nicht oder kaum notwendig ist, da Spiele teilweise oder komplett auf Dialoge verzichten oder eigene minimalistisch Dialogimplementierungen mitbringen. Sie profitieren von der im Vergleich zu Java wesentliche höheren Ausführungsgeschwindigkeit des Kompilats und von den recht vagen UI-Vorschriften für Spiele in den AppStore-Vorschriften.
Auf der anderen Seite stehen die Entwickler dialogorientierter Apps. Auf sie wartet einiges an Neuland (etwa Apples Interface-Konzept und strenge UI-Vorschriften) und die Unstimmigkeiten zwischen den Beispielen und der aktuellen API-Version. Auch viele nicht oder nur unzureichend beschriebene manuelle Schritte erfordern Kenntnisse der Apple-Umgebung und Rechercheaufwand, zumal die Informationen derzeit noch recht dünn gesät sind. Dazu kommt der recht hohe Aufwand, den man treiben muss, um einen Dialog anzuzeigen und zu pflegen.
Auf der Plusseite verbucht man hier natürlich das parallele Benutzen einer weitgehend gleichen Codebasis für zwei Plattformen, was man durch den Einsatz bestimmter Techniken noch optimieren kann. Darüber hinaus gibt es für viele Einsatzgebiete passende Java-Bibliotheken samt Tooling, die man für Objective-C oder Swift gar nicht finden kann. Hierbei sei beispielhaft JAXP genannt, das ein deutlich einfacheres Nutzen von komplexen Webservices und allgemein XML erlaubt, als der einfache SAX-Parser, der in den iOS-Bibliotheken integriert ist.
Beiden, sowohl den Spiele- als auch den Dialog-App-Entwicklern kommt zu Gute, dass man nicht nur keine neue Programmiersprache erlernen muss, sondern in den Programmen vertraute Techniken wie Reflections und Annotationen verwenden kann. Dazu kommt noch die wohlbekannte Bedienung von Eclipse (oder gegebenenfalls auch IntelliJ IDEA) mit den mittlerweile sehr umfangreichen Refactoring-Fähigkeiten, an denen es in Xcode fehlt beziehungsweise die im Falle von Swift bisher noch nicht fertig umgesetzt wurden.
Zumindestens eines der erwähnten Build-Werkzeuge sollte einem Java-Programmierer bekannt sein. Bei Gradle oder Maven fällt auf, dass sie in der Bedienung deutlich handlicher und speziell bei der Beachtung gewisser Konventionen einfacher anzuwenden sind als die in Xcode recht rudimentär vorhandenen Entsprechungen. Mit ein wenig Mühe und ein paar Plug-ins sollte es auch möglich sein, nicht nur den Build-Prozess von manuellen Schritten zu befreien. Auch der gezielte Aufruf des Xcode-Interface-Builder-Editors, die Zwei-Wege-Generierung und Ergänzung der parallelen Klassen in Java und Xcode sollten zwar nicht trivial, aber im mittleren Schwierigkeitsbereich angesiedelt sein.
Ähnliches war kurz nach dem Erscheinen von Xamarin möglich geworden. Das einzig Problematische dabei könnte der durch den Prozess veränderte Code in den Java-Klassen sein. Da ist Xamarin dank der Technik der partiellen Klassen in C# wesentlich besser dran. Und leider gibt es unter Eclipse auch keinen gängigen Editor, der analog zu der NetBeans-IDE partielle, nicht editierbare Bereiche kennt, die dann für automatische Code-Änderungen zur Verfügung stehen.
Spezialeffekte gewünscht?
Einige Projekte beschäftigen sich damit, JavaFX auf diversen Plattformen lauffähig zu machen. Seit RoboVM ist es nun möglich, mit dem Framework erstellte Anwendungen auf einem iOS-Gerät auszuführen. Leider ist JavaFX auf mobilen Geräten, nicht nur auf iPhone und iPad, immer noch nicht zu gebrauchen. Das liegt einerseits daran, dass die UI-Elemente viel zu klein sind und anderseits ist die Bedienung immer noch eher auf eine Desktop-Umgebung mit Maus ausgelegt, weshalb die Anwendungen nicht nativ wirken.
Auch mit nachträglichen Anpassungen der Bedienelemente wird es äußerst schwierig, wenn nicht unmöglich sein, die Hüter des App Store zu überlisten. Hier ist Oracle wohl gerade dabei, das in JavaFX vorhandene Potenzial, eines der führenden Frameworks zur Oberflächengestaltung nicht nur für Desktop-, sondern auch für mobile Anwendungen zu werden, zu vernichten. Davon abgesehen, lässt sich die Demo-Anwendung ohne Anpassungen kompilieren und komplett testen.
Beim Versuch, die Beispiel-Anwendung aus GitHub zu kompilieren, ist im Übrigen darauf zu achten, dass eine aktuelle Version von Java 8 (mindestens u40) auf dem Mac installiert ist.
