Offline can make or break your business.

No connection, no problem.

The idea that we are living in a permanently connected world, where mobile users always have network access, isn’t always true. Think of field service workers, for example, for whom internet connection is often restricted or unavailable. Poor unfortunate souls.

Developing for offline users becomes a powerful differentiator in today’s world. And it can be painful. The good news is it doesn’t have to be.

The best way to do it is the offline-first approach. Design and develop your app to work without a network connection, just like in the 90s!

For your 90s-style app to operate, you are going to need data. The best place to store it is (of course) a database, but it should be a local database that runs in the mobile device. For instance, in a field service app, this database would store tasks for workers. But data does not live just in the device, it’s in the back-end as well. So you need to synchronize data back and forth between the two. This just isn’t easy, and neither are other parts of the process.

Compounding this challenge is that your app will run in more than one kind of device, each of which has a local databases. The upshot of that? You will have databases all over the place.

None of this database situation is easy, and neither are other parts of the process. So, let’s look at what you can do.

Plan How You’ll Go Off the Grid

Knowing what you want to make available to your users offline will save you development time. So, you need to define your use cases early. When planning your offline scenarios, ask yourself:

What features and capabilities should be available? Do users only need to browse data offline? Or can they also push local changes back to the server? Is there multimedia they need to view offline, such as videos that show how to do a complicated task?

Do users only need to browse data offline? Or can they also push local changes back to the server? Is there multimedia they need to view offline, such as videos that show how to do a complicated task? ​ What data will you store locally? Ideally, you should only store a subset of your database in your device. Local databases are lightweight. And, device storage capability has its limits. Also, hand-held devices have limited computing power and battery capacity, so you need to have this in mind as you work through your use cases.

Ideally, you should only store a subset of your database in your device. Local databases are lightweight. And, device storage capability has its limits. Also, hand-held devices have limited computing power and battery capacity, so you need to have this in mind as you work through your use cases. What conditions will trigger synchronization? Is there any critical information you want sent to the remote database as soon as a connection is available? Is data synchronized only when the user requires it? Or, can users wait to synchronize all data later? Will synchronization be triggered by certain events, such as on user login or when the network is restored?

Is there any critical information you want sent to the remote database as soon as a connection is available? Is data synchronized only when the user requires it? Or, can users wait to synchronize all data later? Will synchronization be triggered by certain events, such as on user login or when the network is restored? When do you need a connection to the server? And for what functionality?

After those questions are answered, you’re part of the way there. Time to tackle the challenges.

Offline Challenges

Okay, you’ve asked the right questions and developed your use cases. Are you all set to go? Probably not. There are technical hurdles to overcome when developing offline apps.

Application Assets

The application must include all the resources required to run standalone from the server without any connectivity. You can use techniques such as hydration, which caches the application’s assets on the device the first time the user starts the app. Then, the next time the application is running online, there’s an automatic update.

Local Database

Data on the device is stored in a local database. Picking the right technology is easy: SQLite can run together with your native app or with your hybrid app using this PhoneGap plugin. If you have sensitive information, SQLCipher enables you to secure your data with a 256-bit AES encryption.

The physical size of the device storage limits what can reside there, so it should only be the necessary data. To address limited space on data stored locally, you need to define the information you want to store on the device. This means having control over which data should be stored offline without losing speed and flexibility.

A mobile database with you at all times.

Offline Synchronization

This is the hardest part. You have to carefully analyze the use cases for your application and know what applies best for each. Are your mobile users going to read data only? Do they modify existing data? A few common patterns can ease the pain.

Read-only Data

This pattern is for when your users only need to read data while the app is offline. It’s simple, too. You just have to download all data from your back-end and update it in the local database. If you have large amounts of data to synchronize, be sure to analyze the data in the device first, and only update what’s new or what’s changed.

Read/Write Data Last Write Wins

When it’s likely that only one user will change data while the app is offline, this is the path to follow. Once you have all the data in the local database (using the read-only data pattern), local changes are tracked to be synchronized later to the database. If more than one user changes the same data, the last change to be synchronized wins. As you can understand, this can lead to data loss, so the next pattern might be a better bet.

Read/Write Data With Conflict Detection

If you have a scenario where more than one user will change the same data while the app is offline, conflict detection and resolution techniques are necessary. This involves tracking changes and detecting conflicting changes upon synchronization. This process is highly dependent on the data and use cases of your application.

Summing Up This Offline Thing

So what does all this look like? Here’s a diagram that outlines the runtime architecture of a typical application with offline support:

Breaking down offline.

An additional note: On the back-end, typically there are REST APIs that need to accept only authenticated calls from the devices. These are secure APIs that ensure only authenticated users can start the synchronization process, and all connections run over SSL so data remains secure.

Let’s Take This Offline

Offline can look like a daunting challenge, but there are solutions that address it. OutSystems, for example, is a great platform for offline apps. However, no matter how you choose to build your offline app, you can make users happy. It’s about choosing the right use cases and data synchronization mechanism and keeping device limitations firmly in mind.

Want to know more about how to handle offline and synchronization patterns? Have a look at this webinar.