Kotlin MVI vs MVVM für formularintensive Android-Apps: UI-Zustände

Warum formularintensive Android-Apps schnell unübersichtlich werden

Formularlastige Apps wirken langsam oder fragil, weil Nutzer ständig auf winzige Entscheidungen warten, die dein Code treffen muss: Ist dieses Feld gültig, hat das Speichern geklappt, sollen wir einen Fehler zeigen, und was passiert, wenn das Netzwerk weg ist.

Formulare offenbaren State-Bugs früh, weil sie mehrere Zustandsarten mischen: UI-Zustand (was sichtbar ist), Eingabezustand (was der Nutzer getippt hat), Serverzustand (was gespeichert ist) und temporärer Zustand (was gerade läuft). Wenn diese auseinanderdriften, fühlt sich die App „zufällig“ an: Buttons werden zur falschen Zeit deaktiviert, alte Fehler bleiben sichtbar oder der Bildschirm setzt sich nach Rotation zurück.

Die meisten Probleme gruppieren sich in vier Bereiche: Validierung (insbesondere Regeln über mehrere Felder), optimistische UI (schnelles Feedback während eine Aktion noch läuft), Fehlerbehandlung (klare, wiederherstellbare Fehler) und Offline-Entwürfe (unfertige Arbeit nicht verlieren).

Gute Formular-UX folgt ein paar einfachen Regeln:

• Validierung sollte hilfreich und feldnah sein. Blockiere nicht das Tippen. Sei streng, wenn es wichtig ist, üblicherweise beim Absenden.
• Optimistische UI sollte die Aktion des Nutzers sofort widerspiegeln, braucht aber einen sauberen Rollback, falls der Server ablehnt.
• Fehler sollten spezifisch, umsetzbar sein und niemals die Nutzereingabe löschen.
• Entwürfe sollten Neustarts, Unterbrechungen und schlechte Verbindungen überstehen.

Deshalb werden Architekturdebatten bei Formularen schnell intensiv. Das gewählte Pattern entscheidet, wie vorhersehbar sich diese Zustände unter Last anfühlen.

Kurze Auffrischung: MVVM und MVI in einfachen Worten

Der eigentliche Unterschied zwischen MVVM und MVI ist, wie Änderungen durch einen Bildschirm fließen.

MVVM (Model View ViewModel) sieht meist so aus: das ViewModel hält die Bildschirmdaten, macht sie der UI verfügbar (oft über StateFlow oder LiveData) und bietet Methoden wie save, validate oder load. Die UI ruft ViewModel-Funktionen auf, wenn der Nutzer interagiert.

MVI (Model View Intent) sieht meist so aus: die UI sendet Events (Intents), ein Reducer verarbeitet sie und der Screen rendert aus einem einzigen State-Objekt, das alles repräsentiert, was die UI gerade braucht. Side-Effects (Netzwerk, DB) werden kontrolliert ausgelöst und melden Ergebnisse als Events zurück.

Eine einfache Merkhilfe für die Denkweise:

• MVVM fragt: „Welche Daten sollte das ViewModel freigeben und welche Methoden sollte es anbieten?“
• MVI fragt: „Welche Events können passieren und wie transformieren sie einen State zum nächsten?“

Beide Patterns funktionieren gut für einfache Bildschirme. Sobald du Cross-Field-Validierung, Autosave, Retries und Offline-Entwürfe hinzufügst, brauchst du strengere Regeln darüber, wer wann den State ändern darf. MVI erzwingt diese Regeln standardmäßig. MVVM kann weiterhin gut funktionieren, braucht aber Disziplin: konsistente Update-Pfade und sorgfältiges Handling von One-Off-UI-Events (Toasts, Navigation).

Wie man Formularzustand ohne Überraschungen modelliert

Der schnellste Weg, die Kontrolle zu verlieren, ist, Formulardaten an zu vielen Orten zu lagern: View-Bindings, mehrere Flows und „nur noch ein Boolean“. Formularintensive Bildschirme bleiben vorhersagbar, wenn es eine einzige Quelle der Wahrheit gibt.

Eine praktische FormState-Struktur

Strebe ein einzelnes FormState an, das rohe Eingaben plus ein paar abgeleitete Flags enthält, denen du vertraust. Halte es langweilig und vollständig, auch wenn es etwas größer wirkt.

