iPhone IBoutlet should be released manually ?

(3 votes, average: 3.67 out of 5)

 Loading ...

If you google this question, you will find many answers. Some says yes, some says no. Here I am showing the results using instrument ObjectAlloc graph.

Background:

I have to use a view controller with a xib. The xib should have a button which need to be connected to an outlet in the view controller.

Best Practice:

In the view controller .h file, declare a UIButton* and a property like below:

UIButton* btnButton;

...

@property(nonatomic, retain) IBOutlet UIButton* btnButton;

in the .m file synthesize and release the button in the dealloc function like:

@sysnthesize btnButton

...

- (void) dealloc{

btnButton =nil;

[super release];

}

Now, using in the interface builder connect the button.

What happens now:

As said in the apple documentation :

Each time you ask the NSBundle or NSNib class to load a nib file, the underlying code creates a new copy of the objects in that file and returns them to you. The nib-loading code does not recycle nib file objects from a previous load attempt. Because each set of objects is a new copy, your code is responsible for releasing those objects when it is done with them. How you release the objects depends on the platform and on the memory model in use. Table 2-1 lists the supported platform and memory model configurations and the nib retention behavior associated with each one.

…bla bla…

Objects in the nib file are created with a retain count of 1 and then autoreleased. As it rebuilds the object hierarchy, however, UIKit reestablishes connections between the objects using the setValue:forKey: method, which uses the available setter method or retains the object by default if no setter method is available. If you define outlets for nib-file objects, you should also define a setter method for accessing that outlet. Setter methods for outlets should retain their values, and setter methods for outlets containing top-level objects must retain their values to prevent them from being deallocated. If you do not store the top-level objects in outlets, you must retain either the array returned by the loadNibNamed:owner:options: method or the objects inside the array to prevent those objects from being released prematurely.

How we practice often:

In the view controller .h file, declare a UIButton* and a property like below:

IBOutlet UIButton* btnButton;

in the .m file synthesize and release the button in the dealloc function like:

- (void) dealloc{

[btnButton release]; // should we need to do this?!!

[super release];

}

What’s the question?!!

The question is that if we really need to release the btnButton in the dealloc method.

well, we can go on discussion and ultimately we may find that YES, we need to. The outlets should be released in the dealloc. Backing up this conclusion I created a simple project with two view controller one having 6 button connected as mentioned last.

If we  release in the dealloc method, we can see that memory foot print remains the same after closing the last view.

outlest are released in the dealloc method

Now, if we don’t release the outlets or simply assign them nil value we will find memory footprint is increased! See the image below:

outlets are not released or assigned nil value

Conclusion:

We better release the outlets in the dealloc method.

Actually rom the memory management point of view, it doesn’t matter whether you use property or instance variable of IBOutlet. In fact,
IBOutlet does nothing but a help to the Interface builder finding the connectors. Behind the seen, same thing happens for both the way, so you have to release any outlets in the dealloc method.

Download  the Sample Project demonstrating memory footprint for outlets.