MacKuba

Photo by Sharyn Morrow (CC)

For the last several weeks, I’ve been learning a lot about ObjectiveC and Cocoa programming. It’s really addictive… I just can’t stop myself sometimes :) I’m reading the “RubyCocoa” book from Pragmatic Programmers and “Cocoa Programming for Mac OS X” by Aaron Hillegass. I also read some online tutorials – on Apple’s site, on Cocoa Dev Central (I love the illustrations there!), or elsewhere (check out my Cocoa bookmarks on Delicious for more).

The more I learn about Cocoa, the more I like it. It does have its problems which annoy me sometimes, but in general, it seems to make programming GUI applications really easy once you learn it. You can do really amazing things by calling just a few methods, and even better – you can create simple applications while not writing ANY CODE at all. So much can be done by connecting things in the Interface Builder, that sometimes you don’t need much more…

Here is a list of some of the things that I like in Cocoa:

• Interface Builder – that’s Apple’s tool for designing application UIs – windows, menus, etc. Once you get used to it, creating a new window full of controls can take just a few minutes. You just drag a window out of the library toolbox, then you drag some controls onto it, set their attributes by (un)selecting some checkboxes, make connections between them and other parts of the application – and that’s it.
• MVC pattern. They’re really serious about it here. In Qt or Swing, MVC was mentioned sometimes, but for me it was rather just another tool that could be used in some specific cases. It’s completely different in Cocoa: it’s the main underlying philosophy of all Cocoa applications, you can’t escape it, whether you like it or not – just like in Rails. You keep your data in the models, display it in the views, and control everything in the controllers – just like it should be. Even the controls are sometimes split into a kind of “view of the view” (cell) and “controller of the view” (control). And this is good. Because it makes it a lot easier to (properly) design the architecture of the application, to decide who manages what and who is responsible for what. I always had problems with this in other GUI frameworks – everything was done in subclasses of window or widget classes, and interconnected in a complex web of relations. Cocoa makes all of this much more clean.
• Bindings. This is a feature that allows linking two properties of two objects together in such a way that changing one automatically updates another. This is extremely useful when you want to connect the values of two controls in order to display the same value in both of them (e.g. a slider and a text field), or the value of a control to a value of a model object. No manual updates, no adding of observers, no notifications, no sending of signals – you just set a few things in the Interface Builder and that’s all. Everything else happens magically behind the scenes. This makes a lot of code that you would have to write in other frameworks unnecessary in Cocoa.As a bonus, you can bind not only to real properties, but also to functions of them, like the average value of all elements in a table (which is automatically recalculated each time any of the elements changes).
• Core Data – Apple’s persistence and data management framework. This is a component that is essential for creating an application with no code at all. You can design your data model in a graphical designer (which basically helps you draw an ERD diagram), and then a standard controller – without any modifications – can take care of managing an array of model objects. Core Data also makes it trivial to save/load data to a XML, binary or SQLite file. It’s more or less Cocoa’s version of ActiveRecord (although less user-friendly – because it’s not Ruby, after all…). (I originally planned to make a small screencast showing how simple it is to create an application with Core Data, but I realized that my recorded voice just sucks, so that description will have to do :)
• Document architecture – a set of classes that make it easy to write applications that operate on some kind of documents. All the code that makes it possible to open new document windows, save/load their data from a file, manage windows and so on, is done for you – you just have to specify how a single document works and how to serialize your data.
• Undo manager – it’s really simple to add undo/redo functionality to the application – you need to provide a reverse function for any operation that you would like to be undoable, and register it in an undo manager each time the operation is run. After that, the manager manages the operation stack for you.
• Built-in controllers, like NSArrayController. That class contains most of the code that you need to manage and display a list of objects. That involves adding and removing objects, sorting them by any field, managing user’s selection, and so on. Of course, you can connect multiple array controllers if you have a hierarchy of model classes. Add to that powerful built-in view classes like NSTableView, and writing an application that lets you display and edit lists of records boils down to mapping table columns to model fields and buttons to controller actions…
• Notifications – it’s easy to communicate using messages sent through a notification center, if you need to connect two objects in two completely different parts of the application. And it’s just as easy to send such notifications outside the application – that way you can monitor everything that happens in the system and cooperate with other applications.
• Wealth of view controls; the Interface Builder’s library contains a lot of controls, some of which I don’t remember seeing in other GUI toolkits – like Image Well (a place into which you can drop an image from another application), token field (a text field which operates on tokens, e.g. email addresses, rather than characters), or rating indicator (which lets user choose a number of stars to indicate how good something is). And a lot of the controls can have several different looks and types – for example, checkbox is a type of button, and rating indicator is just a different kind of a progress bar. This is why I decided to learn Cocoa instead of writing Mac applications in Qt – by taking the lowest common denominator, I lose all the controls that don’t exist anywhere else, and I can’t take advantage of all that diversity.

I’ve read most of the chapters from Aaron Hillegass’s book, and I still feel like I’m barely scratching the surface of the Cocoa framework. I’m sure there’s still a lot of functionality in it that I haven’t even heard about. And there are other frameworks too – Core Animation for adding special effects, various frameworks for using audio and video, for accessing various system services… yeah, there’s still a lot to learn :) But once I start to feel comfortable with Cocoa, I can begin actually writing something useful, and I’ll learn the rest as I go along.

I planned to write another list of things that annoy me in Cocoa here, but the post is already getting too long, so I guess I’ll leave that for the next time…