What is View Controller Life cycle in swift?
Ans: View Controller Life cycle swift : View Controllers (VC) are the Controller part of the MVC(Model View Controller) triangle. They are responsible for controlling the view. Every time you want to display more or less significantly complex pieces of UI, you would want to use a View Controller to handle the lifecycle and user interaction callbacks of that UI.
In a nutshell, a View Controller is a simple subclass of UIViewController that has to have a view to draw the UI on. It is either attached to a UIWindow as the root View Controller of that window or managed by a UINavigationController or by another VC or system to be presented to the user.
At the end of the day, when you develop iOS apps there are two main reasons you’d want to use View Controllers:
get lifecycle callback for the view that the VC is managing (when the view was loaded, displayed, hidden, etc.)
get handy built-in system integrations to present and dismiss VCs using UINavigationController, modal presentation, or parent/child containment API
View Controller lifecycle callbacks:
- view controller lifecycle swift
- explain view controller lifecycle in ios
- apple view controller lifecycle
- extjs view controller lifecycle
- ui view controller lifecycle
- objective c view controller lifecycle
- xamarin ios view controller lifecycle
View Controller Life cycle swift is Explained as below Cycle
loadView: you can override this method if you’d like to create the view for your VC manually.
viewDidLoad : this method is called once when your VC’s view was loaded in memory for the first time. Do any additional setup and initializations here. Typically, this is the method where most of your custom view initialization and autolayout setup will go. Also, start your services and other async data-related stuff here.
ViewWillAppear() : View Controller Life cycle swift
viewWillAppear : this method is called when the view is about to appear on the screen. It will be called after viewDidLoad and ev- ery subsequent time after view disappears from screen and then appears again. For example, when you present a view in a navbar it will call viewDidLoad and then viewWillAppear/viewDidAppear for that VC.
Later, if you push a new VC on top of it, viewWillDisappear and viewDidDisappear will be called because it’s no longer the fore- ground/top VC. Later still, if the user taps the Back button, viewWill- Appear and viewDidAppear for that first VC will be called because it becomes the top VC again. Use this method to do final UI customiza- tions, hook up UI observers, etc.
This technique is typically used to refresh the user interface with information that could have changed while the view controller was not visible.
Additionally, you may set up the user interface for animations that you wish to start as soon as the view controller appears.
viewDidAppear VS ViewDidLoad
Initializer or viewDidLoad code should contain instructions that only need to be executed once ().
The view’s limits are established in this stage, but the orientation is not used.
ViewWillLayoutSubviews() : View Controller Life cycle swift
viewWillLayoutSubviews is called right before layout Subviews() in underlying UIView for that VC. It is rarely used to adjust your view positioning.
viewDidLayoutSubviews()is called right after layout Subviews() in underlying UIView for that VC. It is rarely used to adjust your view positioning.
viewDidAppear :this method is called right after the view as shown on the screen and follows a viewWillAppear call.
viewWillDisappear is called when the view is about to become “hidden” i.e. not the top view controller presented to the user (see example above).
This function is called just before switching to the next view controller and removing the original view controller from the screen.
Even though there aren’t many routine chores to be completed at this time, you might need to override this function.
viewDidDisappear is called after viewWillDisappear and indicates that the view is “hidden”.
This function is invoked when a view controller is removed from the screen.
This function is commonly overridden to prevent tasks that should not execute while a view controller is not on screen.
You can, for example, cease listening to alerts, examining other objects’ attributes, monitoring the device sensors, or making a network call that is no longer required.
didReceiveMemoryWarning is called when the system is low on memory and needs to release additional resources. Deallocate as much as you can here. Don’t go crazy about it, though, because nowadays phones are so powerful that memory warnings rarely happen.
Additionally, View Controller, just like Views, can be initialized either pro- grammatically in code using init… constructor/initializer methods or loaded from a storyboard/xib file. In the former case, one of the initializer methods will be called and in the latter it will be via -initWithCoder.
A view controller is deinitialized before it is removed from memory. Override deinit() to clear up resources allocated by the view controller but not released by ARC. Remember that simply because a VC is no longer visible does not imply that it has been deallocated. NavigationController and other container view controllers can maintain their VCs in memory. Remember that even if a VC is off-screen, if it is still in memory, it can still function correctly and receive alerts.
When the orientation of the interface changes, UIKit calls this function on the window’s root view controller just before the size changes. The message is then propagated across the view controller hierarchy by the root view controller notifying its child view controllers. The property with includes a UIViewControllerTransitionCoordinator coordinator, an enum that represents the new orientation, and the parameter to holds the container’s view’s new CGSize size.
Red flag:you simply have to know this stuff to be able to develop iOS apps.