5 ms·

Amazon could to this, too, if they are forced to give all their profits to Apple after end of June. They were supposed to launch a web app reader soon anyway. T

Amazon could to this, too, if they are forced to give all their profits to Apple after end of June. They were supposed to launch a web app reader soon anyway. They demo'ed it a few months ago. 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.

thought_alarm 15y ago
This isn't some act of defiance. Playboy is doing exactly what Apple wants them to do, which is create content for the iPad. If Apple wanted them in the App Store they would be in the App Store.
pseudonym 15y ago
Considering the way Safari caches pages, you're lucky if you're not forced to reload a page when switching between Safari windows, let alone apps. The Safari cache size on iOS devices is cripplingly nonexistent, and I wouldn't be surprised if it only used RAM and no disk caching.
- statictype 15y ago
  I think if you explicitly specify a cache-manifest, it caches it somewhere - I assume to disk, since RAM is scarce. 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.
  - markbao 15y ago
    The Gmail web app uses regular cache manifest offline functionality to cache the assets, but then uses Web SQL (of which the W3C has dropped the development of the spec) to store and serve up the messages.
markbao 15y ago
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.54.39_AM.png 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.
statictype 15y ago
I doubt offline storage would be remotely capable of holding all your Kindle books. And requiring an internet connection to read it isn't optimal. 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.
- tomjen3 15y ago
  How much space does a kindle book take? 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?
  - abdelazer 15y ago
    Yes. The Web SQL database on iOS can hold a maximum of 50MB and on Android 2+ it can hold an expandable amount (in practice it's often limited for various reason to 50–100-ish).

thought_alarm 15y ago

This isn't some act of defiance. Playboy is doing exactly what Apple wants them to do, which is create content for the iPad. If Apple wanted them in the App Store they would be in the App Store.

pseudonym 15y ago

Considering the way Safari caches pages, you're lucky if you're not forced to reload a page when switching between Safari windows, let alone apps. The Safari cache size on iOS devices is cripplingly nonexistent, and I wouldn't be surprised if it only used RAM and no disk caching.

statictype 15y ago
I think if you explicitly specify a cache-manifest, it caches it somewhere - I assume to disk, since RAM is scarce. 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.
- markbao 15y ago
  The Gmail web app uses regular cache manifest offline functionality to cache the assets, but then uses Web SQL (of which the W3C has dropped the development of the spec) to store and serve up the messages.

markbao 15y ago

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.54.39_AM.png 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.

statictype 15y ago

I doubt offline storage would be remotely capable of holding all your Kindle books. And requiring an internet connection to read it isn't optimal. 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.

tomjen3 15y ago
How much space does a kindle book take? 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?
- abdelazer 15y ago
  Yes. The Web SQL database on iOS can hold a maximum of 50MB and on Android 2+ it can hold an expandable amount (in practice it's often limited for various reason to 50–100-ish).