Explain how to create a navigation controller using storyboard in IOS development _ios

About Storyboard

After IOS5, Apple offers a new way to make the UI, which is storyboard. In simple terms, storyboard can be seen as a set of Viewcontroller corresponding Xib, and the way they are converted. In storyboard, you can see not only the layout style of each viewcontroller, but also the transition relationships between each viewcontroller. Compared to a single xib, its code needs are less, also because of the collection of various xib, so that the understanding of the interface and the speed of modification has been greatly improved. Reducing the amount of code is reducing the amount of bugs, which is one of the truths in program development.

After Xcode5, Storyboard has become the default configuration for new projects, which also represents Apple's recommendations and future directions for developers. WWDC2013 of the various sample code are also basically used storyboard to demonstrate. It can be foreseen that Apple will certainly continue to harden in this area, whereas pure code or a single xib will probably not be enhanced.

If you don't take into account the iOS version of the support (in fact, now rarely see the iOS4 to start supporting the app), now storyboard face the biggest problem is the collaboration of many people. Because all the UI is defined in a file, so many developers personal or enterprise technical leaders think that storyboard can not be collaborative development, in fact, this is more a kind of unfamiliar to the storyboard caused by misunderstanding. Although Apple did not explicitly mention it in WWDC, no one has stipulated that the entire project can have only one storyboard file. One way to do this is to break down the different parts of the project into several storyboard and arrange the developers to take responsibility for their own parts. Simple examples such as a uitabbarviewcontroller based application with 4 tab functions, can use 4 storyboard to represent 4 tab, and to complete development without interfering with each other. There is no such thing as a conflict. Storyboard API is so simple, now the total number of methods in the SDK can be counted on one hand, so the specific method here no longer wordy.

Another challenge for storyboard comes from the reuse of Viewcontroller and the processing of customized view. For the former, in the correct package interface and good design based on the fact that storyboard VC reuse and code VC reuse is no essential difference, in storyboard to add a good encapsulation needs to be reused scene can be resolved. For the latter, because the existence of a single view is not allowed in storyboard, many times we need to customize the UI with the help of a single xib. This can be said to be due to the storyboard design ideas, storyboard more emphasis is a hierarchical structure, is in the overall perspective of the organization of UI design and migration. For a single view, more emphasis is on reuse and customization than on the process of the entire project. Believe that grasping this point, you can well understand when to use Xib, when to use storyboard.

The last thing to say about storyboard is that there are now some concerns about storyboard performance. Because storyboard files tend to be larger and slower to load than a single xib. But in fact, with the current equipment replacement, in iPhone4 are difficult to find today, this performance gap can be almost ignored. And then the device, whether read or parse, will only be faster and quicker. So the problem of performance is absolutely not necessary to worry about.

Using storyboard to create the navigation controller and the life cycle of the controller
First, the basic process

To create a new project, the system default Master controller inherits from Uiviewcontroller and deletes the main controller two files.

In storyboard, the default controller is view Controller, and what we need is the navigation controller, then delete the system, drag a navigation controller in, the default first child controller in the navigation controller is a tableview Controller, Here do not need, delete it, drag three view controller to the interface to connect, simple settings on it.

Button line, hold down CTRL, select push on the right side of the interface.

After the basic setup, the interface is as follows:

After such a few simple settings, you can achieve a simple multiple-page switching. For the development of a great convenience, but storyboard is not omnipotent, to note that in the development, if the last page to add a button, so that it directly jump to the previous page will appear problems.

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

Simple interface settings can be accomplished by dragging the control.

There are problems with the following lines: (Jump from the back of the controller to the front, only through the code to achieve)

The cause of the problem: (When the Click Back, not the third controller to remove the top of the stack, but first create the two controller, at this time the stack has four controllers, the top of the stack is two).

Second, the life cycle of the controller

Simple code Description:

Copy Code code as follows:

@interface Njoneviewcontroller ()

@property (nonatomic, strong) Nsarray *foods;
@end

@implementation Njoneviewcontroller

Called when the controller's view is loaded
-(void) viewdidload
{
[Super Viewdidload];
NSLog (@ "1 Controller View loading complete");
}

Call when the controller's view is about to be displayed
-(void) Viewwillappear: (BOOL) animated
{
[Super Viewwillappear:yes];
NSLog (@ "1 controller view is about to be displayed");
}

Call when the controller's view is fully displayed
-(void) Viewdidappear: (BOOL) animated
{
[Super viewdidappear:animated];
NSLog (@ "1 Controller view full display");
}

Call when the controller's view is about to disappear
-(void) Viewwilldisappear: (BOOL) animated
{
[Super viewwilldisappear:animated];
NSLog (@ "1 controller view is about to disappear");
}
When the controller's view disappears completely, call
-(void) Viewdiddisappear: (BOOL) animated
{
[Super viewdiddisappear:animated];
NSLog (@ "1 controller view completely disappears");
}

The controller's view is about to be destroyed when called
-(void) viewwillunload
{
[Super Viewwillunload];
}
The controller's view is completely destroyed when called
-(void) viewdidunload
{
[Super Viewdidunload];
Empty the unwanted attributes
[Self.foods release];
Self.foods = nil;
}

-(void) Setfoods: (Nsarray *) foods
//{
if (_foods!= Foods) {
[Foods release];
_foods = [foods retain];
//    }
//}

Called when a memory warning is received
-(void) didreceivememorywarning
{
[Super didreceivememorywarning];
}
/**/

@end

Print the results as follows

Three important methods:

Copy Code code as follows:

The controller's view is about to be destroyed when called
-(void) viewwillunload
{
[Super Viewwillunload];
}
The controller's view is completely destroyed when called
-(void) viewdidunload
{
[Super Viewdidunload];
Empty the unwanted attributes
[Self.foods release];
Self.foods = nil;
}

Called when a memory warning is received
-(void) didreceivememorywarning
{
[Super didreceivememorywarning];
}

Add:

Two memory warning differences (compared to proxy):

Proxy memory Warning: When something happens to application (when a memory warning is received), it notifies its agent, and the agent notifies its window,window that it notifies its root controller that the root controller notifies its child controller. Memory warnings are passed down one level down (which can be validated by printing output in two places).

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

Analog Memory Warning:

Memory warning Processing diagram:

Can the view of the controller 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 on the top of the stack, the one controller's view appears on the window, and if a memory warning occurs at this time, one is not destroyed because it is on the window.

If you come back to a two controller, it creates a corresponding Twoview display on the window, one of the corresponding view is moved away, and if a memory warning occurs, then OneView is no longer displayed on the window, so it is destroyed.

Special Note: Outlet represents attributes, when the controller is created, the attribute is generally also a value, when the call-(void) Viewdidunload method, that is, the controller's view completely destroyed, all the property data will be emptied. Generally in the ios5 before, but also in this method to empty all the attributes inside.

Tip: All of the controller's methods are actually a loop.