--- title: "Wann dein Flutter-Widget eine State Machine braucht" description: "Von der Apollo-Software über David Harel bis zu Flutter: Wann State Machines und Statecharts bei komplexen UIs besser sind als Booleans und GestureDetector, und was das für Bloc und Cubit heißt." canonical_url: "https://robocitrus.com/blog/state-machines-statecharts-flutter-ui" --- > Index of every page on this site: [llms.txt](https://robocitrus.com/llms.txt) ## Ein Talk, der mit Kampfjets und Mondlandung anfängt Der Talk hieß "From Fighter Jets to Flutter" und ging eigentlich um State Machines und Statecharts in der Flutter-UI-Entwicklung. Der Speaker hat gleich zu Beginn gesagt: Es wird heute keinen Kampf geben. Stattdessen ging es zum Mond. Ich fand den Einstieg stark, weil er eine Frage beantwortet, die ich mir selbst oft stelle: Warum werden meine UIs irgendwann unübersichtlich, obwohl jeder einzelne Teil simpel aussieht? ## Die Geschichte in kurz Margaret Hamilton war Teil des Teams, das die Software für die Apollo-Mission geschrieben hat. Wenn dort Software abstürzt, ist das keine Fehlermeldung, sondern eine Katastrophe. Hot Reload gab es auch nicht. Eine Anekdote aus dem Talk: Kurz vor der Landung hat die Software gemerkt, dass die CPU-Auslastung hochgeht, und hat verhindert, dass bestimmter Code läuft. Sonst wäre die Software abgestürzt. Danach gründete Hamilton 1977 mit Kollegen die Firma Higher Order Software. Die Idee: eine neue Art, kritische Software zu beschreiben, deklarativ und mit strenger Syntax. Was sich in dieser Syntax nicht ausdrücken lässt, gilt als falsch. Dabei nutzten sie Funktionsbäume, also Graphen, die zeigen, was die Software tut. David Harel promovierte damals am MIT und arbeitete einen Sommer mit dem Team. Er fragte, wie man solche Software eigentlich verifiziert. Von der "alles steckt in der Syntax"-Antwort war er nicht überzeugt. Die grafische Darstellung hat ihm aber gefallen. Später wurde er für ein vertrauliches Projekt in Israel angefragt. Es ging um Software für Kampfjets. Die Ingenieure kannten ihre Teile sehr gut, konnten aber das Gesamtsystem nicht beschreiben. Auf Fragen gab es Verweise auf hunderte Seiten Handbücher. Harel merkte beim Fragen und Zuhören, dass er anfing, Diagramme zu zeichnen. Und dass die Leute diese Diagramme besser verstanden als einen Stapel Text. So entstanden die Statecharts. Eine Randnotiz zur Quellenlage: Beim Jahr der Kampfjet-Arbeit ist die Mitschrift unklar, deshalb nenne ich hier keins. ## State Machine vs. Statechart Eine State Machine ist simpel. Du hast einen Zustand, es kommt ein Event, du landest in einem anderen Zustand. Mehr ist es nicht. Für komplexe Systeme reicht das nicht. Harel hat das Konzept deshalb zu Statecharts erweitert. Der wichtigste Punkt aus dem Talk: Zustände können andere Zustände enthalten. Du verschachtelst sie. Damit lässt sich viel komplexeres Verhalten beschreiben, ohne dass das Diagramm explodiert. ## Das Beispiel: Karten auf einem Board Der Speaker arbeitet an einem Tool, das Designs in Flutter-Code übersetzt. Dort wurde er mit komplexen Interaktionen konfrontiert: Ziehen von Anfassern, Größe ändern, verschieben. Irgendwann kam er nicht mehr weiter, die Interaktionen zu beschreiben. Dann stieß er auf Harel. Für die Demo hat er eine kleine Notiz-App gebaut. Karten liegen auf einem Board, du kannst sie ziehen und an den Ecken skalieren. Der spannende Teil: Während du eine Karte an der Ecke skalierst, drückst du die Leertaste. Jetzt verschiebst du die ganze Karte. Lässt du die Taste los, skalierst du wieder. Wer ein Design-Tool kennt, kennt dieses Verhalten. Das Statechart dazu besteht aus: - einem `idle`-Zustand, in dem nichts passiert, - einem `changing`-Zustand, der die Unterzustände `resizing` und `moving` enthält, - einem `canceled`-Zustand, wenn die Aktion verworfen wird. Zustände und Events können Daten tragen. Beim Skalieren muss die App zum Beispiel wissen, welche Ecke gezogen wird. Das Event "resize" bringt diese Information mit. Das macht die Beschreibung deutlich einfacher. Umgesetzt hat der Speaker das mit einem eigenen Dart-Package namens Harel, benannt nach David Harel. Dazu gibt es ein Tool, den Harel Inspector. ## Der Inspector und warum er mich überzeugt hat Der Inspector verbindet sich mit der laufenden App und zeigt das Statechart als Diagramm. Du ziehst an einer Ecke, und der aktive Zustand leuchtet auf. Drückst du die Leertaste, siehst du live den Wechsel von `resizing` zu `moving`. Dazu kommen zwei Dinge, die ich praktisch finde: - Ein Event-Log, das alle Events in der Reihenfolge zeigt. Daran kannst du Bugs ablesen. - Ein Klick auf einen Zustand springt direkt zum passenden Code in der IDE. In großen Codebasen spart das Suchzeit. Der Speaker sagte dazu sinngemäß: Ohne so ein Framework schreibst du `print`-Ausgaben von Hand. Mit einer State Machine bekommst du Observability geschenkt. Und mit einem `GestureDetector` plus ein paar Booleans musst du sie für jede App neu bauen. ## KI schreibt den Code, du musst ihn trotzdem verstehen Der Teil hat mich am meisten beschäftigt. Der Speaker hat das Publikum gefragt, wer den Code liest, den ein LLM schreibt. Wer mehr als die Hälfte liest? Wer alles? Seine Aussage: Wir haben schlicht nicht die Zeit, jede Zeile zu prüfen. Die Demo-App selbst hat ein LLM geschrieben. Er hat ihm das Package und einen Skill gegeben und gesagt, es soll die App damit bauen. Trotzdem muss er verstehen, was da passiert. Ein Diagramm, das du live neben der App laufen siehst, geht dafür schneller als Logik lesen. Und weil es sichtbar ist, kann auch dein Agent es sich ansehen. Das deckt sich mit dem, was ich in [Wenn KI deine Flutter-App schreibt](https://robocitrus.com/blog/wenn-ki-deine-flutter-app-schreibt) und [Marionette MCP: KI-Agenten testen Flutter-Apps](https://robocitrus.com/blog/marionette-mcp-ki-agenten-flutter-apps-testen) schon beschrieben habe: Je besser du sehen kannst, was die App tut, desto besser kannst du KI-Code kontrollieren. ## Wann lohnt sich eine State Machine? Der Speaker war klar: Nicht für jedes UI-Stück. Seine Faustregel ist eine Frage: Fängt mein Widget an, wie eine App auszusehen? Seine Beispiele: - Ein Rich-Text-Editor mit fett, kursiv, Blocktypen und Drag-and-drop ist kein Widget mehr, sondern eine App. - Ein Story-Viewer im Instagram-Stil: Hochwischen zeigt Reaktionen, Runterwischen blendet sie aus, kurz drücken verwirft sie. Solche Interaktionen plant man am Anfang oft nicht mit. Aber Nutzer erwarten sie, weil sie Instagram oder TikTok kennen. Und wenn du sie bauen musst, ist das der Moment für eine State Machine. Er sagte auch, dass man den ganzen Aufwand mit States und Events manchmal gar nicht braucht. Dann reicht normale Architektur. ## Meine Einordnung: State Machine und Bloc Ab hier meine eigene Meinung, nicht die des Speakers. Er hat im Talk weder [Bloc](https://bloclibrary.dev) noch Cubit verglichen. Ich nutze Bloc und Cubit in den meisten meiner Apps, die Gründe stehen in [Flutter State Management 2026](https://robocitrus.com/blog/flutter-state-management-2026). Für Screens mit Daten, Laden, Fehler und Erfolg passt das sehr gut. Ein Cubit mit einer sauberen Liste von States ist im Grunde schon eine kleine State Machine. Was Bloc nicht abdeckt, ist die Feinheit im Widget selbst. Wenn eine einzelne Karte zwischen Skalieren, Verschieben und Abbrechen wechselt, mit Tastendruck mittendrin, lege ich dafür keinen Bloc an. Dort würde ich heute zu einer echten State Machine greifen, statt Booleans in einem `StatefulWidget` zu stapeln. Ich sehe das so: Bloc oder Cubit für den App-Zustand, State Machine für komplexe Interaktionen in einem Widget. Ob ich das Harel-Package selbst einsetze, kann ich noch nicht sagen. Ich habe es nicht ausprobiert. Die Idee, Observability geschenkt zu bekommen, finde ich aber gut. ## Fazit Der Talk hat mir ein einfaches Kriterium mitgegeben: Wenn dein Widget wie eine App aussieht, brauchst du mehr als Booleans. Statecharts sind dafür seit Jahrzehnten bewährt, von Kampfjets bis zum Design-Tool. Und in Zeiten von KI-generiertem Code ist ein Diagramm, das du live beobachten kannst, ein ziemlich praktisches Sicherheitsnetz. Für die meisten Screens reicht Architektur. Für die wenigen interaktiven Spezialfälle lohnt sich der Blick auf State Machines. Mehr zur Sicht auf das Framework findest du in [Warum ich Flutter liebe](https://robocitrus.com/blog/warum-ich-flutter-liebe). Und wie KI das Entwickeln insgesamt verändert, steht in [KI in der App-Entwicklung](https://robocitrus.com/blog/ki-in-der-app-entwicklung). --- ## Häufig gestellte Fragen (FAQ) Eine State Machine hat Zustände, Events und Übergänge. Ein Statechart erweitert das um verschachtelte Zustände und beschreibt damit komplexeres Verhalten. Harel hat das Konzept entwickelt, weil einfache State Machines für Systeme wie Kampfjet-Software nicht reichten. Der Speaker nutzt eine Faustregel: Wenn dein Widget anfängt, wie eine App auszusehen. Typische Fälle sind Editoren mit vielen Modi oder Gesten-Interaktionen wie bei einem Story-Viewer. Für normale Formulare und Listen reicht meist deine bestehende Architektur. Aus dem Talk ging das nicht hervor. Meine Einschätzung: Nein. Bloc oder Cubit passen für den App-Zustand, eine State Machine für komplexe Interaktionen innerhalb eines Widgets. Beides lässt sich kombinieren. Ein Dart-Package des Speakers, benannt nach David Harel. Damit beschreibst du UI-Verhalten als Statechart. Dazu gibt es den Harel Inspector, der das Diagramm live zur laufenden App anzeigt, ein Event-Log liefert und zum passenden Code springt. Ich habe es selbst noch nicht eingesetzt. Laut Speaker ja, weil du das Verhalten als Diagramm live beobachten kannst, statt Logik zu lesen. Er hat die Demo-App von einem LLM schreiben lassen, mit dem Package und einem Skill als Kontext, und sie dann über den Inspector nachvollzogen. --- *Dieser Artikel wurde inspiriert vom Talk "State Machines, State Charts, and Flutter UI Development" (From Fighter Jets to Flutter) auf der FlutterCon 2026.* ## Sitemap See the full [sitemap](https://robocitrus.com/sitemap.md) for all pages.