Good resources for Cocoa programming

Discussion in 'Mac Programming' started by kaworu1986, Jul 9, 2012.

  1. kaworu1986 macrumors member


    Jul 5, 2007
    What are some good materials to learn how to code in Objective C/Cocoa? I am a WPF developer by trade and am trying to pick up Objective C/Cocoa to port an app but am getting nowhere.
    Objective C by itself doesn't seem too bad: you've got your classes, interfaces, accessors, properties and so on; what I'm having enormous trouble with is interface builder: (everything is done by drag and drop, and it's quite obscure) where is the equivalent of code behind I can wire control events to?
    Another huge source of confusion is controllers vs delegates: it seems different tutorials use them interchangeably and I have no clue what one or the other should be responsible for.
    Is there any good tutorial/book that teaches Cocoa WITHOUT also teaching how to program? I am not looking for a course on object oriented programming or design patterns.
  2. robvas macrumors 68030

    Mar 29, 2009
    Cocoa Programming for Mac OS X by Aaron Hillegass

    Make sure the book you get covers Xcode 4 - or you'll spend a lot of time going in circles.
  3. GorillaPaws, Jul 9, 2012
    Last edited: Jul 10, 2012

    GorillaPaws macrumors 6502a


    Oct 26, 2003
    Richmond, VA
    I agree with the Hillegass book suggestion, get the latest edition.

    Xib files don't generate code, they're fully-formed "freeze-dried" objects that get "rehydrated" when they are loaded at runtime. You can create UI objects with code, but it's really not a good idea to manually code your interface instead of learning how to wire up controls (which will take you less time than learning how to manually do it). Take it from people who have been doing this a while, and learn the bits of Interface Builder you need (Hillegass's book will walk you through it).

    Delegates are a bit tricky to grok at first, but they're not unique to Cocoa (neither are controllers in the MVC pattern). The basic idea is that some classes will have a delegate protocol that allows a second class to manipulate the behavior. This second class is a controller class (in the MVC sense), although not all controllers are delegates. A very common class with a delegate pattern is NSTableView. The NSTableView class knows how to draw tables to the screen within a view, but the behavior can be customized. So you'll create a controller object to act as the delegate for that tableview and you can use this controller object to implement custom behavior, by responding to the calls it will send you. So while the app is running, at some point it will call the method for each row:
    - (CGFloat)tableView:(NSTableView *)tableView heightOfRow:(NSInteger)row
    If your app wants to have a customized row height (maybe you want the first 5 rows to be big and everything else small), you can look at the passed in row parameter and return the row height that you want in your implementation. You don't control when your NSTableView calls these, but you need to have an answer to the tableview's "question" if you want to have something other than the default behavior.

    Additionally, tableviews also have a datasource protocol which is similar to the delegate protocol except it's asking which values to display in the table's cells. So if your controller class adopts the NSTableViewDataSource Protocol, then it's going to ask you how many rows does the table have, and your implementation will return the number of rows it has. The NSTableView instance will say, I'm about to make row 2, column 0, what value do I write here, and you'll return @"Delegates are neat!" for that call.

    What this does, is allows Apple to design one generic NSTableView class, that all Cocoa programmers are familiar with, and then gives the programmers the tools to implement custom behavior without having to subclass. Subclassing some classes in Cocoa requires a delicate touch, and can lead to bad things happening if you override the wrong methods. Generally speaking, you often don't subclass in Cocoa to get customized behavior.

    I know the delegate pattern seems a little backwards, or inside out, with the table asking your controller what to do, instead of your controller bossing it around, but it ends up being a really nice way to structure your code once you get the hang of it.

    Returning to the MVC issue, if you have a simple app that has a tableview with data being displayed from a file, then your classes might look like: a window with an NSTableView in it wired up to a controller object that is both the table's delegate and it's data source, and a model class that deals with persisting the data and reading it from disk. The controller class in such an app will get the data from the model class, and add this info to it's internal datasource protocol implementations. The Table will ask your controller class about what data it needs to display by calling the datasource protocol methods and then ask how to visually display the information by calling the delegate methods such as the row height example, and finally it works out all of the drawing logic on how to display "Delegates are neat!" with a large row height in the appropriate cell. Controllers are the mediators between the model classes and your view classes.

    I hope that helped clarify things a bit. Hillegass does a better job explaining it.
  4. firewood macrumors 604

    Jul 29, 2003
    Silicon Valley
    Look for Apple's Catalog sample app, which includes a lot of equivalent manual UI object creation code.
    IB creates the object directly, so there is no code involved, the runtime just unpacks nib bits directly into an being a created object.

    Good catch. A delegate IS a controller, specifically a controller that you declare (by setting it as a delegate) that it will handle certain tasks for yet another object.
  5. knightlie macrumors 6502a

    Feb 18, 2008
    If you're coming from a .NET background then Cocoa delegates are nothing like .NET delegate methods, which are events. Cocoa delegates are like "partner" objects which receive notifications when things happen, or provide needed information.

    Try not to think in .NET terms when learning Cocoa/Obj-C because they're very dfferent and you'll just get bogged down.
  6. whooleytoo macrumors 604


    Aug 2, 2002
    Cork, Ireland.
    Yeah, in many languages, if you want to customise the behaviour of an object (beyond whatever public member variables/methods it exposes), you need to subclass its class and add/change the required behaviour.

    Obj-C/Cocoa tends to take a different approach. Generally instead of subclassing, they use a delegate approach: use a generic object (such as a built-in UIView) with a fairly tightly coupled partner that specifies the behaviour of the generic object. Think of a delegate as an overbearing spouse, to whom the other partner defers most decisions. :)

    For instance: a Cocoa tableview (UITableView) is paired with a UITableViewDataSource 'delegate', and the tableview will repeatedly call the delegate: "Hey, how many sections do I draw?", "How many rows do I draw?", "What do I draw in this cell?"

    The terminology varies a little depending on where/how the delegate is used (e.g. "delegate", "datasource", "controller") but the concept is pretty much the same. Presumably the reason for this approach - as opposed to subclassing - is the MVC approach; keeping the view code and controller code separate.
  7. chown33, Jul 10, 2012
    Last edited: Jul 10, 2012

    chown33 macrumors 604

    Aug 9, 2009
    Sailing beyond the sunset
    Read the Cocoa Fundamentals Guide.

    The Introduction has links to other fundamental documentation, such as Drawing Guide, View Programming Guide, and the Objective-C Language Guide.

    Also see Cocoa Core Competencies. It's good for looking up exactly what a term or concept means in Cocoa.
  8. kaworu1986 thread starter macrumors member


    Jul 5, 2007
    I finally managed to get a hold of the book by Aaron Hillegass and would like to thank those who suggested it. The book is clear, has plenty of pictures to help familiarize with Xcode/Interface builder and I am enjoying it so far.
  9. sofianito macrumors 65816


    Jan 14, 2011
    Not necessarily. You could use composition to delegate behaviour to other object methods instead of inheritance.
  10. aaronvan Suspended


    Dec 21, 2011
    República Cascadia
    A couple Cocoa sites


Share This Page