I've worked rather extensively with the offline cache, and I can confidently report that the offline cache is buggy and annoying to use, especially with MobileSafari. It's not as simple as just simply downloading content and telling the browser 'when offline, serve this up.' You need to define exactly what resources you want to cache in a file called the cache manifest. The browser will download and cache the content, and subsequent accesses to the website will serve up the cached content and assets, even if you are online. To update the cache for new items, the original cache manifest file needs to be updated. However, a pretty prevalent bug sometimes occurs when you update the cache manifest file, but MobileSafari refuses to re-cache content. In this case, MobileSafari will forever serve up the cached content and never see the changes in the cache manifest file, until the user goes to their Settings and clears the cache. I'll give you one guess as to how many will do that.
Using the cache will automatically cache the index page by default, as it is the master file that is telling the browser to cache according to the cache manifest. Therefore, every time the browser accesses this file, it will be served from cache, even if you are online. That means that if you want dynamic content, you will have to make an ajax request to refresh the content on the index page. This proves especially frustrating if you have a lot of areas with dynamic content. And forget about doing logged in/logged out functionality.
Furthermore, when the cache manifest file is updated and the browser redownloads all the files, the updated files will not show in the navigator until after a refresh. So let's say you updated your index page and bumped the cache manifest to tell the browser to update the index page. It will first serve the old index page from the old cache, and then serve the new index page from the just-updated cache upon the next refresh.
So should the offline access store the entire history of articles? Or should it store, say, the latest accessed ones? If you just store the latest accessed issues, you would have to update the cache manifest file when a new issue has been updated, and then MobileSafari will need to re-download every single image file and asset over again. No diffs. Yuck.
There are a lot of compromises you need to make when building offline caching with MobileSafari using the application cache, and there is always the risk of the occasional refusal to cache which will require the user to manually clear the application cache in the settings (few will ever do that). Offline functionality is possible, but you will need to make serious concessions and work around the problems that caching currently has. Not to mention the little space given on disk for caching.
The way I tried to work around it, which is not foolproof but at least it's Windows XP compared to the Microsoft BOB of going all offline cache, is to use offline cache for assets (css, js, index file), use ajax to populate dynamic elements when online, and for the storage and retrieval of raw data, use the (now deprecated) Web SQL database. This is the approach Google uses for offline Gmail (screenshot for the curious: http://winning.markbao.com/6xyM/Screen_shot_2011-05-22_at_7....). This only works on iOS devices, though, and would not work for Playboy since their data isn't text, but jpegs.
I guess you could store images as base64 encoded text in the Web SQL database, then create the images using the data: protocol. However, not sure you could fit many images in as the file size would be higher.
Using the cache will automatically cache the index page by default, as it is the master file that is telling the browser to cache according to the cache manifest. Therefore, every time the browser accesses this file, it will be served from cache, even if you are online. That means that if you want dynamic content, you will have to make an ajax request to refresh the content on the index page. This proves especially frustrating if you have a lot of areas with dynamic content. And forget about doing logged in/logged out functionality.
Furthermore, when the cache manifest file is updated and the browser redownloads all the files, the updated files will not show in the navigator until after a refresh. So let's say you updated your index page and bumped the cache manifest to tell the browser to update the index page. It will first serve the old index page from the old cache, and then serve the new index page from the just-updated cache upon the next refresh.
So should the offline access store the entire history of articles? Or should it store, say, the latest accessed ones? If you just store the latest accessed issues, you would have to update the cache manifest file when a new issue has been updated, and then MobileSafari will need to re-download every single image file and asset over again. No diffs. Yuck.
There are a lot of compromises you need to make when building offline caching with MobileSafari using the application cache, and there is always the risk of the occasional refusal to cache which will require the user to manually clear the application cache in the settings (few will ever do that). Offline functionality is possible, but you will need to make serious concessions and work around the problems that caching currently has. Not to mention the little space given on disk for caching.
The way I tried to work around it, which is not foolproof but at least it's Windows XP compared to the Microsoft BOB of going all offline cache, is to use offline cache for assets (css, js, index file), use ajax to populate dynamic elements when online, and for the storage and retrieval of raw data, use the (now deprecated) Web SQL database. This is the approach Google uses for offline Gmail (screenshot for the curious: http://winning.markbao.com/6xyM/Screen_shot_2011-05-22_at_7....). This only works on iOS devices, though, and would not work for Playboy since their data isn't text, but jpegs.
tl;dr caching sucks.