iOS Rage Path---View controller (uiviewcontroller) usage explained

First, preface

In a previous article, we've covered what you can learn from the first app in iOS. In that article, we mainly introduced the startup process of an iOS program and the application of several objects, as well as the life cycle of the application, also introduced the application of the controller knowledge Point, introduced its life cycle method, So for an iOS app will generally contain multiple pages, and each page is a controller, a controller is generally related to a uiview, but we actually use these controllers when we find that the jump relationship between multiple pages how to control. In the previous article know that an application corresponds to a Window object UIWindow, each window has a root controller object, so if an application has more than one controller how to manage these controllers? So that is the focus of this article needs to be introduced.

Two, two view controllers

In Android we know that each page is an activity, and that the jumps and communications between each page are delivered using the intent object, and that there is no such mechanism in iOS, and that managing multiple controllers in iOS is generally two kinds of controllers:

One is the switch controller Uitabbarcontroller, one is the navigation controller Uinavigationcontroller

Although the two controllers manage multiple controllers, they are also a controller class, and both have their own usage scenarios.

1, Uitabbarcontroller is generally used in the home page switch, for example, the homepage of the Four tab switch is to use this controller management:

This is somewhat similar to the functionality implemented by Viewpager+fragment in Android.

2, Uinavigationcontroller is generally used to jump from one controller page to another page controller, which is very similar to the activity jump in Android. And it's one of the most used scenes.

three, switch controller Uitabbarcontroller

Let's introduce the first controller management class: Uitabbarcontroller class, first of all to say, or the same old, first set up a simple case:

Select the parent class that needs to inherit uitabbarcontroller, in fact, he is also a controller:

Then we need to set up this controller as a root controller and then manage the following added sub-controller content through this controller:

To set up the root controller in the same way as before in the Appdelegate callback method, the following is the beginning of adding a child controller:

Since more than one sub-controller is required to operate the case, a new two controller class is created, and then the Tabbaritem property of the sub-controller is set after initialization, which represents the child controller's item style property in Uitabbarcontroller. Of course, here in order to simply use some of the system provided by the style, you can also customize their own style, this after the introduction of specific items when the time again, in fact, it is not difficult to use some properties. After the initialization is complete, all the sub-controllers are added to a nsarray, and the final is set to Uitabbarcontroller. Here's a look at the effect:

See the bottom there are two can toggle item, see their style is the system corresponding to the contact and more styles, of course, we can customize such a style, you can set the item's picture and text. This is not a demonstration.

Here we will find that the controller is really similar to the viewpager+fragment in Android, so the problem is that when we use Viewpager+fragment for Android, Simply adding a sub-controller is not enough, we generally need to know something, here are two main things:

First thing: Switching events between each sub-controller, which is the callback event for tab switching

The second thing: the life cycle of each sub-controller changes in the process of switching

So here's a look at these two things in more detail, first of all: how to listen for switching events between each sub-controller

This is also very similar to Android, which is to add Proxy method to the switch controller, of course, in Android is called callback method. Adding a proxy here is simple:

Because we define the controller in the Appdelegate class, we need the Appdelegate class to implement the proxy protocol: Uitabbarcontrollerdelegate, we can implement several proxy methods after implementation:

The first method: This proxy method is called after the child controller switch is complete, the parameters are returned is the currently selected sub-controller.

-(void) Tabbarcontroller: ( Uitabbarcontroller *) Tabbarcontroller Didselectviewcontroller: (uiviewcontroller *) Viewcontroller

The second method: This proxy method is to determine whether the current sub-controller can be selected, if the return of Yes indicates can be selected, if the return no means not to be selected, that is, the operation is not switchable.

-(BOOL) Tabbarcontroller: (uitabbarcontroller *) Tabbarcontroller Shouldselectviewcontroller: (uiviewcontroller *) Viewcontroller

Of course, there are other proxy methods, which are not described in detail here, because these two methods in the actual development of the use of the most. Here, by the way, let's talk about the two common properties of this controller:

