Step 1: Install Ruby

To get SASS setup, you’ll first need to install Ruby and Ruby Gems (SASS is bundled with something called “Compass”, and Compass is a “Gem” that can be added into Ruby). You can go the painful route and install Ruby and then add Gems into it. However, if you’re stupid about these things, you can do what I did and just grab the Ruby 1.92 installer–it comes pre-built with Gems already configured.

Get the Ruby 1.92 Installer

When prompted, choose “”Add Ruby executables to you PATH”

I installed to the default directory on Windows (C:\Ruby192\)

Step 2: Setup Compass

Now that Ruby is installed, the next step is to get Compass (e.g., SASS) setup. This step actually took me the longest, simply because I’m stupid about command-line stuff. So here’s a play-by-play of what to do (this is for Windows…I assume Mac is similar), just in case you suffer from a similar level of stupidity:

• Open a new Command Shell (Start -> Run -> type “cmd”)
• Navigate to your Ruby installation directory (cd/ruby192)
• Type “gem install compass –pre” – if it works, you should see a bunch of text appear about things being installed, configured, and what not.
• BTW, we’re using “–pre” to get a beta version (0.11) of Compass. This is necessary, as the latest non-beta will break when compiling.

Step 3: Done!

You’re done. The next step is to actually start customizing some sassy stylesheets!

Check it out

My idea on this is to use the versioning as a way to push incremental database schema changes in a systematic way.  For example, you could easily define a complex series of schema updates that take the user’s database version (whatever it might be) directly to the most current version.  However, this seems like an undue amount of work to me.  Rather, I think that maintaining a procedural update history of each version makes more sense.

Here’s the idea.  Let’s say that we’re building a blog.  Perhaps version 1 of our database is very simple: just a “posts” table that captures title, content, publishdate, and author.

VERSION 1
posts
      postid
      title
      content
      publishdate
      author

But let’s say in version 2, we add two more tables (comments and categories, for example).

VERSION 1          --->    VERSION 2
posts                      posts
      postid                    postid
      title                     title
      content                   content
      publishdate               publishdate
      author                    author
                           comments
                                commentid
                                content
                                author
                                publishdate
                                postid
                           categories
                                categoryid
                                category

Now our approach is increasing in complexity, for not only do we need to give new users the full version 2 schema, but we also need to upgrade version 1 users to the new schema without destroying their existing data.

But let’s push this out into the future a bit.  Perhaps by version 3, we’ve added a few more tables.  Now we have to give new users the version 3 schema and upgrade BOTH version 2 and potential version 1 users to the new schema, taking into the account the discrepencies between version 1 and 2, and between both 1 and 3 and 2 and 3.

VERSION 1          --->    VERSION 3
posts                      posts
      postid                    postid
      title                     title
      content                   content
      publishdate               publishdate
      author                    author
                           comments
                                commentid
                                content
                                author
                                publishdate
                                postid
                           categories
                                categoryid
                                category
                           tags
                                tagid
                                tag
                           bloginfo
                                title
                                owner
                                tagline

VERSION 2          --->    VERSION 3
posts                      posts
      postid                    postid
      title                     title
      content                   content
      publishdate               publishdate
      author                    author
comments                   comments
      commentid                 commentid
      content                   content
      author                    author
      publishdate               publishdate
      postid                    postid
categories                 categories
      categoryid                categoryid
      category                  category
                           tags
                                tagid
                                tag
                           bloginfo
                                title
                                owner
                                tagline

Oh, and we just realized we need to add an additional column to our original “posts” table, so version 3.1 increases the complexity yet again.

How do we manage this?  Do we write a full complement of schema updates to get each version (1, 2, and 3) to the current version (3.1)?  If we do, this will be a lot of code.  Do we simply write a bunch of clunky “if exists” procedures in our sql to account for gaps in our schemas at any stage in the versioning?  It’s a better solution, but is still lacking, IMO, because it doesn’t really show how the changes are occurring across versions.  If something goes wrong at some point, it’s not immediately obvious where the discrepancy originated.

