Views, controllers, and user interface objects

This post introduces views, controllers, and user interface building blocks.

It was most recently updated in September 2013.


The window object

An iOS app has a window object, an instance of UIWindow. The reference documentation states:

The two principal functions of a window are to provide an area for displaying its views and to distribute events to the views. The window is the root view in the view hierarchy.

Normally, the window displays a status bar at the top (20 points in height), which displays cellular carrier information, the battery charge indicator, and so on.

An iOS app typically has only one window object. A typical app has many different screens, however. A view holds a screenful of content, and one view at a time is displayed to the user. At times, however, another view can be layered on top of a view, which happens when an alert appears for example.


View objects in iOS programs

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 screenful 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.

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 the storyboard file, and edited with the Interface Builder (IB) part of Xcode.

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


Controller objects in iOS programs

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 are declared properties that point to user interface elements. It also includes i, which handle user interaction and environment/runtime events. In summary, a view controller 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 controller (the “C” in MVC) mediates between your (data) model and a view.

The view is a property of a view controller.

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.


User interface Library

To add a UI element to your view, select it from the Xcode Library panel, which appears at the bottom of the right-side utility area, when you are editing the storyboard.

The Library organizes the UI elements into categories, accessible on the drop-down at the top.

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 (some of which are “controls”)

UI elements are views themselves. They are “subviews” of the parent or containing view, which typically is the full-screen view. Some UI elements are “controls”, which respond to user interaction, and generate events (that call methods).

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 managed by the runtime.

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 view 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 iOS Human Interface Guidelines. That document will become a reference to you, as you learn to develop apps for iOS.






  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

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

You are commenting using your 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: