Android-Oberflächen für reale Nutzungssituationen gestalten
Mobile Aufgaben, Bedienbedingungen und bestätigte Zustände in einem nachvollziehbaren Entwurf zusammenführen.
Eine Android-Oberfläche muss die reale Aufgabe tragen
Eine brauchbare Android-Oberfläche hilft einem Menschen bei einer konkreten Aufgabe unter echten Bedingungen. Dazu gehören erreichbare Bedienelemente, verständliche Zustände und ein verlässlicher Umgang mit Unterbrechungen. Ein schönes statisches Bildschirmbild zeigt davon nur einen Ausschnitt. Besonders bei einer mobilen Fachanwendung muss klar bleiben, was eingegeben, tatsächlich gespeichert, gerade übertragen und vom Server bestätigt wurde.
Unser eigenes fiktives Beispiel ist ein Wartungsbericht. Eine Servicetechnikerin dokumentiert eine Beobachtung am Gerät, speichert den Entwurf und überträgt ihn später. Der Arbeitsplatz kann eng sein und die Verbindung kann ausfallen. Das ist ein bewusst gewählter Nutzungskontext, keine behauptete Kundenanwendung. Wir entwickeln daraus eine Aufgabenfolge, ein kompilierbares Kotlin-Zustandsmodell und eine nachvollziehbare Prüfung seiner sichtbaren Aussagen.
Die wichtigste Frage lautet nicht, wie viele Funktionen auf den Startbildschirm passen. Sie lautet, welcher nächste Schritt in dieser Situation sicher verständlich ist. Ein kurzer gespeicherter Entwurf kann wertvoller sein als eine umfangreiche Eingabemaske, deren Zustand nach einer Unterbrechung unklar bleibt. Die Gestaltung beginnt deshalb mit Arbeit, Umgebung und Rückmeldung statt mit einer Sammlung dekorativer App-Bildschirme.
Den Nutzungskontext konkret aufschreiben
Für unser Beispiel erfassen wir die Situation vor Ort: Die Person steht am Gerät, hat nur kurz Zeit und möchte eine Beobachtung festhalten. Sie kann möglicherweise nicht beide Hände dauerhaft benutzen. Eine Tastatur verdeckt beim Schreiben einen Teil der Oberfläche. Der nächste Arbeitsschritt kann sie unterbrechen. Diese Annahmen werden mit den tatsächlichen Anwendern geprüft, bevor sie zu verbindlichen Produktanforderungen werden.
Notieren Sie zu jeder Hauptaufgabe Eingabe, Ergebnis und eine typische Störung. Beim Wartungsbericht ist die Eingabe ein kurzer Text. Das erste Ergebnis ist ein gespeicherter Entwurf, das zweite ein bestätigter Servereingang. Eine typische Störung ist die verlorene Verbindung. Diese einfache Aufteilung macht bereits sichtbar, dass ein einzelner allgemeiner Erfolgsstatus für den gesamten Ablauf zu ungenau wäre.
Eine spätere Nutzung am Schreibtisch kann andere Bedürfnisse haben. Vielleicht werden dort viele Berichte verglichen oder fachlich freigegeben. Das muss nicht dieselbe mobile Eingabemaske leisten. Eine App darf ihre Ansichten auf unterschiedliche Aufgaben zuschneiden. Ein größerer Bildschirm ist dabei nicht bloß eine Gelegenheit, dieselben Felder breiter zu machen, sondern kann einen anderen sinnvoll gekoppelten Arbeitsbereich ermöglichen.
Die Hauptaktion aus dem aktuellen Zustand ableiten
Solange der Text ungespeicherte Änderungen enthält, lautet die passende Aktion im Beispiel Entwurf speichern. Ist genau dieser Stand gespeichert und eine Verbindung verfügbar, kann Übertragen angeboten werden. Während die Übertragung läuft, darf dieselbe Schaltfläche keinen beliebigen zweiten Versuch auslösen. Nach einer passenden Bestätigung sagt die Oberfläche ausdrücklich Servereingang bestätigt. Diese Wörter beschreiben unterschiedliche beobachtbare Zustände.
Eine Netzwerkanzeige allein beweist keinen erfolgreichen Serverkontakt. Selbst bei verfügbarer Verbindung kann ein bestimmter Endpunkt nicht erreichbar sein oder die Verarbeitung ablehnen. Deshalb leitet unser Modell die Bestätigung nicht aus einem Verbindungssymbol ab. Sie ist ein eigener Zustand, den die tatsächliche Verarbeitung liefern muss. Die Oberfläche soll den Menschen nicht durch eine optimistische Erfolgsmeldung über fehlende Rückmeldungen hinwegtäuschen.
Bei einer fehlgeschlagenen Übertragung bleibt der gespeicherte Inhalt erhalten. Eine erneute Übertragung wird als solche benannt. Welche Wiederholung denselben fachlichen Vorgang betrifft, muss die Datenverarbeitung gesondert festlegen. Die Beschriftung einer Schaltfläche löst keine serverseitige Duplikatfrage. Der Entwurf macht lediglich den nächsten sinnvollen Schritt verständlich und hält dessen technische Voraussetzungen sichtbar auseinander.
Zustand, Speicherung und Darstellung trennen
Die sichtbare Oberfläche erhält im Beispiel einen beschriebenen Berichtszustand. Eine reine Funktion leitet daraus Texte und Aktivierung der Hauptaktion ab. Sie schreibt keine Datei und sendet keine Netzwerkanfrage. Diese Trennung macht die Aussagen unabhängig vom Bildschirm prüfbar. In einer Android-Anwendung wird sie mit der tatsächlichen Zustandsverwaltung und dem Datenzugriff verbunden, statt den ganzen Ablauf in einzelne Klickereignisse zu verteilen.
Die Android-Dokumentation zum Anheben von Zustand beschreibt, wie gemeinsam benötigter Zustand an einem geeigneten gemeinsamen Eigentümer liegt. Für unseren Bericht bedeutet das: Text, Speicherstand und Übertragungsstand dürfen nicht in mehreren unabhängigen Komponenten widersprüchlich gepflegt werden. Ein sichtbarer Status und die Schaltfläche brauchen dieselbe fachliche Grundlage. Die konkrete Einbindung in ViewModel und Datenebene richtet sich nach dem vorhandenen Anwendungsaufbau.
Auch eine Bildschirmdrehung und ein durch das System beendeter Prozess sind unterschiedliche Situationen. Nicht jeder Darstellungszustand benötigt denselben Speichermechanismus wie der wertvolle Entwurfstext. Für den Bericht muss die Datenebene festlegen, wann ein Stand dauerhaft verfügbar ist. Ein bloßer Wert im Arbeitsspeicher darf nicht als gespeicherter Entwurf bezeichnet werden. Diese Entscheidung wird an der tatsächlichen Persistenz geprüft.
Android Developers: State hoisting
Den Entwurfsstand ausdrücklich kennzeichnen
Unser Modell verwendet eine Revisionsnummer für den aktuellen Text und eine weitere für den zuletzt gespeicherten Stand. Sind beide gleich, darf Auf Gerät gespeichert erscheinen. Nach einer Änderung unterscheiden sie sich und der Zustand lautet Ungespeicherte Änderungen. Die Revisionsnummer ist eine eigene vereinfachte Modellannahme. Sie hilft hier, die Aussage an genau den aktuellen Inhalt zu binden und nicht an irgendeinen früheren Speichervorgang.
Die Übertragung trägt ebenfalls die zugehörige Revision. Wird ein älterer Stand bestätigt, darf die Oberfläche den neuen Text nicht als bestätigt darstellen. Das Modell nennt dann Älterer Stand bestätigt. Dieser Randfall tritt beispielsweise auf, wenn eine Person während einer laufenden Übertragung schon weiterarbeitet. Eine technisch richtige Antwort auf eine ältere Anfrage kann sonst eine fachlich falsche Aussage über den aktuellen Bildschirm erzeugen.
Die reine Darstellung entscheidet nicht, welche Anfrageantwort zu welchem Übertragungsversuch gehört. Die reale Datenebene muss das zuverlässig zuordnen und gleichzeitige Vorgänge kontrollieren. Auch Konflikte zwischen Geräten sind darin nicht implementiert. Eine klare kleine Modellgrenze ist nützlich: Sie macht die sichtbaren Aussagen präzise, ohne eine vollständige Synchronisationslösung zu behaupten.
Das kompilierte Kotlin-Beispiel
Der folgende Baustein besteht aus Datenklassen, eindeutig benannten Übertragungszuständen und der Funktion present. Er wurde tatsächlich mit Kotlin/JVM kompiliert und in 38 isolierten Fällen ausgeführt. Die Prüfung betrifft die Zustandsausgabe. Es handelt sich nicht um einen ausgeführten Android-Bildschirm, eine echte dauerhafte Speicherung oder einen tatsächlich übertragenen Bericht. Diese Integrationsaufgaben müssen in einer App zusätzlich umgesetzt und geprüft werden.
Ungültige Revisionswerte werden mit require zurückgewiesen. Eine reale Zustandsverwaltung muss solche Daten kontrolliert behandeln und darf beschädigte Bestandsdaten nicht ungeprüft direkt in die Ansicht geben. Das Beispiel kürzt den eingegebenen Text nicht automatisch und bewahrt ihn im Zustandsobjekt. Eine leere oder ausschließlich aus Leerraum bestehende Nachricht erhält keine Übertragungsaktion. Die fachliche Inhaltsprüfung des Servers bleibt zusätzlich erforderlich.
sealed interface Transfer {
data object None : Transfer
data class Sending(val revision: Int) : Transfer
data class Accepted(val revision: Int) : Transfer
data class Failed(val revision: Int) : Transfer
}
data class ReportState(
val text: String,
val revision: Int,
val savedRevision: Int? = null,
val transfer: Transfer = Transfer.None
)
data class ReportUi(
val storageText: String,
val transferText: String,
val actionText: String,
val actionEnabled: Boolean
)
fun present(state: ReportState, connectionAvailable: Boolean): ReportUi {
require(state.revision >= 0)
require(state.savedRevision == null || state.savedRevision in 0..state.revision)
val transferredRevision = when (val t = state.transfer) {
Transfer.None -> null
is Transfer.Sending -> t.revision
is Transfer.Accepted -> t.revision
is Transfer.Failed -> t.revision
}
require(transferredRevision == null || transferredRevision in 0..state.revision)
val stored = state.savedRevision == state.revision
val currentTransfer = transferredRevision == state.revision
val transferText = when (state.transfer) {
Transfer.None -> "Nicht übertragen"
is Transfer.Sending -> if (currentTransfer) "Übertragung läuft"
else "Älterer Stand wird übertragen"
is Transfer.Accepted -> if (currentTransfer) "Servereingang bestätigt"
else "Älterer Stand bestätigt"
is Transfer.Failed -> if (currentTransfer) "Übertragung fehlgeschlagen"
else "Älterer Stand nicht übertragen"
}
val action = when {
state.text.isBlank() -> "Nachricht ergänzen" to false
!stored -> "Entwurf speichern" to true
state.transfer is Transfer.Sending -> "Übertragung läuft" to false
state.transfer is Transfer.Accepted && currentTransfer -> "Servereingang bestätigt" to false
!connectionAvailable -> "Auf Verbindung warten" to false
state.transfer is Transfer.Failed && currentTransfer -> "Erneut übertragen" to true
else -> "Übertragen" to true
}
return ReportUi(
if (stored) "Auf Gerät gespeichert" else "Ungespeicherte Änderungen",
transferText, action.first, action.second
)
}
Die Texte in einer Android-Ansicht verwenden
Eine Compose-Ansicht kann die abgeleiteten Texte als sichtbare Beschriftungen und den Aktivierungswert für ihre Hauptaktion verwenden. Das eigentliche Klickereignis wird an den zuständigen Ablauf weitergegeben. Die Anzeige sollte nicht eigenständig behaupten, dass ein Speichern erfolgreich war. Erst die bestätigte Datenoperation aktualisiert den gespeicherten Stand. Dasselbe Prinzip gilt für den Beginn und das Ergebnis einer Übertragung.
Ein kurzer Zustandswechsel kann zusätzlich zugänglich angekündigt werden, wenn dies für den Ablauf sinnvoll ist. Die konkrete Semantik und das Verhalten mit TalkBack gehören in die Android-Abnahme. Eine separate Inhaltsbeschreibung sollte nicht wahllos denselben bereits sichtbaren Schaltflächentext wiederholen. Bedienelemente brauchen verständliche Namen und Rollen, während rein dekorative Bestandteile keine zusätzliche unnötige Navigationslast erzeugen sollen.
Die erklärende Grafik zeigt bewusst schematische Oberflächen aus den tatsächlichen Kotlin-Ausgaben. Sie ist kein angeblicher Android-Laufbildschirm. So lässt sich der fachliche Unterschied zwischen gespeichert, unterwegs und bestätigt gut prüfen, bevor die endgültigen Systemleisten, Tastaturzustände und Gerätebedingungen getestet werden. Ein Entwurf und ein Laufzeitnachweis erfüllen verschiedene Aufgaben und werden entsprechend benannt.
Berührungsflächen und Bedienabstände ernst nehmen
Android beschreibt für interaktive Ziele die übliche Mindestgröße von 48 dp. Eine sichtbare kleine Grafik und ihr tatsächlich erreichbarer Berührungsbereich sind dabei zu unterscheiden. Für unseren Bericht bekommt die Hauptaktion eine gut erkennbare Fläche und Abstand zu anderen Aktionen. Der konkrete Geräteeinsatz kann darüber hinaus andere Anforderungen stellen. Ein Zahlenwert allein beweist noch nicht, dass die Bedienung vor Ort angenehm und fehlerarm ist.
Bei einer stehenden einhändigen Nutzung prüfen wir, ob die häufigste Aktion ohne ungewollte Nachbaraktion erreichbar bleibt. Ein destruktiver Schritt gehört nicht unmittelbar an dieselbe kleine Stelle wie das Speichern. Große Flächen helfen wenig, wenn mehrere ähnliche Schaltflächen keine klare Priorität besitzen. Unser Entwurf hat deshalb einen erkennbaren nächsten Schritt und ordnet zusätzliche Funktionen zurückhaltend ein.
Wenn Handschuhe, besondere Eingabegeräte oder starke Umgebungsbedingungen tatsächlich zum Arbeitsablauf gehören, werden sie mit realistischen Geräten geprüft. Eine beliebige künstliche Handschuhszene im Titelbild wäre kein entsprechender Nachweis. Für das hier gewählte Beispiel bleibt die Darstellung bewusst bei einer normalen Telefonbedienung. Zusätzliche Arbeitsplatzanforderungen werden nicht aus einem schönen Motiv abgeleitet.
Android Developers: Accessibility defaults
Text, Tastatur und sichtbaren Arbeitsraum abstimmen
Der Bericht braucht ein verständlich beschriftetes Eingabefeld. Ein Platzhalter allein verliert nach der Eingabe seine orientierende Funktion. Eine passende Eingabekonfiguration kann die mobile Bearbeitung unterstützen. Die gewählte Tastaturaktion muss zum Feld passen: Eine mehrzeilige Beobachtung darf nicht versehentlich beim gewünschten Zeilenumbruch als fertiger Vorgang behandelt werden. Das tatsächliche Verhalten wird mit der verwendeten Texteingabekomponente geprüft.
Die Bildschirmtastatur kann den verfügbaren Raum deutlich verändern. Die aktive Eingabe und die nötige Rückmeldung sollen erreichbar bleiben, ohne unter einer starren unteren Leiste zu verschwinden. Systemleisten, Aussparungen und Tastaturabstände gehören deshalb zum Layoutentwurf. Androids Insets-Unterstützung liefert dafür technische Grundlagen, die passend in den konkreten Aufbau integriert werden. Einfach alle Inhalte mit festen Pixelabständen nach unten zu schieben wäre keine verlässliche allgemeine Lösung.
Größere Schrift und längere Übersetzungen dürfen wichtige Zustände nicht unverständlich abschneiden. Unser Status Servereingang bestätigt ist länger als ein kurzes OK und besitzt einen konkreten fachlichen Nutzen. Die Gestaltung muss dafür Raum schaffen. Eine verkürzte Meldung ist nur dann besser, wenn ihre Bedeutung erhalten bleibt. Textskalierung wird an echten Steuerelementen geprüft und nicht nur durch eine vergrößerte Bildvorschau simuliert.
Am verfügbaren Fenster statt am Gerätenamen orientieren
Eine App kann auf einem großen Gerät in einem kleinen Fenster laufen. Umgekehrt kann derselbe Ablauf mehr Raum erhalten, ohne dass eine neue Gerätebezeichnung relevant wäre. Die Android-Dokumentation empfiehlt deshalb, den tatsächlich zugeteilten Fensterbereich für Layoutentscheidungen zu betrachten. Für unseren Bericht kann ein enger Bereich eine einzelne Arbeitsansicht zeigen, während mehr Platz eine Übersicht und den ausgewählten Bericht nebeneinander ermöglicht.
Die zentrale Aufgabe bleibt dabei erhalten. Eine größere Ansicht sollte nicht plötzlich andere Speicher- oder Bestätigungsregeln besitzen. Unsere reine Zustandsausgabe ist deshalb unabhängig von der äußeren Aufteilung. Das Layout entscheidet, wo Informationen sinnvoll stehen. Die fachliche Logik entscheidet, was diese Informationen bedeuten. Diese Trennung erleichtert spätere Änderungen an Fenstergröße und Anordnung.
Prüfen Sie kleine Fenster, Querformat und längere Inhalte mit derselben Datenlage. Ein nahtloser Wechsel muss den ausgewählten Vorgang und den ungespeicherten Text sinnvoll erhalten. Ob ein Zweibereichslayout wirklich hilft, hängt von der Aufgabe ab. Für eine kurze Eingabe direkt am Gerät kann eine konzentrierte einzelne Ansicht weiterhin die bessere Wahl sein. Mehr verfügbare Fläche muss nicht vollständig mit zusätzlichen Funktionen gefüllt werden.
Android Developers: Adaptive layouts
Verbindungsprobleme als normalen Ablauf behandeln
Im Beispiel darf der Entwurf ohne Verbindung weiter bearbeitet und gespeichert werden. Eine Übertragung ist ein gesonderter Schritt. Die Android-Dokumentation zu Offline-first beschreibt die lokale und entfernte Datenquelle als eigene Zuständigkeiten einer Datenebene. Für unseren konkreten Bericht muss diese Ebene festlegen, wann Speicherung bestätigt wird, wann Übertragungen beginnen und wie Ergebnisse in den sichtbaren Zustand zurückfließen.
Das kleine Kotlin-Modell zeigt dafür die erwartete Aussage, implementiert aber keine Warteschlange, keine Datenbank und keinen Hintergrunddienst. Ein echter Offlineablauf braucht außerdem Entscheidungen zu Konflikten und Wiederholungen. Welche Fassung gewinnt nach paralleler Bearbeitung? Was passiert bei einer serverseitigen Ablehnung? Diese Fragen werden nicht durch die Wahl eines modernen UI-Werkzeugs automatisch beantwortet.
Für die Person bleibt entscheidend, dass ihr Text nicht verschwindet und der Stand verständlich ist. Eine unterbrochene Verbindung soll keine erfundene Erfolgsmeldung erzeugen. Ein bereits bestätigter Servereingang wird umgekehrt nicht allein deshalb zurückgenommen, weil später die Verbindung fehlt. Unsere Prüfungen behandeln genau diese Unterscheidung. Sie macht die Oberfläche ehrlicher und reduziert unnötige Wiederholungsversuche.
Android Developers: Offline-first
Die tatsächlich ausgeführten Fälle verstehen
Die 38 Kotlin-Prüfungen unterscheiden ungespeicherten Entwurf, gespeicherten Offlinezustand, mögliche Onlineübertragung, laufende Übertragung, Bestätigung und Fehlschlag. Leere Texte werden gesondert behandelt. Negative und zukünftige Revisionswerte werden zurückgewiesen. Eine ältere Bestätigung wird nach einer Textänderung nicht als Bestätigung der neuen Fassung ausgegeben. Diese Fälle betreffen die fachliche Zustandsaussage und sind unabhängig vom endgültigen Aussehen des Bildschirms.
Die Abbildung verwendet drei direkt ausgegebene Ergebnisse: gespeichert ohne Verbindung, Übertragung läuft und Servereingang bestätigt. Alle beziehen sich auf denselben aktuellen Stand. Die sichtbaren Texte wurden aus dem kompilierten Modell übernommen. Das vermittelt eine überprüfbare fachliche Beziehung. Die Grafik beweist weder ein echtes Android-Layout noch eine bereits vorhandene Serververbindung und wird deshalb als schematischer Entwurf eingeordnet.
Für eine App-Abnahme ergänzen wir Geräteprüfungen mit Tastatur, Schriftvergrößerung, TalkBack, Unterbrechung und wiederhergestelltem Entwurf. Die Speicher- und Übertragungswege werden mit tatsächlichen Ergebnissen getestet. Ein einzelner Screenshot reicht dafür nicht. Er ist hilfreich für die visuelle Einordnung, während Zustandswechsel, Persistenz und technische Rückmeldungen eigene Beobachtungen brauchen.
Mit realistischen Aufgaben statt bloßen Bildschirmen abnehmen
Eine geeignete Aufgabe lautet: Beobachtung am Gerät notieren, Entwurf speichern, die App verlassen und später genau diesen Stand wiederfinden. Danach folgt eine Übertragung mit unterbrochener Verbindung. Die Testperson soll anhand der Oberfläche sagen können, was sicher vorhanden ist und was noch fehlt. Diese Frage prüft Verständnis und Verhalten zugleich, statt nur nach dem persönlichen Geschmack für eine Farbe zu fragen.
Ein zweiter Fall verändert den Text nach einer bereits bestätigten Übertragung. Jetzt darf die ältere Bestätigung nicht den neuen Entwurf überdecken. Ein weiterer Fall nutzt größere Schrift und die geöffnete Tastatur. Beobachten Sie, ob die Person die Hauptaktion findet und den Status versteht. Die tatsächlichen Arbeitsbedingungen werden soweit möglich einbezogen, ohne eine Laborvorschau als vollständige Vor-Ort-Prüfung auszugeben.
Zur Übergabe gehören die Zuständigkeit für fachliche Statusbegriffe, die Speicherung und die Fehlerauswertung. Gestaltung und Entwicklung nutzen dieselben Fallbeschreibungen. Wenn ein neuer Status hinzukommt, werden Texte, Aktion und Gegenfälle gemeinsam ergänzt. So bleibt die Anwendung bei wachsendem Umfang verständlich. Eine gute Oberfläche ist kein einmal freigegebenes Bild, sondern die sichtbare Seite eines überprüfbaren Arbeitsablaufs.
Den Umfang bewusst auf die Aufgabe konzentrieren
Unser Beispiel braucht keine Kartenansicht, keinen Chat und kein komplexes Dashboard, um eine kurze Wartungsbeobachtung zuverlässig zu erfassen. Solche Funktionen können in anderen Abläufen sinnvoll sein, sollten aber eine konkrete Aufgabe lösen. Eine App gewinnt nicht allein dadurch, dass mehr vertraute Muster gleichzeitig eingebaut werden. Für die mobile Situation zählt, ob notwendige Arbeit mit klarer Orientierung erledigt werden kann.
Die Gestaltung verwendet daher eine kurze beschriftete Eingabe, einen verständlichen Speicherhinweis, einen gesonderten Übertragungsstand und eine eindeutige nächste Aktion. Diese Teile lassen sich mit dem vorhandenen CI gestalten, ohne ihre Bedeutung zu verändern. Kräftige Markenfarbe kann eine Aktion hervorheben. Sie sollte nicht gleichzeitig jede Information und jede Fehlermeldung gleich dringlich aussehen lassen.
Der entscheidende Qualitätsmaßstab bleibt der reale Vorgang: Der Mensch versteht seinen aktuellen Stand, verliert wichtige Eingaben nicht unbemerkt und erhält eine passende nächste Handlung. Der Kotlin-Baustein liefert dafür einen kleinen überprüften Kern. Die Android-Integration verbindet ihn mit echten Komponenten, dauerhafter Datenhaltung und nachvollziehbarer Verarbeitung. Erst gemeinsam ergibt das eine verlässlich nutzbare mobile Fachanwendung.
Zustände und nächste Handlung
| Situation | Aussage und Aktion |
|---|---|
| Neuer Text | Ungespeicherte Änderungen, Entwurf speichern |
| Gespeichert ohne Verbindung | Auf Gerät gespeichert, auf Verbindung warten |
| Übertragung läuft | Noch keine Bestätigung, Doppelaktion gesperrt |
| Passender Servereingang | Dieser Stand bestätigt, keine fachliche Freigabe behauptet |
| Text nach Bestätigung geändert | Frühere Bestätigung betrifft nur den älteren Stand |
Checkliste für die Android-Abnahme
- Hauptaufgabe und reale Unterbrechungen beschreiben.
- Entwurf, dauerhafte Speicherung und Servereingang trennen.
- Texte und Hauptaktion aus demselben aktuellen Zustand ableiten.
- Große Berührungsflächen und verständliche zugängliche Namen prüfen.
- Tastatur, Systemleisten, Schriftvergrößerung und kleine Fenster testen.
- Ältere Antworten und neue Änderungen nachvollziehbar unterscheiden.
- Prozessende, Wiederherstellung, Fehlschlag und Wiederholung prüfen.
- Kotlin-Logik, Android-Laufzeit und echte Datenverarbeitung getrennt belegen.
Quellen und Prüfstand
Primärquellen am 09.11.2026 geprüft. Wartungsbericht und Zustandsmodell sind eigene fiktive Beispiele. Der Code wurde mit Kotlin/JVM 2.0.21 kompiliert und in 38 isolierten Fällen ausgeführt. Kein Android-Gerätetest und keine tatsächliche Speicherung oder Übertragung werden damit behauptet.
