Learn iOS 8 App Development, Second Edition (2014)

Chapter 10. Got Views?

You now have a lot of experience adding view objects to your design, arranging them, connecting them to outlets and actions, and customizing them. You’ve created iOS apps using buttons, labels, image views, a few text fields, and the odd toolbar. While you probably haven’t been yearning for other kinds of view objects, there are more available. The Cocoa Touch framework provides all kinds of switches, toggles, sliders, specialty buttons, pickers, indicators, doo-dads, and gizmos you can use to build your apps. And if that isn’t enough, many of those objects can be customized in ways you haven’t explored yet. In this chapter, you’ll learn about the following:

· Downloading sample projects

· Button views

· Switches, sliders, and steppers

· Indicators

· Labels, text fields, and text views

· Pickers

· Grouped table views

· Scroll views

· Search controls

· Alerts and action sheets

Anyone who’s spent time building Lego figures, Erector Set constructions, or experimental aircraft will know one thing: your ability to imagine what’s possible is directly linked to your knowledge about what parts you have to work with. To that end, I invite you on a guided tour of iOS view objects.

Learning by Example

Software development is a lot like cooking. It’s one thing to read recipes, talk about the process, and enjoy the results. It’s another thing to actually do it. One of the best ways to learn how to cook is to watch someone who knows what they’re doing and emulate them.

Apple provides many example projects—fully written, ready-to-run apps—that demonstrate the use of various technologies in iOS. All you have to do is download one, build it, run it, and then mine it for all of its secrets. These example projects are a great way to get started using, or at least understanding how to use, many of the frameworks and features in iOS.

Not only does Apple provide these example projects free of charge, it has made it ridiculously simple to download them. Xcode will search for, download, and open sample code projects with the click of a button. Start in Xcode’s documentation window (Help Documentation and API Reference), as shown in Figure 10-1.

Figure 10-1. Searching for sample code

Search for the UICatalog project, as shown in Figure 10-1. Click it and the project’s documentation page appears. Near the top is an Open Project link. Click it. Xcode downloads the project’s archive file, un-archives it, and opens the project in a new workspace window, as shown in Figure 10-2. How easy was that?

Figure 10-2. UICatalog project

Note Sample projects are not part of the Xcode installation package and require an Internet connection to download.

You’ll find that the documentation for many classes contains links to sample projects, making it easy to download code that shows you those classes in action.

Tip While Apple’s so-called walled garden keeps most iOS app projects within the developer community (after all, you have to be a developer to build and run apps on your iOS device) that hasn’t stopped the open source community. Many open source iOS projects are available to developers (like you) and to brave individuals who have “jailbroken” their device. A quick Internet search will turn up open source apps, as well as frameworks and code libraries, you can use in your own projects.

The UICatalog project is extra-special. It’s an app that demonstrates every major view object supplied by iOS. So, not only is it a handy visual reference to the kinds of view objects iOS supplies, but you can see exactly how these objects are created and used in an app.

Run the UICatalog app in a simulator (or on your own device, if you like), as shown in Figure 10-3. As of this writing, UICatalog contains two projects: one app written in Objective-C and an identical app written in Swift. When you download them, Xcode will open both projects. It doesn’t matter which one you run. For exploring the code, you’ll be interested in the Swift version, so close the Objective-C project.

Figure 10-3. UICatalog app

The list consists of the core set of stand-alone UIKit view classes, in alphabetical order, followed by the specialty search and toolbar classes. Let’s start with everyone’s favorite control: the button.

Buttons

A button is a straightforward view object; it acts like a physical button. The UIButton class draws a button and observes touch events to determine how the user is interacting with it. It translates what the user is doing into action events, such as “user touched inside the button,” “user moved their finger outside the button,” “user moved back inside the button,” and “user released their finger while still inside the button.” That’s pretty much all it does.

I know what you’re thinking. Well, maybe I don’t. But I hope you’re thinking, “But a button does more than that! It sends action messages to another object, it remembers its state, it can be disabled, and it can have gesture recognizers attached to it. That’s a lot!”

It is a lot, but the UIButton class doesn’t do any of those things. UIButton is at the end of a chain of classes, each of which is responsible for one set of closely related behaviors. Software engineers say that each class performs a role. The role of a UIButton object is to act like a button. Its superclasses do all of that other stuff. So that you can get a clearer picture of what’s going on, I think it’s time for you to dissect a UIButton. This will help you understand not only how UIButton was built but how all control views are constructed.

