„Die App soll auch offline funktionieren“ klingt nach einer Anforderung an die Netzwerkschicht. Tatsächlich ist es eine Anforderung an das Datenmodell – und sie lässt sich später kaum noch nachrüsten.
Der übliche Irrtum
Der naheliegende Ansatz lautet: Serverantworten zwischenspeichern und bei fehlender Verbindung den letzten Stand anzeigen. Das funktioniert für Lesezugriffe. Sobald der Benutzer offline etwas ändert, entstehen Fragen, die ein Cache nicht beantwortet:
- Welcher Stand gilt, wenn dieselbe Information auf zwei Geräten geändert wurde?
- Was passiert mit einer Änderung, deren Übertragung dauerhaft fehlschlägt?
- Wie erkennt der Benutzer, dass sein Gerät nicht den aktuellen Stand zeigt?
Engineering Note
Ein Cache verschiebt die Entscheidung, wem ein Datensatz gehört. Offline-first trifft sie.
Die eigentliche Entscheidung
Offline-first bedeutet: Das Gerät ist die führende Quelle für die Daten, die dort entstehen. Der Server – falls es einen gibt – ist ein weiterer Beteiligter, nicht die Wahrheit.
Daraus folgen konkrete Festlegungen im Datenmodell:
- Jeder Datensatz braucht eine geräteseitig erzeugbare Identität, keine vom Server vergebene laufende Nummer.
- Zeitstempel müssen aussagekräftig sein, auch wenn die Geräteuhr falsch geht.
- Löschungen brauchen eine explizite Darstellung, sonst kehren gelöschte Einträge zurück.
Der einfachste Fall: kein Backend
Die konsequenteste Variante ist, gar keinen Server vorzusehen. Damit entfallen Konfliktauflösung, Kontenverwaltung und der gesamte Bereich der Datenübertragung.
Der Preis ist ebenso klar: Ein Gerätewechsel ist eine bewusste Handlung des Benutzers, und es gibt keinen Abgleich zwischen zwei Geräten desselben Benutzers.
Entscheidung
Diese Variante ist bei AuraHarmony umgesetzt: Sämtliche Daten verbleiben auf dem Gerät, ein Serverabgleich findet nicht statt.
Migrationen nicht vergessen
Lokale Datenhaltung heißt lokale Schemaänderungen. Jede Version, die je installiert war, muss auf den aktuellen Stand migrierbar sein – auch wenn dazwischen mehrere Versionen übersprungen wurden.
// Migrationen werden explizit und lueckenlos angegeben.
// Ein uebersprungener Schritt faellt sonst erst beim Nutzer auf.
val migrations = arrayOf(
MIGRATION_1_2,
MIGRATION_2_3,
MIGRATION_3_4,
)
Risiko
Eine fehlende Migration führt beim Benutzer zu Datenverlust und lässt sich nach der Auslieferung nicht mehr korrigieren.
Was das für die Planung bedeutet
Die Frage „soll die App offline funktionieren“ gehört an den Anfang, nicht in die zweite Ausbaustufe. Sie entscheidet über Identitäten, Zeitstempel, Löschsemantik und Migrationsstrategie – also über das Fundament.
Eine Einordnung des Arbeitsfelds gibt die Seite Mobile Development.