The Flying Jalapeño Lives

After Scott Stevenson put out this question on Twitter and his subsequent blog post, it got me thinking. When I really started digging into Cocoa, I remember staring at UIViewController and UITableViewControler for hours, maybe days. Figuring out what all of those methods did seemed impossible.

In retrospect, I can see these classes represent some of the fundamental design patterns used in Cocoa (touch): delegation, composition, protocols, MVC, nibs, memory management, etc… Once I understood how to use a UITableViewController, I was able to dissect and comprehend the interactions and use of other classes much more easily.

There were many “ah ha” moments when learning those concepts. Previous to iPhone programming, I mainly wrote C and machine level code. It wasn’t my first foray into OOP, but it has been my deepest and most comprehensive.

Learning to write methods that you never actually call yourself was a huge mental hurdle. Splitting class responsibilities according to MVC was logical, but hard to do right (I know, a discussion in itself) the first few times.

Similar to MVC, was memory management. It’s so easy: alloc(or new or copy)+retain = release+autorelease. But when do you actually release? When should you just set to nil? Should you use the accessor or not? Maybe it is best to just use the assign property. Should I create an autorelease pool? Is it best to just “leave the object around” and just handle it if a memory warning pops up. You have a lot of design decisions to make even though the basic premise is simple.

Nibs were simply awesome to layout my views, but learning to hook up the right things and how to use them effectively was no simple task. The outlets and actions themselves weren’t that confusing. The “things you don’t quite have to know until there is a problem” were hard to get my head around. For example: how to load nibs from other nibs, load UINavigationControllers in UITabBarControllers, what the proxy objects actually are, which controller classes to include in the nib, what “really” happens when objects are unarchived, realizing that “initWithCoder:” is called on classes that are defrosted from a nib, how to load UITableViewCells from nibs, etc…  There are many intricacies, most of which you never think about until your app doesn’t work.

After I had some time to think over these problems and Scott’s question, I came to realize (at least for me), Cocoa just took time to learn. Everyone comes from a different background with a different skill set. Add to that, the size and breadth of Cocoa. It should come as no surprise that everyone has to take there knocks when moving to Cocoa and Objective-C, no matter where there coming from (save Next developers).

So, how to wrap this up? To all of the beginner iPhone and Mac developers: know that you have a mountain to climb. Find information where ever you can. The Cocoa development community is great and there is no shortage of resources. Eventually you will reach the “critical mass” of information when you can begin to solve your own problems much more effectively. You will always have more to learn, but will develop an instinct to find what is wrong and begin to ask the right questions.

Is there anything that you think is missing from Scott’s list or that I glossed over? Let me know.