Architecture of Preference Panes

This section provides an overview of the preference pane architecture. It describes the various components involved in using preference panes and how they fit together, the design principle within the plug-in, and finally some implementation details.

Application Architecture

There are three logical components to the preference pane architecture: the application that loads the preference pane plug-ins (the preference application), the Preference Panes framework (PreferencePanes.framework), and the preference pane plug-ins themselves. The responsibilities of each are as follows:

In managing the preference settings, the preference pane object usually interacts with an additional component: the object to which the preferences apply. This target can be part of the operating system or one or more separate applications; the interaction can be by direct communication between the preference pane object and target or by indirect communication though the use of a preference file.

The plug-in architecture of preference panes is illustrated, showing a case of indirect communication with the target application, in Figure 1.

Figure 1  Plug-in architecture of preference panes
Plug-in architecture of preference panes

Design Architecture

Preference panes are built using a Model-View-Controller (MVC) design wherein the user interface (View) and data model (Model) are separated from one another with all communication going through a third object (Controller). Cocoa applications, as well as the Cocoa frameworks, are frequently implemented using MVC, which allows for greater flexibility and object reuse.

Figure 2 shows the MVC design as it applies to preference panes. The NSPreferencePane subclass (the preference pane object) assumes the central role as Controller. It is the intermediary between the user interface defined within a nib file and the preference file, which holds the user’s preferences. Through target-action connections between the user interface (the View) and the preference pane object, the user interface sends messages to the preference pane object as the user performs actions. The preference application can also be considered part of the View, since it provides the window for displaying the preference pane and notifies the preference pane object when the user selects and deselects the preference pane. The preference pane object translates these user actions into modified preference values and updates the values in the preference file (the Model).

Figure 2  Model-View-Controller design of preference panes
Model-View-Controller design of preference panes


The Preference Panes framework is an Objective-C framework built on top of Cocoa. As such, it can be used only by a Cocoa application, and the user interface you create for the preference pane module must also be implemented using Cocoa. You cannot create a Carbon-based, or Java-based, preference pane with this framework. In contrast, the application to which the preferences apply can be implemented in any language using any framework, provided it is able to communicate with the preference pane.

For storing preferences, Mac OS X has a built-in preference system, Core Foundation Preference Services, that provides all applications (Cocoa, Carbon, or BSD) the ability to easily read and write preference information to standardized XML-based files. When direct communication between applications is required, you can choose from a variety of methods from low-level signals and sockets to high-level Apple events, most of which are available to both Cocoa and Carbon applications.