Essential Guide to Making Your App Work Offline

With the rapid adoption of smartphones and tablets, most part of people has high-powered mobile devices within arm’s reach at all times. There are more mobile devices in the world than the total number of computers and television units combined. As the result, this opportunity radically changes the way how the majority of business owners delivers their services or products to clients: they consider mobile apps as a way to the significant improvement of their customer service. This means that if you don’t want to bow out your market position and give it up to newcomers, your business definitely needs a mobile presence to have an opportunity to support your audience when needed and be in a touch with end users 24/7.

Although, you need to remember: fluently working in online mode mobile app just isn’t enough. Undoubtedly, network technologies are growing every day but still there are cases when it is not feasible to have a stable Internet connection. And if entrepreneurs think this won’t harm their business they are wrong.

For example, let’s take a situation when therapist measured patient’s vital signs and needs to put all data into the mHealth app but during this action the connection was lost. When this happens it is not possible to store measured data without offline mode and, as the result, achieve the proper quality of home health care. In such cases, a lot of mobile apps benefit from working without Internet connection and for some sort of mobile apps it is even critical to work without the connection to the network as end users might need to perform some actions right away.

So, let’s go through the process and find out the true benefits of making app work offline besides modeling your business safer and besides succeeding with happy clients. Read on to get the lowdown.

How to Make an App Work Offline?

To understand how to build a mobile application with an offline mode which is resilient to different network scenarios it is useful to know the key technologies that allow to make application work offline. Mobile apps can be built with two core capabilities:

• Local storage/ database
• Data synchronization

Let’s take a closer look at all possible challenges that you can deal with during the offline mobile application development and explain deeper each capability:

Offline Data Storage and Access

While making your app work offline you will often need to store data directly on the client’s device. This allows your application to work effectively even when there is no connection. There are several different methods or levels of an offline data storage that make an app run offline. It can be different for different mobile platforms (iOS, Android, Windows phone and other) and we’ll go through each of them.

Local caching and cookies

When you use web technologies for building a mobile app it is possible to use browser application caching or cookies. Normally, when you visit a certain URL your browser makes a request to a server to return the appropriate page but when a server is an offline browser can fail to show you the requested page. Here, you will need a cache manifest which is just a simple list of essential files. Setting up an app cache manifest tells the browser how it can use pages that have been already downloaded rather than just immediately display an error when there is no longer a network connection.

Cache Manifest:

[text]styles.css
jquery-3.2.1.min.js
index.html[/text]

It should be served with a text/cache-manifest MIME-type and linked to in HTML pages with the following tag:

[text]html manifest=”offline.manifest”[/text]

When a browser loads the file it will ask whether you permit data to be cached on your device. Such approach allows web-based mobile applications to work even if the user loses internet connection. For example, peers will be able to read the news or email messages still they didn’t find a WI-FI hotspot.

Another approach that could be used to retain local web based app data (even when the browser is shut down) is to browser cookies. This is the most basic approach and is very limited due to the condition that cookies tend to store around 4KB of data. One of the disadvantages of this method is that cookies are resent to the server with each HTTP request which results in a waste of a lot of bandwidth to resend the all offline data even if you don’t need it.

What you need to remember is that cookies are vulnerable to being deleted if a user simply decides to clear them. So this approach is recommended for the simplest storage requirements only.

Shared Preferences

To develop an offline app for Android and iOS you will need a certain mechanism that allows storing user’s preferences which are pieces of information that you save persistently and use to configure your app. Often mobile apps expose preferences to users so they could customize the appearance and behavior of the app.

Android Platform

Android platform provides SharedPreferences APIs that can be used to save a relatively small collection of primitive data in key-values pairs. In simple words, a SharedPreferences object is a reference to the file that contains key-value pairs and APIs provide simple methods to read and write preferences. In this case, you have a key that can only be the string type, and the appropriate value for that key. In turn, the value can be one of the following types: boolean, float, int, long or string. Each of the SharedPreferences files is managed by the Android platform and is internally stored as .xml file in a private directory. An app can have multiple SharedPreferences files and, ideally, it is used to store application preferences.