The first property: SelectedIndex represents the index value that gets to the currently selected sub-controller, which can read and write operations, that is, the index value can be set to determine which controller is currently selected. It is generally determined at the time of initialization which controller is currently selected by default.

The second property: Selectedviewcontroller represents the currently selected sub-controller, this property is also read and write operation, in fact, his function and the above index value function is similar, just one is the operator sub-controller index value, One is to manipulate the child controller object directly.

With these two properties in combination with the above two proxy methods can meet our development needs.

The second thing to solve next is how the various sub-controllers will change their life cycle during the switchover, in fact we have introduced the controller lifecycle approach in the previous article:

When 1> view is initialized, the controller's Viewdidload method is called
When the 2> view is initialized, the view of the root controller is added to the window
3> The controller's viewwillappear is called when the view is about to be added to the window: method
4> when the view has been added to the window, the controller's viewdidappear is called: method
5> if the controller's view is about to be removed from the window, the controller's viewwilldisappear is called: method
6> if the controller's view has been removed from the window, the controller's viewdiddisappear is called: method
7> if the controller receives a memory warning, the controller's Didreceivememorywarning method is called
The default implementation of the Didreceivememorywarning method is that if the controller's view is not displayed in the window, that is, Controller.view.superview is nil, the system destroys the controller's view.
8> the controller's Viewdidunload method is called after the destruction is complete
9> if the controller's view was previously destroyed because of a memory warning and now needs to access the controller's view again, the previous steps are repeated to initialize the view

Here we mainly take a look at the Viewwillappear,viewdidappear,viewwilldisapper,viewdiddisappear method, other methods may not be used here. To make it easier to see the effect, we can define a Baseviewcontroller class, add log information to its lifecycle method, and finally let the child controller inherit the class, so that the life cycle method of each child controller can be found:

Here to see how we add the log information, first need to know which sub-controller so need to print the name of the sub-controller, you can use the Self keyword, and then the method name, here because do not want to manually write the method name, so use Nsstringfromselector (_cmd ) to get the name of the current method.

Let's run the program again and then switch the sub controller multiple times to see the effect:

We can get three important information from the log:

The first message: when a sub-controller calls the Viewdidload proxy method only when it is to be displayed, and sees the beginning, this method of the second sub-controller is not mobilized, and when I switch to the second controller, the display is called, Can be understood as lazy loading mechanism. Use to load the view.

The second message: The View Load Agent method for each sub-controller viedidload will only be called once, that is, the first time the show, the next show will not be called again, of course, this is not absolute, for example, if the system memory is insufficient, will be recycled some resources, Then the controller may be recycled at this point, then the next time you switch to this sub-controller will still call his load method, but most of the time is called only once.

The third message: The message that we care about most is that each sub-controller will call back the viewdidappear,viewdiddisappear in the process of switching to and fro. So if we need to do something, we're going to do it in these two proxy methods.

When we get here, we're done with the first controller management class Uitabbarcontroller in iOS, and he's really similar to viewpager+fragment in Android, We can get some of the information we want in the actual development of iOS from our use of Android, here are two things: the first thing is to switch the callback is the proxy method, and the second thing is how the life cycle of each sub-controller changes during the switchover. Finally, there are several important properties, such as how to get the current switch to which sub-controller, how to manually set to the default choice of which sub-controller to wait. With this information we can meet the normal development of the program. Then we will introduce a controller management class, this class in the actual development used more.

four, navigation controller Uinavigationcontroller

Navigation controller Uinavigationcontroller class in the actual development process may use more, generally from one page to another page to use this controller, we still like the above steps, the beginning of the simple new one this controller, Remember to inherit the Uinavigationcontroller class:

He's actually a controller:

Once defined, we can set the root controller class of the application window controller in the Appdelegate callback method:

