Cocoa conceptual problems
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.
Tags: development, iPhone
real time twitter by:
June 1st, 2009 at 5:23 am
Conceptual Problems in Cocoa Touch…
You’ve been kicked (a good thing) – Trackback from iPhoneKicks.com – iPhone SDK links, community driven…
June 3rd, 2009 at 7:25 pm
Great post – after a year learning Cocoa my head is still spinning. Sometimes I still wonder whether I truly understand how to program on the iPhone or I have just started following a set of rules that allow we to more or less cope with the oddness of the platform. I have an almost superstitious approach to certain likes (like how I handle memory). It feels a lot more like OCD than programming -
“Don’t step on the crack in the sidewalk or your will over-release your object”
Or something like that.
June 3rd, 2009 at 7:54 pm
About 60% of the way thru the LaMarche book and 30% thru Kochan, I feel like I’m in cave partially lit by my candle light. The trouble is that when I move to a new area, wherever I have just been goes dark again. I’m not sure I’ll ever see the whole cave.
June 4th, 2009 at 12:50 am
@Matt
I feel the same way when in particular when it comes to Core Graphics and Core Animation. I just copy ad paste when it comes to CG and I figure it as I have all the inevitable problems. With Core Animation, I have the great Bill Dudney book. Even still, it is mainly Mac focused and feels a bit over me at times. Transactions, actions and groups cause my brain tumor to grow significantly each time I think about them.
@candy
The LaMarche book is good, but to be honest I probably bought it to late. I got much of my first coding done by following the iCodeBlog tutorials. It was one of the blogs before the fall of the Great NDA. For me the best way was going through tutorials and then just changing everything I could and keeping it working. The next thing I did was just pick a project and said “I will learn everything I need to build and ship this app”. That is how we built Compounds.
June 12th, 2009 at 9:56 am
[...] Cocoa conceptual problems [...]
April 29th, 2010 at 11:20 am
One thing I think is strange is that many authors talk so much about memory management and such but -dealloc is never called according to my NSLogs.
I read somewhere that an iPhone app is sent a kill when you press the Home button, which does exactly that: stops it in its tracks immediately. I heard this is done to speed up the exit process. No memory management on exit is needed.
I’m wondering why I need to be obsessed with memory when I have (supposedly) 28Mb and my app will never use anywhere near that amount. I read that the 28Mb is actually shared with all the background Apple processes and that I might have much less than that. How do I find out how much memory I actually have to work with? I’ve never seen any mention of how to determine this (except for jailbroken iPhones).