The problem of data caching is especially challenging when it comes to travelling apps. Most of them contain area descriptions, artistic maps of local area, google maps, top interesting places of this area, top area’s activities, services on this area, contact information, media galleries, similar places, serving times, goods/exhibitions catalogues etc.
While walking, driving or cycling somewhere, the app user may discover that there is no Internet connection. And at this particular moment s/he wants to take a look what is around them. All the data listed above should be always accessible, so the user doesn’t feel any form of inconvenience while working with the app. Because the primary purpose of such apps is to provide a user with the requested information under all conditions.
What is important for travelling apps and is tied to data availability (depends on caching)?
- power consumption - user might not be able to charge his device often
- not to be dependent on Internet connectivity
- use Internet channels effectively (distinguish download strategy for 3G and WiFi)
- all required data should always be available
- user experience of the application should not be Internet access dependent
- navigation within the application should not be blocked
- all views should be accessible even with initial dataset or some default data.
If you are looking to meet all the requirements, you may end up with a very expensive solution. That may, in turn, introduce a lot of budget-related limitations and affect the final app design idea.
It is not always possible to meet all the requirements, but there is a number of options that Lemberg can suggest to ensure the final solution is as sleek as possible.
The choice of the best option for each particular case should take into account all requirements and limitations.
- power consumption. In some cases a user may not have a possibility to recharge the battery quickly, but for others it is not an issue at all. Stable internet connectivity to access data will increase power consumption.
- available internet channel. User may have no Internet access, s/he can have 3G or WiFi, or EDGE. For this limitation a strategy should be discussed how the app should behave and what it should load.
- amount of data that should be cached. When online, the app should think about its future usage and perform data caching in background. What data will be cached should be agreed on during development.
Let’s take a look at our caching options table.
Cache all data
This is the simplest case from implementation point, but not the best one for the huge data set cases. It can introduce delay to data update process, not to mention it’s also battery consuming (especially if the data size is enormous).
Cache only data recommended by the Server
The CMS can provide the mobile application with a list of content that should be cached.
The mobile app will have to call respective API method that tells it about cache candidates and afterwards syncs the selected data. This is the best scenario for cases when “Only Featured content is cached by the application”.
Cache only text data
The mobile application should cache only text data.
Images, videos, audios can be loaded only when the application is online. For images, the application can use some default image, so UX is better.
Cache only Favorites data
It doesn’t require extra API call support on server side as with the above case.
The mobile app user marks content item as Favorite , thus placing it into the sync queue.
Cache only selected data (not related to favorites)
This looks similar to the above case and can be implemented by means of it, but often a User needs to have cached some items that are not their Favorites. For example, if you visit a place, you must have a route that should always be available on your device, but all these locations are not your Favorites.
Cache the Recently visited content items
Similarly to the Favorites solution, but related more to caching your browsing history. The number of items can be limited to 5 or 10 latest, depending on the size or other properties.
Cache all data related to the selected
This option is more of an extension to all of the above. Every content item may be related to other content items.
Try not to cache data that expires quickly. Some samples of this data are provided below. For these cases it is always better to provide the last update date.
Forecast for 5 days will definitely expire in 5 days.
Calendar can expire since the last available date.
News may also expire, depending on what they are about.
Live camera shots
Expire immediately, but can be cached for future reuse as a media gallery.
Expire on the last day of the promotion.
Status of entrances, lifts, parkings etc.
Expire within a short period of time.
As a summary for caching approach: there is a number of caching options to choose from, but the final solution depends on your practical limitations. Items to keep in mind while designing data cache:
- Identify limitations
- Identify what objects to cache
- Identify cache frequency - how often app should launch cache process (for cases of every 30 minutes, every hour or every day)?
- Identify cache triggers - what are events that should launch cache process?
- Identify sync rules - what and how to add, update, remove?
- Identify caching channel (WiFi, 3G, EDGE etc)
Lemberg is always here to help customer in selecting the best solution for particular case, as well as in any other ones, so don`t hesitate to contact us or add your questions in the comment section below.
Learn about Lemberg`s experience in developing apps for latest gadgets.