Re: KVO and the observeValueForKeyPath bottleneck
Re: KVO and the observeValueForKeyPath bottleneck
- Subject: Re: KVO and the observeValueForKeyPath bottleneck
- From: Jakob Olesen <email@hidden>
- Date: Mon, 17 Jul 2006 12:38:44 +0200
On 14/07/2006, at 19.44, Matt Neuburg wrote:
I'm just curious about how people are handling the fact that when
you do
KVO, all your notifications are bottlenecked through a single method,
observeValueForKeyPath:... This is a very unpleasant and crude
architecture
(in contrast to NSNotification where, when a notification comes in,
it is
automatically routed to the selector of your choice). I really
don't want a
series of "ifs" here. I can imagine a simple dispatcher
architecture based
on NSSelectorFromString; is this the sort of thing people are
using? Thx -
m.
Here is what I am currently using:
- (void)awakeFromNib
{
[myController addObserver:self forKeyPath:@"selectedObjects"
options:0 context:@selector(selectionChanged:)];
}
- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)
object change:(NSDictionary *)change context:(void *)context
{
if ([self respondsToSelector:(SEL)context])
[self performSelector:(SEL)context withObject:change];
}
Just be really careful to always use a context that is a selector,
otherwise you will probably crash. [NSObject respondsToSelector:]
will probably work for a pointer that is not a selector, but I
wouldn't count on it.
You can of course pass the object or keyPath as well if you need it.
Unfortunately there is no [NSObject
performSelector:withObject:withObject:withObject:] if you need all
three arguments.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden