On mobile devices, the users may not always have a good network connection – however the web app should still work. So it helps to look at the network as an enhancement rather than a requirement.
The philosophy to be used here should be
Offline means not having a wifi or data connection – but these scenarios cannot be detected by seeking a network connection attempt – this is fact a tricky area. Look at the following scenarios for a computer with only wifi.
The browser cannot definitely tell if it is online. Or even if it is definitely offline unless it has no connection at all to another device.
There is an attribute that is supposed to tell whether your machine is connected and couple of alerts that are there in the body of the document which go off when it goes offline or online.
However, these only tell you whether there is a network connection or not – but not weather that connection is connected to anything. For e.g if your computer is connected to the router but you cable modem goes out, your computer will be fooled into believing that it is connected.
Similarly, the network connection may be there but ‘barely’ there, e.g one bar network.
This is why we cannot have online by default: we cant wait for the network to fail first.
You cant build for ‘online first’ and use ‘cache’ if the connection fails, since it often takes a long time to determine if the computer is connected or not – the user cannot be left in a waiting mode during this time.
So what does ‘offline first’ approach mean?
The appcache is a manifest that is pointed to from inside the html file.
Some points to remember about managing the appcache
- only files that can be statically served can be localy cached (if it has to be interpreted by the server, e.g a python script, it cannot be cached).
- The appcache is likely to have a limited size so adding too many files or heavy files like video may lead to issues.
- Refreshing of cache has to be optimised.
The key point is that on a mobile device,
- the appcache is used first even when the mobile is online,
- the app should be optimised to first serve from the cache even before it connects to the network.
A key challenge of working with the manifest file is that it has to be updated every time the resources are changed – hence any time any of the files in the system are changed (e.g just tweaking the css a bit), the manifest too has to be changed. One way is to keep updating the manifest version number every time such a change happens.
Once you have an appcache on the user’s machine, on every subsequent reload, the resources will be loaded from the appcache even if it is online. For a Html resource with a manifest, an async manifest update will be started, even though the user is served from the cache – the user in this case is already served the page from the cache even as the manifest finishes getting updated.
It is possible to listen for a new update being available and then prompting the user to reload for an update from the new cache.
Note: The manifest file should never be far-future cached as otherwise the user will get locked into the cache downloaded and will never be able to refresh the same unless he deletes the cache from his device.
Apart from the app resources like html / css / images etc, it is important to figure out what data can be stored locally on the device.
There are 3 possible methods of storing locally.
Local storage is the oldest and most basic storage APIs – however, you can only get 2-5 MB in local storage per domain depending on the browser, cannot search through the data.
WebSQL is a more complex storage system – however, it is not available for IE or firefox plus it is a specification that is no longer being maintained and hence is a dead end.
Indexed DB is the other choice for a complex DB storage system – it is supported in all the new browsers but not supported in some of the older browsers.
What data should be stored in the local storage?
Persistent data would be useful to store as it would be required in future sessions. Network API responses would be useful to store especially for offline situations as you already then have the data from a previous session cached.
A final warning:
The user could delete the cache anytime and hence the local storage should never be the ONLY place any important data is stored.
Do read the other related posts which cover the notes for the other chapters of this course.
ps: to find all posts related to this post, searching for ‘mobile web development’ should help.