Building Offline HTML5 Power Web Apps and Offline App HTTP Cache
WEBINAR: On-demand webcast
How to Boost Database Development Productivity on Linux, Docker, and Kubernetes with Microsoft SQL Server 2017 REGISTER >
Today is a world of smart web applications powered by connectivity to the Internet. However, it would be a very poor customer experience if web pages hosting rich applications like email, calendars suddenly show a 404 error the moment they lose Internet connectivity. Customers expect their applications and web applications to work in the often-connected scenarios.
Moreover, in the age of Gmail and Google Chrome, it is expected that the web application continue to operate for the user when the Internet connectivity is lost and later regained.
To support such scenarios, the HTMl5 specification provides a couple of features that enable Web applications to work offline.
- SQL based database support for storing data locally
- Offline application HTTP cache which enables web application availability when Internet connectivity is list.
In this article, we will explore the "offline application HTTP cache" in more detail.
The support for enabling offline support is available as a manifest declaration that declare the files needed for the application to work offline. HTML5 compliant browsers honor this manifest declaration by caching a copy of the declared filed.
The application cache manifest is a text file that states resources that are desired to be cached. Also, it supports declaration of resources which are always to be retrieved from the server.
A simple Cache manifest file has three sections (as mentioned in the HTML5 specification http://www.w3.org/TR/offline-webapps/):
Section 1 is the CACHE MANIFEST section which declares all the resources that are to be cached to support offline mode. Any resource declared here will be downloaded the first time the browser loads the web page and it is connected to Internet.
The second section is the NETWORK section where we can declare all the resources that we do not want to cache. Server side scripts are a classic example which are typically declared in this section.
The third section in the application cache manifest is the FALLBACK section which declares the fallback URLs for specified URLs. In this section, the URL to fallback is specified.
Let us take a look at a simple application cache manifest file.
In the above manifest file, we have declared that we want to cache the following resources: (i) index.html, (ii) style.css, (iii) header.png, and (iv) background.png).
In the NETWORK section, we have also declared that we do not want servicesidescript.cgi to be cached and that this file needs to be fetched from the server every time.
Finally, in the FALLBACK section, we have declared that the application should fallback to resources mentioned in the list in case network is not available and user is trying to access online content.
This application cache manifest file typically resides in the same folder as the application. Server would typically block .appcache files. You can override that by declaring support for "text/cache-manifest" in the .htaccess file.
To link application cache manifest with a web application, the manifest attribute can be specified as under in the HTML file
In the above HTML file, we have specified "app.appcache" as the application cache manifest file and linked it to the web page.
Determining if the application is offline
HTML5 specifies support for an API to determine if the web application is offline or online.
The Navigator object has an onLine attribute which can be queried to check the status of internet connectivity.
var isOnline = navigator.onLine;
The web application can listen to online and offline events on the Window object to decide if they need to check if the online status has changed.
In this article, we learned about building offline HTML5 powered web application using offline application HTTP cache.
About the author
Vipul Patel is a Program Manager currently working at Amazon Corporation. He has formerly worked at Microsoft in the Lync team and in the .NET team (in the Base Class libraries and the Debugging and Profiling team). He can be reached at firstname.lastname@example.org