Offlinefähigkeit in mobilen Applikationen

1. September 2014

Die Anzahl von mobilen Applikationen wächst heutzutage immer schneller an. Diese Feststellung gilt sowohl für die sog. Store-Apps (die öffentlich den Kunden zur Verfügung gestellt werden) als auch für Enterprise Applikationen, die in dem Backend des Unternehmens intergiert werden. Viele von diesen Anwendungen funktionieren aber nur dann, wenn eine Verbindung mit dem Internet besteht.

Manchmal, selbst im Fall von kurzen Verbindungsabbrüchen, ist die weitere Arbeit mit der Anwendung unmöglich. Dies kann allerdings in manchen Geschäftsszenarien nicht akzeptabel sein. Um die Benutzererfahrung zu verbessern und dieses Problem zu lösen, bieten viele Anwendungen Offlinefähigkeit an. Wenn man sich diese mobilen Anwendungen genauer anschaut, scheint die Verwendung des Begriffs der Offlinefähigkeit inkonsistent zu sein. Es gibt keine einheitliche Implementierung von Offlinefähigkeit.

Man kann folgende Varianten von Offlinefähigkeit unterschieden:

Varianten der Offlinefähigkeit

  • Variante 0: Keine Offlinefähigkeit

Die Anwendung hört auf zu funktionieren oder stürzt einfach ab, wenn sie die Verbindung verliert.

  • Variante 1: Erkennung von Verbindungsabbrüchen

Bei dieser Variante erkennt die Anwendung lediglich Verbindungsabbrüche. Die weitere Arbeit ist nicht möglich, aber die Applikation wird weiterhin ausgeführt und stürzt nicht ab. Der Benutzer wird aber eventuell eine Fehlermeldung bekommen.

  • Variante 2: Überwindung von kurzen Verbindungsabbrüchen

Die Applikation funktioniert trotz kurzfristiger Verbindungsabbrüche. In dieser Variante gibt es aber keine lokale Persistenz von Daten und Synchronisation mit dem Server. Die Anwendung kann beispielweise die Verbindung automatisch wiederherstellen. Daten hingegen werden zumindest teilweise auch in Voraus geladen werden, damit die App auch offline funktioniert.

  • Variante 3: „Echte“ Offlinefähigkeit

Die Anwendung ist ohne Internetverbindung funktionsfähig. Der Benutzer kann nicht nur Daten einsehen, sondern diese auch hinzufügen und löschen. Diese werden lokal auf dem Endgerät zwischengespeichert. Dazu müssen sie aber auch mit dem Server synchronisiert werden. Der Benutzer kann kontinuierlich arbeiten, ohne darauf zu achten, ob er gerade online oder offline ist. Diese letzte Variante ist die Schwierigste, wenn es um die praktische Umsetzung geht.

Bei der Implementierung der Offlinefähigkeit muss man sich also zunächst die Frage stellen, um welche Art von Offlinefähigkeit es sich handeln soll.

Sollte man sich für Variante 3 entscheiden, steht man vor einigen Herausforderungen:

  • Persistenz der lokalen Daten – unterschiedliche Plattformen bieten diverse Möglichkeiten der Datenpersistenz. Die können sowohl in relationaler, wie beispielsweise bei WebSQL oder SQLLite, als auch in unstrukturierter Form (z. B. im Filesystem) vorliegen.
  • Art und Weise der Integration mit dem bestehenden Backend – das heißt wie die Endanwendung auf dem Server integriert wird.
  • Synchronisierung von Daten – die Daten von sämtlichen Endgeräten müssen mit dem Server synchronisiert werden. Sämtliche Aspekte, wie z.B. Konflikterkennung und Konfliktlösung müssen sorgfältig durchdacht werden.

Die Architektur für diese Variante wird auf dem folgenden Bild schematisch dargestellt:

flurfunkOffline1

 

Fazit

Offlinefähigkeit ist ein sehr interessantes Feature, das die Benutzererfahrung mit mobilen Anwendungen erheblich verbessern kann. Wenn der Anwender ständigen Verbindungsabbrüchen ausgesetzt ist, scheint diese Funktionalität ein unabdingbares Element der modernen Entwicklung von mobilen Apps zu sein.

Für die Art der Umsetzung muss man sich entsprechend Gedanken machen, ob die einfachste Variante reicht oder ob das Businessszenario die echte Offlinefähigkeit notwendig macht. Der Fokus muss hierbei auf der Erkennung der Bedürfnisse des Kunden liegen, um die passende Variante zu wählen.