// Call the superclass's designated initializer [super initWithStyle:UITableViewStyleGrouped];
// Create an array of 10 random possession objects possessions = [[NSMutableArray alloc] init];
for(int i = 0; i < 10; i++) {
[possessions addObject:[Possession randomPossession]];
}
In the code above, initWithStyle: (the designated initializer of the superclass) is overridden to call the new designated initializer, init. One reason for this change is users of this class now only have to send it the message init; they don’t have to worry about passing it any arguments. It also forces ItemsViewController to appear in grouped table view style. (It looks prettier this way.)
UITableViewDataSource protocol
Now that ItemsViewController has some possessions, you need to teach it how to turn those possessions into rows that its UITableView can display. When a UITableView needs to know what to display, it has a set of messages it sends to itsdataSource. These methods are declared in the UITableViewDataSource protocol.
Once again, you will peer into the iPhone SDK documentation to find these methods. In ItemsViewController.h, Command-Option-double click on the string UITableViewController to pull up the Developer Documentation window and the class reference for UITableViewController (Figure 10.9).
Figure 10.9. Documentation window
This reference will tell you everything you would ever want to know about UITableViewController. The basic information about the class is in a table at the top of the page. For instance, the Inherits from section tells you the class hierarchy ofUITableViewController; ItemsViewController will also respond to any methods these classes implement. You can click on any of the items in this table to get to the reference for them.
Experienced iPhone developers spend a lot of time in the documentation. Many developers new to the Apple way of doing things don’t understand the importance of the documentation. Regardless of the amount of experience you have with the iPhone SDK, you will still spend a lot of time checking the documentation for the method or class you need. (The documentation browser is always open on any Big Nerd Ranch employee’s computer.) When starting or struggling with an implementation, browse the documentation to find the appropriate classes and methods to work with. Remember, if a common task is difficult in Cocoa Touch, you are probably doing it wrong. The documentation will usually show you the easy way.
Right now, you are looking for the methods from the UITableViewDataSource protocol that ItemsViewController could implement to turn Possession instances into rows for the table view. Click on UITableViewDataSource in the Conforms to section to get to the protocol reference. There you can scroll down and see all the messages that a UITableView can send to its dataSource.
There are many methods here, but the two that are marked required method must be implemented. For UITableViewController to properly conform to
UITableViewDataSource, it must implement tableView:numberOfRowsInSecti on: andtableView:cellForRowAtIndexPath:. These methods tell the table view how many rows it should display and what content to display in each row.
In ItemsViewController.m, you can see that the required methods have already been implemented by the template. Delete the implementation for them because you’re going to write your own. (If you aren’t sure which methods to delete, just delete everything between @implementation and @end except for the init methods you already implemented.)
Whenever a UITableView needs to display itself, it sends a series of messages (the required methods plus any optional ones that have been implemented) to its dataSource. The required method tableView:numberOfRowsInSection: returns an integer value for the number of rows that the UITableView should display.
Because there needs to be a row for each entry in the possessions array, the implementation of this method should return the number of entries in the array as shown inFigure 10.10.
Figure 10.10. Obtaining the number of rows
Now implement tableView:numberOfRowsInSection: in ItemsViewController.m.
- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section
{ return [possessions count];
}
(You might be wondering what a “section” means in this method name. Table views can be broken up into sections, and each section can have its own set of rows. For example, in the address book, all the names beginning with “D” are grouped together in a section. By default, a table view has one section. For this exercise, we will work with only one section. Once you understand how a table view works, it’s not hard to use multiple sections. In fact, using multiple sections is one of the challenges at the end of this chapter.)
UITableViewCells
A UITableViewCell is a subclass of UIView, and each row in a UITableView is represented by a UITableViewCell. (Recall that a table on the iPhone can only have one column, so a row will only have one cell.) UITableView is a container for UITableViewCells. A cell consists of a content view where the cell displays data and an accessory view (Figure 10.11). In the accessory view, the cell can display an action-oriented icon – like a checkbox, a disclosure button, or a fancy blue dot with a chevron inside. These icons are accessed through pre-defined constants for the appearance of the accessory view. (See the docs for UITableViewCell for details.)
Figure 10.11. UITableViewCell layout
However, the real meat of a UITableViewCell is the content view. Each cell’s contentView has three subviews. Two of those subviews are UILabel instances, textLabel and detailTextLabel. The third is a UIImageView called imageView (Figure 10.12).
Figure 10.12. UITableViewCell hierarchy
Each cell also has a UITableViewCellStyle that determines which of these subviews are used and their position within the contentView. These styles are show in Figure 10.13.
Figure 10.13. UITableViewCellStyles
In this chapter, each cell will display the description of a Possession. To make this happen, you will implement the tableView:cellForRowAtIndexPath: in the data source (ItemsViewController). This method will create a cell, set its textLabel to the description of the corresponding Possession, and return it to
the UITableView that requested it (Figure 10.14).
Figure 10.14. UITableViewCell retrieval
How do you decide which cell a Possession corresponds to? One of the parameters sent to tableView:cellForRowAtIndexPath: is an NSIndexPath, which has two properties, section and row. When this message is sent to a data source, the table view is asking, “Can I have a cell to display in section X at row Y?” Because there is only one section in this exercise, the row is the only value of consequence. Therefore, implement this method in ItemsViewController.m so that the nth row displays the nth entry in the possessions array.
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
{ // Create an instance of UITableViewCell, with default appearance UITableViewCell *cell =
[[[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:@"UITableViewCell"] autorelease];
// Set the text on the cell with the description of the possession // that is at the nth index of possessions, where n = row this cell
// will appear in on the tableview
Possession *p = [possessions objectAtIndex:[indexPath row]];
[[cell textLabel] setText:[p description]];
return cell;
}
You can build and run the application now, and you’ll see a UITableView populated with a list of random Possessions. Yep, it was that easy! Thanks, Cocoa Touch! Also note that you didn’t have to change anything about Possession – you simply changed the controller object to interface with a
different view. This is why Model-View-Controller is such a powerful concept. With a minimal amount of code, you were able to show the same data in an entirely different way.