Versteckte Kosten einer offline App

Die Herausforderungen in einem Softwareprojekt sind so vielfältig wie die Anforderungen selbst. Oft fordern die Gegebenheit am Kundenstandort eine offline App: Zum Beispiel durch die schwache Netzabdeckung in einem entlegenen Seitental, in einem Gebäude mit massivem Stahlbeton und gut isolierten Fenstern oder in einer sehr ländlichen Gegend.

Um besser zu verstehen, wann eine offline App Sinn macht, teilen wir ein Beispiel aus unserem Arbeitsalltag.

Für Viterma haben wir einen Offline-Badkonfigurator entwickelt. Ziel war es, dass Mitarbeiter:innen im Vertriebsaußendienst bei Kund:innen vor Ort komplexe Angebote erstellen, konfigurieren und kalkulieren können, ohne auf eine Internetverbindung angewiesen zu sein.

Die User synchronisieren (regelmäßig) ihre Daten und laden dadurch ihre Änderungen hoch sowie die neuesten Daten herunter, um offline arbeiten zu können und einen möglichst aktuellen Datenstand zu haben.

3 Szenarien: Versteckte Kosten einer offline App

Wer über die Entwicklung einer offline App nachdenkt, sollte auch die „Kostenfallen“ kennen. Werden bestimmte Funktionen on- und offline zur Verfügung gestellt, entstehen Mehrkosten. Im besten Fall entspricht die On- und Offline-Geschäftslogik dem (fast) gleichen Code. Dann unterscheidet sich nur die Art und Weise, wie man an die Daten kommt (z.B. via API, wenn man online ist oder aus der Datenbank des Browsers, wenn man offline ist).

Doch es gibt auch Geschäftslogiken, in deren Entwicklung sich Kosten verstecken, die auf den ersten Blick nicht offensichtlich sind. Wir erinnern uns an den Badkonfigurator für Viterma – hier ein paar Beispiele, wo und wann unerwartete Mehrkosten entstehen könnten: 
 

1. Eine neue Einstellung wird hinzugefügt

Einstellungen haben in unserem Fall Auswirkungen auf den Preis, da sie für die Preiskalkulation verwendet werden. Mit einer Applikation, die offline genutzt werden kann, ergeben sich folgende Szenarien:

• Unterschiedliche Angebotsversionen
  Nehmen wir an, ein User aktualisiert auf die neueste Version der Applikation und synchronisiert die Daten. Was passiert, wenn ein älteres Angebot synchronisiert wird, in dem die neu hinzugefügten Einstellung noch gar nicht verwendet wurde? 
  Eine Migration ist notwendig. Je älter das Angebote, desto mehr Migrationen müssen angewendet werden. Diese müssen immer miteinander kompatibel sein, auch wenn sich die zugrunde liegenden Daten (z.B. Produkte, Einstellungen) inzwischen geändert haben. 
• Neue App-Version, alten Daten
  Hat ein User auf die neueste Version der Applikation aktualisiert, aber aus diversen Gründen nicht synchronisiert, hat er jetzt eine Applikationsversion, welche die neue Einstellung erwartet. Die Einstellung selbst fehlt aber noch. Somit kann der Angebotspreis nicht korrekt berechnet werden. Ob diese Situation verhindert werden muss oder akzeptabel ist, hängt von der Geschäftslogik ab.
• Alte App-Version, neues Angebot
  Hat ein User noch nicht auf die neueste Version aktualisiert, aber öffnet online ein Angebot, bei dem die neue Einstellung bereits verwendet wird, muss man ihn daran hindern, dieses mit einem alten Stand zu überschreiben und ihn darauf hinweisen, dass er updaten muss.
   

2. Verteilte Daten

Sobald man Daten nicht nur an einer zentralen Stelle verwaltet (z.B. Datenbankserver), sondern auch offline zur Verfügung stellt, hat man mehrere Datenstände. Einen zentralen in der Datenbank und einen weiteren pro Endgerät. Diese Datenstände ändern sich in unregelmäßigen Abständen, z.B. wenn der User synchronisiert oder Daten in der zentralen Datenbank geändert werden, z.B. durch den nächtlichen Import. Es ergeben sich also unzählige Kombinationen von Datenständen, die mitunter auch zu unterschiedlichen Ergebnissen in der Applikation führen.

Das ist speziell dann verwirrend, wenn mehrere User dieselben Schritte mit den gleichen Parametern durchführen, aber unterschiedliche Ergebnisse in der gleichen Applikationsversion bekommen.

