So two months ago the Yale Daily News was looking for a CS major to make an iPhone app for them. They have quite and extensive business team, with a highly visible website (100,000+ views per week!) and internet presence, so this was the logical next step. At the time, I had never worked on a real project before (all of my programming knowledge was either self-taught or limited to a few functions/methods in one or two files), but I volunteered because I figured it would be a good opportunity to try my hands at some real coding. A few days and a couple of meetings later, I was working on the project. Alone. Talk about getting thrown in the deep end and learning how to swim.
First thing to do, of course,was to teach myself Objective-C. Having worked through Stephen Prata’s C++ Primer Plus, 5th Edition I was reasonably familiar with object-oriented concepts and general C-syntax, but boy, was I in for a surprise. At first glance, Objective-C is hideous. You have to put  around every method call, and its function names (or “selectors,” as they call them), can get absurdly long (try keysSortedByValueWithOptions:usingComparator: for a short one). However, after doing some reading, I found that it was reasonably easy to learn, and actually had a lot to like:
Highlights are as follows:
- Apple Developer’s Library – top notch; includes sample code and extensive class references
- sending messages to nil/NULL – really neat feature that allows your program to avoid crashing when you send a message to nil. Prevents you from having to write extra logic to deal with nil/NULL cases.
- dynamic (run-time) typing - you can make pointers of type “id” (Objective-C’s equivalent to Java’s “Object”) – and because each instance of an object contains a reference to its class ([self class] or equivalently, self.class), you can write a single function for any data/object type, and vary the implementation within the function itself based on the data type
- selectors - you always know what each parameter to a function/method represents, because the selector (i.e. function name) varies based on the required parameters. As a result, there is no function overloading; technically, you are writing an entirely new function.
- sending messages to nil/NULL – dangerous!!! Can lead to some very undesirable functionality if you’re not careful. The feature is good if you know what you’re doing, but it can lead to some very sloppy code. Also, the functionality does not prevent against the more common error of messaging / dereferencing a pointer to deallocated memory, so that is something to watch out for. Good practice would be to set a pointer to nil as soon as its pointee has been deallocated. That way, you can avoid crashes.
- dynamic typing – code might compile but crash at run time. Java, on the other hand, is strongly typed, so this kind of problem is less frequent. However, in Objective-C, you can type your variables (usually pointers) if you want.
- retain/release and memory management – it’s a pain to understand exactly how retaining works, and whose responsibility it is to release an object. (NOTE: iOS SDK 5.0+ uses automatic reference counting, which takes the burden of memory management off the developer. You should still understand how it works). Here’s a good resource for memory management in Objective-C
- It’s incorporation of C is very awkward. Although Objective-C is functionally a superset of C, it looks very strange when you have C code in an Objective-C class. You have to sort of treat them as two languages when coding/debugging, which can get kind of annoying
If you’re interested, you can check out my app here (it’s free).