I have been learning Objective-C part-time. Partly to learn something new and different but also partly out of curiosity. As a Java programmer, I initially thought it would be a doddle but as soon as I looked at the code I realised it was going to take a bit of getting used to. After going through Apple’s excellent, yet verbose, guide: The Objective-C 2.0 Programming Language – I started to get used to the syntax. Its not that hard, especially if you come from a C or Java background. Here are some of the differences and some of the highlights I have encountered so far.
1. Methods, Functions, Messaging
The most difficult thing to get used to initially is the syntax for calling methods, or as its called in Objective-C: messaging. In Java calling a method on an object looks like this:
[car drive:10 speed:100];
Whoaaa! Hold on a minute. That is completely different from Java and C. Well, don’t panic. If you have ever programmed with C or C++ you will probably understand the first bit – Car *car. We are creating a pointer to a place in memory that holds a car. The part after the equals is a little more confusing. The designers of Objective-C have dropped the dot-notation completely for messaging objects. The piece of code [Car alloc] can be rewritten in Java as Car.alloc(). In Objective-C, this is the way to allocate a piece of memory for your instance. It is also the way you call methods on instances.
The closest equivalent to a constructor that I can find in Objective-C is the init message call. All objects have an init method – inherited from the base object NSObject (in Java this would be equivalent to Object). You can override the init method in your classes to add initialisation code.
So the first line in our example now makes sense, but what about the second line? Objective-C uses the concept of named arguments. This may seem redundant or a little verbose, but once you get used to it, it does make it easier to read. This syntax scheme is an adaptation of the way you would message objects in Smalltalk. So we are basically messaging our instance of car to drive 10 at the speed of 100. I could have possibly made the method a little more informative and written it as: [car driveFor:10 speed:100].
2. Garbage Collection vs. Retain Counts
Since Mac OS X 10.5, Mac developers have been treated to the simplicity of writing code without having to worry about memory management – in other words, Garbage Collection has been introduced. The only thing to bear in mind is that if you want to write code that is supported by older versions of Mac OS X, namely, 10.4 and the iPhone you will still need manage your memory manually. Fortunately, detecting memory leaks is fairly simple with the Apple developer tool Instruments.
The mechanism by which you manage memory manually is called retain counts. Every time you make an object point to another object you increase that object’s retain count. This loosely means that if you have 10 pointers pointing to an instance, the instance will have a retain count of 10. Whenever you are finished with a pointer you need to release the object. This drops the instance’s retain count by 1. When an instance’s retain count reaches 0 it will be deallocated.
There are many pitfalls with manual memory management. Having a memory leak means that over time your application will consume more and more memory and it will crash the system eventually. There are 2 main ways you can create a memory leak. The first is to have an orphaned object. This is where the object has a retain count greater than zero but there are no other objects pointing to it. The other is to have a retain cycle. This is where Object A points to Object B and Object B points to Object A, and nothing else points to these two objects.
If you want to build applications for the iPhone or for older versions of Mac OS X then you need to be more meticulous with your code. Make sure that your objects always clean up after themselves and use the application Instruments to ensure you have no memory leaks. On the iPhone memory leaks can be disastrous, since you only have a very limited amount of memory to play with. Should your application run out of the allocated memory on the iPhone, it will reboot – basically quit your application.
3. Cool Extras
Objective-C has some really cool features built into it and some downright weird ones. Two really cool features that have no equivalents in Java are: Key-Value Coding and @synthesize/@property directives.
Key-Value Coding is a very neat and dynamic way of querying objects by name. Some people would say that you can do similar tricks in Java with Reflection but Key-Value Coding has a lot more useful features that you cannot leverage in Java without writing a lot of code.
Key-Value Coding works like this:
[car setValue:@”BMW” forKey:@”carMaker”];
You can also describe keypaths for key-values. A keypath is basically a way of navigating a pointer graph to a property from object to object. For example:
In addition to keypaths, there are also aggregator functions you can use on key-values in arrays. So for instance, if we have an array of car objects and we want the average top speed of all the cars at the BMW dealer we could do the following:
Another cool feature that Objective-C contains, that I use all the time are the @property/@synthesize preprocessor directives. The combination of these eliminates the need to write boilerplate getter and setter code. The @property directive, used in the header file for a class, tells the compiler that this is a property of the class. In addition you can make the property read only or readable/writable, by adding read or readwrite in brackets like this:
4. So Far, So Good
So far my experiences with Objective-C have been favourable. I do get confused sometimes when my code won’t compile and it looks correct, only to realise that it would be correct in Java but will never work in Objective-C. Apple’s Interface Builder software is top notch and makes designing and hooking up your interface very simple. XCode’s code editore on the other hand, in my opinion, is a bit behind compared to Eclipse. A Mac developer would, however, probably class Eclipse as bloatware. Instruments is my favourite and makes optimising your application and finding memory leaks a doddle.