Mentioned APIs provide two Context methods that can be used to get a SharedPreferences object. The first of those two is used when an app has a single preferences file and the second one – when your app has multiple preferences files, or if you want to give a custom name for the SharedPreferences instance.

Below is an example of how to work with SharedPreferences on Android:

[text]SharedPreferences sharedPreferences = getPreferences(MODE_PRIVATE);
SharedPreferences sharedPreferences = getSharedPreferences(fileNameString, MODE_PRIVATE);[/text]

Modifications of the preferences must go through the SharedPreferences.Editor object. In order to add/edit a value, use the Editor’s putXXX() method, where XXX is one of the appropriate type’s name. You can also remove a key-value preference pair by calling remove() method. Finally, the Editor’s commit() method should be called after putting or removing values, otherwise, your changes will not be persisted.

Here is an example of how to manage SharedPreferences on Android:

[text]SharedPreferences.Editor editor = sharedPreferences.edit();
editor.putString(keyString, valueString);
editor.commit();[/text]

iOS Platform

While developing an offline mode for an iOS app you can use NSUserDefaults class in order to save and update user’s preferences. The NSUserDefaults class provides a programmatic interface that permits an app to customize its behavior to match a user’s preferences. For example, you can give an opportunity for users to save a profile image offline or add a feature that saves documents automatically. These preferences are recorded by the application in what is known as the iOS “defaults system”.

In this way, information is cached which helps avoid the opening of the user’s defaults database each time you need a default value. And as the iOS defaults system is available within all of the code in your mobile application, any saved to the defaults system data will persist through app sessions. What this means for the user is that after he closes the app or reboots his phone he is still able to use the saved data next time he opens an app.

Local (Internal/External) Storage

There are lots of cases where you might want to store data but SharedPreferences method is too limiting for your needs such as storing images, serialized objects, .xml, json or other files. Then an Internal/External Data Storage method is a good way to go. Also, it is used specifically for those situations when you need to store data to the device filesystem that doesn’t require relational database capabilities. The next worthy point is that it allows very fast storage of data and is easy to use.

Additionally, all of the data that was stored using the Internal Storage method is thoroughly private to your application, and after your app is uninstalled the data is deleted from the device.

SQLite database

Finally, the majority of mobile platforms such as Android, iOS, and Windows Phone provide support for apps to use SQLite databases for data storage, although database managing is specific for each platform.

And here’s way it is such a big deal.

SQLite is an Open Source database system which works great on mobile devices as its storage offers an app the speed and power of a full featured relational database. To make the managing side simple  SQLite uses a single file to store all the data. Of course, it won’t solve too much on the sync- and conflict resolution site but it is an easy and simple to use alternative for queuing or caching information. So if you are going to store data that needs to be queried SQLite storage is an option to consider.

Here is a simple list of code that shows how to create a single table in Android platform:

[text]
public class SampleSQLiteDBHelper extends SQLiteOpenHelper {

private static final int DATABASE_VERSION = 2;
public static final String DATABASE_NAME = “sample_database”;
public static final String PERSON_TABLE_NAME = “person”;
public static final String PERSON_COLUMN_ID = “_id”;
public static final String PERSON_COLUMN_NAME = “name”;
public static final String PERSON_COLUMN_AGE = “age”;
public static final String PERSON_COLUMN_GENDER = “gender”;

public SampleSQLiteDBHelper(Context context) {
super(context, DATABASE_NAME, null, DATABASE_VERSION);
}

@Override
public void onCreate(SQLiteDatabase sqLiteDatabase) {
sqLiteDatabase.execSQL(“CREATE TABLE ” + PERSON_TABLE_NAME + ” (” +
PERSON_COLUMN_ID + ” INTEGER PRIMARY KEY AUTOINCREMENT, ” +
PERSON_COLUMN_NAME + ” TEXT, ” +
PERSON_COLUMN_AGE + ” INT UNSIGNED, ” +
PERSON_COLUMN_GENDER + ” TEXT” + “)”);
}

@Override
public void onUpgrade(SQLiteDatabase sqLiteDatabase, int i, int i1) {
sqLiteDatabase.execSQL(“DROP TABLE IF EXISTS ” + PERSON_TABLE_NAME);
onCreate(sqLiteDatabase);
}
}
[/text]

