© DrHitch/Shutterstock.com
Xtend beyond Java

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


Im zweiten Kapitel habe ich bereits einen groben Überblick über die DSL gegeben [1]. Jetzt sehen wir uns das Resultat in einem Projekt genauer an.

Eine Vorbemerkung: Eine DSL bezieht sich immer, wie „domain-specific“ bereits ausdrückt, auf bestimmte projektspezifische Annahmen, Regeln oder Use Cases. In unserem Fall handelt es sich um mobile Businessanwendungen, wo Stamm- und Bewegungsdaten vom Server abgerufen und erfasste bzw. geänderte Daten per REST-API an den Server zurückgesandt werden. Ein Offlinemodus muss voll gewährleistet sein, damit Mitarbeiter (z. B. Servicetechniker) unabhängig und transparent arbeiten können – auch wenn gerade kein Netz vorhanden ist. Eine weitere wichtige Annahme in dieser DSL: Alle Daten können im Speicher gehalten werden, wobei durch die Verwendung von C++-Pointern des Typs QObject* der Speicherbedarf gering ist, da auch im UI (QML) mit den Pointern gearbeitet wird, also kein By-Value-Mapping erfolgt. Selbst das Einlesen größerer Datenmengen ist problemlos durch asynchrones „Nachladen“ umgesetzt, worauf ich aber in diesem Kapitel nicht näher eingehe. Es gibt andere Situationen, wo die Daten nicht In-Memory verfügbar sind, sondern immer per Query aus der SQLite gelesen werden – aber das ist dann eine andere DSL. Das Datenmodell und das Eclipse-Projekt befinden sich auf GitHub. Es ist ein simples kleines Projekt, das folgende Daten enthält (Abb. 3.1):

  • Aufträge und Auftragspositionen
  • Kunden, die einem Auftrag zugeordnet werden können
  • Schlagworte, die einem Auftrag als Suchkriterien zugewiesen werden können
gentz_1.jpg

Abbildung 3.1: Beispielprojekt: Beziehungen

Einige Besonderheiten habe ich eingebaut, die typisch für Businessanwendungen sind. Einige Daten existieren nur im Zusammenhang mit anderen, manche Daten werden vom Server empfangen, dienen aber nur als „Look-up“-Daten, die nicht am mobilen Gerät geändert werden. Die vom Server übertragenen Datenmengen können sehr unterschiedlich sein, ebenfalls die Datenstrukturen. Hier ein paar Informationen, welche Besonderheiten in das Beispielprojekt eingebaut wurden (Abb. 3.2):

gentz_2.jpg

Abbildung 3.2: Beispielprojekt: Persistierung

  • Positionen sind Bestandteil von Aufträgen, d. h., sie können nicht alleine existieren. Wird ein Auftrag gelöscht, werden auch alle Positionen kaskadierend gelöscht.
  • Schlagworte werden in der mobilen App nicht geändert, sind also nur „read-only“.
  • Kundendaten sind sehr groß und werden daher in einer SQLite-Tabelle gecacht. Alle anderen Daten werden direkt als JSON ge...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang