Say if I have a navigation stack like this: UINavigationController->ViewController1->ViewController2. When ViewController2 gets popped, does the system guarantee the executing order of below methods?
dealloc of ViewController2
viewWillAppear of ViewController1
I've tested for a while and only see dealloc is called first, but I don't know if this can be guaranteed, i.e., is it also possible ViewController1's viewWillAppear gets called before ViewController2's dealloc?
There is no such guarantee of order, and it's even likely viewWillAppear of your ViewController1 is called before ViewController2.dealloc is called.
The reason is that depending on autorelease pools and internal references, it's likely the system still has a reference to the view controller that is just disappearing/has just disappeared when it calls the viewWillAppear of the view controller that's about to get shown.
If you require cleanup to be run when ViewController2 is popped, implement viewWillDisappear/viewDidDisappear. Again, there is no guarantee that vc2.viewWillDisappear will be called before vc1.viewWillAppear, but you can rely on vc2.viewWillDisappear getting called before vc1.viewDidAppear (note Did, not Will in the last one).
Related
I am using navigation controller. I have pushed two viewcontroller to navigation stack. When I am coming back to viewcontroller1 from viewcontroller2 using back button of navigation bar then viewdidload method of viewcontroller1 is called again.But as much as I know viewdidload is called only once at loading time. So why is this happening? Please tell me.
Thanks!!
-(void)viewDidLoad called only when view controller is loaded
but if you want to call any method then you can write code in
-(void)viewWillAppear
this method called every time when your view is appear.
About viewDidLoad
viewDidLoad: is called every time your view controller's view is loaded, not just the first time. The controller's view can be loaded and unloaded multiple times during the lifespan of the controller and viewDidLoad will be called every time. It may be unloaded whenever it's not on screen, usually if memory is low.
Best practices
Remember not to do view controller initialisation in viewDidLoad. This is a common mistake. For stuff that should only happen once when the view controller is loaded, do it in one of the controller's init methods.
If you're popping/dismissing back to it, viewDidLoad is not generally called, but viewDidAppear will.
The exception to this is in iOS versions prior to 6.0, if you received a memory warning, your view could be unloaded, and it will be reloaded when you pop back.
As you are pushing the viewcontrollers, AFAIK they create a new instance of the view controller they are presenting. When you get back to viewController1 it's viewDidLoad will not be called but the viewController2 viewDidLoad will be called every time you move from viewController1 to viewController2. When you perform pop from viewController2 it is deallocated there itself
Apple's documentation says "When a segue is triggered, it causes a new view controller to be instantiated and transitioned onscreen." Some behavior I'm seeing has me questioning if the VC is actually destroyed and recreated each time the view is seque'd to.
In my application each time I seque to a particular view I note that the the following viewController function is called (which is consistent with the VC being recreated each time it is sequed to):
- (id)initWithCoder:(NSCoder *)aDecoder
Note, this viewController is also a datasource for it's collectionView and has a property:
#property (strong, nonatomic) NSMutableArray *messages;
And every time initWithCoder is called I alloc and init a messages array and assign it to the above pointer.
When I navigate back to another view and then seque back again I'm seeing strangeness that has me thinking that the VC might be being re-used. Or alternately if the first instance wasn't destroyed and can still receive notifications.
The first thing that is strange is that in viewDidLoad if I call addObserver:self for a particular notification which I want this VC to handle then the second time I seque into this VC I will get two notifications sent to the VC's notification handler for every notification sent. This is consistent with the VC being reused otherwise why would the handler get called twice?
But going against this re-use scenario is that initWithCoder is in-fact being called the second time the View is loaded.
Since I don't want 2 or more notifications generated for every notification post, I use a static boolean to guarantee that addObserver is only called once. I.e. addObserver is only called the first time viewDidLoad is called, and not subsequent times.
viewDidLoad and notification handler access the messages array. On the second seque, viewDidLoad seems to access a newly alloc/init'd messages array but when the notification handler accesses messages it seems to be the previous messages array from the previous time the VC was loaded.
Any ideas?
Make sure you are unregistering yourself as an observer on those specific keys once the view is being dismissed. You might have old method still being performed because they were never unregistered.
I use the following to open a new view controller
ViewController *mainMenu = [self.storyboard instantiateViewControllerWithIdentifier:#"mainview"];
[self.navigationController pushViewController:mainMenu animated:NO];
When the mainview is active on the screen the application still runs old view controller (methods) in the background.
How i can stop the old view controller from running or make it inactive?
First, let's ask ourselves this: what kind of methods run on a view controller?
I'm going to categorize the methods that are part of a UIViewController subclass into 4 categories (though there's clearly overlap among these categories).
Life-cycle methods. These are methods such as viewDidLoad, viewWillAppear:, etc. that run as part of the view controller's life-cycle. None of these methods should be running if the view is "in the background" other than, arguably, viewDidLoad, viewWillAppear: which are technically called before the view has come to the foreground, and viewDidDisappear: which is technically called just after the view has left the foreground. So we don't really need to worry about these.
Delegate methods. Your view controller could delegate objects. The delegate methods are called on your view controller whenever the object they're delegating calls them. In the majority of the cases, we're talking about delegating some sort of UI element which is part of the view controller. This UI element would be "in the background" any time the view controller is, so it shouldn't be calling delegate methods.
NSTimer called methods. NSTimer can keep a strong reference to an object, and keep that object alive until the fire time ticks over and it calls the specified method on that object. These methods are certainly likely to be called even if the view controller is in the background, but if you want to stop the timer from running if the view controller's view isn't visible, then just invalidate it in viewDidDisappear:.
Miscellaneous methods. These methods don't necessarily into any of the above categories (though they could). Most of the time these methods are called are from within the view controller themselves, so if nothing is being called from one of the first three categories, it will be rare that this category is called (unless the method is public).
So you've got methods running "in the background" on your view controller. What category do they fall in?
If they're in the first category, then either you're calling a life-cycle method manually from somewhere (which I can't recommend against enough--there's no good reason to do this), or perhaps you don't understand the UIViewController life cycle.
If they're in the second category, then it's most likely good that they're being called. If the Object A is being delegated by View Controller A and Object A is still working on some process and still requires delegation, then it's extraordinarily important that View Controller A is still responding to the delegation methods. If you don't want this to happen, you need to stop Object A from requiring delegation.
If they're in the third category, invalidate your NSTimer objects when it's appropriate. NSTimer doesn't just magically not do what you scheduled it to do. You have to invalidate it in viewDidDisappear if you don't want it to call methods on the view controller when its view is not visible.
If they're in the fourth category, start by making sure you've not got public methods that you're calling manually from outside the view controller. If you do, well stop calling them. If you don't, go double check the first three categories.
If you mean that the view controller that was active before is still executing code, I'd suggest doing the following to remove it from view and execution before pushing:
ViewController *mainMenu = [self.storyboard instantiateViewControllerWithIdentifier:#"mainview"];
[self.navigationController popViewControllerAnimated: NO]; // Takes the old one away
[self.navigationController pushViewController:mainMenu animated:NO];
I've got a question regarding the two mentioned methods, since in my tests I don´t make clear the order they are called. I thought that, firstly, viewDidLoad is called when the viewController is loaded for first time (as the name indicates), and inmediately after the init method. Then, I thought that once viewDidLoad returns, viewWillAppear is called. If you display another viewController, and then you return to this one, then it should be already loaded and only viewWillAppear will be called.
However, while developing I make the impression that there is no order when calling viewDidLoad and viewWillAppear... I couldn´t find a clear description of this lifecycle in Apple's documentation, how does this actually work?
Thanks!
I would like to add to Caleb's answer: Don't confuse the view controller and the view! The name viewDidLoad clearly indicates that the method is invoked after the view has been loaded. It is the view controller that does the loading.
Some pointers regarding the lifecycle of views and the order in which messages are sent:
Not an official Apple document, but I find this diagram really useful because it includes pretty much all of UIViewController's lifecycle overrides.
In the section Resource Management in View Controllers from Apple's "View Controller Programming Guide" there is a flowchart that depicts how views are initially loaded. It explains loadView and viewDidLoad, also in conjunction with storyboards.
The section Responding to Display-Related Notifications from Apple's "View Controller Programming Guide" explains how to respond to views appearing and disappearing (viewWillAppear: et al)
If you are planning on implementing a container view controller: The UIViewController class reference has a good overview of how messages need to be sent by your subclass.
I'm stopping here. You can find more stuff yourself by googling for "uiviewcontroller life cycle".
-viewDidLoad is called when the controller loads its view, which is not necessarily right after initialization. View controllers don't load their views until they need them, either to display or for any other reason.
-viewWillAppear is called just before the view is displayed. This will be after -viewDidLoad, but you don't know exactly how long after. -viewWillAppear is called every time the view is displayed; -viewDidLoad will only be called a second time if the view is unloaded at some point (such as didReceiveMemoryWarning). These days that's unusual, but it can happen.
Or if the viewController is set to nil, which can usually happen if a view controller is kicked off the navigation stack, and therefore next time it is brought to the navigation stack it needs to call -viewDidLoad again.
I thought that, firstly, viewDidLoad is called when the viewController
is loaded for first time (as the name indicates), and inmediately after the init method
No. The name indicates that the controller's view has been loaded (not the controller itself). Actually the docs state that this method will get called after the view hierarchy has been loaded into memory (either via loadView or through a nib for example).
Then, I thought that once viewDidLoad returns, viewWillAppear is
called
Again, no. loadView (and as a consequence viewDidLoad) method will get called the first time that view property is to be accessed and is nil (which is the case when you're initializing a controller). Think of this simple scenario:
MyViewController *vc = [[MyViewController alloc] init];
UIView *view = vc.view; // <= loadView & viewDidLoad will fire but it certainly didn't appear...
However, while developing I make the impression that there is no order
when calling viewDidLoad and viewWillAppear...
Well there is an order. We know for sure that viewWillAppear will always be called after viewDidLoad (if both of them are to be called of course).
As you said, ViewDidLoad is only calling once after loading the view. So we can initialize the instances in the viewDidLoad. It is mainly meant for the initialization.
viewWillAppear will invoke whenever we reach to this view. So if there is any changes in UI, we can done it in viewWillAppear.
I ran a trace on when all these calls are made: http://thecodist.com/article/ios_arc_storyboards_and_uiviewcontroller_trace
I have a navigation based application and in the child view I have a button, tapping on which results in calling the popToRootViewController method.
-(IBAction)popToRootViewController
{
[self.navigationController popToRootViewControllerAnimated:YES];
}
This should result in calling the viewWillAppear method of the rootViewController and it is happening in most of the cases. However, occasionally viewDidLoad of rootViewController is called. I am not able to find the reason behind it. Does any one has any idea why viewDidLoad is called sometimes?
On iOS 5 and Earlier, the System May Unload Views When Memory Is Low:
http://developer.apple.com/library/ios/#featuredarticles/ViewControllerPGforiPhoneOS/ViewLoadingandUnloading/ViewLoadingandUnloading.html
viewDidLoad is called once when view controller's view is loaded first time.
viewWillAppear will be called after viewDidLoad method when view controller's view is loaded first time.
Now when ever u push or pop controller in navigationController, the visible controller's viewWillApper method will be called surely.
viewDidLoad, as the name implies, is called just after a view controller has loaded its view. If a view controller is no longer the frontmost controller, it may release its view to save memory (and it used to call viewWillUnload and viewDidUnload which are now deprecated in iOS 6). If this happens, when it comes to front again (or whenever something calls thecontroller.view), it will recreate the view (if is not Nib-based, it will call loadView), and then call viewDidLoad.