Providing offline support for mobile apps

Offline support for mobile applications can be understood as the ability of the application to respond gracefully when the network connection is unstable. In the relatively new technical context of mobile devices, new problems have also arisen, such as normal or abnormal network connections, high latency, and low bandwidth. These problems have not been around for a long time, and engineers who have just started mobile development do not know much about them. In addition, creating a mobile application that can adapt to different network conditions may also include the following requirements:

• Display appropriate error messages if the network call fails.
• Allows use of the app in "guest mode", with certain features available only when the user is logged in.
• Clearly display network disconnection information on the UI (connected mode/offline mode).
• Disable certain controls when the network connection is lost.
• Allows users to query and operate data even without a network connection (offline data access).
• Test your app under different network connection conditions!

While all of these points are important from a usability perspective, one point in particular is more complex: offline data access. Your application may need to support a variety of different offline data access scenarios or levels, which I will explain below.

Local Cache

The application can still display information when there is no network connection, but the data needs to be refreshed when the network is connected. To achieve this, some degree of data persistence is required on the mobile device, and usually it needs to be retained for a period of time.

There are three different "strategies" for refreshing the data in the cache, and I will analyze them one by one below.

Network First

Always try to get data from the server, and if it cannot be obtained from the server, then turn to get data from the local cache. If you particularly want to always display the latest and updated information, then this strategy is very helpful to you.

Local First

In a specified period of time, data will not be retrieved from the network at all, but obtained from the local cache. If your application can accept displaying cached data without any risk, then this method is suitable for you. On the other hand, this method provides a better user experience because there is usually no delay.

Hybrid/Intelligent

This method returns the result from the local cache before getting the data from the server. You can choose to wait for notification from the server or poll the service in the background to refresh the local cache data. This mechanism can achieve a good balance between performance and user experience, while it still refreshes the local cache regularly, avoiding the risk of showing "expired" data to users.

In addition, the inadequacy of local cache can be effectively compensated by the support of some kind of server-side cache. Just like HTTP cache, when the client needs to obtain data from the server, it can send a "revision number" to confirm whether the data has been updated. The server will check whether the revision number sent by the client is consistent with the data on the server. Depending on the result, it will either notify the client that the data does not need to be updated, or return the latest data.

Example scenario

The improvements in performance and user experience make local caching very practical in many scenarios, and the key condition for this practicality is that the data does not need to be displayed in real time. The longer the data can be retained in the local cache, the more prominent the advantage of this method.

Examples of this include areas or contacts that the user is interested in, which are highly useful information that is not updated very frequently, making them ideal for local caching.

Local Queue

Once the application loses network connectivity, server requests can be queued locally for later processing. This allows users to initiate fire and forget operations and receive notification of completion once they are successfully processed by the server (if they are indeed processed).

When processing multiple operations on a local queue, you need to consider the following issues:

• The user should be notified that the operation has been queued.
• Users are likely to want to know the actual status of the queue, which operations have been completed and which operations are still waiting?
• For operations that are still in the queue, the ability to manually undo or retry them may be very important.
• Once these operations are sent to the server, the user wants to know the final processing result (success or failure).
• After an operation enters the queue, the user may need to restart the entire process, thus interrupting the operation.

Local queues are a good idea when consumers are doing field work such as auditing or measuring, and sending reports. If these operations do not require updating records, but just inserting new records, the entire implementation becomes much simpler, without the need for concurrency management or conflict handling.

Example scenario

Local queues can help you perform operations without waiting for their results, which is very important for operations such as inventory checks or audits, allowing users to use the application or send reports without waiting for a network connection.

Data Synchronization

By using local caches and queues, you can keep the device and server data updated, which is what we know as "synchronization". There are several ways to achieve data synchronization.

Keep mobile data updated

In this scenario, you need to keep your mobile app data in sync. There are two ways to achieve this: use a local cache as described above, or request the latest changes from the server. These latest changes are also called "deltas" and allow the mobile app to rebuild the current state of the server. In order to be able to query for the latest updates, you need to use some audit fields, such as 'UpdatedOn', 'CreatedOn' and 'DeletedOn'.

In the second scenario, the data is not modified on the device, so there is no need to deal with any conflicts, so the data on the server is always correct.

Keep server data updated

This can be achieved by using a local queue, but queues alone are not enough. What if the state of the data on the server has changed since I tried to modify it when my request is sent? If the execution of the request is delayed, for example, if the network connection is disconnected, it is possible that concurrency conflicts will increase. In this case, the developer (or user) must decide how to "merge" the changes in the server and the application. For each data conflict, there are several ways to merge:

