The programmatic interface for table views is expressed through several classes, two formal protocols, and a category added to a Foundation framework class. You have to deal with all of these API components when implementing a table view.
A table view itself is an instance of the UITableView class. This class declares methods that allow you to configure the appearance of the table view—for example, specifying the default height of rows or providing a view used as the header for the table. Other methods give you access to the currently selected row as well as specific rows or cells. You can call other methods of UITableView to manage selections, scroll the table view, and insert or delete rows and sections.
UITableView inherits from UIScrollView, which defines scrolling behavior for views with content larger than the size of the window. UITableView redefines the scrolling behavior to allow vertical scrolling only.
A UITableView object must have a delegate and a data source. Following the Model-View-Controller design pattern, the data source mediates between the application’s data model (that is, its model objects) and the table view; the delegate, on the other hand, manages the appearance and behavior of the table view. The data source and the delegate are often (but not necessarily) the same object, and that object is frequently a custom subclass of UITableViewController.(See “Navigating a Data Hierarchy With Table Views” for further information.)
The data source adopts the UITableViewDataSource protocol and the delegate adopts the UITableViewDelegate protocol. UITableViewDataSource has one optional method through which the data source tells the table view how many sections it has (the default is one); it also has a required method through which it tells the table view how many rows are in each section. The UITableViewDelegate protocol declares a method that the delegate must implement to return a cell object that the table view uses when drawing a particular row. (“Table View Cells” gives more detail about this delegate task.) It also allows the delegate to modify visible aspects of the table view. Both protocols also include optional methods for responding to selections and taps on accessory views and for managing the insertion, deletion, and reordering of cells.
An application can make use of a convenience class, UILocalizedIndexedCollation, to help the data source organize the data for indexed lists and display the proper section when users tap an item in the index. The UILocalizedIndexedCollation class also localizes section titles. The UILocalizedIndexedCollation class was introduced in iOS 3.0.
Many methods of UITableView, UITableViewDataSource, and UITableViewDelegate have as parameters or return value objects representing index paths. An index path identifies a path to a specific node in a tree of nested arrays, and in the Foundation framework it is represented by an NSIndexPath object. UIKit declares a category on NSIndexPath (see NSIndexPath UIKit Additions) with methods that return key paths, locate rows in sections, and construct NSIndexPath objects from row and section indexes.
As noted in “Data Source and Delegate,” the data source must return a cell object for each visible row that a table view displays. These cell objects must inherit from the UITableViewCell class. This class includes methods that let you manage cell selection and editing, manage accessory views, and configure the cell. You can directly instantiate cells in the standard styles defined by the UITableViewCell class and give these cells content consisting of one or two strings of text and, in some styles, both image and text as content. Or, instead of using a cell in a standard style, you can put your own custom subviews in the content view of an “off the shelf” cell object. You may also subclass UITableViewCell to radically customize the appearance and behavior of table-view cells. “A Closer Look at Table-View Cells” discusses all of these approaches.
Last updated: 2010-08-03