Browser Support
Before delving into any latest technology, you should always perform a quick spike on browser vendor and platform support. Otherwise, you risk writing something that will only benefit a select few users. With respect to Offline Apps, the news is good! According to caniuse.com, all class A browsers and mobile devices support offline applications, with the exception of Internet Explorer 9 (version 10 will support them) and Opera Mini versions 5.0 to 7.0. Firefox and Chrome offer the most support, with Firefox going back 21 versions and Chrome 23! Now, just because a technology enjoys wide support, that doesn't mean that you should just expect it to work the same way everywhere. As with any Web technology, you should test your work on as many browsers and platforms as possible before releasing it to a production environment.
Good Candidates for the Offline Treatment
Sites that make good offline apps offline generally fall into two categories: those that let you manipulate data and those that let you search and retrieve information. Sites that fit the first category include Wikipedia, YouTube, and Twitter. What all those examples have in common is that the lion's share of the work tends to occur on the server and, while there's a large amount of data available, users tend to only use a fraction of it. Data manipulation sites include jsfiddle, JSLint & CSS Lint, and Google Docs. With these sites the processing takes place on the client, in JavaScript code. They offer a limited amount of data, but you can use that data in multiple ways, or create your own data. The latter is what the Application Cache was designed for, although there are ways to work with data lookup and retrieval sites to some extent as well.
The Undependable online and offline Events
You may have heard of the navigator.onLine property. It returns a boolean true or false value that specifies whether the system is in online or offline mode. Firefox 3 took the idea even further by introducing the "online" and "offline" events. These two events are fired on the <body> of each page when the browser switches between online and offline mode, bubbling up from document.body, to the document, and end at the global window object. For this reason, you can register listeners for these events using addEventListener() on the window, document, or document.body. Here's an example that registers a event handler at the document level:
1
2
3
4
5
6
7
8
9
10
11
| if ( window.addEventListener && 'online' in document.body) { window.addEventListener('load', function() { function updateOnlineStatus(event) { alert("I am " + event.type); } document.addEventListener('online', updateOnlineStatus); document.addEventListener('offline', updateOnlineStatus); }}); |
The check for the 'online' property is important because most browsers don't support the online and offline Events. It's also the reason that they aren't dependable triggers for caching resources.
The Manifest File
The use of a Cache Manifest is the simplest way to manage resource caching. It's just a list of files required by your pages. To make use of caching, simply include a link to the manifest file in every page of your application that requires it. No JavaScript required! The only caveats are that the Manifest file must be sent from your web-server with a specific mime-type of "text/cache-manifest" and must contain "CACHE MANIFEST" (without the quotes) on the first line. Rather than configuring web server properties, a lot of developers are choosing to serve the manifest file dynamically using a server-side language such as PHP or .NET. Here's a sample manifest file using PHP:
1
2
3
4
5
6
7
8
| <?header("content-type:text/cache-manifest");echo "CACHE MANIFESTindex.htmlcnet.jsol44s.jsol44s.css";?> |
The recommended file naming convention is "<cache_file_name>.appcache" whereby the "appcache" extension stands for "Application Cache". But that's just a suggestion. Obviously, if you're using a server-side language to generate your manifest file, you should give it the corresponding extension. Here's a link to reference the above PHP-generated cache manifest file:
1
2
3
| <!DOCTYPE HTML><html manifest="./cache_manifest.php">... |
Updating the Cache Manifest
Once a page has been cached, the browser will continue to fetch it from the AppCache, even after you're back online! The browser will only look for updates to files listed in the manifest if the manifest file itself has changed since the browser last checked. When a cache manifest is reviewed by the browser, it uses a complete byte-wise comparison so that any change that makes the manifest different will work - including comments. As such, we can use a version comment to indicate change even when the file list has not changed so that the browser refreshes all of the files with the latest server copies:
1
2
3
4
5
| <?header("content-type:text/cache-manifest");echo "CACHE MANIFEST# refresh files from server:# Cache Manifest Version: 1.3 |
Conclusion
In today's article, we saw how to keep our Web applications going even when the network is unavailable using the application cache. Next time, we'll construct a sample app that includes a cache manifest that demonstrates the AppCache in action.
No comments:
Post a Comment
Thanks for comment me