oreilly.comSafari Books Online.Conferences.


AddThis Social Bookmark Button

Understanding the NSTableView Class

by Jose Cruz

The table view widget is an interface feature commonly found in most modern software applications. It is used to display and edit data in a tabular format. The widget is modeled after the traditional accounting ledger, which displays financial data using ordered rows and columns. It improves upon the ledger concept, however, by allowing the displayed data to interact with the user as well as with each other.

This article provides an in-depth introduction to the use and implementation of the NSTableView Cocoa class. It demonstrates how to use Interface Builder to add an NSTableView widget to an application view. It shows how to implement a data-source controller that will maintain the data for either a single- or a multiple-column table view. It demonstrates how to allow users to edit the tabular data either directly on the table view or through a separate editing view. It also shows how to implement a custom formatter to display the data in a structured manner. Finally, it demonstrates how to customized certain table behaviors through the delegation process.

To assist in the understanding of the NSTableView class, the tutorial application, TableDemo, is made available for downloading. The application and its XCode project can be downloaded here. Readers are assumed to have a basic understanding of the Objective C language and the Cocoa Framework. They are also expected to have a working familiarity with the XCode development environment and its companion tool, Interface Builder.

The NSTableView Class

The NSTableView class is perhaps one of the most complex Cocoa class found in the Application Framework Kit. Its wide range of features can be quite daunting and formidable to the uninitiated. In fact, it is quite common to find questions on various Cocoa mailing lists pertaining to the proper implementation of the NSTableView class.

Figure 1. The NSTableView class.
Figure 1. The NSTableView class

Shown in Figure 1 is a simplified structure of the NSTableView class. The class itself consists primarily of an NSScrollView enclosing a number of subviews. It uses an NSTableHeaderView object to maintain the headers that denote each table column. It maintains a separate NSCell to be used for data editing. It also maintains an NSView to serve as the customizable upper-right cornerpiece. Finally, each table column subview is maintained as an NSMutableArray collection.

The NSTableView class accepts a wide range of data, each encapsulated using the appropriate NSObject. It then renders the data in human-readable form using either a custom NSFormatter object or, by default, the NSObject [description] message. The class also provides a number of useful features to manage its displayed data at runtime without the need for additional code. For instance, its table columns can be selected, resized, and reordered. It can display gridlines or alternating background colors to help delineate its tabular rows. Its built-in support for horizontal and vertical scrollbars can also be displayed either automatically or manually. It can also hide and show its column headers, as well as change the font and text displayed by its column headers.

The NSTableView class generates a number of messages to delegate control over certain display behaviors to a target object. The object can then determine which table column is being selected, moved, or resized. It can also control which table row or column will be selected, or which table cell will be edited. The controller object can also use the delegate messages to determine how the table view will respond to certain mouse events.

Unfortunately, the NSTableView class does not automatically enable support the Edit menu. Because of this limitation, additional code must be provided to enable basic menu actions such as Copy, Select All, and Select None. Hopefully, Apple will address this in future implementations of the class by providing delegate methods that can be used to add the necessary menu handling code.

The Interface Builder application makes it quite easy to add an NSTableView object to an application view. Simply click on the Cocoa Data Views icon on the Palette window, and drag and drop the widget onto the desired view, which can either an NSWindow, NSPanel, or NSView (Figure 2). To configure its default display attributes, click to select the widget and choose Show Inspector from the Tools menu. Then use the Inspector Panel (Figure 3) to set the desired display attributes.

Figure 2. The Cocoa Data Views palette.
Figure 2. The Cocoa Data Views palette

Figure 3. The NSTableView Inspector panel.
Figure 3. The NSTableView Inspector panel

When an NSTableView widget is added to the application view, Interface Builder automatically instantiates an NSTableView object and adds the object to the responder chain of the parent view. It also populates the table widget with placeholder test data. This can be switched off by clearing the checkbox labeled Populate NSTableView/NSOutlineView (Cocoa only) in the Preferences window of Interface Builder.

Currently, Apple does not provide any official OS X guidelines for the look and feel of table views. Nonetheless, there are a number of implicit rules to create a consistent and legible implementation of an NSTableView object.

  • Always use the Aqua guides when placing an NSTableView widget on its parent view. This ensures an optimal and consistent use of the space provided by the view. A table widget that crowds out surrounding widgets can be just as unsightly as one surrounded by too much white space. Also, a poorly placed widget increases the time-to-target factor thus making the overall interface difficult to navigate.

  • Whenever possible, use the same font and color for both the table header and data. If different fonts have to be used, select those fonts with the same general shape or form to maintain legibility. For example, if the header text uses a block-serif font, use a block-serif font as well for the data text.

  • Separate font styles for the header and data fonts can be used as long as they are consistent. If a specific data cell needs to adopt a different style, do so sparingly and only as a point of emphasis.

  • Use alternating background colors as opposed to gridlines when delineating each table rows. Colors are less visibly intrusive and they give the table view a more professional look. When assign a custom background color, use cool pastel color (blues or greens) or greys as opposed to warm (reds and yellows) or bright ones to maintain legibility. To add emphasis to a specific table row, use either a complementary text colour or a different text style.

Pages: 1, 2, 3, 4, 5

Next Pagearrow