Question

This is a curiosity question (unless it proves to have created a memory leak, then it’s real). I have often created custom UITableViewCells for my projects before ARC, but this is the first time I’ve had an opportunity with ARC and Storyboards. It’s written often that the best practice with ARC when dealing with IB assigned views (UITextField, UIImage, etc.) that property that holds the reference be set to “nil” in the viewDidUnload override in the UIViewController.

My question in this case is concerned when you subclass a UIView instead of a UIViewController. For example the UITableViewCell. I have set up a Custom table view cell in my prototypes and added some control views to it. I then created a subclass of UITableViewCell and assigned it to the prototype for IB to return when it dequeues. I created some IBOutlets and linked the control views to these IBOutlets. All fairly typical stuff. My question is that since I don’t have anything to set the IBOutlets to nil, have I created a memory leak?

Thanks for any advice.

Answer 1

Only you can know if you have created a memory leak because it depends how you have your structure, however you probably havent. In arc it is much harder to create a memory leak since the retain release is handled by you.

But here is what you need to know.

First of all, setting things to nil in the view did unload method is only necessary to set in a view controller, but this is only because that view controller might be holding STRONG reference to certain elements in a view. Remember that in ARC objects are released when there are no strong references to them. When you add an element to a view using the IB this view has a strong reference to the element. If you additionally create a STRONG property in the viewcontroller to this element now you have 2 things pointing the element. If there is a low memory condition and the system wants to free up some memory (releasing non visible views) that is when the viewdidunload is called (to nil possible strong reference to elements in the view and to nil other objects that were for that view but can be easily recreated)

Your concern might be in hooking up stuff to the IB on the UITableViewCell. As long as you hook up these controlls to the prototype cell that you designed then it is perfectly fine. Remember that this prototype is a container for all your controls in that cell so the table should be managing the memory for these (when not needed everything in that cell will be unloaded or reused)

Important: You should hook up the controls to the table view cell, not
to the view controller! You see, whenever your data source asks the
table view for a new cell with dequeueReusableCellWithIdentifier, the
table view doesn’t give you the actual prototype cell but a copy (or
one of the previous cells is recycled if possible). This means there
will be more than one instance of PlayerCell at any given time. If you
were to connect a label from the cell to an outlet on the view
controller, then sev- eral copies of the label will try to use the
same outlet. That’s just asking for trouble. (On the other hand,
connecting the prototype cell to actions on the view controller is
perfectly fine. You would do that if you had custom buttons or other
UIControls on your cell.)

raywenderlich.com Page 149
iOS5 by Tutorials Beginning Storyboards