Heh, don’t worry. These are good questions to have at this point in the book. A lot of this becomes more clear later on, but here is some help for now:
Yes, your thoughts on the concept of delegation are correct. However, your thoughts on MVC are a bit off - a controller must have pointers to model objects in order to access them. Typically, this means a controller will have an instance variable that points at its model object(s). So, while locationManager is (arguably) a model object, it doesn’t lose its model object status just because a controller has a pointer to it. Keep in mind, the locationManager is NOT inside the controller, but exists as its own object elsewhere in memory. The controller simply know where that object is by keeping an instance variable that points to it. Your suggestion is that you produce another layer between the controller and the locationManager… which would mean the controller would have an instance variable that points at that object anyhow, so you’d just be writing redundant code.
In general, delegation is an object-oriented approach to callbacks. Overall, there are 4 main callback types in Cocoa: target-action (this is what buttons use), blocks (you’ll see these later), notifications (you’ll see these later, too) and delegation. Delegation is used when an object’s actions can produce multiple outcomes. If you think about a button, there’s really only one outcome: it was tapped. Thus, you register one object to receive one message when that outcome occurs. The location manager, on the other hand, can figure out the location, the heading, or fail, and thus has multiple outcomes. The delegate protocol lists all the possible outcomes. Then, you register one object to receive ALL the messages for each possible outcome.
Another example you will see later is NSURLConnection, which is used to pass and retrieve data from a server. Its delegate gets informed when new data is available, when the connection has completed or when the connection has failed. It is a very common pattern in Cocoa Touch simply because it makes the implementation of the delegate object a lot easier - you don’t have to register each message individually, you simply set up the delegate and implement the methods you want to know about.
(Check out page 499 for a deeper discussion).