Debugging GPS-based apps can be troublesome, especially given the unrealistic dataset provided in Simulator. Fortunately, Josh Adams has created a handy tool, GpxLocationManager, to streamline GPS debugging. Josh walks us through how to extract quality location data for debugging, and how to test it using GpxLocationManager.

Easy Development of GPS-Based Apps (0:00)

This talk will cover ways to make developing GPS-based apps easier. For those who have used apps like Uber or any run-tracking app, you may have noticed that functionality these apps share is that they’re able to show your location in space, often on a map. They do this using the Global Position System (GPS) sensor built into every iPhone.

The way a programmer accesses GPS data is via a class called CLLocationManager. Basically, the programmer hands CLLocationManager a delegate, which, if you activate the class, will send location data in the form of CLLocation structs to the app as the user moves around.

CLLocationManagerDelegate

func locationManager(manager: CLLocationManager, didUpdateLocations locations: [CLLocation]) {

    // do stuff with array of CLLocations

}

The CLLocation conveys four points of data: latitude, longitude, elevation, and a time stamp. The time stamp matters because for the purposes of a route, when the user was at each point in space is important.

coordinate.latitude: Double
coordinate latitude: Double
altitude: Double
timestamp: NSDate

Demo: Run Tracking App (1:32)

I have been developing a run tracking app for myself. I noticed that when I just use the GPS sensor in the iPhone, it hard to debug. (I’m not usually running while programming!) Instead, I tried to use the GPS data that’s built into the simulator. There are four sets of pre-baked data to choose from, all sourced from locations around the Apple campus: “Apple”, “City Bicycle Ride”, “City Run”, and “Freeway Drive”.

The first problem I noticed with this built-in data is that there are four sets of it. If I get sick of testing my app around Cupertino, there was nothing I could do about it.

Another problem is that the runner moves very slowly. It’s actually to scale, but if I wanted to have the runner go a mile in my development test cycle, that would take around eight minutes at the default pace. It’s very slow.

The third and final problem I saw was that the elevation data during this Apple campus run was perfectly level, resting at zero elevation. I don’t think Cupertino is at zero elevation – it’d probably be a little bit damper if it were! It turns out this built-in data always gives an elevation of zero feet, and it never ever changes. That was a problem for my app because runners care about elevation increases and decreases, but there’s no way to test that functionality with the built-in data.

GpxLocationManager (4:07)

I wanted a different way to feed GPS data to an app as I was developing it, so I developed GpxLocationManager. I recalled there’s something called a GPX file, which is basically an XML format for location data. I got a GPX file from the run tracking app I use called iSmoothrun, but a lot of GPS-based apps will export similar XML files.

I used some XML data generated from a run around my house. I also implemented a kind of replacement for CLLocationManager that can take any GPX file and use that as data. With that, I can test data for a runner somewhere other than Cupertino, like Berkeley Hills.

With this, I’ve also addressed another problem with the built-in data; I designed GpxLocationManager to allow speed-ups by an arbitrary amount. The user can speed up up to ten times. GpxLocationManager also respects elevation data. In the example available on GitHub, I show a run around my house, complete with elevation increases and decreases.

Here’s the location of the repository and sample app. Thank you!

Next Up: New Features in Realm Obj-C & Swift