Re: NSArrayController nib binding vs code binding
Re: NSArrayController nib binding vs code binding
- Subject: Re: NSArrayController nib binding vs code binding
- From: Quincey Morris <email@hidden>
- Date: Mon, 18 Jul 2011 22:16:33 -0700
On Jul 18, 2011, at 19:13, Trygve Inda wrote:
> Where am I not KVO compliant?
I can't answer exactly, because you didn't provide enough information. So let me provide an example.
Let's assume the array controller was bound to an array property of an object in the nib of class MyClass, and you want to have your app delegate create the MyClass object instead. Let's also assume the nib file involved here *isn't* the main nib, and that File's Owner of this auxiliary nib is the app delegate. (It doesn't have to be, but if it's something else you need to find the app delegate a different way.)
So, you're going to bind to File's Owner, but what key? How do you refer to the MyClass object that the app delegate created? Well, the app delegate needs a property "myClassInstance", so that the key can be "myClassInstance.places". See? There's "really" another property -- "myClassInstance" -- of the app delegate. If this property is KVO compliant, then it doesn't matter when the binding gets hooked up, because it will *eventually* get notified of the correct MyClass instance.
If your MyClass instance exists only as an instance variable, it isn't a KVO compliant property. That means that the timing of the binding, the timing of the MyClass instance creation, and the timing of the nib file loading need to be perfectly coordinated so that everything exists just at the moment it needs to exist. That timing is hard, or at least annoying, to figure out properly, and failures to figure it out are what drive people to this list with questions about nib bindings that "don't work". :)
If all of this is done with KVO compliant properties instead, then timing isn't an issue. If a *property* has a nil value when something else is getting initialized, it won't matter because it'll eventually get its real value and broadcast the change as a KVO notification.
That's what was behind my suggestions, which were:
1. Put the binding back in the nib file. Bindings (like array controllers) are ugly glue, and the best place for them is in the nib file where at least they don't masquerade as interesting code.
2. Make the MyClass instance available to the nib file as a KVO compliant property of (in my example) the app delegate. How you do it will depend on whatever creates the MyClass instance.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden