In this section we’ll look at two controls that report back different signals than the simple button-up or button-down control events. The first is the UITextField, the prime control for entering text, and the second is the relatively simple (but unique) UISlider. In the process, we’ll also explore the other text-based entry formats, because they share some unique issues with UITextField.
Accepting text input with UITextField
You have four ways to display pure text in the SDK: the UILabel, the UISearchBar, the UITextView, and the UITextField. Each has a slightly different purpose. The UILabel and the UISearchBar are intended for short snippets of text; the UITextView is intended for multiple lines. Each of those text objects except the UILabel is editable, but only the UITextField is a UIControl subclass with its own control events already defined.
If the UITextField sounds familiar, that’s because you used it in the eventreporter example. If you go back and look at the screenshots, you’ll see that the Begin and End buttons are displayed in ovals that look a lot like input boxes. As we mentioned at the time, we liked the way they looked, but they also gave us a good excuse to familiarize you with the object without getting into its details.
Usually, a UITextField will accept user input. It’s intended to be used mainly for accepting short user input. The trickiest thing about using a UITextField is getting it to relinquish control of your device after you call up a keyboard. The following code shows the two steps needed to resolve this problem. We’re assuming that you’re working with a myText UITextField object visually and instantiated inside a view controller:
Your setup of an interface object begins, pretty typically, inside its controller’s viewDidLoad method. Here you turn the text field keyboard’s Return key into a bright blue Done key, to make it clear that’s how you get out. You accomplish this by using part of the UITextInputTraits protocol, which defines a couple of common features for objects that use keyboards.
To do anything else, you need to declare a delegate for the UITextField that follows the UITextFieldDelegate protocol. This can be done either by setting the text field’s delegate property programmatically or by drawing a delegate link visually. (This sample code presumes you’ve taken the easier solution of doing so visually.) After you’ve done that, you can modify the textFieldShouldReturn: delegate method. We’re assuming that the view controller has been set as the delegate, which would be typical, and which allows you to do this work in the same view controller class file.
Finally, you enter two standard lines of code into this delegate method. They tell the text field to let go of first-responder status (which, as we’ve previously noted, is what’s necessary to make a keyboard go away) and return a YES Boolean.
With this code in place, a user can get in and out of a UITextField. To use the text field afterward, you need to monitor the text field’s special control events (especially UIControlEventEditingDidEnd) and also look at its text property.
In a moment, we’ll provide a sample of how that works. First, let’s examine a few other text objects that aren’t controls but that you might use to accept text entry.
UILABEL
The UILabel isn’t user editable.
UISEARCHBAR
The UISearchBar looks an awful lot like a UITextField with some nuances, such as a button to clear the field and a bookmark button. Despite the similarities in style, the UISearchBar isn’t a UIControl object but instead follows an entirely different methodology.
To use a UISearchBar, set its delegate to be the object of your choice, likely your view controller. Then, respond to the half-dozen messages described in UISearch-BarDelegate. The most important of these is the searchBarSearchButtonClicked: method. Be sure to include resignFirstResponder in order to clear the keyboard; then, you can take actions based on the results. There’s an example of a UISearchBar in topic 9, section 9.2.3.
UITEXTVIEW
A UITextView works like a UITextField, except that it allows users to enter many lines of text. The biggest gotcha here is that you can’t use the Return key as your Done button, because users will likely want to hit Returns in their text. Instead, you must have a Done button somewhere near the top of your screen, where it can be seen when the keyboard is up. When that button is clicked, you can set the text view to resignFirstResponder. Beyond that, you must set the UITextView’s delegate property; then you can watch for delegate messages, most importantly textViewDidEndEditing:.
With the quick digression into this variety of text objects out of the way, we can now return to the other UIControl object that we wanted to discuss: UISlider.
Allowing value selection with UISlider
The slider is a simple object, but we’ve singled it out because it’s the one other class that has its own control event, UIControlEventValueChanged. If you target this event, you’ll find that it gets called whenever the slider moves, but the control event won’t tell you what the new value is. To get that information, your action method must query the slider’s properties.
Three properties are of particular note: value shows a slider’s current value, minimumValue shows the bottom of its scale, and maximumValue shows the top of its scale. You can use value without modification if you’ve set your slider to return a reasonable number (as described in the class reference); or if you prefer, you can use all three properties together to determine the percentage that the slider is moved over— which is what you’ll do in one final control example.
A TextField/Slider mashup
Because we want to examine two UIControl objects more closely, it makes sense to quickly mash up an example that takes advantage of both of them. You’ll do this in the View-Based RGB Application, which sets the background color of a view based on the word you type into a UITextField and the selected position of a UISlider.
As usual, you create all of these objects visually. Then, go hog wild linking objects to your view controller. In all, you should create five links: an outlet each for your text field and slider, an action link for the important text field and the slider events, and a
delegate link for the text field. Figure 6.8 shows what the view controller’s Connections tab looks like after these have all been done.
As shown, the actions from both of the controls link into a single method, called changeColor:. Whenever either control is changed, this method adjusts the color of the screen accordingly. The following listing shows how.
Listing 6.2 Accessing a text field and a slider
The hardest part of working with a UITextField is setting it up, which you did earlier. Now that you have input coming back, all you need to do is access the text property and do with it as you will O.
Meanwhile, by working with your three slider values, you’re able to easily generate a value from 0 to 1 ©. Putting that together with the color you generated from your text field input results in a background color that you can change in two ways. Figure 6.9 takes a final look at this new program.
Would it be better to do this with a UISegmentedControl and a UISlider? Probably. But as is, it offers a quick example of how a text field works. Furthermore, it shows how you can combine action management by letting multiple controls point to a single method, a technique that will be useful in more complex programs.
As usual, more information about both of these controls is available in the Apple class references, including lots of methods and properties that we didn’t talk about.
Figure 6.8 A heavily connected view controller will be a pretty normal sight as you gain experience in creating objects visually.
Figure 6.9 A text field and a slider conspire to set the color of the iPhone’s background.
Actions made easy
Throughout the latter half of this topic, you’ve seen controls that are tied to the fully fledged target-action mechanism. In the next topic, that will change when you see the same idea in a somewhat simplified form.
Sometimes, buttons or other controls are built into other classes of objects (such as the button that can be built into the navigation bar). These controls have special methods that allow them to automatically create a target-action pair. As a result, you don’t have to go through the nuisance of calling the addTarget: action: forControlEvents : method separately.
We’ll point out this technique when we encounter it as part of the navigation controller.
Actions in use
There are numerous control objects that we’ve opted not to cover here, mainly because they use the same general principles as those we’ve talked about. Nonetheless, they’ll remain an important factor throughout the rest of this topic.
In particular, controls represent one of the main ways that users can offer input to your programs, and we’ll discuss them when we talk about data in topic 9. We’ll also offer more complex programs that use a variety of controls from topic 9 on. Through those examples, the majority of the UI controls will receive some coverage in this topic.