data class FormState(
  val fields: Fields,
  val fieldErrors: Map<FieldId, String> = emptyMap(),
  val formError: String? = null,
  val isDirty: Boolean = false,
  val isValid: Boolean = false,
  val submitStatus: SubmitStatus = SubmitStatus.Idle,
  val draftStatus: DraftStatus = DraftStatus.NotSaved
)

sealed class SubmitStatus { object Idle; object Saving; object Saved; data class Failed(val msg: String) }
sealed class DraftStatus { object NotSaved; object Saving; object Saved }

Das trennt Feld-Validierung (pro Eingabe) von Formularproblemen (wie „Gesamt muss > 0 sein“). Abgeleitete Flags wie isDirty und isValid sollten an einer Stelle berechnet werden, nicht in der UI mehrfach implementiert.

Ein sauberes mentales Modell ist: fields (was der Nutzer getippt hat), validation (was falsch ist), status (was die App gerade macht), dirtiness (was sich seit dem letzten Speichern geändert hat) und drafts (ob eine Offline-Kopie existiert).

Wohin One-Off-Effekte gehören

Formulare lösen auch einmalige Events aus: Snackbars, Navigation, „Gespeichert“-Banner. Pack diese nicht in FormState, sonst feuern sie erneut nach Rotation oder wenn die UI sich wieder anmeldet.

In MVVM emittiere Effekte über einen separaten Channel (z. B. ein SharedFlow). In MVI modele sie als Effects (oder Events), die die UI einmal konsumiert. Diese Trennung verhindert „phantom“-Fehler und doppelte Erfolgsmeldungen.

Validierungsfluss in MVVM vs MVI

Validierung ist der Punkt, an dem Formularscreens fragil werden. Die Schlüsselfrage ist, wo Regeln leben und wie Ergebnisse zur UI zurückkommen.

Einfache, synchrone Regeln (Pflichtfelder, Mindestlänge, Zahlenbereiche) sollten im ViewModel oder Domain-Layer laufen, nicht in der UI. Das macht Regeln testbar und konsistent.

Asynchrone Regeln (wie „ist diese E-Mail schon vergeben?“) sind kniffliger. Du musst Loading, veraltete Ergebnisse und den Fall „der Nutzer tippt wieder“ behandeln.

In MVVM wird Validierung häufig zu einer Mischung aus State und Hilfsmethoden: die UI sendet Änderungen (Textupdates, Fokuswechsel, Submit-Klicks) ans ViewModel; das ViewModel aktualisiert ein StateFlow/LiveData und stellt feldbezogene Fehler sowie ein abgeleitetes canSubmit bereit. Async-Prüfungen starten meist einen Job, setzen einen Loading-Flag und aktualisieren einen Fehler, wenn sie fertig sind.

In MVI ist Validierung oft expliziter. Eine praktische Arbeitsteilung ist:

• Der Reducer führt synchrone Validierung durch und aktualisiert Feldfehler sofort.
• Ein Effect führt asynchrone Validierung aus und dispatcht ein Ergebnis-Intent.
• Der Reducer wendet dieses Ergebnis nur an, wenn es noch zur aktuellsten Eingabe passt.

Dieser letzte Schritt ist wichtig. Tippt der Nutzer während einer laufenden „E-Mail-unique“-Prüfung eine neue E-Mail, sollten alte Ergebnisse die aktuelle Eingabe nicht überschreiben. MVI macht das oft leichter kodierbar, weil du den zuletzt geprüften Wert im State speichern und veraltete Antworten ignorieren kannst.

Optimistische UI und asynchrone Speichervorgänge

Optimistische UI bedeutet, dass der Bildschirm so tut, als hätte das Speichern bereits funktioniert, bevor die Netzwerkantwort eintrifft. Bei einem Formular heißt das oft: der Speichern-Button wechselt zu „Saving…“, ein kleines „Gespeichert“-Indikator erscheint später, und Eingaben bleiben nutzbar (oder werden absichtlich gesperrt), solange die Anfrage läuft.

In MVVM wird das häufig durch Flags wie isSaving, lastSavedAt und saveError umgesetzt. Das Risiko ist Drift: Überlappende Speichervorgänge können diese Flags inkonsistent lassen. In MVI aktualisiert ein Reducer ein einziges State-Objekt, sodass „Saving“ und „Disabled“ seltener widersprüchlich sind.

