Exploring Interface Builder
- Understanding Interface Builder
- Creating User Interfaces
- Customizing the Interface Appearance
- Connecting to Code
- Further Exploration
- Summary
- Q&A
- Workshop
- Activities
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 the 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 (UI) 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 just a drawing tool for graphical user interfaces (GUIs); it helps you symbolically build application functionality without writing code. This translates to fewer bugs, shorter development time, and easier-to-maintain projects.
If you read through Apple’s developer documentation, you’ll see IB 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 Swift. Without IB, creating the most basic interactive applications would be an exercise in frustration.
This hour focuses on navigating IB 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, IB, and the iOS Simulator for the first time. So, stay alert and keep reading.
The IB 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 iOS device display the text Hello Xcode on the screen:
var myMessage: UILabel
myMessage=UILabel(frame:CGRectMake(30.0,50.0,300.0,50.0))
myMessage.font=UIFont.systemFontOfSize(48.0)
myMessage.text="Hello Xcode"
myMessage.textColor=UIColor(patternImage: UIImage(named:"Background")!)
view.addSubview(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 would 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.
IB 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 IB is, quite literally, a matter of connecting or reconnecting the dots as you see fit.
The Anatomy of an IB Storyboard
Your work in IB 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 IB and display a barebones storyboard file with a single scene. You will need to choose View, Show Toolbar from the menu bar to make the workspace look like a normal project. Once the file is open and the toolbar visible, we can get our bearings.
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).
)
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 multiscene storyboards beginning in Hour 11, “Implementing Multiple Scenes and Popovers.”
Click the arrow in front of View Controller Scene to show its hierarchy (and then expand the View Controller object within it, as well).
Six icons should be visible in the scene: View Controller, View (within View Controller), Top Layout Guide (within View Controller), Bottom Layout Guide (within View Controller), First Responder, and Exit. With the exception of View, these are special icons used to represent unique noninterface objects in our application; these will be present in most of the storyboard scenes that you work with:
- View Controller: The View Controller icon 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 UIs and view controllers in Hour 6.
- Top Layout Guide: A guide line that marks the “top” of your content area (usually the bottom of the iOS status bar). You can use this guide to keep your UI objects below the portions of the display managed by iOS. This is part of the Auto Layout system that we discuss later this hour, and in depth in Hour 16, “Building Responsive User Interfaces.”
- Bottom Layout Guide: A guide line that marks the “bottom” of your content area. This is usually the bottom of the view itself. Like the Top Layout Guide, this is used to help position your user interface. Again, this is an Auto Layout tool that we won’t really need until much later in the book.
- 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. Therefore, as you add controls to your interface, they are 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.
- First Responder: The First Responder icon 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.
- Exit: The Exit icon serves a very specific purpose that will come into play only in multiscene applications. When you are creating an app that moves the user between a series of screens, the Exit icon provides a visual means of jumping back to a previous screen. If you have built five scenes that link from one to another and you want to quickly return to the first scene from the fifth, you’ll link from the fifth scene to the first scene’s Exit icon. We test this out in Hour 11.
- Storyboard Entry Point: This icon is just an indicator that this scene is what your application is going to display when it launches. Storyboards can have many scenes, but they need to start somewhere. That somewhere is the entry point.
As you build your UIs, the list of objects within your scenes will grow accordingly. Some UIs may consist of dozens of different objects, leading to rather busy and complex scenes, as demonstrated in Figure 5.2.
)
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 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 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 IB. 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 UI (such as the first responder and view controller objects) can be found in an icon bar directly above the UI design in the editor. This is known as the scene dock, and is visible in Figure 5.3.
)
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.