Good afternoon everyone. Welcome to session 512, "Using HTML5 Offline Storage." My name is Brady Eidson. I'm an Engineer on the Safari and WebKit team. Today we're going to be talking about data, all sorts of data, data that you as web application developers are all very familiar with.

Things like HTML, JavaScript, and CSS that make up your web applications, also the media, a lot of the images, and other UI and artworks that make our applications feel very modern and very native. And these are types of data that you developed and then served your users from a server. And there's something that you deliver that make up your application. Then there's other type of data that your application creates and relies on. Things like application state, windows sizes, window positions. So when your user returns to the application, they might want things to look the same.

Then speaking of your users, they have preferences, all the little knobs and buttons that you give them to tweak and change the way they use their application. You know a few other types of things about your users. You know they're locale, they're accessibility type settings, some account info, an e-mail web app for example might have some e-mail messages an address book.

It might have some sort of social bookmarking thing and it's getting a little messy. But it gets a lot messier when we think about the all the documents and stuff that your users create using your web applications. And it's just getting crazy how creative a web app can be these days. It feels a little bit like the Wild West out there because you have to wrangle all these data around without some really good supporting technologies.

You've used things like cookies which were designed for talking to a server but you've crammed a little nuggets of data into them and it's kind of worked. And a lot of web developers have turned to plug-ins to make things work a little bit and that has its own host of problems.

And this is all keeping the data local to the browser of course. And then there's the ultimate solution, package up the data, shipped it over the cloud, keep it on a server somewhere. And this makes sense a lot of the time when you want to sync data to the server. But sometimes it's just way overblown, overkill. So we're going to give you a lasso to give you a new tool to wrangle all this data about in much better ways. And we're going to do this using open standards developed by well-respected standard buddies.

You might have heard of this buzz word lately, HTML5. It's a technology of standards that Apple really believes in that makes web apps do some pretty cool things. And one of the great things about HTML5 is every major browser has announced some amount of support for it and all these offline data technologies we're about to talk about are included there.

So Safari specifically, on Mac, on Windows, and on iOS devices supports everything we're going to talk about here today. In addition, to mobile Safari on iOS devices supporting these technologies, UIWebView native applications also support all of these things in iOS 4. So this is Safari on all sorts of types of devices, on Macs, on PCs, and of course the new mobile hotness that runs iOS 4. And there's something very interesting about some of these devices, the laptops, the iPads, iPod touches that they're very portable devices. Users take them all over the place but they don't' always have a network connection. They're not always tethered to the cloud.

So, as web application developers this kind of presents a problem and some of you might be asking yourself, "OK, well, so what can I do without the cloud?" And that's what we're going to learn today. Today we're going to solve three great-- three problems that have been plaguing us for a long time. First, we're going to make our application itself accessible offline, packaging up all the resources that make up the application that you author and served to your users and cut the cloud out of the picture.

Then we're going to talk about a great way to persist simple data. This is something that a lot of you have used cookies and plug-ins for a little nuggets of data and we're just going to build that right into the browser in a very reliable way. And then for the more complex data, we're going to discuss the full on data center in the browser and we'll get to that at the end.

So first let's start at the beginning. We have an application. We need to make it accessible offline. There's a fantastic new standard called the HTML5 application cache and it does that for us. And it makes the entire application accessible offline. All the HTML and JavaScript, CSS, all of the media that makes up the UI. And even though cache is in the name of the spec don't conflate it with the HTTP cache. This is a real persistent, reliable offline store of your application. The browser will remember everything and serve things locally and it won't ever forget it until someone tells it to.

The spec also provides for automated updates of your application. You author the content, put it up on a server, and then the browser handles getting new versions of that application to your users. All you have to do is specify a resource manifest to make this work. A resource manifest is just a text file with the list of URLs. Every URL of every resource in your application has to somehow be accounted for in the manifest file. And we'll go into a little more detail in that in a little bit.

And then there's a little new non-mandatory API. You can completely ignore if you choose but there're some events and things you can listen to, to help you developed your application cache website and perhaps provide a richer user experience if you so choose. So there're two fabulous advantages of using the application cache.

One, I said a couple of times, I'm going to say it again, your app works offline in a persistent reliable way but something is not quite so obvious when you're using the application cache and the browsers remembers every resource that makes up your app, is that of course your app still works online but much faster. When the browser can completely ignore the network and just served local copies of every resource that makes up your application, things are blazing fast. It feels a lot more native.

So how does it work? We're using the application cache. How is our web application loaded in the browser? So, your user visits the URL for your web application and Safari sees that you've specified a manifest file. It already has a copy of all the resources and the manifest. And it just loads the local copies of the resources completely ignores the server.

So your user is already using your application and Safari now in the background without any action from you or your user change the server says, "Hey, is there any a new manifest file? Is there a new update for this application?" And then they'll compare any new manifest the server passes back to the manifest that has already.

And if they are different by one byte, they must be different files, each individual resource is revalidated, all the HTML, JavaScript, CSS media et cetera. And then the next time your user visits the URL for your web application they will be using the new version of it and that's all automatic.

So to show you a demo of how we put a manifest in and make something work offline, I'm going to show you a really cool HTM5 game that a developer out there has made and it really is one of the greatest games of our time. It's pretty cool. I'm sure a lot of you will be very familiar with it. And I'm a big fan T-Spin.

I'm sure you all heard of T-Spin. Of course this is T-Spin. This is a very professional reaching app. It really speaks to the real T-Spin fan because it fetches that when the next televised professional T-Spin match is. It fetches that from a server of T-Spin resources and it lets me know while I'm playing. So this is really cool. This is all pure native web technology. HTML5 standards and it's the same T-Spin you all know and love.

But there's a problem with this app and I'm viewing this from a server and all the time like I take my iPad to the park for example and there's no Wi-Fi there and I just want to play some T-Spin out in nature and have the squirrels watch me play and I can't.

So the application cache is designed to solve this problem. So let's go ahead and see if we can make this better and work offline using the application cache. So I've already gone ahead and made a manifest file for T-Spin here. And this is the list of all the URLs that make up the application.

The manifest file has to start with the phrase cache manifest that both the spec and the browser vendors who participate in writing the spec want to make it very strict and explicit that you are opting in to this application cache manifest because it's changing the loading model of web pages. So one of the explicit things you have to do is start off your manifest file with cache manifest.

The other thing which I'm not going to show you, I've already done on this server, is reconfigure my web server to serve the manifest file with the text/cache-manifest mime type. It's a specific mime type that will be in the slides later. And those two things together tell the web browser, "Hey, this is a savvy web developer using this cool new stuff and I'm going to start showing their app offline." So these are all the resources that are critical to make T-Spin work offline, a lot of JavaScript, a lot of images. And then down here, we have a section called the network section.

Now, this is interesting because sometimes resources don't make sense to be cached offline. This is the thing like the live feed that tells me when the next televised match of T-Spin is. It only ever makes sense to be getting that from the network. So to allow the browser to fetch that URL from the network, I need to list it in the manifest. So I've gone ahead and done that here.

So then there's on one more change we have to do to make application cache work with T-Spin. We have to edit our main HTML file and we have to go ahead and specify the manifest. And now the next time the browser fetches this HTML, it's going to see there's a manifest.

It's going to fetch the manifest file and start turning on the application cache for the application. So now we've done this. I want to go ahead and use my iPad in the park and have the squirrels watch me play. So I'm going to go ahead and demo this on the iPad. Let me go ahead and load Safari here. I'm going to ahead and visit T-Spin.

So this is a normal situation. Wi-Fi is a little fuzzy around here. It's having to download all of these resources like any web application normally does. It's taking a little longer than it was earlier. OK, here we go. So this web-- this developer who made this awesome game gave us an iPad formatted control pad here so that's pretty cool.

This is still taking a lot longer than we planned but it's still progressing and in about 5 seconds I'm going to fall back and show this to you on desktop Safari, four, three, two, one, OK. Let's just go ahead and show this to you on the desktop. OK, so I'm going to go ahead and bring up the T-Spin app here in Safari.

So remember, I've enabled the application cache here. So eventually, I'm going to prove to you that this does work offline. But everything works exactly the same as it use to before and it's pretty cool. We're loading the next match. And actually, that's not what I was expecting to happen. I think I see here the iPad has finished loading so I'm going to back to that. OK. Meanfest, that's exactly what is happening. Thanks for calling that up. And that's why we usually drag and drop code instead of typing it live because that type of thing happens.