There is a difference between this and Uitabbarcontroller, this controller is actually very similar to the activity of Android, because this is also a stack structure, all the activity in Android has a stack structure to maintain. But here is simpler than Android, there is not so many complex boot mode, just remember to use the stack structure to maintain the controller in the application. Then the operation of the stack is out of the stack and into the stack, and here the top of the controller is displayed in the current application, so if we want to enter a page, then only need to put the controller page into the stack, if you want to return directly out of the stack.

Below we still use the above two sub-controller as a case to operate, at the beginning, we put the first sub-controller into the stack to show:

See the top there are two options, in fact, this is the navigation controller for each sub-controller of a navigation item header settings, this item generally includes the title, the left item, the right item, and these items are similar to the previous TabItem, have icon and text. Here we add a click event to the right item, click to jump to the second controller, in the second controller's navigation item to add the left item click event, click on the return:

In the first sub-controller, we set the navigation item title content, left and right item content, here still adopted the system style, and then added the click event, and after the click to jump to the second sub-controller is also directly into the stack operation can, here need to note is that, For each child controller, you can use the Navigationcontroller property to get his navigation controller object, and then you can manipulate the stack. From here can also be seen, in the first controller must use the second controller so need to import the class definition, while we generally need to carry data when jumping, then this can be directly through the second controller object of some methods set. This is not the same as Android, you can bundle the data into bundle object packaging sent past.

In the second sub-controller, we did not define the navigation item, but we still see that this is the system default effect, of course, we can not, but generally will be preserved. Of course we also simulated the effect of click-back:

We can see here that the navigation controller provides three ways to stack, and here's a look at the three differences:

1, popviewcontrolleranimated:

This method is the most we use, is directly out of the stack operation, equivalent to delete the Stack top object, then there is the effect of the return.

2, poptorootviewcontrolleranimated:

This method to see the name can be known is also out of the stack, but he went very thoroughly, directly back to the bottom of the stack, the sub-controller is out of the stack.

3, poptoviewcontroller:animated:

This method to see a number of parameters, also said can be out of the stack to the specified controller location, that is, the controller before the designated controllers are drawn stack.

Actually seeing these three ways is very similar to the startup mode of activity in Android.

The first method corresponds to the Singletop boot mode in Android

The second method corresponds to the Singletask boot mode in Android

The third method corresponds to the singleinstance boot mode in Android

Of course, this is just for the sake of understanding, and the comparison with Android, you can find that is not exactly the same. However, these three kinds of stack-up methods are also very well understood, because they are three ways to meet all of our development of the requirements of the stack.

Look at the next piece of code, the execution of a proxy object method, in fact, this is to do the current sub-controller returned after the need to carry some return data to the previous sub-controller function, then why not here in this sub-controller class to import the first child controller definition, And then call its method directly to get the return data? In fact, think about it, because we know there's only one way to jump from one controller to the next. So the import is not related, but if the return from a controller to the previous controller has multiple paths, because the controller may be multiple controllers to jump over, if you need to return a value, you need to import each jump over the controller definition, it is conceivable that this sub-controller class will become very large and coupled. So here we can define a protocol in the second controller, all need to jump over the controller can implement this protocol, and then in the second controller can be very flexible to call this ID type object of the specified method, the return value function.

In return, the first to determine whether the proxy object has a corresponding proxy method, and some words will begin to call.

As with the previous switch controller, there are two things we need to solve when using the navigation controller:

First thing: The proxy method of the sub-controller on the stack and the stack

The second thing: The life cycle changes of the sub-controller at the time of the stack and the stack

Let's take a look at the first thing, and just as before, here we also need to implement a protocol: Uinavigationcontrollerdelegate, or the Appdelegate class needs to be implemented.

The first method: The function of this proxy method is about to show which controller, that is, into the stack operation.

-(void) Navigationcontroller: ( Uinavigationcontroller *) Navigationcontroller Willshowviewcontroller: (uiviewcontroller *) Viewcontroller Animated: (BOOL) animated

The second method: The function of this proxy method is which controller is displayed, that is, the stack top controller.

