That particular code example fails if ‘index’ isn’t an object, which would be done as part of an init script. It’s not far from pseudo-code. See the full code at https://github.com/jakearchibald/appcache-demo/blob/master/www/localstorage-cache/js/offliner-v1.js#L62 for an end-to-end example.
Copy & paste the code below to embed this comment.
xmlblog
My generation has a penchant for foul language. On our watch bitch and son-of-a-bitch have made it past the censors on the public airwaves. So you understand where I’m coming from, I’m no puritan—I use “colorful” language myself (perhaps too often I’m ashamed to say). But there are still places where I don’t. I don’t use expletives in meetings, or when toasting at weddings, in churches or temples, at the dinner table, and a few other places where the clearly seem inappropriate. On the other hand, great writers do often include distasteful words to make a sharp point. But they do so judiciously. If I understand you correctly, you made a conscious decision to employ the term, “douchebag.” Fine, but I think it was unwarranted and counterproductive in this case.
Copy & paste the code below to embed this comment.
Kris Meister
Nice to see a technical article with sass.
I finished a project recently which created a mobile Web-App for distribution on iOS and Android. Web-Apps are an especially convenient use of AppCache. The user bookmarks the app to their homescreen and upon opening the app runs in full-screen outside the browser and with AppCache will run without web connectivity.
In my case I was only building a prototype and didn’t run into many of the update issue you faced. But the client was very relieved that they didn’t need to integrate the whole iOS provisioning profile system.
I agree with your article that bookmarking individual content articles needs a solution and your technique of using LocalStorage fits the bill.
However, I think the future of AppCache is in creating Mobile Web-Apps that circumvent the proprietary vendor marketplaces.
Well done, sir, both for the technical content and writing style. Having hit most of those gotchas during the last year, I can only wish this had existed earlier.
@Seannachie: “Blatantly derogatory” to whom, exactly? Our nation’s poor, oppressed douchebag minority? The manufacturers of vaginal nozzle syringes? Or perhaps you’re afraid he’s hurting ApplicationCache’s feelings? But go ahead, please suggest an equally snappy, fetching and accurate alternative title then.
Thank you for the article. I am similar in my approach to development in terms of attitude. We don’t have to take ourselves too seriously and I find the ones that do have much less to contribute.
That is a great article, thank you very much. I learned a lot from it. Gotcha #6 could easily be avoided by providing different .manifest files for different platforms though.
Thanks very much for your greatful job. But I find that the “iframe hack” is not work in chrome(26), Each time I refresh the page(http://appcache-demo.s3-website-us-east-1.amazonaws.com/localstorage-cache/), static resources in fallback.html load from cache, but the same resources in index.html still download from server.
Copy & paste the code below to embed this comment.
Jempey
First of all, a great article and a great introduction into the story of going offline. The application cache is indeed not that easy to implement and there are a lot of pitfalls. But when it works, it works, and it works perfectly! To say… for the lastest popular desktop and mobile browsers.
In an attempt for a newspaper project I had to develop an android html5/javascript application which needed to work offline. Not a big problem at all, but when migrating everything to an android webview, allmost everything went wrong. Making the application cache work in an android webview seems to be extremely difficult. We haven’t found a solution yet, but for instance, the demo page of A List a part doesn’t work either.
More on this issue @ https://github.com/kurti-vdb/AppcacheDemo
Caching in general is not easy to get right, and caches on top of caches are always going to be a barrel of fun to debug, especially when they’re incredibly sensitive to all kinds of implicit assumptions and state.
For most purposes, AppCache does nothing more than the Expires HTTP header has done for years.
Content sent with future-dated Expires even works offline. (Until the user hits refresh, anyway—which is really a sign of what browser vendors have had to do to accommodate bad caching implementations. I’m interested to see if they will hold out any better against bad AppCache implementations.)
But AppCache is also a pre-loader, which is an entirely separate thing from caching, and I’m not sure they should be conflated. For a given resource you might reasonably want to cache but not pre-load, and for another pre-load but not cache.
For any non-trivial application, which is to say any application for which caching and preloading might be useful, the work of cache invalidation and decisions about what to pre-load, end up being done in application code. Letting the browser make some of the decisions independently of the app code leads to coupling, which leads to complexity, which leads to bugs.
33 Reader Comments
Back to the ArticleJake Archibald
That particular code example fails if ‘index’ isn’t an object, which would be done as part of an init script. It’s not far from pseudo-code. See the full code at https://github.com/jakearchibald/appcache-demo/blob/master/www/localstorage-cache/js/offliner-v1.js#L62 for an end-to-end example.
xmlblog
My generation has a penchant for foul language. On our watch bitch and son-of-a-bitch have made it past the censors on the public airwaves. So you understand where I’m coming from, I’m no puritan—I use “colorful” language myself (perhaps too often I’m ashamed to say). But there are still places where I don’t. I don’t use expletives in meetings, or when toasting at weddings, in churches or temples, at the dinner table, and a few other places where the clearly seem inappropriate. On the other hand, great writers do often include distasteful words to make a sharp point. But they do so judiciously. If I understand you correctly, you made a conscious decision to employ the term, “douchebag.” Fine, but I think it was unwarranted and counterproductive in this case.
Kris Meister
Nice to see a technical article with sass.
I finished a project recently which created a mobile Web-App for distribution on iOS and Android. Web-Apps are an especially convenient use of AppCache. The user bookmarks the app to their homescreen and upon opening the app runs in full-screen outside the browser and with AppCache will run without web connectivity.
In my case I was only building a prototype and didn’t run into many of the update issue you faced. But the client was very relieved that they didn’t need to integrate the whole iOS provisioning profile system.
I agree with your article that bookmarking individual content articles needs a solution and your technique of using LocalStorage fits the bill.
However, I think the future of AppCache is in creating Mobile Web-Apps that circumvent the proprietary vendor marketplaces.
jpatokal
Well done, sir, both for the technical content and writing style. Having hit most of those gotchas during the last year, I can only wish this had existed earlier.
@Seannachie: “Blatantly derogatory” to whom, exactly? Our nation’s poor, oppressed douchebag minority? The manufacturers of vaginal nozzle syringes? Or perhaps you’re afraid he’s hurting ApplicationCache’s feelings? But go ahead, please suggest an equally snappy, fetching and accurate alternative title then.
duppyconquer
I had to create this account to say…
@SEANNACHIE is a Douchebag! LMAO.
Ganesh
Its a great article :)
バイオの買物.com 代表 加々美直史
Great article. Doing something similar myself, the use of FALLBACK was especially informative.
Eric Brown 1
Good article. I’m just laughing at some of the cry baby comments. @SEANNACHIE… what an AppCache!!
Jason Sebring
Thank you for the article. I am similar in my approach to development in terms of attitude. We don’t have to take ourselves too seriously and I find the ones that do have much less to contribute.
Zero Point Surfer
That is a great article, thank you very much. I learned a lot from it. Gotcha #6 could easily be avoided by providing different .manifest files for different platforms though.
blessdyb
Thanks very much for your greatful job. But I find that the “iframe hack” is not work in chrome(26), Each time I refresh the page(http://appcache-demo.s3-website-us-east-1.amazonaws.com/localstorage-cache/), static resources in fallback.html load from cache, but the same resources in index.html still download from server.
Jempey
First of all, a great article and a great introduction into the story of going offline. The application cache is indeed not that easy to implement and there are a lot of pitfalls. But when it works, it works, and it works perfectly! To say… for the lastest popular desktop and mobile browsers.
In an attempt for a newspaper project I had to develop an android html5/javascript application which needed to work offline. Not a big problem at all, but when migrating everything to an android webview, allmost everything went wrong. Making the application cache work in an android webview seems to be extremely difficult. We haven’t found a solution yet, but for instance, the demo page of A List a part doesn’t work either.
More on this issue @ https://github.com/kurti-vdb/AppcacheDemo
Tom Love
Caching in general is not easy to get right, and caches on top of caches are always going to be a barrel of fun to debug, especially when they’re incredibly sensitive to all kinds of implicit assumptions and state.
For most purposes, AppCache does nothing more than the Expires HTTP header has done for years.
Content sent with future-dated Expires even works offline. (Until the user hits refresh, anyway—which is really a sign of what browser vendors have had to do to accommodate bad caching implementations. I’m interested to see if they will hold out any better against bad AppCache implementations.)
But AppCache is also a pre-loader, which is an entirely separate thing from caching, and I’m not sure they should be conflated. For a given resource you might reasonably want to cache but not pre-load, and for another pre-load but not cache.
For any non-trivial application, which is to say any application for which caching and preloading might be useful, the work of cache invalidation and decisions about what to pre-load, end up being done in application code. Letting the browser make some of the decisions independently of the app code leads to coupling, which leads to complexity, which leads to bugs.