The day you have surely been waiting for has finally arrived. Our blog series “AR Helpers” continues with part 2. We will be discussing only one Helper today, but in our opinion, this one is so useful that it deserves its very own article.
Codename: “Loading on Demand”:
Anyone who’s ever been at one of our talks or technology workshops has probably heard of Loading on Demand. But some may still not know what we are talking about. I therefore present to you the new AR Helper with the Codename: Loading on Demand, which is an awesome system for data management in AR applications.
What’s Loading on Demand?
Often Augmented Reality apps use 3D models, videos or pictures as content and the size of these data (especially 3D models) is usually not so small. For simplification, I only will use 3D models synonymously for content from now on. The same would, however, be possible with videos or pictures as well.
With Loading on Demand you don’t have to include all models in the app from the get-go. Instead, they are downloaded later when you need them. And the great thing is that you only need to download these models once, after which they are saved in the storage of your device and will be used from then on. As the term Loading on Demand suggests, the download happens at the exact time the user needs the content. Why this is important and how it is done, I will now explain a little bit more closely.
Why Loading on Demand?
There are many reasons why Loading on Demand is a good thing and all of them connect to the usability of the app. Basically, Augmented Reality applications often need a lot of data and that’s why Loading on Demand is a perfect Augmented Reality Helper.
App Store Limits
The first and major reason for Loading on Demand is that the Apple App Store as well as the Google Play Store have size limits which control whether an app can be downloaded via your mobile data connection. That would be 150MB in the App Store and 100 MB in the Play Store – any larger and you need WIFI to download them.
With our Loading on Demand system, most of the data doesn’t need to be inside the app but can be loaded later. So initially, you just download the lightweight version of the app, which meets the store limits and contains only the most important contents or models and you get the rest when you need it.
You can probably imagine (or know from experience) that users might not want to download an app that takes up too much storage, because it contains models they might not even need. For example, you want to buy a new table and would like to preview it in Augmented Reality directly in your living room at home. Imagine having every model the seller has in their catalog inside the app and thus on your smartphone. That would mean having to download the models for every bed, couch, lamp and whatever else. Not only would it take a long time, it would also mean a full hard drive. With Loading on Demand, the app comes without any models (or maybe just the top sellers) and gets the complete list with pictures of every model from the server. You can then look through this list and can download the model for the preferred table in order to view it in AR. You save time, storage and a lot of frustration.
As many of you will already know, when you release an app in the stores you have to wait a certain period of time before it becomes publicly available. This is due to the review process where Apple and Google check whether an app complies with their guidelines. In the case of the Apple App Store, this process can sometimes take two weeks or longer. If every model were contained inside the app, changing, deleting or adding a model would potentially also take a while.
Loading on Demand has a way around this. It works with a version management system which always checks for updates and if a change has occurred, it updates the models. Thus, the app doesn’t need to be re-released every time and can get all the new models from the server.
When does the user need the models?
This question must be re-evaluated for every individual app, of course. However, in our experience, there seem to be four main scenarios:
1. The app contains the models at the time of downloading
Sometimes it is more useful to put all or some of the models directly inside the app. The user can interact with the models from the beginning and has the full functionality of the app right away. If only a limited set comes with the app, it downloads the extra models in the background. Be aware of not putting too many models into the app because it might cause the problems described earlier.
2. The models are loaded at the start of the app and are stored on the hard drive
Sometimes it’s important to have some models already loaded at the start of the app. In our backend, there is a priority field which can be checked if a product is very important. At the start, the app checks for models on the server which are marked as priority and not downloaded yet and loads them. It could be done in the background while the user works with other functions or for example during the tutorial process. It’s also important to mark only the most important models as priority to reduce the storage use and waiting time.
Image 1: progress bars show models being loaded at the start of the app
3. Every model loads in the background
This system is only when there aren’t too many models, but when all of them are important for using the app correctly. It works best if used in connection with variety number one. You put one model in the app and the others are loaded in the background. The user can try the app and the rest of the content is prepared in the background. Using visual aids, the user knows which models are already available and which aren’t.
4. The user decides which model to load
This version is the simplest and most common. The user gets a list of available models and downloads every model that is of interest individually. Once downloaded, it can be used immediately. If the models are connected to different targets, the app can load the right model simply by using the target as a trigger. The download progress is visualized in Augmented Reality as a percentage value. Thus, only models relevant to each individual user are stored on the smartphone or tablet and any other models are available for download at any time.
Image 2: models are loaded individually, progress is shown in AR
Variations two to four can also be used for updating content. The user gets a notification for any new or changed model and can decide whether to download it or not. In our opinion, these are the best and most used systems for loading Augmented Reality content from a server. Of course, every app has its own particular requirements, which take some programming effort. Because of that we kept our system as open as possible, so we can react to every individual case.
And now, stay tuned – more AR helpers are on their way!