Let's say that I have 2 UIViewControllers on a stack within a UINavigationController. In the "parent" we call "[self.navigationController pushViewController:childViewController animated:YES];" upon some user action and in the "child" we call "[self.navigationController popViewControllerAnimated:YES];" upon some user action.
How can we recognize within the parent that we just got back?
Is there some "event" driven method that can recognize that this popViewControllerAnimated action was called from the child?
It seems like you're using this child controller as a modal in that it can be 'dismissed'. If that is the case, try to follow Apple's patterns that they use for UIAlertViews.
If that is the case, I'd do either of the following to implement a delegate pattern(delegate vs block is a huge debate that I will not get into here) so the owner(the one that pushes the child on) knows when its dismissed:
Create a protocol (ChildControllerDelegate), have one method in it childControllerWasDismissed:(ChildController *)
add a block property(make sure its a copy property, not retain) to the ChildController
You'll then want to call the delegate method or block on viewDidDisappear. If you want finer grain control, have a delegate method or block that corresponds viewWillDisappear / viewDidDisappear.
I'd successfully resolved this by setting navigationController?.delegate = self and then implementing this method to determine whether the current view controller is shown again after a pop.
func navigationController(navigationController: UINavigationController, didShowViewController viewController: UIViewController, animated: Bool) {
if viewController == self {
// we got back
} else {
// some other controller was pushed
}
}
There's a few way to hint at that. What you can do, is call the popViewControllerAnimated from the parent. You can do that by passing a block to the child controller that would then execute the said block and thus popping would be done by the parent controller.
You can also use the UINavigationController delegate to be notified when a UIViewController will be dismissed:
- (void)navigationController:(UINavigationController *)navigationController willShowViewController:(UIViewController *)viewController animated:(BOOL)animated;
This method will let you know which VC will be shown and you can check if the current (not yet popped) VC is the child you were looking for.
You can also do some trick with - (void)viewWillAppear: but this might require some hacks.
First read this, it will help you understand what is going on with view controllers.
Then implement viewWillAppear: and viewDidAppear: in your parent view controller to log a message.
Related
I have a stack of UIViewController subclasses. Each modifies a NSManagedObject model. Many of them also present their own modal view controllers.
I need to save changes to the NSManagedObjectContext when a user either 'pops' the view controller or pushes the next view controller.
Currently, I'm hiding the default back button and setting my own UIBarButtonItem with a target of self and a custom action.
This works okay, but ideally, I want to use the default back button and run code before the pop. Is there a way I can run my own code before the pop?
(I'd prefer not to put code into viewWillDisappear as persisting to disk can be expensive and this method can also be triggered by modals being displayed by view controller.) Can it be done?
You can do it in viewDidDisappear, after checking that self is either 1) the second last element in self.navigationController.viewControllers (the case where the next VC just got pushed) or 2) self.navigationController is nil (the self VC just got popped).
Yes.. Navigation controller has a delegate which indicates when a view controller popped or pushed.. You can use that to do your task...
Add following method in your code:
- (void) viewWillDisappear:(BOOL)animated{
//your code here
}
I use viewWillDissappear to make any changes persistant.
If required i Use viewWillAppear to recoginze any changes (reload the data) that may have taken place while other puhed view controlers did their work.
For pop check isMovingFromParent in viewWillDisappear
func viewWillDisappear(_ animation:Bool){
super.viewWillDisappear(animation);
if isMovingFromParent {
// your code here
}
}
This code is from Utility app, added by Apple when creating a project.
What's the difference between this:
- (void)flipsideViewControllerDidFinish:(FlipsideViewController *)controller
{
[self dismissModalViewControllerAnimated:YES];
}
And this:
- (void)flipsideViewControllerDidFinish:(FlipsideViewController *)controller
{
[controller dismissModalViewControllerAnimated:YES];
}
They both work, but the first one is the main code from Utility app, added by Apple.
So is there any difference, and why does self works? self is MainViewController, not FlipsideViewController. I have no idea, does it has something to do with delegation?
Thank you.
It all depends on which object is executing flipsideViewControllerDidFinish; if it is the same as the controller, then it is just the same.
In practice, what happens is that sometimes the class that is delegating (in your case FlipsideViewController), also implements the delegate protocol (ie., acts as a delegate). In such case, self and controller are the same. This would correspond to a delegate intialization (eg. in the init method) like:
self.delegate = self;
But you could have your delegate be a different class (eg., the application delegate, or whatever) and in this case they would be different. In this case you would say (eg in init):
self.delegate = [UIApplication sharedApplication].delegate;
In this case, you application delegate would receive the call to FlipsideViewController and the controller argument tells which object it refers to; in this case, self != controller.
Another case is when your delegate is acting as a delegate for more than one object; in this case, the controller argument tells which object is the delegating one.
In practice, within the delegate method implementation you can safely use the controller argument without much thinking.
I know that an answer has been already chosen as correct and Sergio have done a good job explaining delegation, but on this specific case the answer is far more simple. self and controller in this case are not the same thing (as you say also in the question). self is the presenting controller and controller is the presented one. So, the reason that both calls work is this:
The presenting view controller is responsible for dismissing the view
controller it presented. If you call this method on the presented view
controller itself, however, it automatically forwards the message to
the presenting view controller.
From Apple's documentation on UIViewController
I have a couple of UITableViewController classes and I just noticed that these methods aren't being called:
-(void)viewWillAppear:(BOOL)animated;
-(void)viewDidAppear:(BOOL)animated;
I read in http://discussions.apple.com/thread.jspa?threadID=1529769&tstart=0 that I would have to call those methods myself when pushing view controllers, but that's strange, since it works for anything but UITableViewController.
Also makes it a bit of an issue when I need to have a UITableViewCell deselected in the UIViewController that pushed the UITableViewController.
I can't find it in the documentation, but I think this might be because you are using a UINavigationController.
How about setting the UINavigationController's delegate property and then implementing UINavigationControllerDelegate? It provides two optional methods:
– navigationController:willShowViewController:animated:
– navigationController:didShowViewController:animated:
For example, navigationController:willShowViewController:animated: might look something like this:
- (void)navigationController:(UINavigationController *)navigationController willShowViewController:(UIViewController *)viewController animated:(BOOL)animated {
if ([viewController isKindOfClass:[UITableViewController class]]) {
[viewController viewWillAppear:animated];
}
}
Anyway, this will get you the behavior you want without having to hack calls to viewWillAppear: all over your project.
Did anyone resolve this because the original post is correct - simply using UITableViewController and pushing the table view of that controller onto the navController does NOT trigger these methods despite the fact that it should. I have a series of UITableViewControllers and table views that are pushed and popped to display hierarchical data - nothing fancy, but the "viewWill/Did/Appear/Disappear" methods are never called. Only the viewDidLoad and viewDidUnload are called.
There must be a wiring problem in both our setups, but simply pushing a view into the navigationController should be all that is required (?) - hard to believe that this could have gone unnoticed as a fundamental bug this long.
?
These two methods are called by default to notify for the changes. UITableViewController is a subclass of UIViewController, so there will be the same behavior. You can see more in the View Controller Programming Guide
The viewWillAppear: and viewDidAppear: methods give subclasses a chance to perform any additional actions related to the appearance of the view.
How do you know that these methods are not called? Can you provide some more codes, or at least you test them with a NSLog() to see if there are some messages printed.
I'm seeing the same problem. I have a simple UIView from the IB and I do a addSubview with a class that extends UITableViewController.
I can see the view of the TableViewController without problems in my application, but the viewWillAppear function is never called in this situation.
Well, the discussion linked from the question has the answer right in it. UINavigationController needs to receive the "viewWillAppear" message in order for it to send those messages to the view controllers you push onto it.
So ironically if you don't do what Apple recommends, and you subclass UINavController for your view controller, then everything works great.
However, if you just create a UINavController inside of your view controller, then you need to implement "viewWillAppear", "viewDidAppear" and so on and forward those to your nav controller.
Note that this is especially important if you're using Three20, because its view controller hierarchy expects the "viewWillAppear" message to be received. If its not you can end up with TTTableViews that don't draw.
The same can occur if you use a UITabViewController. You need to force the viewWillAppear call by implementing either the UITabViewControllerDelegate or UINavigationControllerDelegate callbacks
This explanation may help: http://www.mlsite.net/blog/?p=210
my protocol:
#protocol ElectricalSystemEngineDelegate
-(void)didRequestMainMenu:(id)sender;
#end
I designed this protocol in order to handle dismissal of a modal View Controller inside my rootView controller. My rootView controller adopts this protocol and is declared as follows:
#import "ElectricalSystemEngineDelegate.h"
#interface RootViewController: UIViewController <ElectricalSystemEngineDelegate>
//other ivars & methods including instantiation of my modalViewController.
I use an out-of-the-box:
-(IBAction)displayElectricalViewController
-to display the modal controller... which works fine. I am, however, confused on how to proceed further with the implementation of this protocol to handle dismissal of the controller..
//The implementation of my root view controller.
-(void)didRequestMainMenu:(id)sender {
[self dismissModalViewControllerAnimated: YES];
}
Obviously, I correctly implemented the protocol by using the prescribed method. I want the method to dismiss my view controller when called. I also want it to be called by the tapping of a back button in the modalViewController.
As the apple docs say, "In some cases, an object might be willing to notify other objects of its actions so that they can take whatever collateral measures might be required." My goal is for my ElecticalViewController to notify its parent (the RootViewController) that it should be dismissed. That dismissal should be triggered by tapping the back button. How does the object accomplish this notification?
You need to add id <ElectricalSystemEngineDelegate> delegate property to your ElectricalViewController.
Then you need to assign self (RootViewController) to that delegate after you created ElectricalViewController.
Then you call [delegate didRequestMainMenu] when you dispose ElectricalViewController.
Then you need to create a method didRequestMainMenu to your RootViewController.
I need to update the parent view on an iPhone after popping a child view off the navigation stack. How can I setup the parent view to be notified or receive an automatic method call when the child is popped off the stack and the parent becomes visible again?
The user enters data on the child page that I want to display on the parent page after the user is done and pops the view.
Thanks for you help!
I just resolved this self same problem - and the answers above are almost correct, they just forgot about setting the delegate.
I have a root view controller that displays the size of a list, calls a child view controller that may alter the size of a list, and must update the size upon return.
When I create my parent view (SettingsView below), and add it as the root view of a UINavigationController, I make sure to set the UINavigationController's delegate before I display the view - that's the key part:
SettingsView *sv = [[SettingsView alloc] initWithNibName:#"SettingsView" bundle:nil];
UINavigationController *nc = [[UINavigationController alloc] initWithRootViewController:sv];
[nc setDelegate:sv];
In the parent view, implement the UINavigationControllerDelegate protocol:
#interface SettingsView : UIViewController <UINavigationControllerDelegate>
and provide the willShowViewController method:
- (void)navigationController:(UINavigationController *)navigationController willShowViewController:(UIViewController *)viewController animated:(BOOL)animated
{
// Your code to update the parent view
}
This is called after the child view is dismissed, and before the parent view is redisplayed.
I had the need to do something like this as well. In the ViewController that owned my UINavigationController, I had to implement willShowViewController, like this:
- (void)navigationController:(UINavigationController *)navigationController willShowViewController:(UIViewController *)viewController animated:(BOOL)animated {
}
That method is called whenever the UINavigationController changes views. If I'm understanding your question correctly, I think this should do what you want.
I think there is some confusion here. UIViews are not pushed to and popped from the UINavigationController's stack. What is being pushed and popped is UIViewControllers, which in turn handle one or (more often) several views each.
Fortunately, the UIViewController has these methods:
-(void) viewWillAppear:(BOOL)animated;
-(void) viewDidAppear:(BOOL)animated;
-(void) viewWillDisappear:(BOOL)animated;
-(void) viewDidDisappear:(BOOL)animated;
These are called whenever the view is about to (dis)appear, or has just (dis)appeared. I works with tab bars, modal views and navigation controllers. (And it's a good idea to make use of these when you implement custom controllers.)
So in your case, if I understand correctly, you simply have to override the viewWillAppear: or viewDidAppear: method on what you call the "parent page" (which is presumably handled by a UIViewController) and put in code to update the appearance of the page to reflect the data just entered.
(If I remember correctly, you must make sure that the UINavigationController gets a viewWill/DidAppear: message when it is first displayed, in order for these messages to later be sent to its child controllers. If you set this up with a template or in IB you probably don't have to worry about it.)
Felixyz answer did the trick for me. Calling the view will appear method will run the code in it every time the view appears. Different from view did load, which runs its code only when the view is first loaded. So your parent view would not update itself if a child view altered the info displayed in the parent, and was then popped off the sack. But if the parents calls view will appear, the code gets ran every time the view shows back up.
Make sure to call the super method at the same time. Proper implementation would look like this:
- (void)viewWillAppear:(BOOL)animated
{
[super viewWillAppear:animated];
NSLog(#"View Appearing");
}
If you need to notify one controller to another you may use delegation pattern as described here (see 2nd answer).
Unfortunately there is no automatic notification(AFAIK) for exact task as you described.
To meet your needs you may send message to delegate (i.e. to your parent controller) in viewWillDisappear function of your child controller.