Why use delegates?

Joined
Mar 4, 2010
Messages
51
Reaction score
0
Points
6
I'll bet money that I'm missing something here, but I don't quite understand the point of jumping through hoops for delegates. I just learned how to use them, but what I don't understand is why.

Instead of doing all the set up work, why not just have a certain view controller assign itself as some sort of property (aside from the delegate property) and then just call a method from the view controller using the property? Like:

Code:
//In the first view controller which is a subclass of UIViewController
//(Assume SecondViewController is another subclass of UIViewController)

SecondViewController *myViewController = [[UIViewController alloc] init];

myViewController.ObjectImGoingToSendAMessageTo = self;

[[self navigationController] pushViewController:myViewController animated:YES];
[myViewController release];

Then in the SecondViewController class set up the ObjectImGoingToSendAMessageTo ivar and then just have a method like this:

Code:
- (void)somethingHappened {
[ObjectImGoingToSendAMessageTo doSomethingCool];
}

Wouldn't this accomplish the same thing (i.e. being able to send some message from the second view back to the first view)? Or is there something special about using protocols and delegates that I'm not understanding?
 
Joined
Dec 13, 2007
Messages
256
Reaction score
10
Points
18
Location
United States of America
Your Mac's Specs
2.1GHz MacBook with 4GB RAM, Mac OS X 10.6, iLife and iWork ‘09
I'd try to explain it, but I think Apple has already done an excellent job: read this (also check out the Definitive Discussion at the bottom). Basically it helps in separating code among objects, making more generic (reusable!) code, and in keeping code MVC-compliant.
 
Joined
Jun 25, 2005
Messages
3,231
Reaction score
112
Points
63
Location
On the road
Your Mac's Specs
2011 MBP, i7, 16GB RAM, MBP 2.16Ghz Core Duo, 2GB ram, Dual 867Mhz MDD, 1.75GB ram, ATI 9800 Pro vid
What you have set up is a delegate. Just to note, the delegate ivar is set as type 'id'.

One reason to setup the protocol is so that compiler doesn't spit out warnings that the method call on the delegate isn't found. Another reason is so that your object doesn't have to know any further details about the delegate; you don't need to import the .h file from the delegate to clear those warnings. This allows many different objects to be a delegate to your object. Only one at a time though.

Say I have an object that contains coordinate data used to draw a map of the world. It does't know how to draw though. I also have a window where I want to draw a view and a choice between a Cylindrical Projection map and a Interrupted Projection map. These maps draw very differently, but can use the same data. The window may set up the appropriate view and set the delegate of the data to that view and then send a draw message to the data object. Since the data has a delegate that knows how to draw it will send a "drawWithData: sender" message to the map so that map will know where to get the data. It seems a bit convoluted, but it allows me to use many different map types and easily swap them out at run time.

If you wanted two maps up at the same time using the same data, then you would look at NSNotification.
 
OP
S
Joined
Mar 4, 2010
Messages
51
Reaction score
0
Points
6
@xstep: That makes a lot of sense, thank you!

@nabl: Unfortunately that link only explains what delegates are rather than why to use them. But I appreciate the time you took to get me the link. ^_^
 

Shop Amazon


Shop for your Apple, Mac, iPhone and other computer products on Amazon.
We are a participant in the Amazon Services LLC Associates Program, an affiliate program designed to provide a means for us to earn fees by linking to Amazon and affiliated sites.
Top