Lighter View Controllers

Light View Controllers

*Separate Out Data Source and Other Protocol

*The nice thing is that we can test this class separately, and never have to worry about writing it again. The same principle applies if you use something else other than arrays.

In one of the applications we were working on this year, we made heavy use of Core Data. We created a similar class, but instead of being backed by an array, it is backed by a fetched results controller. It implements all the logic for animating the updates, doing section headers, and deletion. You can then create an instance of this object and feed it a fetch request and a block for configuring the cell, and the rest will be taken care of. 

*Move Domain Logic into the Model.

Some code cannot be easily moved into a model object but is still clearly associated with model code, and for this, we can use a Store. The store can take care of data loading, caching, and setting up the database stack. This store is also often called a service layer or a repository. 

*Move Web Service Logic to the Model Layer.

*Move View Code into the View Layer.

*We often have the problem where one view controller has some state and communicates with multiple other view controllers. Often, it then makes sense to put this state into a separate object and pass it around the view controllers, which then all observe and modify that state. The advantage is that it's all in one place, and we don't end up entangled in nested delegate callbacks. 

Clean Table View Code

*Table view controllers have one unique selling point over standard view controllers, and that's the support for Apple's implementation for "pull to refresh." At the moment, the only documented way of using gUIRefreshControl is within a table view controller. There are ways to make it work in other contexts, but these could easily not work with the next iOS update.

*Instead of getting rid of the table view controller entirely, you could also add it as a child view controller to another view controller. Then the table view controller continues to manage only the table view and the parent view controller can take care of whatever additional interface elements you might need.

*In cases where we have multiple model objects that can be presented using the same cell type, we can even go one step further to gain reusability of the cell. First, we define a protocol on the cell to which an object must conform in order to be displayed by this cell type. Then we simply change the configure method in the cell category to accept any object conforming to this protocol. These simple steps decouple the cell from any specific model object and make it applicable to different data types.

Test View Controllers

*When we break things up into small components(i.e. small classes), we can test each class on its own. The class that we're testing interacts with other classes. We get around this by using a so-called mock or stub. Think of a mock object as a placeholder. The class we're testing will interact with placeholders instead of real objects. That way, we focus our test and ensure that it doesn't depend on other parts of our app. 跳过

*View Controller Containment

*

 [self addChildViewController:_startMapViewController];          //  1

    [topContainer addSubview:_startMapViewController.view];         //  2

    [_startMapViewController didMoveToParentViewController:self];   //  3

1. The _startMapViewController is added as a child of the root view controller. This automatically calls the method willMoveToParentViewController: on the child.

2. The child's view is added as a subview of the first container view.

3. The child is notified that is now has a parent view controller.

*

        toController.view.frame = fromController.view.bounds;                           //  1

        [self addChildViewController:toController];                                     //

        [fromController willMoveToParentViewController:nil];                            //

        

        [self transitionFromViewController:fromController

                          toViewController:toController

                                  duration:0.2

                                   options:direction | UIViewAnimationOptionCurveEaseIn

                                animations:nil

                                completion:^(BOOL finished) {

                                    

                                    [toController didMoveToParentViewController:self];  //  2

                                    [fromController removeFromParentViewController];    //  3

                                    [infoButton setEnabled:YES];

                                }];

1. Before the animation we add the toController as a child and we inform the fromController that it will be removed. If the fromController's view is part of the container's view hierarchy, this is where viewWillDisappear: is called.

2. toController is informed of its new parent, and appropriate view event methods will be called.

3. The fromController is removed.

This convenience method for view controller transitions automatically swaps out the old view controller's view for the new one. However, if you implement your own transition and you wish to only display one view at a time, you have to call removeFromSuperview on the old view and addSubview: for the new view yourself. Getting the sequence of method calls wrong will most likely result in an UIViewControllerHierarchyInconsistency warning. For example, this will happen if you call didMoveToParentViewController: before you added the view.