This question already has answers here:
Looking to understand the iOS UIViewController lifecycle
(11 answers)
iPhone SDK: what is the difference between loadView and viewDidLoad?
(8 answers)
Closed 5 years ago.
Can someone please help me understand what exactly viewDidLoad()does? I know it's called when the view controller is first loaded into memory. I addition, I am aware I can treat it as a main(). But I would like to know more about it. What does it reference too? UIView? It loads and treats all the buttons, labels, etc? Having a detailed and well explained overview would help!
In addition, I'm also confused about override. Does it add code to existent viewDidLoad()?
Thank you!
override func viewDidLoad() {
super.viewDidLoad()
// Do any additional setup after loading the view, typically from a nib.
}
P.S I am new here, feel free to leave any comments about my question formatting.
viewDidLoad is the method that is called once the MainView of a ViewController has been loaded. This is called after loadView is called.In the image you can see the MainView and other views within it. As soon as MainView has been loaded whatever will be included within the MainView you can get access to it (YES, all the buttons, labels, etc) in the ViewDidLoad method.
I'm also confused about override. Does it add code to existent viewDidLoad()?
As we know if subclass provides the specific implementation of the method that has been provided by one of its parent class, it is known as method overriding.
Here, the viewDidLoad in the superclass (UIViewController) is only an empty function. You need to Just override the function for your initial setup of the view once it has been loaded.
viewDidLoad is called when the ViewController has loaded its view hierarchy into memory. This is the point where you can perform your customized initialisation for your view controller.
For instance, if your view controller has a UILabel and you want to set a custom text to it, this is the point where you do that.
Related
I have been mainly working with storyboard until I recently moving to only creating controller with code.
I followed our coding standard to create some subview in the loadView() function, inside which, the first line is super.loadView().
From what I observed, after I called super.loadView(), the frame of self.view is already set correctly with the viewController itself, which is exactly the frame of the viewController.
My more experience colleagues are saying this was 100% not working in the old days that it should give u CGRectZero instead and probably I should not rely on it.
I want to hear more suggestion from other people.
Here is my sample project setup:
1. create a simple proj
2. add a button in the first VC
3. create second VC by code, override loadView() function in second VC, call super.loadView() there and print self.view.bounds next line
4. self.present or use navigation controller from VC1 in the button action to present or push to VC2
5. it always give me correct frame of the second VC.
Please let me know.
----------- Edit -------------
To clarify my question, I know the lifecycle functions like viewDidLayoutSubviews or layoutSubViews to return the correct view. I am NOT asking these.
My question is why loadView() IS returning me the CORRECT frame now.
Unfortunatelly I cannot give any insights as to what is happening under the hood - what I can do though, is tell you that according to the documentation you shouldn’t be calling super.loadView() :
You can override this method in order to create your views manually. If you choose to do so, assign the root view of your view hierarchy to the view property. The views you create should be unique instances and should not be shared with any other view controller object. Your custom implementation of this method should not call super.
(Emphasis mine)
1) I have been mainly working with storyboard until I recently moving to only creating controller with code.
I followed our coding standard to create some subview in the loadView() function, inside which, the first line is super.loadView().
Since you are using xibs, use viewDidLoad over loadView because of If you use Interface Builder to create your views and initialize the view controller, you must not override this method. as stated in loadView in Apple Docs.
2) My more experience colleagues are saying this was 100% not working in the old days that it should give u CGRectZero instead and probably I should not rely on it.
I want to hear more suggestion from other people.
The proper frame for the viewController.view will be when viewWillLayoutSubviews is called. As for its subviews, viewDidLayoutSubviews is what you will need
view frame inside loadView and viewDidLoad are Nib frame size. Your colleagues are correct that it will not return a proper size. This is noticeable upon running an iPad app with viewcontroller presented modally, or run your app on different screen size as contrast to what the device is in xib
ALSO, this question is directly related to yours:
Why am I having to manually set my view's frame in viewDidLoad?
In a project I'm working on, I have a view controller which overrides the loadView() method for setting up the view hierarchy programatically. I was curious if there are requirements regarding what goes in this method versus in viewDidLoad(), or if the latter is redundant when loadView() is already overridden. Is there anything that cannot be done e.g. at the very end of loadView() that should be deferred until viewDidLoad() is called, or is it simply a matter of preference?
EDIT: The initial phrasing of this question was somewhat opinion based. To clarify, I'm interested in whether there is any reference material indicating that there are technical limitations regarding methods that are not able to be used in loadView() that can be used in viewDidLoad().
The documentation for loadView pretty much answers your question:
If you use Interface Builder to create your views and initialize the view controller, you must not override this method.
You can override this method in order to create your views manually. If you choose to do so, assign the root view of your view hierarchy to the view property. The views you create should be unique instances and should not be shared with any other view controller object. Your custom implementation of this method should not call super.
If you want to perform any additional initialization of your views, do so in the viewDidLoad() method.
In other words, only ever override loadView if you are writing your view controller strictly in code - no nib or storyboard. And then only if you have a reason for the base view of the controller to be something other than a plain old UIView that you get by default. And remember that you must not call super.loadView() in your implementation.
I would use viewDidLoad to create and setup any subviews you wish to add to the base view of the view controller (whether loadView was used or not). Also use viewDidLoad for any other setup that can't be done until the view has been loaded.
Technically, if you override loadView to setup a custom base view, anything you might have put in viewDidLoad can be put in your loadView. But I would still separate the responsibility. Only use loadView (if needed) to create and setup the base view of the controller. Use viewDidLoad to create other subviews as needed and any other controller setup.
Also keep in mind that some view controller initial setup belongs in the initializer. But such code can't make any reference to any views.
This question already has answers here:
iOS 7 - Difference between viewDidLoad and viewDidAppear
(7 answers)
Closed 7 years ago.
I want to execute code before view appears but viewDidLoad is getting called before viewWillAppear. Why is it so??
ViewDidLoad is called when the view is loaded in to memory. i.e if you are using storyboard, the app has unarchived the view and loaded it into memory(not yet on screen).
When the app is ready to load the view on the screen it will call the viewWillAppear method.
In your case, if you want to execute code before the view appears on screen, you could add it in either viewDidLoad or viewWillAppear.
Because the view needs to load into memory before it can be displayed.
You need to read further about the view lifecycle. Check this link.
Only after the view and it's elements are loaded into memory, the view is painted on screen and viewWillAppear and viewDidAppear is called respectively.
If you need to execute code before view appears you need to use the viewWillAppear method.
I just wanted to provide some more information, maybe it will help you.
If you use constraints you may look on:
- viewDidLayoutSubviews()
Called to notify the view controller that its view has just laid out
its subviews.
So it will be called after your constraints applied.
I'm getting the Unable to simultaneously satisfy constraints error.
I don't get the error when the viewcontroller establishes itself using viewDidLoad but it does get the error when using loadView...
Why is this happening?
I thought the only difference between loadView and viewDidLoad is that viewDidLoad occurs after loadView. At least, that seems to be the going explanation...
I don't know whether my answer would completely address your issue,but it might act as a starting point to resolve your issue.
There are quite a few points(you might be aware of) which needs to be noted before you use loadView:
loadView is a method that gets called when view is loading,viewDidLoad is method that will be executed after the
view is loaded.
loadView is recommended when you are willing to create the view programatically instead of setting in xib file,other wise there is
no point in using or calling loadView(It all depends on your
application requirement though).
Don't call super loadView if you initialise your view from story
board or xib file.
If you initialise your view from story board, do not call
[super loadView] and you must assign your rootView to self.view
property, if you call [super loadView] inside the method, you better never override this method and put your code in viewDidLoad method..
If you are using xib file to set up the view,do the modifications of objects set up in viewDidLoad and don't call loadView,if you are creating the view programatically,initialise the view in the loadView and do the additional set up in viewDidLoad.
The constraint error generally pops up in story board or xib file,when "Use AutoLayout" is selected,if you unselect it,the error disappears,since you are creating the view programatically in loadView,it is your responsibility to see to it that the auto layout option is disabled i.e. you need to make use of setTranslatesAutoresizingMaskIntoConstraints property by setting it to "NO".
You can also refer to some of related questions here and there which could well get you out of this issue.
Thanks and happy coding :)
This question already has answers here:
What is meaning of calling superview's viewwillappear?
(3 answers)
Closed 9 years ago.
What happens if you don't call super in your implementation of the view events (viewWillAppear, viewDidAppear etc.) of UIViewController?
It seems like I've forgotten to do this before, and it's unclear to me that there was any adverse impacts.
If you subclass one of your own view controller classes, you will certainly want to call super for any of these types of methods or your own base class's methods will not be invoked.
There's also the question of whether your top-level view controller classes need to call super to run the code in the base UIViewController class itself. In the UIViewController reference, it appears that the requirement to call super is documented for certain methods, among them viewWillAppear:, viewDidAppear, viewWillDisappear:, and viewDidDisappear:
If you override this method, you must call super at some point in your implementation.
However, there is no indication of what will happen if you fail to do so.
So apparently, there is something implemented in these methods in the base iOS framework view controller classes. Or at least, Apple reserves the option to implement something in these methods. You could say that they are virtual rather than abstract methods.
If you've subclassed your UIViewController delegate from anywhere (and you always subclass UIViewController at least once, in making your customized view controller), then any delegate methods in subclasses you've derived from won't get called.