As we have stated earlier in this tutorial, ViewControllers are the basic building blocks of the iOS applications. A ViewController is a container in the storyboard on which the content views are drawn to create an iOS application. However, The ViewControllers are ones the manage the content views for an iOS application.
In iOS development, we use a variety of ViewControllers to manage the content views, for example, UIViewController, TableViewController, CollectionViewController, PageViewController, etc. In this section of the tutorial, we will discuss UIViewController.
A UIViewController is an object which manages the view hierarchy of the UIKit application. The UIViewController defines the shared behavior and properties for all types of ViewController that are used in the iOS application. The UIViewController class inherits the UIResponder class.
UIViewController is the parent class for all the view controllers created to build an iOS application, including In-Built ViewControllers like CollectionViewController and TableViewController. In iOS applications, we don't need to instantiate the UIViewController class directly. Instead, we define our class that inherits the UIViewController and add the lifecycle methods to manage the view hierarchy.
As we have already discussed, UIViewController inherits the UIResponder class, which enables the user interactions with views. There are the following responsibilities of UIViewController.
To build a real-time iOS application, we use multiple view controllers in combination where all the view controllers represent the different portion of the application. UIViewController controls the coordination with the other view controllers used in the application. A ViewController may present different view controllers to display a new set of views. It may also act as the container for the other view controller's content.
Every iOS application contains at least one subclass of UIViewController. To build an iOS application, we create multiple custom view controllers that define the overall functionality of our application. In the following section, we will give a brief overview of the functionality, our custom subclass of UIViewController provides.
The root view of the view hierarchy is stored in the view property of the class. The root view is the container for the rest of the views in the view hierarchy. The size and position of the root view are determined by the object that owns it, which is either a parent view controller or the app's window. The view controller that is owned by the window is the app's root view controller, and its view is sized to fill the window.
To create the content views in the iOS application, we must specify the views. There are the following ways that can be used to specify the views in the iOS applications.
1) The most preferable way to specify custom views is by using a storyboard. We can specify the view in the storyboard and create the connection of the views to the respective ViewController class. We can also specify the relationships between different ViewControllers of the application in the storyboard itself. To load a view controller from the storyboard, we call the instantiateViewController(withIdentifier:) method of the UIStoryboard class. The storyboard object creates the viewcontroller object and returns it to the code.
2) We can specify the views using a Nib file. However, the nib file facilitates us to specify the views for a single viewcontroller class but doesn?t let us define relationships among different ViewControllers.
3) We can specify the views for a ViewController using the loadView() method in which we create the view hierarchy programmatically and assign the root view of the hierarchy to the UIViewController view property.
In the storyboard, the root view of the ViewController always sized to fit in the assigned space of ViewController. For all the custom views we add to the storyboard, we must define the auto-layout constraints that govern the size and position of the views on different screen sizes.
Based on the change in the appearance of the viewcontroller, the subclass manages the listener methods, which are notified once the view appears or disappears. The following image shows the methods and their respective view states.
The following methods are notified on the change in the appearance of the viewcontroller.
Implementing Container ViewController
The Container ViewController acts as a container for the other view controller, I.e., it manages the presentation of the content of other view controllers it owns, which are also known as the child view controllers. A custom ViewController can also act as the container view controller.
The container view controller should declare a public interface to associate its children. The nature of these methods depends on the semantics of the container we are creating. We need to decide how many children can be displayed by the view controller at once, when those children are displayed, and where they appear in your view controller's view hierarchy. The view controller class defines what relationships, if any, are shared by the children. By establishing a clean public interface for your container, you ensure that children use its capabilities logically, without accessing too many private details about how your container implements the behavior.
The following method can be called to maintain the container view controllers.
The ViewControlles provides built-in support to release the unused memory by the iOS application, which also stops the memory leak in the application if any. The UIViewController class provides a lifecycle method didRecieveMemoryWarning(), which is notified on the low-level memory condition.