Location aware services and applications are becoming more important than ever before, as smartphones, tablets, and other fully featured mobile devices become ubiquitous. The W3C Geolocation API gives developers an easy way to integrate client side location aware services within their web pages.

Hello, location aware world!

With the advent of geolocation services and mapping APIs, web sites and applications are popping up daily providing the following types location aware software:

• Games and social applications, (e.g., Foursquare, Twitter, Trip It, Facebook, etc…)
• Search applications for local services (e.g., restaurants, shops, entertainment, etc…)
• Navigation & maps
• Package shipping/tracking & transportation services
• Personal health & fitness
• More…

Notice there’s a good mix of both business and consumer applications that benefit from using geolocation. Fortunately, for developers, location aware web sites and apps are easy to create with web standards like HTML5, JavaScript, and CSS. On top of that, APIs like Bing  or Google Maps make great companions to these sites – and don’t forget 3rd party APIs such as Foursquare or Yelp.

How location aware web sites work

Geolocation apps work by detecting the user’s location via positional data that it receives from a geolocation source.

There are three basic steps to the process:

1. The client browses to a web page that attempts to access the geolocation source.
2. The app requests permission to send access the geolocation source.
3. If the user permits, the app or web site can access and use the user’s positional data. (If not, an error occurs. See below

Once you have obtained the user’s coordinates from the API, you can display maps, give directions,show nearby points of interest

However, keep in mind that the device is the deciding factor regarding the accuracy of the positional data. For example, using a 3G smart phone should yield more accurate results than a desktop machine that connects through an ISP a mile away, using an IP address based method. Devices can use one or more of these methods:

• Coordinate triangulation
• Global Positioning System (GPS)
• Wi-Fi with MAC addresses from RFID, Wi-Fi, and Bluetooth
• IP address
• GSM or CDMA cell phone IDs
• Custom sources: Some phone manufacturers like Nokia

Many smart phones provide a way for users to switch between sources such as 3G or WIFI.

Obtaining the user’s positional data using the HTML5 Geolocation API.

For creating web sites either straight-up JavaScript or jQuery will work fine with the geolocation API. It’s quite small, with only three methods:

Before obtaining the user’s coordinates, a call to Modernizr performs feature detection for geolocation support. If the browser supports geolocation, the code calls the watchPosition() method, and passes success and error callback methods as arguments. Below is the code sample outlining  the call to watchPosition().

$(function () {

    var watchID;

    $("#watch").click(function () {

        if (Modernizr.geolocation) {

            var nav = window.navigator;

            if (nav != null) {

                var geoloc = nav.geolocation;

                watchID = geoloc.watchPosition(successCallback, errorCallback);

            }

        }

        else

        { $("#message").text("You'll need to enter your address manually."); }

    });   

});

.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, “Courier New”, courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }

A successful completion of the watchPosition() method triggers the successCallback() method. At this time, the code can access the positional data returned from the Geolocation service in order to display Bing maps, list nearby attractions, or whatever is required. Below shows code that obtains the user’s coordinates, then displays the latitude and longitude in a web page <div> element (<div id=”message”>). Notice that the position argument  is populated with data, however not all the properties will contain values (e.g., altitude), depending on the capabilities the device and service.

function successCallback(position) {

    var latitude = position.coords.latitude;

    var longitude = position.coords.longitude;

    $("#message").text("There you are at " + latitude + " " + longitude);

}

.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, “Courier New”, courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }

.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, “Courier New”, courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }

Of course, the code won’t always run successfully. There are many things that can get in the way: bad weather, permission denied, timeouts, no cell reception, and gremlins, to name a few.

Dealing with errors and timeouts

The errorCallback() function does what you might expect, it runs when an error occurs. There are three frequently occurring errors to look for when the errorCallback() executes:

1. PERMISSION_DENIED
2. POSITION_UNAVAILABLE 
3. TIMEOUT

A switch statement works nicely to determine the error source and take corrective action, as each case checks value in the error.code property against a set of constants that correspond to error numbers.

