(Bild: QT)
Eckdaten
Der Artikel beschreibt warum die Kombination aus deklarativem Benutzeroberflächen-Design mit imperativer Business-Logik es Entwicklern von Embedded-Systemen ermöglicht, bei minimalen Aufwendungen beziehungsweise Nacharbeiten neue Plattformen einzuführen. Gleichzeitig können die Vorteile der neuen Schnittstellenfunktionen auf jedem Gerät genutzt werden.
Die Massenmärkte für Smartphones und Tablets haben sich in den letzten Jahren stark verändert. In beiden Fällen hatte das Betriebssystem iOS von Apple eine frühe Führung übernommen, bevor Android und Windows 8 hinzukamen. Heute werden diese Märkte von Android dominiert. Aber auch innerhalb des Android-Ecosystems versuchen die Gerätehersteller, ihre Angebote zu differenzieren über eigens entwickelte Wearables und deren Entwickler-Ecosysteme. Die Märkte für Mobilgeräte werden sich auch weiter schnell ändern, da die Gerätehersteller neue Möglichkeiten suchen, sich vom Wettbewerb zu differenzieren.
Die Code-Wiederverwendung einer Multiscreen-Anwendung lässt sich maximieren, indem ein gemeinsamer Business-Logik-Teil für alle Plattformen eingeführt wird. Hinzu kommt ein Rapid-UI-Design mit einem deklarativen Ansatz, das die Layouts für jede Target-Variante unterscheidet. QT
Zu Smartphones und Tablets kommen immer mehr Embedded-Systeme hinzu, mit zunehmend umfangreicheren Benutzeroberflächen. Dazu zählen große Berührungs-/Touch- und Gesten-basierte Schnittstellen, beispielsweise im Automotive-Bereich. Aktionen, die bei herkömmlichen Embedded-Systemen aus einer Kombination schwer zu merkender Menüselektionen und Tastenbetätigungen bestehen, lassen sich nun mit einer einzigen Geste auf einem Touch-basierten Panel ausführen. Entweder können diese Panels fest mit dem Embedded-System verbunden sein oder im Falle eines Tablets mit dem System über eine Netzwerk- oder Internet-Verbindung kommunizieren. Die mobile Kommunikationsvariante entspricht einem Trend der allgemein auch als „Bring-Your-Own-Device“ bezeichnet wird.
Industrieller Einsatz
Im industriellen Einsatz lassen sich mit Smartphones und Tablets Maschinen direkt programmieren und überwachen. Einsetzbar sind zudem intelligente (smarte) Sensoren, die keine integrierte Benutzeroberfläche aufweisen, aber über ein Smartphone, Tablet oder einen PC zugänglich sind. Dies ist der neueste Trend bei der Embedded-Entwicklung für das Internet der Dinge (IoT).
Nutzer verlangen heute eine flexiblere Anwendung und Steuerung ihrer Elektronikgeräte im Haus und im Fahrzeug. Ein TV-Gerät verfügt nicht länger nur über eine Fernbedienung. Die Fernbedienung kann ein iPhone oder ein Android-Tablet sein, das jeweils eine andere Benutzeroberfläche bietet und die Gesten sowie das Look & Feel der Plattform nutzt. Auch das TV-Gerät hat seine eigene Benutzerschnittstelle, die sich weiterhin konsistent verhält, wenn der Nutzer zwischen den mobilen Geräten wechselt. Durch die zunehmende Zahl vernetzter Geräte sind daher Multiscreen- oder Multiple-Plattform-Embedded-Anwendungen nötig.
Da für immer mehr Anwendungen Multi-Plattform-Schnittstellen erforderlich sind, erhöhen sich Entwicklungsdauer und Ressourcenbedarf. Jede Plattform (Target) ist anders und verlangt eine speziell auf sie ausgelegte Anwendung. Treten Fehler auf, ist es Aufgabe des Entwicklungsteams, herausfinden, wie die verschiedenen Plattformen aufeinander ausgerichtet werden müssen, um Korrekturen vornehmen zu können.
Der Übergang zu Multi-Plattform-Anwendungen zwingt Software-Entwickler, außerhalb der üblichen Denkweise zu agieren, da sie ihre Software vollständig Plattform-unabhängig entwickeln müssen. Bei Musik-Streaming-Diensten beispielsweise befinden sich die Anwendungs- und Nutzerdaten im Cloud-Backend. Mehrere Client-Anwendungen greifen von überall auf diesen Dienst zu, über den Desktop, mobil, das Fahrzeug oder das TV-Gerät. Damit ist eine nahtlose Benutzererfahrung garantiert. Der Mehrwert dieses Dienstes ergibt sich aus den Cloud-Inhalten und daraus, wie einfach auf diese von verschiedenen Geräten zugegriffen werden kann.
Um die Inhalte darzustellen, ist es auch möglich, webbasierte Techniken zu verwenden, bei denen alles auf dem Client im Browser läuft. Die Back-End-Verarbeitung wird über einen Cloud-Server abgewickelt. Um volle Funktionalität in der Cloud bieten zu können, muss der Client allerdings immer verbunden sein. In vielen Fällen erweist sich dies als unpraktisch. Wird eine neue Geräteklasse mit anderen Benutzerschnittstellen-Funktionen eingeführt, muss selbst das Browser-basierte Look & Feel geändert werden. Trotz kontinuierlicher Verbesserung der Laufzeittechnologien sind HTML5-basierte UIs, nativen UIs (User Interface) bei Leistungsfähigkeit und durchgängiger Entwicklung oftmals unterlegen, da HTML5 ursprünglich nicht für die einfache Entwicklung skalierbarer Benutzerschnittstellen vorgesehen war.
Die optimale Lösung besteht nicht darin, dedizierte native Anwendungen für jedes Target zu schreiben. Stattdessen sollte ein Plattform-übergreifendes Software-Framework und eine klare Trennung der Core-Business-Logik und Präsentationsebene vorgenommen werden, um die erforderliche Flexibilität zu bieten.
Gleicher Code über alle Targets
Ziel ist es, nicht genau den gleichen Code über alle Targets hinweg zu verwenden, sondern den gemeinsam nutzbaren, geschriebenen Code zu maximieren und weiterhin eine ansprechbare Benutzeroberfläche unterstützen. Die richtige Programmgestaltung und eine modularisierte Code-Architektur vereinfachen dies. Einen Großteil der Core-Business-Funktionen und Datenverarbeitung erledigt der Plattform-übergreifende Code, der keine direkte Verbindung zur Darstellung hat. Die Präsentationsebene lässt sich in gemeinsame UI-Bereiche aufteilen, wie UI-Elemente und Themes, sowie in Target-abhängige Definitionen des tatsächlichen Layout-Managements. Letzteres spiegelt die Unterschiede zwischen Target-Bildschirm oder Plattform wider – von der Displaygröße bis hin zur unterstützten Interaktion. Damit ist es nöglich, die gemeinsamen UI-Elemente und Themes wiederzuverwenden. Die für einen Desktop oder ein mausorientiertes Betriebssystem entwickelte Layout-Managementebene der Darstellung, lässt sich anders handhaben, um der gestenreicheren Umgebung eines Smartphones zu entsprechen. In der Ebene darunter wird genau die gleiche plattform-übergreifende Core-Funktionalität genutzt (Bild 1).
Ereignisgesteuerte Ansprechbarkeit
Bei korrekt entwickelten Techniken kommunizieren die beiden Ebenen nahtlos miteinander und bieten die ereignisgesteuerte Ansprechbarkeit, die Anwender heute von Benutzeroberflächen erwarten. Entscheidend ist ein Plattform-übergreifendes Application-Framework, das nicht nur die Trennung der Business-Logik von der Darstellung vornimmt, sondern auch Mechanismen bereitstellt, die das Anpassen der Benutzeroberfläche für jedes Target vereinfacht und die Code-Wiederverwendung maximiert.
Ein Plattform-übergreifendes Application Framework garantiert, dass Business-Logik und Kernfunktionalität wiederverwendbar sind. Wohingegen jedes Betriebssystem die Netzwerkdienste auf seine eigene Weise freigibt, kann ein Framework diese Unterschiede durch ein gemeinsames API (Application Programming Interface) verbergen. Wie bei UI- und Netzwerk-fokussierten APIs enthält ein Framework unter Umständen eine Vielzahl von Modulen: für Datenbank-Zugriff, Multimedia-Funktion und gemeinsam vernetzte Funktionalität wie Kameras und GPS-basierte Ortungsdienste.
Traditionelle Techniken zur Verbindung der UI-Steuerung mit der Business-Logik umfassen Callbacks. Dabei handelt es sich um Pointer (Zeiger) auf C- oder C++-Funktionen. Tritt ein User-Interface-Ereignis auf, nutzt der Callback den Pointer, um der Funktion eine Änderung mitzuteilen. Bei diesem Ansatz treten zwei Probleme auf. Der Programmierer muss sicherstellen, dass der Callback mit den richtigen Argumenten aufgerufen wird. Dies verkompliziert die Wartung und kann zu Fehlern führen, bei Änderungen der Benutzeroberfläche. Außerdem verlangt dieser Ansatz eine enge Verknüpfung von Schnittstellen- und Business-Logik-Code, da jeder Callback genau wissen muss, auf welche Funktion er zugreifen muss.
Signals- und Slots-Ansatz
Die Lösung dieses Problems erfolgt durch einen flexibleren Mechanismus, bei dem Ereignisse bestimmte Signale erzeugen, die dann wiederum von einer oder mehreren Funktionen (Slots) verarbeitet werden. Dieser Signals-und-Slots-Ansatz ist flexibel, da sich die beiden Teile nicht kennen müssen. Über ihr Meta-Objekt sind sie lose miteinander vernetzt – eine Instanz, die alle Metadaten eines einzelnen Objekts enthält. Ein Signal kann somit mit mehr als einem Slot verbunden werden und umgekehrt. Somit ist dieses System flexibler als Callbacks. Die Verbindungen zwischen den Funktionen sind zudem typensicher, um zu gewährleisten, dass die Funktionen keine korrupten Daten empfangen. Signals-und-Slots ist ein Mechanismus, der sich im Qt-Framework für Objekte befindet, damit diese miteinander kommunizieren können.
Eine herkömmliche Herangehensweise beim Erstellen von Benutzeroberflächen für Desktop-Umgebungen sind Widgets. Da dieser Ansatz aus dem Desktop-Bereich stammt, bietet er nicht die Flexibilität eines ansprechenden UI-Designs, wie es bei Plattform-unabhängigen Multiscreen-Anwendungen erforderlich ist. Konzepte und Techniken, die für das Web entwickelt wurden, bieten mehr Unabhängigkeit, wenn auch mit einer starken Abhängigkeit von einem Remote-Server. Der Client stellt nur die Daten dar, die auf verschiedene Bildschirmgrößen skaliert werden. Es ist auch ein ähnlicher Ansatz möglich, der die Vorteile einer Ausführung hinzufügt, die vollständig vor Ort stattfindet. Ein Beispiel ist die deklarative Entwicklungssprache QML, die Teil des Qt-Frameworks ist.
QML basiert auf Java-Script und unterstützt eine durchgehende, Touch-basierte Entwicklung von Benutzeroberflächen. Sein deklarativer Ansatz auf Basis von Ereignissen und Eigenschaften trennt das Layout- und Schnittstellenverhalten von der Core-Application-Logik. Damit eignet sich dieser Ansatz gut für die Entwicklung von Benutzeroberflächen. Was auf einem Gerät mit einer Geste initiiert wurde, kann auf einem anderen Gerät mit einem Slider-Objekt umgesetzt werden. Durch die Bindung verschiedener Eigenschaften an Objekte können Entwickler verschiedene Schnittstellenkonfiguration ausprobieren und an das jeweilige Display eines Targets anpassen. Die zugrundeliegende C++-Core-Business-Logik bleibt gleich und ermöglicht direkten Geräte- und Peripherie-Zugriff sowie eine Performance-Optimierung. Die Änderungen für unterschiedliche Client-Schnittstellen liegen in der Benutzerschnittstellen-Deklaration, die über QML erfolgt.
Die Aktualisierung der Benutzeroberfläche für ein anderes Gerät erfolgt durch den einfachen Austausch einer deklarativen QML-Layout-Datei durch eine andere oder durch die Änderung weniger Variablen innerhalb der gleichen Layout-Datei. Da QML-Dateien dynamisch geladen werden können (selbst online), lassen sich Benutzeroberflächen aus der Ferne aktualisieren und verbessern, ohne dabei die Anwendung erneut bereitstellen zu müssen.
