I’ve split the presentation I gave up into three separate blog posts, which I’ll be putting up over the next few days. This one will cover basic use of the navigator.geolocation API, with the next two showing you how to use the data that gives you to find out where the user actually is, and to plot that data using Google’s static maps API.

To start, I should explain that Beer Near Me was only ever intended to be used as a platform to be used to help me learn about the navigator.geolocation API and how it works. All the data that gets shown by the site was initially kind of secondary to me, as was the map that I use to show it off.

Of course, navigator.geolocation turned out to be far easier to work with than I expected.

Support for navigator.geolocation

The first thing to be aware of is that right now, support for navigator.geolocation is pretty poor. If you’re using Firefox 3.5+ or Mobile Safari you can use it out of the box, and you can turn on geolocation support in Chrome, but apart from that you’re plain out of luck. Since the idea behind Beer Near Me was to learn about navigator.geolocation that means that right now I’m not supporting any other APIs.

It’s not all doom and gloom though. There are implementations of the API available for use in other browsers as plugins – for example Geode will get you support in earlier versions of Firefox 3, and Google Gears opens up the ability to play with geolocation in some other browsers. There’s also Loki (a Skyhook based plugin) that will get you support over a whole bunch of browsers but uses a differently specified API. Of course, I’ve not actually used any of these, so your guess is as good as mine as to whether they are any good or not. I seem to remember Loki looking interesting a couple of years ago.

Finding a location

So, how to actually use navigator.geolocation? Well, a good place to start would be checking whether the browser supports it. We’ll do this in JavaScript, since that’s the only place we can reliably perform the check.

if (navigator.geolocation) {
    // do geolocation
} else {
    // say sorry to the user
}

Pretty simple. It’s your standard JavaScript functionality check. If we have the functionality available then we can actually do something with it.

navigator.geolocation.getCurrentPosition(
    foundLocation, // a user generated function
    noLocation,    // yup, user generated too
    {
        enableHighAccuracy: true,
        maximumAge: 1800,
        timeout: 30
    }
);

Here, we’re calling getCurrentLocation() with two callback functions and some options. Once the browser (and the user) has decided whether or not to return a location, either the foundLocation or noLocation functions that you get to write are called, and the user’s location is passed into them.

Before we get to those callback functions though, lets talk for a minute about the options we’re passing into getCurrentPosition(). Essentially, what we’re saying in the code above is:

Try to give me highly accurate positioning if possible. I’d like to actually know where I am.

Oh, and if you have a position cached that’s no older than 30 minutes, could you give me that immediately please? I know that kind of contradicts what I said a moment ago, but I know better than you.

And one more thing – if it takes you longer than 30 seconds to work out where you are, just give up. There’s a good fellow.

And that’s it really, with that little bit of code we’ve set up the browser to do some magic and try and work out where it is.

Watching for changes to the user’s location

The only problem with this is that the iPhone in particular seems a bit rubbish at following these instructions. The first result it sends back seems to be uniformly Not Good, and generally quite old. So what can we do about that? Thankfully, there’s an easy answer provided to us in the API – the watchPosition() function. This uses exactly the same parameters as getCurrentLocation() and can simply be dropped in as a replacement for it.

watchPosition does what you’d expect it to do. Instead of finding a location once, it will keep watching the user’s location and call the success function whenever the location changes. The thing that watchPosition() is most useful for though, is getting more accurate locations as the user’s device tries different location finding techniques.

You see, different devices will try and locate themselves in different ways. Some of the techniques they’ll use will be be quick, some slow, and some very expensive when it comes to battery life. For example, here’s what the iPhone does, as I understand it:

1. First, the iPhone will look to see if there’s a location cached in its memory and give you that if available.

2. If you’re still watching for new locations, it will then try and grab a general location from the cell towers it knows about.

   Depending on the number of towers available, this might give you really good, or really bad accuracy. For example, in Bedford (where I live), using cell tower triangulation I get an accuracy which basically covers the entire town. Not particularly useful. It is quick though, and doesn’t really cost much in terms of power.