OK. So I'm just going to stick with the desktop here. So let's go ahead and refresh and see work on the desktop. This is a little debugging aid I've patched in to those events I described that are non-mandatory. They're optional. And it helps me determine the application-- application cache is actually working. So I'm going to go ahead and start playing it.

And it's working pretty great, except something weird happened. It couldn't find the schedule for the next televised match. So I bet there's probably a problem with the manifest file that caused that to happened. So I'm going to ahead and quit Safari and take a look at my manifest. And down here, so this was the URL for that live feed.

As I've mentioned a couple of times, every URL that our application accesses have to be accounted for in the manifest file somehow. And this includes the URLs that come from the network that we aren't caching offline. I probably have a typo in here. In fact, I'm almost sure I do. So I'm going to go ahead and do something you can only do in the network section and just replace it with an asterisk.

This is telling the application cache mechanism, "Hey, this application uses a lot of online content. I just want to allow it to access the web at will." So I'm going to go ahead and save my manifest file and go back to Safari and load my game, there again. So right now, I'm viewing version 1 of the application.

The version I showed you not 20 seconds ago. But Safari in the background has gone ahead and refetched the manifest and revalidated all the resources. So actually, you can see that there's a missing image here because that was another part that I forgot to specify, resources, refresh. Yeah, I think that it was.

So let's quit Safari one more time. Watch Safari one more time, OK. So now we're on version 3 of the application. My script only called for two versions and there we go. It has refetched the manifest, updated itself said, "OK, that little refresh spinning. I can go ahead and cache that so now it's the displayable." And now that it's allowed any fetch any URL from the network it's gone ahead and got my next televised match up there. So now, this is locally cache in the browser and it will work offline. So to prove that to you here on the desktop, I'm going to-- just to prove this to you.

This is on the different display. I'm going to go ahead and turn off web sharing. So the web server is now completely disabled. I'm going to go ahead and go back to Safari and load it and it works just fined. You can see my little red debug indicator here.

It says, "Hey, I tried to fine the manifest file but I can't because the web server isn't there anymore." So this actually would be working on the iPad just great with the Wi-Fi disabled. It would work out in the park with the squirrels watching me play and that would be pretty cool.

So, I can play T-Spin, one of the most exciting games of our time anywhere.

So the demo is a little rocky, but we did cover all the points I wanted to cover. One of which I only mentioned, didn't show you. You do have to change your server to specify, to serve the file with the correct mime type. Then after you have text file, your list of your URLs you have to go ahead and specify that in your HTML using the manifest attribute on the HTML tag.

Now we did proved to you that resources not in the manifest due fail to load. That little progress spinning down there in the corner and the live feed of the next televised T-Spin match so I can watch the professionals and really tune my game. Now when I made a change in the manifest file on the server side and then refresh that in Safari that is what triggers an update of the application.

So even if you change a resource like an HTML or JavaScript file, you do have to go to the manifest file and change something to force an update. You can use a comment to do that. And that update process, it is automatic. It's in the background. Safari does it just by the mere act of the user visiting the URL. You don't need to worry about it. Your user doesn't need to worry about it. It usually just works. So that's the application cache, a way to store the entire application offline.

Now some of you web developers are murmuring, I can hear some murmurs saying, "Well, that's great now my app works offline but what about all the data it creates? All that data we discuss earlier?" There're a couple of solutions for that. First, we'll talk about how to persist simple data, the little nuggets of data that many web developers are used to using cookies and plug-ins for. And there's a great standard in HTML5 web storage standard which is designed to do just that.

Now on the web storage spec describes a standard interface for storing items of data. And these items of data are simply key/value pairs of data. If you're familiar with cookies which is a key string and a value string, exact same type of thing. If you're familiar with Flash's local storage, exact same type of thing, key/value pairs of data. It has origin-based security. This is the standard security model in the web. It has been for some time.

And recent HTML5 standards have really solidified it. This means that a page served from a domain you control has access to its own set of data and only pages served from the domain you control have access to that set of data and pages from other domains do not. So you and your apps own your data. Now, there's various implementation of this interface.

This simple interface which I'll show you in a moment, if you already know how to program in JavaScript, you already know how to use this interface. There're various implementations of it. Concrete objects that have the same programming model but give you a few different abilities. What implementations am I talking about? The spec itself describes one called SessionStorage. SessionStorage allows different browser tabs or windows to keep completely separate sessions from each other.

