KATI

In Computer Administrative Debris, I briefly discussed the idea of “directness” in interaction design. I described a “direct” interaction model as one where the visual representation of the content and the interface to the content are the same. A direct interaction model also implies some sort of physical interaction with content. Today, we most frequently use the mouse as an extension of our bodies to “point” at objects on the screen and to “drag” or “drop” them. With gesture and touch-based technologies entering the mainstream, these interactions will become more and more concerned with the movement and/or form of the user’s actual body.

A beautiful and extreme example of directness in an interface design can be found in the the software developed by Golan Levin and Zachary Lieberman for their 2004 audio/visual performances, Manual Input Sessions.

The Manual Input Sessions is a series of audiovisual vignettes which probe the expressive possibilities of hand gestures and finger movements.

Using a custom hardware/software setup, they developed interfaces for creating and composing audio in real-time that incorporate physical objects and the body into the interaction models. Users of this software literally mold the audio with their hands over time.

Also, when you watch the videos, notice how each interface has environmental characteristics that aid the user in creating and composing the audio. This is a clever way to add extra meaning to the input data. It also infuses the interfaces with a sense of play and exploration, so they become much more instrument-like and less tool-like.

[these videos need sound]

In the last post on NSViewController, I described the need for a view controller class that is part of a sound controller architecture, especially when developing an application with a single window interface. In this post, Jonathan Dann and I will share the design we came up with for integrating NSViewController into the existing Cocoa MVC application architecture using NSWindowController as the glue.

Before, we do that…

Meet Jonathan.

I’m currently training with the National Health Service in the UK, working towards becoming a state-registered Medical Physicist. I was introduced to programming during my Bachelor’s degree where I did a short course in C. During my Master’s degree I learnt some FORTRAN and then had my first experience of object-oriented programming during that year. Since then I’ve been learning as much as I could about Cocoa, design patterns, and the whole world of Mac programming. I’ve begun to write my first app, which will be available sometime around September, which really began life as a personal project when the tool I was using didn’t work right and didn’t fit properly within OS X.

As my code grew in size I soon realised that I needed a controller for some of my more complex view behaviour, NSSplitViews, NSTextViews, NSOutlineViews all need delegates to unlock their power and when all of this was in the same window controller I got the feeling it was doing work that it shouldn’t have to. I started using NSViewController and came to the conclusion that it didn’t quite fit in my design, after considering how MVC should work I asked on cocoa-dev how other people use it. Sure enough, it sparked some conversation. I think that Apple has left the use of this class up to developers intentionally, maybe they will extend it in future releases, maybe having a structured controller system seems a little abstract for smaller programs, but I think it makes things easier to maintain in the long-run.

After using the class for a while I am of the mind that each view in an app could potentially have its own controller, although this would probably be overkill; the only structure that then makes sense is a tree, just like the view hierarchy. I now use these classes extensively to inform the views, for example, how they should look: the view can then draw itself based on those options it gets from its overlord.

The XS (extra special) Controllers

Our solution includes to two classes:

1. XSWindowController, an NSWindowController subclass
2. XSViewController, an NSViewController subclass

You can find these classes in the example project (XCode 3.0). Dowonload it here.

The Goal of This Design

The goal of our design is simple: We want a way to manage a group of view controllers in a way that fits in nicely with the current Cocoa MVC architecture.

When building a Cocoa app, the controller layer of the architecture can be described very loosely as:

• NSDocument contains a list of NSWindowControllers
• Each window controller has an associated window

We want to extend this design so that:

• NSDocument contains a list of NSWindowControllers*
• Each NSWindowController conains a list of NSViewControllers
• Each NSViewController contains a list of subcontrollers
• Each NSViewController has an associated view

*Our changes happen beneath the document layer, so it is also a valid design for applications that aren’t document-based.

XSViewController and XSWindowController

In order to meet our goals, we enhanced Cocoa’s NSWindowController and NSViewController classes.

In XSViewController, we added a list of subcontrollers and the necessary methods to manage that list. We also gave the view controllers a reference to the window controller.

In XSWindowController, we added a list of view controllers. The window controller is the “host” for the view controllers, so when the window controller is created and destroyed by the document, it does the same to the view controllers. The window controller also does some extra work that is necessary for the view controllers to be integrated smoothly into the existing Cocoa controller architecture. We’ll describe this work further down.

In this setup, you would use the following XSWindowController methods to add and remove view controllers,

