A view controller manages a view, typically loaded from a nib file.
- macOS 10.5+
This management includes:
Memory management of top-level objects similar to that performed by the
NSWindowclass, taking the same care to prevent reference cycles when controls are bound to the nib file's owner.
Declaring a generic
viewproperty, to make it easy to establish bindings in the nib to an object that isn't yet known at nib-loading time or readily available to the code that's doing the nib loading.
Implementing the key-value binding NSEditor informal protocol, so that apps using a view controller can easily make bound controls in the views commit or discard changes by the user.
In macOS 10.10 and later, a view controller offers a full set of life cycle methods, allowing you to manage the content of a window in a way that is on a par with iOS view controller management. These methods, presented in order here to reflect a typical cycle, are:
View life cycle:
User interaction cycle:
In addition, in macOS 10.10 and later, a view controller participates in the responder chain. You can implement action methods directly in the view controller. Corresponding actions that originate in the view controller’s view proceed up the responder chain and are handled by those methods.
Prior to OS X v10.10, a typical usage pattern for loading a nib file was to subclass
NSView and override its
load method to call
[super load. But in macOS 10.10 and later, the
load method automatically looks for a nib file with the same name as the view controller. To take advantage of this behavior, name a nib file after its corresponding view controller and pass
nil to both parameters of the
A view controller employs lazy loading of its view: Immediately after a view controller is loaded into memory, the value of its
is property is
false. The value changes to
true after the
load method returns and just before the system calls the
A view controller is meant to be highly reusable, such as for dynamically representing various objects. For example, the
add methods of the
NSPrint classes take an
NSView instance as the argument, and set the
view property to the
NSPrint object that is to be shown to the user. This allows a developer to easily create new printing accessory views using bindings and the
NSPrint class's key-value coding and key-value observing compliance. When the user dismisses a printing dialog, the
NSPrint classes each send NSEditor messages to each accessory view controller to ensure that the user's changes have been committed or discarded properly. The titles of the accessories are retrieved from the view controllers and shown to the user in menus that the user can choose from.