Is it safe to assume that an attribute, namely fetchedResultsController
, of chatViewController
, an instance of a subclass of UITableViewController
, is always nil
when viewDidLoad
is called, assuming that it's set to nil
in viewDidUnload
? Phew!
If that's the case, then I see no immediate need to redefine the accessor function like in the Xcode example application CoreDataBooks. I'd rather just put all that code in viewDidLoad
instead of in a separate function because that's the only place I'll use it.
viewDidLoad
is called only when view is instantiated for first time . If you're not recreating the view controller each time in your application, you'll only get it called once (and called again if you get a memory warning, and the view is nil'd out).viewDidLoad is called after your view is loaded. Whether or not fetchedResultsController is nil or not depends on how the viewController is initialized. For example, when creating the
detailViewController
, you could set itsfetchedViewController
beforeviewDidLoad
is called:That said, then nil'ing fetchedResultsController in viewDidUnload would ensure that it's nil.
You have to assume that viewDidLoad can be called multiple times. If there is a memory warning sent, your view controller will unload the view from memory, and the next time it is needed viewDidLoad will be called.
ViewDidLoad Called in These Secnarion:-
1.when we push the view controller after creating it’s object by segue or by stoary board id.
2.it called more than one in the case of creating instance more time in application and push it again and again.for example:-if you implement like coaursal(that having required to additional controller during scrolling) like that it’s need so it can called multiple times viewDidLoad.
3.it called when all memory instance (uiviewcontroller and it’s subclass instantiated) that means when our view is ready to load in memory with the address.
4.Remember only child class controller object is created..parent class object never been instantiated during normal Secnarion.