Charting the unknown OS X development territory

January 31, 2007

I’ve posted relatively little over the past few days and generally engaged in relatively few visible “extracurricular” activities. This is because I’m on a mission to teach myself a bit about GUI development on OS X.

As I’ve said before, OS X is a fine machine for a web hacker if you want to develop some web type of stuff. But apart from that, it’s also the world’s finest desktop environment and so I want to learn a bit more about how stuff works and how to build my own.

But why?

I’m actually doing this for two purposes. One, I have some actual stuff that I want to build in OS X. And second, I strongly believe that learning in general is good for you, and learning specifically about different programming and development environments and approaches helps you become a better engineer in general, even if you do not end up using the particular tools. I’ve found that I learn a lot from each new language or environment and can reflect this experience back on the other environments that I’m working with. And if as a byproduct I can produce cool stuff on a Mac, then that’s not so bad either. :)

Dissecting the target

The Mac GUI development environment is pretty easy to get hang of, since the number of choices is far more limited than on Windows. There may be other, more obscure niche solutions, but Xcode is THE way to do things. And inside Xcode, you have a number of choices, but not so much as to get overly confusing.

When building GUI-s for the Mac, you are going to do it in Cocoa and Objective-C. Neither one is necessarily tied to the other. You can do many things with Objective-C apart from building Mac GUI-s, and you can use another language besides Objective-C to develop Cocoa apps. The interface development is not really connected with implementation. For interfaces, you use the Interface Builder tool, and the “engine” in your interface can be in different languages. You could use PyObjC to build stuff in Python, and I definitely plan to check this out at some point.

Or, you can build perfectly usable apps in AppleScript. I was almost going to do this, but AppleScript had some limitations that didn’t suit well with my purposes. One, I didn’t understand how to register timer functions in AppleScript, say, if you need something to run every ten minutes or so. Second and more importantly, there doesn’t seem to be a way of registering a Skype API callback function with pure AppleScript, so that your script would be notified every time there is an event. Plus I’m sure there are big performance implications also when using AppleScript vs the more lowlevel Objective-C. To make things more perverse, you can actually mix languages freely in Xcode, so that you could have parts of your app in AppleScript and others in Objective-C, but to make things more challenging, at this point I’m heading right on to Objective-C.

Parlez-vouz ObjC?

At first glance, it may seem a bit intimidating. Any previous experience helps. For example, I found my previous C experience, as well as Python objects scripting, ancient Pascal work, and PHP all useful. The object basics are the same in all environments. Once you realize that minus and plus in front of the method definitions mean nothing more that the first one is an instance method and the second one is a class method, and that

[f1 setTo: 2 over: 5];

means nothing more than the f1 instance of whatever class is being sent the “setTo:over:” message/method with two parameters, then it all becomes quite fun.

There are some things in the language that I find perverse. What’s with the weird construct of method and variable names? Why not have normal separation like most other languages in the world like “setTo(a = 1, b = 2)”? It kinda feels indeed more “human-language-like” and maybe easier to understand for some, but I’m not among them.

Study method

For grasping the basics, I’m finding the “Programming in Objective-C” by Stephen G. Kochan extremely useful. It covers a mix of subjects, first in ObjC, then some basic C stuff, then ObjC again. I’m the kind of person with “typing memory” and therefore I find it useful to just type and try the examples in the book, even though some of them are pretty obvious. But just to memorize things it helps a lot.

One last major bit remaining is understanding the whole Cocoa UI signaling system and the correct MVC way to architect things. The ideal way of doing things for me is to get to a point where I look at some code/design and it instantly makes sense what goes where and what is connected to whatever else, and if I need to make something of my own, it instantly pops to my head what’s the most appropriate way of doing it. I’m not quite there yet with Mac GUI-s, but I can see the light.

Deathmatch galore

At some point, it would be cool to do a comparison of Xcode/Objc and, say, Visual Basic in MS Visual Studio Express, from a whole application development perspective. There are many criteria and in some, one is better and in others, the other one is. For example, Visual Basic (and other Studio environments too I guess) rock in their editor where they instantly offer you a dropdown of applicable methods to the current object, and the connection between the UI and code somehow feels more naturally coupled. Whereas it’s a horrible experience to plan the deployment and installation of your product, I actually had to resort to third-party tools for this. In Xcode and more generally OS X, the installation problem is not really that existent as most apps are self-contained and the full package is automatically good to go from the moment you write your first line of code.