How could a UIVIew know its child has committed suicide

I have a quick question:

View Controller X has added a sub-view: View Controller Y.

Y has a "quit" button. When the button is tapped, it removes its view from X's view hierarchy.

But I found Y's 'viewDidUnload' method is not called and its memory can't be re开发者_运维百科leased. How could Y release itself properly, or how could X know that Y is gone?

I believe I can make a protocol and let Y call a method from X, but I hope there is a easier way.

So you want the Y view controller to get cleaned when its view is closed? Prior to iOS5 there's nothing fancy to support more than one UIViewController on screen at once, so you basically how to make the calls yourself. You could notify X when Y is closed (you could use NSNotificationCenter, or a delegate), and X would set Y's view to nil which would cause the viewDidUnload method to be called in it. Additionally you could even release the Y view controller, which would dealloc every instance it has (along with the view itself) if you're not going to show it again.

As you have added View Controller Y in View Controller X by coding...

    [viewX.view addSubView:viewY.view];

So, the viewDidLoad method wont going to execute. And, as far as memory management is concerns, you can code for that in viewX.m, i.e. as the "quit" has been tapped...

    [viewY removeFromSuperView];
    [viewY released];

If you only need to know when a subview has been removed from its parent view, implement didAddSubview: and/or willRemoveSubview:. (See here in the documentation)

If you want to release the viewController when removing the view, you need to... release the viewController when you remove the view: [viewController.view removeFromSuperview]; [viewController release]; viewController = nil;

The viewDidUnload method is only called when there is a memoryWarning being issued by iOS, and that the ViewController then automatically unload its view (if it is not onscreen, e.g. the ViewController is not the topmost of a NavCtrl's stack so its view is not visible) to release some memory (and will then re-load the view from your XIB and recall viewDidLoad when it needs to reload the view to display it again).

You should not have 2 UIViewControllers on screen at the same time. There is a whole range of problems associated with that and it is not how they are intended to be used.

A single UIViewController should manage all subviews associated with a single screen. If you want a "child" view subclass UIView and add it as a subview.

To allow to switch between view controllers easily, add a UINavigationController as the root view controller, and push/pop view controllers via that. You can then change screens very easily. Remember - you can turn of the navbar and/or animation you get no visual indication that your app is using a navigation controller, but full benefit of it's ability to manage a stack of views and ensure all the correct notifications are sent to each view controller as it loads/appears/disappears/unloads.

If you get in the habit of building every app with a UINavigationController as the root view controller things become very simple.