© DrHitch/Shutterstock.com
Shortcuts
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.

Shortcut Autorenteam


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 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): 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 gespeichert Das Datenmodell des Beispielprojekts ist schnell erfasst (Abb. 3.3).Die projektspezifischen Besonderheiten finden sich im Datenmodell wieder. Die Beziehung zwischen Auftrag und Positionen ist im Auftra...

Shortcuts
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.

Shortcut Autorenteam


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 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): 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 gespeichert Das Datenmodell des Beispielprojekts ist schnell erfasst (Abb. 3.3).Die projektspezifischen Besonderheiten finden sich im Datenmodell wieder. Die Beziehung zwischen Auftrag und Positionen ist im Auftra...

Neugierig geworden?


    
Loading...

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