Omni-Channel Marketing: Unifying Your Sales and Marketing Efforts
20 December 2024
Contact Info
- Lilongwe, Malawi
- +265 899 25 21 95 (Whatsapp)
- contact@webmobyle.com
- Working Days: Monday - Friday
People First Building Your Custom Solutions | Request Quote
- Work Days: Monday - Friday
- +265 899 25 21 95
Making An App Available Offline
Making An App Available Offline
Download Audio: Making An App Available Offline
Internet connectivity can sometimes be taken for granted when developing an app. Whether it be a web app or a mobile app, this is a factor that should be given serious consideration. You have to ask yourself whether it is important that users have access to the app even if there is no Internet connectivity.
Deciding to make an app available offline is a big deal. First off, I am talking of apps that in some way or other, communicate with a remote server for some, or all of their operations. Therefore apps that simply do something locally on the user’s device do not apply.
One of the most important questions to consider when implementing an app that is also available offline, is to inquire about how much of the app’s operations involve other users. The simple reason for this being that, if a user has to wait for data from other users in order to effectively use the app, then it should not be made available offline.
For example, making a social networking app available offline is for the most part impractical, since real-time and chronological reactions are important for social interactions. On the other hand, if you take an exercise and fitness tracking app: this type of app is mostly dependent on the activities of the user. It works seamlessly offline and just needs to access a remote server to store and synchronise data, and can work really well offline.
Making an app available offline involves two primary functions. The first is the ability to store data locally on the device being used, and the second is to be able to synchronise the data with a remote server.
Storing Data Locally
The remote server is the primary store of data, and an app downloads this data to use it in its operations. This is why you typically need an active Internet connection to use most apps, so that your app can exchange data with the remote server.
Depending on whether your app is a web app or a mobile app, the mechanisms for storing data are different. Web apps, with the aid of programs called service workers, will store pages in a cache. What happens in this case is that, pages are stored locally in the browser cache.
When a web app is offline, the browser will revert to the page cache, to retrieve a copy of the stored pages. Browser caching is a passive activity, and the browser only serves previously cached pages whilst a web app is offline.
Browser caching can be used in conjunction with a feature called Local Storage within the browser, which is a key-value-pair storage system used in web apps and websites, in order to store data which can be retrieved later. Unlike the cache, Local Storage is active storage that can be accessed and altered.
In mobile apps, there are two storage options available on both Android and iOS: the first being Shared Preferences. Shared Preferences is a simple key-value-pair storage similar to Local Storage in a browser for Web Apps.
The second storage option is to use SQLite. SQLite is a relational database, which means it can be used to form complex relationships between data stored in rows and colums, and allows for querying of that data using Structure Query Language (SQL): a very common language for querying databases.
Syncing Data To Remote Server
Since browser caching is a passive activity, there is no new data that is stored on the device to sync data to the server for web apps, when using this method. However, an implementation can be done to sync Local Storage to the remote server in web apps.
On mobile devices, however, the most effective way to store data for syncing with a remote server is through using SQLite. The way to do this is to keep track of timestamps. All data rows in the database should be stored with a time column.
When it comes to syncing data, the app should check each row’s timestamp, to see if a record needs changing. If a timestamp is found to be newer on the device storage compared to the server, it means that the device made a change to the value which needs to be updated on the server.
If on the other hand a timestamp is newer on the server, it means that another device made a change to the value, and the value needs to be updated on the device. This way, the user’s data are always synchronised.
It should be noted that update operations can become so many during synchronisation, that they take a toll on app and server performance. The syncing algorithm should therefore be optimised to only synchronise at certain intervals, and also optionally synchronise some data more frequently than others, depending on app design.
Want to hear some more from the Webmobyle Blog? Please
Leave A Comment