iOS ViewController LifeCycle.

View Controller LifeCycle


Now we are discuss about ViewController LifeCycle And how works its delegates methods provids  by the LifeCycle events.
LifeCycle is an event which have certain steps from the point of creation to deletion.




-- Now we see the different different stages of the view controllers described below.


The UIViewController contains three steps of managements-


               1- View UIManagedDocument (loadview,viewDidLoad)
               2- Event management(viewWillAppear,viewDidAppear,ViewWillDisAppear,viewDidDisappear)
               3- memory management(didReceiveMemoryWarning)

Now we Discuss the working of the Delegate methods :-


 - didReceiveMemoryWarning [ (void)didReceiveMemoryWarning ] -


               iOS devices have a limited amount of memory and power. When the memory starts to fill up, iOS does not use its limited hard disk space to move data out of the memory like a computer does. If your app starts using too much memory, iOS will notify it. Since view controllers perform resource management, these notifications are delivered to them through this method. In this way you can take actions to free some memory. Keep in mind that if you ignore memory warnings and the memory used by your app goes over a certain threshold, iOS will end your app means this will look like a crash to the user and should be avoided.

loadView– You should never call this method manually. It is automatically called when its view property is accessed. It loads or creates a view and assigns it to the view property. Override this method in order to create view controller’s default view manually. If you use Interface Builder to create view controller’s views, you must not override this method.

viewDidLoad() Called when the view controller’s content view (the top of its view hierarchy) is created and loaded from a storyboard. The view controller’s outlets are guaranteed to have valid values by the time this method is called. Use this method to perform any additional setup required by your view controller.

viewWillAppear()Called just before the view controller’s content view is added to the app’s view hierarchy. Use this method to trigger any operations that need to occur before the content view is presented onscreen. Despite the name, just because the system calls this method, it does not guarantee that the content view will become visible. The view may be obscured by other views or hidden. This method simply indicates that the content view is about to be added to the app’s view hierarchy.

viewDidAppear()Called just after the view controller’s content view has been added to the app’s view hierarchy. Use this method to trigger any operations that need to occur as soon as the view is presented onscreen, such as fetching data or showing an animation. Despite the name, just because the system calls this method, it does not guarantee that the content view is visible. The view may be obscured by other views or hidden. This method simply indicates that the content view has been added to the app’s view hierarchy.


viewWillDisappear()Called just before the view controller’s content view is removed from the app’s view hierarchy. Use this method to perform cleanup tasks like committing changes or resigning the first responder status. Despite the name, the system does not call this method just because the content view will be hidden or obscured. This method is only called when the content view is about to be removed from the app’s view hierarchy.

viewDidDisappear()Called just after the view controller’s content view has been removed from the app’s view hierarchy. Use this method to perform additional teardown activities. Despite the name, the system does not call this method just because the content view has become hidden or obscured. This method is only called when the content view has been removed from the app’s view hierarchy.


Comments