So my solution is to manage the version updates through incremental upgrades to the newest version by way of any versions in between.  Therefore, if our current version is 3.1, a user with the 1.0 version will be upgraded to 3.1 by first upgrading to 2, then to 3, then to 3.1.  While this requires a bit more effort than the “if exists” SQL-based solution, it provides an immediate version history, providing great introspection into how each version is related to the previous, and to the next.  Let’s look at how this plays out:

First, I create an array representing the complete version history of the database:

this.apphistory    =    ['1.00','2.00','3.00','3.10'];
this.appversion    =    '3.10';

Then, upon each opening of the database, I invoke a custom method “setSchema” which checks the current version of the database against the current “official” version of the database, and handles the incremental updates if needed:

setSchema = function() {
     // set array for holding our sql statements; sql lite can only process one statement at a time
     var sql    = new Array();
     // get history object-- returns current version and whether version is equal to the "official" or current version
     var history = this.getHistory();
     // if client db version is not equal to current appversion, start iterative update
     var ver = history.iscurrent ? this.appversion : history.current;
     if(!history.iscurrent) {
          switch(ver) {
               case '1.00':
                    sql[0]    =    "create table  comments(commentid,content,author,publishdate,postid);";
                    break;
               case '2.00':
                    sql[0]    =    "create table categories(categoryid,category)";
                    sql[1]    =    "create table tags(tagid,tag)";
                    break;
               case '3.00':
                    sql[0]     =   "alter table posts add created";
                    sql[1]    =    "alter table posts add updated";
                    break;
               // default will be a snapshot of the current version of the schema;
               default:
                    sql[0]    =    "create table posts(postid integer primary key  autoincrement,title,publishdate,author,content,created,updated);";
                    sql[1]    =    "create table  comments(commentid,content,author,publishdate,postid);";
                    sql[2]    =    "create table categories(categoryid,category)";
                    sql[3]    =    "create table tags(tagid,tag)";
                    sql[4]    =    "create table bloginfo(name,owner,tagline)";
          }
          this.database.transaction(function (t) {
          for(var i=0;i<sql.length;i++) {
               t.executeSql(sql[i]);
          }
      });
      this.setVersion();
   }
}

What’s basically happening here is that the “default” case will always have what the “official” version of the database should be.  In this case, this is the “3.10″ version of the database.  So if any new users come to the site, they will get the full-on copy of this database written to their client.  If, however, they have a previous version of the database, they don’t need a full upgrade to the 3.1.  Rather, they only need incremental changes to get them to the current database version.  Therefore, if the client has a “2.00″ database version, they will execute SQL statements to get them to the “3.00″ version, and on the next pass of this method, they will get the final incremental change to “3.10.”

And in the future, when additional tables or columns are added/modified, the “default” case can be updated to include the changes, and a case for “3.10″ can be added to manage the incremental change to the newest version.

As I mentioned before, this is perhaps not the prettiest way to manage this.  The thing I like, however, is how explicitly it defines the relationships between the versions.  With a quick glance, we can see what changes are occurring from version to version.  And, because this is an iterative process, we don’t have to worry about updating the “version 2.00″ case to get the client database directly to the newest version (imagine doing that for 50 versions…yikes!). Rather, because the upgrade from 2.00 to 3.00 will ALWAYS be the same, we only have to worry about keeping the newest and most recent versions synched, as this process will take any previous version iteratively through to the official current version.

Enter Web SQL databases.  As the name implies, Web SQL databases are, well, client-based SQL databases (SQL Lite, to be exact) that can be levered through JavaScript.  Each “origin” can have a number of databases, each of which has a unique name and version (more about this later).  If you use something like the Developer Tools in Chrome, you can see these databases in action–including the databases themselves, child tables, and any data that has been added to the tables.

Working with Web SQL

The doorway to creating and using Web SQL databases is the openDatabase() method.  It doesn’t matter if you’re creating a new database, or creating a connection to an existing one: this is the first thing you’ll do, and here’s what it looks like:

this.database = openDatabase('Blog',"",'A Blog to Rule the World',2000000);

The openDatabase() method takes 4 required arguments:

