The Core iOS Developer’s Cookbook, Fifth Edition (2014)

Chapter 9. Creating and Managing Table Views

Tables provide a scrolling list–based interaction class that works particularly well for small GUI elements. Many apps that ship natively with the iPhone and iPod touch center on table-based navigation, including Contacts, Settings, and iPod. On these smaller iOS devices, limited screen size makes using tables, with their scrolling and individual item selection, an ideal way to deliver information and content in a simple, easy-to-manipulate form. On the larger iPad, tables integrate with larger detail presentations, providing an important role in split view controllers. In this chapter, you’ll discover how iOS tables work, what kinds of tables are available to you as a developer, and how you can use table features in your own programs.

iOS Tables

A standard iOS table consists of a simple vertical scrolling list of individual cells. Users may scroll or flick their way up and down until they find an item they want to interact with. On iOS, tables are ubiquitous. Several built-in iOS apps are based entirely on table views, and they form the core of numerous third-party applications.

Most tables you see in iOS are built using UITableView and customized with options provided by its delegate and data source protocols. In addition to a standard scrolling list of cells, which provides the most generic table implementation, you can create specialized tables with custom art, background, labels, and more.

Specialized tables include the kind of tables you see in the Preferences application, with their white cells over a gray background; tables with sections and an index, such as the ones used in the Contacts application; and related classes of wheeled tables, such as those used to set appointment dates and alarms. And, when you need to move beyond tables and their scrolling lists to more grid-like presentations, you can use the related class of collection views, which are introduced in Chapter 10, “Collection Views.”

No matter what type of table you use, they all work in the same general way. Tables are built around the Model–View–Controller (MVC) paradigm. They present cells provided from a data source and respond to user interactions by calling well-defined delegate methods.

A data source provides a class with on-demand information about a table’s contents. It represents the underlying data model and mediates between that model and the table’s view. A data source tells the table about its structure. For example, it specifies how many sections to use and how many items each section includes. Data sources provide individual table cells on-demand and populate those cells with model data that matches each cell’s position within the table.

Data sources express a table’s model; delegates act as controllers. Delegates manage user interactions, letting applications respond to changes in table selections and user-directed edits. For example, users might tap on a new cell to select it, reorder a cell to a new position, or add and delete cells. Delegates monitor these user interaction requests, react by allowing and disallowing them, and update the data model in response to successful actions.

The view, data source, and delegate work together to express an MVC development pattern. This pattern is not limited to table views. You see this view/data source/delegate approach used in a number of key iOS classes. Picker views, collection views, and page view controllers all use data sources and delegates.

Delegation

Table view data sources and delegates are examples of delegation, assigning responsibility for specific activities and information to a secondary object. Several UIKit classes use delegation to respond to user interactions and to provide content. For example, when you set a table’s delegate, you tell it to pass along any interaction messages and let that delegate take responsibility for them.

Table views provide a good example of delegation. When a user taps on a table row, the UITableView instance has no built-in way of responding to that tap. The class is general purpose, and it provides no native semantics for taps. Instead, it consults its delegate—usually a view controller class—and passes along the selection change. You add meaning to the tap at a point of time completely separate from when Apple created the table class. Delegation allows classes to be created without specific meaning while ensuring that application-specific handlers can be added at a later time.

The UITableView delegate method tableView:didSelectRowAtIndexPath: provides a typical delegation example. A delegate object defines this method and specifies how the app should react to a selection change initiated by the user. You might display a menu or navigate to a subview or place a check mark on the tapped row. The response depends entirely on how you implement the delegated selection change method. None of this was known at the time the table class was implemented.

To set an object’s delegate or data source, assign its delegate or dataSource property. This instructs your application to redirect interaction callbacks to the assigned object. You let Objective-C know that your object implements the delegate methods by declaring the protocol or protocols it implements in the class declaration. This declaration appears in angle brackets (for example, <UITableViewDelegate> or <UITableViewDataSource>), to the right of the class inheritance. When declaring multiple protocols, separate them with commas within a single set of angle brackets (for example, <UITableViewDelegate, UITableViewDataSource>). A class that declares a protocol is responsible for implementing all required methods associated with that protocol and may implement any or all of the optional methods as well.

