Exploring Xcode's Interface Builder
- Understanding Interface Builder
- Creating User Interfaces
- Customizing the Interface Appearance
- Connecting to Code
- Further Exploration
- Summary
- Q&A
- Workshop
This chapter is from the book
This chapter is from the book
This chapter is from the book
Over the past few hours, you’ve become familiar with the core iOS technologies, Xcode projects, and iOS Simulator. Although these are certainly important skills for becoming a successful developer, there’s nothing quite like laying out your first iOS application interface and watching it come to life in your hands.
This hour introduces you to Interface Builder: the remarkable user interface editor integrated into Xcode. Interface Builder provides a visual approach to application interface design that is fun, intuitive, and deceptively powerful.
Understanding Interface Builder
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.
If you read through Apple’s developer documentation, you’ll see Interface Builder referred to as an “editor” within Xcode. This is a bit of an oversimplification of a tool that previously existed as a standalone application in the Apple Developer Suite. An understanding of IB and its use is as fundamentally important to iOS development as Objective-C. Without Interface Builder, creating the most basic interactive applications would be an exercise in frustration.
This hour focuses on navigating Interface Builder and will be key to your success in the rest of the book. In Hour 6, “Model-View-Controller Application Design,” you combine what you’ve learned about Xcode projects, the code editor, Interface Builder, and iOS Simulator for the first time. So, stay alert and keep reading.
The Interface Builder Approach
Using Xcode and the Cocoa toolset, you can program iOS 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 Hour 2, “Introduction to Xcode and the iOS Simulator,” you entered this listing into Xcode to make your iDevice display the text Hello Xcode in the corner of the screen:
UILabel *myMessage; myMessage=[[UILabelalloc]initWithFrame:CGRectMake(30.0,50.0,300.0,50.0)]; myMessage.font=[UIFontsystemFontOfSize:48]; myMessage.text=@"Hello Xcode"; myMessage.textColor= [UIColorcolorWithPatternImage:[UIImageimageNamed:@"Background.png"]]; [self.windowaddSubview:myMessage];
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 all 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 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 this hour, 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 Storyboard
Your work in Interface Builder results in an XML file called a storyboard, containing a hierarchy of objects for each unique screen that your application is going to display. The objects could be interface elements—buttons, toggle switches, and so forth—but might also be other noninterface objects that you will need to use. The collection of objects for a specific display is called a scene. Storyboards can hold as many scenes as you need, and even link them together visually via segues.
For example, a simple recipe application might have one scene that consists of a list of recipes the user can choose from. A second scene may contain the details for making a selected recipe. The recipe list could be set to segue to the detail view with a fancy fade-out/fade-in effect when the name of a recipe is touched. All of this functionality can be described visually in an application’s storyboard file.
Storyboards aren’t just about cool visuals, however. They also help you create usable objects without having to allocate or initialize them manually. When a scene in a storyboard file is loaded by your application, the objects described in it are instantiated and can be accessed by your code.
The Storyboard Document Outline
What do storyboard files look like in IB? Open the Hour 5 Projects folder and double-click the file Empty.storyboard to open Interface Builder and display a barebones storyboard file. The contents of the file are shown visually in the IB Editor area, and hierarchically by scene in the Document Outline area located in the column to the left of the Editor area (see Figure 5.1).
){kind=link}
)
Figure 5.1. A storyboard scene’s objects are represented by icons.
Note that there is only a single scene in the file: view controller scene. Single-scene storyboards will be the starting place for much of your interface work in this book because they provide plenty of room for collecting user input and displaying output. We explore multi-scene storyboards beginning in Hour 11, “Implementing Multiple Scenes and Popovers.”
Three icons are visible in the view controller scene: First Responder, View Controller, and View. The first two are special icons used to represent unique noninterface objects in our application; these will be present in all storyboard scenes that you work with:
- First Responder: The first responder stands for the object that the user is currently interacting with. When a user works with an iOS 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 Controller: The View Controller denotes the object that loads and interacts with a storyboard scene in your running application. This is the object that effectively instantiates all the other objects described within a scene. You’ll learn more about the relationship between user interfaces and view controllers in Hour 6.
- View: The View icon is an instance of the object UIView and represents the visual layout that will be loaded by the view controller and displayed on the iOS device’s screen. 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.
As you build your user interfaces, the list of objects within your scenes will grow accordingly. Some user interfaces may consist of dozens of different objects, leading to rather busy and complex scenes, as demonstrated in Figure 5.2.
){kind=link}
)
Figure 5.2. Storyboard scenes and their associated views can grow quite large and complex.
You can collapse or expand your hierarchy of views within the Document Outline area to help manage the information overload that you are bound to experience as your applications become more advanced.
Working with the Document Outline Area Objects
The Document Outline area shows icons for objects in your application, but what good are they? Aside from presenting a nice list, do they provide any functionality?
Absolutely! Each icon gives you a visual means of referring to the objects they represent. You 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 View Controller icon, you can create a connection from the GUI element to a method that you want it to activate. You can even drag from certain objects directly to your code, quickly inserting a variable or method that will interact with that object.
Xcode provides developers with a great deal of flexibility when working with objects in Interface Builder. You can interact with the actual UI elements in the IB Editor, or with the icons that represent them in the Document Outline area. In addition, any object that isn’t directly visible in the user interface (such as the first responder and view controller objects) can be found in an icon bar directly below the user interface design in the Editor, as shown in Figure 5.3.
){kind=link}
)
Figure 5.3. You will interact with objects either in the Editor or in the Document Outline area.
We go through a hands-on example later this hour so that you can get a feel for how interacting with and connecting objects works. Before we do that, however, let’s look at how you go about turning a blank view into an interface masterpiece.