- (void)addViewController:(XSViewController *)viewController;
- (void)removeViewController:(XSViewController *)viewController;

In XSViewController, you can nest controllers and manipulate the structure of the controller tree using several methods that will be familiar to those who have worked with mutable arrays,

- (void)addChild:(XSViewController *)child;
- (void)insertObject:(XSViewController *)child inChildrenAtIndex:(NSUInteger)index;
- (void)insertObjects:(NSArray *)children inChildrenAtIndexes:(NSIndexSet *)indexes;
- (void)insertObjects:(NSArray *)children inChildrenAtIndex:(NSUInteger)index;
- (void)removeChild:(XSViewController *)child;
- (void)removeObjectFromChildrenAtIndex:(NSUInteger)index;

As long as you use these methods to add and remove view controllers from the application, you will get all of the benefits of the design.

Quick design note:

We want to note here that we considered a design where the window controller contained one view controller that would be the root of a single view controller tree. We chose to keep a list of view controllers in the window controller because it feels redundant to have to make a second controller that represents the entire window.

In a perfect world, the view controllers and window controllers would actually be the same class, so that the window controller would be the root of a single tree of controllers. This isn’t possible, but we decided that we would design with that structure in mind anyway.

Working with Cocoa

So, after we had this system set up and running, making sure that memory management was handled properly, we had to handle some Cocoa-specific behaviors so that the view controllers were well integrated into the Cocoa application architecture. This is the “glue-code” of this design. There are two Cocoa-related issues that we had to consider.

Cocoa Consideration 1: Taking care of the Responder Chain

NSViewController is a subclass of NSResponder, but it needs to be added to the responder chain to receive action events from things like buttons and menu items. We decided that our design should patch the responder chain so that it runs through the view controllers like this:

We looked at two approaches to solving this problem. The first approach would be to handle the responder chain in the NSViewController class, so that when a view controller was added or removed from the tree, its super controller would make sure the responder chain was patched together correctly.

The other approach is to have the window controller do the responder chain patching whenever a view controller is added or removed.

Both of these approaches have their advantages and disadvantages.

The first approach would keep things logically clean and less glue-like. The view controllers wouldn’t have to communicate back to the window controller when they add or remove their subcontrollers. If this were the perfect design world, where the window and view controllers were in the same tree, this would be the obvious way to maintain the responder chain throughout a single hierarchy of controllers.

The second approach is just more simple in this particular setup. Since this isn’t the perfect design world, the code that adds the view controllers to the responder chain would have to be repeated in both classes anyway. Letting one class handle the responder chain keeps this code centralized.

We decided to use the second approach. We don’t feel that there is a perfect solution to this problem and that either approach works fine.

The method that patches the responder chain is in XSWindowController:

- (void)patchResponderChain;

The source code will show how simple it is to keep the responder chain looking like it does in the diagram.

Consideration 2: Bindings and Observations

Bindings and Key-Value Observing are powerful Cocoa mechanisms that help us to keep our controllers and our data models separate. Most view controllers and window controllers will have bindings or KVO set up in some way.

In NSViewController, there is the idea of a “representedObject”. According to the documentation of NSViewController:

Declaring a generic representedObject property, 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.

This is a handy feature of NSViewController, especially if you are setting up all of your bindings in Interface Builder, but in a more complex setup, the single “representedObject” may not be the best way to expose a view controller to the data in an application.

There are situations where you might want to set up several KVOs and bindings in code and then remove them when you don’t need them anymore. If you forgo the “representedObject” as a means to set up KVO with your application’s data, you might come across this message in your logs when you close the document:

An instance (so-and-so) of class (so-and-so) is being deallocated while key value observers are still registered with it. Break on _NSKVODeallocateLog to start debugging.

We decided to go ahead and handle the possibility of these situations by adding a method to XSViewController called,

- (void)removeObservations;

This gives the view controllers a chance to remove observations or bindings that they set up in code before the data is released. The window controller has to manage the timing of this. In XSWindowController, we do it right before the window closes, in an implementation of the window’s delegate method,

- (void)windowWillClose:(NSNotification *)notification;

The window controller tells its view controllers to “removeObservations” here and they pass the message on to their subcontrollers. The window controller and document can then release data as they normally would in their implementations of “dealloc”.

Quick notes on subclassing:

If an XSViewController subclass implements the “removeObservations” method, it is responsible for calling super’s implementation so that the message will continue to be propagated down its branch of the tree.

