Re: No more .ibplugins in Xcode 4, so now what...?
Re: No more .ibplugins in Xcode 4, so now what...?
- Subject: Re: No more .ibplugins in Xcode 4, so now what...?
- From: Kyle Sluder <email@hidden>
- Date: Fri, 13 May 2011 11:08:42 -0700
On Fri, May 13, 2011 at 10:24 AM, Sean McBride <email@hidden> wrote:
>>Bindings are also helpful when there are logically
>>multiple KVO observations that need to be made. But often times that's
>>done more simply with a regular property.
>
> I have found bindings very helpful for supporting undo, as model changes
> are automagically updated in the UI. But sometimes they are a PITA. :)
Well, strictly speaking bindings have nothing to do with undo. They're
just a protocol for telling an object, "Hey, that thing you call the
Foo binding? Do whatever magic you need to do to hook it up to this
keypath on this object over here." 99 times out of a hundred, the
object in question is just going to interpret that to mean "add myself
as an observer for the provided keypath on the provided object, and
when I get -observeValueForKeypath:::, use that value to update my foo
property."
(I realize this is probably very old hat for you and many readers of
the list, but it took me an incredibly long time to get this point,
and I suspect many list readers are also at varying stages of bindings
comprehension.)
But if you're implementing the whole kit and caboodle, there's usually
no advantage to adopting the bindings API. For example, we have a
custom view that has three or four bindings on it. You can't use this
view without a delegate that is a subclass of a certain type. At this
point, the bindings are useless to us, because our -setDelegate:
implementation looks like this:
- (void)setDelegate:(DelegateClass *)delegate {
[self bind:@"binding1" toObject:delegate
withKeyPath:@"constantKeyPath" options:nil];
[self bind:@"binding2" toObject:delegate
withKeyPath:@"anotherConstantKeyPath" options:nil];
// etc.
}
Meanwhile, -[CustomView bind::::] just looks like this:
- (void)bind:(NSString *)binding toObject:object withKeyPath:keypath
options:(NSDictionary)options {
if ([binding isEqualToString:@"binding1"])
[object addObserver:self forKeyPath:keypath options:0
context:Binding1Context];
else if ([binding isEqualToString:@"binding2"])
[object addObserver:self forKeyPath:keypath options:0
context:Binding2Context];
// etc.
}
Because we control both sides of the equation, bindings really don't
help us here. We could just as easily call -addObserver:::: from
within -setDelegate:. If we supported arbitrary delegate objects, or
we were releasing this view as part of our public frameworks, the
bindings API might be more worthwhile. But right now it's a vestige
from when we didn't require a certain delegate class.
--Kyle Sluder
_______________________________________________
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