This post is the result of investigation into a stackoverflow.com question of
So, you’ve created a spiffy
NSView of your own, and have decided to make it
compatible with bindings. Great! So you go and read the documentation, and
you look at mmalc’s GraphicsBindings examples. You override
bind:toObject:withKeyPath:options: and everything works. But wait! Why isn’t
NSWindowController ever being deallocated anymore?
Now you’ve got a nasty retain cycle on your hands. You do a little research and
discover that not only do other people have the same problem, but even
Apple’s bindings used to have it a few years ago. How did Apple fix the
problem? With the magic, undocumented class
NSAutounbinder, which nobody
seems to know much about.
Other people will tell you that you don’t need to override
bind:toObject:withKeyPath:options: and that bindings work automatically. This
is only a half truth.
NSObject does provide an implementation of
bind:toObject:withKeyPath:options:, but it only half works. Using the default
NSObject implementation, changes in the model will update the view, but the
reverse is not true. When the bound property of the view changes, nothing
happens to the model.
So, what is a Cocoa developer to do? I’ll explain how to implement your own
bindings that work exactly like Apple’s, with no retain cycles.
found this solution anywhere else, so as far as I know, I’m the discoverer. I
feel so special. It has been mentioned before at least once. The solution
is hard to find, though.