The development of Six to Eight

For the last couple of months, my spare time “relaxation” programming has been the development of an iPhone app for the Stack Exchange platform. For those not in the know, Stack Exchange is an expert community presented as a Q & A site. Users gather reputation for asking and answering questions. Examples you might know are Stack Overflow and Super User – though with the advent of Area 51, they’re adding new sites at a fair clip.

They’ve recently release a JSON based API for accessing their sites, and as an avid Stack Overflow user and Apple fan, I’ve wanted a pocket client for ages. Thus, Six to Eight was born. It’s my first “Release quality” iOS development, and I thought some people might like to know how it went – both other Stack Exchange API users, and other iPhone developers.

I set out to provide a good quality application. One that felt at home on my iPhone, was useful, and provided a good foundation on which I can build in the future. As such, I focused on 4 key developmental areas:

Core functionality: It might seem obvious, but way too many apps are little more than web browsers without a decent set of browser controls. With Six to Eight, the two key ideas are “Your Stack Exchange, in your pocket” and “Your Stack Exchange user, in your pocket”. I’ve tried to design an app that provides those things in a fast and iPhone consistent experience. Everything should feel like it belongs on the iPhone – iOS like UI idioms, user input via taps, most input data being derived automatically. Users also expect a certain level of polish, which I hope I’ve delivered.

Network error handling and recovery: Coding for the iPhone, you’ve got to be ready to handle, at any time, the loss of network connectivity or the degradation of network performance to that of a 14.4k modem. Just finished parts 1 and 2 of a critical 3 part request? You can bet on a decent number of your users losing their connection just then. Six to Eight underwent a lot of testing to ensure it remaines usable even on a GPRS connection, handles network drops gracefully, and reports them to the user as best it can.

Asynchronous UI: Blocking your UI whilst you wait for data is a cardinal sin. It makes your app feel unresponsive, and renders it unusable on a slow connection. Six to Eight performs all data collection and processing in the background, streaming it into the UI as it arrives. This way, you get to see what’s been downloaded so far, without waiting for every request to complete. You can also cancel any request you’re bored of waiting for.

State preservation: iPhone apps are often asked to quit with no notice, for inbound phone calls or because the user pressed “Home”. I tried to ensure that whenever you quit, both data and UI state are persisted so you reload back to the same state you left from.

Six to Eight is approximately 14,000 lines of code. Of course, this measure by itself is useless – but how much of this code is devoted to each part of the application is, to me, interesting. The following percentages are just my estimates based on how much time each feature took and the rough code footprint, as one can’t easily untangle the mix of the above ideas.

Core functionality: 40%. Less than half the program is needed to provide the functionality I wanted. This includes talking to the Stack Exchange API, processing the data, presenting it in the UI and responding the UI events. If I was programming for a desktop machine with a guaranteed fast network connection, I could have basically stopped here at around 5000 lines.

Error handling and recovery: 10%. This includes propagating errors around the system, presenting them to the user, and designing the UI so it can present partial data where missing data is in an error state.

Asynchronous UI: 25%. This includes designing the UI as a state machine that can present data incrementally no matter what order it arrives in, as well as the concurrent download and processing of data from the Stack Exchange API.

State preservation: 25%. This includes the ability to serialise and de-serialise all forms of Stack Exchange data and the state of each view within the UI.

In my next post, I’ll talk about one part of the core functionality I rather like, from both the Stack Exchange API and iPhone development perspectives.

Comments are closed.