writing my Strava Android app, part 2

More progress...

First, I did more sketch work on my proposed pages for the app. One of these involves data plots: plotting the altitude, and on a separate plot, speed from a Strava activity on a graph. This is the biggest challenge of my GUI design: the rest consists of a text widget, a bunch of button widgets, and some labels, with more simple widgets in the "configuration" screen. Plots with limited pixels are a challenge: I believe the screen resolution is only 480 × 800 for which only a small subset, for example 400 × 100, will be available for each plot. Not so bad, actually, but real estates needs to be used efficiently. I'll avoid doing anything fancy: no scrolling or zooming, for example. The goal is just to identify portions of the ride in a clearly identifiable fashion. For this I can either do my own plots with graphic primitives or use a more general purpose plotting package. I'm not yet decided on this.

Second, I looked into the Strava API itself (it's a work in progress so I resist putting the link here). It's not nearly as bad as I feared. The Strava API consists of specific GET and PUT transactions, using the appropriate URL's, to read and write JSON data to the servers. JSON stands for "JavaScript Object Notation". The advantage of this is it is effectively language-indendent. For example, CPAN has a nice JSON package for Perl, my favorite scripting language. However, I will resist the temptation to do this project in Perl: Java is definitely the way to go. Perl is great for quick-and-dirty projects but for stuff intended for distribution on Android Market I should toe the line and follow best practices, which means Java. (Note: this won't stop me from at some point whipping together a quick script in Perl to export ride data to CSV format, something which I'll find personally useful). Previously I'd been a bit intimidated because the Strava API examples are in Ruby, a language of which I know virtually nothing. But Java should work equally well. The challenge with the API will be writing data: I still need to experiment with that. Worst case is the app will write data to a new activity, then leave it to the user to delete the old one to avoid duplication. But I strongly suspect I'll be able to work out activity deletion or even direct data substitution as well.

Here's an example of what version 1 of the Strava API produces: JSON data of a recent short ride I did. It's fairly straightforward, if inefficient. For example, were I to want to download all data for all crossings of the Golden Gate Bridge for statistical analysis (which would be interesting, to get a statistical distribution of speeds), that would be extremely slow; I'd want a compressed data format like FIT (used by Garmin: a Perl library and a link to the Garmin SDK are here) for that purpose. But for a single ride the rich text format provided by JSON is fine.

As an aside, version 2 of the API claims to allow data to be filtered before download (similar to Garmin "smart sampling"). This should help a lot on the bandwidth hit. But using FIT or similar would probably be at least a 10× improvement.

There is another issue: user authentication. Hopefully this can be handled by the standing Strava app. But I may need to add a log-in page to mine. This isn't something with which I've dealt before.

On the number-crunching side, Java is a fairly simple, sequential language and the sequential array processing should be simple enough.

So things are looking okay. The goal on any programming job is to take complex tasks and break them down into simpler sub-tasks. Then take these sub-tasks, and if necessary, break them down into even simpler sub-tasks. You keep breaking tasks down until the remaining tasks are so simple, the actual coding of them is trivial. It's a lazy shortcut to try to take too much in one bite: to do a complex task directly, and attempting to do so invariably turns the project into a mess. The actual coding part for each sub-task should be simple. The challenge is in organizing the tree of tasks, in knowing exactly what you want to do before you try doing it.