Creating Tables

iOS includes two primary table classes: a prebuilt controller class (UITableViewController) and a direct view (UITableView). The controller offers a view controller subclass customized for tables. It includes an established table view that takes up the entire controller view, and it eliminates repetitive tasks required for working with table instances. Specifically, it declares all the necessary protocols and defines itself as its table’s delegate and data source. When using a table view outside the controller class, you need to perform these tasks manually. The table view controller takes care of them for you.

Table Styles

On the iPhone, tables come in two formats: plain table lists and grouped tables. Plain tables, by default, display on a simple white background with transparent cells. The iOS Settings application uses the grouped style, which displays on a light gray background with each subsection appearing over a white background.

Changing styles requires nothing more than initializing the table view controller with a different style. You can do this explicitly when creating a new instance. This cannot be changed after initialization. Here’s an example:

myTableViewController = [[UITableViewController alloc]
initWithStyle:UITableViewStyleGrouped];

When using controllers from XIBs and storyboards, adjust the Table View > Style property in the Attributes inspector.

Laying Out the View

UITableView instances are, as the name suggests, views that present interactive tables on the iOS screen. The UITableView class descends from the UIScrollView class. This inheritance provides the up and down scrolling capabilities for the table. Like other views, UITableViewinstances define their boundaries through frames, and they can be children or parents of other views. To create a table view, you allocate it, initialize it with a frame or constrain it with Auto Layout, and then add all the bookkeeping details by assigning data source and delegate objects.

UITableViewControllers take care of the view layout work for you. The class creates a standard view controller and populates it with a single UITableView, sets its frame to allow for any navigation bars or toolbars, and so on. You can access that table view via the tableViewinstance variable.

Assigning a Data Source

UITableView instances rely on an external source to feed either new or existing table cells on demand. Cells are small views that populate the table, adding row-based content. This external source is called a data source and refers to the object whose responsibility it is to return a cell on request to a table.

The table’s dataSource property sets an object to act as a table’s source of cells and other layout information. That object declares and must implement the UITableViewDataSource protocol. In addition to returning cells, a table’s data source specifies the number of sections in the table, the number of cells per section, any titles associated with the sections, cell heights, an optional table of contents, and more. The data source defines how the table looks and the content that populates it.

Typically, the view controller that owns the table view acts as the data source for that view. When working with UITableViewController subclasses, you need not declare the protocol because the parent class implicitly supports that protocol and automatically assigns the controller as the data source.

Serving Cells

The table’s data source populates the table with cells by implementing the tableView:cellForRowAtIndexPath: method. Any time the table’s reloadData method is invoked, the table starts querying its data source to load the onscreen cells into your table. Your code can callreloadData at any time to force the table to reload its contents.

Data sources provide table cells based on an index path, which is passed as a parameter to the cell request method. Index paths, objects of the NSIndexPath class, describe the path through a data tree to a particular node—namely their section and their row. You can create an index path by supplying a section and row:

NSIndexPath *myIndexPath = [NSIndexPath indexPathForRow:5 inSection:0];

In tables, use sections to split data into logical groups and rows to index members within each group. It’s the data source’s job to associate an index path with a concrete UITableViewCell instance and return that cell on demand.

Registering Cell Classes

Register any cell type you work with early in the creation of your table view. Registration allows cell dequeuing methods to automatically create new cells for you. Typically, you register cells in your initializer or in loadView or viewDidLoad methods. Be sure that this registration takes place before the first time your table attempts to load its data. Each table view instance registers its own types. You supply an arbitrary string identifier, which you use as a key when requesting new cells.

You can register by class (starting in iOS 6) or by XIBs (iOS 5 and later). Here are examples of both approaches:

[self.tableView registerClass:[UITableViewCell class]
forCellReuseIdentifier:@"table cell"];
[self.tableView registerNib:
[UINib nibWithNibName:@"CustomCell" bundle:[NSBundle mainBundle]]
forCellReuseIdentifier:@"custom cell"];

