Understand offline first and offline last in Android

This article is a follow up of this article How to make an easy offline working Android application. In this article, I will explain you what are the main offline strategies: offline first and offline last. The implementation will be done using an HTTP cache as explained in the previous article.

Offline first strategy

Even if the server if available, you get the information from the cache.

Offline first schema

As you can see on the schema, the application will request information from the cache almost every time. The two notable exception to this rule are:

• Cache is empty. It means that your application never connect to the Internet.
• Cache is outdated. The condition to determine if a cache is outdated or not is fixed by you. It can be the time or your app receiving a push notification for example.

Here is a possible implementation of this strategy

This implementation is composed of two steps:

• In HttpService line 15, there is a declared constant HEADER_CACHE that is used in ChatService line 14. This constant represent the time in second that you want to keep the request in cache. I have done that because I consider that every request will have a different value. Indeed, for a response containing a variable price, 5 minutes should be enough while a response containing a phone number can be stored for a day.
• Then in HttpService line 26, there is an HTTP interceptor. This interceptor will read the previously declared header and if it have a value it will check the cache for the requested time. This means that in my case, I will request the server only every 60 seconds.

The main advantage of this implementation is that if you rotate your device and do an other request to the service. That’s fine because you won’t actually query the server, only your cache.

Offline last strategy

Only when the server isn’t available, you get the information from the cache.

Offline last schema

As you can see on the schema, the application will request information from the cache only when the server isn’t available.

Here is a possible implementation of this strategy

For this implementation, the important part is the interceptor line 25. By default, the request is proceed to the server except when an exception is raised (usually a ConnectException). In this case, the request is rerouted to the cache. There is also a max-stale attribute to this request because I consider that the cache isn’t valid after 24 hours without a connection to the server.

The main advantage of this implementation is that if your user doesn’t have Internet and/or you have issues with your server, you can still make your app usable if it doesn’t require new data for your user. This is way better than having your app crashes or not usable at all without Internet.

How to use the two strategies at the same time?

It is possible, the implementation follow this schema:

Combination between offline first and offline last

It works like this:

• At t0, a request is made to the server with a correct response.
• Between t0 and t1, the HTTP client will only look for the cached response
• At t1, a request is made to the server if it works when we are back in t0 case.
• Between t1 and t2, every time the HTTP client can’t access the server it reads from the last cached response. If it access the server, then we are back in t0 case.
• After t2, you should ask your user to connect to the Internet because the data that you have in your cache is completely outdated.

Here is a possible implementation of it:

As you can see, it take the same implementation as before:

• Between line 27 and 37, that’s the offline first implementation.
• Between line 37 and 47, that’s the offline last implementation.

And that’s it, I hope you enjoyed this article. If you have any questions, you can contact me using my linkedin, my twitter or in the comment section below.