Im Fall des Badkonfigurators stellt sich den Usern meist die Frage, wie sich der Preis zusammensetzt. Deswegen könnte eine Protokollierung der Preise und angewandten Einstellungen eine Lösung sein. Das war für uns der richtige Schritt, um auch anderen Anforderungen gerecht zu werden.

3. Konfliktbehandlung

Sobald man mehrere Datenstände zu ein und demselben Datensatz (in unserem Fall das Angebot) hat, kommt es zu Konflikten. Was passiert, wenn ich offline und online das gleiche Angebot bearbeitet habe? Gewinnt immer offline oder immer online oder immer der Letzte?

Wir haben verschiedene Strategien für die Konfliktlösung implementiert, die die User bei ihrer täglichen Arbeit unterstützen. Es kann aber auch Szenarien geben, in denen es schlicht unmöglich ist, die richtige Entscheidung automatisiert zu treffen. Zum Beispiel kann sich ein Angebot in unterschiedlichen Status befinden, aber nur im Status „Erstellt“ darf es bearbeitet werden. Was passiert, wenn ein Angebot online im Status „Bestellt”, aber offline im Status „Erstellt“ ist und wichtige Änderungen beinhaltet?
 

Überlegungspunkte für die Entwicklung einer offline App

Unsere Erfahrung zeigt, dass neben den eben genannten Stolperfallen einige technische Punkte beachtet werden müssen.

• Implementierung im Frontend oder Backend: Die Logik fürs offline Arbeiten muss im Frontend implementiert werden, weil sie offline zur Verfügung stehen soll. Logik, die im Frontend läuft, kann aber deutlich einfacher umgangen werden. Man kann die Applikation entweder nur einer vertrauenswürdigen Gruppe zugänglich machen oder doch alles im Backend implementieren und einen deutlichen Mehraufwand in Kauf nehmen.
• Lokaler Speicherplatz: Der Speicherplatz im Browser ist limitiert und der Browser kümmert sich darum, dass vermeintlich selten verwendete Dateien gelöscht werden. Es kann also vorkommen, dass Produktbilder plötzlich nicht mehr angezeigt werden. Eine Lösung wäre die Dateienverwaltung über eine neue Dateisystem-API im Browser – was natürlich mit mehr Aufwand verbunden ist.
• Internetgeschwindigkeit vs. große Datenmengen: In der heutigen Zeit und mit den technischen Möglichkeiten will man Produkte natürlich über Bilder, Kataloge oder gar Videos zeigen. Bei zig-Tausenden Produkten kann der (initiale) Download dementsprechend viel Zeit und Ressourcen in Anspruch nehmen.
• Online-Offline-Detection: Die Funktion zum Feststellen, ob ich gerade online oder offline bin, ist von Browser zu Browser und von Betriebssystem zu Betriebssystem unterschiedlich und dadurch nicht sehr zuverlässig: Mitunter wird keine Unterscheidung zwischen „mit Netzwerk verbunden“ und „Internet“ verfügbar gemacht oder sie geschieht erst sehr zeitversetzt. 
• Versionierung von APIs: Schnittstellen zwischen Offline-Client und Backend können nicht so einfach geändert werden, da sonst ältere Clients nicht mehr funktionieren. Eine gewisse Zeit lang muss man also kompatibel mit den alten Clients bleiben, was die Weiterentwicklung ein Stück aufwendiger macht. 
   

Fazit

Anhand der oben genannten Szenarien sollte klar sein, welches Ausmaß an Entscheidungen und Überlegungen eine offline App mit sich bringt. 
Für sich alleine gesehen sind einige einfach lösbar, aber durch die Menge, die sich bei einer großen Applikation anhäufen, fallen sie stark ins Gewicht. Bei der Entscheidung „Offline: ja oder nein?“ gibt’s also vieles zu bedenken.

Mein Tipp: 
Bei neuen und ähnlich komplexen Projekten gehen wir aufgrund unserer Erfahrungen von einem Mehraufwand von 50–80 % für die Offline-Fähigkeit aus. Das beste Ausgangsszenario ist, wenn bereits bei der Planung und Konzeption alle Ideen, Wünsche und Features auch unter dem Aspekt der Offline-Fähigkeit beleuchtet werden. Gemeinsam versuchen wir dann spezifische Zusammenhänge und deren Bedeutung zu analysieren. Zum Beispiel steigen mit einer offline App der initiale Implementierungsaufwand und die Komplexität, damit auch die Wartbarkeit. Eine schwierigere Wartbarkeit führt wiederum zu höheren Aufwänden für die laufenden Wartung und zukünftige Anpassungen. Und so weiter.