Tables Use a Collection of Classes to Manage Content

The various components of a table view—including column, row, header, and cell—are each supported by a distinct NSView subclass. These classes work together with the NSTableView class itself to display content and to enable behaviors such as animation, column rearrangement, sorting, and selection. And, because most tables use NSView objects to represent individual cells, it’s easy to design custom cell views in Interface Builder and to support animation and column management.

Interface Builder Makes It Easy to Create Tables

Using Interface Builder, you add a table view to a window or superview, add and arrange columns, and specify column headers. Then, you typically create cell view prototypes that your app uses to provide the content layout for each table cell. (If you’re working with an NSCell-based table, you create subclasses of NSCell for each table cell.) Many aspects of tables can be set directly in Interface Builder, which means that you can avoid writing additional code.

Tables Can Get Data in Two Ways

You must provide data to the table view. You can do this in one of two ways:

• Programmatically, by implementing a data source class

• Using Cocoa bindings

To provide data programmatically, you create a class that conforms to the NSTableViewDataSource protocol and implement the method that provides the row and column data as requested.

Use Cocoa bindings to create a relationship between a controller class instance, which manages the interaction between data objects, and the table view. When you use the bindings approach, you don’t create a data source class for providing the data or supporting editing.

The techniques you use to create and populate a table differ depending on whether the table is NSView based or NSCell based.

A Table’s Appearance and Behaviors Are Customizable

You can customize various aspects of a table’s appearance, including background color, row color, and grid line color. You can also specify how a table should behave when users make selections or sort table data. (The techniques you use to modify a table’s appearance and behavior are the same for both NSView-based and NSCell-based tables.)

NSCell-Based Tables Are Still Supported

In OS X v10.6 and earlier, each table view cell was required to be a subclass of NSCell. This approach caused limitations when designing complex custom cells, often requiring you to write your own NSCell subclasses. Providing animation, such as progress views, was also extremely difficult. In this document these types of table views are referred to as NSCell-based table views. NSCell-based tables continue to be supported in OS X v10.7 and later, but they’re typically used only to support legacy code. In general, you should use NSView-based tables.

Although you use the same Interface Builder techniques to create both NSView-based and NSCell-based table views (and to add columns to a table), the code required to provide individual cells, populate the table view, and support programmatic editing differs depending on the table type. In addition, you use different Cocoa bindings techniques depending on whether you’re working with an NSView-based or NSCell-based table.