So they each have a data store that only that browser tab or window can get to. If some of you who've tried to use cookies for session management and have noticed that your application can't be used twice and at the same time, that's the type of problem that this is intended to resolve-- to solve. But the much more immediate one is the LocalStorage. LocalStorage is a global object that all browser tabs and windows can get at and it's for persistent data.

If you set an item of data on the LocalStorage object it is saved to the user's hard drive within the browser and it will stay there persistently and reliably and it will be there, a day, a week, a month a year from now. So those are both in the spec. If some of you started looking at developing Safari extensions, the Settings and SecureSettings objects in Safari extensions implement the exact same interface. So it really is just a simple JavaScript programming model, the exact same interface that works for a lot of different situations.

So exactly how does it work? I think a common thing is probably your user has a session of using your application and then they're going to quit. So we need to save some information about their session so we can restore it later. So we can do that with LocalStorage and SessionStorage.

Here for example, we're remembering the window location, the coordinate on the screen where the window was-- when the user quit. The way we remember that is by setting the windowLocation property on the LocalStorage object. It's that simple. This is JavaScript programming. You're setting a property on an object except the LocalStorage object has a very unique semantic about it which means the properties persist to disk and they're going to be there later.

So this is something that a user could quit the browser and come back a week later and fire up your web app again and the window location property will be there on the LocalStorage object. So that works for properties, you know the name of beforehand with the dot property notation.

You can use the array, bracket property, access notation in JavaScript if you want for more variable properties. These are just JavaScript objects that are like collections you can iterate over them. So for example, I want to iterate over all of the data items stored in the sessionStorage because we're saving the session out. So I can just go forth and in sessionStorage.

Then for each item, I'm just going to go ahead and move it from sessionStorage to localStorage to save it off. And there's another API, an actual method call on these storage objects that you can use called setItem to do that. And course, there's a removeItem for removing individual items from a storage object and you can just wipe the whole thing out at once if you chose.

So to show you a demo of how easy it is to spice up an already existing app using a little of this LocalStorage magic, I'd like to invite one of the finest T-Spin players I know, up on stage my fellow colleague, Andy Estes, up on the stage to show you how that works.

So, Brady showed us this really great demo of how we can take our web application to make it available offline using the application cache and, you know, the example he use was this really fun game called T-Spin. I've been really enjoying playing this. A childhood favorite game of mine and, you know, now that it's implemented using these great HTML5 web technologies, I've really been having a lot of fun playing it.

And to be honest, you know, things have been getting pretty competitive in the office. Brady and I are really always kind of jousting to see who can get top score in this game. So, you know, one of the nice things that the developer provided for us here is tracking the score.

So you can see that as I played through here, right over here it's updating my score. And, you know, even better, it's tracking my high score. So, you know, Brady and I can play separate matches and we can see who gets the highest score. Now the really nice thing about this high score is that it's persistent.

So if I were to go and, you know, quit out Safari and then decide to come back in later, I can simply go back to the game and sure enough my high score is remembered. So this is really interesting, let's take a look at the code and see how the developer chose to implement this high score tracking. So I'm going to leave Safari and go over to Xcode. And I happened to have access to the JavaScript of this game of course.

So there is an object in this game called "High Score" and this object has a constructor. So when the game starts up this constructor is called and it's initializing a property called "High Score" and it's calling its helper function called retrieveHighScore. Now presumably, retrieveHighScore is reaching out into some sort of persistent data store, where the browser can access and seeing if a high score is there. And if so it's pulling it in and setting this property to that value. And if for whatever reason we get a null we'll just initialize high score to zero.

So, then as we go and play the game, we have additional properties or-- I'm sorry, we have some additional methods on this object that, you know, each time the score is updated, what its going to do is it's going to check to see if that score is higher than the high score and if it is it will first, you know, set the property to that new value and then also call storeHighScore. So storeHighScore is another helper function like retrieveHighScore.

It's going to go and somehow save this value off into persistent storage. So why don't we go and see what retrieve and storeHighScore are doing. Let's switch over another file here. And we see that retrieveHighScore is calling a function called readCookie, and storeHighScore is calling a function called createCookies.

So, ah-ha, we're using cookies. And Brady covered cookies a little bit. You know, cookies obviously work. This game works fine with cookies but there're a couple disadvantages. And you know, the first disadvantage is that it's really kind of the wrong idiom. Cookies are designed to transmit data between user agents and servers but we just saw with the application cache that this application works just fine offline without any access to a server. So, you know, a cookie isn't really appropriate in this case.

