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 ()2 3@property (nonatomic, strong) Nsarray *Foods;4 @end5 6 @implementationNjoneviewcontroller7 8 //when the view of the controller is loaded, it is called9- (void) ViewdidloadTen { One [Super Viewdidload]; ANSLog (@"1 Controller View load complete"); - } -  the //called when the controller's view is about to be displayed -- (void) Viewwillappear: (BOOL) Animated - { - [Super Viewwillappear:yes]; +NSLog (@"view of the 1 controller is about to be displayed"); - } +  A //called when the controller's view is fully displayed at- (void) Viewdidappear: (BOOL) Animated - { - [Super viewdidappear:animated]; -NSLog (@"1 View full display of the controller"); - } -  in //call when the controller's view is about to disappear -- (void) Viewwilldisappear: (BOOL) Animated to { + [Super viewwilldisappear:animated]; -NSLog (@"1 Controller view is about to disappear"); the } * //call when the controller's view disappears completely $- (void) Viewdiddisappear: (BOOL) AnimatedPanax Notoginseng { - [Super viewdiddisappear:animated]; theNSLog (@"1 Controller's view disappears completely"); + } A  the //called when the controller's view is about to be destroyed +- (void) Viewwillunload - { $ [Super Viewwillunload]; $ } - //called when the controller's view is completely destroyed -- (void) Viewdidunload the { - [Super Viewdidunload];Wuyi     //empty the unwanted properties the //[Self.foods release]; -Self.foods =Nil; Wu } -  About //-(void) Setfoods: (Nsarray *) Foods $ //{ - //if (_foods! = Foods) { - //[Foods release]; - //_foods = [foods retain]; A //    } + //} the  - //called when a memory warning is received $- (void) didreceivememorywarning the { the [Super didreceivememorywarning]; the } the  /**/ -  in @end

Printing results are as follows

Three important methods:

//called when the controller's view is about to be destroyed- (void) viewwillunload{[Super Viewwillunload];}//called when the controller's view is completely destroyed- (void) viewdidunload{[Super Viewdidunload]; //empty the unwanted properties//[Self.foods release];Self.foods =Nil;}//called when a memory warning is received- (void) didreceivememorywarning{[Super didreceivememorywarning];}

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.