While I’m ragging on mobile stuff, I should say something productive.
Yesterday, I built “checkin” into my personal site. Today, I tested it. There are things to improve, but that’s fine. It’s an early prototype.
One thing I’ve noticed is that there’s not much in the way of joined up thinking regarding geolocation.
I have an Android smartphone. It has a GPS built in. This is what I used to check into my site earlier.
But I am currently unable to checkin from another mobile device I am carrying with me, namely my laptop.
This thing is beautifully small. It’s the same size as an iPad, but is actually designed for people to do work on, rather than gawp at and dribble. So, why don’t laptop computers have GPSes? Who knows. It’s not like one might want to find one’s location on a map or look up your nearest whatever on some service or the other. It would kind of make sense.
Well, okay, given that we don’t have that, what about interfacing with a GPS in another device? That might work. We have this nice smartphone sitting there, we could use that. How would we talk to that? We could use Bluetooth, I guess. This blog post gives the instructions. But that’s overly nerdy. I have to have a special app on the phone, that uses a protocol I don’t otherwise use (Bluetooth), and relies on using gpsd. gpsd, if you don’t know, is a Unix daemon you leave running which reads the signal coming through the serial port (we can treat Bluetooth is just a fancy way of doing serial port-style communication over radio).
That’s needless overhead. gpsd is useful if you were, say, monitoring the GPS continuously. But for writing something like a little checkin app, you don’t need a continuous connection to the GPS data, just a one-shot call to the device, and have it return a blob of data, preferably in some kind of sane format like JSON or XML rather than a stream of bits that you need to be a GPS freak to grok.
Here’s a better idea. We could use a widely documented protocol to talk between devices and phones: HTTP, and TCP/IP. If you run Android, someone has ported Jetty. We could just write a little Java web app that sits quietly in the background on Android and serves up the things we care about to us over HTTP. We talk to the device anyway: we’re using it to let us get on the Internet through a wifi hotspot.
There’s a bit more that we need though. We need to teach the browser to recognise “ask my phone over HTTP for info on where I am”. According to devmo, this should be a matter of implementing
nsIGeolocationProvider in Firefox. God knows whether that’s even possible in other browsers.
Anyway, I think that this highlights one of the many things that annoys me about current mobile tech: the lack of simple integration between devices. We’ve been so focussed on “apps” (and wasting enormous amounts of time rebuilding pointless, anti-web, AOL-style content silos wrapped in blobs of Java/Objective C code) and on the “cloud” that we’ve forgotten that we have devices that should be able to talk to one another. The computer on my lap should be able to talk to the phone in my pocket easily. We should actually have proper synchronisation between devices without having them have to go and talk to a canonical server in the “cloud”. (Hey, I wouldn’t want to use Subversion again for writing code, why would I want to use the equivalent of Subversion rather than Git for synchronising my stuff between devices?) iTunes achieved this: plugin iPod, wait a few minutes, all your new podcasts and media sync back-and-forth between MP3 player and computer. But we are now failing to make all these device which are marketed as “connected” devices actually connect to one another.
And it’s a shame, because there’s interesting things we could actually build on top of them.