If you have to know about offline architectures for iOS and Android apps, 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 is 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 did not support the offline capabilities in 2016 and its 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 organizing 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 for iOS and Android apps, 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.
In this, you can see about the retrofit because a lot of developers use it as their data model. In architecture for iOS and Android apps, the view model relies on the network or the server to work. If there is no network then nothing can happen on 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.
In this, the cache is applied to the architecture with the dedicated cache service. By doing this the developers can include the HTTP requests locally.
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.
A Progressive Web App (PWA) is a web app that tries to replicate the behavior of a native app. They’re designed for quick loads, push alerts, and use while offline or with poor network access. PWAs are similar to native applications in that they may be installed on a user’s device. However, they are developed using standard web technologies like HTML, CSS, and JavaScript.
As a result, consumers no longer need to download an app from an app store. Also, PWAs are more accessible and more straightforward to produce than native applications. PWAs provide the conveniences of a native app while still being accessible through a web browser. To close the gap between native applications and the web, PWA strives to provide a unified and consistent user experience. With PWAs, business owners can avoid the battle of choosing between a native app vs hybrid app.
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.
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.
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.
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, the offline architectures are used for note-taking apps, email apps, weather apps, finance-type apps, and messaging apps.
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?
- To what extent is caching reliable?
- 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 for iOS and Android apps. But this is not sufficient if you are a developer. Make sure you get to about these before you develop an app.
