Tables on iOS

Coming from the desktop, one might expect a UITableView to look something like a spreadsheet, with rows and columns presented in a two-dimensional grid. Instead, the table view is a vertically scrolling list of items, optionally split into sections.

The table view is essential for many of the apps that ship with the iPhone, as well as popular third-party apps. In Mail, tables are used for the list of accounts, the mailboxes within each account, and the contents of each mailbox. The Reminders app is little more than a table view with some editing features, as are the alarms in the Clock app. The Music app shows lists of artists or albums, and within them lists of songs. Even the Settings app is built around a table, albeit one of a different style than is used in most apps (more on that later).

To add a table to an iOS app, we use an instance of UITableView. This is a UIScrollView subclass, itself a subclass of UIView, so it can either be a full-screen view unto itself or embedded as the child of another view. It cannot, however, have arbitrary subviews added to it, as it uses its subviews to present the individual cells within the table view.

The table has two properties that are crucial for it to actually do anything. The most important is the dataSource, which is an object that implements the UITableViewDataSource protocol. This protocol defines methods that tell the table how many sections it has (and optionally what their titles are) and how many rows are in a given section, and it provides a cell view for a given section-row pair. The data source also has editing methods that allow for the addition, deletion, or reordering of table contents.

The second important property to know about is the table’s delegate, an object implementing the UITableViewDelegate protocol, which provides method definitions for handling selection of rows and other user interface events.

These two roles are performed not by the table itself—whose only responsibility is presenting the data and tracking user gestures like scrolling and selection—but by some other object, often a view controller. Typically, there are two approaches to wiring up a table to its contents:

• Have a UIViewController implement the UITableViewDataSource and UITableViewDelegate protocols.

• Use a UITableViewController, a subclass of the UIViewController that is also defined as implementing the UITableViewDataSource and UITableViewDelegate protocols.

It’s helpful to use the second approach when the only view presented by the controller is a table, as this gives us some nice additional functionality like built-in pull-to-refresh, or scrolling to the top when the status bar is tapped. But this approach prevents having subviews other than the table, like an overlaid progress bar or spinner while we’re loading, or maybe an ad view below the table.