Um Double-Submit und Race-Conditions zu vermeiden, behandle jedes Save als identifizierbares Ereignis. Tippt der Nutzer zweimal auf Speichern oder editiert während eines Speichers, brauchst du eine Regel, welche Antwort gewinnt. Einige Safeguards funktionieren in beiden Patterns: deaktiviere Save während des Speicherns (oder debouncte Klicks), hänge eine requestId (oder Version) an jedes Save und ignoriere veraltete Antworten, cancelle In-Flight-Arbeiten, wenn der Nutzer den Bildschirm verlässt, und definiere, was Bearbeitungen während des Speicherns bedeuten (einen weiteren Save anstellen oder das Formular wieder als dirty markieren).

Teilweise Erfolge sind ebenfalls üblich: der Server akzeptiert einige Felder, lehnt andere ab. Modelle das explizit. Behalte feldbezogene Fehler (und falls nötig feldbezogenen Sync-Status), sodass du insgesamt „Gespeichert“ zeigen kannst und gleichzeitig ein Feld hervorhebst, das Aufmerksamkeit braucht.

Fehlerzustände, von denen sich Nutzer erholen können

Form-Screens schlagen auf mehr Arten fehl als nur „etwas ist schiefgelaufen“. Wenn jeder Fehler zu einem generischen Toast wird, tippen Nutzer neu, verlieren Vertrauen und brechen den Flow ab. Das Ziel ist immer dasselbe: Eingaben sichern, eine klare Lösung zeigen und Retry normal wirken lassen.

Hilfreich ist, Fehler danach zu trennen, wo sie hingehören. Eine falsch formatierte E-Mail ist nicht dasselbe wie ein Serverausfall.

Feldfehler sollten inline und an das jeweilige Eingabefeld gebunden sein. Formularweite Fehler sollten in der Nähe der Submit-Aktion stehen und erklären, was die Absendung blockiert. Netzwerkfehler sollten einen Retry anbieten und das Formular editierbar lassen. Berechtigungs- oder Auth-Fehler sollten den Nutzer zur Wiederanmeldung führen, während ein Draft erhalten bleibt.

Eine Kernregel zur Wiederherstellung: lösche niemals Nutzereingaben bei einem Fehler. Wenn das Speichern fehlschlägt, behalte die aktuellen Werte im Speicher und auf der Festplatte. Retry sollte dieselbe Payload erneut senden, es sei denn, der Nutzer ändert etwas.

Unterschiede zeigen sich darin, wie Serverfehler in UI-State gemappt werden. In MVVM ist es leicht, mehrere Flows oder Felder zu aktualisieren und dabei Inkonsistenzen zu schaffen. In MVI wendest du normalerweise die Serverantwort in einem Reducer-Schritt an, der fieldErrors und formError zusammen aktualisiert.

Entscheide außerdem, was State ist und was ein One-Off-Effekt ist. Inline-Fehler und „Submission failed“ gehören in den State (sie müssen Rotation überstehen). Einmalkommunikationen wie Snackbar, Vibration oder Navigation sind Effekte.

Offline-Entwürfe und Wiederherstellung von in Bearbeitung befindlichen Formularen

Eine formularintensive App fühlt sich „offline“ an, selbst wenn das Netzwerk funktioniert. Nutzer wechseln Apps, das OS killt deinen Prozess oder sie verlieren während des Tippens das Signal. Drafts verhindern, dass sie von vorn anfangen müssen.

Zuerst: Definiere, was ein Draft bedeutet. Nur das „saubere“ Modell zu speichern reicht oft nicht aus. Du willst meistens den Bildschirm genau so wiederherstellen, wie er aussah, inklusive halbfertiger Felder.

Was sich zu persistieren lohnt, sind meist rohe Nutzereingaben (Strings so wie getippt, ausgewählte IDs, Attachment-URIs) plus genug Metadaten zum später sicheren Mergen: ein letzter bekannter Server-Snapshot und ein Versionsmarker (updatedAt, ETag oder einfach ein Increment). Validierung kann bei der Wiederherstellung neu berechnet werden.

Die Speicherwahl hängt von Sensitivität und Größe ab. Kleine Drafts können in Preferences leben, mehrstufige Formulare und Attachments sind in einer lokalen DB sicherer. Enthält der Draft persönliche Daten, nutze verschlüsselten Speicher.

