A few years ago I was interested in location-aware phone apps, and experimented with that sort of thing using my Blackberry Bold 9000. I didn’t know what I wanted to make. But it was going to be awesome.

The 9000 was notable because it was one of the very few Blackberries that supported satellite GPS, as opposed to the cell-tower-only type. I don’t remember all the apps I spent time with, but one I found useful was InstaMapper, which recorded GPS fixes at a fixed interval, and then uploaded them to the company’s server. I have not checked their services lately but in 2010 they were one of the best, and free. Their website had a map view of a device’s track, and an API was provided for pulling the data out myself.

That was fun, and I had all the usual sort of optimistic visions about doing “something cool” with the tech, and eventually “making money”. Well, there were at least a couple problems that I can recall.

One, InstaMapper was in control of the data.

Two, InstaMapper used the network to move GPS fixes to a server instead of storing them locally on the phone. This meant that the device needed to keep Internet connectivity and also drank a whole lot of battery. After a week or two of recording myself for fun, I simply had to give up because the phone always needed charging. I should add that the 9000’s battery life was incredible, especially compared to my current Android. That 9000 could go for two days with regular use and maximum screen brightness.

A few weeks later a friend invited me on a long weekend hiking trip. We would be gone all three days, and the park was remote so there was little hope of finding a cell connection anywhere, let alone a consistent usable 3G signal.

I knew Java 6 well enough, but Blackberry OS (4.6 at the time, and 5.0 shortly after) was not a full JRE. It was probably close to Java 4, but was stripped down even further. Not only were there no generics, but many classes were simply not included.

Anyhow, I got more or less familiar with the Eclipse plugin that Blackberry provided for development, the Vector class, and looking up replacement source for any missing classes. I sat down the evening before the trip and got a minimalist app together that logged GPS fixes with elevation to a CSV file, and retried if the GPS signal was ever lost. The GUI updated to show the latest record.

I had a phone, and I had an offline GPS app. The question that remained was battery life. I had no spare batteries so a single charge would have to get me through almost 72 hours of recording. The battery consumption of frequent SD card access was unknown, and so was the consumption of offline GPS analysis.

Anyhow, the trip began as planned early the next morning, and I topped off the battery overnight and then disabled 3G and WiFi, turned screen brightness to minimum, and did my best to reduce the load on the battery. To account for any amount of power drain, I had written the app to allow for a range of intervals between fixes, from every 5 seconds to every 60 seconds.

As it turned out, my paranoia was unfounded. Mid-way through the first day, with the app set to record at the longest interval, I checked the phone and was happily shocked to find that the phone was still at 90%+ life. I set the app on the 5-second interval and continued hiking, reassured that the entire trip could be recorded.

The lesson was that cell connections drain battery, not GPS, and not SD card access.

After getting home the next Monday night, I pulled the CSV file off the phone and inspected it. Unfortunately the majority of the first day was recorded at 60-second intervals and the segments were long, but the remainder was crisp and accurate.

Since moving away from Blackberry to Android, I have not had to port my app thanks to Google’s My Tracks app (UPDATE Oct 2016: My Tracks has been deprecated). It provides offline GPS logging and even has an in-app map display as well as charts and stats. I am still proud of building that solution to the problem before a hard deadline, and that it was successful.