Question

I faced a very interesting situation and do not know how to resolve it. I’ll outline first the architecture of my program. I have a UITableViewController derived class that also implements a my delegate protocol. The cells in this table view are custom cells, and each of them have a strong (assign) type property to the delegate (the table view controller). The delegate handle some UI action.

To reproduce the crash, I load the table view, and then navigate away from it. Normally here the table view would be dealloced but in my case the cells still hold the strong reference to it, so it remains in the memory. The problem is that I get a crash when a memory warning arrives to the device after this. I deducted that the following happens:

• the table view controller receives a memory warning
• the it releases all their (reusable) cells
• in the dealloc of the cells I nil the delegate property, thus they send a release to the table view controller.
• when the last cell nils its property, the ref count of the table view reaches zero, so it will dealloc itself
• after freeing the cells, the default implementation of didReceiveMemoryWarning of the table view continues, but already on a dealloced, zombie object
• sometimes later it calls viewDidUnload on the zombie and it crashes the app.

How can I resolve this situation?

PS: obviously I don’t use ARC

Answer 1

When you’re setting a delegate, you should assign it, not retain it (and so the deallocation of the cells should not send a release message to the table view controller).

Delegating objects do not (and should not) retain their delegates.
However, clients of delegating objects (applications, usually) are
responsible for ensuring that their delegates are around to receive
delegation messages. To do this, they may have to retain the delegate
in memory-managed code. This precaution applies equally to data
sources, notification observers, and targets of action messages. Note
that in a garbage-collection environment, the reference to the
delegate is strong because the retain-cycle problem does not apply.

From Concepts in Objective-C Programming