Note No UIButton objects were harmed in the making of this book.

The Responder and View Classes

A UIButton is a subclass of UIControl, which is a subclass of UIView, which is a subclass of UIResponder, as shown in Figure 10-4. Each class adds one layer of functionality that, taken together, makes a button.

Figure 10-4. Anatomy of a button

The UIResponder class defines all the event-related functions of the objects, most notably the methods that handle touch events. You learned all about UIResponder in Chapter 4, and you created a custom UIView object that overrode the touch event handling methods with your own, so I won’t repeat any of that here.

The next layer that UIButton inherits is UIView. UIView is a big, complicated class. It has dozens of properties and more than 100 methods. It’s huge because it’s responsible for every aspect of how every visible object in the iOS universe gets displayed on a screen. It handles the geometry of the view, its coordinate systems, transformations (such as rotation, scaling, and skewing), animation, how the view gets repositioned when the screen size changes, and hit testing. It’s also responsible for drawing itself, drawing its subviews, deciding when those views need to be redrawn, and more. You’ll get very intimate with UIView in Chapter 11.

One seemingly unrelated property of UIView is its gestureRecognizers property. The UIView class doesn’t do anything with gesture recognizers directly. But a UIView defines a visible region of the display, and any visible region can have a gesture recognizer attached to it so that property exists in UIView.

HOW GESTURE RECOGNIZERS GET EVENTS

Gesture recognizers are fed events by the UIWindow object during touch event delivery. In Chapter 4, I explained that hit testing is used to determine the view that will receive the touch events. That description oversimplified the process somewhat.

Starting with iOS 3.2, the UIWindow first looks at the initial (hit test) view to see whether it has any gesture recognizer objects attached to it. If it does, the touch events are first sent to those gesture recognizer objects, instead of being delivered directly to the view object. If the gesture recognizers aren’t interested, then the event eventually makes its way to the view object.

If you need to, there are a variety of ways to alter this behavior, but it’s a tad complicated. For all of the details, read the “Gesture Recognizers” chapter of the Event Handling Guide for iOS that you’ll find in Xcode’s Documentation and API Reference window.

So, everything that’s visual about the button is defined in the UIView class. Now move on to the next layer, the UIControl class.

The Control Class

UIControl is the abstract class that defines the properties common to all control objects. This includes buttons, sliders, switches, steppers, and so on. A control object does the following:

· Sends action messages to target objects

· Can be enabled or disabled

· Can be selected

· Can be highlighted

· Establishes how content is aligned

The first item in the previous list is the most important. The UIControl class defines the mechanism for delivering action messages to recipients, typically controller objects. Every UIControl object maintains a table of events that trigger actions, the object that will receive that action, and the action message it will send. When you’re editing an Interface Builder file and you connect an event to an action method in another object, you’re adding one entry to that object’s event dispatch table.

Note Remember from Chapter 4 that an event can be associated with an action that is sent to the first responder. You do this by specifying the message to send and using nil as the target object for that message.

The other properties (enabled, selected, and highlighted) are general indicators of the control’s appearance and behavior. Subclasses of UIControl determine exactly what those properties mean, if anything.

The enabled property is the most consistent. A control object interacts with the user when enabled and ignores touch events when disabled (control.enabled = false). Most control classes indicate that they are disabled by dimming, or graying, their image to show the user the control is inert.

The highlighted property is used to indicate that the user is currently touching the control. Many controls “light up” when touched, and this property reflects that.

The selected property is for controls that can be turned on or off, such as the UISwitch class. Controls that don’t, such as buttons, ignore this property.

The UIControl class also introduces the concept of an alignment (vertical and horizontal) through the contentVerticalAlignment and contentHorizontalAlignment properties. Most control objects have some sort of title or image and use these properties to position that in the view.

Button Types

You’ve now worked your way back to the UIButton class. It’s this class that implements the button-specific behavior of a control+view+responder object. The UIButton class supplies a handful of predefined button looks, along with a plethora of customizations so you can make it look just about any way you want.

The most important property of a button is its type. A button can be one of the following types:

· System

· Custom

· Detail disclosure

· An “info” button (light or dark)

· An “add contact” button