And secondly, you know, if we dig in to the implementation of these two functions, we'll see that they're actually pretty complicated. You know, I have to build this particularly formatted string and set it equal to document.cookie. It has to have the key/value pair. It needs to have an expiration date and a path to send it back to the server. You know, I care about the key/value pair, but I don't really care when it expires or what path that sent to him on the server.

But I have to provide these details, otherwise, things just wont' work. And you know, if we look in the read cookie, things are equally complicated. You know, I get the string back from document.cookie that has all the cookies for this domain, you know, I have to tokenize it based on a semi-colon. I have to loop through and try to find my key.

I have to worry about if there's any white space and trim that out. And then finally, and I'll return the substring that represents the value for that key. So this is really complicated. And what I'm trying to do is something really simple. I'm trying to just persist and retrieve a simple key/value pair.

Luckily, LocalStorage provides a really simple way for us to do this effectively. So, let's look at what these routines would like with LocalStorage. So I'll delete this version. And if I can find where my second screen is I'll bring over the LocalStorage version. And, you know, wow, this is a lot simpler. It's the same two functions, retrieveHighScore and storeHighScore. But they're one line functions. I went from maybe 40 lines of JavaScript down to 2 one line functions. As Brady mentioned, you know, I'm just using the JavaScript's programming techniques that you as developers are all quite familiar with.

I have a LocalStorage object. I'm reading a property called High Score of that object. You can either use the dot property notation. You can use the array access notation like I did down here. You can use them interchangeably and either one of them will just work. So we can say that this, you know-- this kind of code matches the complexity of the problem. It's a simple problem and we can use simple code to solve it. But it would be nice if this actually still works. So let's say that-- and let's go back into T-Spin and see if I can actually still play the game.

And sure enough I can. So my high score is reset because I'm not using my cookies anymore. I'm using a local storage property. But we can see it's updating as I'm playing and even better I can quit Safari, I can come back in and yeah, it maintained my high score.

So that's very cool. [Applause] Thanks. [Applause] Another really cool thing about using LocalStorage instead of cookies is that I can use some features of the Web Inspector to get a little more information. So I'm going to pop-up the Web Inspector. Across the top, I have this tab called storage.

And now that I've set a LocalStorage or-- yeah, a local storage property, there's now this new item in this left-hand column called Local Storage. And if I clicked on it, sure enough I see my key/value pair that I set in code and I can inspect its current value.

And you know, even better what I can do, like I said Brady and I been really competitive, I'm really trying to beat him. So, let's see.

Yeah, I don't think he's going to be able to beat that one but don't tell him I did that. Well, alright, back to you Brady.

OK.

Thanks Andy. So I stepped out for a minute I didn't see anything he might have done. He did OK right guys? Great. OK, so simple programming techniques, simple demo. And that's just fantastic. And that's the thing is it really just a straightforward if you know how to program a JavaScript.

What Andy showed is that you can use the LocalStorage object to globally and persistent store data. You can quit the browser, relaunch, the data is still there and it will be there for the future. And he also demonstrated, you know, no matter how you reference the property and his case, I believe those high score using the dot property, access the array bracket notation. Or if you wanted to use the getItem call that is in the LocalStorage API.

It's all the same property and you can just choose how you want to code. So that was web storage, simple stuff, simple data, simple straightforward solution. But now I hear some more murmurs in the audience from some advance web developer saying "OK, I can store the simple stuff. But I need something with a little more oomph.

I've got megabytes of data that I'm wrangling around and it's got structure and it's all this relational data" and well that's what the data center and the browser is about. And by the data center and browser I'm talking about the HTML5 SQL databases spec. The SQL databases spec is about real-world SQL. This is the same structured query language that many of you are familiar with form working on servers, working on infrastructure or from taking databases classes and college.

But it's the real-world SQL. We're moving on around large amounts of data and it might take some time to process on that data. So the API is asynchronous and it is callback-based. Safari will handle all this stuff on a background thread and the way you interact with the database mechanism is by providing some JavaScript callback functions to take care of things when you need to.

Again, like session storage and local storage, it has the same origin base security model that is this standard security model of the web. Pages served from your domain that you own and control but the only ones who can get at your set of databases. So there are some advantages of keeping it local, keeping databases local. One is of course the theme of the talk it works offline. This is a database that is not on some server that we need to go through the cloud to get to.

