5

I've created a web app that caches all necessary code and data for use offline through applicationCache. However, every time the app starts up, it immediately tries to check for updates. This blocks the browser for a significant chunk of time, even if it doesn't find anything to update. This behavior is highly disruptive to the app (shouldn't updates be done in the background, anyway?). Just the checking stage takes a lot of time on a mobile device, and if it find updates all bets are off as to how long downloading will take (b/c it has to redownload all files) - which also freezes up the browser.

So, I am wondering:

  1. Is there a way to delegate applicationCache updates to a shared Web Worker? OR
  2. Is there a way to block all applicationCache updates until the user specifically wants to check for updates and presses a button that will initiate updates through applicationCache.update()? OR
  3. Are there other ways to mitigate the time spent on checking for updates?
  4. Shouldn't application cache updates run asynchronously in the background?



edit: perhaps a carefully-constructed cache-control header on the manifest file is the answer? I'll be investigating this, but I hope somebody can give me more info on these updates. Thanks.


UPDATE

Ok, I've played with headers, and nothing has helped. I'm starting a bounty. If you can help, please do!

Community
  • 1
  • 1
ampersand
  • 4,264
  • 2
  • 24
  • 32

2 Answers2

1

If you want to give the user more control over the actual update, you could parameterise the manifest URL with something specific to that user. Then when the user wants to update, you fire off a request to the server which rolls that particular user's manifest file, and then reload the page client-side to force a reload of the manifest.

I've since been doing some reading and came across this article which seems to be a much more elegant solution if the user is already on the cached page -

http://www.html5rocks.com/tutorials/appcache/beginner/#toc-updating-cache

As for the load time involved in the manifest up-to-date check, that's not something I've ever had a problem with. My understanding was that it happens in the background, are you just concerned about the browser showing loading hints?

Chris
  • 522
  • 2
  • 6
  • thank you for trying. I've already been through that article and every other good one out there on application cache. I have similar update functionality already baked in. I can tell you this: I also thought cache updates should happen in the bg, but they in fact freeze the UI during update. And the browser updates on page launch REGARDLESS of whether I tell it to or not. I am not concerned with hints or anything like that. I am concerned with a non-functional user interface while the page is loading. I'll post a link in a moment so you can take a look at the whole thing. – ampersand May 31 '11 at 23:55
  • I haven't had much of a chance to look at it but there appears to be a significant amount of work being done in the dataLoader done callback. Are you sure that it is not this which is causing the lag you see? I've had some experience with jQuery mobile and we found that doing any rebuilding of the UI in JavaScript caused significant performance problems (we actually went as far as swapping out jQuery mobile with our own platform). – Chris Jun 01 '11 at 12:19
  • The dataLoader is mostly doing just that - loading data - from the cache. There is hardly any dom manipulation....Perhaps it's poor design on my part, but I'm not sure. Anyway, thanks for taking a look. – ampersand Jun 01 '11 at 16:11
0

The abort() method may be the answer...someday, but I haven't come across any browsers that implement it yet.

I had a similar problem, and tried everything, including the wild idea of putting the manifest inside itself to see if it would cache itself. So I could do the updates manually with ajax requests and eval'ing javascript stuffed into localStorage...yikes.

Finally, I created a very simple html page with a simple manifest. When I tested it, the UI didn't lock up. Slowly I started to add things into the page, and play around with the manifest contents to see what things might cause it to freeze during the applicationCache check. I finally got failure when I added an image to the page, but left it out of the manifest -- that's when the UI started to lock up again. I went back to my original project, and found a few images that needed to be in the manifest, and that fixed the locking UI issue there too.

The checking phase of the applicationCache tries to be asynchronous (at least on the devices I've tested). However, if there are any files missing from the manifest, then everything must wait for the applicationCache to finish checking.

It appears that when the browser needs a file that has not been cached, it waits for the applicationCache to complete the update before it will make a request for the file -- which kind of makes sense, since other resources may rely on the missing file. This puts the brakes on the rendering and makes the UI freeze up. If the manifest is unreachable (e.g. on a different network), the UI can be locked up for about a minute.

To find the files that need to be added to the manifest, watch the server logs as you refresh the app a few times. The suspects will be any GET requests for files other than the manifest.

two-bit-fool
  • 4,978
  • 6
  • 28
  • 26