Join Joe Marini for an in-depth discussion in this video Caching information with local storage, part of Mobile Web Design & Development Fundamentals.
Cookies are also transmitted to and from the server on every request, which bloats the request size and transmits data across the air needlessly, either incurring greater charges for the user or slowing down the experience. Cookies are also not very secure. They're sent as clear text unless your whole site is served as SSL. So those are some of the drawbacks of using cookies and local storage provides solutions to all these problems. First, it provides a much more database-like solution. The values that you want to store are stored per domain, just like cookies are, so other web pages can get at the information that you stored.
Data is stored as sets of key value pairs--again, sort of similar to how you do cookies and definitely the same way as you're probably used to using with associative arrays or objects. There is about 5MB of storage area for each domain to store data in, though currently no browser provides a way to increase that limit. And there is also a nice event model for detecting when changes take place in local storage. So in order to use local storage, you first have to detect if the local storage API is present in the browser.
You can do that one of a variety of ways. You can look for window.localstorage; in this example I am just using Modernizr. Modernizr, which we looked at earlier, is a way for detecting whether features are supported, and in this case I'm just using Modernizr to see if the local storage feature is present, and if it is, I can use that API to store data. Otherwise, there is no local storage, and in that case maybe I was fall back to using cookies. Once you've detected whether local storage is present, you can use it, and the local storage features are accessed from the window.local storage object.
So if you store a number that's a pretty big floating-point number in local storage, each one of those numbers in that data is going to be stored as an individual character; it's not going to be stored as some 4-byte or 8-byte number. So you'll have to cast it back to being a floating-point number when you retrieve it later, because it going to come back as a string. To remove items from local storage and to clear out local storage entirely, you use the removeItem function and you give it a key, and removeItem will remove the data associated with that key. Or you can call the clear function, which will clear out local storage entirely.
You can also just retrieve general information about the local storage area. The localstorage.length property will tell you the number of key value pairs that are currently in storage, and you can also ask for the name of the key that's at index n. So if you want to iterate over all the keys and out what there names are, you can do that using the key function. Finally, let's take a look at handling local storage events. The local storage event object will send events up through the event model as changes happen to it, and the way that you do that is by using the addEventListener function to register a storage event and then give it the name of the function that you want to handle the events that happen on the local storage object. And when an event happens, the storage change handler here--well, that's what I've named it--will get called, and you can see what's going on.
The event object that gets passed into the event handler contains information about the storage change event. So in the event object there'll be these properties. There is key, there is oldValue, newValue, URL, and storageArea. The key is the name of the key that's been changed. It's either being added, it's being removed, or it's being changed in some way. The oldValue is the old value of the key, and if it's being added for the first time, this value will be null, because there is no old value. The newValue is the new value of the key.
The URL is the page that caused the storage area to change and the storageArea object refers to the storage object itself, your local storage or session storage. I didn't cover session storage in this section right here, but it works the same way as local storage does; it's just not saved out to disk. Let's take a look at some code to see how this actually works. So here we are in the code. This is my local storage example, and let me show you what its look in Design view, so you can see what we're going to do. What we're going to do is use this form to store some information locally on the client.
So I'm going to collect First Name, Last Name, and Postal Code and if we go back into the Source, you can see down here that's where the form is right here. And when that button gets clicked, we're going to call a function call storeLocalContent, and it's going to get the values of the first name, last name, and postcode input fields and store them locally. So what I'm going to do is fill out the code up here. To do that I'm going to my snippets file. So what I'm going to do is first copy this line, paste it in. And what this test is doing is seeing if the local storage object is present on the window.
Now I could have used Modernizr for this, but I thought it would be instructive to see how to test for the presence of local storage without using Modernizr. So it tests to see if there is a local storage property in the window object and if the window object's local storage property is not equal to null. So if that test evaluates to true, then we know that local storage is there. So I am going to copy this, and this line of code basically says that if local storage is not supported, then we're just going to replace the contents of the form with a little message that says, "Sorry, your browser doesn't support the storage API." Okay.
And then finally, I will copy the code that actually does the work, or does some of the work. If we load this page up and there is already some content in the local storage area, we're going to restore it into the form. So we're going to check to see it the local storage objects length is not equal to zero, which means there is always some key value pairs in there. And if there is data in there, we're going to get the information out of local storage and put it into the appropriate form field by last name, first, and postal code.
Okay, so let's save, and then I'm going to copy over my two functions for storing and clearing local content, and I'll paste those in right here. And this is the function that we're going to call when the user clicks on the Store Data button. So it is going to store the first, last name, and postal code. Okay, so I'll save, and we'll copy this over to our web server folder.
So let's first try this out in our Windows Phone emulator. So here's our form, and you can see that the contents of the form over there, so that means we support it. So I'm going to go ahead and type in my name. There's Joe, and I'll type in Marini, and my Postal Code is 90121, and now I'll click the Save button, and so now the data has been saved. So now if I were to navigate away from this page and now we go back to it, you can see that the data is being filled in again because the code that detected that there was information already in local storage is filling in the information.
Let's try it one other emulator to see if it works. Let's try it here in Opera, and here is the form. Let's go ahead and try it, and we'll save it, okay, and we'll navigate away from this. All right, and then we'll go back to it, and you can see that information is being filled in correctly. So using local storage, without using cookies, you can save information locally on the user's device in a persistent fashion and reload it as necessary.
- Implementing well-defined web standards
- Working with Modernizr and Mobile Boilerplate
- Building a first mobile web page
- Understanding content adaptation strategies
- Designing forms for mobile
- Detecting client capabilities with script
- Using server-side detection with PHP and ASP.NET
- Working with mobile browser capabilities
- Viewing and testing the mobile site on device emulators