Re: KVO one-step listening but two-step notifying?
Re: KVO one-step listening but two-step notifying?
- Subject: Re: KVO one-step listening but two-step notifying?
- From: Daniel Jalkut <email@hidden>
- Date: Thu, 22 Dec 2005 20:22:08 -0500
Hamish: I have a somewhat similar situation in that I use bindings to
reflect the state of a model that is part local and part remote. That
is, some model values are set directly in the local model, while
others are merely "cached" in the local model and represent the state
of some distant object.
I think mmalcom's gut feeling that you should design things in term
of dependent objects is probably wise. But I have gotten away with
"blank" will/did-change combos, and I assume they must be safe. It's
not up to the observer to decide how I change the values they are
observing. In the long run, it's probably a good idea to look at the
"blank" notifications and see if the state that leads to them can
instead be represented as a KVO compliant value.
I have assumed that it would be dangerous to just call the
"didChange" without the "willChange," though I admit it feels weird
to say will and did in one fell swoop.
Daniel
On Dec 22, 2005, at 7:53 PM, mmalcolm crawford wrote:
On Dec 22, 2005, at 4:14 PM, Hamish Allan wrote:
I'm trying to implement an KVO-compliant object which proxies a
KVO-compliant property from either one object or another,
depending on an internal setting.
- (id)property
{
if (_setting)
return [_object1 property];
else
return [_object2 property];
}
I can register for change notifications for the appropriate key on
both _object1 and _object2, but these notifications come in the
form of observeValueForKeyPath:ofObject:change:context: messages.
To ensure that my dependents are properly notified, I am supposed
to send two messages: a "willChange" message prior to the change,
and a "didChange" afterwards, but as far as I can tell I only get
the observeValue.. message when _objectN property has already
changed.
What is the best way to ensure KVO compliance in this case?
First, this sounds suspicious. It's not immediately clear why you
would have a pattern like this. That said, it seems like you
simply have a dependency -- 'property' is a key that's dependent on
'setting'. If 'setting' is KVO compliant, then you should just be
able to use setKeys:triggerChangeNotificationsForDependentKey:...
If 'setting' is not KVO compliant, then you will probably get away
with just invoking the will/didChange methods *for 'property'*
directly either in 'setting''s setter method or before and after
you modify 'setting'. If the value of 'property' doesn't actually
change, it doesn't strictly matter (it's just inefficient)... What
does actually matter is if you invoke the change notification
methods after a change has already been made, or "in
isolation" (i.e. invoke one but not the other).
mmalc
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
sweater.com
This email sent to email@hidden
_______________________________________________
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