Offline Mobile App Architectures for iOS and Android Apps

No matter how good a developer you are, you would require something to support your app offline. On this page, you will get to know about the offline mobile application architectures with which you can develop robust apps that can tackle the offline capabilities in the best way.

Have you ever thought about why you have to design an app for the offline experience? Offline mobile app architecture is the most important thing that every developer should consider. Sometimes networks die and the networks are low and there are even more factors that will often need offline support. If your apps have users operating from different parts of the world then you need to account for the offline support or experience even more. Even if you are a good developer, in most cases you will require something to support your app offline. Everything depends upon what your app does; it might be simple or complicated sometimes.

If you have to know about offline architectures, it really takes more than 20 programming books to get you there. No matter whether you are a developer or a CEO or even a product manager, trying to understand how your app could behave offline is very important and will serve you more things in the future.

First of all, it is important to understand the three broad categories of offline apps.

• Data stored offline where there is no editing functionality. For this, you can consider the example of GPS data where the data is being stored offline temporarily.
• The users can edit their data offline and once they are back online they can sync their details. For this, a note-taking app will be a great example.
• The users can edit other data offline. For this, you can imagine edits to an offline Google doc type application.

In this, you could see some offline mobile architectures to develop robust apps, and with these how you can build an application that can tackle the offline capabilities.

Trello’s offline architecture story

Trello did not support the offline capabilities in 2016 and their users were complaining a lot about this issue. The users wanted to use this app when they were traveling in subways to their work and organize the things before reaching their destination. In the initial architecture that Trello was looking into, it always assumed that the app would have a network attached to it. Their users were suffering from network disruption and this app was helpless for the app users. So in such a situation, Trello decided to move to offline-first architecture.

In the newer app architecture, a local database plays a central role. After this up-gradation, the entire Trello app was able to run offline and it was very useful for many of its users. Trello went leaps beyond to make sure whether the app architecture can work smoothly both offline and online.

Application architecture without offline considerations

In this, you can see about the retrofit because a lot of developers use it as their data model. In architecture, the view model relies on the network or the server to work. If there is no network then nothing can happen in the mobile and for the end-user, it might seem like the app is stuck in between.

If there is no network in the place then the application’s user interface would suffer from the pending request and would behave in absence of internet connectivity.

To improve this condition it is highly advisable to place a model within the app. Most of the clients will come with apps that have no model in place. But it should not be the case when you create an app.

Here is a minimal improvement that can be done to improve the quality of the app. First, it is important to introduce a model. For example, you can consider the newsfeed app in which your user reads something interesting and wants to add a comment. You have to place a model with your app and see how you feel. Till the comment gets synchronized it will appear in a light color and when it gets fully synchronized it will turn into a dark color.

At some point in time, the developers noticed the shortcomings and started to introduce the local cache to their app. This was actually to work in the offline scenarios.

Here you can consider the same news feed app but also with a context to android. Usually, the developers handle the cache and this is done via the shared preferences or the SQLite database.

Dedicated cache service

In this, the cache is applied to the architecture with the dedicated cache service. Doing this the developers can include the HTTP requests locally.

Cache applied to the presenter:

In the modification, the cache is applied to the presenter.

With both of these, it seemed to work for the low complexity cases. If you are building an app that has a substantial user base then it may not be able to work properly. Also, you can frequently see some implementation errors.

Caching can reduce the number of web server requests your app is making.

App architecture with retrofit

If you are using something like a retrofit, you can just simply create a custom configuration for the HTTP client and you can define the cache size for the client. In the end, you can configure the interpreter to get the request from the cache if the server is not available.

Even if you have used a library like robospice on android you would think that you have covered enough for an offline experience but this is not sufficient.

The persistent offline architecture

While caching HTTP requests it might seem like a good solution. The issue with most of the HTTP requests is that you basically start with an empty model when you leave an app and come back. If your model is empty it can’t fetch anything that you have in your cache memory.

How do you fix this?

You have to change it to a persistent model. First start by persisting data on disk, by doing this the application can have the data if the user leaves the application. Also, use something called application logic with this you can make the network calls and keep the persistent model up to date.

Whenever the application logic does that it notifies and can be built on top of RX or on whatever you prefer. As soon as it fetches the information it shares it with the persistent model. This information can be then used by the entire application. Whatever component needs the information, the component can directly request the information from the persistent model.

Space for further optimizations

Now you have allowed a user to post the comment in the zero network conditions. But what you can do when your user wants to post three consecutive comments. With the architecture, the comments could appear at once and this is a sort of poor user experience. For all this, you have to look at the process flow and see how things are happening. You can implement these with the queues and separate them by the network and local queues. Now when the user adds comments in the comment section the app that you have created will not behave as it did with the previous cases.

The offline architectures are better suited for e-commerce apps, Real-time apps. News apps and map apps. The reasons are, it can bring faster data retrieval after sending the first request and can handle the connectivity better. Ahead of time, offline architectures are used for note-taking apps, email apps, weather apps, finance type apps, and messaging apps.

Offline — online sync: architectural considerations

If you are not sure about what offline considerations you have to keep in the mobile app, here are a few things that your offline architecture should support,

• How and where you are going to cache your data?
• How reliable is caching?
• How is the architecture going to handle concurrency?
• Is there any safeguard in your architecture to handle the data conflicts?
• How can this architecture handle the connectivity changes?

This blog can help you in many ways to know about offline architectures for mobile apps. But this is not sufficient if you are a developer. Make sure you get to about these before you develop an app.

Originally published at https://echoinnovateit.com on December 17, 2020.