Home > 2010 Fall DPS913 > Views, view controllers, and user interface elements

Views, view controllers, and user interface elements

September 16, 2010 Leave a comment Go to comments

This post introduces the user interface building blocks.


Views, and view controllers

A view is a rectangular area, used to display content in the user interface. That’s the general definition.

In an iOS app, a view typically displays a screen of content. If your app has many screens of content, each one is a distinct view. When the app’s flow of control requires a new screen of content, the old view is replaced by the new view. An iOS app displays one screen at a time.

The “root” of the iOS display hierarchy is a special view, called a window. Typically, there is only one window in an iOS app, and it fills the entire screen. Typically, the window displays a 20-pixel tall status bar at the top, which displays carrier information, the battery charge indicator, and so on.

A view is an instance of UIView, and it defines a rectangular area in a window. Typically, a view fills all the space available in the window (i.e. the whole area less the status bar at the top). In your iOS app project, a view is located in a nib file, and edited with Interface Builder.

A view (for screen content) is a container. It can hold subviews, each with its own content. Well-known subviews for new iOS programmers include the user interface controls (e.g. button, text field, etc.) that you can place on the view’s design surface.

Views are responsible for the following tasks:

  1. Drawing content
  2. Manage subviews (e.g. user interface controls)
  3. Receiving and processing touch events

A view is usually paired with a view controller. A view controller is a source code module that holds the processing logic for the view. It will, for example, include outlets, which point to user interface elements. It also includes methods, which handle user interaction and environment/runtime events. In summary, it manages a screenful of content.

Most of your iOS app’s logic will be contained in view controllers.

In the MVC design pattern, for an iOS app, a view controller (the “C” in MVC) mediates between your (data) model and a view.

Soon, you will learn how to work with views and view controllers, putting them together to build a complete app. You will learn how to:

  • Manage device orientation/rotation state changes
  • Create a drill-down (or master-detail) navigation-based app, which manages a series of views and view controllers
  • Create a multi-mode (or switching) tab bar-based app, which manages a set of independent views and view controllers
  • Present modal content, which must be processed before the user is returned to the main flow of your app
  • Include ready-to-present view controllers, to select an image, or an address book entry, for example
  • Create custom views, based on Core Graphics drawing functions


User interface elements

As you would expect, you can add buttons, labels, text fields, and so on, to your user interface. IB has a “Library” panel that lists the available UI elements. Most of them are visible elements, while some are objects that support or enable the visible elements.

To add a UI element to your view, select it from the IB Library panel. The Library organizes the UI elements into categories, as shown in the image of the drop-down on the right. Below that image is another, showing the elements in the “Inputs & Values” category.

You can also use the filter textbook at the bottom of the to conveniently narrow the list. When you select the desired UI element, make sure that you note what type (class) it is. You will need this type name when you write code in your view controller.

UI elements are views themselves. They are “subviews” of the parent or containing view, which typically is the full-screen view.

What about memory management – do we need to perform memory management tasks for the UI objects that are created and configured in Interface Builder? No. UI objects created in IB are initialized with an autorelease message, which means that they will be cleaned up when the view goes out of scope.

What about memory management, for the outlets that are declared in the view controller code – do we need to perform memory management on those objects? Yes. The technique was discussed in an earlier section, titled “Declaring a property for an outlet”.

See this for complete coverage:

Memory Management of Nib Objects

Note that outlets are not initialized in our view controller code. This is because they are pointers to UI objects, and those objects are initialized by the runtime when the nib is loaded.

Returning to the UI elements topic, what UI elements are available? The image to the right shows the “Inputs & Values” items, and you will use some of these in Lab 1. You will also need to use a “Text View” (UITextView), and an “Image View” (UIImageView), from the “Data Views” category.

How should UI elements be used? While you can get started on your own, and experiment with them, you should read (at some point in the near future) a document titled “iPhone Human Interface Guidelines“. That document will become a reference to you, as you learn to develop apps for iOS.


Categories: 2010 Fall DPS913
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: