a user’s interaction with an application. A UIView has an associated UIViewController. The UIViewController manages the view. The view controller loads and unloads its associated views, manages views, and handles application life cycle events for its views.
Every graphical iOS control you use in Interface Builder is a UIView subclass. Table 7-1 lists the UIView subclasses. Notice that UIScrollView and UIControl both have further subclasses
listed in the table’s second column.
UIViews function as containers, controls, displays, alerts, action sheets, and navigation controls, and also as the application’s window. In future chapters, we’ll cover most of these UIView types. This chapter limits itself to a simple display view and associated view controller.
The UIViewController manages UIViews. It is responsible for creating, displaying, hiding,
and destroying a view. The UIViewControl is also responsible for responding to a view’s life
cycle events, handling orientation, and serving as a bridge between your application’s view
and model. The view controller is your application’s controller in the model-view-controller
design pattern.
View-Based Application Template
The easiest route to creating a single view application is using Xcode’s View-based Application
template. This template creates a single view and a view controller for managing the view. While
the View-based application is not as useful as Xcode’s other project templates, it is helpful here,
as it generates the simplest iOS graphical application and provides a straightforward UIView and
UIViewController example. In the next task, you will generate an application using this template.
But, before continuing, first we will review IBOutlets and IBActions.
IBOutlet and IBAction
You have already used IBOutlets and IBActions in previous chapters. Without really knowing
what they are, you probably already have a good idea of what they accomplish; outlets and
actions are how you connect things in a nib with things outside a nib. An outlet connects an
instance variable outside a nib to an object in a nib.
IBOutlet is a preprocessor directive, evaluates to void, and is ignored by the compiler,
but all you really need to know is that IBOutlet is how Interface Builder knows the
variable was created for its use. When you change the class of an object, Interface Builder
scans the class for IBOutlets and knows those variables are intended as outlets. You can
then easily connect your graphical component to the variable, as Interface Builder adds
the outlets to the inspector automatically for you to select. Note, though, Interface Builder
doesn’t connect the outlets to anything; it just adds them. You are responsible for adding
any connections.
Actions are messages sent from objects in the nib to methods outside the nib. You define
an action in your code using the IBAction keyword. Like IBOutlet, it’s a preprocessor directive
and evaluates to void. You define an action in your code using the IBAction keyword. Also,
like IBOutlet, when you assign a class to a control in Interface Builder, it scans the class for
IBActions and adds them to the inspector for you to select. You can then connect user interface
events to a specific method in your code. Note that a method designated as an action must not
return a value, as the preprocessor replaces IBAction with void, and so all the compiler sees is
void. An action also takes a single parameter, sender. The sender is the id of the control calling
the action. So if a UIButton instance called an IBAction named changeLabelValue, the sender
would be the pointer to the UIButton.
-(IBAction) changeLabelValue: (id) sender;
IBOutlet and IBAction don’t require much explanation, as you use these two directives so
frequently they become second nature. Any instance variable external to Interface Builder that
must communicate with a control in Interface Builder must be an IBOutlet. Any method that
must be called from a control in Interface Builder must be an IBAction.
No comments:
Post a Comment