Let’s talk about view controller containers. More and more, developers are using non-standard user interfaces for organizing their screens in an iOS applications.
As these interfaces become more involved, programmers can fall into the trap of making their code more complex – which leads to more complex problems in debugging, maintenance and usability.
Such pitfalls include: not leveraging view controller hierarchies properly, cramming too many views and functionality into a single view controller, leaking container responsibilities to child view controllers, tightly coupling child view controllers with their parent and introducing intermediate abstract view controller classes to make containers mesh with their children. Or, just plain avoiding view controllers altogether.
This article will serve as the first part to a multi-part series that covers implementing view controller containers and taking advantage of animated transitions. In the first installment, we’ll lay the foundation for some terminology we’ll use throughout the series by reviewing existing view controller containers.
To warrant the creation of a custom view controller container, you must want to modify at least one of these three things:
- The organization and traversal of view controllers in the container.
- The layout of each view controller’s view.
- The built-in interface element for swapping view controllers.
These ‘Big 3’ concepts and their terminology (organization and traversal, layout and animation, and built-in interface) will become central to our discussion of view controller containers.
Container Organization and Traversal
There are two standard view controller containers that you will see in nearly every application, UINavigationController and UITabBarController. These two take a different approach to the organization and traversal of their view controllers. Organization doesn’t refer to the layout of their views on the screen, but rather, if you were to draw the contained view controllers in a diagram, what standard data structure would best describe the organization of the view controllers?
Tab bar controllers organize their view controllers in a list. Each view controller in the list can be switched to at any time and doesn’t rely on any other view controller in the list.
A navigation controller organizes its view controllers in a tree. (We always hear that a navigation controller maintains a stack of view controllers, but that’s just the implementation of its storage and how it is manipulated.) View controllers in a navigation controller’s tree are related in some way; either as steps in the same process or different levels of detail for the same information. A view controller in the tree determines the next level of possible view controllers and can only return to the view controller above it in the tree.
As it turns out, trees and lists cover nearly every view controller organization and traversal scheme we can think of. When creating our own view controller containers, we are unlikely to think up a container that organizes its view controllers differently than UINavigationController and UITabBarController. Although, you may be more clever than I and could look at a list of data structures and find a new and interesting way to organize view controllers – like a graph or matrix.
A view controller container determines where the views of its view controllers appear. Containers like tab bar and navigation controllers have nearly identical layouts: there is one “active” view controller that is visible, and the controls for the container view controller (the navigation bar or tab bar) are always visible.
UISplitViewControllers are a type of container view controller that takes a different approach regarding layout. Instead of one view controller being visible at a time, a split view controller shows two view controllers side-by-side.
The layout of a view controller container is one place where we have the opportunity to be creative in our own custom containers. Consider the Facebook iOS application – swiping the main view controller left reveals a chat panel on the right side. This panel is its own view controller. The layout is similar to that of a UISplitViewController, but different enough to warrant the creation of a custom container view controller.
Notice, here, that this container contains another container: the main view view controller is a UITabBarController with its own view controller list. This chaining together of containers works well when we follow all of the rules in implementing our own containers.
A navigation controller also implements its own slide animation when pushing or popping view controllers. A tab bar controller has no inherent animation. However, both of these containers allow you to customize the animation when transitioning to a new view controller. Customizing this animation will be covered later in this series.
Container Built-In Interface
The final item that would warrant a custom container is a container’s built-in interface. The built-in interface of a container view controller is a view (or views) controlled by the container itself. Typically, the built-in interface allows the user to transition to another view controller in the container.
A tab bar controller, for example, displays a tab bar. This bar is the interface for navigating through each view controller. Likewise, a navigation controller has a navigation bar. (A split view controller, on the other hand, has no built-in interface and only displays the view’s of its contained view controllers.)
The built-in interface is perhaps the most common area of customization. As an example, the Richtree Markets application uses a navigation bar with a drop-down menu to navigate between different view controllers.
The organization and traversal of this container is identical to the UITabBarController. The layout, too, is similar – the active view controller’s view and the interface for switching to another view controller. However, the interface for switching view controllers – the drop down menu – is much different.
Armed with our three concepts and terminology, we’ll use the next article to implement a brand new view controller container. Stay tuned.