Re: KVO & Bindings: Proxy object & change notifications
Re: KVO & Bindings: Proxy object & change notifications
- Subject: Re: KVO & Bindings: Proxy object & change notifications
- From: Dave Keck <email@hidden>
- Date: Tue, 10 Mar 2009 21:09:39 -1000
Hey Ken, thanks for your reply.
> Are you sure that PrefCtrl is returning the same proxy each time?
Yes. The proxy object is setup in PrefCtrl's -init, and is never changed.
> Also, at the time that you invoke -willChangeValueForKey: have you already
> changed your internal state such that invoking [theProxy
> valueForKey:@"someFeature"] returns the "after" value? It should still
> return the "before" value at that point. It must not return the "after"
> value until after the -willChangeValueForKey: call completes.
I'm changing the value of the 'someFeature' key after willChange, and
before didChange. That is, from the context of PrefCtrl:
// #1: value for 'someFeature' is nil at this point
[self willChangeValueForKey: @"values"];
// #2: value for 'someFeature' is still nil at this point
[valuesDictionary setValue: someFeature forKey: @"someFeature"];
// #3 value for 'someFeature' is NOT nil at this point
[self didChangeValueForKey: @"values"];
// #4 value for 'someFeature' is the same as point #3 (still not nil)
(Note that valuesDictionary is PrefCtrl's underlying backing store for
all the prefs.)
> That's what it's complaining about. It's saying that [theProxy
> valueForKey:@"someFeature"] isn't the same object it was when the
> observation was established, so KVO can't unhook itself from the object it
> had earlier hooked into. Note that it's attempting this unwinding during
> -willChangeValueForKey:. Of course, that object won't be the same _after_
> -willChangeValueForKey: -- you are, after all, changing it -- but it needs
> it to be the same _at_ -willChangeValueForKey: for KVO's housekeeping to
> work.
I'm not sure if it's relevant, but does it matter that someFeature is
originally nil - I'm assuming it couldn't possibly have an observer
before I change the value to something non-nil...?
> Also, since KVO was watching the "someFeature" property of the proxy, and
> that property is different than it was, but KVO never noticed that it
> changed, it's reporting that the property changed in a non-KVO-compliant
> fashion. Since you are using a proxy to front for your PrefCtrl, are you
> also making sure that all changes of PrefCtrl's properties cause change
> notifications for the proxy's virtual properties? That is, are you
> forwarding all -will/didChange... invocations on your PrefCtrl object to
> your proxy, at least for keys other than "values"?
That's precisely my issue - because the prefs can be changed from
other processes, the app doesn't know which specific properties
changed - all it knows is that there was a change. Of course I could
find out what specific changes occurred by comparing the new prefs
with the old prefs, but I find it far more convenient just to issue a
blanket willChange/didChange: @"values". To emulate this situation, in
my example project I use the code above, which modifies PrefCtrl's
'valuesDictionary' backing store directly, surrounded by the
willChange/didChange: @"values". I've tried sending individual
willChange/didChange for every key that's in PrefCtrl - and it works -
I just don't understand why just sending willChange/didChange:
@"values doesn't (at least for a 3+ segment key path.) Again, the
example project that exhibits this issue is here:
http://www.docdave.com/kvo_project.zip
> You may be able to eliminate the proxy altogether, by the way. Have you
> tried having the "values" property of the PrefCtrl object just return "self"
> -- the PrefCtrl object itself? That would avoid the need to forward things
> in either direction, but still give you the ability to will/didChange... the
> "values" property to provoke a wholesale updating of all observers of any
> properties. At least, I think that should work.
I decided to go the proxy route simply because PrefCtrl has some of
its own properties that I didn't want to get confused with actual
preferences... to me, it just seems cleaner.
Thanks!
David
_______________________________________________
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