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.
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.