The iPhone
interface options are what makes the device so enjoyable to use and what
gives you, the developer, a truly rich canvas to work with. You’ll
still need to come up with ideas for what your application will do, but the interface can be the deciding factor in whether your vision “clicks” with its intended audience.
In
the last two hours, you learned about fields, sliders, labels, and
images as input and output options. In this lesson, you explore two new
input options for handling discrete values, along with two new view
types that extend the information you can display to web pages and
beyond.
Switches
In most traditional desktop
applications, the choice between something being “active” or “inactive”
is made by checking or unchecking a check box or by choosing between
radio buttons. On the iPhone, Apple has chosen to abandon these options
in favor of switches and segmented controls. Switches (UISwitch) present a simple on/off UI element that resembles a traditional physical toggle switch, as shown in Figure 1. Switches have very few configurable options and should be used for handling Boolean values.
By the Way
Check boxes and radio buttons, while not part of the iPhone UI Library, can be created with the UIButton
class using the button states and custom button images. Apple provides
the flexibility to customize to your heart’s content—but sticking with
what a user expects to see on the iPhone screen is recommended.
To work with the switch, we’ll
make use of its Value Changed event to detect a toggle of the switch and
then read its current value via the on property or the isOn instance method.
The value returned when checking a switch is a Boolean, meaning that we can compare it to TRUE or FALSE (or YES/NO) to determine its state, or evaluate the result directly in a conditional statement.
For example, to check whether a switch mySwitch is turned on, we can use code similar to this:
if ([mySwitch isOn]) { <switch is on> } else { <switch is off> }
Segmented Controls
When user input needs to extend beyond just a Boolean value, a segmented control (UISegmentedControl)
can be used. Segmented controls present a linear line of buttons
(sometimes referred to as a button bar) where a single button can be
active within the bar, as demonstrated in Figure 2.
Segmented controls, when used
according to Apple’s guidelines, result in a change in what the user is
seeing onscreen. They are often used to choose between categories of
information or to switch between the display of application screens,
such as configuration and results screens. For simply choosing from a
list of values where no immediate visual change takes place, the Picker
object should be used instead.
By the Way
Apple recommends using segmented controls to update the information visible in a view. If the change, however, means altering everything
onscreen, you are probably better off switching between multiple
independent views using a toolbar or tab bar.
Handling interactions with a
segmented control will be very similar to the toggle button. We’ll be
watching for the Value Changed event and determining the currently
selected button through the selectedSegmentIndex, which returns the number of the button chosen (starting with 0, from left to right).
We can combine the index with the object’s instance method titleForSegmentAtIndex
to work directly with the titles assigned to each segment. To retrieve
the name of the currently selected button in a segmented control called mySegment, we could use the code fragment:
[mySegment titleForSegmentAtIndex: mySegment.selectedSegmentIndex]
We’ll make use of this technique later in the lesson.
Web Views
In the previous iPhone applications that you’ve built, you’ve used the typical iPhone view: an instance of UIView
to hold your controls, content, and images. This is the view you’ll use
most often in your apps, but it isn’t the only view supported in the
iOS SDK. A web view, or UIWebView, provides advanced features that open up a whole new range of possibilities in your apps.
Think of a web view as a
borderless Safari window that you can add to your applications and
control programmatically. You can present HTML, load web pages, and
offer pinching and zooming gestures all “for free” using this class.
Supported Content Types
Web views can also be used to display a wide range of files, without needing to know anything about the file formats:
HTML, Images, and CSS
Word documents (.doc/.docx)
Excel spreadsheets (.xls/.xlsx)
Keynote presentations (.key.zip)
Numbers spreadsheets (.numbers.zip)
Pages documents (.pages.zip)
PDF files (.pdf)
PowerPoint presentations (.ppt/.pptx)
You can add these files as
resources to your project and display them within a web view, access
them on remote servers, or read them from the iPhone’s sandbox file
storage.
Loading Remote Content with NSURL, NSURLRequest, and requestWithURL
Web views implement a method called requestWithURL that you can use to load an arbitrary URL, but, unfortunately, you can’t just pass it a string and expect it to work.
To load content into a web view, you’ll frequently use NSURL and NSURLRequest. These two classes provide the ability to manipulate URLs and prepare them to be used as a request for a remote resource. You will first create an instance of an NSURL object, most often from a string. For example, to create an NSURL that stores the address for Apple, you could use the following:
NSURL *appleURL;
appleURL=[[NSURL alloc] initWithString:@"http://www.apple.com/"];
Once the NSURL object is created, you need to create an NSURLRequest object that can be passed to a web view and loaded. To return an NSURLRequest from an NSURL object, we can use the NSURLRequest class method requestWithURL that, given an NSURL, returns the corresponding request object:
[NSURLRequest requestWithURL: appleURL]
Finally, this value would be passed to the requestWithURL
method of the web view, which then takes over and handles loading the
process. Putting all the pieces together, loading Apple’s website into a
web view called appleView would look like this:
NSURL *appleURL;
appleURL=[[NSURL alloc] initWithString:@"http://www.apple.com/"];
[appleView loadRequest:[NSURLRequest requestWithURL: appleURL]];
We’ll be implementing web views in this hour’s first project, so you’ll have a chance to put this to use shortly.
Did you Know?
Another way that you
get content into your application is by loading HTML directly into a web
view. For example, if you generate HTML content in a string called myHTML, you can use the loadHTMLString:baseURL method of a web view to load the HTML content and display it. Assuming a web view called htmlView, this might be written as follows:
[htmlView loadHTMLString:myHTML baseURL:nil]
Scrolling Views
You’ve certainly used
iPhone applications that display more information than what fits on a
single screen; in these cases, what happens? Chances are, the
application allows you to scroll to access additional content.
Frequently, this is managed through a scrolling view, or UIScrollView.
Scrolling views, as their name suggests, provide scrolling features and
can display more than a single screen’s worth of information.
Unfortunately, Apple
has gone about halfway toward making scrolling views something that you
can add to your projects in Interface Builder. You can add the view, but
until you add a line of code to your application, it won’t scroll!
We’ll close out this hour’s lesson with a quick example (a single line
of code!) that will enable UIScrollView instances that you create in Interface Builder to scroll your content.
