Augmented Reality
Die AR Helfer – Teil 2
12. April 2018
Heute werden wir zwar nur einen neuen Helper vorstellen, aber wir finden er ist so nützlich, dass er seinen eigenen Blogartikel verdient hat.
Nun ist es endlich soweit und etwas, auf das Ihr alle sicher schon hart gewartet habt, passiert endlich. Die Blogreihe AR Helfer wird mit dem Teil 2 fortgesetzt. 😉
Codename: „Loading on Demand“:
Vielen von euch, die schon einmal bei einem unserer Vorträge oder Technolgieworkshops dabei waren, ist sicher auch schon einmal der Begriff Loading on Demand unterkommen. Viele von euch haben sich aber sicher gefragt, wovon wir da eigentlich reden. Somit stelle ich den neuen AR Helfer mit dem Codenamen Loading on Demand vor welcher ein ausgeklügeltes System für die Datenverwaltung bei Augmented Reality Anwendungen ist.
Was ist nun eigentlich dieses Loading on Demand?
Augmented Reality Anwendungen arbeiten meistens mit 3DModellen, Videos und Bildern als Content und die Dateigrößen dieser Contents sind besonders von 3D Modellen nicht gerade gering. Zur Vereinfachung des Blogs werde ich deshalb später nur noch 3D Modelle als Beispiele für Contents nennen. Das gleiche könnte man aber natürlich auch mit Videos oder Bildern machen. Mit Loading on Demand ist es möglich, diese nicht direkt in die App packen zu müssen, sondern diese später über einen Server nachzuladen. Das Tolle daran ist, dass jedes Modell auch nur einmal geladen werden muss. Danach ist es direkt auf der Festplatte gespeichert und kann von dort abgerufen werden. Wie der Begriff Loading on Demand es schon beschreibt passiert das Laden dann, wenn der Nutzer den Content braucht. Warum man eigentlich diesen Umweg geht und welche verschiedenen Wege wir uns dafür ausgedacht haben, möchte ich euch in diesen Blog genauer erklären.
Warum eigentlich Loading on Demand?
Dafür gibt es mehrere Gründe und alle haben etwas mit der Usability von Apps zu tun. Da besonders bei Augmented Reality Apps meistens große Datenmengen auftreten, ist Loading on Demand ein perfekter AR Helper.
App Store Limits
Der erste und wahrscheinlich wichtigste Grund ist, dass es im Apple App Store und im Google Play Store bestimmte Grenzen für die Dateigröße gibt, mit der eine App über die mobilen Daten (bzw. bei Play Store ohne Warnung) heruntergeladen werden kann (App Store: 150 MB; Play Store: 100 MB). Überschreitet die App diese Größe, muss ein WLAN verfügbar sein bzw. beim Play Store eine Warnung bestätigt werden um die App zu laden. Mit unseren Loading on Demand System müssen diese Daten nicht in der App enthalten sein, sondern können eben dann nachgeladen werden, wenn sie der Nutzer braucht. Somit kann der Nutzer eine leichtgewichtige App (welche auch die Grenzen des App Stores einhält) herunterladen, die nur die wichtigsten Contents enthält und bekommt die anderen Modelle direkt vom Server, wenn er sie braucht.
Verschwendeter Speicherplatz
Wenn alle Modelle direkt in der App sind, kommt natürlich noch hinzu, dass niemand gerne riesige Apps herunterlädt. Noch dazu, wenn sie Modelle enthalten die man potentiell gar nicht braucht. Zum Beispiel möchte sich ein Nutzer oder eine Nutzerin verschiedene Tische mittels Augmented Reality direkt zuhause im Arbeitsraum ansehen. Wären nun alle Modelle aus dem Katalog der Anbieterfirma bereits enthalten, müsste man somit gleich auch alle Modelle von Betten, Couches und Lampen ebenfalls herunterladen. Dies führt zu langen Wartezeiten und einer vollen Festplatte. Mittels Loading on Demand bekommt man die App komplett ohne Modelle (oder möglicherweise nur mit den Topsellern) ausgeliefert und holt sich die aktuelle Liste mit den Bildern aller Modelle vom Server. Dann kann man diese Liste durchsehen, das 3D Modell seines bevorzugten Tisches herunterladen und mittels AR bei sich zu Hause ausprobieren. Somit kann Zeit, Speicherplatz und jede Menge Frust eingespart werden.
Schnelle Updates
Vielen von euch ist sicher schon bekannt, dass es in den beiden Stores zu bestimmten Wartezeiten kommt, bevor eine App in den Store darf. Vorab wird von Apple und Google geprüft, ob sie überhaupt die Richtlinien für Store-Apps einhalten. Bei Apple kann so ein Review schon einmal zwei Wochen dauern. Wären nun alle Modelle direkt in der App verpackt, braucht auch das Austauschen eines bestehenden Modells, das Hinzufügen eines neuen Modells oder das Löschen eines alten Modells ebenfalls diese Zeit. Loading on Demand bietet hierfür also auch einen Ausweg. Es arbeitet mit einen Versionierungssystem, welches immer erkennt, ob es neue Versionen von bereits heruntergeladenen Modellen gibt, bzw. ob Modelle hinzugefügt oder gelöscht werden müssen. Wenn das der Fall ist, werden die Modelle dann direkt vom Server geladen. Somit muss die App dann nicht mehr neu veröffentlicht werden und kann jederzeit neue Modelle vom Server bekommen.
Wann braucht der Nutzer idealerweise die Modelle?
Diese Frage muss eigentlich für jede App gesondert beurteilt werden, jedoch haben sich vier Varianten herauskristallisiert:
1. Modelle sind in der App beim Download der App enthalten:
Manchmal macht es auch Sinn, ein paar Produkte direkt in die App zu packen. Dann kann der Nutzer gleich loslegen und sich diese Produkte ansehen. Daneben hat die App Zeit, sich darum zu kümmern, wann sie die anderen Modelle laden sollen. Jedoch sollte man hier wirklich darauf achten, dass nicht zu viele Modelle enthalten sind. Damit es nicht zu den oben genannten Problemen kommt.
2. Modelle werden beim App Start geladen und auf der Festplatte gespeichert:
Manchmal ist es wichtig, die Modelle verfügbar zu haben bevor die App startet. Somit gibt es bei unserem System (im Backend) ein Priority Feld welches angehakt wird, wenn dieses Produkt besonders wichtig ist. Beim App-Start überprüft die App ob es Modelle am Server gibt, die mit Priority gekennzeichnet sind und noch nicht heruntergeladen wurden und lädt dieser direkt runter. Dies kann zum Beispiel im Hintergrund passieren, sodass der Nutzer inzwischen mit den anderen Funktionen der App arbeiten kann. Andernfalls kann es auch mit einem Tutorial in der App versteckt werden. Hierbei ist jedoch auch wichtig, dass dieses Priority Feld wirklich nur bei den wichtigsten Modellen angehakt wird. Um sowohl viel Speicherplatz zu sparen als auch lange Wartezeiten zu vermeiden.
Beispiel 1: Laden der Modelle beim Start der App, Visualisierung mit Prozessbalken
3. Alle Modelle laden im Hintergrund:
Diese Funktion macht nur dann Sinn, wenn es nicht zu viele Modelle gibt, jedoch alle für die Verwendung der App wichtig sind. Am besten funktioniert diese Variante, wenn sie zusammen mit der ersten Variante eingesetzt wird. Somit packt man ein Modell direkt in die App und die anderen werden im Hintergrund nachgeladen. So kann der Nutzer bereits die App ausprobieren und im Hintergrund vorbereiten sich die anderen Modelle. Mithilfe verschiedener Visualisierungen kann dann angezeigt werden, welche Modelle bereits verfügbar sind und welche noch geladen werden.
4. Der Nutzer entscheidet welches Modell er herunterladen möchte:
Diese Variante ist die einfachste und meistgenutzte Variante. Der Nutzer bekommt eine Liste an verfügbaren Modellen und klickt auf den Download-Button des gewählten Produkts. Das Modell wird heruntergeladen und man kann es direkt verwenden. Wenn man zum Beispiel verschiedene Targets nutzt, kann die App auch durch das erkannte Target das richtige Modell laden. Der Nutzer bekommt hier bereits in Augmented Reality den Fortschritt mittels einer Prozentzahl angezeigt. Somit sind immer nur die für den Nutzer wichtigen Modelle am Smartphone oder Tablet und andere für den Nutzer nicht interessante Modelle werden gar nicht heruntergeladen.
Beispiel 2: Laden der Modelle nach Bedarf, Visualisierung in AR
Die Varianten 2-4 kann man wie oben beschreiben und auch bei Updates von Modellen verwenden. Der Nutzer wird darauf hingewiesen, dass es ein Update zu bestimmten Modellen gibt. Und kann selbst entscheiden, ob er dieses laden möchte oder nicht. Dies sind aus unserer Sicht die besten und am häufigsten gebrauchten Varianten um Modelle für die Augmented Reality Visualisierung von einem Server zu laden. Natürlich gibt es in jeder App Sonderfälle, welche man dann dezidiert ausprogrammieren muss. Deswegen haben wir unser System so offen wie möglich gelassen um auf solche Sonderfälle reagieren zu können.