• Keep the version on the device
• Keep the version on the server
• Keep both versions

The operation of merging records is often automated by mobile developers. The specific algorithm used is determined by the business rules of the application. If a situation cannot be fully automated, the user will be prompted to make a decision.

Keep the data updated on both the mobile terminal and the server

This approach is also known as two-way synchronization. As you may have guessed, this strategy is a combination of the two techniques above. It is the most complete and largest of the scenarios described so far. But please note that although it is tempting to create an application that supports two-way synchronization, it is also by far the most complex scenario. And the problem is not only its complexity. As I have already mentioned in this article, two-way synchronization is not always necessary.

Example scenario

Two-way synchronization brings a whole new level of user experience to mobile applications, and one of the key conditions for using two-way synchronization is to allow all users in a team or group to be able to keep up to date with the activities of others. An example of this is a collaborative application that needs to show the latest status of updates, comments, or status changes. Imagine if there is a collaborative address book, then every member of the team can update the contact information in it at any time.

think

Adding offline support to the mobile app you create can greatly improve the user experience, but choosing the right level of support and then implementing it is not a simple task. Below I have listed some issues you should consider when planning to add offline capabilities to your app.

Data size

When caching data locally, be cautious about the size of the data you store. It is important to try to strike a good balance between the amount of data you cache and the improvement in the user experience you get. If the amount of data is very large (such as saving the contents of a complete Sharepoint site), you may have to consider providing the user with an option to choose which data to cache for offline reading.

Data storage

Be sure to make smart decisions about how and where you store your data. Does the data contain sensitive information? If so, encrypt it when you save it. Once you choose to encrypt the data, make sure you store the key used to decrypt the data in a safe place, and consider using the operating system's features to achieve this. Also note that your application code can be read (or reflected) on some platforms, so consider obfuscating the code. ***, but not insignificant, make sure you have some mechanism to remotely wipe the data on the device. Tools like mobile device management (MDM) platforms can help you achieve this function, but it can also be done by the application itself.

Battery Use

If you plan to use polling or background jobs, make sure you carefully consider battery usage. Certain operations and network functions can drain your battery quickly and hurt your user experience. You can check the battery status before starting a power-intensive operation, whether the device is charging, etc.

Application of data

You may need to query and manipulate data (add, modify, delete), depending on the needs of your application. In scenarios with a certain degree of complexity, using a database as a persistence mechanism is a good choice. To choose a suitable database, you need to consider the following issues:

• Platform support: Can I use this database on every version of my app? (iOS, Android, Web, hybrid, etc…)
• Choosing relational or NoSQL database technology
• With ORM support, the object model is easily mapped to the database
• Data size
• Support for synchronous protocols (such as CouchDB)

Below we will analyze some libraries and databases one by one, which are very useful for us to implement offline functions.

Using libraries and databases

SQLite

SQLite is an open source relational database that is very suitable for use on mobile devices. It uses a single file to save data, so it is very simple to manage persistence. It does not play a big role in synchronization and conflict resolution, but it is an easy-to-use choice for caching and queuing information. It supports major mobile platforms such as iOS, Android, Xamarin and Windows Phone.

SQLCypher

As mentioned above, if the data you cache or queue is very sensitive, you need to encrypt it while saving it. SQLCypher is a very robust option for encrypting SQLite databases. It supports every major mobile platform, but this library needs to be paid. It has multiple versions available depending on the security level and supported features.

Couchbase Mobile

Couchbase, originally named Membase, is an open source distributed NoSQL database. It is particularly suitable for offline application scenarios because it can synchronize data bidirectionally through Couchbase Mobile and an additional synchronization gateway. It supports mainstream mobile platforms, including Xamarin and PhoneGap, and provides local file encryption.

Meteor

Meteor is an open source platform for creating web applications with built-in real-time update capabilities. Meteor is built on the open source Node.js platform and MongoDB, and provides a publish-subscribe mechanism that can deliver data changes to each connected client in real time.

It supports all mobile platforms through hybrid tools like PhoneGap and Cordova.

Conclusion

Once users begin to expect their personal apps to achieve the same level of user experience as enterprise-level apps, offline support cannot be ignored. Being able to provide users with good support for offline scenarios will greatly improve the user experience of mobile apps and is also crucial for employee productivity.

Be aware of the security issues when storing data locally on the device, and try not to underestimate the impact your app may have on the user's battery life.