This is a database accessible on our users' machines in the browser. So this is great in some situations. But I know a lot of you are thinking, "Well, I have this complex structure relational data that I need to store it on the serve-- store it on a server somewhere.

The whole point of my application or my set up is that I sync this data to a server and then I sync it back down to the browser later." Well, you can still use the local database to cache that data locally and to prepare for the eventuality where there is no network connection. And when you do so, you get fantastic benefits along the lines of better performance. When the database is being created locally, fetching results from the rows and tables is just instantaneous.

And then lower latency, we're cutting the network out of the situation, we don't have to travel across the world, we don't have to travel through the airways and Wi-Fi or cellular connections, we just have to travel through our machine to the user's disc. So things are really quick.

And then especially in this portable devices when we're disabling the radios and we're not using this power-hungry broadcast to get at this data because we have a locally cache copy of it, we can improve battery life by quite a bit. Radios are very expensive for batteries. So I'm going to focus on one thing back on the overview slide really quick. And that is, real-world SQL. What do I mean when I say real-world SQL? I absolutely mean everything you think it means.

I mean there's tables of data that you can create and drop at will and there's rows of data you can throw massive amounts of rows at the database and it will handle them and chew them up and I'm sure there's indexes when you know the scheme of your database, you can provide performance hints to make it work faster.

There're definitely triggers you can install so you can make things work and stay consistent as data is dropped and stuff, and you bet there's transactions. Their built into the API. We don't let you forget them. They're so important to performance and consistency that they're the very fundamental construct of the database API. So how does this API work? I'll walk you through it.

Since it's asynchronous, it takes a little bit of walking through the trails. So let's follow the bread crumbs. First, you get a database object to work with. There's a new call on the window object called openDatabase. It takes a few arguments. The only really important one is that first argument the database identifier. In this case, we're referring to the base called "MyDatabase." And that's the unique identifier for the database. If I open the same database again in the future, I'll be getting an access to the same data stored in it.

So when do that openDatabase returns you a database object? There're a couple things you can do with it. But by far, the most important one is start a SQLTransaction. And the way you do that is by calling transaction on the database object. There're a few different flavors of this method but the one that lets you actually do something useful is the one that takes a single callback function.

So starting this transaction, it's going to happen on this background thread, Safari's going to handle all the heavy lifting. And then when the transaction is open and ready to go, that's when your callback function is going to be called. Your callback function is going to take a single argument which is an SQLTransaction object.

And this object is where things happen, where SQL is run. So using this object we can execute some SQL by calling executeSql. And this is just a very simple SQL statement. I'm creating a test table with the test value in it. But this is where my database experience and from JavaScript in the browser begins. So let's go into a little more depth by showing you a demo.

OK, so if any of you have researched the SQL database spec, Google around for it, one thing you might have run across is what has become the canonical example of a web database app that we put together when we first implemented. And that is of course the WebKit Sticky Notes. What better thing to store in a relational database than some sticky notes. So that's what we use as our demo. So we see here I got the sticky note I can drag around. I can put some stuff on it.

I'm on stage mom. So she can see that later and its storing this in the database. Now I can go ahead and quit Safari, relaunch it, go ahead and go back to the same page and have the exact same note there as the same contents and there's actually a lot more data going on in this note behind the scenes that you might not be aware of. First off, it's got the text of course which-- there we go.

But down here, it also has the last modified date. As I move it around, it remembers the position of the sticky note. And then of course, I might want multiple notes and you'll notice that their stacked, they have a Z order that shifts around as I select a new note. So we also remember the Z order.

So take a quick mental snapshot here of how these notes look. I'm going to go ahead and quit Safari, relaunch it, go back to this page and all of that information, the locations and the Z orders relations between them is stored in the database. So it's pretty cool.

Let's go ahead and bring up the Web Inspector. As Andy showed you earlier, it can introspect into local storage pretty well but it also has a great way to look at the databases. So I'm guessing by looking at the Web Inspector here, we called our database Note Test because that's what shows up in the sidebar here.

And the inside of Note Test is a table called "WebKit Sticky Notes." And indeed, these are all the notes that I have on here. It's got the idea of the note, the text of the note, the time stamp, their locations, their Z order. So that's all in the database here. I can even like I have a little command prompt here so I can do some stuff in the database if I want, it has tab completion, helps out.

