8.1.7. Entwicklungsentscheidungen

Schon ein kleines Bedienpanel berührt mehrere Fragen. Wo wird eine Aktion ausgeführt? Welcher Konfigurationsstand gilt? Was passiert, wenn die Verbindung während einer Übertragung abbricht? Diese Entscheidungen bestimmen, wie verlässlich sich das Gerät im Alltag bedienen lässt.

Tastatur- und Medienaktionen lassen sich als USB-HID-Eingaben vom Gerät senden. Die Zuordnung einer Tastenkombination zu einer IntelliJ-Aktion bleibt dadurch in der Keymap der Entwicklungsumgebung. Eine normale Tastatureingabe braucht keine besondere IntelliJ-Erweiterung.

Für das Starten eines Programms verwendet das Projekt einen benannten App-Befehl. Das Gerät kennt beispielsweise den Namen eines Werkzeugs. Der Desktop-Katalog enthält den Programmpfad und die Argumente. So kann dieselbe Buttonbelegung auf verschiedenen Computern jeweils auf eine passende lokale Installation zeigen. Die Definitionen werden mit einer Desktop-Datei gespeichert. Beim Übertragen zum Gerät entfallen die ausführbaren Details.

Im Editor kann eine neue Belegung entstehen, während das Gerät mit seiner bisherigen Konfiguration weiterarbeitet. Save sichert den Entwurf in einer Datei. Erst ein erfolgreiches Send to device aktiviert ihn einschließlich des zugehörigen Befehlskatalogs.

Diese Unterscheidung vermeidet überraschende Änderungen während der Bearbeitung. Ein geänderter Programmpfad wird beispielsweise erst nach der ausdrücklichen Übertragung für die laufende Bedienung wirksam. Auch die Entscheidung, eine Datei zu speichern und die Anwendung zu beenden, führt nicht zu einer Übertragung.

Eine Konfiguration besitzt eine UUID, eine Revision und eine commitId. Die UUID verbindet Bearbeitungen desselben Dokuments miteinander. Revision und commitId kennzeichnen den gespeicherten Stand. Der Desktop prüft zusätzlich Inhalte, damit identische Kennungen allein keine Gleichheit vortäuschen.

Bei abweichenden Ständen entscheidet der Benutzer, ob er die gesamte Gerätekonfiguration übernimmt oder den Desktop-Entwurf an das Gerät sendet. Teiländerungen und App-Befehle werden bis zur Klärung eingeschränkt. Direkte HID-Funktionen bleiben verfügbar.

Der Aufwand lohnt sich besonders bei Verbindungsabbrüchen. Geht eine Antwort verloren, kann das Gerät die Änderung bereits gespeichert haben. Ein erneutes Lesen klärt den Stand, bevor weitere Änderungen darauf aufbauen.

Ein Programmbefehl bekommt eine eigene Anfragekennung. Der Desktop meldet zurück, ob der Prozess gestartet wurde, bereits läuft oder ein Fehler aufgetreten ist. Das Gerät erwartet die Antwort innerhalb von zwei Sekunden und zeigt einen Fehler vorübergehend rot an.

Die Aussage „gestartet“ bezieht sich auf den Prozessstart. Ein Programm kann später trotzdem fehlschlagen. Ebenso endet die Überwachung eines Launchers, sobald dessen eigener Prozess beendet ist. Diese Grenze ist relevant, wenn ein Launcher eine andere Anwendung öffnet und sofort wieder aussteigt.

Tastendrücke werden nach einer unterbrochenen Verbindung nicht nachgeholt. Damit führt das Wiederanstecken nicht plötzlich einen früher angeforderten Programmstart aus.

Buttons haben eine Zeile, eine Spalte und eine rechteckige Ausdehnung. Leere Plätze sind Teil des Layouts. Eine Änderung der Spaltenzahl packt die vorhandenen Buttons nicht automatisch neu zusammen. Das erhält bewusst gewählte Positionen und macht die Auswirkung einer Bearbeitung nachvollziehbar.

Jede Seite kann ihre eigene Ausrichtung besitzen. Die Anwendung speichert persönliche Vorgaben für die automatische Spaltenzahl lokal. Die transportable Konfiguration enthält zugleich die aufgelöste Breite, damit ein anderes Gerät oder ein anderer Computer mit dem Layout arbeiten kann.

Ein Profil bestimmt, welche vorhandenen Seiten sichtbar sind. Es vermeidet damit separate Kopien einer Seite für unterschiedliche Situationen. Eine Medienseite kann in mehreren Profilen auftauchen, während eine Seite mit IDE-Aktionen nur im Entwicklungsprofil sichtbar ist.

Der Desktop kann das Profil anhand der aktiven Anwendung auswählen. Die manuelle Auswahl bleibt bestehen, bis ausdrücklich in den automatischen Modus zurückgewechselt wird. Der Laufzeitwechsel eines Profils schreibt keine neue Konfiguration in den Flash.

Der Java-Teil bietet eine Bibliothek für das Geräteprotokoll und darauf aufbauend CLI und JavaFX-Anwendung. Wiederverwendbare FX-Funktionen wie die Tray-Anbindung liegen in NeitzelLib. Die Anwendung bündelt ihre Laufzeit mit jpackage in einem Anwendungsabbild für den jeweiligen Build-Rechner.

Diese Aufteilung bringt mehrere Build-Abhängigkeiten mit sich. Dafür lassen sich Protokollzugriffe unabhängig von der Oberfläche verwenden und prüfen. Die konkrete Bedienung erläutert das Kapitel Konfiguration und Nutzung.