3. If the cell tower triangulation wasn’t awesome then the iPhone will gather information about all the WIFI hotspots it can see.

   This data gets sent to Skyhook, which does a whole bunch of triangulation and sends back a result. This is obviously slower than just hitting the cell towers, but it can give you a really accurate result depending on where you are (better than GPS in some built up areas).

4. Finally, if you’re still looking for a location, the iPhone will fire up the GPS.

   This is expensive, slow, and drains the battery, so is left as a last resort. It generally gives the best quality results though.

So, you see, things aren’t necessarily as simple as asking for a position. A whole bunch of stuff can be going on in the background, and grabbing the best location the user’s device knows about as time goes on can be very useful.

Using the location we’ve found

So, now that we’re requesting a location, what do we do once we actually get one? Lets have a look.

foundLocation = function(position) {
    // position.coords.latitude
    // position.coords.longitude
    // position.coords.accuracy
    // and more…
}

As you can see, the function we call on location finding success gets passed a single parameter – position. This object contains a coords object, and a timestamp representing the time the location was determined. It’s the coords object we’re interested in right now, since that contains the latitude, longitude and accuracy (measured in metres) of the user’s current location – all the information a grown chap could need for finding some beer. Other applications might make use of the altitude, heading and speed information, but that’s not vital when looking for beer, so I’m ignoring it for now.

Putting it all together

Quickly putting all this together, here’s some JavaScript you can copy and paste into a page to see this all in action.

/*global document, navigator */
var beerLocation = {
    foundLocation: function (position) {
        beerLocation.setPara(
            "Lat = " + position.coords.latitude + 
            ", lon = " + position.coords.longitude + 
            ", accuracy = " + position.coords.accuracy + "m");
    },

    noLocation: function () {
        beerLocation.setPara("Boo! You didn't share your location!");
    },

    noGeoLocation: function () {
        beerLocation.setPara(
            "Sorry, but your browser doesn't support geolocation.");
    },

    setPara: function (text) {
        var p = document.getElementById('location-info');
        if (!p) {
            p = document.createElement('p');
            p.id = 'location-info';
            document.body.appendChild(p);
        }

        p.innerHTML = text;
    }
};

if (navigator.geolocation) {
    navigator.geolocation.watchPosition(
        beerLocation.foundLocation, 
        beerLocation.noLocation,
        {
            enableHighAccuracy: true,
            maximumAge: 120000
        }
    );
} else {
    beerLocation.noGeoLocation();
}

Alternatively, take a look at it in situ and in action on my geolocation test page. The location shown by this page will keep updating as you move around or your device’s accuracy improves. For best results, try it out on an iPhone.

And finally

And that’s how easy it is to find a user’s location and keep updating it. You just need to do something with the latitude and longitude once you’ve found it.

In Beer Near Me I do two things with the location once it’s been found – I tell the user the street address of the location, and I display it on a map. And, of course, I’ll be writing about how I’m doing that in the next couple of posts.

A couple of weeks ago, I realised that my public vCard was less useful than it might be. One of the specific reasons that I created it was to make it easy for people to add a bunch of my contact information to their address books when I met them, rather than them having to manually type in a whole load of stuff that was on a business card. It turns out that this is great when that person’s sat at their own computer, but if they’re (for example) using an iPhone then things become a little more difficult.

You see, the iPhone doesn’t like to use MobileSafari to download files. That’s fine in general – you don’t get a filesystem to peruse on the iPhone, so the only way that downloads would be useful is if the iPhone already knows what to do with them. That’s why applications are allowed to register their own custom URL schemes.

Unfortunately, by default the iPhone only registers a few URL schemes for use within web pages – mailto:, tel: and sms: as pseudo protocols, as well as specific URL structures for Google Maps, YouTube and iTunes links. This makes it impossible to do things like adding an address to the Address Book or an event to the Calendar with a single click on a link in a webpage – you just get a message that reads “Download failed. Safari cannot download this file”.

