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:
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).
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.
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.
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.
[contactform topcontent=”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!” bottomcontent=”Want to learn more about our mobile offerings?” linktext=”Click Here” link=”https://www.ideas2it.com/mobile-healthcare”][/contactform]