I have written a piece of code to create a record in Core DB in ViewWillDisappear. but unable to test that on simulator as ViewWillDisappear is never invoked. What kind of operation should i do to invoke it. tried stopping from Xcode no luck.
may be a silly one. but needs pointers.
Thanks.
Doc
says :
This method is called in response to a view being removed from a view hierarchy. This method is called before the view is actually removed and before any animations are configured.
Subclasses can override this method and use it to commit editing changes, resign the first responder status of the view, or perform other relevant tasks. For example, you might use this method to revert changes to the orientation or style of the status bar that were made in the viewDidDisappear: method when the view was first presented. If you override this method, you must call super at some point in your implementation.
You have to pop this view controller from the navigation stack or to push another view controller from it in order to invoke viewWillDissapear
Related
I recently ran into a headache with iOS view controller containment.
Everything works as expected, except in one particular case:
If a child view controller is contained by a parent while the parent is in-between its viewWillAppear and viewDidAppear calls, then viewWillAppear will never be sent to the child VC (the child VC sees viewDidLoad and then viewDidAppear).
This edge case can come up e.g. if you create and contain a child VC as the result of an asynchronous network call, which might land in-between the parent's viewWillAppear and viewDidAppear.
I've put together a demo here: https://gist.github.com/cellularmitosis/8205610a80112eebd96c
To reproduce this locally, create a new "Single View Application" iOS project in Xcode, then replace the contents of ViewController.swift with the above gist.
Am I missing something obvious here, or is this a bug on Apple's part?
I'm guessing this means I need to override shouldAutomaticallyForwardAppearanceMethods() to return false, and then manually call beginAppearanceTransition and endAppearanceTransition?
Follow-up: This is the workaround which I'm currently using: https://gist.github.com/cellularmitosis/56d734ab087a3f283455
I implemented a view controller transition state tracker, and if the parent VC is in-between viewWillAppear and viewDidAppear, then we answer false to shouldAutomaticallyForwardAppearanceMethods.
containChildViewController is updated to handle both true and false for shouldAutomaticallyForwardAppearanceMethods.
Definitely a kludge, but it appears to work.
TODO: There may be an analogous bug during the viewWillDisappear -> viewDidDisappear transition. I haven't checked.
EDIT: edited the workaround gist to use beginAppearanceTransition/endAppearanceTransition instead of directly calling viewWillAppear/viewDidAppear
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'm using the Facebook iOS SDK to have users authenticate and when they log out and log back in, the state of the main view controller, the one with the logout button, is in the same state as when they left it.
How can I completely remove the view controller from memory so that every time they log back in, the view controller's viewDidLoad method is called and the view controller is re-initialized.
When done with it each time you need to release all references.
When you need to show it again, create and use a new instance. This is the only way to ensure viewDidLoad is called each time you need it.
Or if you want to keep reusing the same one over and over, add a restart method (or something similar). The implementation of this method can reset the UI to whatever starting state you need. Or you can put this logic in the viewWillAppear: method. This depends on whether viewWillAppear: can be called due to pushing and popping other view controllers.
I am using a Storyboard with a UINavigationController that is set as "is initial View Controller". It's attached RootViewControllers. viewDidLoad method gets called after application:didFinishLaunchingWithOptions: and applicationDidBecomeActive:.
Why does that happen?
Because the view is loaded before your application becomes active. Active is defined as the point at which your application begins responding to events, and you need a view for this.
If you want to know why viewDidLoad method gets called after those methed I suggest you to read the app-launch-sequence-ios. It's the normal bootstrap execeution in every iOS application.
When you istantiate a controller with an associated view, the view for that controller takes some time to load in memory. viewDidLoad is not called immediately but only when the view has been loaded completely. Here you are sure that outlet for that view are linked correctly.
Hope it helps.
I need to save my data by calling a method I already have when a viewController is popped using the back button created by the UINavigationController.
Is there a way to get a delegate callback or a notification I didn't see anything in the documentation?
In your viewWillDisappear method, you can check the property:
[self isMovingFromParentViewController]
to find out if the view is disappearing as a result of being popped off the stack or not.
You will be notified that the view will be disappearing, with the view controller method viewWillDisappear:, however, this will be called each time the view is moved offscreen, whether that means the controller is popped or a new controller is pushed, or whatever else may cause your view to disappear.
Perhaps a better design would be to save your data in your controllers dealloc method. Normally, a navigation controller is the owner of a view pushed into it's stack, so popping it usually causes it to deallocate. This isn't always the case though and depends on how you've written your app.