Sinatra + Tokyo Cabinet

SubwayDelay requires a server to communicate with the iPhone application.  Instead of going with the popular Ruby on Rails stack, I decided to use a lighter-weight alternative called Sinatra.  Sinatra is great when you don’t need the overhead of Rails… it’s easy to figure out what’s going on in the framework since the codebase is small, and I’ve successfully used it in several cases where a web service component is needed.  For the user-visible web pages, I used Haml and Sass instead of the usual ERB since I find those DSL implementations a bit more succinct.

More importantly, in this application I was faced with data that would steadily increase in size.  I wanted to make sure that application performance remained constant, without becoming steadily worse as the size of data increased.  With AT&T’s current network woes, the last thing I wanted was to cause users to wait extra time for their app to load because of slow delivery speed of my web stack!

For readers interested in things like computational complexity, this meant that I was looking to make sure that the algorithms would be able to complete in constant time.  In order to achieve this, I realized that a Hash-type data store would come in handy.  I used Tokyo Cabinet with Tokyo Tyrant, which serializes and deserializes small Ruby Hash objects as my application needs them.

The result was an application that was extremely quick to develop, and which should have great scaling properties.

Core Data on iPhone

When I was approximately halfway through developing my iPhone application, which stores user preferences, Apple released iPhone OS 3.0.  Among many improvements to the toolkit was Core Data, a feature which had only been available previously on Mac OS X for desktop computers.  Essentially, Core Data is an Object-Relational Mapping system.  It enables the user to set up a backend data store using sqlite, and helps with flushing changes, selecting objects, and instantiating the correct models for your application.

I realized immediately that it was exactly what I was looking for to handle storing the basic data that I needed to maintain.  I took a step back, realizing that it would probably delay the release by a few days, and dug into the Core Data learning materials on the Apple Developers web site and the sample applications.  In the end, the slight detour was well worth the effort.  I have an application that adheres to the data store that Apple suggests, and the fact that Core Data integrates well into the strict MVC framework on the iPhone was icing on the cake.  I’d recommend a similar approach to anyone currently working on an iPhone application.

Apple Developer Docs and App Submission

As a Ruby developer, I’m used to being able to Google just about any problem that I come across and find a solution on the web.  With the iPhone, this isn’t necessarily the case.  The NDA that Apple had in place during early App development stifled some important discussion.  Now that this has been lifted, the Internet is starting to fill up with more useful information for the iPhone developer.  In particular I’ve been impressed with StackOverflow.com for relevant and helpful exchanges among developers.

There are still substantial deficits in information on the web, though, especially in things like the provisioning process.  It also complicates matters a bit because I believe that Apple has made some very slight changes to their tools, rendering some public web pages obsolete.  What I found in the end is that if you follow the yellow brick road laid out by Apple, things tend to fall into place.  Having trouble getting your keys in place to release the application?  Read the HowTo guide in iTunes Connect a couple of times and nine out of ten times the suggested approach will just work.  Afterwards, maybe there will be some useful information to be gleaned by general Googling, but try to restrain yourself and you may end up fixing things faster by just reading the Apple docs closely.  They really are very well written and comprehensive.

Conclusion

The availability of elegant Web service frameworks like Sinatra, key-value storage systems such as Tokyo Cabinet, and tools such as Core Data in the iPhone development kit can be composed to create flexible and scalable web services that extend to mobile devices, as I found in my recent development of SubwayDelay.  Any other tools that have come in handy for you in building apps using a similar stack?  Let me know in the comments.

Although there are other libraries out there that do some of the same things, I decided to write this library after some careful thought because nothing else really had the right balance of features that I needed in terms of abstraction of the details of new feed detection and conditional GET.  Feedtosis is also lightweight in that it delegates the heavy lifting of actually making HTTP requests and normalizing feeds to the very capable ruby libraries taf2-curb and FeedNormalizer respectively.  In Feedtosis I tried to follow a Unix-like philosophy of building utilities that only solve one particular problem, while allowing composition with other minimal utilities in order to create robust systems.  I hope that you find it useful!  Feel free to forward me any comments, and please post any issues that you have with the library on its GitHub page.

In case you’d like to see the material from the presentation, check out the attached Presentation PDF or Powerpoint.