© DrHitch/Shutterstock.com
Xtend beyond Java

2 Beschleunigte Entwicklung von C++- und Qt-basierten Anwendungen - Teil 1


Wer einmal MDSD (Model-driven Software Development) erfolgreich in Projekten eingesetzt hat, mag es nicht mehr missen. Vor mehr als zehn Jahren habe ich mit oAW (openArchitectureWare) [1] gearbeitet, und über einen langen Zeitraum war es elementarer Bestandteil meiner Lösungen. In den letzten Jahren hat sich aber mein Fokus hin zu mobilen Businessanwendungen für BlackBerry verschoben. Die IDE ist immer noch Eclipse (Eclipse Momentics) [2], programmiert wird aber in C, C++, Qt, QML – und ich weiß nicht, wie oft ich mir während der Entwicklung einen generativen Ansatz zurückgewünscht habe. Jetzt gibt es Licht am Ende des Tunnels: „ekkes DSL 4 Cascades“ ist ein erster Start. Was damit bereits möglich ist, zeigt dieses Kapitel auf.

Florian Pirchner und Klemens Edler beschreiben in ihrem Kapitel „DSLs mit Xtext, Sirius und Vaadin“ sehr gut die Qualen eines Entwicklers von Businesssoftware. Vieles davon trifft auch auf die Entwicklung mobiler Business-Apps zu – unabhängig vom OS (Android, BlackBerry10, iOS, Windows).

Vorweg: Ich spreche hier von anspruchsvollen, komplexen und nativen Apps. Handelt es sich um webbasierte Apps, dann kann das Szenario ähnlich wie bei Florian und Klemens beschrieben auch mit Vaadin und Co. gelöst werden. Es gibt viele Apps, für die der Webansatz (HTML5, CSS, JS) richtig ist, und es ist sicherlich oft eine Erleichterung, mobile Apps plattformübergreifend schreiben zu können. Meine Anwendungen mit komplexen Workflows, tiefer Integration in das Betriebssystem, Zugriff auf alle Sensoren und Events des darunter liegenden OS bei gleichzeitig intuitivem UI mit cooler UX sind derzeit aber nur durch eine native Umsetzung zu lösen. In diesem Kapitel beziehen sich alle Lösungen auf Anwendungen für BlackBerry 10 im Enterprise-Umfeld. Geplant ist eine entsprechende Version für Swift/iOS gegen Ende des Jahres.

Daten, Persistenz und Caching

Die Daten einer mobilen App werden in den meisten Fällen per Web Service (REST, SOAP) zur Verfügung gestellt. Um offline arbeiten zu können, benötigt man eine lokale Caching-Strategie, wobei sich das direkte Speichern von JSON oder der Einsatz einer SQLite-Datenbank bewährt haben. Geänderte oder neu erfasste Daten sind wieder an den Server zu senden, wobei der Einsatz einer Queue sinnvoll ist, um auch offline arbeiten zu können.

Am Gerät befindliche Daten werden im UI unterschiedlich dargestellt, sei es in einem List-Datenmodell oder in einer Detailseite. Änderungen an einzelnen Feldern (Properties) sollen sich sofort in anderen Fenstern oder Feldern auswirken oder dafür sorgen, dass sich ein Icon oder eine Textfarbe ändert. Dazu werden Events genutzt – im Falle von BlackBerry 10 ist das elegant und flexibel mit Qt Signals und Slots gelöst.

Das Problem ist aber, dass es eine Menge an Code „drumherum“ gibt, der kodiert werden muss, um all die genannten Anforderungen zu implementieren. Hier setzt meine DSL an: Der Entwickler soll dadurch entlastet werden, indem „langweiliger“ Code generiert wird. Die gesamte App-Entwicklung wird dadurch nicht nur beschleunigt. Der Entwickler kann dann auch Dinge nutzen, die sonst aufwändig zu programmieren sind.

Allerdings ist die DSL kein App-Generator. Der Entwickler muss also immer noch wissen, was er da tut. Sie ist auch kein UI-Generator. Die UI-Erzeugung steht deshalb nicht im Fokus, weil die meisten meiner Anwendungen ohnehin ein handgeschmiedetes UI bekommen. In Kürze sollen aber zumindest UI-Container mit generiert werden können, um eine formularbasierte Datenerfassung zu unterstützen.

Lunifera DTO DSL als Basis

Zunächst ein großer Dank an Florian Pirchner und Klemens Edler von Lunifera. Die dort entwickelte DTO DSL ist die Basis von „ekkes DSL 4 Cascades“ und ebenfalls Open Source bei GitHub unter der Apache-Lizenz bereitgestellt [3]. Die Aufgaben einer DTO sind ja ähnlich – ob nun im Kontext einer Vaadin-Webanwendung wie bei Lunifera oder in einer mobilen BlackBerry-10-App. Die Dokumentation der DTO DSL gilt zunächst einmal sinngemäß auch für ekkes DSL 4 Cascades. Auch die Modelle selbst sehen daher ähnlich aus. Abbildung 2.1 zeigt ein Beispielmodell. Bei GitHub steht ebenfalls eine Beispiel-App zur Verfügung [4].

gentz_xtend_1.jpg

Abbildung 2.1: DTO-Modell

Eclipse im Duett oder Trio

Die mobile App-Entwicklung erfolgt mit der Eclipse Momentics IDE. Die DSL selbst benötigt Eclipse Luna mit Xtext und Xtend. Sofern die DSL „passt“, werden nur diese beiden Eclipse-Instanzen benötigt. Wer aber bei GitHub einen Fork der DSL Extension macht, um die Xtend-Templates anzupassen, muss während der Templateentwicklung noch eine Runtime starten, die dann die aktuellen Templates ausführt. In diesem Falle sind dann drei Eclipse-Instanzen gestartet. Die Arbeitsaufteilung der Eclipse-Instanzen:

  • Momentics: Der normale Entwicklungsworkflow mit Cascades (C++, Qt, QML) und den zugehörigen Editoren.
  • DSL: Eclipse mit allen von Lunifera benötigten Plug-ins, außerdem die Plug-ins org.lunifera.dsl.ext.cpp.qt.lib und org.lunifera.dsl.ext.dtos.cpp.qt, die alle Templates und Klassen für ekkes DSL 4 Cascades bereitstellen.
  • Runtime: Der DSL-Editor, um in Projekten komfortabel mit Content Assist das Domain Model zu beschreiben und daraus den Code zu generieren. Sollen die Templates nicht angepasst werden, werden die Projekte direkt aus der DSL-Instanz bearbeitet.

Einen Überblick über die Zuständigkeiten der Eclipse-Instanzen zeigt Abbildung 2.2

gentz_xtend_2.jpg

Abbildung 2.2: Eclipse-Trio: Momentics, DSL, Runtime

Die Codegenerierung erfolgt direkt in das zugehörige Momentics-Projekt – auch das DTO-Modell se...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang