Class diagram

The class belongs to the AppKit framework. Its simplified UML class diagram looks like this:

It inherits from NSResponder, associates with a bundle, a view and some other represented object. That’s what the diagram says, in not so many words. Really though, the bundle association amounts to a nib association using a given nib name.

Title

What does the title attribute represent? An interesting question. Apple’s documentation proves most enigmatic. Described as the ‘localized title of the receiver’s view,’ the discussion continues:

“NSViewController does not use the title property directly. This property is here because so many anticipated uses of this class will involve letting the user choose among multiple named views using a pulldown menu or some other user interface.”

Exactly what ‘anticipated uses’ refers to, the reader is left to wonder! The warm feeling of anticipation remains.

Usage

According to documentation, the view controller becomes the nib’s owner. Its view outlet connects to the nib’s primary view. Using Interface Builder’s Cocoa View template gives you such a nib. The class of File’s Owner defaults to NSObject. Change this to NSViewController and link its view outlet to Custom View—the NSView already set-up by the template. (Makes you wonder why the View template does not automatically make the file owner’s class equal to NSViewController with its view outlet pointing at the custom view.) Via the nib’s owner, the controller, views and controls within the nib can bind to some other key-value coding and observing (KVC and KVO) compliant object for key-path “representedObject” applied to the controller, i.e. nib owner.

Does that make any sense? It assumes some grasp of nib and key-value paradigms.

In simple terms, NSViewController ties together a view and a model, the represented object. Isn’t that exactly what we’d expect from a controller in MVC architecture? Superficially, the class is analogous to NSWindowController. What window controller does for window and document, view controller does for view and represented object: view and model, plus controller. Window controller has -loadWindow behaviour for loading the window from its nib. View controller analogously carries the -loadView method. It almost makes you wonder if the two classes should really be one and the same; or belong to the same super-class, an abstract window-view controller.

Exemplars

Studying examples is a good way to grasp new concepts. A picture paints a thousand words. Samples are software engineering pictures. Where best to find good paintings? Where better than Apple? Surprisingly though, Apple’s sample code contains only a few examples that use NSViewController. Why is that surprising? Anyway, here they are:

• CrossEvents from 2007 subclasses the view controller. It demonstrates sending Carbon events and NSNotifications between Carbon and Cocoa. View controller’s usage is not the primary focus. It’s used just as a tool for loading a nib-based NSView. Not a complicated example, but helps to show that view controllers have their trivial use.
• HIView-NSView—same can be said. This sample was upgraded in May 2007 to use NSViewController.
• IconCollection—same again, not a direct demonstration of NSViewController usage per se. NSCollectionView’s use as an icon collection viewer is the main purpose. Yet it combines window and view controllers together with bindings.
• SourceView is an interesting sample. Relatively complex, it combines custom view-controller subclasses, as well as custom window controller.
• ViewController directly demonstrates view controlling. It has three custom view controllers, one each for image, table and video viewing. The sample also includes a window controller. So interesting to see how window and view controllers co-ordinate.

Are there any more? I’ve made a thorough search but no others at Apple Developer. Third-party developer sources may include examples, of course.

There is one intriguing fact about the Apple samples: only ViewController uses the represented object and only to store a integer representing the number of subviews present in the view controller’s view. So not really useful.

Responder and responder chain

NSViewController is a kind of NSResponder.

What is a responder anyway? If, like me, you generally ignore things that work right until they break, you’ll likely know little about the “responder chain,” how it works and why; simply because it normally doesn’t matter. The framework takes care of such details. Why concern yourself?

In this case, the answer is simple. NSViewController does not automatically join the responder chain, as does NSWindowController. If you want your view controllers in the chain, you must put them there yourself.

Respond to what and how?

The simplified story: responders (subclasses of NSResponder) link up together in a chain. When event or action messages fire, Apple’s Application Kit invokes the responders one-by-one until it finds a response. Events and actions correspond to keyboard presses, mouse clicks, scroll wheels, tablet events, menu items, help requests and such. Interactive inputs, by another name. Responders include windows, views and application objects, window and view controllers also.

That’s a very simplified version. See Apple’s Cocoa Event-Handling Guide for the gross details. Read the section entitled The Responder Chain.

In reality, the responder chain amounts to just a singly-linked list of NSResponder objects. Each responder encapsulates a nextResponder reference to the next responder in the chain, or nil if none. No next responder indicates the end of the chain. Every NSWindow has a first responder marking the start of the chain. However, the starting point varies; exact route varies too. Multiple responder chains exist at any one time, and which to choose depends on the type of message, whether or not NSWindowController is involved, and whether document or non-document architecture applies. So not exactly straightforward!

In all cases though, first responder is always first. Then comes the view hierarchy followed by the enclosing NSWindow and its delegate.

Question arises: where in the chain do view controllers belong? For instance, they could sit between the view hierarchy and its window. Alternatively, behind each view so that the view responds first followed immediately by its view controller. In practise, applications may need custom configurations of responders, possibly even dynamic.

More on this later.