Is swapCache() required in HTML5 offline apps?

Question

If I don't implement any updateready event handler and don't call swapCache(), does that mean that the browser will always use the first (oldest) downloaded version of the application?

If no, then why is the swapCache() method needed?

Bogbean

Answer 1

Swapcache makes sure that "subsequent" calls to cached resources are taken from the new cache. Subsequent meaning after swapcache. To see this in action try setting the src property of an img dynamically after the swapcache call in the updateready event (so that the browser loads it at that particular time). Make sure this image is not already loaded elsewhere in the page since that will distort this test. Now change the image and change the manifest files (to force reloading the cached files). Reload the page in your browser. You should now see the new version of the image in your rendered page. Now comment out the call to swapcache. Make a change to the manifest file and reload the page and thus all resources. Refresh the page again (to make sure you have a version from the new cache). Now change the image again and change the manifest. Again reload the page: now you see the old version of the image. In the last case, the browser finished loading the new versions in cache, but since swapcache was not called, the image was still taken from the old cache.

If you do not do any dynamic loading of resources in your page, the swapcache has no effect.

In particular, if you reload the page in the updateready event handler calling swapcache first has no effect since reloading the page will get it from the new cache anyway.

Dishwater

Answer 2

I have an app with a pretty large cache (>100mb). This takes a particularly long time to swap the cache in (and pretty much locks the browser while this is happening). So I display a message indicating that the app is updating (please wait...), then call swapCache(), then display a new message when it's done indicating completion.

Not sure if this answers your question (as to why it's necessarily needed), but I think it provides a valid use case for swapCache() at least.

Mahler

This is pretty cool. What would happen if you didn't call it, would the browser just be stuck for a long time on the next page load? And also, what happens after you called it, if you include some new files... can it happen that half of the files (ones already loaded) come from the old version, others from a newer one? – Lavalley

I don't think you'll ever run into a case where you have a mixed bag of cache files. swapCache() will only run when status='updateready' (otherwise it throws an error or just doesn't do anything I believe). If you added new files, they would be downloaded through the normal mechanism and once complete, fire a new 'updateready' event. I can't think of a scenario in which you could combine files from different cache versions. Not sure what would happen if I didn't call it. I presume that the application would just never be cached. Maybe I'll test that this weekend and get back to you. – Mahler

Tested. If swapCache() is not called, the application is not updated immediately but instead is updated the next time the page is refreshed. So basically you can give the user an option to update now or update later. If they're in the middle of doing something, this is a nice option to have. – Mahler

But if the page is not reloaded when you call swapCache(), imagine the following: page loads file1.js, calls swapCache() and then loads file2.js (e.g. using document.createElement('script')). Or an image instead of a JS file. Then you'd have loaded files from different versions, no? – Lavalley

In that scenario, the current page would continue to function with the old cache, whereas if you navigated to a new page it would be using the new cache. If you then went back to the original page, it would be using the new cache (the equivalent of refreshing it). – Mahler

Answer 3

Let's imagine 2 different scenarios.

1. You call location.reload() when the new content is available. The page will reload using its all-new content. applicationCache.swapCache() is not needed in this case.

2. Your user continues to interact with your page, without any reload. This interaction causes an asset to load dynamically. For the sake of argument, let's imagine that it's a rollover image, and let's imagine that you have just updated this rollover image. Without applicationCache.swapCache(), your user will continue to see the old rollover image. After applicationCache.swapCache(), s/he will see the new rollover image.

So applicationCache.swapCache() without a reload says: "Keep the page looking the way it was when it was loaded, but use any new assets now, as soon as the page asks for them".

Magisterial

Answer 4

The SwapCache method provides a mechanism for the application to be in control of how an when updates are applied. In regular HTML apps, it can be difficult to determine if the correct JS is present on the clients browser. Also browser implementations vary on when a cache would be updated, I found the iPhone particularly stubborn. swapCache put me back in control of how my app is updated i.e. I could choose to automatically apply the patch or let the user choose when to apply etc.

Unconventional

On updateready, I show a "Update available, click to restart now" notice and perform location.reload(); on click. If they don't click, the app is updated by itself the next time it loads. I don't understand how I could update the app without reloading, with swapCache(). And with reloading, I don't need swapCache() anyways. I still don't understand when it's needed. – Lavalley

Gets even weirder than that: in Chrome Im getting updateready event and when I call swapCache() inside handler, Chrome complains Uncaught InvalidStateError: Failed to execute 'swapCache' on 'ApplicationCache': there is no newer application cache to swap to. – Scrounge

Answer 5

I was wondering the same thing. I seem to be able to trigger a successful update by just calling "window.applicationCache.update()". If the manifest file has been modified, the 'download' event is triggered, then eventually the "update ready".

When I reload it, it appears to have been applied. I don't seem to need to call swapCache(). I have provision for calling it from the app, but so far have not noticed any effect on the update process.

Calling update() basically eliminates one reload, AFAICS.

Muns

Answer 6

swapCache will switch from the previous set of resources listed in the cache manifest (when the running webapp was loaded) to the new set. You are doing this in response to an updateready after all, which signals that a new manifest has been loaded.

This is not to be confused with loading individual resources, for which the usual browser caching policies still apply. In other words you will swap set of resources, but individual resources need their own cache management to ensure they're reloaded when you need them to.

I haven't tried this yet, but it would seem to suggest structuring the code as an "update controller" javascript file that handles the update process, and javascript sources with a versioned filename (or URL) with known entry points.

Truly