Container View Controller

Document directory

• 1. uiviewcontroller
• Ii. Hierarchy
• Iii. Container
• Iv. Custom container View Controller

1. uiviewcontroller

During iOS development, we often deal with uiviewcontroller. From the class name, we can see that uiviewcontroller belongs to the C (Controller) in the MVC model. More specifically, it is a view controller, A view is managed ).

The view of uiviewcontroller is lazy loading. When you access its view attributes, the view is loaded from the XIB file or created by code (overwrite the loadview method and customize its view hierarchy ), and return, if you want to determine whether a View Controller's view has been loaded, you need to determine through the isviewloaded method provided by the Controller.

After a view is loaded, viewdidload is called. You can request or load data to update your interface.
When view is added to view hierarchy, viewwillappear is called. When view is added, viewdidappear is called. Similarly, viewwilldisappear is called when view is to be removed from view hierarchy, when the removal is completed, viewdiddisappear is called.

When the memory is insufficient, the didreceivememorywarning of all the uiviewcontroller objects will be called. The default implementation is that if the superview of the current viewcontroller view is nil, the view will be released and viewdidunload will be called. In viewdidunload, you can perform subsequent Memory cleanup (mainly the release of interface elements, which need to be rebuilt when loaded again ).

If you want to display a View Controller, there is usually one of the following ways:

1. Set it to the rootviewcontroller of the window (uiwindow before IOS 4.0 does not have the rootviewcontroller attribute. You can only add a view of the View Controller through addsubview)
2. Use an existing container for display. For example, use uinavigationcontroller to display a View Controller [navigationcontroller pushviewcontroller: VC animated: Yes];
3. Presentmodalviewcontroller is displayed on the modal interface.
4. Use addsubview as the subview of the view of another view controller.

Directly using the four methods is dangerous. The previous View Controller cannot call the function related to the lifecycle of the current view controller, and transfer the rotation event.

Ii. Hierarchy

We know that a view can add another view as a subview to form a view hierarchy. When a view is added to the view hierarchy of the window, it will be displayed ". Each View Controller manages a view hierarchy. the View Controller itself can have a child View Controller, so there is also a concept of View Controller hierarchy. When the View Controller receives an event such as rotation from the upper layer, child to be passed to it
View Controller. Generally, view hierarchy and View Controller hierarchy must be consistent. For example, the superview of a View Controller is managed by its parent View Controller.

Iii. Container

An iOS app is rarely composed of only one viewcontroller, unless the app is extremely simple. When there are multiple view controllers, we need to manage these view controllers. Objects that are responsible for displaying one or more view controllers and managing their view lifecycles are called containers. Most containers are also a view controller, such a container can be called the container View Controller, and a few containers are not the View Controller, such as uipopovercontroller, which inherits from nsobject.

Our commonly used containers include uinavigationcontroller and uitabbarcontroller. Generally, containers share some common features:

1. Provides interfaces for managing the child View Controller, such as adding the child View Controller, switching the display of the Child View Controller, and removing the child View Controller.
2. The container "owns" all child view Controllers
3. The container is responsible for calling appearance callback of the Child View Controller (viewwillappear, viewdidappear, viewwilldisaapper, viewdiddisappear), and transferring rotation events.
4. Ensure that the hierarchical relationship between view hierarchy and View Controller hierarchy is consistent. Use the parent View Controller to associate the child View Controller with the container.

It can be seen from the above that implementing a container View Controller is not a simple task. Fortunately, the interface size of the iPhone is limited, in general, the View Controller's view is full of interfaces or built-in containers. We do not need to create additional containers on our own, but the situation is different on the iPad.

Iv. Custom container View Controller

The framework does not support custom container View Controller before iOS 5. Some new interfaces are opened in iOS 5 to support custom containers.

addChildViewController:removeFromParentViewControllertransitionFromViewController:toViewController:duration:options:animations:completion:willMoveToParentViewController:didMoveToParentViewController:

The first two interfaces are important. You can directly change the hierarchy of the View Controller.

Unexpectedly, do the following without any additional settings:

[viewController.view addSubview:otherViewController.view]

In iOS 5, otherviewcontroller can immediately receive calls from viewwillappear and viewdidappear.

As for the transfer of rotation events and the call of viewwillappear viewdidappear at other times, the call must be based on [viewcontroller addchildviewcontroller: otherviewcontroller.

When we need to implement custom containers on iOS 4, or sometimes we don't want methods like viewwillappear to be automatically called, but want to control them by ourselves, at this time, we need to manually call these methods, instead of automatically calling them by the framework. In iOS 5, you can easily disable the automatic call feature, and overwrite automaticallyforwardappearanceandrotationmethodstochildviewcontrollers to return no

However, it is still problematic to overwrite this method in ios5. When executing the following statement

[viewController.view addSubview:otherViewController.view]

Otherviewcontroller can still immediately receive calls from viewwillappear and viewdidappear.
To solve this problem, call [viewcontroller. View addsubview: otherviewcontroller. View] In ios5 to perform the following operations:

[viewController addChildViewController:otherViewController]

In general, there are many problems and notes for implementing containers compatible with IOS 4 and iOS 5.

1. Before and after a view is added to the view level, call viewwillappear and viewdidappear respectively. The same method must be called for the currently displayed child View Controller in the viewwillappear, viewdidappear, viewwilldisappear, and viewdiddisappe, the container must ensure that the view of the child View Controller has been loaded before calling viewwillappear of the child View Controller. another point is to ensure that the view of the container does not show that the bounds is cgrectzero, because if the view contains multiple subviews, when the bounds changes, the subview changes the frame according to its autoresizingmask, however, when bounds is changed to 0 and then to 0, the frame of the subview may not be what you want (for example, the autoresizingmask of a subview is uiviewautoresizingflexiblebottommargin)
2. The shouldautorotatetointerfaceorientation of the container needs to detect shouldautorotatetointerfaceorientation of each child View Controller. If one does not support shouldautorotatetointerfaceorientation
3. The willrotatetointerfaceorientation, didrotatefrominterfaceorientation, and willanimaterotationtointerfaceorientation methods of the container need to pass these events to all child view controllers.
4. Because the parentviewcontroller attribute of uiviewcontroller is read-only, and ios4 does not provide interfaces supported by containers (the interfaces supported by containers in iOS 5 indirectly maintain this attribute ), therefore, in order to associate childviewcontroller with the container, we can add a base class of View Controller, such as supercontroller, to specify the corresponding parentviewcontroller.
5. Since interfaceorientation of uiviewcontroller is read-only and ios5 does not provide container interfaces, the interfaceorientation of uiviewcontroller becomes untrusted, to obtain the orientation of the current uiviewcontroller, we can use the value of interfaceorientation of rootviewcontroller in uiwindow.
6. In the viewdidunload method of the container, you must release the view of childviewcontroller that has not been released by the view and call its viewdidunload method.

Apple has a very detailed document on uiviewcontroller and its usage.
Uiviewcontroller reference,
Viewcontroller programming guide.

Reprinted: http://geeklu.com/2012/05/custom-container-view-controller/