All of these button styles are shown in the UICatalog app, except for the detail disclosure and custom types, as shown in Figure 10-5. The important thing to remember is that a button’s type is determined when it is created. Unlike all of its other properties, it cannot be changed afterward. An info button is an info button for life.

Figure 10-5. Buttons

The system button is the workhorse of iOS. It’s the standard, default button style used throughout the iOS interface. The premiere properties that adjust your button’s look are as follows:

· Tint color

· Title text (plain or attributed) and color

· Foreground image

· Background image or color

The tintColor property sets the highlight and accent color of the button. The standard color is blue.

The button’s title can be a simple string value (which you’ve used in your projects so far), or it can be attributed string. An attributed string is a string that includes text attributes: font, size, italics, bold, subscript offset, and so on. Creating attributed strings is a bit complicated but allows you to create buttons with whatever font and style the system is capable of. I describe attributed strings in Chapter 20.

You can also use an image instead of text for your button’s label by setting its image property. Similarly, the background can be set to an image or a solid color. You can also mix these in any combination you want: text title over an image background, image over a solid color background, image with no background (by setting the background color to UIColor’s clearColor object), and so on.

Images used for a button’s background can utilize an interesting feature that allows the graphic to resize its center portion independently of its edges. The cap insets (capInsets) property defines a margin around the edge of the image that is not scaled when the image is stretched to fit the size of the button. This property lets you design a single graphic image that will fill any button size, without distorting its edges.

At the other extreme is the custom type. This is a blank canvas, and iOS adds nothing to the look or behavior of the button. You can still use the title and image properties, but most of the standard button behavior (such as highlighting) is left up to you.

The detail disclosure type is the right-facing arrow button that normally appears only in the cells of a table view. The add contact button displays a plus (+) symbol, and the two info buttons present a localized symbol indicating more information is available. These four types have predefined appearances and sizes, and there’s almost nothing about them that you can customize.

Note There’s a rounded rectangle button type that is obsolete and should be ignored. If you use this type, your iOS 8 button will behave like the system type.

Control States

When creating and configuring the button’s title, image, background image, and background color, you must consider the various states the button (control) can be in. The UIControl’s enabled, highlighted, and selected properties combine to form a single state value (UIControlState) for that control. The state will always be one of normal, highlighted, disabled, or selected.

When the button is displaying normally, its state is .Normal. When the user is touching it, its state changes to .Highlighted. When it’s disabled, its state becomes .Disabled.

When you set a button’s title, image, background, or color, you do so for a particular state. This allows you to set one button image for when the button is enabled and alternate images for when it’s disabled, highlighted, or selected. You see this reflected in the functions that set these properties:

setTitle(_:,forState:)
setTitleColor(_:,forState:)
setAttributedTitle(_:,forState:)
setImage(_:,forState:)
setBackgroundImage(_:,forState:)

You don’t have to set values for every state. At a minimum, set the value for the normal (.Normal) state. If that’s all you set, that value will be used for all other states. If you then want it to have a different title, image, background, or color for one of the other states, set that too.

There are lots of other, subtler properties for fine-tuning your button’s look and feel. You can, for example, control the shadow thrown by the title text or change the position (inset) of the title, image, and background image. Read through the documentation for UIButton for all the available properties.

Button Code

You now know enough about button properties to take a peek at the button construction code in UICatalog. Up to now, you’ve created button objects using Interface Builder, which is fine—there’s nothing wrong with that. But you can also create any iOS object programmatically, as you’ve done with other objects like arrays and images. And you can take a hybrid approach, letting Interface Builder create an object while you then customize or adapt it in code.

The UICatalog app takes this last approach. Most objects are created in a storyboard and then tweaked in the code. The project is meticulously organized to help you locate these. Each example in the app, such as Buttons, has a storyboard scene (Buttons Scene) and a view controller (ButtonsViewController) with similar names, as shown in Figure 10-6.

Figure 10-6. Organization of UICatalog project

Click the ButtonsViewController.swift file and find the configureImageButton() function. It should look something like the following code:

func configureImageButton() {
imageButton.setTitle("", forState: .Normal)
imageButton.tintColor = UIColor.applicationPurpleColor()
let imageButtonNormalImage = UIImage(named: "x_icon")
imageButton.setImage(imageButtonNormalImage, forState: .Normal)
imageButton.accessibilityLabel = NSLocalizedString("X Button", comment: "")
imageButton.addTarget(self, action: "buttonClicked:", forControlEvents: .TouchUpInside)
}

