While it seems at times my early progress on my Android/Strava app project has stagnated, really I've gotten a decent amount done.
On the computer side, I had to upgrade the Ubuntu on my Thinkpad T60 from 9.10 to 11.10 to allow for the installation of current packages. This was inhibited by an inability to access my CD drive, but a bit of isopropyl alcohol blown off with a blast of dry compressed air (borrowed from the tech support at work... shh!) on the sensitive bits seemed to fix that. As with my previous Ubuntu upgrade, I lost a lot of packages in the shuffle, even things as fundamental as emacs, but as these omissions are encountered I reinstall them. Things are basically up and running now.
Second, I gave in and ordered a Mac Air. The Thinkpad is in a fairly sorry state at this point, and I really think the Mac will provide a better machine for my needs. I'll get that in another week.
Then education: The Oracle (formerly Sun) Java Tutorial is quite good. I admit it's a bit thick going when contemplating when one chooses static versus dynamic nested classes, or anonymous versus named sub-classes, or how to organize classes and objects. But looking at some Perl code I've written, for example to calculate the rating of climbs based on the profile data, I welcome switching to an object oriented model. It at least offers the promise of enforcing a bit more localization and structure to things. With Perl it's too easy to fall into bad habits.
So to that end, I started "sketching out" the class structure for my application. I've even started coding some of the key methods: as I've noted, the key is to break down complex problems into simpler ones. For example, a key for processing GPS data is to apply reasonable smoothing functions. So I have a class for Strava activities, a sub-class for the ride data, a generic private method for applying smoothing functions, then specific public method for smoothing altitude, speed, and power. Another nested class in the Strava activity class is the header information: for example the "athlete", the date, time, etc. Then a final nested class I use for derived elements. I need to write methods to determine these derived elements, which will be public methods in the derived element nested class.
For the final execution, two candidates are server-side web and Android app. For the Android App, I'm well into Android Application Development for Dummies by Donn Felker. Although it does have the occasional typo to keep a reader on his feet, it's an excellent book, written with the goal of removing the intimidation factor from writing Android apps. Don't make the mistake of assuming the title implies the material is dumbed down: there's plenty of meat there. Right now I'm only slightly intimidated. But I won't really appreciate the task at hand until I dig into the Eclipse development environment used in the book's project and have at it. A mobile phone is not a super-stable or super-friendly platform for computation, so things must be done with a degree of care.
For the server side option, I've been reading Robin Nixon's book in the famous O'Rielly series. This looks like it may well be more benefit in some Low-Key Hillclimb coding I want to do to allow people to access historical results. But that's on the back burner for now. For server-side Java, which I want to use for this project, I'd need a bit more. Certainly if I'm thinking of both phone and web I want to reuse as much code as possible, and that implies using the same language for each, and Java is the obvious choice if the phone is going to be Android. iPhone apps, for example, tend to be built in Objective C (see, for example, iPhone App Development for Dummies, by Neal Goldstein). I've never written in Objective-C, but by all accounts like Java it's a good language, much better than C++, which I really dislike. So I'm still a bit fuzzy on the server-side web option: that's not my focus right now.
On the Java side, Strava uses JSON-formatted data so I've made good progress with the Google GSON library for Java. This seems among the simpler JSON libraries for Java, making it relatively straightforward to both encode and decode the sort of streams Strava uses. I've got the basic GSON examples running (I was hacking on those while listening to the 4th quarter of the superbowl on the radio). Next up is to write a little Java version of my Strava-to-CSV converter to make sure I have that nailed down. One thing I'll say for Perl is it took just a few minutes to dash off that code, while Java with its greater formality is a bit slower going.
So this project has been picking away at the perimeters of the problem. Honestly I'm still a bit worried about whether I'm going to reach my 29 Feb deadline for a working prototype. It'll be fun.