Die größte Architekturfrage ist, wo die Quelle der Wahrheit liegt. In MVVM persistieren Teams oft aus dem ViewModel heraus, wann immer Felder sich ändern. In MVI kann Persistieren nach jedem Reducer-Update einfacher sein, weil du einen kohärenten State (oder ein abgeleitetes Draft-Objekt) speicherst.

Die Timing-Frage beim Autosave ist wichtig. Auf jeden Tastendruck zu speichern ist laut; ein kurzes Debounce (z. B. 300–800 ms) plus Speichern beim Schrittwechsel funktioniert gut.

Wenn der Nutzer wieder online ist, brauchst du Merge-Regeln. Ein praktischer Ansatz: ist die Server-Version unverändert, wende den Draft an und sende ihn. Wenn sie sich geändert hat, zeige eine klare Wahl: Draft behalten oder Serverdaten neu laden.

Schritt-für-Schritt: Baue ein zuverlässiges Formular mit beiden Patterns

Zuverlässige Formulare starten mit klaren Regeln, nicht mit UI-Code. Jede Nutzeraktion sollte zu einem vorhersehbaren State führen, und jedes asynchrone Ergebnis sollte einen eindeutigen Zielort haben.

Schreibe die Aktionen auf, auf die dein Screen reagieren muss: tippen, Fokusverlust, submit, retry und Step-Navigation. In MVVM werden das ViewModel-Methoden und State-Updates. In MVI werden es explizite Intents.

Dann arbeite in kleinen Schritten:

1. Definiere Events für den gesamten Lebenszyklus: edit, blur, submit, save success/failure, retry, restore draft.
2. Entwerfe ein State-Objekt: Feldwerte, feldbezogene Fehler, Gesamtform-Status und „hat ungespeicherte Änderungen“.
3. Füge Validierung hinzu: leichte Checks während der Bearbeitung, strengere Checks beim Absenden.
4. Ergänze optimistische Save-Regeln: was sich sofort ändert und was einen Rollback auslöst.
5. Füge Drafts hinzu: Autosave mit Debounce, Wiederherstellung beim Öffnen und ein kleines „Draft wiederhergestellt“-Indikator, damit Nutzer dem Zustand vertrauen.

Behandle Fehler als Teil des Erlebnisses. Bewahre Eingaben, hebe nur das hervor, was zu korrigieren ist, und biete eine klare nächste Aktion (bearbeiten, erneut versuchen oder Draft behalten).

Wenn du komplexe Formularzustände prototypen willst, ohne Android-UI zu schreiben, kann eine No-Code-Plattform wie AppMaster nützlich sein, um Workflows zuerst zu validieren. Danach kannst du dieselben Regeln in MVVM oder MVI mit weniger Überraschungen implementieren.

Beispiel-Szenario: mehrstufiges Spesenformular

Stell dir ein 4-Schritt-Spesenformular vor: Details (Datum, Kategorie, Betrag), Beleg-Upload, Notizen, dann Review und Absenden. Nach dem Absenden zeigt es einen Genehmigungsstatus wie Draft, Submitted, Rejected, Approved. Knackpunkte sind Validierung, fehlgeschlagene Saves und das Beibehalten eines Drafts, wenn das Telefon offline geht.

In MVVM hältst du typischerweise einen FormUiState im ViewModel (oft ein StateFlow). Jede Feldänderung ruft eine ViewModel-Funktion wie onAmountChanged() oder onReceiptSelected() auf. Validierung läuft bei Änderung, beim Schrittwechsel oder beim Absenden. Eine gängige Struktur ist rohe Eingaben plus feldbezogene Fehler, mit abgeleiteten Flags, die steuern, ob Next/Submit aktiv sind.

In MVI wird derselbe Ablauf explizit: die UI sendet Intents wie AmountChanged, NextClicked, SubmitClicked und RetrySave. Ein Reducer gibt einen neuen State zurück. Side-Effects (Upload Receipt, API-Aufruf, Snackbar zeigen) laufen außerhalb des Reducers und liefern Ergebnisse als Events zurück.

In der Praxis macht MVVM es einfach, schnell Funktionen hinzuzufügen und einen Flow zu update3g. MVI macht es schwerer, versehentlich einen State-Transition zu überspringen, weil jede Änderung durch den Reducer kanalisiert wird.

Häufige Fehler und Fallen

Die meisten Formular-Bugs entstehen durch unklare Regeln darüber, wer die Wahrheit besitzt, wann Validierung läuft und was passiert, wenn asynchrone Ergebnisse verspätet ankommen.