If you use the SQLite storage in the process of the mobile app development and data privacy is a vital need, the development of its environment requires a specific approach. One of the acceptable ways to do this will be the encryption using SQLCipher.

SQLCipher is an extension to SQLite that provides transparent 256-bit AES encryption of the database files. It makes the development of a secure mobile application easier and, as a result, it helps protect the data of end users better.

The main benefits of SQLCipher are that it is a very robust system for encrypting SQLite databases and it has versions for the mobile platforms listed above. Also, it is available in different editions depending on the level of security and support you need and provide both community (free) and commercial editions.

Synchronization

One of the core features of the offline application is that users are able to perform some actions in offline mode and then synchronize it with a central repository. In many cases, your app may have both client side storage and server side storage, and the app will manage the flow of data between server and client.

Data synchronization is the second of two core capabilities that mobile apps can be built with and it is the process of establishing consistency among data from a source to a target data storage and vice versa, and the continuous harmonization of the data over time. It is fundamental to a wide variety of applications, including mobile device synchronization.

Data syncing is a quite broad concept. It takes many forms and covers a range of different approaches with their up- and downsides. As the result, implementation of synchronization logic is not a trivial task and it severely depends on such factors as data model complexity, the amount of data transferred and stored, and other requirements. In each particular case, the choice should be in favor of the simplest implementation that meets the requirements.

Usually, by implementing the offline mode feature you encounter cases when your customers are able to edit information on the server-side and, at the same time, on the mobile side. This is the most complete and powerful of the scenarios.

Notice: while it might be tempting to build offline applications that support the two-way sync it is by far the most complicated approach of all. With this approach, your synchronization logic should ensure that after successful synchronization data will be up-to-date on mobile and server side at the same time.

This can be achieved by adding the certain “audit” fields to each object that should be synchronized between mobile and server, and vice versa. These fields can be like these: ‘last_updated_on’, ‘created_on’, and if the data isn’t physically removed: ‘deleted_on’. But be aware of physical removes since the rows deleted from server DB have to be removed in the mobile DB also. If data should be physically removed from the server DB your architecture should provide an approach to keep information about data that was removed. As an option, it can be a ‘deleted_record’ table with a following fields ‘table_name’, ‘deleted_on’, ‘server_record_id’.

Based on my experience, I would recommend to have a timestamp ‘last_updated_on’ column in every table that should be synchronized, and every time user inserts or updates the record your logic should update the appropriate ‘last_updated_on’ column. Then when mobile client request server for a synchronization, your logic will iterate all over the tables checking if the timestamp in ‘last_updated_on’ is newer than the date of the last synchronization. If it is newer than the logic will put it into the collection and send a response to the client.

In case, when the records are deleted physically you will have to read all the new rows of ‘deleted_record’ table and execute an extraction in the mobile DB.

In case, when data is edited on both sides you can not use DB’s ID as an identifier of the objects because there can be the same IDs for the newly created objects in the different mobile devices. To ensure the unicity on the different devices you should use some unique identifier. In our implementation, we call this field ‘synchronization_key’ and usually it contains UUID value.

It’s Time to Start

Let’s summarize all that has been said in this tutorial. We live in the ‘high-tech’ time where mobile users expect not just a good level of performance and user experience in their mobile applications but excellent. Today, offline support is a part of these expectations and can no longer be ignored. By implementing support of the majority of offline scenarios you will dramatically improve the mobile app user’s experience and boost your team’s productivity.

At Romexsoft, we have experience with such sort of mobile applications development so if you are looking for mobile developers in Ukraine to help you implement the offline mode within your app, let’s get in touch and build a bespoke solution together. We have solutions for you.

Written by Romexsoft on May 11, 2017
Author: Yura Bondarenko