by December 1, 2010 0 comments



Shwetank Dixit, Opera Software

One of the limitations of the Web so far has been that we always have to be connected online to use it. To make the Web truly compete with desktop or other native apps, we need a way to run web applications in an offline environment too.
Till now it wasn’t really feasible to do so, but with HTML5 and other upcoming technologies, it has become possible. In this article we’ll take a look at how to do so.

Storing data for offline use

Till now we did not have a reliable way to store data on the client side for offline usage. Sure, we have cookies, but their storage limit is really low, and there are no programmatic APIs as such to make storing and retrieving data from it easy and robust. We needed a new way to do it, and the W3C has come up with an API called the Web Storage API for this purpose.
The Web Storage API has ways to store data for two purposes. One is called ‘Session Storage’ which is for storing data temporarily just for that session. Once you close the window or tab, its gone. The other is called ‘Local Storage’, which is much more persistent. Even if you close the tab or window, but load the site up again in a new tab or window, the data should persist until the time you explicitly delete it using your browser’s preference options.
We’ll focus on local storage, and see how data can be stored in the browser in a persistent manner with it. Using it is quite simple really. It works in the following way:
localStorage.setItem (yourkey, yourvalue); //sets the key and value associated with it
localStorage.getItem(yourkey); //will return a value associated with that key
For example, in the JavaScript of your page, just write the following:
localStorage.setItem (“India”, “Rupee”);
localStorage.setItem (“USA”, “Dollar”);
localStorage.setItem (“Japan”, “Yen”);
The above code will store country names as keys, and the corresponding currencies as values.
Then if you write something like:
var currency = localStorage.getItem(“India”);
the value of ‘currency’ will now be ‘Rupee’
Keep in mind that information is stored as strings here, so if you are storing a numerical value, and try to retrieve it back, then convert its type from a string, to a float or something similar.

Storing files needed to run the application offline
We’ve seen how to store the data for offline usage, but how about the actual files which are needed to run an app offline? Till now we had to reply on the browser cache, but it was unreliable and once again, we did not have a programmatic API to control which files needed to be cached in which way.
So in HTML5, you have a new feature called offline applications. Modern browsers, like Opera, which have advanced support for HTML5, support this. It calls for browsers to support a special type of cache called ‘Application Cache’, or ‘AppCache’ for short. The AppCache is a special type of cache which will store the files needed to run the application offline reliably and with greater programmatic control. Lets see how this works.

The Manifest File
The manifest file is just a text file renamed as ‘.manifest’ which will list the files that the AppCache needs to store for offline usage. The first line of the manifest file always has to start with the words ‘CACHE MANIFEST’
The following is an example of a simple cache manifest file
CACHE MANIFEST
styles.css
scripting.js
index.htm
The above states that styles.css, scripting.js and index.htm will be stored in the browsers application cache.
Keep in mind that this manifest file has to be served with the MIME type as ‘text/cache-manifest’. Also keep in mind that all the files mentioned here are relative to the URL of the manifest file. In the above example, the three files mentioned are assumed to be in the same directory as the manifest file itself.
Now to make sure that our web page actually uses this application cache. How do we do that? By employing the following code in the html

where ‘example.manifest’ is our manifest file which lists the files to be stored in the AppCache.

Using section headers
You can use section headers in the manifest files to special case how the files will be stored (or not stored).
For example, you may want certain files to always be downloaded from the server, and never be part of the application cache. You can do this by using the ‘NETWORK:’ section header.
For example, take the following manifest file
CACHE MANIFEST
CACHE:
files/*
NETWORK:
files/style.css
In the above example, all files will be cached under the ‘files’ directory, however, an exception will be made for style.css, which will bypass the AppCache, and always will be downloaded from the server and never be stored in the AppCache.
You can also use section headers to provide fallback content. Say if a picture hasn’t loaded completely or at all, then instead of showing a blank space, it might be good to display a default image there instead. You can do this kind of stuff using the ‘FALLBACK:’ section header.
For example,
CACHE MANIFEST
CACHE:
index.htm
style.css
FALLBACK:
image.jpg fallback.jpg
In the above example, index.htm and styles.css are stored in the AppCache. If we look under the ‘FALLBACK:’ section header, we’ll see two files: ‘image.jpg’ and ‘fallback.jpg’. The latter is also stored in the AppCache, but will only be displayed in place of image.jpg if image.jpg fails to load completely for some reason.
If image.jpg does load properly, then the fallback image will not be shown in its place, but otherwise, it will.

Using the Application Cache API
The Speciifcation lists an API that you can work with to periodically update the AppCache with newer files and it swap in the new cache. We’ll look at the main things from the API here. For more details on other events and functions, refer to the specification. Depending on the state of the AppCache at the moment, certain events gets fired. One notable one is ‘updateready’, which is called when a newer version of the manifest file is available on the server.
When ‘updateready’ is fired, we need to get the new copy of the manifest file and then swap in the old manifest copy with the updated manifest file.
We get a copy of the newest manifest file by using the ‘applicationCache.update()’ function. This will get us the newest copy of the manifest file. However, this copy is sill not in use. We still need to swap it in and replace the older cache. We do it using the ‘applicationCache.swapCache()’ function.
Lets take a look at the following code:
setInterval(function () { window.applicationCache.update(); }, 1800000); // We check for an updated manifest file every 30 minutes. If it’s updated, we download a new cache as defined by the new manifest file.
window.applicationCache.addEventListener(‘updateready’, function(){
window.applicationCache.swapCache(); //swap to the newest version of the cache
}, false);
In the above code, we check every 30 minutes whether the manifest file has been updated on the server or not. If it has, then a new copy of the cache is downloaded, as specified in the updated manifest file.
Once this happens, then an ‘updateready’ event is fired, telling the browser that an updated AppCache is ready to be swapped in for use. We have an event handler in place which listens to this event, and as soon as the event is fired, application.swapCache() is run, which swaps out the old copy (which was in use till now) and swaps in the new updated copy of the AppCache for further use.

Wrapping it up
We’ve now seen how to use cutting edge web technologies to store data and files for your web application for offline usage. This is a really powerful capability for web applications to have, and hopefully we’ll see Web applications gain more of a prominence and usage by people, even when people are not connected to the Internet.

No Comments so far

Jump into a conversation

No Comments Yet!

You can be the one to start a conversation.

<