Qualität, die man spürt

Im Laufe der Zeit haben wir mittlerweile schon einige Apps gebaut und haben dabei stetig an dem „guten Gefühl“ der Apps gebastelt. Eine App ist erst dann richtig gut, wenn ich sie einfach in die Hand nehmen kann und die Benutzung ohne weitere Erklärung verstanden habe. Wenn das Ganze dann flüssig funktioniert und ich nicht ständig warten muss, oder bei Netzaussetzern die App unbenutzbar wird, dann hat die App einen guten Habitus.

Qualität spürt man, insbesondere wenn Sie nicht da ist – so ist es auch bei Apps. Damit sich die Apps die auf unserem AppFramework basieren gut „anfühlen“ und zügig arbeiten haben wir einige Maßnahmen ergriffen:

 

Caching – Preload – Offline

Wir haben unser AppFramework mit einem intelligenten Caching-Mechanismus ausgestattet. Das Caching sämtlicher Inhalte folgt einer unserer Caching Regeln. Vereinfacht gesagt sind das: „nicht cachen“, „cachen wenn nicht älter als“ oder „für immer cachen“.  Darüber hinaus kann für jedes Element der Navigationshierarchie angeben werden, ob und wie viele seiner Kinder vorgeladen werden sollen – das sogenannte Preload. Das Preload wirkt dabei sowohl auf einzelne Kinder eines Elements in der Navigationshierarchie, wie auch auf die ganze App ab dem Root-Navigationselement. Die Kombination aus Caching und Preload bilden den Offline-Mechanismus des AppFrameworks. Der Offline-Mechanismus erlaubt es, dass alle Elemente die einmal geladen und im Cache gespeichert worden sind auch im Flugmodus oder in anderen Situationen in denen kein Netzzugriff möglich ist vorhanden sind.

 

Geschwindigkeit – Image-Cruncher

Die Geräte auf denen unseren Apps laufen sind heute technisch gesehen alle ausreichend schnell. Ich hatte letztens ein altes iPhone 3Gs in der Hand – was für ein Unterschied. Der Flaschenhals ist das Netz. Oft ist man im WLAN, aber gerade wenn man unterwegs ist hat man manchmal ein schwaches Netz. Da unsere Apps die Inhalte und die Bilder von unterschiedlichen Quellen laden können hatten wir in der Vergangenheit immer mal wieder ein Performance-Problem. Die Texte sind nicht das Problem, aber gerne wurde im CMS des Kunden das ein oder andere 2 MB Bild hochgeladen. Über WLAN kommt das zwar schnell an, den mobilen Benutzer aber lässt es verzweifeln. Auf einem normalen Phone brauche ich keine Bilder mit 4000×3000 Pixeln, da reichen für die Thumbnails und Ansicht manchmal 10-20 % dieser Größe. Einige Maßnahmen, wie beispielsweise der gezippter Transfer u.a., haben wir in unseren Apps schon getroffen, aber das wichtigste und neueste Feature ist unser ImageCruncher. Der ImageCruncher funktioniert als eine Art Proxy und kann jedes Bild das die App benötigt dynamisch auf die benötigte Größe „crunchen“. Neben der Größenanpassung kann der ImageCruncher das Bild auch verändern (z. B. runde Bildmaske). Die Verbesserungen der App im Bereich Geschwindigkeit und damit auch im Habitus seit der Einführung des ImageCrunchers lassen sich recht einfach zusammenfassen: WOW! Das hat echt was gebracht! Wir brauchen viel weniger Bandbreite, können deutlich mehr Bilder cachen und die Geräte müssen die Bilder zur Darstellung weniger umrechnen.

 

Caching und Performance sind zwei wichtige Aspekte die man nicht sieht, aber spürt!