tags:

views:

353

answers:

3

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?

A: 

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.

Andy Monis
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.
Jaka Jančar
A: 

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.

BobFromBris
+1  A: 

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.

dosboy
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?
Jaka Jančar
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.
dosboy
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.
dosboy
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?
Jaka Jančar
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).
dosboy