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:
Code:
- (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.
