Let’s
get it out of the way up front: Yes, Interface Builder (or IB for
short) does help you create interfaces for your applications, but it
isn’t a just a drawing tool for GUIs; it helps you symbolically build
application functionality without writing code. This translates to
fewer bugs, less development time, and easier-to-maintain projects!
By the Way
At the time this book was
being written, Apple began previewing a new version of their developer
tools—Xcode 4. In Xcode 4, Interface Builder is part of the development
suite, not a standalone application. We are providing an introduction
to Xcode 4’s tools in a downloadable document at http://teachyourselfiphone.com.
If you are a beginner, I
recommend using the Xcode 3.2 toolset for the time being. It is time
tested and, at least compared to the early previews of Xcode 4,
includes coding features, such as bookmarks, that Xcode 4 does not.
The Interface Builder Approach
Using Xcode and the
Cocoa toolset, you can program iPhone interfaces by hand—instantiating
interface objects, defining where they appear on the screen, setting
any attributes for the object, and, finally, making them visible. For
example, in “Introduction to Xcode and the iPhone Simulator", you entered this listing into Xcode to make your iPhone display the text Hello Xcode in the middle of the screen:
myMessage=[[UILabel alloc] initWithFrame:CGRectMake(25.0,225.0,300.0,50.0)];
myMessage.text=@"Hello Xcode";
myMessage.font=[UIFont systemFontOfSize:48];
[window addSubview:myMessage];
[myMessage release];
Imagine how long it
would take to build interfaces with text, buttons, images, and dozens
of other controls—and think of all the code you’d need to wade through
just to make small changes!
Over the years,
there have been many different approaches to graphical interface
builders. One of the most common implementations is to enable the user
to “draw” an interface, but, behind the scenes, create the code that
generates that interface. Any tweaks require the code to be edited by
hand—hardly an acceptable situation.
Another tactic is to
maintain the interface definition symbolically, but to attach the code
that implements functionality directly to interface elements. This,
unfortunately, means that if you want to change your interface, or swap
functionality from one UI element to another, you have to move the code
as well.
Interface Builder
works differently. Instead of autogenerating interface code or tying
source listings directly to interface elements, IB builds live objects
that connect to your application code through simple links called connections.
Want to change how a feature of your app is triggered? Just change the
connection. As you’ll learn a bit later, changing how your application
works with the objects you create in Interface Builder is, quite
literally, a matter of connecting or reconnecting the dots as you see
fit.
The Anatomy of an Interface Builder XIB File
Your work in Interface Builder results
in an XML file called an XIB or (for legacy reasons) NIB file,
containing a hierarchy of objects. The objects could be interface
elements—buttons, toggle switches, and so forth—but might also be other
noninterface objects that you need to use in your app. When the XIB
file is loaded by your application, the objects described in it are
instantiated and can be accessed by your code.
By the Way
Instantiation,
just as a quick refresher, is the process of creating an instance of an
object that you can work with in your program. An instantiated object
gains all the functionality described by its class. Buttons, for
example, automatically highlight when clicked, content views scroll,
and so on.
The Document Window
What do XIB files look like in IB? The contents of the
file are shown in the IB “Document” window (see Figure 1).
By the Way
If you do not see a window
with icons when opening the XIB file, choose Window, Document to ensure
that the Document window is active and visible on your screen.
In this sample file,
three icons are initially visible: File’s Owner, First Responder, and
View. The first two are special icons used to represent unique objects
in our application; these will be present in all XIB files that you
work with:
File’s Owner:
The File’s Owner icon denotes the object that loads the XIB file in
your running application. This is the object that effectively
instantiates all the other objects described in the XIB file. For
example, you may have an interface defined in myInterface.xib, which is
loaded by an object you’ve written called myInterfaceController. In this case, the File’s Owner would represent the myInterfaceController object.
First Responder:
The first responder icon stands for the object that the user is
currently interacting with. When a user works with an iPhone
application, multiple objects could potentially respond to the various
gestures or keystrokes that the user creates. The first responder is
the object currently in control and interacting with the user. A text
field that the user is typing into, for example, would be the first
responder until the user moves to another field or control.
View:
The view icon is an instance of the object UIView and represents the
visual layout that will be loaded and displayed on the iPhone’s screen.
You can double-click view icons to open and edit them with the IB
tools, as shown in Figure 2.
Views are hierarchical in nature. This means that as you add controls to your interface, they will be contained within
the view. You can even add views within views to cluster controls or
create visual elements that can be shown or hidden as a group. Because
a view can contain many other objects, I recommend using the list or
column view of the Document window to make sure that you can view the
full hierarchy of objects you’ve created in an XIB file. To change the
document view, click the view mode icon on the Document window toolbar
(see Figure 3).
Did You Know?
At its most basic level, a view (UIView)
is a rectangular region that can contain content and respond to user
events (touches and so forth). All the controls (buttons, fields, and
so on) that you’ll add to a view are, in fact, subclasses of UIView.
This isn’t necessarily something you need to be worried about, except
that you’ll be encountering documentation that refers to buttons and
other interface elements referred to as subviews and the views that contain them as superviews.
Just keep in the back of your
mind that pretty much everything you see on the iPhone screen can be
considered a “view” and the terminology will seem a little less alien.
Working with the Document Icons
The Document window shows
icons for objects in your application, but what good are they? Aside
from presenting a nice list, do the Document window icons provide any
functionality?
Absolutely! These icons give
you a visual means of referring to the objects they represent. You will
interact with the icons by dragging to and from them to create the
connections that drive your application’s features.
Consider an onscreen control,
such as a button, that needs to be able to trigger an action in your
code. By dragging from the button to the File’s Owner icon, you can
create a connection from the GUI element you’ve drawn to a method
you’ve written in the object that loaded the XIB file.
We’ll go through a hands-on
example later this hour so that you can get a feel for how this works.
Before we do that, however, let’s take a look at how you go about
turning a blank view into an interface masterpiece.
