Cookies? Ja, auch wir haben welche. Mehr dazu gibts in der Datenschutzerklärung.

1. Apr 2019

Pascal Vogt

Software Engineer

Vorgehen

Ausgangslage

Eine unserer nativen iOS- und Android-Apps wird seit einigen Jahren von einem Grossverteiler zur Qualitätskontrolle in vielen Filialen eingesetzt. Diese App muss mit neuen Features aufgewertet werden. Auf der bestehenden Codebasis müsste sehr viel angepasst werden, was sich für die bestehende App jedoch nicht mehr lohnen würde – der Aufwand wäre schlicht zu hoch.

Gemeinsam mit dem Auftraggeber wurde entschieden, die App neu als Web-App mit einer Offline-Synchronisation zu bauen. Was auf den ersten Blick einfach klingt, hat sich in der Praxis als Weg mit vielen Stolpersteinen entpuppt. Unsere Erfahrungen damit teilen wir in diesem Blog mit interessierten Entwicklern.

Feldtest mit zwei Prototypen

Die Voraussetzungen waren soweit bekannt, dass wir wussten, mit welchen Hürden bei der WiFi-Versorgung in den Filialen zu rechnen war. Schon mit den native Apps traten immer wieder Verbindungsprobleme auf, die auf unterschiedlich konfigurierte WLAN-Hotspots und Endgeräte (Smartphones und Tablets mit iOS und Android) zurückzuführen waren. Damit wir besser auf die WiFi-Versorgung und die Endgeräte eingehen konnten, bauten wir zwei verschiedene Prototypen für einen Feldtest.

Die Tests fanden auf verschiedenen Geräten statt, in verschiedenen Filialen, an mehreren Standorten.

Erkenntnisse aus dem Feldtest

Der Feldtest lieferte uns wichtige Erkenntnisse:

  • Das Netzwerk hat sich nochmals anders verhalten. Es war langsamer und gab mehr Netzwerkwechsel und Unterbrüche.
  • Auf einem modernen Android Gerät hat die Web-App inkl. Synchronisation bereits als Prototyp sehr gut funktioniert.
  • Die Prototypen verhalten sich zwischen iOS, Android und Windowsgeräten sehr unterschiedlich.
  • Die Nutzer verwenden die App unterschiedlich.
  • Die Datenmenge während dem Test ist entscheidend für die Messergebnisse.

 

Probleme und Erkenntnisse

Unterschätzte Unterschiede in der Rechenleistung

Uns war klar, dass die Rechenleistung der Smartphones einer der einschränkenden Faktoren für die Performance der Web-App darstellt. Eher überrascht waren wir jedoch von den Einschränkungen, die uns die verschiedenen Browser auf den Smartphone und auch auf PCs auferlegten. Dazu gehörten verfügbarer lokaler Speicher und die zur Verfügung stehende CPU Leistung.  Performance der Anzeige, Einschränkung von genutzten Funktionen. 

Synchronisation abhängig vom Endgerät

Bei der Synchronisation sind sehr viele Komponenten involviert. Dadurch ergeben sich verschiedene Möglichkeiten, wie die Ereignisse während der Synchronisation ablaufen können. Dadurch kann es sein, dass ein Problem nur bei einer spezifischen Geräte/Browser-Kombination auftaucht, weil dort beispielsweise ein Touch-Event in einer anderen Reihenfolge abgehandelt wird oder weil ein Übergang in der Netzwerkverbindung aggressiver gehandhabt wird als bei anderen Geräten.

Synchronisation durch Browser und Kamera beeinflusst

Dass der Internet Explorer oft Probleme verursacht, wissen wir schon lange. Dass der IE bei Operationen mit hoher lokaler CPU-Last im Vergleich zu den modernen Browsern aber so extrem schlecht performt, war für uns neu. Und die Synchronisation braucht kurzzeitig eine recht hohe Rechenleistung!

Fotos beanspruchen aufgrund der stetig wachsenden Pixel-Dichte der Handykameras immer mehr Speicherplatz – was sich wiederum auf die Performance auswirkt, wenn die Fotos durch die App skaliert werden müssen. Beim Skalieren muss das Bild in unkomprimierter Form im Memory bearbeitet werden. Eine native App nutzt dazu die Onboard-Funktionen, die Web-App im Browser ist auf die limitierten Memory-Zuweisungen pro Tab angewiesen. Diese Limiten müssen berücksichtigt werden, damit es nicht zum Absturz der Web-App kommt.

Synchronisation ist komplex!

Um die Komplexität der Synchronisation im Griff zu behalten, hat die Definition und die strikte Einhaltung von Regeln absolute Priorität. Die Anwender verlassen sich auf diese Mechanismen und verlieren das Vertrauen in die Web-App, wenn die Daten nicht in jedem Fall synchron sind.

Dem Timing muss besondere Aufmerksamkeit geschenkt werden. Wir haben die Strategie gewählt, dass immer der Datensatz mit dem neusten Zeitstempel in der Synchronisation gewinnt. Abweichende Zeitzonen-Einstellungen und viele weitere Faktoren können sich dabei negativ auswirken.

Der weiter oben beschriebene Effekt mit der grossen Datenmenge bei Bildern hat die Synchronisation ebenfalls massiv beeinflusst. Um auch grosse Mengen von Bildern während der Synchronisation handhaben zu können, ohne dass der Browser den Geist aufgibt, setzten wir dazu den aus der TCP-Verarbeitung bekannten «Exponential Backoff» ein.

Datenmenge im Auge behalten

Ist die zu synchronisierende Datenmenge zu gross, entwickelt der Browser mehr oder weniger spontan (je nach Fabrikat) die Neigung, Daten einfach zu löschen. Wenn bei länger dauernden Schreiboperationen in die lokale Datenbank der Browser länger keine Rückmeldung gibt, kann es entweder an der schlechten Performance liegen (besserer Fall), oder die Operation wird einfach nicht ausgeführt (schlechter Fall). Es ist daher wichtig, die Datenmenge stets so klein wie möglich zu halten, was – siehe weiter oben – gerade bei vielen Bildern nicht einfach ist.

Ergebnis

Die neue Web-App ist bei zehn Mandanten installiert und wird von über 700 Benutzern zur Qualitätskontrolle im Retailbereich (Fach- und Supermarkt) eingesetzt. Seit dem Start der neuen Web-App werden pro Monat rund 1’500 Qualitätskontrollen durchgeführt, ausgewertet und als Basis für Verbesserungen aller Art verwendet.

zum Blog

Genossenschaft Migros Aare FRISCHE WINNER

Jetzt frisch in Ihrer Migros: Diesen Slogan kennen die Kunden des grössten Lebensmittelhändlers der Schweiz. Und dank Frische Winner sind die Produkte dort jetzt noch frischer.

Thomas Schuoler 5. Jan 2018 Hat Individualsoftware ausgedient?

Warum sich der Weg in die Standardisierung nicht immer lohnt

Kontakt aufnehmen