function handle_errors(error) {

    switch (error.code) {

        case error.PERMISSION_DENIED: 

            alert("User did not share geolocation data");

            break;

        case error.POSITION_UNAVAILABLE: 

            alert("Could not detect current position");

            break;

        case error.TIMEOUT: 

            alert("Time out");

            break;

        default: 

            alert("Unknown error");

            break;

    }

} 

.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, “Courier New”, courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }

.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, “Courier New”, courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }

Summary

Location aware web sites are becoming more important than ever before, and since the W3C Geolocation API is a standard, it works with any technology ranging from plain HTML to ASP.NET.

To get started creating location aware sites, check out the following resources:

W3C Geolocation Introduction

Geolocation APIs & client side frameworks on Code Project

Before the advent of Web Storage, developers have had to juggle between cookies, session, query strings, and HTML forms to manage data across stateless HTTP requests – with cookies being the only client-side, data storage mechanism. Working with all these different ways to get data from here to there is often tedious at best, but unavoidable, as most web applications do need to preserve state somewhere. At the same time, you also need to consider users who have turned off features like cookies, either knocking both cookies and session objects out of the question or making them harder to work with than they should be.

Enter…HTML5 Web Storage

HTML5 Web Storage, also known as DOM Storage, is a way to preserve state on either the client or server, making it much easier to work with (or should I say against?) stateless nature of HTTP. Web storage gives you, the developer a great deal of flexibility in how you deal with data. In the earlier days of the web, hardware constraints on both the server and client, coupled with low bandwidth, created an environment in which it was much harder to pass data around. Today however, hardware is cheaper, better, and faster, so most of the constraints have been lifted, but the supporting mechanisms to move data around haven’t changed much (e.g., cookies, session, query strings). That is, until the advent and adoption of Web Storage.

Today’s storage issues revolve around these points:

• Having a choice between storage on the server or client between HTTP requests
• The need to deal with larger sets of data, to provide a rich client side experience to users
• Optimize performance and scalability by not forcing data to travel with the HTTP requests, like cookies, form data or query strings.
• Cross browser friendliness

Web Storage helps solve these important issues, as you can add data to either server (session) storage or a local (client memory) storage.

Web Storage Browser Compatibility

As far as cross browser compatibility goes, all the major browsers support Web Storage.

Web Storage size limits

Web Storage also allows you to cram much more into storage than the traditional 4k that you get with cookies. So far, the value is 5MB; however, browsers can implement the limits they’d like. According to the W3C, here’s the official word on Web Storage size limits.

“A mostly arbitrary limit of five megabytes per origin is recommended. Implementation feedback is welcome and will be used to update this suggestion in the future.”

IE allows up to 10MB, as stated here in the DOM Storage documentation on MSDN.

“Storage size is calculated as the total length of all key names and values, and a single storage area can contain up to 10 million bytes. The remainingSpace property is used to determine the available storage space.”

Moving from a mere 4k to more than 5MB gives you far more space to work with than ever before. Of course, you still need to write the code to work with Web Storage.

Working with the Web Storage API

The Web Storage API is a really small and easy to use library to stash data wherever and whenever you need. However, Web Storage isn’t just a huge bag of cookies or over-bloated session variables. Because you can store data locally, without transmitting it back to the server, applications such as these are far easier to write and maintain.

• Wizards, multi-page applications
• Shopping cart data
• Local document storage, for online word processing, spreadsheets, or blogs
• Rich, UI heavy web applications that need to display large amounts of data

Applications like these will also perform much better, as bandwidth needs decrease when the data stays put, and doesn’t travel with the HTTP request, as cookies and form elements do.

There are two ways to deal with data in the Web Storage API:

• Local storage
  • Long term data persistence
  • The local storage object spans multiple windows and persists beyond the current session
  • Values put into localStorage are shared across all windows from the same origin
  • Data is stored on the client. Behaving similarly to cookies, values persist beyond when the browser’s session ends
