Qiulang Qiulang - 1 month ago 7
Objective-C Question

In ARC how does a child object tells parent object I am done, please release me (to avoid memory leaks)

My parent object creates a child object to do some async action. It involves some user interaction and that's one of the reasons I didn't use

NSOperation
. Only the child object knows when it has finished its task, then how does it tell its parent object that I am done, please release me to avoid memory leaks?

Currently, I come up with this, the parent object has a callback method called
releaseChild
, which is just
child = nil
; When the child object finishes its task it calls parent's
releaseChild
just to set itself to nil. Actually, I wrap the call in a
dispatch_after
but the idea is the same, the child object calls its parent to set itself to nil.

I was wondering is there a better way ?

----- update -----

I know the "normal" way to write my child is to create a
UIViewController
object, push it to
UINavigationController
. When it is finished user can pop it up,
ARC
will then release it. In that way, I don't need to worry about memory leaks (normally). But I think the question to release a child object when it is done and only it knows when it is done has a border application than writing a
UIViewController
object.

CRD CRD
Answer

In the question:

Only the child object knows when it has finished its task, then how does it tell its parent object that I am done, please release me to avoid memory leaks?

and in a later comment:

the problem is the child object can't set itself to nil.

What it appears you need is a child object which controls its own lifetime. This is easily done; an object remains alive as long as there is a reference to it stored in a variable attributed as storing strong references - and that attribute is the default. That variable can be global, local, instance, it doesn't matter... So to control your its own destiny an object just needs to keep a reference to itself.

The following code, copied from Manual object lifetime with ARC (a previous answer I wrote a few years ago, I can crib from myself ;-)), shows one way to do this:

@implementation MasterOfMyOwnDestiny
{
   MasterOfMyOwnDestiny *alsoMe;
}

- (void) lifeIsGood
{
    alsoMe = self;
}

- (void) woeIsMe
{
    alsoMe = nil;
}

...

@end

In your case you can have the child set alsoMe during its initialisation, so the child starts off controlling its own lifetime. When the child decides it has finished its work it simply calls [self woeIsMe] as its final action.

Note: You can of course remove the methods and just set the instance variable directly within the child, making it hard for any other object to kill the child off.

If the parent needs to have a reference to the child for any reason, other than to keep the child alive, then it can store that reference in a variable attributed as storing weak references, e.g. something like:

__weak MasterOfMyOwnDestiny *myChild = [MasterOfMyOwnDestiny new];

such a reference will not keep the object referenced by myChild alive, and will be automatically set to nil when that object dies.

Comments