Register as many kinds of cells as you need. You are not limited to one type per table. Mix and match cells within a table however your design demands.

Dequeuing Cells

Your data source responds to cell requests by building cells from code, or it can load its cells from Interface Builder (IB) sources. Here’s a minimal data source method that returns a cell at the requested index path and labels it with text derived from its data model:

- (UITableViewCell *)tableView:(UITableView *)aTableView
cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
UITableViewCell *cell = [self.tableView
dequeueReusableCellWithIdentifier:@"cell"
forIndexPath:indexPath];
cell.textLabel.text =
[dataModel objectAtIndexPath:indexPath].text;
return cell;
}

If you’re an established iOS developer, you’ll appreciate this: You no longer need to check to see whether the queue already has an existing cell of the type you requested. The queue now transparently creates and initializes new instances as needed.

Use the dequeuing mechanism to request cells. As cells scroll off the table and out of view, the table caches them into a queue, ready for reuse. This mechanism returns any available table cells stored in the queue; when the queue runs dry, the mechanism creates and returns new instances.

Registering cells for reuse provides each instance with an identifier tag. The table searches for that type and pops them off the queue as needed. This saves memory and provides a fast, efficient way to feed cells when users scroll quickly through long lists onscreen.

Assigning a Delegate

Like many other Cocoa Touch interaction objects, UITableView instances use delegates to respond to user interactions and implement meaningful responses. Your table’s delegate can respond to events such as the table scrolling, user edits, or row selection changes. Delegation allows the table to hand off responsibility for reacting to these interactions to the object you specify, typically the controller object that owns the table view.

If you’re working directly with a UITableView, assign the delegate property to a responsible object. The delegate declares the UITableViewDelegate protocol. As with data sources, you can skip setting the delegate and declaring the protocol when working withUITableViewController or its custom subclass.

Recipe: Implementing a Basic Table

A basic table implementation consists of little more than a set of data used to label cells and a few methods. Recipe 9-1 provides about as basic a table as you can imagine. It creates the flat (nonsectioned) table shown in Figure 9-1. Each cell includes a text label and an image consisting of the cell’s row number inside a box.

Figure 9-1 Recipe 9-1 builds this basic table view.

Users can tap on cells. When they do so, the controller’s title updates to match the selected item. A Deselect button tells the table to remove the current selection and reset the title; a Find button moves the selection into view, even if it’s been scrolled offscreen.

This implementation attempts to scroll the “found” selection to the top (UITableViewScrollPositionTop), space permitting. Zulu, the last item in this table, cannot scroll any higher than the bottom of the view because you simply run out of table after its cell.

Data Source Methods

To display a table, even a basic flat one like the one that Recipe 9-1 builds, every table data source must implement three core instance methods. These methods define how the table is structured and provide content for the table:

numberOfSectionsInTableView—Tables can display their data in sections or as a single list. For flat tables, return 1. This indicates that the entire table should be presented as one single list. For sectioned lists, return a value of 2 or higher.

tableView:numberOfRowsInSection:—This method returns the number of rows for a given section. For Recipe 9-1’s flat list, this method returns the number of rows for the entire table. For more complex lists, you need to provide a way to report back per section. Core Data provides especially simple sectioned table integration, as you’ll read about in Chapter 12, “A Taste of Core Data.” As with all counting in iOS, section ordering starts with 0 as the first section.

tableView:cellForRowAtIndexPath:—This method returns a cell to the calling table. Use the index path’s row and section properties to determine which cell to provide and make sure to take advantage of reusable cells where possible to minimize memory overhead.

Responding to User Touches

Recipe 9-1 responds to the user in the tableView:didSelectRowAtIndexPath: delegate method. This recipe’s implementation updates the view controller’s title and enables both bar buttons for searching and deselecting. These buttons remain enabled as long as there’s a valid selection. If the user chooses the Deselect option, this code calls deselectRowAtIndexPath:animated: and disables both buttons.