01.02.2014 Views

Objective-C Fundamentals

Objective-C Fundamentals

Objective-C Fundamentals

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

156 CHAPTER 7 Protocols<br />

■<br />

■<br />

UITableViewCellAccessoryDetailDisclosureButton<br />

This method leaves the accessory view of the UITableViewCell as an open rightbracket<br />

image in a blue background.<br />

UITableViewCellAccessoryCheckmark<br />

This method leaves the accessory view of the UITableViewCell as a checkmark<br />

image.<br />

In order for this delegate method to be called, your table view cell must have an accessory<br />

for the user to tap. The accessory type of a cell is set during the creation of the<br />

cell itself, usually in the tableView:cellForRowAtIndexPath:. UITableViewCell has<br />

two methods for setting an accessory view:<br />

■<br />

■<br />

setAccessoryType:<br />

This method takes a UITableViewCellAccessoryType parameter. Any other<br />

object passed into this method will result in an error.<br />

setAccessoryView:<br />

If you want to have some other type of custom accessory presented in the accessory<br />

view, use this method. It takes in a general UIView or any subclass of it. This<br />

method is useful when you’re trying to style an application that doesn’t work<br />

with the default accessory types provided by Apple. Be careful when providing<br />

UIButtons here: you can get a single button firing off to two separate methods<br />

when it’s tapped.<br />

The following methods are similar to the tableView: accessoryButtonTappedFor-<br />

RowWithIndexPath: except they’re called when any other section of a table view cell is<br />

selected. Two points of entry are provided for the selection of a cell, willSelect and<br />

didSelect. This is commonly done throughout other Apple-provided delegates. Multiple<br />

methods like these exist to allow developers the ability to react to users at any<br />

point during the application flow. willSelect is called before the didSelect, but a<br />

call to willSelect is always followed by a call to didSelect:<br />

- (NSIndexPath *)tableView:(UITableView *)tableView<br />

willSelectRowAtIndexPath:(NSIndexPath *)indexPath<br />

- (void)tableView:(UITableView *)tableView<br />

didSelectRowAtIndexPath:(NSIndexPath *)indexPath<br />

Just as there’s an entry point to react to the user selecting any given cell, the following<br />

methods provide points at which to react when a cell is being deselected:<br />

- (NSIndexPath *)tableView:(UITableView *)tableView<br />

willDeselectRowAtIndexPath:(NSIndexPath *)indexPath<br />

- (void)tableView:(UITableView *)tableView<br />

didDeselectRowAtIndexPath:(NSIndexPath *)indexPath<br />

It’s common for table views to have alternating background colors, as can be seen in<br />

the App Store and iTunes Music Store. Some developers might think the background<br />

colors should be set when they create the cell, either in the UITableViewCell subclass

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!