original source: https://winch.io/blog/article/caching-prefetching-and-the-offline-mode/

Pierre Chapuis, 2013-08-21

# Caching, Prefetching and the Offline Mode

Making native mobile applications really fast on slow networks is far 
from trivial. We will see how caching requests is just the baseline, 
how prefetching is better but still not perfect, and how true offline 
modes are attainable.

## Caching is good

Mobile applications have a particularity: they cannot seriously rely on 
the network. Sometimes users will be completely offline, but even when 
they are not odds are that the network will be way slower than on a 
regular terminal.

Paradoxically, mobile applications also tend to make a lot of network 
requests. That is because bundling data with the applications 
themselves is impractical: it increases their weight significantly and 
forces developers to publish new releases to update them, a process 
which can take weeks on some platforms.

A common way to increase the reactivity of those applications is to 
introduce a cache. The principle is simple: the application remembers 
requests it makes and their results, and if it should make a request it 
has already made in the past, it returns the previous result instead.

For instance, imagine a simple application to browse an online photo 
album. The user scrolls through photos, and every time they do the 
application requests a JPEG image and displays it.

If the application does not use a cache, when the user opens the 
application, the first photograph is downloaded and shown to the user 
with some latency. They scroll to the second photograph, same thing. 
They scroll back to the first one, and here we go again. Every action 
incurs a latency penalty due to network requests.

If the application does use a cache, our user will still suffer from 
latency for the first and second photographs, but they will not when 
they go back to the first one. That image will already be in the cache, 
so it will be returned instantly.

By the way, as you may know, Web browsers already use that technique. 
However, if you make a native application, you better make sure your 
network library takes care of this or implement it yourself.

## Prefetching is better

As we saw, using a cache helps, but only for requests that have already 
been made by the application. Is there any way to make new requests 
faster then?

One of the solutions is called prefetching: when you know that you are 
likely to need an asset soon, you make the corresponding request 
immediatly in an asynchronous fashion. That way, the result will be 
stored in the cache, and when you will actually need it it will be 
available instantaneously.

In our online photo album example, you could start to prefetch all the 
photos of the album as soon as the user opens it. Sliding to the second 
photograph would then be as fast as coming back to the first one: both 
requests would be cache hits.

Sadly, that logic is not trivial, so few application developers bother 
to implement it. This is a domain where the Web is actually ahead, 
since browser [vendors care a lot about speed](1). So much for people who 
thought native always meant fast.

1: http://www.igvita.com/posa/high-performance-networking-in-google-chrome/#prefetching

## Offline as the default

We have seen that prefetching was better than caching, but that few 
applications benefited from it due to its implementation complexity. 
Moreover, there are other issues to solve, one of which is expiration. 
Once you have put something in the cache, when are you going to remove 
it? And if the resource changes on the server, how are you going to 
know your local copy is outdated if you never request it?

On top of that, a cache, even with prefetching, is designed to speed up 
requests when your user has access to the network. It does not 
guarantee what will happen if they temporarily do not, for instance if 
they ride public transportation. Too bad, since being used in such 
places is precisely the very definition of mobile devices.

Knowing that, you can go a step further: instead of fetching data to 
warm a cache, store it in a local, durable database. Instead of 
expiring content, have the servers explicitly inform mobile devices of 
what they should update and what they can remove. This way, your 
application will be fast and work offline.

The issue? Now you need to implement a local database. You need a 
server, and server-side logic. You need client-side code to manage the 
data. You need efficient networking code to download it, and this is a 
whole problem in itself...

Prefetching was hard enough that most people did not care, and this is 
way harder. Who will do it? Is this wishful thinking?

Well, no longer. It turns out, we have done it for you! Winch is a 
system comprising an embedded database, a data transfer protocol and a 
Software as a Service part, which makes writing fast mobile 
applications that also work offline as easy as possible. Add it to your 
application, store your data in a central datastore, and we will make 
sure to deliver it to your mobile clients efficiently.

Curious? Learn more about how it works. Sold already? Then sign up and 
dive in!