Offline enabled web applications became a wide discussed theme in many conferences in 2012. Paul Kinlan conducted an experiment with offline apps: top 50(ish) apps on iOS and Android, downloaded app, pulled the plug, loaded app; and the same experiment with offline apps. But most of the apps gave the next result: ‘Unable connect to the Internet’. It’s not surprising that native apps won hands down. Lots worked brilliantly offline without online requirement. Many of them load and offer UI with cached content but needed web for more information. And only minority of apps failed to load. And there are some tips from Paul:

• You have to use App Cache if you want to have any offline experience at all;
• You have to use both indexedDB and WebSQL if you want to have any offline storage at all;
• Eco-systems needs to be built around API’s;
• Apps should be able access to native API’s;
• Apps should be secured by default CSP FTW;
• Apps should be built with use of well-known technology (HTML, CSS, JavaScript).

Offline is very important crucial feature and we should take into account this aspect from the start of our work with application rather than waiting to add it later during development process. For instance, FormAgent mobile clients were designed to let user continue operation without network and sync up data when network is available.

Let’s consider the basic principles you should be guided when you engine an app in order to adapt it for operating in offline mode:

1. Decouple your app from the server at the limit

Usually the server played a majority role when creating the content for the web. Data is stored in database with an access to it via PHP or Ruby, and then data is maintained and rendered to HTML with templates. Most of the modern frameworks use MVC architecture to separate these tasks, but still all the heavy lifting is done by serve. Storing, manipulating and rendering of the content require connection with the server. Offline first approach is about moving the MVC stack to the client side. There is only JSON API stays on the server side for database access. Thus, server components are lightweight and are really easy to write unit tests for.

Tips:

• make sure that client app is able to operate without server side and providing minimum viable experience,
• use JSON.

2. Create an API wrapper object in the client side code

Don’t fill your application code with Ajax calls or callbacks. Build an object which mirrors the end point API’s functionality for better code separation in the application, debugging, using of the mock data. You are also enabled to write unit tests. This object can use AJAX internally.

Tips:

• abstracting the JSON API into separate object,
• don’t clutter up the code of the app with AJAX calls.

3. Decouple data updates from data storage

Try not just to request data directly from the API object for rendering the templates. It is rather to create data object that will be as a proxy between API object and the rest of the app. This object will be responsible for the data updates’ requests and processing the responses, synchronizing data which had being changed when no connection had been available.

Tips:

• use separate object for data storing and synchronizing,
• all operation with the data should be via this proxy object.

Author’s BIO: Sergii Brook is a SEO Manager and small writer at QArea. Qarea is Outsourcing Software Development Company which also provides Mobile Development Services .