If an XSWindowController subclass needs to implement “windowWillClose”, it should be sure to call super’s implementation so that the view controllers will get the message to remove their observations. The timing of this message is important, so if you are releasing some data here, be sure to call super first.

Using “windowWillClose” for a feature like this may not be the best solution, but as far as we can tell, it seems like the most convenient place to perform this task.

That’s It.

With these few enhancements, we now have two new abstract super-classes for our controllers, XSWindowController and XSViewController. When we subclass them to build our UIs, we get the controller architecture that we illustrated at the beginning of the post and the following features built in to our view controller:

• Automatic memory management!
• Automatic inclusion in the responder chain!!!
• A designated method for removing observations or bindings!
• A relationship with the window controller and document!

This design will become more and more useful as your single window interface becomes more complex, especially as your feature set changes over the life-time of your development. With this architecture in place, you have more flexibility to try things out and change your design without worrying about breaking the responder chain (which is not that easy to debug) or causing memory leaks by accident as you’re working rapidly to test UI designs. As long as you keep to MVC design principles, it is possible to create self-contained view controllers that can be plugged in to, and unplugged from, your UI with very little hassle.

Next Time…

First, thanks so much to Jonathan for working on this post with me. It was great to have the chance to brainstorm with another developer, especially one whose applications are completely different from the ones I work on every day. Working with him on this design helped to get me out of my usual mind-set and to isolate the issues that are truly common to any Cocoa application rather than unique to my own projects. This has been an educational and super-productive experience for me – Thanks, Jonathan!

AND a another big thanks to Jonathan for setting up the Xcode 3.0 example project and the source code!

In the next and last post about NSViewController, I’m going to discuss its relationship to NSView and the view hierarchy in more detail. One of the many important jobs of a view controller is to help to build and manage the view hierarchy during runtime. This is especially important when coding a single window interface that needs to give users access to many different features that can’t all be displayed in the window at one time.

Anyone who is sick of me writing about autoresizing should just skip the next installment ; ) ( or in Japanese, ^_- )

Resources

The example project contains XSWindowController and XSViewController, which contain all the nitty-gritty implementation details. There is also an example app that shows how you could subclass these classes to build a UI based on the XS controllers.

Cocoa Event-Handling Guide: The Responder Chain

Introduction to Document-Based Applications Overview

NSViewController Class Reference

NSWindowController Class Reference

Introduction to Key-Value Observing Programming Guide

Introduction to Cocoa Bindings Programming Topics

UPDATE 04/23/08

We updated the example project today. The biggest change we made is in XSViewController. We were previously setting the “representedObject” of child controllers to be that of its parent. In the new version we don’t deal with “representedObject” in any way. You can just use NSViewControllers methods to set them case-by-case.

XCode Project

Just the Source Code

Just XSViewController and XSWindowController

Applications like iTunes and iPhoto have established a single window interface as the de-facto standard for modern Mac UI design. This design is great for end users, who no longer have to switch between several windows to be productive with their software. For developers, on the other hand, this design poses several challenges in terms of interaction design and software architecture, especially in the view and controller layers of the MVC architecture prescribed by Cocoa. This post is the first of three that will address this architectural design problem and, more specifically, examine the role of Cocoa’s new NSViewController class in this design.

There are at least two major architectural issues that have to be addressed by the interface developer when coding this kind of interface. First, a single window interface requires a software architecture that can effectively handle dynamic changes in the view hierarchy during runtime. I’ll address this issue in more detail in the third post on this topic.

The second issue that needs to be addressed is that in a single window interface design, a great deal of burden naturally falls on NSWindowController. In this type of setup, the application’s main window controller is responsible for handling a majority of the user interface. In other words, the interface code for an entire application, apart from a few dialog windows here and there, is expected to go into one single class. This code quickly becomes unmanageable and unmaintainable as the feature set changes and grows. It is natural to start to break this code up into logical groups of subcontrollers and to develop a system to manage and maintain these groups.

To accomplish this, many of us have already come up with our own “view controller” systems to extend our controller architecture. Apple has also started to address this issue by adding NSViewController to the Cocoa SDK in Leopard.

