Viewers: in countries Watching now:
In HTML5 First Look, author James Williamson introduces the newest HTML specification, providing a high-level overview of HTML5 in its current state, how it differs from HTML 4, the current level of support in various browsers and mobile devices, and how the specification might evolve in the future. Exercise files accompany the course.
One of the challenges in building web applications is that occasionally your users will be offline, leaving them without a way to access and use the application. Now, that's precisely the thing that the Offline Web Applications section of the HTML5 specification is designed to address. The Offline Web Applications API, or as it's more commonly referred to as Offline Applications, instructs the browser or device to store a version of the application in the user's cache, so that when the user is offline, the application can still be interacted with.
Once that connectivity is restored, you could update information on the server or update the application with any newer data that the user has inputted. Now, for example, you could build a Contacts application that stores the client's contacts, like phone numbers and things like that, in the cloud. If the application was offline, cached versions of the contacts could be accessed and the user could still add new contacts to her list. So once the application goes back online, you could trigger the application to sync up, so that newer contacts are either uploaded or downloaded based upon where they were added.
So here is how it works. Now, any web page that's part of the application should contain a reference to a specific type of file called a cache manifest file. This is what it looks like right here, this code. The cache manifest is a text file that contains references to which application resources should be downloaded as being part of that application. Now, I need to mention here that any server hosting this particular site needs to be able to recognize the manifest mime type. You should add this mime type to your server before building offline applications.
Now, your browser is then going to use the reference to the cache manifest and create an application cache specifically for its resources that's separate from the browser cache. As long as this appcache or application cache exists, any page referencing this cache manifest will be added to its appcache. Now, inside the cache manifest, you'll list any and all resources necessary for the application to function offline. This could be HTML files, images, external scripts or even external styles.
So what's a header? Well, we have three flavors of headers available to us in cache manifest: Cache, Network and Fallback. Let's take a look at a slightly more complex manifest. So here, notice that we're using a couple of headers. The Cache header tells the browser that all resources listed after it are explicit and should be added to the application cache. The Network header creates references to what is known as the online white list. Items listed here are not cached and the device is instructed to bypass references to this resource in the cache and always try to access them online.
Now, there's something really important here about the explicit reference in the cache as well. If it's listed in the Cache header, like these are, essentially you're telling the device or browser "Always use these, don't bother to check to see if they're newer ones." And that means that when people visit your site again, they're going to see the files from their cache instead of what you have on the server, and if you're not updating them all the time, that's fine, but we'll talk a little bit later on how to deal with newer content. Now, let's take a look at a manifest that specifies Fallback content. So here we have a much more complicated cache manifest.
Now, Fallback content, you'll notice that's the last header here that's using the offline image, Fallback content allows you to specify substitute content to use when the user is offline and the resource is not available. In this example, since the update image is not explicitly cached, each time the application loads, it will be requested by the server. Now, if the request fails for whatever reason or if the application is unable to load the resource, it's going to load this Fallback content. In this case, the offline JPEG would be substituted for the update graphic, providing a visual clue to the user that uploading is unavailable when offline.
Now, note that the Fallback content has two parts to it. The resource that you're monitoring to see if it's successful loads or not and in the Fallback content that it should use if that resource is unavailable. Sounds pretty simple, right? It is, and for the most part it's widely supported. As of this recording, a version of all major browsers, other than Internet Explorer, supports offline applications. As you can see, Internet Explorer 9 says it will support offline caching. Now, the caching process itself has a few quirks you need to be aware of. First, if a resource is listed as explicit in the manifest, the cache version is always used.
Remember that. Even if the online connection is working. The server will not check to see if there's a new version of the resource. However, if the contents of the manifest file changes, the browser will prompt a new download and yes, it will download all of the resources again, not just the ones that have changed. So this means that if you change resources on your server, you need to update and change the cache manifest in order to force the cache to store new versions of your resources. Most online examples utilize a comment to track version numbers.
A quick change to the version number inside of a comment is all that's required to force an entirely new download of the application. Now, there's also a few points you need to consider when building offline apps. For the most part, it seems that all browsers are utilizing an opt-in nature to application caching. If you create an offline app, users are going to have to okay the downloading of the resource files before continuing. The specification is really vague about the opt-in nature of application caching. S, this is something to watch closely as the specification matures and best practices evolve.
Also, the offline application interface controls how to specify which resources should be available offline. What those resources do, how they store data, and how they control any syncing operations when connections have been restored is up to your own applications. There are online and offline events that you can capture, but it's up to you to respond to those events within your own application. If you're looking to learn more about offline apps, check out the specification on the W3C site, and you might also want to check out Mark Pilgrim's article on offline applications from his absolutely tremendous online resource, Dive Into HTML.
O'Reilly has posted the chapter on offline apps from its iPhone Apps book online as well, and it's a great resource that features several practical examples. Now, for those of you who really plan on kicking the tires of offline apps, Jonathan Stark has written a script to assist in debugging those apps, which can be notoriously hard to debug. You can find that in his blog archives. Like most of the HTML5 specification, the section on offline applications is designed to help lay the groundwork for the next generation of web applications. By allowing users to access, interact, and use your application when offline, you can add an entirely new type of functionality to your web applications.
There are currently no FAQs about HTML5 First Look.
Access exercise files from a button right under the course name.
Search within course videos and transcripts, and jump right to the results.
Remove icons showing you already watched videos if you want to start over.
Make the video wide, narrow, full-screen, or pop the player out of the page into its own window.
Click on text in the transcript to jump to that spot in the video. As the video plays, the relevant spot in the transcript will be highlighted.