Guidelines for creating non-view objects in a XIB file

Question

Interface Builder provides the ability to create non-view/controller objects in a XIB file. In the past I have used this feature to instantiate and wire-up small components that manage view components in the XIB and this seemed a fairly reasonable thing to do.

However, I was wondering what other legitimate uses there are for this feature. It is rather attractive tool as it effectively moves the responsibility for instantiating and injecting the dependencies of such objects out of your code and onto the framework.

In the case of Interface Builder I am curious to know what the guidelines are for using this dependency injection feature?

Answer 1

No guidelines, you're on your own.

Edit after teabot's comment: Look, to me it's still not clear how nib memory management really works. When I release a window controller that owns the nib, do the deserialized objects really leave memory?

I think I read somewhere that if you are using bindings between nib controls and the window controller you get a leak and in some cases I got into funny nib-related annoyances myself.

It's also it's very difficult to track down some nib-related bugs as wrong binding keys or missing action IB links.

So I prefer to keep the nib contents to a minimum, usually all the stuff you need to make full use of bindings (usually array controllers) but no more.

[I got an idea for a new question]

Answer 2

The rule of thumb I use, is auxiliary objects can be put in if they are related to the UI being defined in the nib in some way - so either proxy objects that hold references to elements or actions that get triggered.

Proxy methods all get wired in when loading the nib and pass in the already created object via the userinfo dictionary you can optionally pass in along with the nib name.

There's nothing at all wrong though I think, in a purely logical nib that would use the target/action system to wire up multiple proxy objects. That might be easier than doing all the wiring in code, though I've not seen that used in practice.