A standard view controller class is a great idea and welcome addition to Cocoa. One particular feature, the built-in memory management of objects in nib files, makes NSViewController a very attractive alternative to using a custom view controller. However, this class seems to have been left out of the controller layer of Cocoa’s MVC application architecture. Apart from being a subclass of NSResponder, there is no indication from the documentation or the class’s design that it is intended to be a part of the current controller architecture, but at the same time, it cannot be functional on its own. So where does NSViewController fit into a Cocoa app and how can developers use this class effectively to build a solid controller architecture in their applications?

NSViewController and the Cocoa MVC Architecture

For larger projects, specifically projects with single window interfaces, the view controllers form a significant portion of the software architecture and it would make sense for there to be a standard way to approach view controllers as a general design problem. Unfortunately, the Cocoa documentation doesn’t give developers any hint as to what that approach should be. There are some clues in NSViewController’s API about how you could patch a single view controller into a specific area of your current design, but nothing that suggests a holistic design strategy.

The conceptual documentation of Cocoa’s “Document-Based Application Architecture” hasn’t been updated yet to explain how the Cocoa engineers intend for us to incorporate NSViewController the current application architecture. For example, the section that describes the “Key Objects” in the architecture makes no mention of NSViewController, and because of that, the paragraphs on “Typical Usage Patterns” still suggest that:

If your document has only one window, but it is complex enough that you’d like to split up some of the logic in the controller layer, you can subclass NSWindowController as well as NSDocument. In this case, any outlets and actions and any other behavior that is specific to the management of the user interface goes into the NSWindowController subclass.

Clearly a single NSWindowController subclass isn’t going to manage the whole user interface for an application like iPhoto. This would be a perfect place to discuss the role of NSViewController.

I’ve given a lot of thought to the possibility that maybe it is better for Apple to leave this particular design decision to the developers. As I mentioned, the view controllers in an application can grow into a significant portion of the architecture and it is annoying when Cocoa’s designs clash with your own. However, if this is the case, what is the point of adding a view controller to Cocoa? Those of us that have our own view controller system design already have our own view controller class that works in that design. What is the incentive to use NSViewController instead of our own class if it doesn’t present a solution to the larger problem?

I’ve found from my own experience and from talking to other developers, that the design of a view controller system is the kind of design that tends to solve itself naturally within the current Cocoa MVC architecture. There isn’t much room for imagination when it comes to its most basic structure. If you ask developers how they organize their controllers, you’ll almost always get some variation of the same basic design: view controllers own and manage a list of subcontrollers and the window controller owns and manages the view controllers. It isn’t much different from the window and the view hierarchy. The window has a content view and the content view has a list of subviews which contain a lists of subviews, etc.

In fact, this particular relationship – the window and its views to the window controller and its view controllers – is very tight. The view controllers and the window controller build and manage the view hierarchy. The window controller has to add the view controllers’ views to the window’s content view. On top of that, the window controller needs to provide a way for the view controllers to enter the responder chain and, if there is a document, it should also give them access to that. It seems logical that the relationship between NSWindowController and NSViewController should exist by default. The view controllers are, after all, an extension of the window controller.

When programming a large, single window interface, the first enhancements a developer is likely to make to NSViewController, before they can effectively use it in their application, is to add a list of subcontrollers and implement the methods to manage the list. The next thing would be to establish some kind of relationship between this structure of view controllers and NSWindowController. These enhancements are enough to make NSViewController a key player in the current Cocoa controller archtitecture.

Taking the Plunge

The modifications to NSViewController that I mentioned above are simple enough for developers to make on their own. But there are certain caveats that come up in the implementation details that are directly related to Cocoa. These “gotchas” are not obvious until you start to test the design, but they also have to be dealt with before NSViewController can work effectively within the current controller architecture.

This is how I met Jonathan Dann on the Cocoa-dev list. Jonathan’s post was titled, “Correct use of NSViewController”. The title caught my attention because I had just finished my view controller design the week before. I was not too surprised to see that his question had to do with implementing the exact design I’ve described in this post. A few others chimed in with their solutions and it was very clear to me that this design is very obvious and that the issues in it were not unique to my implementation.

Jonathan and I continued our discussion off-list and decided that we would write about the experience we had with NSViewController. In the next post, he and I will describe the issues we came across when we tried to incorporate NSViewController into the Cocoa architecture and also provide our subclasses of NSViewController and NSWindowController as an example of how it might be accomplished.

To be continued…

Resources

Introduction to Document-Based Applications Overview

NSViewController Class Reference

NSWindowController Class Reference

NSViewController documentation bug report - rdar://problem/5794739