setting delegate in a subview to nil

Question

Lets say I have a UIViewController. Inside of that UIViewController I have a UITextView. In the viewDidLoad I set UITextView's delegate to self. This means that I need to do textview.delegate = nil in the dealloc? Is this true? Can someone please explain in layman terms why is this so?

If I am misunderstanding the concept of "relasing UIViewController but not setting the subviews delegate to nil prior to calling the [super dealloc]" then can someone give me an example of this

A REAL WRONG EXAMPLE: (CLARIFICATION)

CreateGroupViewController * cgvc = [[CreateGroupViewController alloc] init];
    cgvc.delegate = self;
    UINavigationController * uinc = [[UINavigationController alloc] initWithRootViewController:cgvc];
    uinc.navigationBar.tintColor = [UIColor blackColor];
    uinc.modalPresentationStyle = UIModalPresentationFormSheet;
    [self presentModalViewController:uinc animated:YES];
    cgvc.delegate = nil;    
    [cgvc release];

My point being is that, it is not actually correct to say that every time you release an object it is good to set the delegate to nil. In this case I am showing a ModalViewController. However before the delegate is executed I already nulled the delegate and therefore it doesn't perform. Now how do you explain this?

Answer 1

Yes, you should set the delegate to nil when you're done with it. This prevents the app from crashing if an attempt is made to invoke a method on the delegate object after it has been released. (Keep in mind that it is perfectly legal to send a message to a nil object).

More details at Should you set the delegate to nil in the class using the delegate or in the class itself.

Answer 2

Yes, That's the right way to go about this. Once you set delegate to an object, you are actually assigning the delegate to that particular object and its the ideal way to set it as nil before you release it.

Answer 3

UPDATE Addressing your snippet:

CreateGroupViewController * cgvc;
cgvc = [[CreateGroupViewController alloc] init];
// We now _own_ cgvc; we are responsible for its memory
cgvc.delegate = self;    // cgvc will send us some fun messages

cgvc.delegate = nil;     // Not necessary, because:
[cgvc release];          // cgvc no longer exists

The only case where this makes sense is if the object which is the delegate, call it A, is being deallocated before the object it was delegating for, call it B. This might happen if B is a text field, for example. The text field will stick around after A disappears, and we don't want B trying to send messages to deallocated A:

MyDelegateClass * del = [[MyDelegateClass alloc] init];
myLongLivedObjThatNeedsADelegate.delegate = del;

// Do stuff...

// Release delegate object without setting outlet to nil
[del release];

// ----
// Some time later, in myLongLivedObjectThatNeedsADelegate:
[delegate objShouldDoX:self];  // CRASH! delegate points to 
                               // deallocated instance

---

If you have an object in a variable, and you no longer need the object, but the variable might (accidentally) get used later, it is a safety measure to set the variable to nil after releasing the object.

Demonstration:

NSString * str1 = [[NSString alloc] init];
NSString * str2 = [[NSString alloc] init];
NSString * str3 = [[NSString alloc] init];

str1 = nil;       // We just leaked the object that was at str1;
                  // there is no way to release it.
[str1 release];   // Does nothing
[str1 length];    // Also does nothing

[str2 release];   // Release the object
[str2 length];    // CRASH! message sent to deallocated instance

[str3 release];
str3 = nil;      // A safety measure
[str3 length];   // Does nothing

When you have properties and synthesized setters, it gets a little bit more interesting. If you have a property:

@property (retain) NSString * myString;

for which you synthesize the setter, the setter will look something like this:

- (void) setMyString:(NSString *)newString {
    [newString retain];    // Take ownership of new object
    [myString release];    // Relinquish old object
    myString = newString;  // Rename new object
}

So, if you do self.myString = nil;, what happens is equivalent to the following:

[self setMyString:nil];
    // Inside setMyString: newString is nil
    [nil release];        // Does nothing
    [myString release];   // Relinquish old object
    myString = nil;       // Set myString to nil

You see that the synthesized property carries out the conventional "safety" practice automatically for you. This is why you may see people recommend setting properties to nil.

The last thing to note here is that it doesn't really matter whether you set an ivar to nil in dealloc, because that name isn't going to be used anymore. The object that owns it is being destroyed, so the "safety measure" does not apply. Therefore, in dealloc, you can simply release your ivars without worry.