Handling Offline Capability And Data Sync In Native Mobile Apps
Native mobile applications in enterprises
Mobile applications are the front-facing entities for most businesses. B2C and B2B startups alike rely heavily on apps to communicate with their intended audiences. In the world of enterprise applications, however, mobile apps are used only as extensions of their web counterparts. We, however, are of the opinion that these enterprises really need a no-nonsense, lightweight app that exposes access to the data residing in the cloud server. And these apps, unlike their web counterparts, need to work both offline and online.
Why, you ask? Consider a home-healthcare worker traveling to remote locations to service his patients. He will have to deal with discontinuity in his mobile internet connection. However, his work entails taking notes against the patient’s records, possibly getting the patient’s signature and reporting to the back-office at the end of the day. He needs smooth synchronization of his updates with the server with minimal supervision. This goes for any field worker.
So, how do you build an app with offline sync capabilities?
There are several commercial services and frameworks that handle offline data sync. However, sometimes all you need is a simple mechanism with no frills and no major impact on your existing setup. This is especially true for enterprises, with massive existing infrastructure that can only be supplemented, not replaced. Designing your own synchronization model is the best bet in these cases.
We had to build this sort of a “sometimes-connected” Android mobile app recently, and we’re going to share our experiences. The main design goal was to build an app that could be used offline a majority of the time. After due analysis, we finalized on the following as our guiding principles for the app:
- The app should store and maintain a relevant local copy of the data and model.
- There should be a bi-directional data synchronization setup between potentially multiple apps and the cloud server.
- There should be a firm mechanism in place to handle data conflicts resulting from multiple updates.
Here’s how the workflow for our build was.
Step 1 – Initial Data Sync
When the app executes for the first time, it checks for any relevant data in the server database, downloads the data and stores it in the local database.
Step 2 – Synchronizing Local Data to the Server
For the optimized performance, the app always interacts with its local database for the Create, Read, Update and Delete operation (CRUD).
- After the initial data sync (for a given user) , whenever the user performs a CRUD operation, the changes are updated in the local database and a server sync flag is set there.
- The app then checks for network availability.
- If connections (Mobile data/Wi-Fi) are available, the app syncs the local data to the server database using REST APIs. If this succeeds, the app updates the server sync flag in the local database.
- If networks are unavailable or the sync fails for some reason, the app attempts the process again with a background sync service.
- These steps are repeated at regular intervals.
Step 3 – Synchronizing Server Data to the Local Database
Similar to the local data update, when there is an update to the record in the server, the same is to be pushed to all local copies.
- The server notifies the client (using FCM/ APNS)
- The app then triggers the background sync service.
- The sync service fetches the updated data and resolves conflicts if any.
- The local data is then updated to the server values.
Step 4 – Conflict Management
We chose to handle conflicts locally using timestamps. When data updates happen, a timestamp is noted and the sync service ensures the latest data is updated everywhere.
- After the changes are downloaded from the server, any conflict with local data is resolved based on the timestamp of the data.
- When local changes are sent to the server, the sync flag is updated along with the timestamp.
However, there is no single right way to manage conflicts. It depends entirely on the app’s requirements. We found that this worked well for us. It is also important to analyze the various factors that can influence the app’s performance, when a lot of data synchronization is involved.
Step 5 – Resumed Internet Connectivity
When the user goes offline for a while, and then connects to the internet, the app receives a callback from the OS and the sync service is triggered at this point.
Have a project for us? Want to learn more about how we work?
Give us your email address and we’ll get back to you!