Auf Mobilgeräten ist Konnektivität nie selbstverständlich: U-Bahn, Aufzug, Flugzeug. Eine Offline-First -App behandelt den Offline-Zustand nicht als Fehler, sondern als Normalzustand — das Netzwerk ist nur eine Optimierung. Mit Flutter und Firebase gibt es das fast geschenkt.

Firestore ist standardmäßig Offline-First

Das Firestore-SDK pflegt einen persistenten lokalen Cache und bedient Lesezugriffe aus diesem Cache , wenn kein Netzwerk verfügbar ist. Auf Mobilgeräten ist das standardmäßig aktiviert; es lässt sich explizit konfigurieren:

Schreibvorgänge werden in eine Warteschlange eingereiht

Ein Schreibvorgang im Offline-Modus schlägt nicht fehl: Er wird in eine lokale Warteschlange eingereiht und bei Netzwiederkehr erneut ausgeführt. Die UI kann die Daten sofort anzeigen (optimistisches Lesen) dank des Flags hasPendingWrites , das in den Metadaten des Snapshots verfügbar ist:

Konflikte auflösen

Zwei Geräte ändern dasselbe Dokument offline: Wer gewinnt? Standardmäßig gilt Last-Write-Wins , was Daten überschreiben kann. Für einen Zähler bevorzugt man FieldValue.increment() (kommutativ, also konfliktfrei); für alles andere entscheidet ein updatedAt mit FieldValue.serverTimestamp() zum Zeitpunkt der Synchronisierung.

• › Zähler → increment()
• › Server-Zeitstempel → serverTimestamp()
• › Komplexe Geschäftsregel → eine Transaktion in einer Cloud Function

Offline testen

Offline wird nicht „nach Gefühl" getestet: firestore.disableNetwork() erzwingt den Offline-Modus in einem Integrationstest, enableNetwork() spielt anschließend die Warteschlange erneut ab. Der Firestore-Offline-Leitfaden dokumentiert jede API.

Offline-First bedeutet nicht, einen Netzwerkausfall zu behandeln. Es bedeutet, die App so zu gestalten, als würde das Netzwerk nicht existieren , und die Synchronisierung zu einem bloßen Implementierungsdetail werden zu lassen.