Delegates - retain or assign - release?

Question

I've seen a number of posts related to delegates, and I would like to know the proper way to reference them. Suppose I have an object declared like:

@interface MyViewController : UITableViewController {
    id delegate;    
}
@property (nonatomic, retain) id delegate;
@end

Through the lifecycle of MyViewController , it will make calls to methods of its delegate in response to interaction with the user.

When it's time to get rid of an instance of MyViewController , does the delegate ivar need to be release 'ed in the implementation's dealloc method since it is declared with retain ?

Or conversely, should delegate even be retained? Perhaps it should be @property (nonatomic, assign) id delegate ? According to Apple's docs :

retain ... You typically use this attribute for scalar types such as NSInteger and CGRect, or (in a reference-counted environment) for objects you don't own such as delegates.

Normally I'd just go with what the docs say, but I've seen a lot of code that calls retain on a delegate. Is this just "bad code?" I defer to the experts here... What is the proper way to handle this?

Answer 1

You generally want to assign delegates rather than retain them, in order to avoid circular retain counts where object A retains object B and object B retains object A. (You might see this referred to as keeping a "weak reference" to the delegate.) For example, consider the following common pattern:

-(void)someMethod {
    self.utilityObject = [[[Bar alloc] init] autorelease];
    self.utilityObject.delegate = self;
    [self.utilityObject doSomeWork];
}

if the utilityObject and delegate properties are both declared using retain , then self now retains self.utilityObject and self.utilityObject retains self .

See Why are Objective-C delegates usually given the property assign instead of retain? for more on this.

If you assign the delegate rather than retaining it then you don't need to worry about releasing it in dealloc.

Answer 2

It is usually indicative of bad design, since most delegates retain their objects (creating the potential for retain loops and thus leaks.) But there are some cases where an object should retain its delegate. These are usually cases where no reference is available to the object, so the delegate cannot be the one to retain it--but that itself can sometimes indicate bad design.

Answer 3

I've heard a lot of opinions on this as well. I don't know the Right Way, but I can tell you what I've arrived at through my own work.

You want to retain anything that you need to preserve your handle on. That's all ownership is, in a reference-counted environment. It's a declaration that "I'll need this later, don't let it go away on me".

That ALSO means you're responsible for releasing your claim on it. If you don't specifically do that, you're prone to various problems, but especially dealing with delegates which might well retain the object they're a delegate of. If you don't deal with your retention of the delegate, the ownership will be cyclical and the objects will leak. But don't forget to release what you retain, and you'll be okay.