1. Name: Any valid string, including the empty string, is acceptable.  Database names must be unique, however, and should be evaluated in a case-sensitive manner
2. Version: The version of the database to open
3. Display Name: A friendly name that the browser can use (in prompts, etc.)
4. Estimated Size: Each database has a default  maximum size, and users will be prompted to allow this to increase if the data exceeds the default quota.  Specifying a particular value here can avoid this annoyance by telling the browser up front what the total size might eventually be, short-circuiting the otherwise annoying prompts at each incremental increase (e.g., at 5, 10, 15, 20MB…)

Additionally, there is an optional 5th argument– callback method.  This callback method will be invoked if the database is created (not opened), and per the spec should be used to invoke the changeVersion() method to set the appropriate version of the database.  If no callback method is specified, the database will be created with whatever version is specified in the openDatabase() method invocation.

Now that we’ve got an open connection to our database, let’s do some stuff to it!

SQL Transactions

The core of working with your now-open connection is the Web SQL transaction() method.  [There's also the "readTransaction()" method, which allows for read-only access].  This method takes 1-3 arguments, including the following:

1. SQLTransactionCallback: This is required, and is the executeSql method that will actually execute the sql command (more on this later)
2. SQLTransactionCallback: Optional callback method to handle transaction errors.  This method passes both the transaction, and an error object which contains, among other things, a message describing the error
3. SQLVoidCallback: Optional callback method executed upon a successful transaction

A really cool part about the transaction() method is that it provides the ability for rollback.  This is why, in short, the actual execution of the SQL is wrapped in a transaction.  It’s kind of a pain if you don’t care about rollbacks, but if you don’t care about rollbacks, maybe you don’t care about data integrity

Here’s what a transaction might look like:

database.transaction(
     function(t){
        //execute sql here...
     }
);

Executing SQL

Now that we’ve created a transaction() method wrapper, we can actually get down to running some SQL.  This is accomplished by the aptly named executeSQL() method.  This method takes up to 4 arguments:

1. SQLStatement: A valid string representation of the SQL to be executed (this, obviously, is required)
2. Argument Array: An array of arguments to be matched in SQL statement (more about this later)
3. SQLStatementCallback: An optional callback method to be invoked on successful execution of the SQL statement–this method passes the transaction and result set from the query…so it’s pretty important to specify if you want to return data from the database…
4. SQLStatementErrorCallback: An optional callback method to be invoked when the executeSql() method fails–this method passes the transaction and error object

So let’s say we want to create a new table called “posts” with a few columns.  Our full transaction/executeSql() statement might look like this:

database.transaction(
     function(t) {
          t.executeSql("create table posts(postid integer primary key autoincrement,title,publishdate,author,content);";
     }
)

One thing to note, especially relating to schema creation, is that in SQL Lite, only one SQL statement can be executed per request.  So for example, if you’re trying to create multiple tables at one time (like when you’re building the schema for your database), you’ll have to pass the SQL statement for each table creation to an individual executeSql() method.  To streamline this, I simply create an array of SQL statements, and then iterate over them in a loop.  I’m sure there are other fine ways to accomplish this as well, but this works for me.

Preventing SQL Injection

If you’re a web developer, you should always be aware of the possibility of SQL injection, and do all that you can to prevent it.  Because of the way that Web Sql is structured, it’s probably a pretty big temptation to build SQL statements on the fly.  DON’T DO IT. This just opens the door to SQL injection, and because this is all happening in JavaScript, it would not be hard to identify where SQL is being dynamically generated and exploit it.

To help prevent SQL injection, the 2nd argument of the executeSQL() method, the Arguments array, allows you to specify “placeholders” in your SQL that can be substituted at execution time with scrubbed and validated data.  It works like this:

var sql = "insert into posts (title,content,publishdate,author) values (?,?,?,?,?)";
var val = new Array(t,c,p,a);
var executeSql(sql,val);

As you can see, in the actual SQL statement, I used “?” to specify my argument’s placeholders.  Then, I created a new array containing my scrubbed values coming from the client.  Then, I simply passed both to my executeSql method, and it works brilliantly.  Simple.  Of course, since I’m passing an array and not a key/value pair object, the order of the arguments compared to the placeholders is EXTREMELY important.  Just keep that in mind

Finally…Getting Some Data

So far, we’ve seen how to establish a database connection, create transactions, and then execute SQL against the database.  Now let’s talk about what to do with the data once we get it.

If you’ll remember, the executeSql() method provides an optional (although recommended) callback method that returns a results object from the executed SQL.  This object contains the following:

• insertedId:  This is the id of the row that a SQL execution inserted, if any.  If multiple rows were inserted, it returns the id of the last inserted row.  Very handy.
• rowsAffected:  This is the number of rows affected by the SQL execution.
• rows:  An object containing any rows returned from the SQL execution

Once you’ve got the “rows” object to work with, you can retrieve an individual row’s data like so:

var row     = results.rows.item(num);
var title   = row.title;
var author  = row.author;
var content = row.content;

As you can see, each “column” in the row can simply be accessed by its name in the object.  Pretty simple, huh?

So What’s the Point?

As we’ve seen, working with Web SQL databases is pretty straightforward.  If you’re familiar with anonymous functions, and have a good grasp of general SQL, this is easy stuff.   Plus, because it is SQL based, the concepts involved with managing the data and database structure are no big deal, and you can concentrate more on developing the connections, error-handling, etc.

But on a more conceptual level, what’s the point of this?  After all, this is still a client-based solution.  If the user goes nuclear on their client history settings, any databases will be wiped out.  If this data, in that sense, is still so “temporary,” why bother with it?

Obviously, Web SQL databases are not intended to be replacements for server-based solutions.  On some level, data does need to be managed in a controlled, secure, and “permanent” way.  Web SQL is not going to change that.  What it will change, however, is how application development happens.

For example, consider the present situation.  If you’re developing an application that needs to regularly (let’s say once a minute) save data states for your users, the way to do this is through either clunky cookies (blah) or regular server-side hits to save records to a managed database.  While this works, it’s expensive.  Depending on the size of the data and amount of traffic, this could result in thousands and thousands of remote requests hitting every couple seconds.  If you have the hardware to handle this, it’s not a big deal.  But if you don’t, it can take it’s toll.

So what if you could reduce this by a quarter? Or half?  Or a 75%?  Imagine this:  instead of hitting the server every minute to save a data state, you could instead change the schedule to once every 5 minutes.  During those 5 minutes you could still have the same routine running, only in this scenario it would be saving the data state to the client Web SQL database.  Then, after 5 minutes, a protocol could transfer the saved datastates from client to server.  This will be entirely seemless to the user, and will save load on the server by making the requests less frequent.

Or imagine making your applications available offline.  When connected, the client machine could maintain a synchronized set of data with the remote server.  Then, when the client goes offline, they could continue working with the application, utilizing the data from their machine’s synched data from the server.  Then, when they are available to get online again, the client data repository could be resynched with the remote server, pushing any new or modified data.  While the experience between offline and online states would be different in some ways, the very ability to be able to work online and offline in a more or less seamless manner is a radical paradigm shift for web-based applications, and opens up the doors of some very exciting possibilities.

The Demo

Ok, enough of this post.  If you’re interested in learning more, be sure to check out the W3C spec of this.

Also, be sure to check out my demo (use Chrome…).  It’s a simple blog manager that allows you to create, edit and delete posts.  Check it out!!

In HTML5, this becomes a reality. Enter Server-Sent Events. In a nutshell, server-sent events “enable servers to push data to Web pages over HTTP or using dedicated server-push protocols.” This means, basically, that the client doesn’t have to keep asking for information: the server will notify the client when new information is available.

In it’s present state, server-sent events are only available for Opera and Chrome (6) dev releases. Additionally, they are currently implemented in two different ways. For Opera, the technology utilizes a DOM element (), while Chrome is entirely JS based. For this overview, I’ll be concentrating on the Chrome implementation.

For the example I worked up, I’ve created a simple chat interface. The basic idea is that two people share usernames, entering them into their respective client interfaces. When each chat message is sent, the record is saved to a database on the server, and an independent page continues to query the db for new data pertaining to the chat session. If new data exists, it pushes it to the clients’ interfaces.

The Code

So first things first. Let’s create our EventSource, the base object that we’ll utilize to make the magic happen:

serverevent = new EventSource("serversent_helper.cfm");
serverevent.addEventListener('message', onMessageHandler);

This is easy enough to see what’s happening. Basically, I define a new EventSource, and pass to it the server-side page that will manage the pushing of data. Finally, I add a listener to the “onmessage” event of the EventSource, which then in turn calls a user-defined function to do whatever with the data from the server (an event object is passed in the callback method).

That’s it. Seriously, pretty simple. From here, the rest is basically getting the data from the server to be in the proper format to work with the EventSource. And this is where it gets a little murky. Per the spec, the data pushed from the server has to be in a very specific format. To be honest, I spent more time than I’d care to admit on this. But it was a good lesson.

There’s a lot in the spec about this, so I’ll only cover the most important details. This is from serversent_helper.cfm, the source specified in the EventSource invocation:

           writeoutput("data:"&serializejson(message)&chr(10));
           writeoutput("id:"&qmessages.messageid&chr(10));

What I’m not showing you is the queries I used to create and retrieve data from the chat sessions. Assuming that a chat to be pushed exists, this is the code that generates the data pushed to the client.

First, notice the content declaration of “text/event-stream“. This is incredibly important. If your content is not in this format, the push from the server will not work.

Next, notice the output sections. Per the spec, data pushed should be in the following format: “data: [string]“. It is the combination of “data:” and an accompanying string that makes the push work. Without it, nothing will happen. Following the “data:” declaration, I’ve also set “id:”. This is important because you can optionally tag each push with an id which will then be subsequently passed as a header in future interactions between the client and server. Specifically, the header “Last-Event-ID” will be used, so if a connection is lost, the last-used id can be processed when the connection is restored, picking up where it left off.

Finally, notice the newline characters at the end of each line (“chr(10)” in ColdFusion, “\n” in other languages). This is EXTREMELY important because the “field names” of the response are processed on the basis of the newline characters. In this example, if I did not put the newline character after the “data” block, my response would look like {…jsonstring…}id:numeric, rather than just {…jsonstring…}. Additionally, the Last-Event-ID would not get set.

And yes, you can use JSON, so not problems at all pushing complex data objects

Additional Methods and Considerations

I didn’t use these in my demo, but thought I’d point them out anyway. Besides the “onmessage” event, you can also add listeners to the following exposed events from EventSource:

1. onopen – fires when connection between server and client is created
2. onerror – fires when there’s an error in the connection

And in addition to the url and Last-Event-ID, the readyState attribute is available from EventSource. As its name implies, readyState represents the current state of the connection, and can take the following values:

1. CONNECTING = 0
2. OPEN = 1
3. CLOSED = 2

Wrapping Up

As mentioned earlier, because of the relative newness of EventSource, its implementation is severely limited. However, I think it is a pretty cool idea and I can think of lots of potential uses for this, specifically in relation to connection-less data pushing. I’m excited to see how this develops as the spec is more well-defined and more browsers begin to implement it.

A note about the demo. It definitely works, but there are a few things to keep in mind:

1. It will ONLY work with the latest dev version of Chrome (v. 6). If you try it in any other browser, it will be quite disappointing
2. Because it’s just a quick demo, you’ll have to arrange a chat with someone with the same dev version of Chrome, and you’ll have to coordinate the usernames that you’ll use to try it out, given that the chat sessions are based on user-entered names
3. Sure, I could have made a static example…but I thought the chat would show off the tech a bit more…so sue me!!!

As with the other items we’ve been exploring in our look at HTML5-related technologies, Notifications are really easy to work with.  A word of warning, however.  Right now, this is only implemented in Chrome, and the W3C spec is itself based upon a webkit-specific API.  So in order to make these work right now, you have to use the Chromium API, not the W3C spec.  The fundamental principles are precisely the same (since the latter is based on the former), but has some minor differences.

So now for the obligatory example–let’s get my (or someone else’s…) most recent Twitter post and display a notification.

First, let’s create a reference to the Notifications object:

var notification = window.webkitNotifications;

(Notice the “webkit” syntax)

Now that we have a reference to our Notifications interface, let’s handle the entering and submitting of a Twitter username:

function SetNotification() {
     var username = Ext.get('twitterusername').getValue();
     if(username=='') {
          Ext.Msg.alert('Attention!','Please enter a Twitter username');
          return false;
     }
     if(notification.checkPermission()==0) {
          GetTwitterData();
     }
     else {
          notification.requestPermission(PermissionDelegate);
     }
}

A few things to point out here.  First, as part of the spec, the user has to grant permissions to the service to create Notifications.  Before we actually handle the requesting of permissions, we can check if permissions already exist by invoking the checkPermission() method.  This will return three possible values:

1. PERMISSION_ALLOWED = 0;
2. PERMISSION_NOT_ALLOWED = 1;
3. PERMISSION_DENIED = 2;

To me, the numbering is a bit counter-intuitive (0 == allowed?), but it’s easy enough to work with.

So if we’ve already obtained permissions, we simply call our main function for retrieving Twitter data.  If permissions do not exist, however, we invoke the requestPermission() method.  This will create a browser prompt, and the user can either Allow or Deny permissions for Notifications.  requestPermission() takes one argument: a callback function.  This can be invoked to handle post-permission granting/denying.  In this example, the callback is PermissionDelegate():

function PermissionDelegate() {    �
     // if permissions have been granted (checkpermission()==0), proceed; otherwise, show error message and cancel operation�
     if(notification.checkPermission()==0) {
          GetTwitterData();
     }
     else {
          Ext.Msg.alert('Notice','To receive notifications from this application, please grant permissions when prompted.<br /><br />Please try again.');
     }
}

Simple enough.  If the user grants permissions (checkPermission()==0), we continue with the processing.  If not, we display an error message and suggest that the users tries the operation again.

So on with the example.  I won’t bore you with the process of getting the Twitter post.  If you want, you can check the source code, but it boils down to the nifty JSONP hack…

Now that we’ve been granted permission to create Notifications, and finally have the Twitter data, let’s create a notification!

function TweetSuccess(req) {
     if(req.length) {
          var type = Ext.getCmp('radiogroup').getValue().value;
          var img     = req[0].user.profile_image_url;
          var name    = req[0].user.screen_name;
          var tweet    = req[0].text;
          if(type==1) {
               var tweet    = tweet.parseURL().parseUsername().parseHashtag();
               notification.createHTMLNotification("notification_helper.cfm?title="+name+"&img="+img+"&content="+tweet).show();
          }
          else {
               notification.createNotification(img,name,tweet).show();
          }
      }
      else {
           Ext.Msg.alert('Uh-oh','Sorry, that\'s not a valid Twitter username. Please try again!');
           return false;
      }
}

Most of this function is just getting the values from the returned data, so we’ll skip to the important stuff: createNotification() and createHTMLNotification().

Why two methods?  Well, each provides a little bit different way of displaying notifications, of course!

createNotification() creates a standard, vanilla notification that inherits whatever styles the browser has defined for its notifications.  This method takes three arguments:

1. iconUrl – This is the path (absolute) of the icon that you would like displayed in the notification
2. title – Um, the title of the notification
3. body -  The main content to be displayed in the notification.

While this works pretty nicely, I wasn’t thrilled with the look of the notification.  And although I didn’t pursue it very far, I couldn’t get links or any other styling to show up in the notification.

createHTMLNotifications() picks up where createNotification() falls short in the customization department.  Whereas you pass icons, titles, and body content to createNotification(), you simply pass a url to a page that defines your notification content for createHTMLNotifications().  While this creates a bit more work for arranging icons, titles, and body content, it does allow you to be a bit more creative in how the notifications look.  Plus, since it’s an HTML notification, you can use some nifty CSS3, and who doesn’t love that!

Wrapping Up

There’s a bunch more to Notifications that I didn’t cover (like closing them programmatically, etc.), but hopefully this is a nice introduction to the concepts behind what will hopefully be embraced by all browsers in the very near future.  I see a lot of promise to these, and can’t wait until all the environments are more unified to start utilizing them to their full potential.

As always, be sure to check out the demo (remember, Chrome only ) and let me know what you think.

So unless you haven’t visited the web in the last 3 years, you know that location-based services are super-hot right now.  If social networking was the final result of Web 2.0, wiring-in people’s browsers (both position-locked and mobile) to geolocation is easily Web 3.0 and beyond.  For example, with few exceptions, the vast majority of my iPhone apps have some geo-location component.  Whether it’s my RedBox app finding me the closest kiosk, or FourSquare letting me “check in” to new (and not so new) locations, nearly everything I do on the web is able to be tagged with a location.  Every tweet, every Facebook wall post, heck, even this blog post have geolocation data attached to them.  In every possible way, the web is no longer just about “what” you are doing–it’s where you’re doing it as well.

To help make this more of an integrated reality, HTML5 will come fully-loaded with baked-in geolocation support.  As with client-side storage, dealing with the geolocation options is quite easy.

Let’s take a look at a simple example.  In what follows, I simply want to get a snap-shot of my current location and plop a marker of it on a Google map.  With HTML5, this is super easy.

First, we’ll be dealing with the Geolocation object.  This object is basically the wrapper for everything that we’ll be doing, so we’ll start by getting a reference to it:

var geo = navigator.geolocation;

Now there are several methods that are a part of the Geolocation object.  However, the one we’ll be looking at is getCurrentPosition().  As it’s name indicates, getCurrentPosition() is the gateway method for invoking geo-location services in HTML5.  This method takes up to 3 arguments:

1. Success callback method
2. Error handler method
3. PositionOptions

The PositionOptions object, additionally, has 3 parameters that can be defined and passed in getCurrentPosition():

1. enableHighAccuracy (specifies whether highest accuracy search should be used…can affect performance)
2. timeout (how long the process should wait before invoking the PositionError object if Position cannot be retrieved)
3. maximumAge (how old a cached Position object can be used before a new one must be requested)

Putting this all together, our invocation of getCurrentPosition() looks like this:

var get = navigator.geolocation;
geo.getCurrentPosition(GeoSuccess,GeoError,{enableHighAccuracy:false});

Note: if you run the demo of this code, you’ll notice that you’ll be prompted to allow the browser to begin gathering location-based information about you.  This is part of the spec, and is intended to protect user’s privacy.  Given how click-happy most people are, I’m not sure it will accomplish much, but go figure

Now that we’ve invoked getCurrentPosition(), we’ll receive back a new Position object containing all the info we need about the location of the user.  Depending on the implementation, this will include a coords object that provides:

1. longitude
2. latitude
3. altitude
4. accuracy
5. altitudeAccuracy
6. heading
7. speed

For our purposes, only 1, 2, and 4 are important.  One interesting thing to note, however is that “accuracy” provides information on how accurate, in meters, the geo-location was.  In my test, I got an accuracy range of 150 meters–pretty darn good!

With this information, we can now plot our marker on a map.  The rest of the code is really not HTML5 at all–it’s the Google Maps JavaScript API V3…but I thought I’d include it here to show how easy HTML5 and Google Maps make the process of this simple geolocation experiment:

function GeoSuccess(req) {
      var opts = {zoom: 5,mapTypeId:google.maps.MapTypeId.ROADMAP};
      var map = new google.maps.Map(document.getElementById("map_canvas"),opts);
      var loc = new google.maps.LatLng(req.coords.latitude,req.coords.longitude);
      var marker = new google.maps.Marker({position:loc,map:map,title:'Look, Ma, it\'s me!'});
      map.setCenter(loc);
}

Wrapping Up

As you’ve seen in this post, utilizing HTML5′s geolocation services is pretty simple.  There’s much more to it, of course, so be sure to check out the spec.

Also, be sure to check out the demo for this post.  And if you make something cool of your own, let me know about it!

In all fairness, cookies are nice for what they are.  You can store basic information about users and their behaviors on the user’s machine for use on your site, and they are fairly reliable. The problem with them, though, is that they are clunky.  Clunky to set, clunky to expire, and quite limited in terms of storage capability–4000-some characters…lame.

Fortunately, in HTML5, we have a much better option for light-weight client-side storage (like cookies) without the clunky-ness, retarded size limits, and potential “leak” issues.  Actually, we have two

First, let’s talk about the Storage object to which the two options belong.  According to the proposed spec, the Storage object provides access to set, read, and remove “items” which are basically the key/value pairs that everyone is familiar with.  Unlike cookies, however, the key/value pairs do not have an expiration date associated with them, and are removed either by user action or by the cessation of a session.

Enough talk.  Let’s look at the options.

sessionStorage

sessionStorage is an attribute of the Storage object which represents a storage area for each “origin” [read domain].  In other words, sessionStorage is a place you can store stuff for your domain, like user info, favorite colors…whatever.  The unique thing about the sessionStorage attribute, however, is that its lifetime is finite, limited to the current session of the browser.  So, when the session ends (like closing your browser), anything stored in sessionStorage will be purged.  In other words, don’t use it for anything you need to stay around for any period of time!!

localStorage

This one’s simple.  Remember everything I said about sessionStorage?  It’s exactly the same for localStorage, with one major exception: localStorage does not have a finite lifetime.  As long as the user does not deliberately clear the localStorage, its content will persist indefinitely.

Um, okay.  So how do I use them?

Because sessionStorage and localStorage are so similar, they have precisely the same API.  You can access these attributes quite easily with simple JavaScript, and the exposed methods are ridiculously easy to use.

So to get into some code, let’s look at a simple app that will let us enter movie information, comprised of the following data: title, release year, and awesomeness.

To begin, let’s create a shortcut to our storage attribute (localStorage in this example):

<script type="text/javascript">
       var storage = localStorage;
</script>

Pretty crazy hard, huh?  Now I’ll let you build out the form to handle the input of the movie information, but let’s check out a method to handle saving the movie to our localStorage attribute.

<script type="text/javascript">
      function SaveMovie(el) {
           var frm      =    el.form;
          // setup new object to store our movie details
          var movie     =    new Object();
          // add movie details
          movie.title   =    frm.title.value;
          movie.year    =    frm.year.value;
          movie.awesome =    frm.awesome.checked==true ? true : false;
          // get storage object length to see if there are any existing movies
          var inc = storage.length+1;
          // set a key based on increment
          var key = 'movie_'+inc;
          // set storage item with incremented key in case we want more than one movie
          storage.setItem(key,Ext.encode(movie));
          // add movie to our list
      }  �
</script>

The first several lines of this are really just setting up the values that I want to insert into localStorage.  If you look closely, however, you’ll that I’m creating an object to store my movie information.  This is because with localStorage, we have a much larger potential for data storage than we ever did with cookies.  Therefore, I can use JSON-formatted strings if I want to store an object as the “value” of my key/value pair.  This is super nice because I can use a framework (like ExtJS) that handles JSON serialization and deserialization to nicely work with localStorage data as objects, rather than having to rely on clunky string parsing with regex and other nonsense.

Once I have my data object ready, I can invoke the setItem() method of the localStorage attribute to save the movie.  The setItem() method takes two arguments, the name of the key and the value.  Here, I simply passed a dynamically named variable as the key, and my serialized object as the value.

That’s about it.  With setItem(), we can easily add movies to our heart’s content to localStorage.  But how do we get it out?  I’ll show you:

storage.getItem(key);

Pretty simple, right?  And what if you want to remove a move?

storage.removeItem(key);

And what if you want to go nuclear on localStorage?

storage.clear();

Debugging

If you want some awesome debugging of sessionStorage and localStorage, use Chrome.  In the Developer Tools, under “Storage”, you can see any and all key/value pairs that have been saved to either the sessionStorage or localStorage attributes.  Additionally, you can modify and/or remove them in order to nail down exactly the best way to structure your code.  It’s really quite awesome, and I’m looking forward to Firebug hopefully introducing something similar when it’s updated for Firefox 4 and its shiny new tabs.

Wrapping Up

As seen, dealing with the relatively new Storage object and its localStorage and sessionStorage attributes is ridiculously simple.  Once full browser support is provided (it’s pretty wide-spread as it is right now), I think we’ll begin to see a lot of great, slick apps utilize these while the reign of the cookie will begin to dwindle.

If you’d like to check out the full mini-app, see the localStorage demo, as well as the sessionStorage demo.  (Hint: Try closing your browser, and then revisiting after trying each one to see the difference…)

But don’t take my word for it.  Build something of your own, and share your thoughts!