{"id":831,"date":"2009-08-13T21:53:11","date_gmt":"2009-08-13T21:53:11","guid":{"rendered":"http:\/\/dalelane.co.uk\/blog\/?p=831"},"modified":"2009-08-13T22:14:34","modified_gmt":"2009-08-13T22:14:34","slug":"a-fire-eagle-updater-for-windows-mobile","status":"publish","type":"post","link":"https:\/\/dalelane.co.uk\/blog\/?p=831","title":{"rendered":"A Fire Eagle updater for Windows Mobile"},"content":{"rendered":"

I wrote a Fire Eagle web service<\/a> at Open Hack London<\/a> a few months ago – that gave a nice, mobile-friendly way to share your current location, as stored in Fire Eagle<\/a>.<\/p>\n

Last week, I finally got round to updating my Fire Eagle Guest Pass<\/a> web service to use the newer OAuth 1.0a<\/a>. <\/p>\n

This got me thinking that I haven’t used it very much since writing it in May… because while it let me share where Fire Eagle thinks I am, I didn’t have an easy mobile-friendly way to tell Fire Eagle where I am in the first place! \ud83d\ude42<\/p>\n

So while I had “how to do OAuth” fresh in my mind, I thought I’d start writing a quick mobile Fire Eagle client.<\/p>\n

I wrote it in C# for Windows Mobile. There are a few interesting points in the code that deserve their own blog posts, but first I wanted to quickly show what I’ve got working so far.<\/p>\n

Updating your location<\/strong><\/p>\n

The Fire Eagle API<\/a> provides a variety of ways to update your location<\/a>. <\/p>\n

I’ve tried to use a few of them in my mobile app:<\/p>\n

Uploading the Cell ID of the GSM tower your phone is connected to. <\/p>\n

The accuracy of this is going to be variable, but it has several benefits such as not putting a big drain on the battery and working even when you are indoors.<\/p>\n

Unfortunately, Yahoo!’s database of UK cell ids seems very limited, but even so, it’s a neat approach.
\n

\nUploading the phone’s latitude and longitude taken from a GPS unit. <\/p>\n

It’s the most obvious approach, and probably the most accurate in many cases. <\/p>\n

But it’s a battery hog, and needs you to be outdoors and relatively stationary for it to work.
\n

\nIf all else fails, you can manually enter all, or part, of an address. <\/p>\n

If you know the postcode of where you are, this is a fairly quick and easy way of updating Fire Eagle.
\n

\nYou can even just enter any free text, and let Yahoo’s Geo API<\/a> try and identify the place that you mean.
\n

\nFinally, I’ve also added the ability to grab the location out of the current appointment in your mobile’s calendar. <\/p>\n

Again, this relies on Yahoo’s GeoPlanet stuff to try and parse this into an actual place.<\/p>\n



\nI’ve also embedded my Guest Pass page<\/a> in the app so you can share your location once you’ve updated it. <\/p>\n

Once I’ve figured out how to authenticate with Google App Engine<\/a> from C#, I’ll do this properly from the app rather than embedding a webpage. <\/p>\n

But this will do for now.
\n
<\/a>
\nAuthenticating with OAuth<\/strong><\/p>\n

Since the security threat identified in OAuth last April<\/a>, OAuth providers have got even more cautious, and the updated OAuth protocol is even more burdensome than before. <\/p>\n

It’s clunky, but to authenticate my app (without giving me your Yahoo! username and password) I’ve had to do the following:<\/p>\n

First off, the app needs to send a request to the Yahoo! servers. Tapping on the button kicks this off.
\n

\nThis gets you a token string which needs to be entered into an authorization page on the Fire Eagle website.<\/p>\n

To make this a little easier, the token string is copied into the phone’s clipboard, and a button is displayed to launch the authorization web page in your mobile’s default browser.
\n

\nThe user needs to paste the code into the text box and tap Confirm.
\n

\nThis takes you to a verification web page displaying a verify code. <\/p>\n

The user needs to copy this code.
\n

\nThis code needs to be pasted into the text box. <\/p>\n

The process is then completed by tapping the final “Complete Authentication” button.
\n

\nJob done. <\/p>\n

The user is authenticated, and the tokens are stored so that the user doesn’t have to go through this again.
\n
<\/a>
\nUgh<\/strong><\/p>\n

I know that the password anti-pattern<\/a> is “a bad thing”. Asking for a user’s password on another service isn’t good. <\/p>\n

But how much simpler would this authentication be if I could just show the user a couple of text boxes – one for a username and one for a password? <\/p>\n

Because as user experiences go, this is fairly icky. <\/p>\n

(It was fairly icky to code, as well!)<\/p>\n

I know the GUI needs a little work – what I’ve got is a quick-and-dirty first implementation to get the underlying OAuth client code working. And the GUI could do more to walk the user through it. <\/p>\n

But even so… the user still has to switch from app to web browser, copying a value across, navigate a website, then copy a different value switching back from web browser to app. This is going to be too convoluted for many users. <\/p>\n

Ah well, it was interesting to get to grips with the OAuth 1.0a protocol, and now I’ve got an easy way to update Fire Eagle on the move. <\/p>\n

Download<\/strong><\/p>\n

If you would like a copy, download it here<\/a>.<\/p>\n

A few provisos:<\/p>\n