My wife, Lori, and I have been using Listable, both on our iPhone devices and on the Web for the last month, and we have lists of groceries, tasks, movies that we want to watch, and wines that we like. It has been helpful for both Lori and I professionally, as I found out that Lori had been keeping a list of things that needed to be done on her dissertation, and I used it to keep track of bugs that needed to be fixed in Listable.

In our personal lives, it has been helpful as well, as Lori and I are keeping a list of possible baby names for our first, a girl, due on December 30th.  Names we like more get re-arranged to the top, and we mark as “completed” names that we’ve considered and discarded.  Maybe we’ll even share that list with our daughter when she’s old enough to appreciate the collaborative process that went into giving her a name!

We use the Listable web site, listableapp.com, to manage lists when we’re on our computers, and the iPhone app when we’re not at home.  The iPhone app includes push notifications so that you know immediately when a collaborator makes a change to one of your lists.

Listable for the iPhone is a free download in the App Store.

Have you tried Listable?  Let me know what you think in the comments!

This release makes SubwayDelay the only iPhone application to integrate both service alerts and scheduled advisory information available in an easy-to-read format for NYC subway riders.

More information is available at SubwayDelay.com.

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.