· Pretty Good Hat · archive · about·

I work out several times a week, and log those workouts to Runkeeper (because data!). Lately I discovered a small bug in the iOS client, in which a previously set equipment type (treadmill) was persistently being sent with my workouts, even though it doesn’t make sense for the workout type (that is, not running). Thing is, the Runkeeper client does not any longer offer the option to set that equipment type for the workouts I’m doing — this is a nice simplification of the interface, but I can’t get rid of the existing flag for treadmill.

This started to nag at me. I’ve long thought about building a workflow to quickly log my sessions rather than tapping through the app, but never got around to seriously looking into it until now. From working with Slogger, I already have an application registered with the Runkeeper API and am reasonably familiar with working with it, but until this weekend had only done so using scripted curl commands. Works great, but does not hook into iOS very well. I could build an ssh command to execute a curl command from a remote server, and kick it off from workflow or maybe a drafts action; this would have taken me ten minutes, but would have felt kludgy.

So on Saturday morning I downloaded Xcode and looked up iOS development tutorials on iTunes U. And there went my weekend.

Approximately one million browser tabs full of google searches, errors and compiles later, I have this: a tiny app preprogrammed with my two regular workout types (strength training and spinning), an array of scheduled session times, both of which I can cycle through via a pair of buttons (starting with my default of 6:15am). I also have a few extra fields to log additional data about the workout. The auth field is for my app’s token, and allows me to change it if necessary. This is a really basic replacement for a more full featured OAuth workflow, and I’m in the process of figuring out how to move this over to a settings screen so it’s out of the way most of the time; for now it’s also a convenient place to output the result of my http request to the API: if after a submission I get a 201 there, then I know the request was completed successfully.

Oh my gosh, Internet, I made an app1! I have to say, that first time it ran approximately like something I intended it to be, I was thrilled, like over the moon that I made something with buttons I could push and interact with on my phone.

So what have I learned?

I learned how to make https requests to an API using Just; how to make buttons and UI elements and hook them to actions in my code; how to use cocoapods (minimally, anyway); how to break my project using source control in Xcode sufficiently to require bringing the whole thing back from Time Machine (thanks, Synology); and how to redraw my content as the keyboard is revealed and hidden.

What get better at, among other things: I have not successfully triggered an activity spinner while my API request goes though. Fortunately it doesn’t take too long, but I want to read up on the asynchronous dispatch or whatever thing. I also really don’t know much about the schemes, targets, and so on that make up a project structure. Should also probably brush up on that little source control issue, and make more sense of the MVC thing. But hey, not bad for a weekend project.

This was fun. I have something I will use almost every day, which does lots more than scratch my original small itch about submitting the wrong equipment type. And I have a much fuller view than I did, of this world of applications that are such a big part of my life. Cool. Maybe next weekend I’ll come up with another itch.


  1. Recent changes in the Apple Developer Program allow for deploying an app to a local device without going through the App Store and its processes and costs. [return]