CHAPTER 12 ■ CREATING OFFLINE WEB APPLICATIONS

by the browser with no updates in progress. A cache enters the obsolete state if there was at one point a valid cache but the manifest is now missing. There are events (and callback attributes) in the API that correspond to some of these states. For instance, when the cache enters the idle state after an update, the cached event fires. At that time, an application might notify the user that they can disconnect from the network and still expect the application to be available in offline mode. Table 12-2 shows some common events and their associated caches states.

Table 12-2. Common Events and Their Cache States

onchecking CHECKING

ondownloading DOWNLOADING

onupdateready UPDATEREADY

onobsolete OBSOLETE

oncached IDLE

Additionally, there are events indicating update progress, when no update is available, or when an error has occurred:

•onerror

•onnoupdate

•onprogress

window.applicationCache has an update() method. Calling update() requests that the browser update the cache. This includes checking for a new version of the manifest file and downloading new resources if necessary. If there is no cache or if the cache is obsolete, an error will be thrown.

Application Cache in Action

Although creating the manifest file and using it in an application is relatively simple, what happens when you update pages on the server is not as intuitive as you might think. The main thing to keep in mind is that once the browser has successfully cached the application’s resources in the application cache, it will always serve those pages from the cache first. After that, the browser will do only one more thing: check if the manifest file has been changed on the server.

To better understand how the process works, let’s step through an example scenario, using the manifest file shown in Listing 12-5.

1.When you access the index.html page for the very first time (while online), say on http://www.example.com, the browser loads the page and its subresources (CSS, JavaScript, and image files).

2.While parsing the page, the browser comes across the manifest attribute in the html element and proceeds to load all the files listed in the CACHE (default)

301

CHAPTER 12 ■ CREATING OFFLINE WEB APPLICATIONS

and FALLBACK sections in the application cache for the example.com site (browsers allow about 5 MB of storage space).

3.From now on, when you navigate to http://www.example.com, the browser will always load the site from the application cache, and it will then attempt to check if the manifest file has been updated (it can only do the latter when you are online). This means that if you now go offline (voluntarily or otherwise) and point your browser at http://www.example.com, the browser will load the site from the application cache—yes, you can still use the site in its entirety in offline mode.

4.If you try to access a cached resource while you’re offline, it will load from the application cache. When you try to access a NETWORK resource (signup.html), FALLBACK content (offline.html) will be served. NETWORK files will be available again only if you go back online.

5.So far so good. Everything works as expected. We will now try to step you through the digital minefield that you must cross when you change content on the server. When you change, for example, the about.html page on the server and access that page while you’re in online mode by reloading the page in the browser, it would be reasonable to expect the updated page to show up. After all, you’re online and have direct access to the server. However, you will just be looking at the same old page as before, possibly with a puzzled look on your face. The reason for this is that the browser will always load the page from the application cache, and after that it checks only one thing: whether the manifest file has been updated. Therefore, if you want updated resources to be downloaded you must make a change to the manifest file as well (do not just “touch” the file, because that will not be considered a change—it must be a byte-for-byte change). A common way to make this change is to add a version comment at the top of the file as shown in Listing 12.5. The browser does not actually understand the version comment, but it is a good best practice to follow. Because of this and because it is easy to overlook a new or removed file, it is recommended that you use some sort of build script to maintain the manifest file. HTML5 Boilerplate 2.0 (http://html5boilerplate.com) ships with a build file that can be used to automatically build and version the appcache file, a great addition to that already great resource.

6.When you make a change to both the about.html page and the manifest file and subsequently refresh the page in your browser while you’re online you will, once again, be disappointed to see the same old page. What happened? Well, even though the browser has now found that the manifest has been updated and downloaded all of the files again into a new version of the cache, the page was already loaded from the application cache before the server check was performed, and the browser does not automatically reload the page for you in the browser. You can compare this process to how a new version of a software program (for example, the Firefox browser) can be downloaded in the background but require a restart of the program to take effect. If you can’t wait for the next page refresh, you can programmatically add an event listener for the onupdateready event and prompt the user to refresh the page. A little confusing at first, but it all actually makes sense when you think about it.

302