Summa

So you think you want to develop software applications for the iPhone. Sure, this is no big deal, you’ve been writing Java or C# for years now. You transitioned to those languages from Visual Basic 6. Heck, you even took C++ in school. You’re certainly not the type intimidated by learning a new language. Really, how different can Objective C really be? Any of this sound familiar? It sure does to me, since that’s exactly what went through my head prior to writing my first iPhone application. I quickly, and sometimes not so quickly, found that the jump from Java to Objective C was not as seamless as originally anticipated. So, from my pain, and for your benefit, here is a list of 5 things I wish I knew going into iPhone development. I have ordered them from merely annoying (or amusing, depending on your disposition) quirks of the language all the way to massive paradigm shifts that will change the way you code. No, I cannot overstate that last part enough. And no, I swear I am not a scare-monger…

So, now to the list:

1. Say goodbye to the “dot operator”.

Yes, we have all become very familiar with the normal way of calling methods on an object:

        myObject.someGreatFunction(p1, p2);

Well, not so fast. Objective C has its own way of  “sending a message to an object”. Same lovely object and method call in Objective C:

        [myObject someGreatFunction: p1 parameter2:p2];

You may have noticed the extraneous “parameter2″ label in there, and yes, that is an excellent observation, which will make more sense in the next session. Now, like any good programming language, there is of course an exception to this rule, which is, a defined property can be invoked using the dot operator as you would expect, or by sending a message to the object using the standard java style getProperty/setProperty convention.  Hence, if we had a property called “Name”, we could access it through either of these methods:

        [myObject getName] or myObject.Name

2. So you think you know how to overload a method?

So I did promise last section to explain those crazy method signatures, well, here we are. Objective C does not have the same concept of method overloading as most developers are used to. For example, say we had a function that would create and return a Widget object, and has several overloads to pre-populate with several properties. In java:

        public Widget createWidget(int prop1)
        public Widget createWidget(int prop1, int prop2)

This gets a bit hairy in Objective C, as the parameter list is actually considered part of the method name. This requires the properties to be named, and are eventually compiled as the method signature. Ignore the dash, I will explain that later, also ignore the asterisk, that designates the Object is a pointer type and may be the topic of a future blog…

     - (Widget *) createWidget: (int) prop1
     - (Widget *) createWidget:(int) prop1 property2:(int) prop2

This can be confusing, and definitely takes some getting used to.

3. So you think you know what an Interface is?

Of course you know what an interface is, it’s just that in Objective C they call it something completely different, and have a construct called an Interface which sort of does what a Java Interface does, but not really. Confused yet?

In Objective C, a Class is declared in a very C sort of way. There is the header file, designated by a .h extension, which defines the Properties and Functions of the class. Then, there is the Implementation, designated by .m (don’t ask), which has all the good stuff. So, an Interface is sort of the same, as it defines a contract for the Class to follow. The bad part is, it cannot be shared: One Interface for one Implementation. Now, how can you define a contract that can be shared across Classes. There is a construct for that and it is called a Protocol. It behaves pretty much exactly the way you would expect a Java or C# interface to behave. Sorry, no Abstract classes though, no code examples in this section either…

4. Private? Protected? No.

I said I would explain the dash from earlier, and now I will deliver on that promise.

When a method signature is created, in both the Interface and Implementation, it is proceeded by either a “-” or “+”. The dash signifies that the method is an Instance method, and the plus means that it is Static. Simple enough:

        Instance:    - (void) doSomething;
        Static:      + (Object *) getSomething;

Now for some disturbing news. There is absolutely no concept whatsoever of Private or Protected methods in Objective C. Let me repeat that, there are NO Private or Protected methods in Objective C. Yes, everything is Public scoped (except instance variables, which can be private or protected).

5. Managed code? We don’t need no stinkin’ managed code!

So now comes that which will give you the most headaches and sleepless nights when developing in Objective C. If there is one area I could urge you to spend as much time as possible reading about upfront, it would be this. Objective C is NOT a Managed language, as least when it comes to the iPhone. What does this mean for you, if you don’t know already? This means there is NO Garbage Collector. You as the developer will be responsible for allocating your own memory, and are thus responsible for cleaning up said memory when you are finished with it.

What this means? We spoke briefly earlier about pointer types. This is any type that is not native and requires a dynamic amount of memory to be allocated. So, when we performed operations on our mystical Widget object earlier, we would need to create one as such:

        Widget w* = [[Widget alloc] init];

Alloc is the command that allocates memory for the Object and think of init as the Constructor. So far so good? Well, remember that every time you allocate memory, you must also deallocate it. In the case of an instance variable this can be quite simple, there is a dealloc function that you can override, and use this very easy command:

        [w release];

This starts to get tricky though when you have function scoped variables, and becomes even more difficult when you create an Object in one method or object, but pass or return it to another. It becomes very tricky to determine when and where to release your object. Too soon, and you could cause a crash when attempting to read a released memory address. Wait to long, and you lose the pointer and now have a memory leak.  Luckily, there is great tooling in xCode for detecting and repairing leaks, but having a strategy around memory allocation upfront will go a long way towards making development simpler. Also, a piece of advice, don’t wait until the end to clean up memory leaks, do it as a part of regular development. Trust me.

So, is this at all a comprehensive list of all the little annoyances, idiosyncrasies, and game changers you will find in Objective C? Not by a long shot. I would encourage anyone to add comments with things they found difficult, or any tips/tricks they found to help ease the transition from Java or C#, or the more mainstream OO style languages in use out there. This is also not to say that there isn’t a host of great things that you will find in Objective C. I could just as easily do a 5 Things Objective C Does and Java Should Do Too list, but, perhaps another day.