ios超级视图和子视图

Question

I have a superview and I add a subview to make a selection. In the superview (main view) I do the following: [self.view addSubview:cityViewController.view];

In the cityView, when I have done what I need to do, I just do self.view removeFromSuperView.

The question is, from within the superview, how can I tell when the subview has removed itself.

Answer 1

There's a few ways, but honestly since the current view controller (let's call it main) is just adding the cityViewController 's view, keep the handling of adding/removing the views to the current view controller, and just have the main controller call [cityViewController.view removeFromSuperView]

This way you can execute whatever code you want when it receives this notification (be it a method that fires or a UINotification ).

-- edit for sample UINotification code --

main.m

...
//Define cityViewController as an iVar and alloc/init it
[[UINotificationCenter defaultCenter] addObserver:self selector:@selector(didFinishView:) name:@"DidFinishView" object:nil];
[self.view addSubview:cityViewController.view];
...

-(void) didFinishView:(NSNotification *)notification {
    [cityViewController.view removeFromSuperView];
}

CityViewController.m

-(IBAction) doneButtonClick:(id) sender {
    [[NSNotificationCenter defaultCenter] postNotificationName:@"DidFinishView" object:nil];
}

Answer 2

The quick answer is your view should not be removing itself. It's better practice for a view to communicate user interactions to a relevant controller through an interobject communication mechanism. The most common methods are direct messaging, protocols and notifications. The iOS framework uses all of these and there are great docs explaining them. Here's a brief summary:

• Direct messaging. Use this when an object needs to communicate with a specific object of a known type. For example, if MyView is always contained in MyViewController and needs to send messages to it you can add a property to the MyView class that keeps a pointer to the specific MyViewController object. You can then send a message from myView to it's myViewController via [myView.myViewController userDidTapSaveButton] or whatever.

• Protocols. A protocol defines a contract between objects that don't know anything about each other other than that they abide by the contract. For example, UITableView knows that it's delegate conforms to the UITableViewDelegate protocol and it can send the required protocol messages to it's delegate. Any object can conform to the UITableViewDelegate protocol.

• Notifications. Notifications allows an object to post notifications through a central mechanism ( NSNotificationCenter ) that other objects can observe and respond to. Notifications are useful when the object posting the notification doesn't know or care what objects are observing it's notifications.

I'd read the relevant docs and other Q&A on SO about these methods. I'd also study up a bit on the MVC (Model/View/Controller) design pattern so you get more comfortable knowing where to put app logic. Generally, a view should only be responsible for it's display (based on properties set by it's controller), observing/responding to user actions, and notifying it's controller for relevant actions.