This is clearly a pain. As a phone, it seems reasonable that you should be able to easily add contacts to your Address Book. Unfortunately, either Apple thinks you shouldn’t be able to do this from a webpage or they just didn’t consider it as a usecase.

It turns out that they did consider that you might like to open email attachments though. If someone sends you an email that contains a VCF file then you are able to open it and see its contents. If you then scroll down to the bottom of the file you’re greeted with two options, allowing you to “Create New Contact” or “Add to Existing Contact”. Suddenly a world full of contact adding goodness is opened up to you.

So, what I’ve decided to do with my vCard is a little bit of user agent sniffing in my PHP. Currently I assume that every other device in the world other than the iPhone will do something sensible with the normal VCF file (or the microformatted data that’s on the page itself), so I listen out for the iPhone’s user agent. If I see it then I swap out the link to download the VCF file with one that takes the user to a page containing a form allowing them to enter their email address. Once they do, the VCF file is immediately emailed to them and they can add my card to their address book.

Right now the look and feel of the the email form that iPhone users are directed to could be described as rudimentary at best, but it works. At some point in the future I’ll get round to making it look a bit more pretty.

As a solution, I’m fairly happy with this. Whilst it’s nowhere near as nice as being able to simply click on a link and add a contact to your address book, it does at least mean that it becomes possible to add a contact from a web page. Certainly it’s a better solution than not allowing users access to the content at all. It’s also entirely possible that this solution would work for other filetypes, such as calendar events.

My only concern is that this problem may be in existence in other devices other than the iPhone as well. It would almost certainly make sense to make the email option available to users of other devices as well.

So there you have it – to allow a user to add a contact to their Address Book from a webpage on the iPhone don’t try and get them to download it, let them receive it via email instead.

Not having a connection to the outside world shouldn’t be a blocker to getting work done though. On my commute to and from work I have no internet connection available to my laptop and it really doesn’t stop me from getting anything done. In fact, being disconnected from the cloud actually helps to free my mind and reduce the distractions that so often occur when I am connected.

A few people have asked me what my setup is for working on the train, so here’s a brief rundown of what I have on my laptop:

A Development Environment

For me, this is MAMP, a simple installation LAMP setup for the Mac. I personally currently run MAMP Pro, which costs money but gives me an easy interface for creating Virtual Hosts which I find very handy.

Documentation

Just as important as the development environment is the documentation to go with it. If there’s a language or tool that you use that has documentation available for it then download it – you’ll regret your decision not to if you need it and you’re away from a network connection.

Because I write a lot of PHP and it’s a little inconsistent in its naming conventions I’m constantly in and out of the documentation. I find the PHP Function Index application invaluable on the train, as it makes the PHP documentation searchable and also allows you to download and keep an offline copy of all the user comments from PHP.net.

MarsEdit

Right now I’m working in MarsEdit, the really rather nice blog entry writing tool. It allows me to write entries for multiple blogs, store them locally and sync with the blog servers when I have a network connection. It has built in support for Markdown (which matters to me) and gives a nice preview of your entries as you write them. I really wish it would let me turn on a column to show the “Post Status” of my entries though – it would make finding the half finished things so much easier.

Git

I’ve only just started using git (check out my profile on GitHub), but it’s looking like it should fit my usage nicely. Working on the train means that there are plenty of times when I solve a problem and then want to move on to a new one. With my previous setup of an SVN server on a completely separate machine I couldn’t commit my code before starting the second problem. With git though, I can commit any changes I want locally and then upload them to an external server later at my leisure. Apparently, I can even use git on the train for intermediary commits and then commit back to my normal SVN repository when I get home.

A backup network connection

Of course, there are times when you really do need a network connection and then a phone with a decent data plan really comes in handy. On those occasions though Sod’s Law will apply and you won’t have any signal. When that happens I just sit back, relax and move onto something else.