While working on iMacistrano (or iWebistrano if you fancy, either way my little iPhone toy project) I started moving things into background tasks and to use timers to fire off requests on a regular basis, specifically to create a deployment, and then to monitor its state.

I used an NSOperationQueue for the former, and initially an NSTimer for the latter. I sent notifications from the NSInvocationOperation object I stuffed into the queue to notify my controller when the event was finished. It doesn't really matter if you're using a notification or using direct method calls, one thing you have to make sure of: When you're updating GUI controls, pushing new controllers or whatnot, for the love of god, make sure you do all these things in the main thread.

I spent several hours trying to find out why on earth my UITextView wouldn't update, but other controls would. I started looking back at the changes that initially caused the problems, and eventually realized that I'm doing tasks in four different threads. Now that can't be good, especially considering that you're supposed to update the GUI from the main thread.

The simple solution is to use performSelectorOnMainThread: whenever you want to do just that. When you're in a different thread (which you will always be when you're using NSTimer, NSThread or NSOperationQueue), just call that method on whatever object you want to do stuff with the UI:

Easy as pie.

In other news, is it 01234567890 yet?

The guys at Y|Factorial put it in a lot of effort in a new framework for Cocoa which mimics the functionality of ActiveResource. It's ingeniusly called ObjectiveResource, and acts as (having a worst Rails plugin names flashback while writing this) a bridge between your Cocoa (yes, that includes iPhone) applications and RESTful Rails applications.

Below are the two versions compared, one using good old ActiveResource, and one using ObjectiveResource.

In ObjectiveResource it's not all that easy due to the nature of Objective-C and multiple declaration of classes, their properties and interface and implementation, it's still easy enough to use.

I played with it for a couple of hours yesterday, and it was really easy to work with. Sure, it still has some quirks, but the code is an easy read. As a matter of fact, you should really have a good look at it, it's well-tested, well-structured and a nice introduction into things you can do with Cocoa without using the UI features.

Nested resources are still sort of a pain though, they're just not as simple as the ActiveResource version, but I'm thinking there might be room for improvements.

Picture 1

Of course I used everyone's favorite deployment tool Webistrano as a base for my playground project, because let's face it, you want to be able to run deployments from the comfort of your seat in the subway, just before you head into a no-reception zone.

The fruits of my labors are available for your forking pleasure on the GitHubs, and basically makes use of the UITableViewControllers which are a real pleasure to work with.

I love it when two communities merge their ideas of simple-enough programming, and stuff like ObjectiveResource pops out at the end. Another sign that learning new programming languages every once in a while will benefit the ways you program in the languages you already know.

ObjectiveResource won't be the only project that brings together ideas from Ruby and Rails with Objective-C and Cocoa, so they set up camp at a new website.