ViewController and viewcontroller

ViewController and viewcontroller
 

1. page Jump
1. Use UINavigationController to call pushViewController for redirection. In this way, use the stack pressure and stack exit method to manage the Controller. You can call the popViewControllerAnimated method to return the result.

PickImageViewController * ickImageViewController = [[PickImageViewController alloc] init];
[Self. navigationController pushViewController: ickImageViewController animated: true];
[IckImageViewController release];


2. Use the presentViewController of UIViewController to redirect. Call the dismissViewControllerAnimated method to return the result.
PickImageViewController * ickImageViewController = [[PickImageViewController alloc] init];

[Self presentViewController: ickImageViewController

Animated: YES

Completion: ^ (void ){

// Code

}];

// Return [Self dismissViewControllerAnimated: YES

Completion: ^ (void ){

// Code

}];

The difference between the new interface is that it provides a parameter that allows you to input a block. The callback method of this block is called after the viewWillDisappear method of VC. That is, run the callback after the hidden VC object is released.

Ii. Lifecycle

When a View Controller is created and displayed on the screen. Code execution sequence
1. alloc creates an object and allocates Space
2. init (initWithNibName) initializes the object and Data
3. loadView loads a view from nib. Generally, this step does not require interference. Unless you do not use the xib file to create a view
4. After loading viewDidLoad, you can customize data and dynamically create other controls.
5. The viewWillAppear view will appear before the screen, and the view will be displayed immediately on the screen.
6. The viewDidAppear view has been rendered on the screen. The execution sequence of a view removed from the screen and destroyed is almost the opposite of the preceding one.
1. The viewWillDisappear view will be executed before being removed from the screen.
2. The viewDidDisappear view has been removed from the screen and is invisible to the user.
3. The dealloc view is destroyed. You need to release the objects created in init and viewDidLoad.

ViewDidUnload: If this view is not displayed on the current screen when a memory warning occurs, viewDidUnload will be executed and all the child views in this view will be destroyed, to release the memory, the developer needs to manually release the memory for the objects created in viewLoad and viewDidLoad. Because when this view is displayed on the screen again, viewLoad and viewDidLoad are called again to construct the view again.

Iii. view Loading Process

Text descriptions are always laborious in expressing the process. I found the following two images:

Follow the following text to understand the view loading process of viewController:

1. First, judge whether the subclass has overwritten loadView. If any, call it directly. Then call viewDidLoad to load the View.

2. If the nib file name is specified externally by calling initWithNibName: bundle, ViewController records this nib to create the View.

3 if the initWithNibName: bundle name parameter is nil, ViewController will find the associated nib through the following two steps.

A. If the class name contains the Controller, for example, if the class name of ViewController is MyViewController, check whether MyView. nib exists;

B. Find the file with the same name as the ViewController class, for example, MyViewController, and check whether MyViewController. nib exists.

4. If the subclass does not overwrite the loadView, ViewController finds or calls its default loadView from StroyBoards. The default loadView returns a blank UIView object.

Note that the first step is to determine whether the subclass has overwritten loadView, rather than whether the ViewController's View is empty after loadView of the subclass is called. That is to say, if the subclass overrides loadView, no matter whether the subclass can obtain the View in loadView, ViewController directly calls viewDidLoad to load the View.

Iv. view unload process diagram

Follow the instructions below to understand the uninstall process:

1. The system issues a warning or calls the ViewController itself, causing didReceiveMemoryWarning to be called.

2. Call viewWillUnload to release the View.

3 call viewDidUnload

5. simulator Call Sequence

I have constructed an environment in which there are two viewcontrollers, named A and B, and the tags are 1 and 2 respectively. When the control program is started, the loaded interface is displayed, put A button in A and call it to interface B through segue after pressing it. Put A button on the page in B and execute

[Self dismissModalViewControllerAnimated: YES];

To return to interface

Then, check all function calls as follows:

Call

 

1 initWithCoder

1 loadView // If you rewrite it, it will be called here. This step can be referred to below

1 viewDidLoad

1 viewWillAppear

1 viewWillLayoutSubviews

1 viewDidLayoutSubviews

1 viewDidAppear

 

Call

 

2 initWithCoder // initialize 2 first

1 prepareForSegue // call the over-prepared function of 1. Therefore, you can assign values to some related properties of interface B in this function.

2 loadView // if this is overwritten

2 viewDidLoad // 2 interface Loading

1 viewWillDisappear

2 viewWillAppear

2 viewWillLayoutSubviews

2 viewDidLayoutSubviews

2 viewDidAppear

1 viewDidDisappear

 

Called in sequence when switching from B to

 

2 viewWillDisappear

1 viewWillAppear

1 viewDidAppear

2 viewDidDisappear

2 dealloc

 

Load in sequence: Load-display-Layout

The order of completion is: Finish Layout-finish display-finish loading.

 

Note:-(void) loadView; if the function is rewritten, the following is a possible demo:

 

-(Void) loadView

{

CGRect applicationFrame = [[UIScreenmainScreen] applicationFrame];

UIView * contentView = [[UIViewalloc] initWithFrame: applicationFrame];

ContentView. backgroundColor = [UIColordarkGrayColor];

Self. view = contentView;

UILabel * lab = [[UILabelalloc] initWithFrame: CGRectMake (100,100,100,100)];

Lab. text = @ "HelloWorld ";

[Self. viewaddSubview: lab];

}

 

Although the returned value of loadView is null, you must assign values to self. view in the function body. Otherwise, you will receive the following log information when creating the interface:

Application windows are expected to have a root view controller at the end of application launch

The execution sequence is as follows: after the code executes initWithCoder, it directly calls the three loadView functions and does not call other functions (including viewDidLoad, viewWillDisappear, and viewWillLayoutSubviews)

Question:

It is unclear why three times of call. My guess is: the three functions above have checked whether the view exists once and found that the view does not exist, so they have called the viewLoad each time, finally, it is found that the above three functions still do not exist. Therefore, the above three functions return failure and the loading is complete.

However, the contradiction is: why are the above three functions not actually executed? What did the underlying layer do?

 

6. What should I do when I create a view and ViewController?

1. init

Allocating critical data structures required by your view controller

Do not show Code for creating a view. Well designed, only the initialization of relevant data should be performed in init, and the data is critical. Do not drop self. view in init; otherwise, viewcontroller will create a view. (Because the view is lazyinit ).

2. loadView

Creating your view objects

Only initialize view. It is generally used to create key views such as tabView of tableViewController and navgationBar of UINavigationController. getter of view cannot be used (before super loadView is dropped ), it is best not to initialize some non-critical views. If you create a viewController from the nib file, you must first call the super loadView method. However, we recommend that you do not reload this method.

3. viewDidLoad

Allocating or loading data to be displayed in your view

Now that the view is available, it is best to create some additional views and controls. Note that viewDidLoad is called multiple times (viewcontroller may load views multiple times, see Figure 2 ).

4. viewWillAppear is generally called before the view is added to the superview and before the animation is switched. Here we can perform some pre-display processing. For example, the keyboard pops up and some special process Animations (such as the status bar and navigationbar color ).

5. viewDidAppear is generally used for display. After the animation is switched, you can add the relevant code here if necessary.

6. viewDidUnload

Releasing references to view objects

Releasing data that is not needed when your view is not displayed

Now the viewController view is nil. This usually happens when the memory warning occurs, so here you should release those views that are not displayed. For example, if you add a label to the viewcontroller view and the label is the attribute of viewcontroller, set this attribute to nil to avoid unnecessary memory usage, this label will be re-created during viewDidLoad.

7. dealloc

Releasing critical data structures required by your view controller

VII. Notes:

1. All viewcontrollers of iOS can be divided into two categories by structure:

1 ),. ViewController is mainly used to display content. This ViewController is mainly used to display content for users and interact with users, such as UITableViewController and UIViewController.

2) ViewController for controlling and displaying other viewcontrollers. This ViewController is generally a container of ViewController. For example, UINavigationController and UITabbarController. They all have a property: viewControllers. UINavigationController indicates a Stack structure that pushes a ViewController or pop once. Therefore, the latter ViewController generally depends on the former ViewController. UITabbarController represents an Array structure, and each ViewController is tied.

The first ViewController is often inherited to display different data to users. The second type is rarely inherited unless you really need to customize it.

2. When a Controller loads a View, it automatically points some View objects to their corresponding IBOutlet variables.

So when the view is uninstalled, we must release these variables in viewDidUnload, and ViewController will not automatically do this.

The specific method is to set the variable to null (note the difference between the variable release and dealloc). Note that the view attribute of the Controller is empty at this time.