A Guide To Offline App Architecture

According to a recent study, over $1.7 billion in currency is lost yearly due to poor internet connection. Losing such a huge amount of money to the inefficiency of mobile apps is not worthwhile. Also, the cost of the internet worldwide is an issue when considering the online-first architecture.

So, what’s the solution here?

As mentioned in the previous blog, offline-first mobile apps have an edge over mobile-first mobile apps when it comes to great user experience.

We have pretty much discussed the basics of offline-first mobile apps, their introduction, the need & the benefits in the previous blog. Moving forward we would be looking at various approaches to the target offline-first mobile apps, and some tips to keep in mind while moving to offline-first mobile app development.

Moving from an online-first approach to offline

– Single source of truth

In mobile-first apps, the single source of truth is the remote server to which we are uploading, downloading, and then reloading the consumer data. So, to switch to an offline-first approach we need to have access to a local database. And due to the variety of implementations available, the work has been drastically reduced. You can easily choose from various implementations such as Realm, Room, or SharkORM.

Unlike the online first approach, this database would only be the place where we can push or pull our user data. Even with poor internet connectivity, due to offline available databases, we can reduce the time a user waits to download or upload the data.

– Data Fetching

While using offline mobile apps, the operation relies majorly on the database. In this kind of mobile apps, we usually don’t have loading indicators and no content to load. Handling and fetching of the data are done from a single database. After a response from the server, we just push the received data to our existing database from which the app pulls the data. This technique provides a positive app behavior, as the user only sees the loading indicator once. We can also enhance the user experience by concealing the download process using a splash screen.

1. Loading data according to user’s behavior: 

The application may track the way a user interacts with the mobile app and use the analyzes to predict future behavior. Advanced technologies such as AI handle the offline-first architecture better. Using this architecture for mobile apps such as navigation apps, video/music player apps enhances the user experience.

2. Downloading larger files over wireless data: 

In offline-first architecture, the application should try to avoid downloading huge files using the cellular network. It is better to load the large files while being connected to Wi-Fi and cache them for future use.

– Data Syncing

In the upper portion we have covered the data fetching and data downloading in the offline-first mobile apps, but what about uploading the data? When a user modifies or adds new content to the database, our traditional technique is to upload the data in the remote server which requires an active data connection.

With offline-first mobile apps, we save our recently edited data with a flag and mark it as ‘pending’ on the server. A periodical sync process is implemented to try and upload the data when the internet is available. This reduces the data loss and also saves the time & resources of the user.

Here are two techniques for database synchronization-

1. Using existing databases

Using synchronized databases allows you to use some existing solutions that synchronize with the local database with a remote database such as NoSQL databases or SQL databases. This is the best solution if one is starting with a new project from scratch because migrating from one database to another is a tedious task.

2. Self-developed synchronization procedure

A self-made synchronization procedure is an option when existing databases are out of option for you, and then you end up designing your synchronization procedure. While designing a self-made synchronization procedure make sure to initiate a procedure that is periodic, event-based & fixed-time.

– Caching

Many times users go back to recently visited data and caching data from multiple levels becomes difficult if the database is inaccessible. With offline-first mobile apps, the most recent data is available right from the memory cache, and you can also cache some additional data with the help of a disk-based cache too.

Bringing everything together

Combining everything-single source of truth, data fetching, syncing, and caching provides us a great user experience. With no loading indicators, empty views, and errors, users can enjoy a similar experience for online and offline-first apps. Network bandwidth can be saved because the data is only downloaded once and the user can move through the app without any interruptions.

Implementation varies according to the app’s requirements. To further deal with the process, here are a few parameters that you need to keep an eye on:

• The frequency of data fetching, and the requirement of most recent data.
• The size of the app-this would decide how much data you need to download and cache the backend.
• The need for uploading the user content, and handling the data that is edited by multiple users.

Things to keep in mind while designing an offline-first app

The above-mentioned guidelines keep in place a layout for shifting from online-first mobile app architecture to offline-first architecture. Moving forward, some guidelines apply specifically to offline-first apps. Have a look at what these guidelines are:

• Conflicting Data

This conflict arises when the changes applied to the online database are edited by the user when operating the app offline. In this scenario, when the server would try to upload the information, it would face two conflicting pieces of data that would result in unpredictable system behavior.

While handling this situation is relatively easy, various other things had to be taken care of. To overcome this app design conflict, you need to build your mobile app in a way that can handle such conflicts hassle-free. Marking the data priority in the situation discussed would help the app handle data effectively.

• Offline features

Making an offline-first application requires your mobile app to operate in two different modes-i.e. online and offline. The online mode is traditional and is easier to develop while designing the offline mobile app architecture is relatively tricky.

The main part of designing an offline-first architecture is designing an app whose features would be still accessible when it is not connected to the internet. Deciding on the features would be the sole responsibility of the technical team of the project.

Tools and frameworks for developing first apps

By now, we hope that you would have gained a great insight into the offline-first architecture and the guidelines you need to follow to develop the offline mobile application which provides a great user experience.

Moving forward, these are a few tools and frameworks that would help you to develop a great offline-first app:

1. JobScheduler

This is an offline-first framework that has system service available for API level 21+ allowing the users to synchronize tasks with a description of the expected device state that includes parameters such as battery level, internet connection, retry/back-off strategy, and much more.

JobScheduler framework can be considered for both custom database synchronization and notification-triggered downloading. In case this feature is required for API below level 21, Firebase JobDispatcher or Android-job from Evernote can be used.

2. Sync Adapters

This is a system API that is designed specifically for the data synchronization that is managed by a content provider framework that uses android accounts and an authentication framework to perform. Due to the above-mentioned feature implementation is much more complicated than using JobScheduler and requires some boilerplate to work. Because of this complication, you should avoid using this mechanism unless you synchronize data that are provided by some content provider.

3. Connectivity Manager

Connectivity Manager is a system service that is used for monitoring the state of internet connection. Your repositories implementation may direct the queries to the backend calls when the connection is stable and then switch to the disc cache when the network is down.

4. Data Saver

This API was introduced in API level 24 that allows the user to control application data transfer usage. Your mobile application should consider this extension to ConnectivityManager and adjust the transfer usage.

5. Firebase Cloud Messaging

This is a part of Google play services that are required for an application to receive notification from Google cloud. Through this service, you can search for other message services as well.

6. NYTimes Store

NYTimes’ Store is a library that helps you to manage to download and cache the data.

7. SQLite-sync

The solution provided by SQLite-sync simplifies the working of the sync-ready backend and works with several SQL databases. This solution also provides a database that helps in web application translation changes to an XML format that is returned from multiple services. The client application then returns the XML that can be interpreted to fulfill the requested operation in a local database.

Final Words

Offline-first mobile apps are designed to provide a better user experience and app success in the long run. Implementing this approach can help users enjoy all the app functionality even without an internet connection. Designing an offline-first app for android or iOS would be more complicated than creating an application only with functions that require connection to the server, but all the hardwork is worth the wait.

If you are also looking for hire mobile app developers that can guide you on your offline-first app development journey, we are more than happy to help you!