-(void) Navigationcontroller: ( Uinavigationcontroller *) Navigationcontroller Didshowviewcontroller: (uiviewcontroller *) Viewcontroller animated: ( BOOL) animated

Therefore, from these two methods can be seen, these proxy methods are actually listening stack top changes, if the stack top controller changes after the callback method.

Let's continue to look at the second thing, because we use the above sub-controller, so the log is added, we can switch back and forth several times to see the effect:

From the life cycle can be seen, and the above switch controller, each sub-controller is lazy loading mechanism, with the display to take to load, will only call Viewdiddisappear and Viewdidappear methods. From the log we can also see that we can get the data from the upper controller correctly, and we can get the data returned from the previous controller.

v. Summary of view Controller

Here we introduce the two controller management classes commonly used in iOS, that is, the effect of jump switching between multiple controllers in an application. Here's a summary:

First: Switch controller Uitabbarcontroller

This controller is generally used for the first page of the Switch tab function, such as the effect, he and Android viewpager+fragment combination of the effect is very similar to the use of the process, you need to use a sub-controller array to hold all the sub-controller. Then there is a corresponding callback proxy method for the switching operation between each sub-controller,

1, monitor to switch to which sub-controller

2, you can specify a return value to set which sub-controller is not switchable selection

The life cycle method for each of the sub-controllers in this process is:

1, all the sub-controllers are lazy loading mechanism, need to show the time to load

2, if the child controller has been loaded the next time you switch again will only call Viewdidappear and Viewdiddisapper methods such as

Finally, there are two important attributes:

1, the first attribute is the index value of the currently selected sub-controller, this value can be read and written, this value can be set by default to select which child controller

2, the second property is the currently selected sub-controller object, this value can read and write

For each child controller there is a property: Tabbarcontroller can get to the current switch controller object.

The second one: Navigation controller Uinavigationcontroller

This controller uses more, generally for the program's multiple sub-controller jumps between, this controller has a special place is that he uses the stack structure to manage the sub-controller, which is very similar to the activity in Android, but also using the stack structure. Then for the jump is the stack operation, the return is the stack operation. The operation is also very simple. The same here we are in the operation of the time there are two things to know, one is the various sub-controllers in the jump when the callback proxy method:

1, listen to the current stack top change callback proxy method

There is also the need to know the life cycle method changes for each of the sub-controllers:

1, all the sub-controllers are lazy loading mechanism, need to show the time to load.

2, if the child controller has been loaded the next time you switch again will only call Viewdidappear and Viewdiddisapper methods such as

It is then important to note that there are three ways to get out of the stack:

1>, popviewcontrolleranimated:

This method is the most we use, is directly out of the stack operation, equivalent to delete the Stack top object, then there is the effect of the return.

2>, poptorootviewcontrolleranimated:

This method to see the name can be known is also out of the stack, but he went very thoroughly, directly back to the bottom of the stack, the sub-controller is out of the stack.

3>, poptoviewcontroller:animated:

This method to see a number of parameters, also said can be out of the stack to the specified controller location, that is, the controller before the designated controllers are drawn stack.

There are three ways to get started in Android, and there are three ways to meet our daily development needs.

Finally, each sub-controller can get to the navigation controller object through the Navigationcontroller property

Project: http://download.csdn.net/detail/jiangwei0910410003/9667736

Vii. Summary

This article introduces the Controller management class in iOS, mainly to solve the problem of switching and jumping between multiple sub-controllers in an application, the operation in iOS is very simple, not so complicated as Android. With this knowledge, we can easily develop an application, the application can contain multiple controller pages, and then need to do is the content of each controller display, that is, the corresponding specific uiview. This will be something that we need to cover in detail later in this article.

Click here for more information:

Focus on the public, the latest technology dry real-time push

Sweep and make a small series
Add the Note: "Code beautiful" or not pass!

iOS Rage Path---View controller (uiviewcontroller) usage explained