Smart Devices: Die App in der Maschine

Fortsetzung des Artikels von Teil 2.

Ferngesteuerte generische App

Schema der App-Architektur Bildquelle: © Acontis

Die rApp-Architektur: Die generische App fungiert als SOA-Dienste-Server.

Die Verwendung der Remote-App-Plattform (rApp) erlaubt es den Geräte­herstellern, die oben beschriebenen Nachteile zu vermeiden und sich wie bisher vollständig auf die Entwicklung ihrer Geräte-Software zu konzentrieren. Mit den Herausforderungen von App-Entwicklungen auf den Smart Devices und des App-Vertriebs über App-Stores brauchen sich die Gerätehersteller nicht zu beschäftigen.

Die Grundidee: Eine immer gleichbleibende, generische App auf den Smart Devices wird über SOA-Dienste (Service Oriented Architecture) durch die Geräte ferngesteuert. Alle Aktionen gehen dabei immer vom Gerät aus, die generische App tut nur das, was das Gerät ihr aufträgt. Insofern fungiert die generische App als SOA-Dienste-Server und das Gerät ist der SOA-Dienste-Client. Die generische App wird als ein Bestandteil von rApp vom Hersteller acontis in den unterschiedlichen App Stores kostenlos zum Download bereitgestellt. Apple, Android, Windows Phone, Windows Modern Apps, Windows IoT, Desktop Windows, Linux und später Apple OSX werden dabei unterstützt. Desktop-Windows, Linux und MacOS adressieren neben Smart Devices auch herkömm-liche PCs, Laptops und Server, welche somit auch als Terminal zum Benutzer dienen können. Aus diesem Grunde wird im Weiteren der allgemeinere Begriff "Terminal" anstatt "Smart Device" verwendet. Bei Bedarf sind die generischen Apps auch in Source Code erhältlich, sodass der Gerätehersteller gerade bei PCs, Laptops und Servern diese durch ­eigene Programme auf den Terminals ­erweitern kann, welche zum Beispiel zusätzlich zu Benutzerinteraktionen Daten­erfassungen und Auswertungen durchführen.

Für die Geräteseite stellt rApp eine Bibliothek mit definiertem API für gängige (Echtzeit-)Betriebssysteme, Prozessoren und zunächst für die Programmiersprachen C# und C++ zur Verfügung. Über diese Bibliothek, welche der Gerätehersteller in seine Geräte-Software einbindet, kann er alle Funktionen des Terminals wie Bildschirm-Ein- und Ausgabe, Hardware-Funktionen und Dienste quasi fernsteuern. Dabei stehen dem Geräteprogrammierer bei der Remote-Nutzung nahezu alle gängigen Dienste von Smart Devices zur Verfügung.  

Für die Bildschirmausgabe existieren wahlweise zwei Möglichkeiten: Zum einen wie beim Thin-Client-Prinzip die Bildschirm-Aus- und -Eingaben mittels HTML und JavaScript zu beschreiben. Die dabei erzeugten Dateien werden jedoch nicht durch einen Webserver wie üblich bereitgestellt, sondern durch die rApp-Bibliothek auf Veranlassung des Gerätes zum Terminal geschickt (Push-Verfahren), welches den sich daraus ergebenden Bildschirm anzeigt und die in JavaScript programmierte Logik ausführt. Dies hat den Vorteil, dass kein Webserver im Gerät notwendig ist und es auch keine patentrechtlichen Probleme gibt.

Eine zweite Möglichkeit für die Bildschirmausgabe besteht darin, den lokal auf dem Gerät erzeugten Bildschirminhalt mittels H.264 komprimierten Video-Stream an das Terminal zu senden, welches diesen Video-Stream dekomprimiert und auf dem Bildschirm darstellt. Dies ist auch der Weg, den Apple bei CarPlay beschritten hat, um die Bildschirminhalte eines iPhone auf der Konsole des Autos darzustellen. Der Vorteil von H.264 Streaming ist, dass die Bildschirmerzeugung auf dem Gerät mit herkömmlichen Methoden des Geräteherstellers erfolgen kann und nicht auf Web-Techniken umgestiegen werden muss. Das H.264 Streaming zur Bildschirmausgabe setzt allerdings Hardware-Unterstützung im Gerät voraus, wie sie alle modernen Intel- und ARM-Prozessoren mit eingebauter Grafik Processing Unit (GPU) aufweisen.