Thousands of classes are
available in the iOS SDK, but most of your applications will be using a
small set of classes to implement 90% of their features. To familiarize
you with the classes and their purposes, let’s review some of the names
you’re going to be seeing very, very frequently over the next few
hours. Before we begin, keep these few key points in mind:
Apple sets up much of
the structure of your application for you in Xcode. This means that
even though you need some of these classes, you won’t have to lift a
finger to use them. Just create a new Xcode project and they’re added
for you.
You’ll be
adding instances of many of these objects to your projects just by
dragging icons in the Interface Builder application. Again, no coding
needed!
When a
class is used, I tell you why it is needed, what it does, and how it is
used in the project. I don’t want you to have to jump around digging
for references in the book, so focus on the concepts, not memorization.
In
the next section of this hour’s lesson, you’ll learn about the Apple
documentation tools. These helpful utilities will enable you to find
all the class, property, and method information that you could ever
hope for. If it’s gritty details you want, you’ll have them at your
fingertips!
Core Application Classes
When you create a new
application with even the most basic user interaction, you’ll be taking
advantage of a collection of common core classes. Many of these you
won’t be touching, but they still perform an important role. Let’s
review several of these classes now.
The Root Class (NSObject)
As you learned in this article,
“Discovering Objective-C: The Language of Apple Platforms,” the power
of object-oriented programming is that when you create a subclass of an
object, you inherit that object’s functionality. The root class, from
which almost all Objective-C classes inherit, is NSObject. This object defines methods common to all classes, such as alloc, dealloc, and init. You will not need to create NSObject instances manually in this book, but you will use methods inherited from this class to create and manage new objects.
The Application Object (UIApplication)
Every application on the iPhone implements a subclass of UIApplication.
This class handles events, such as notification of when an application
has finished loading, as well as application configuration, such as
controlling the status bar and setting badges (the little red numbers
that can appear on application icons). Like NSObject, you won’t need to create this yourself; just be aware it exists.
Window Objects (UIWindow)
The UIWindow class
provides a container for the management and display of views. In
iOS-speak, a view is more like a typical desktop application “window,”
whereas an instance of UIWindow is just a container that holds the view. You will be using only a single UIWindow instance in this book, and it will be created automatically in the project templates that Xcode provides for us.
Views (UIView)
The UIView class
defines a rectangular area and manages all the onscreen display within
that region—what we will refer to as a view. Most of your applications
will start by adding a view to an instance of UIWindow.
Views can be nested to form
a hierarchy; they rarely exist as a single object. A top-level view,
for example, may contain a button and field. These controls would be
referred to as subviews and the containing view as the superview.
Multiple levels of views can be nested, creating a complex hierarchy of
subviews and superviews. You’ll be creating almost all of your views
visually in Interface Builder, so don’t worry: Complex doesn’t mean
difficult!
Responders (UIResponder)
The UIResponder class provides a means for classes that inherit from it to respond to the touch events produced by the iPhone. UIControl, the superclass for nearly all onscreen controls, inherits from UIView, and subsequently, UIResponder. An instance of UIResponder is just called a responder.
Because there can be
multiple objects that could potentially respond to an event, iOS will
pass events up what is referred to as a chain of responders.
The responder instance that can handle the event is given the
designation first responder. When you’re editing a field, for example,
the field has first responder status because it is actively handling
user input. When you leave the field, it “resigns” first responder
status. For most of your iOS development work, you won’t be directly
managing responders in code.
Onscreen Controls (UIControl)
The UIControl class inherits from UIView
and is used as the superclass for almost all onscreen controls, such as
buttons, fields, and sliders. This class is responsible for handling
the triggering of actions based on touch events, such as “pressing” a
button.
As you’ll learn in the next
hour, a button defines a handful of events that you can respond to;
Interface Builder enables you to tie those events to actions that
you’ve coded. UIControl is responsible for implementing this behavior behind the scenes.
View Controllers (UIViewController)
You’ll be using the UIViewController class in almost all the application projects throughout this book to manage the contents of your views. You’ll use a UIViewController
subclass, for example, to determine what to do when a user taps a
button. Make a sound? Display an image? However you choose to react,
the code you use to carry out your action will be implemented as part
of a view controller instance. You’ll learn much more about view
controllers over the next two hours.
Data Type Classes
An object can potentially hold
data. In fact, most of the classes we’ll be using contain a number of
properties that store information about an object. There are, however,
a set of Foundation classes that you’ll be using throughout this book
for the sole purpose of storing and manipulating information.
By the Way
If you’ve used C or C-like
languages before, you might find that these data type objects are
similar to data types already defined outside of Apple’s frameworks. By
using the Foundation framework implementations, you gain access to a
wide range of methods and features that go well beyond the C/C++ data
types. You will also be able to work with the objects in Objective-C
using the same development patterns as any other object.
Strings (NSString/NSMutableString)
Strings are collections
of characters—numbers, letters, and symbols. You’ll be using strings to
collect user input and to create and format user output frequently
throughout the book.
As with many of the data type objects you’ll be using, there are two string classes: NSString and NSMutableString.
The difference, as the name describes, is that one of the classes can
be used to create strings that can be changed (mutable). An NSString instance remains static once it is initialized, whereas an NSMutableString can be changed (lengthened, shortened, replaced, and so on).
Strings are used so frequently in Cocoa Touch applications that you can create and initialize an NSString using the notation @"<my string value>". For example, if you needed to set the text property of an object called myLabel to a new string that reads "Hello World!", you could use the following:
myLabel.text=@"Hello World!"
Strings can also be initialized with the values of other variables, such as integers, floating-point numbers, and so on.
Arrays (NSArray/NSMutableArray)
A useful category of data
type is a collection. Collections enable your applications to store
multiple pieces of information in a single object. An NSArray is an example of a collection data type that can hold multiple objects, accessed by a numeric index.
You might, for instance, create an array that contains all the user feedback strings you want to display in an application:
myMessages = [[NSArray alloc] initWithObjects: @"Good Job!",@"Bad job!",nil]
[myMessages objectAtIndex: 1]
As with strings, there is a mutable NSMutableArray class that creates an array capable of being changed after it has been created.
Dictionaries (NSDictionary/NSMutableDictionary)
Like arrays, dictionaries are
another collection data type, but with an important difference. Whereas
the objects in an array are accessed by a numeric index, dictionaries
store information as object/key pairs. The key is an arbitrary string,
whereas the object can be anything you want, such as a string. If the
previous array were to be created as an NSDictionary instead, it might look like this:
myMessages = [[NSDictionary alloc] initwithObjectsAndKeys:@"Good Job!",@"positive",@"Bad
Job!",@"negative",nil];
[myMessages objectForKey:@"negative"]
Dictionaries are useful
because they let you store and access data in abstract ways rather than
in a strict numeric order. Once again, the mutable form of the
dictionaries, NSMutableDictionary, can be modified after it has been created.
Numbers (NSNumber/NSDecimalNumber)
We can store strings and
collections of objects, but what about numbers? Working with numbers is
a bit different. In general, if you need to work with an integer,
you’ll use the C data type int, and for floating-point numbers, float. You won’t need to worry about classes and methods and object-oriented programming at all.
So, what about the classes that refer to numbers? The purpose of the NSNumber class is to take a numeric C data type and store it as an NSNumber object. The following line creates a number object with the value 100:
myNumberObject = [[NSNumber alloc] numberWithInt: 100]
You can then work with the number as an object—adding it to arrays, dictionaries, and so on. NSDecimalNumber, a subclass of NSNumber, can be used to perform decimal arithmetic on very large numbers, but will be needed only in special cases.
Dates (NSDate)
If you’ve ever tried to work
with a date manually (interpreting a date string in a program, or even
just doing date arithmetic by hand), you know it can be a great cause
of headaches. How many days were there in September? Was this a leap
year? And so on. The NSDate class provides a convenient way to work with dates as an object.
For example, assume you have a user-provided date (userDate) and you want to use it for a calculation, but only if it is earlier than the current date, in which case, you want to use that date. Typically, this would be a bunch of nasty comparisons and assignments. With NSDate, you would create a date object with the current date in it (provided automatically by the init method):
myDate=[[NSDate alloc] init]
And then grab the earlier of the two dates using the earlierDate method:
[myDate earlierDate: userDate]
Obviously, you can perform many other operations, but you can avoid much of the ugliness of data and time manipulation using NSDate objects.
URLs (NSURL)
URLs are certainly a different
type of data from what we’re accustomed to thinking about, but on an
Internet-connected device like the iPhone, you’ll find that the ability
to manipulate URLs comes in handy. The NSURL class will enable you to manage URLs with ease. For example, suppose you have the URL http://www.floraphotographs.com/index.html and want to get just the machine name out of the string? You could create an NSURL object:
MyURL=[[NSURL alloc] initWithString: @"http://www.floraphotographs.com/index.html"]
This will come in handy as
you start to create Internet-enabled applications. Of course, many more
data type objects are available, and as mentioned earlier, some objects
store their own data, so you won’t, for example, need to maintain a
separate string object to correspond to the text in labels that you
have onscreen.
Speaking of labels, let’s
round out our introduction to common classes with a quick look at some
of the UI elements that you’ll be adding to your applications.
Interface Classes
Part of what makes the
iPhone such a fun device to use are the onscreen touch interfaces that
you can create. As we explore Interface Builder in the next hour,
you’ll get your first hands-on experience with some of these interface
classes. Something to keep in the back of your head as you read through
this section is that many UI objects can take on very different visual
appearance based on how they are configured—so there is quite a bit of
flexibility in your presentation
Labels (UILabel)
You’ll be adding
labels to your applications both to present static text onscreen (as a
typical label) and as a controllable block of text that can be changed
as needed by your program (see Figure 1).