A basic button object is created in the storyboard and connected to the imageButton outlet. The configureImageButton() function then customizes it by clearing its title, assigning an image (for all states), adding explanatory text for the visually impaired, and connecting the button’s action to the buttonClicked(_:) function.

If you want to try different button properties to see what they look like, fiddle with this code and run the app again. The UICatalog app is your UI playground.

Switches and Sliders

Next up on the tour are switches and sliders. Both are input devices. Unlike buttons, switches and sliders retain a value. A switch is just that, as shown on the left in Figure 10-7. It presents a sliding button that can change between on and off values by either tapping or swiping it with your finger. You see these everywhere in iOS, as shown on the right in Figure 10-7.

Figure 10-7. Switches, sliders, and the Settings app

A UISwitch object has a single Boolean value property named, appropriately enough, on. Getting that property will tell you which position the switch is in. Setting the property changes it. You can request that UISwitch perform a little animation eye-candy, when you change its value programmatically, by calling the setOn(_:,animated:) function and passing true for the animated parameter.

A number of properties let you customize your switch’s appearance.

· tintColor, onTintColor, and thumbTintColor: The first two set the colors used when the switch is off and on. The thumbTintColor makes the “thumb” of the switch (the circle you drag) a different color than tintColor.

· onImage and offImage: Normally a switch displays either (localized) “On” or “Off” text titles next to the thumb. You can replace these with images of your choosing. There are important size restrictions, so read the documentation.

Like most controls with a value, a switch sends a “value changed” event (UIControlEvents.ValueChanged) whenever the user changes it. Connect this event to your controller to receive an action message when the switch is flipped.

Sliders, as shown in the middle of Figure 10-7, are another input control that lets the user choose a value by dragging a slider to a position within a predetermined range. While a switch’s value is Boolean, a slider’s value property is a floating-point value that represents a continuous range of numbers.

The slider’s value property is constrained to the range set by the minimumValue and maximumValue properties. These default to 0.0 and 1.0, respectively. Unless you change those, value will be a fractional number between 0.0 and 1.0 (inclusive).

The key visual customization properties are as follows:

· minimumTrackTintColor, maximumTrackTintColor, and thumbTintColor: These change the colors of the tracks (to the left and right of the thumb), as well as the thumb itself. See the tinted slider in the UICatalog (Figure 10-7) for an example and the code that does it.

· minimumValueImage, maximumValueImage, thumbImage (per state): Like with the slider, you can change the image used to draw the tracks of the slider and the thumb itself. The thumb image works like UIButton’s image, in that you can supply different images for different states (normal, highlighted, and disabled).

A slider sends a single “value changed” event when the user moves it, unless you set the continuous property to true. If you set continuous, the control fires a barrage of “value changed” messages as the user drags the slider. You used this setting in the ColorModel app in Chapter 8so color changes happened “live” as you dragged around a slider.

Page Control

A page control (UIPageControl) object, as shown at the bottom of Figure 10-8, can be thought of as a discrete slider control. As its name implies, it’s intended to indicate the user’s position within a small (up to 20) number of pages or items. Apple’s Weather app uses it to indicate which location the user is currently viewing, as shown on the right in Figure 10-8.

Figure 10-8. Page control and Weather app

UIPageControl’s integer currentPage property is its value, and its numberOfPages property determines the former’s range and the number of dots that appear. Its appearance can be slightly modified with these properties:

· pageIndicatorTintColor: This sets the color for the page indicator.

· hidesForSinglePage: If set to true, the control doesn’t draw anything if there’s only one page (numberOfPages<=1).

Tapping a page control object to the right or left of the current page either decrements or increments the currentPage property (moving forward or backward one page) and sends a “value changed” event.

Steppers

A stepper (UIStepper) has the face of UIButton and the heart of UIPageControl, as shown in Figure 10-9. It displays two buttons side by side. Use a stepper when your user needs to increase or decrease something—“something” is up to you; the stepper doesn’t display a value—one step at a time.

Figure 10-9. Stepper

Like a slider, the stepper’s minimumValue and maximumValue properties set the range for its value property. The stepValue property determines what “one step” means. As an example, Table 10-1 would be the property values you’d set for a stepper with 11 possible values, between 1.0 and 6.0.

Table 10-1. Property Values for a Stepper with 11 Possible Values (1.0 to 6.0, Inclusive)