• Session storage
  • Short term data persistence
  • Once the browser’s session ends (window/tab closed), sessionStorage ends
  • Values put into sessionStorage are only visible in the window/tab that created them
  • Data is stored on the server

Both objects are properties of the browser’s window object, and you can access them by using JavaScript/jQuery. Both local and session storage objects are of type

Implementing a simple hit counter will work with similar syntax between local and session storage, however, it will behave much differently in each. Take for example, the following code that sets a page count in local storage and outputs it to an element with an id of pageCount :

$(function () {

    if (localStorage.pagecount) {

        localStorage.pagecount = Number(localStorage.pagecount) + 1;

    }

    else {

        localStorage.pagecount = 1;

    }

    $("#pageCount").text(localStorage.pagecount)

});

<div id="pageCount">Page Count</div>

The page count will increment each time this page is visited by the same user agent, regardless of whether or not it’s a different tab or  window. Closing and reopening the browser will continue to show data in local storage, as it’s been saved to disk. Session storage, on the other hand, though similar in syntax, will vanish once the user has closed the browser. Below is a sample of the same code, but done with session storage:

$(function () {

    if (sessionStorage.pagecount) {

        sessionStorage.pagecount = Number(sessionStorage.pagecount) + 1;

    }

    else {

        sessionStorage.pagecount = 1;

    }

    $("#pageCount").text(sessionStorage.pagecount)

}); 

Due to JavaScript’s dynamic nature, you can create properties on either local or session storage on the fly, as is the case with the pagecount variable in the previous samples. This gives you a lot of flexibility when determining how and where to work with data. This flexibility does come at a price…

Web Storage and security

Security is important to all aspects of development, as where malicious users can gain access to sensitive information or cause damage. Any time that you involve and store data, an attacker will try to gain access to it.

Web Storage is more public than cookies, and you’ll need to take special precautions to ensure security if Web Storage isn’t compromised by attackers. The W3C provides these guidelines on Web Storage security, quoted here:

7.1 DNS spoofing attacks

Because of the potential for DNS spoofing attacks, one cannot guarantee that a host claiming to be in a certain domain really is from that domain. To mitigate this, pages can use TLS. Pages using TLS can be sure that only the user, software working on behalf of the user, and other pages using TLS that have certificates identifying them as being from the same domain, can access their storage areas.

7.2 Cross-directory attacks

Different authors sharing one host name, for example users hosting content on geocities.com, all share one local storage object. There is no feature to restrict the access by pathname. Authors on shared hosts are therefore recommended to avoid using these features, as it would be trivial for other authors to read the data and overwrite it.

Even if a path-restriction feature was made available, the usual DOM scripting security model would make it trivial to bypass this protection and access the data from any path.

7.3 Implementation risks

The two primary risks when implementing these persistent storage features are letting hostile sites read information from other domains, and letting hostile sites write information that is then read from other domains.

Letting third-party sites read data that is not supposed to be read from their domain causes information leakage, For example, a user’s shopping wishlist on one domain could be used by another domain for targeted advertising; or a user’s work-in-progress confidential documents stored by a word-processing site could be examined by the site of a competing company.

Letting third-party sites write data to the persistent storage of other domains can result in information spoofing, which is equally dangerous. For example, a hostile site could add items to a user’s wishlist; or a hostile site could set a user’s session identifier to a known ID that the hostile site can then use to track the user’s actions on the victim site.

Thus, strictly following the origin model described in this specification is important for user security.

As you can see, there is some thought needed before running off to use Web Storage. Additionally, this article from Network World describes HTML5 security issues in general and including specifics on Web Storage.

Summary

Web Storage has the support of all major browsers while promising to be a versatile technology that allows you to create more robust, data driven, client side sites with little code. However, Web Storage is very new and you need to use it with caution, especially when concerned with security.

MSDN Intro to DOM Storage http://msdn.microsoft.com/en-us/library/cc197062(VS.85).aspx