Offline.
Like Online!
But not.
Why Offline
Increasing use of websites as applications
Never possible to guarantee connection on the server or client side, regardless of fallbacks
Risk of downtime can restrict uptake when software is mission critical
Developers blood pressure is generally too low anyway
How Offline
Separate components deal with code storage and data storage
Local Storage
a JavaScript interface for simple string storage
App Cache
a new standard for caching linked resources and HTML
a really, really annoying one
Local Storage
Really basic string storage:
localStorage.setItem('morning','ben');
var hero=localStorage.getItem('morning');
alert(hero); // outputs ben
We can get more utility with JSON
localStorage.setItem('rick',JSON.stringify({"drinks":[beer]}));
var rick=JSON.parse(localStorage.getItem('rick'));
alert(rick.drinks[0]); // outputs beer
Can be expanded using
Storage.prototype.twitter = function() { alert('poopin'); }
Application Cache
<html lang="en" manifest="offline.appcache">
A single file listing all dependencies.
CACHE MANIFEST
style.css
local-storage.js
cat.jpg
comic-sans.ttf
HTML content is cached by the presence of this file.
Including files in the appcache does not link them in the application. They must still be linked with HTML elements
So Far So Good
We already had some pretty good caching mechanisms with HTTP
Expires: Thu, 6 Oct 2013 03:14:15 GMT
Modifying a query string on a resource link re-fetches
<link rel="stylesheet" href="style.css?201308061930"/>
Application Cache will tell you where to go with your smart ass ideas
Where it Goes Wrong
When a page loads, appcache is checked first
HTML and other resources are loaded from the cache
Then, regardless of anything else, the page is rendered
Then the appcache file is re-downloaded from it's original URL
So the page rendered for the user is always their last cached page
Where it Goes Wronger
Because the HTML is rendered from the cache, no changes to query strings or headers will re-download your page
Only changes to the appcache file itself will allow new resources to be downloaded
At which point resources are downloaded again
Or not because these also still follow old caching rules
In Case You Missed It
Only changes to the appcache file itself will work
Changing the URL of the file won't work - because the HTML won't be re-downloaded
Because the appcache re-download uses a regular URL, old caching also applies here
If you set a far future header on your appcache file you will get a migraine
And not be able to update your users' sites
Oh and Also
If something is not included in the appcache file it won't be downloaded, even if included as a resource in the HTML
You can get round this, using a header in the appcache
But it will frustrate you if you forget!
Even better if the appcache file changes and any resource in the new file cannot be downloaded, the whole process fails and the old site is rendered
Good Parts
It does work.
Eventually.
Even though your page does render first, a JavaScript updateready
event will fire if new updates are available - so you can at least do something
Using a build tool like Phing can help alter your appcache file for redownloading, and even help ensure all resources served by your page are included
Thanks for Listening
Slides available online
See a demo of offline applications tomorrow night at
@Manc_JS
7th August. TechHub Manchester. 7pm
Useful links: