Ich möchte das nochmal ansprechen, da mir "die" Lösung leider nicht
eingefallen ist.
Für meine Hauptnavigation ("Bildschirme") habe ich nun eine
tabellenbasierte Zustandsmaschine umgesetzt, d.h. ich suche nach einer
Eingabe die Zordnung zum gegenwärtigen Zustands, aus den beiden Größen
ergibt sich der nächste Zustand, dem wiederum eine Funktion
(screen_foo()) zugeordnet ist.
Die Tastenbelegung für KEY1..KEYN ist in einem Array abgelegt, über das
die Beschriftung und der keycode (= event) ermittelt werden.
Die Funktion der "Bildschirme" (z.B. das Menü) muss ebenfalls über eine
Eingabe getriggert werden.
Natürlich ist abstrakt immer nur ein Zustand möglich, aber in meinem
Verständnis wäre eine Tabelle mit allen Zuständen zu komplex (und nicht
effizient, da sich die Suchzeit vervielfacht).
Ausserdem wird die Darstellung der Zustände unübersichtlich:
Zustand:
BildschirmEins
+ ElementDreiAusgewählt
(+ ElementTypTelefonummer)
+ Taste1MitFunktionBar
+ Taste2MitFunktionFoo
+ Taste3MitFunktionEnter
+ Taste4MitFunktionCancel
BildschirmZwei
+
...
An der Stelle wäre es doch sinnvoll, wenn man verschiedene Tastenlayouts
einführt, die für bestimmte Zustände gelten.
D.h. es bedarf einer Zuordnung Zustand<->Layout und beim Übergang ggf.
eine Aktualisierung der Tasten.
Aber an welcher Stelle geschieht das? Ist es Aufgabe der
Übergangsfunktion? Erfolgt es im Event-Handler
(state+event->state_next)?
Wie dann untergeordnete Zustände (Telefonbuch->Gastlos
ausgewählt->Gastlos bearbeiten->...)gehandhabt werden - keine Ahnung.
Vielleicht ist an der Stelle eine verabschiedung von der Zustandstabelle
nötig, und die Bildschirme bzw. darunterliegende Funktionen bringen ihre
eigenen Zustände mit?
Bin gespannt auf eure Ideen!
