As far as I know, you cannot program the iPhone with Ruby. However, you can program OS X Cocoa applications with Ruby and, as a learning experience, it’s very helpful.
I am coming to believe that the biggest barrier to learning how to program Cocoa are tutorials that emphasize the toolset rather than providing any context. This is a decades-old complaint of mine with programming tutorials, but that’s a subject of another post.
In the case of my Ruby code, here is the object structure:
Which is about as classic an MVC triad as you can hope for, the only variation from the classic structure being the use of the singleton NSNotificationCenter rather than a strict OO Observer pattern.
Initialization also follows the classic sequence: the “main()” in the case of a Cocoa app is this Ruby code, executed outside of a class definition:
This will set in motion the initialization, which will eventually call back to the function applicationDidFinishLaunching(sender) in the just-created instance of the ApplicationDelegate class:
The applicationDidFinishLaunching(sender) method follows the classic MVC initialization sequence:
- Create the Model
- Create the View
- Pass the Model to the View
- View creates its own Controller
- View passes Model to Controller
I then manipulate the Model (by setting its text) in order to show how things are wired up.
But before we review that, let’s take a look at the View initialization function initWithFrame_model(frame, model)
First, we setup the View itself using all those Cocoa calls. Then we instantiate the Controller, passing the model along (we’ll return to MyController.initWithView_model(self, model) shortly). The last step of MyView initialization is registering a callback for when the model posts notifications. In this case, the parameters to addObserver_selector_name_object_() mean “When the @model sends a notification called ‘MyModelUpdatedNotification’ call the function self.on_model_updated()”:
Very straightforward: this the callback made after the model has been updated. In this case, the View reflects the model’s text attribute. It’s a very simple Model and a very simple View!
This is almost deceptive, in that the most complex aspect of MyModel is the use of the NSNotificationCenter. One hopes that in the real world, there are all sorts of domain objects. In case it’s not obvious, NSNotificationCenter.postNotificationName_object_() is the complement to NSNotificationCenter.addObserver_selector_name_object_() discussed previously.
So we’ve got a simple Model that concerns itself with problem domain and a simple View that concerns itself with output. So now let’s return to the initialization sequence and the Controller, which concerns itself with input.
Here, we see again the specification of a callback for when the Model notifies of changes. In this case, I just made an function that simply logged itself to the console (“Does input care if the text changes? Mmm… Not really…”). Really the only important piece of code here is the attachment of the view’s window‘s callbacks to the MyController. To fill that out, I had to write some simple functions to handle events associated with the window closing and the application terminating.
Easy-peasy, and here is the program running: