iOS Development UI chapter-Creating a navigation controller and the life cycle of a controller using storyboard

iOS Development UI chapter-Creating a navigation controller and the life cycle of a controller using storyboard

First, the basic process

Create a new project, the system default host controller inherits from Uiviewcontroller, two files of the master controller are deleted.

In storyboard, the default controller is the view controller, and we need to be the navigation controllers, then the system to delete, drag a navigation controller comes in, the navigation controller in the default first sub-controller is a TableView controller, There is no need, delete it, re-drag three view controller to the interface to connect, simple setup on it.

button, hold down CTRL, and select push on the right interface.

After completing the basic setup, the interface is as follows:

A simple multi-page switch can be achieved with a few simple settings. For the development of a great convenience, but storyboard is not omnipotent, to note in the development, if the last page to add a button, let it jump directly to the previous page there will be a problem.

Hint: Storyboard can do things, use code can do, but the code can do things, storyboard not necessarily be able to do.

Simple interface settings can be done by dragging the controls.

There is a problem with the following connection: (from the back of the controller to the front, only through the code to achieve)

The cause of the problem: (When the click Returns, not the third controller to remove the top of the stack, but the first two controllers, the stack has four controllers, the top of the stack is two).

Second, the life cycle of the controller

Code Simple Description:

1@interfaceNjoneviewcontroller ()23 @property (nonatomic, strong) Nsarray *Foods4@end56@implementationNjoneviewcontroller78//When the view of the controller is loaded, it is called9-(void) Viewdidload10{11[Super Viewdidload];NSLog (@"1 Controller View load complete");13}1415//Called when the controller's view is about to be displayed16-(void) Viewwillappear: (BOOL) animated17{18[Super Viewwillappear:yes];NSLog (@"View of the 1 controller is about to be displayed");20}21st22//Called when the controller's view is fully displayed23-(void) Viewdidappear: (BOOL) animated24{25[Super viewdidappear:animated];NSLog (@"1 View full display of the controller");27}2829//Call when the controller's view is about to disappear30-(void) Viewwilldisappear: (BOOL) animated31{32[Super viewwilldisappear:animated];NSLog (@"1 controller view is about to disappear");34}35//Call when the controller's view disappears completely36-(void) Viewdiddisappear: (BOOL) animated37{38[Super viewdiddisappear:animated];NSLog (@"1 controller's view disappears completely");40}4142//Called when the controller's view is about to be destroyed43-(void) Viewwillunload44{45[Super Viewwillunload];46}47//Called when the controller's view is completely destroyed48-(void) Viewdidunload49{50[Super Viewdidunload];51//Empty the unwanted properties52//[Self.foods release];Self.foods =Nil54}5556//-(void) Setfoods: (Nsarray *) foods57//{58//if (_foods! = Foods) {59//[Foods release];60//_foods = [foods retain];61//}62 //}63 64 // When you receive a memory warning, call 65-( Void) Didreceivememorywarning66 {67  [super Didreceivememorywarning]; 68 }69 /**/70 71  @end   

Printing results are as follows

Three important methods:

The controller's view is about to be destroyed when called-(void) viewwillunload{    [Super Viewwillunload];} // controller view is completely destroyed when called-(void// empties unwanted attributes // [Self.foods release]; self.foods = nil;}  call-(void) didreceivememorywarning{[Super didreceivememorywarning]  When a memory warning is received. 

Add:

Two differences in memory warnings (compared to proxies):

The agent's memory warning: When something happens to application (when a memory warning is received), its agent is notified, and then the agent notifies it that the Window,window notifies its root controller, and the root controller notifies its child controller. Memory warnings are passed down from top to bottom (can be verified by printing output in two places).

You need to know how its parent class handles memory warnings.

Analog Memory Warning:

Handling of memory Warnings:

Can the controller view be destroyed? How does it know if it can be destroyed? How to judge? It is to determine whether this view is on Windows.

The current one controller is at the top of the stack, and the one controller's view is displayed on the window, and if a memory warning occurs at this point, one is not destroyed because it is on the window.

If at this time a second controller, it creates the corresponding Twoview display to the window, one of the corresponding view moved, at this time if a memory warning occurs, then OneView is no longer displayed on the window, so it will be destroyed.

Special Note: Outlet represents a property, when the controller is created, the property is generally also a value, when the-(void) Viewdidunload method is called, that is, after the controller's view is completely destroyed, all the property data will be emptied. In general, before iOS5, all the properties inside the method are emptied.

Tip: These methods of all controllers are actually a loop.

iOS Development UI chapter-Creating a navigation controller and the life cycle of a controller using storyboard