Der häufigste Fehler ist die Mischung von Quellen der Wahrheit. Liest ein Textfeld manchmal aus einem Widget, manchmal aus dem ViewModel-State und manchmal aus einem wiederhergestellten Draft, entstehen zufällige Resets und „meine Eingabe ist weg“-Berichte. Wähle eine kanonische State-Quelle für den Screen und leite alles andere davon ab (Domain-Model, Cache-Rows, API-Payloads).

Eine weitere Falle ist die Verwechslung von State und Events. Ein Toast, Navigation oder „Gespeichert!“-Banner ist einmalig. Eine Fehlermeldung, die sichtbar bleiben muss, bis der Nutzer editiert, ist State. Das Vermischen führt zu doppelten Effekten nach Rotation oder fehlendem Feedback.

Zwei Korrektheitsprobleme treten oft auf:

• Zu starke Validierung bei jedem Tastendruck, besonders bei teuren Checks. Debounce, validiere bei Blur oder nur getrackte Felder.
• Out-of-order asynchrone Ergebnisse ignorieren. Speichert der Nutzer zweimal oder editiert nach dem Speichern, können ältere Antworten neuere Eingaben überschreiben, wenn du keine Request-IDs oder „nur neueste gilt“-Logik benutzt.

Schließlich sind Drafts nicht „nur JSON speichern“. Ohne Versionierung können App-Updates Wiederherstellungen kaputtmachen. Füge eine einfache Schema-Version und eine Migrationsstrategie hinzu, selbst wenn sie für sehr alte Drafts „drop and start fresh“ lautet.

Kurze Checkliste vor dem Release

Bevor ihr MVVM vs MVI diskutiert, stellt sicher, dass euer Formular eine klare Quelle der Wahrheit hat. Wenn ein Wert auf dem Screen ändern kann, gehört er in den State, nicht in ein View-Widget oder ein verstecktes Flag.

Eine praktische Pre-Ship-Checkliste:

• State enthält Eingaben, feldbezogene Fehler, Save-Status (idle/saving/saved/failed) und Draft/Queue-Status, sodass die UI nie raten muss.
• Validierungsregeln sind rein und ohne UI testbar.
• Optimistische UI hat einen Rollback-Pfad für Server-Ablehnung.
• Fehler löschen niemals Nutzereingaben.
• Draft-Restore ist vorhersehbar: entweder ein klares Auto-Restore-Banner oder eine explizite „Draft wiederherstellen“-Aktion.

Ein Test, der echte Bugs fängt: schalte in den Flugmodus mitten im Speichern, schalte wieder an und versuche zweimal neu. Der zweite Retry sollte keinen Duplikat-Eintrag erstellen. Verwende eine Request-ID, einen Idempotency-Key oder einen lokalen „pending save“-Marker, damit Retries sicher sind.

Wenn deine Antworten unscharf sind, straffe zuerst das State-Modell, und wähle dann das Pattern, das diese Regeln am einfachsten erzwingt.

Nächste Schritte: Weg wählen und schneller bauen

Stell eine Frage: Wie teuer ist es, wenn dein Formular in einem merkwürdigen halb-aktualisierten Zustand landet? Wenn der Preis niedrig ist, halte es einfach.

MVVM passt gut, wenn der Screen unkompliziert ist, der State hauptsächlich „Felder + Fehler“ ist und dein Team bereits sicher mit ViewModel + LiveData/StateFlow unterwegs ist.

MVI passt besser, wenn du strikte, vorhersehbare State-Transitions brauchst, viele asynchrone Events (Autosave, Retry, Sync) vorhanden sind oder Bugs teuer sind (Zahlungen, Compliance, kritische Workflows).

Welchen Weg ihr auch wählt: die Tests mit dem höchsten Nutzen für Formulare berühren oft nicht die UI: Validierungs-Edge-Cases, State-Transitions (edit, submit, success, failure, retry), optimistischer Save-Rollback und Draft-Restore plus Konfliktverhalten.

Wenn du auch Backend, Admin-Screens und APIs neben deiner mobilen App brauchst, kann AppMaster (appmaster.io) Produktions-Backends, Web- und native Mobile-Apps aus einem Modell generieren, was hilft, Validierung und Workflow-Regeln über mehrere Oberflächen hinweg konsistent zu halten.