So the Web Inspector is a great tool to help you use database in your web application. So right now we're looking at the sticky notes that are hosted at webkit.org but I have a local copy on my laptop because I use these all the time. I use these to organize my life because I have a lot of stuff going on and I just need a little help. So I'm going to ahead and bring up my local copy.

Don't try to pry into my personal life too much but this is the type of stuff that's on my plate right now. All the types of things I have to worry about. But what is really different about my local copy is that I got it a search box up here because I have so many sticky notes flying around, it's hard to keep track of everything that's going on in my life sometimes.

So I know I need to search for things like I know I need to go shopping after the WWDC party tonight so I have a shopping list in here. I can go ahead and type a search query, OK. So I just-- "sh" was good enough so I can see my shopping list. This is all just standard web technology here and it made everything I didn't-- I wasn't interested in go away and I brought up my shopping list.

And as you know it by now I'm obsessed with T-spin lately especially with beating Andy because somehow he keeps on putting up amazing scores. So I have a lot of notes about T-spin. I had noticed on my shopping list, I have to buy a strategy guide, I need to make sure to watch that match on TV tomorrow and so that's what I have to do regarding T-spin.

So the search box, this really changed my life. It made using this so much easier. So let's go ahead and see how I implemented that. Since all these are in a database, all I had to do was write a little SQL magic and a little JavaScript to query the database for matches.

So you can see here at the beginning of my method I do a little validation to make sure I'm only performing one search at once and to make sure I reset everything to basic if there is no search query. But then right here, the db.transaction this is where the magic starts happening.

So right here I'm calling transaction on the database object like I showed you on slides and I'm providing my callback function. It could be a function I wrote somewhere else in my code but I went ahead and declared the function inline here, isn't JavaScript great? So in my callback function I get a transaction object. So I go ahead and take that transaction object and execute some SQL.

Let me make the window a little bigger here and executes some SQLs. So this one SQL statement is leveraging the power of the database to look at all the text of all the notes and give me the matches of all the notes that I'm searching for. So when I execute that statement, this is a different form of the function call I didn't show you in the slides.

I provide a callback to get the results out of the database because of course it's useless if we can't get the results out. So in this callback, I'm getting a results object. Now the documentation in the spec and in this Sticky Notes example code, you can see what the results of the object is like.

Basically, I get rows of results here. I can just go ahead and iterate over those rows and look for the property I'm interested in, here it's the ID, and then I have those note objects live, I've already created them from the database already when I first visited the web app so I can go ahead and change some classes on them to pop the matches out and make the non-matches go away. So you know about 20 lines of JavaScript one SQL statement leveraging the power of the database to add a really cool feature to what was already kind of a pretty cool little demo. So that's the WebKit Sticky Notes.

So as I showed you, SQL queries available directly from JavaScript. This is a SQL database and web technology meshed together and we can do some pretty cool stuff with it and I think you can do some pretty cool stuff with it too. We can handle complex relational data in the browser, these sticky notes have enough little nuggets of data about them that trying to store them in local storage or cookies or in a plug-in or wrapping them up and shipping it off to a server just to fetch them again later, probably be a little bit of a pain. So we can store that relation and that structure locally in the browser from JavaScript. And what I didn't actually show you in the demo, but what I've alluded to and I think you can imagine is definitely true.

When it makes sense to cache this data or store it locally offline in our users' machines we get performance superior to the cloud. Things-- modern machines are just so fast that handling the database for one user, piece of cake, no sweat. And we can ignore the network, the latency and work even when there isn't a network, then that's pretty great. So that's everything I had to talk to you about today.

We covered the application cache a standard way to store the resources that make up your application offline so your users can use your web application with no network connection at all. We talked about the web storage spec a way to sort key/value pairs of data in a persistent and reliable manner. And then we talked about the data center and the browser. SQL databases a full relational database available to your JavaScript to your apps.

So for more info, you're welcome to contact Vicki Murley, the Safari Technologies Evangelist. Each of these three technologies, are in three different specs that make up the HTML5 family of technology. So here're the URLs for looking up at those. We'd love to hear form you at the WebKit Open Source Project especially to check out that WebKit Sticky Notes demo. And, of course, the Apple Developer Forums are always available for your needs.