Monday, May 31, 2010

Iphone - View Controllers

View controllers are one of the most fundamental building blocks of Iphone applications. How you implement the view controllers in you application determines how information is displayed to the user over multiple screens, or even within the limited space of one screen. They allow you to manage the showing and hiding of information within one screen as well as switching back and forth between screens. This article is a general overview of view controllers and has special focus on the Navigation View Controller.

There are three types of view controllers:
- Custom View Controller
- Container View Controller
- Modal View Controller

Custom View Controllers are controller objects that manage the content of one screen. Most applications will have several screens that display different information, each of these can have its own view controller that manages the presentation of data for that particular screen only.

A Container View Controller on the other hand controls other View Controllers. These are used to define navigation between several different views. A Navigation View Controller and Tab Bar View Controller are examples of Container View Controllers.

The diagram below shows an example interface with three different views that the user can navigate back and forth between, as well as a portion of the screen being used to navigate between four other views.
There are several ways the diagram's flow could be achieved in an application. Lets say we decide to go down the following scenario:

  • Each of the 7 views gets its own custom view controller.
  • Implement a main navigation controller using UINavigationController class provided by the system. This allows us to go back and forth between the three main views.
  • For the four views, that only change a potion of the screen, we have two different options: Implement a UITabBar class in the central view, that switches between the four views or display the Toolbar that is defined within the UINavigationController class. Note that we cannot use the UITabBarController class at this point since the programming guideline prohibits incorporating a UITabBarController into a UINavigationController. However, the guideline does allow having a UINavigationController within a UITabBarController.
The UINavigationViewController is an amazing class that maintains track of a navigation stack. It contains several views that help define a navigation interface: Navigation Bar, Navigation View, Custom Content and the hidden by default Navigation Toolbar. The content of the Navigation bar and Toolbar can be customized however these views do not change. The only view that changes is the Custom Content view. This view always shows the view of the view controller that is at the top of the navigation stack.

The Navigation Bar already has a default back button defined, which displays the name of the previous view's title. If the previous view has no title then the button displays "back" by default. The behavior for this button is already defined and clicking it changes the view to the previous view. Very convenient. Sadly, if the previous view had a title the button says the title of the page and you cannot simply change the text to say "back" or any other custom text. You actually have to define a custom UIBarButtonItem and assign it to the leftBarButtonItem property of the Navigation Bar. This also means that you have to define the behavior of the button as well. The middle of the Navigation Bar generally displays the view title. You can specify a custom title by setting the titleView Property of the Navigation Bar. The right side of the Navigation Bar by default displays nothing unless the rightBarButtonItem property has been set to a custom UIBarButtonItem. The rightBarButtonItem property is often used to specify a next button or a cancel button, all you have to do is put the next view on top of the navigation stack for the controller to know which view to load.

For navigating between the four sub views we used the UITabBar class. The UITabBar class allows you to define two or more tab items, clicking on which changes the selected view. The issue to note here is that placing a view within a view required a lot of fine tuning sizing wise. Even if the views properties for auto sizing are set they didn't always render correctly within each other and we had to specify size in code. Even though we were successful with this avenue, in the end it was easier and cleaner to repeat in each of the four sub views the content of the central view that was common to them and switch the whole of the central with one of these four when a Tab Bar Item was clicked.

I hope you found this introduction / summary helpful. Choosing the path that best suits your application is very important and can have many challenges: unavailable options, rules and regulations, time for fine tuning etc. This is a decision that could determine how much re-work or re-design you may have to do later on in the project.

References and recommended reading:

No comments:

Post a Comment