But why didn't Playboy use offline cache or something? Is it because the Mobile Safari is limited in that regard? I have a feeling Apple will hold off improving that feature for a long time.
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.
"Using the cache will automatically cache the index page by default" => "...cache the page that you put the cache manifest reference to"
"This only works on iOS devices, though" => "This only works on Webkit devices, though"
The Gmail web app (along with some others I've forgotten now) seem to start extremely quickly when you bookmark them to the home screen.
In any case, this new subscription service only affects repeating payments right? So Amazon could still release the Kindle without that feature and it would still work with books that you have bought from the store.
Actually lets get some numbers for that.
Gutenberg ebook 11 (Alice in Wonderland) is available in kindle format 131kb. It is a short childrens book.
Gutenberg ebook 2600 (War and Peace) is available in kindle format 2mb. It is properly longer than most books though.
A tale of two cities (ebook 98) is also available, 506kb.
Anna Karenina (1399) is also available, at 1.1mb.
Twenty Thousand Leagues Under the Sea (ebook 2488) is 551kb with pictures, 518kb sans pictures.
So lets say the average book is going to be about 750kb and most people only need access to their three most recent books. That is only about 3-4mb - can't a web app store that much, client side?