Graphics Programs Reference
In-Depth Information
Figure 15.8 HomepwnerItemCell in action
Let's go back to the
UINib
class you used when loading
HomepwnerItemCell.xib
.
An instance of
UINib
knows how to read a XIB file. (Remember, XIB and NIB are used
interchangeably; technically, an application loads NIBs, but we work with XIBs, so it's
easier to call them that.)
An instance of
UINib
is created with the contents of a XIB file. It loads the data in that
file and holds on to it as long as it lives. When it is sent the message
instanti-
ateWithOwner:options:
, the
UINib
parses that data: all of the archived objects
come alive, and all of the connections are established. (The object passed as the first argu-
ment is the
File's Owner
.)
In
Chapter 10
,
you loaded a XIB file by sending the message
loadNibNamed:owner:options:
to the main
NSBundle
without ever using
UINib
. Well,
loadNibNamed:owner:options:
uses
UINib
under the hood. It
creates an instance of
UINib
and sends it the message
instantiateWithOwn-
er:options:
, relaying the options and owner arguments.
Both of these methods return an
NSArray
. This array contains all of the top-level objects
in the XIB file (the ones that aren't under a disclosure tab in the outline view of the XIB).
When you register a XIB file with a table view, it scans this array for an instance of
UIT-
ableViewCell
or a subclass of it and returns it to your data source.
Since the table view just scans the XIB file for a
UITableViewCell
, it is important
that you only put one instance of
UITableViewCell
in a XIB file used for this pur-
pose. Otherwise, the table view will get confused and throw an exception.
