Outline views are great for displaying hierarchical data because they allow the user to drill down into the parts of the dataset that are the most interesting.
A common place where they show up is in file handling windows. So. My last example in this column will be a directory browser. To build an outline view, all you have to do is create the view in Interface Builder, hook it up to your code and implement 4 specific delegate methods. Simple really.
It turns out that unless you try and understand some of what NSOutlineView does behind the scenes, the chances of actually hooking up your data right are remote… If you have a bug, what tends to happen is that you either get an exception/crash or nothing happens. And since much of the inner workings take place beneath the hood inside runtime, it’s not as if you can put a breakpoint inside the NSOutlineView to see what’s going on. It can take many NSLogs in your code to get some visibility.
You can think of delegate methods like the outsourcing of a task. When the outline view needs to know more about the data that you would like to display in the view, it simply calls the relevant “delegate” method and expects an answer.
These methods are the interface between your dataset and the onscreen view. At a minimum, NSOutlineView requires you to implement 4 delegate methods in your code. There are several other delegates that are strictly optional and which add more functionality to your outline view.
It’s easier to call the 4 compulsory delegates Method 1-4 instead of their full names; besides, this is the order in which runtime tends to call them anyway, so it’s a useful frame of reference.
Let’s dig in to how it all works.
– (int) outlineView: (NSOutlineView *) outlineView numberOfChildrenOfItem:(id)item
This is the first delegate that runtime will call to populate your outline view. It asks the question: “For the node that you just clicked on to expand, how many children objects should I allow for?”
This method is only called on one of 2 occasions. Either:
- When the view is first displayed at start up and runtime needs to know the contents of the Root level of your data
- When a node is expanded and runtime needs to start building the display of that node’s children.
Since these cases both happen relatively rarely, Method#1 tends to be called the least frequently out of the 4 delegates.
The next delegate methods #2 and #3 will be called the number of times you specify in the number you return now. So, if you return “3” here, they will get called 3 times.
2 values are passed to this delegate by runtime:
- (NSOutlineView *) outlineView (or whatever you choose to name the view). This pointer is passed to you in all 4 delegates so I’m only going to bother to explain it once here. When you build an outline view in Interface Builder, you have the option of making a multi-column display. You could have 2 different outlines displaying in each column. To let you know which outlineview runtime is talking about, it sends you a pointer. For a simple 1 column outlineview, you can ignore this pointer.
- (id) item. This is a pointer to the object associated with the node that the user clicked on. For example, in the above diagram, when the user clicked on “Applications”, the pointer to item here would point to the object associated with Applications. There