Debugging Offline Web applications can be hard, because you have to make sure you really are using the current version of your files. If the manifest file is not changed, the browser will not reload the other files, even if they have been changed.
So a good advice is to create some automated build script that changes a version number in your manifest file.
Also keep in mind that when the manifest file has changed and the browser has updated the files, it won’t use them for the current session. So you may want to ask the user to reload the application. For example like this:
window.applicationCache.addEventListener('updateready', function(e) {
if (window.applicationCache.status == window.applicationCache.UPDATEREADY) {
// A changed manifest file has been found and downloaded by
// the browser. Swap cache and reload the page to use the new files.
window.applicationCache.swapCache();
if (confirm('A new version of this site is available. Load it?')) {
window.location.reload();
}
}
}, false);
Debugging using Google Chrome
You can get deeper insights in the caching behavior of your application by using Google Chrome. It offers two helpful functions:
1. Developer Tools
Learn: How to Access the Developer Tools
If the Console is activated (Control-Shift-J or ⌥⌘J), you can see details of the caching mechanics that are automatically logged by the browser.
Example:
Files are getting cached...
Files have already been cached...
You can also implement individual logging by hooking up to the events provided by the API. See the the “AppCache events” section in the Beginners Guide to Using the Application Cache on HTML5 Rocks, for example.
2. AppCache-Internals
You get a list with all cached offline applications with information about Size, Creation Time, Last Update Access and Last Access Time when you open the following internal URL:
chrome://appcache-internals/
If you click on “View Entries”, you will get detailed information about each individual file. You can see if a file has been explicitly or implicitly cached and which one is the master document of the application.
Now, if you click on an individual file, you can even control the actual content of the cached file and see which headers had been sent from the server.
Debugging on an iOS device
If you are debugging on an iOS device be sure to follow the instructions from the Safari Web Content Guide, Section “Debugging”. If in Safari, you will have a chance to see errors with your manifest file.
If in Web App mode, to be sure the cache is deleted, you have to clear history, cookies and cache and to reboot the device. Otherwise you might still be loading old versions of your updated files.
In my tests I found the iOS Web App cache the most hardcore cache to use, ever.
See also:
