iPhone Objective-C for the C# Developer

If you’re a C# developer making your first foray into the land of iPhone and Objective-C programming, you probably have a question or two.  I recently started working in earnest on an iPhone app, so I figured I would write down some of the tips I’ve picked up thus far.

Here they are in no particular order.  No particular level importance.  Just some things that I had to learn and which may help you as well.

Objective-C

• It’s a strict super-set of C, so straight C code is compilable in Objective-C
• Back to the old header and implementation files (.h and .m, respectively)
• There are two types of methods in classes, instance and class methods.  Denoted by a prepended “+” or “-” on the method prototype.  Class methods are just like static.
• All methods are public(!).  That’s right, read that again.  There’s a hack/technique having to do with Objective-C categories to help hide them in the IDE, but they are still callable.
• NSObject is System.Object.
• No garbage collection on the iPhone, there is  reference counting instead.  More on this later.
• What we typically think of as constructors are “init” methods.  Destructors are “dealloc”.  There’s nothing special about these methods, it’s just convention.
• Properties are denoted with @property lines in the header file.  Corresponding @synthesize statements in the implementation file generate the property code.  Special directives in the @property declaration determine the specifics of the implementation (nonatomic, retain, etc.).
• Use #import over #include – it prevents a file from being indrectly #included more than once.
• What .Net calls Interfaces are called Protocols in Objective-C.
• this pointer is called self
• base is super
• Methods are referred to as selectors.  Calling a method is referred to as sending a message to an object.
• Message sending syntax is [recipient method] or [recipient method:paramvalue] or [recipient method:paramValue param2name:param2value]…
• @selector() is for specifying what are essentially delegates.
• id datatype is basically NSObject*
• There are C strings and there are NSStrings.  C string constants are defined like “something”, NSString constants are defined like @”something”
• [[someClass alloc] init] is the typical instantiation pattern. Sometimes there are parameters, as in [[someClass alloc] initWithValue:someValue].   Sometimes you can just call a factory method on the class as in [someClass someClassFromData:data].  The only real difference has to do with the reference counting of the returned object (again, by convention).
• Events are achieved by what they call delegation – registering/attaching an object that adheres to a protocol (interface) to subscribe to events (called Actions).
• No namespaces, but there are categories which I haven’t bothered touching.

Reference Counting

• NSObject implements reference counting.
• Calling alloc or copy sets the reference count to 1.
• To decrement the reference count, call release.
• When the reference count hits 0, NSObject calls dealloc.  NEVER call dealloc yourself.
• Call retain to increment the ref count.  Basically, if you need to keep hold of an object for longer than the duration of one message event cycle (event handler), call retain.    You don’t need to call retain on an object that you directly created with an alloc or copy call – NSObject called retain for you.
• Calling release one too many times is bad – dealloc will end up getting called twice and cause a crash. 
• There is an AutoReleasePool and the ability to call autorelease on NSObject.
• When you call autorelease, the release  call gets posponed/scheduled in the AutoReleasePool.  This is used when a function needs to return a newly created object to the caller.  If it doesn’t call release, the ref count will be incorrect.  If it does call release, it will immediately be deallocated.    Calling autorelease will give the caller time to call retain to take ownership.
• When does the autoreleasepool finally call release?  The pool gets drained at the end of every message pump loop, cleaning up any autoreleased objects.
• So, so summarize… if you call alloc or copy, you need to call release.  If you use a class factory method and need to keep the object around, call retain and be sure to have a matching release later.

Interface Builder

• I have yet to see why Apple developers fall all over themselves about Interface Builder.  No comparison to Visual Studio.
• Interface Builder writes to .xib files (which for some unknown reason are called Nib files).
• It parses your header files for IBAction and IBOutlet on declarations to determine event handlers and variables for interface elements respectively.
• IBAction is a #define for void.
• IBOutlet is a #define for blank.
• Just saving the .h file is sufficient for IB to reparse and pickup the changes.

Ok, I’m tired of typing now.  That ended up a little longer than I intended but I hope it helps you to get up to speed.