Muss das so sein? Nicht unbedingt.
Genau hier setzt das Offline-First-Konzept an. Ziel ist es, eine Anwendung auch ohne stabile Internetverbindung nutzbar zu machen – zumindest bei den Funktionen, die Nutzer am häufigsten benötigen. Das bedeutet nicht, dass jede Funktion offline verfügbar sein muss. Vielmehr soll ein Verbindungsabbruch nicht automatisch dazu führen, dass die Arbeit mit der App unmöglich wird.
Wie funktioniert das in der Praxis?
Daten direkt auf dem Gerät speichern
Die Grundlage einer Offline-First-Anwendung ist die lokale Datenspeicherung. Anstatt bei jedem Öffnen eines Bildschirms alle Informationen vom Server abzurufen, speichert die App die benötigten Daten auch direkt auf dem Gerät.
Dazu gehören beispielsweise gespeicherte Artikel, Aufgaben, Notizen oder Informationen, auf die der Nutzer kürzlich zugegriffen hat. Die Daten können in einer lokalen Datenbank, in Dateien oder in einer anderen Form des Gerätespeichers abgelegt werden.
Öffnet der Nutzer die App ohne Internetverbindung, kann er weiterhin mit den bereits gespeicherten Informationen arbeiten. Die App muss nicht auf eine Serverantwort warten und kann verfügbare Inhalte auch bei einer schwachen Verbindung anzeigen.
Dabei gibt es allerdings einen wichtigen Unterschied: Lokal gespeicherte Daten sind nicht unbedingt aktuell. Wenn jemand Informationen auf dem Server oder auf einem anderen Gerät geändert hat, weiß die App möglicherweise noch nichts davon. Deshalb reicht es nicht aus, Daten einfach nur zu speichern. Sie müssen auch aktualisiert werden können.
Was passiert, wenn der Nutzer offline Änderungen vornimmt?
Stellen wir uns eine Aufgabenverwaltungs-App vor. Während der Fahrt mit der U-Bahn erstellt ein Nutzer eine neue Aufgabe, legt eine Frist fest und speichert sie.
Wenn die App eine permanente Internetverbindung voraussetzt, kann das Speichern fehlschlagen. Bei einer Offline-First-Anwendung lässt sich die Änderung dagegen zunächst lokal auf dem Gerät speichern. Der Nutzer sieht die neue Aufgabe und kann weiterarbeiten.
Gleichzeitig merkt sich die App, dass diese Änderung noch an den Server übertragen werden muss.
Hier kommt eine Offline Queue ins Spiel – eine Warteschlange für ausstehende Vorgänge. Man kann sie sich wie eine Liste von Aufgaben vorstellen, die die App erledigen muss, sobald wieder eine Internetverbindung verfügbar ist.
Sobald die Verbindung wiederhergestellt ist, beginnt die App, die ausstehenden Änderungen zu übertragen. Schlägt ein Vorgang fehl, kann sie einen erneuten Versuch starten.
Allerdings lässt sich nicht jede Aktion sicher aufschieben. Eine Banküberweisung, die eine Bestätigung durch den Server erfordert, gilt beispielsweise nicht allein deshalb als erfolgreich, weil der Nutzer auf eine Schaltfläche geklickt hat. In solchen Fällen muss die App klar zwischen einer noch ausstehenden Anfrage und einer tatsächlich bestätigten Transaktion unterscheiden.
Synchronisierung: Wenn alles wieder auf dem gleichen Stand sein muss
Sobald die Internetverbindung wieder verfügbar ist, muss die App die lokal gespeicherten Daten mit den Daten auf dem Server abgleichen. Dieser Vorgang wird Synchronisierung genannt.
Im einfachsten Fall überträgt die App die offline vorgenommenen Änderungen und lädt die neuesten Informationen vom Server herunter. In der Praxis kann die Synchronisierung jedoch komplizierter sein, insbesondere wenn Nutzer auf mehreren Geräten gearbeitet haben.
Stellen wir uns vor, Sie ändern morgens den Titel einer Aufgabe auf Ihrem Smartphone. Später bearbeitet ein Kollege dieselbe Aufgabe auf einem anderen Gerät. Beide Geräte haben möglicherweise mit derselben ursprünglichen Version begonnen, die Informationen aber unterschiedlich verändert.
Was passiert, wenn sich beide Geräte wieder mit dem Internet verbinden?
Konflikte: Wenn zwei Änderungen aufeinandertreffen
Wird dieselbe Information an mehreren Stellen geändert, bevor die Synchronisierung stattfindet, muss die App entscheiden, wie diese Änderungen zusammengeführt werden. Dieser Vorgang wird Konfliktlösung (Conflict Resolution) genannt.
Eine Möglichkeit ist die Regel Last Write Wins. Dabei gewinnt die letzte Änderung, basierend auf einem festgelegten Zeitstempel. Das ist allerdings nicht immer die beste Lösung. Welcher Ansatz sinnvoll ist, hängt von der Art der Daten und den Folgen ab, die das Überschreiben einer Änderung haben könnte.
Bei einer einfachen Einkaufsliste kann eine automatische Regel ausreichen. Bei einem gemeinsam bearbeiteten Dokument oder wichtigen Geschäftsdaten kann es dagegen notwendig sein, Änderungen zusammenzuführen oder dem Nutzer den Konflikt anzuzeigen, damit er selbst entscheiden kann.
Deshalb sollten die Regeln für Synchronisierung und Konfliktlösung bereits bei der Planung der Anwendung berücksichtigt werden. Werden diese Fragen erst später geklärt, kann das zu Datenverlust oder unvorhersehbarem Verhalten führen.
Was passiert, wenn die Verbindung immer wieder abbricht?
Auch nach der Wiederherstellung der Verbindung funktioniert nicht unbedingt alles auf Anhieb. Das Netzwerk kann instabil sein, der Server vorübergehend nicht reagieren oder eine Anfrage aus einem anderen Grund fehlschlagen.
Deshalb benötigen Offline-First-Anwendungen zuverlässige Retry-Mechanismen, also Mechanismen für erneute Versuche. Bei vorübergehenden Fehlern kann die App versuchen, eine Anfrage erneut zu senden. Häufig werden die Wartezeiten zwischen den Versuchen dabei schrittweise verlängert. Dieser Ansatz wird als Exponential Backoff bezeichnet.
Wichtig ist jedoch, nicht jede Anfrage unüberlegt zu wiederholen. Lehnt der Server eine Aktion ab, weil dem Nutzer die erforderlichen Berechtigungen fehlen, wird das Problem durch Warten nicht gelöst. Bei Vorgängen, die Daten verändern, muss außerdem verhindert werden, dass dieselbe Aktion durch einen erneuten Versuch doppelt ausgeführt wird.
Die App sollte dem Nutzer auch zeigen, was gerade passiert. Wurde die Änderung nur auf dem Gerät gespeichert? Wartet sie auf die Übertragung? Hat der Server sie bereits bestätigt? Eine klare Statusanzeige ist deutlich hilfreicher als eine allgemeine Fehlermeldung.
Offline First ist mehr als ein technisches Feature
Ein Offline-First-Ansatz kann die Nutzererfahrung erheblich verbessern, insbesondere auf Reisen, bei der Arbeit im Außendienst oder in Gebieten mit unzuverlässiger Internetverbindung. Die App kann schneller reagieren, Nutzer müssen verlorene Eingaben nicht erneut machen und eine vorübergehende Verbindungsstörung muss ihre Arbeit nicht unterbrechen.
Gleichzeitig erfordert dieser Ansatz sorgfältige Planung. Welche Daten sollen offline verfügbar sein? Welche Änderungen können sicher gespeichert und später übertragen werden? Wie werden Konflikte gelöst? Was passiert, wenn die Synchronisierung wiederholt fehlschlägt?
Die Antworten hängen von der jeweiligen Anwendung ab. Eine Offline-First-Notiz-App stellt andere Anforderungen als eine Banking-App oder ein Tool für die Zusammenarbeit in Echtzeit.
Eine gute Offline-First-Anwendung verspricht nicht, dass sie niemals eine Internetverbindung benötigt. Sie sorgt aber dafür, dass ein Verbindungsabbruch den Nutzer nicht unnötig bei seiner Arbeit aufhält.
Genau das ist der Unterschied zwischen einer App, die nur unter idealen Bedingungen funktioniert, und einer Anwendung, die für die reale Welt entwickelt wurde.
