Im Gespräch mit Jochen Krause und Holger Staudacher

RAP mobile: Eclipse Rich Ajax Platform für mobile Geräte

Mit RAP mobile hat EclipseSource ein neues Projekt ins Leben gerufen, das das Prinzip der Rich Ajax Platform (RAP) auf den Mobile-Bereich überträgt. Wir sprachen mit EclipseSource CEO Jochen Krause und EclipseSource Software-Engineer Holger Staudacher über Ziele und Hintergründe von RAP mobile.

JAXenter: RAP mobile ist ein neues Projekt aus dem Hause EclipseSource. Worum handelt es sich dabei?

Der Name des Projektes beinhaltet schon Hinweise auf den Funktionsumfang. RAP mobile bringt die Eclipse Rich Ajax Platform (RAP) auf mobile Geräte. Grundsätzlich können Entwickler mit RAP Multi-User-Anwendungen auf Basis der SWT API in Java schreiben. Bisher konnten RAP-Anwendungen lediglich über den Browser bedient werden.

Mit RAP mobile gehen wir nun einen Schritt weiter. Wir haben native Clients entwickelt, die eine RAP- bzw. SWT-Anwendung auf mobilen Gerät darstellen. Dabei läuft der Kern der Anwendung wie bisher auf der Server-Seite. Anwendungsdaten werden lediglich zur Präsentation zum Client mittels HTTP(S) übertragen. Somit sind empfindliche Daten auch bei Verlust des mobilen Gerätes sicher auf dem Server und können nicht unbefugt genutzt werden. Die mobilen Clients bauen das auf dem Server definierte UI mit nativen Widgets auf. Sie sind somit sehr schnell und profitieren von der Usability der zu Grunde liegenden Plattform.

JAXenter: Auf welchem Technologie-Stack baut RAP mobile auf?

RAP mobile setzt den Open-Source RAP-Server unverändert ein. Der RAP-Server basiert auf Servlet-Technologie, was bedeutet, dass der Server mit jedem JEE Servlet-Container bzw. Application-Server genutzt werden kann. Darüber hinaus baut RAP auf das bekannte Modularisierungssystem OSGi auf und erlaubt so eine gute Strukturierung von Anwendungen. Durch die Verwendung von OSGi erschließt sich auch der gesamte Eclipse-Runtime-Technologie-Stack wie z.B. EMF, Birt, Scout, Virgo, Riena und viele mehr. Die Verwendung von OSGi ist jedoch optional, RAP kann auch als Library in ein Webarchiv (.war) eingebettet werden.

Auf der Client-Seite setzt RAP mobile auf die nativen Widget Toolkits der jeweiligen Plattform, ähnlich wie dies auch bei SWT auf dem Desktop der Fall ist. Ein SWT Button wird auf dem Client durch einen iOS bzw. Android Button dargestellt. Die Definition des User Interface geschieht also in Java mit SWT. Diese Definition wird auf dem Server zur Laufzeit in eine JSON-Repräsentation übersetzt und an den Client gesendet. Die JSON-Repräsentation ist nicht plattformspezifisch. Der Client erstellt anhand der übertragenen JSON-Repräsentation ein natives UI.

Durch diese Architektur ist es unkompliziert, weitere Plattformen wie z.B. Windows Phone zu unterstützen. Die einzige Voraussetzung ist, dass die zu Grunde liegende Plattform (und Sprache) mit JSON umgehen kann, was mittlerweile die Regel darstellt. Der Technologie-Stack auf der Client-Seite ist also zum einen ein JSON-Parser und zum anderen die native UI-Bibliothek bzw. Plattform. Bei den derzeitigen Clients sind dies also Objective-C bzw. iOS für Apple-Geräte und Java für den Android Client.

JAXenter: Welche Vorteile bringt RAP mobile gegenüber einer nativen Entwicklung für iOS, Android oder Windows Phone?

Die Antwort auf diese Frage liegt schon in der Aufzählung der verschiedenen Plattformen verborgen, nämlich Multi-Platform! Wenn sich ein Unternehmen heute entscheidet, eine Mobile App anzubieten, steht es zuerst einmal vor einer weitreichenden Entscheidung. Soll die App für eine oder für eine Vielzahl von Plattformen entwickelt werden. Mit immer weiter steigendem Marktanteil von Android-Geräten beinhaltet die Antwort auf diese Frage meistens mindestens zwei Plattformen: „Zumindest iOS und Android müssen unterstützt werden!“. Aber auch Blackberry hat eine große installierte Basis und Windows Phone könnte zukünftig auch eine wichtige Rolle spielen.

Diese Anforderung bedeutet, dass die App-Entwickler die gleiche App für zwei oder mehr grundverschiedene Plattformen entwickeln müssen. Dabei sollte darauf geachtet werden, dass das UI ähnlich zu bedienen ist, ohne jedoch gegen die plattformspezifischen Nutzungsmuster zu verstoßen. Dies resultiert zwangsläufig in einer großen Redundanz an Quellcode bzw. Wissen und stark erhöhten Entwicklungs- und Wartungsaufwänden. Dies kann mit RAP mobile vermieden werden.

Bei RAP mobile wird die Anwendung lediglich einmal, nämlich in Java bzw. SWT, programmiert und über die nativen Clients dargestellt. Ein weiterer Pluspunkt für RAP mobile ist die Einbettung in eine stabile und reife Plattform, die MVC (JFace) und Databinding unterstützt. Auch die einfache Einbettung weiterer OSGi-Komponenten ist möglich. Nicht unerwähnt bleiben sollte auch die einfache Durchführung von Updates. Während plattformspezifische Apps neue Versionen ausliefern und auf jedem Gerät installieren müssen, kann bei RAP mobile einfach die Server-Seite aktualisiert werden.

Auf der anderen Seite bedeutet die Verwendung von SWT aber auch eine Einschränkung des Funktionsumfangs des Widget Toolkits. Für den Zielmarkt für RAP mobile, nämlich sichere Geschäftsapplikationen, stellt diese Einschränkung aus unserer Sicht jedoch kein nennenswertes Problem dar. Mit RAP mobile lassen sich bereits sehr ansprechende Applikationen erstellen, die auch die typischen nativen Animationen und Bedienmuster unterstützen.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.