Close
Enter your
text here

Offline Web Applications with HTML5 – Part 1

Offline Web Applications with HTML5 – Part 1 150 150 manu.mukundan
Written by Kerstin Maier

Offline Web Applications with HTML5 - Part 1

Friday, 05 September 2014 00:00

The ability of web-based applications to run offline is a requirement that is still indispensable in many companies today. Although the trend in the age of mobile devices such as smartphones and PDAs today is that everyone is online 24 hours a day.
There are still many situations in which an internet connection is expected or unexpectedly not available. An offline-capable web application enables the user to continue working in these cases without disturbing his workflow or losing data. The new HTML5 specification also deals with the requirement “offline capability” and provides some features for implementation. In a series of blog entries we would like to introduce these to you.
The central feature to support offline capable web applications in the HTML5 specification is the Offline Application Caching API. In addition, there are some complementary independent specifications that aim to provide further offline functionality.

.

The offline features of HTML5 consist of the following components
The Offline Application Caching API (ApplicationCache)

  • The Web Storage specification: includes an API for client-side storage of session-specific data and an API for storage of cross-session data
  • The Web SQL database: a client-side JavaScript database
  • Web Workers: to execute parallel “background” processes in the client
  • This blog entry deals with the HTML5 Application Cache. The further specifications are presented in the following blog entries.

The HTML5 Application Caching API

An application cache is a set of cached resources identified by URLs. HTML5 offers the developer of a web application the possibility to create a manifest file in which he specifies all files that the browser should cache (i.e. all files that are necessary to display the page correctly offline).

To enable the caching of a page, the HTML attribute “manifest” must be defined on the <html> element:
<!DOCTYPE HTML> <html manifest=”/cache.manifest”> <body> … </body> </html>
manifest.cache is the name of the manifest file.
The following box shows an example manifest file:#v1 – Version of the manifest file
CACHE MANIFEST index.html stylesheet.css images/logo.png scripts/misc.js NETWORK: search.php login.php FALLBACK: images/dynamic.php static_image.png

The manifest file must always start with CACHE MANIFEST and consists of the following parts:
CACHE: this section defines the resources to cache
NETWORK: defines a whitelist of resources that must never be cached and always require a connection to the server. If the user is not online, the browser should not use a cached version of these files.
FALLBACK: this section is intended to provide a backup strategy. If for some reason the browser cannot load the files to be cached, the fallback resources are used instead. Each line under Fallback consists of 2 URIs. The second URI is a URI the browser should use if the files under the 1st URI cannot be found.
In the example a static image should be loaded if the data under images/dynamic.php cannot be loaded.

All lines starting with # are considered comments.
How does the caching work? If the user calls up a page for which a cache has been defined, the browser tries to refresh it. It first loads a copy of the manifest. At the first call it loads all resources into the cache.

If the page is called again, it checks whether the manifest has changed. If so, all resources are downloaded again. The cache is not updated if only files listed in it have changed. So to trigger an update, the contents of the manifest file must be changed (for example, you can count up the version number in the comment).

HTML5 also defines an API to make changes to the cache manually. This includes various methods to query the online/offline status, to manually update or empty the cache, and the ability to register EventListener to access various cache event