Developer On the Train

Recently, I spent nearly a whole week riding the trains of the Great Western Main Line, writing code to perform location-based unlocking in an environment that let me easily test it. From a developer's perspective, the difficult part of this project is the unlocking, so that's what it is important to get right first of all.

Apple's development APIs offer a few different ways of detecting the user's location. You can set up a geofence, which is like a virtual perimeter wall around a certain location. When the user crosses the wall, the system informs the app in question. Or, the app can ask to be notified whenever the user has made a significant location change — you get notified when they move a reasonable distance, but not more than once every five minutes. Finally, you can request detailed location updates. For these, you get notified about once a second with exactly where the user is (you can specify the level of accuracy required). The latter is the most accurate and detailed, but has the unfortunate side effect of draining the user's battery.

Of the three, it seemed that geofences were what we wanted. At least, they would be, if they worked on trains. I knew from previous testing that geofences had an unfortunate tendency not to fire when the user was on a train. The same was true of significant location changes.

So that just left detailed location updates. “But you said they drain the user's battery!”, I hear you cry. This was indeed a great problem, so we came up with a proposed solution: we set up a geofence around the station where the user gets on the train. When that geofence fires, we turn on the detailed location updates. We leave them on until the next story has been unlocked, then we turn them off again. This plan seemed plausible because the geofences do work when someone walks up to a station on foot, even though they don't seem to work when you're on a train.

This brings me to the point where I was working on the Great Western Main Line. In order to write the functionality required, I needed to be able to iteratively test it as I went along. The easiest way to do that was to write it while on the train, so I could test it immediately.

After a week, the code wasn't finished, but I had shown that various pieces of it could work. The hardest part to get right is still starting things off at the user's point of origin — those geofences are still a bit finicky at times, and if the geofence doesn't fire I'm not given many clues as to why. But I did get to experience stories being unlocked while I travelled: I had an especially nice moment when I was coming back on the last day, having stopped coding, and idly browsing Twitter on my phone. As I crossed the Maidenhead bridge on a High Speed Train bound for Paddington, I got a notification that the story related to that bridge had been unlocked. Experiencing the app as a user will, without expecting when the story was to be unlocked, helped me discover a bit of what a location aware app can feel like when it's done right.

-- Amy Worrall

Top