Re: Question about notifying KVO observers of changes to a property.
Re: Question about notifying KVO observers of changes to a property.
- Subject: Re: Question about notifying KVO observers of changes to a property.
- From: Peter Duniho <email@hidden>
- Date: Thu, 21 May 2009 18:24:51 -0700
On May 21, 2009, at 5:43 PM, Morales Vivó Óscar wrote:
On May 21, 2009, at 16:34 , Peter Duniho wrote:
On May 21, 2009, at 11:33 AM, Morales Vivó Óscar wrote:
I have an cocoa controller object with a property that is
actually read from another, C++ object. It works fine when
updating or reading the value, but sometimes other C++ parts of
the program will change the value of the property and there's no
good way to notify the cocoa controller object of the change.
I wanted to know if it's an issue from, elsewhere in the program,
just call the object's willChangeValueForKey: and
didChangeValueForKey: for a property that automatically notifies
when directly changed, or if there's a more immediate and
officially sanctioned way of letting an object know that it
should notify its observers that one of its properties has
changed its value.
Sorry if this is a silly question, but...
If you are able to call the associated KVO methods
(willChangeValueForKey:, didChangeValueForKey:), why can't you
just call the property setter? [...]
Good point. The problem I'm having is that I don't know when to call
the "willChange…" method, only that sometimes I need to call the
"didChange…" one.
Um, okay. So did I misunderstand the question? You seemed to be
asking whether there would be a problem calling "willChange…" and
"didChange…" when you change the value directly in C++.
I don't have an answer for what the best way to solve the problem
would be. But if it were me, I'd do one of two things, depending on
how much encapsulation you want in your C++ code (i.e. do you want the
C++ code to know about your Obj-C class, or Obj-C at all?).
If you want encapsulation, I'd implement some kind of "event" pattern
in your C++ code, by which a client callback can be executed whenever
the value needs to be updated. Then your Obj-C class can use a C/C++
helper function or class to subscribe to the event, which would then
forward that to the Obj-C object itself, where the appropriate KVO
notifications can be handled.
If you don't want that much encapsulation, then I would just make all
value changes go through the Obj-C object, which the C++ code would
know about. In the C++ code, rather than setting the value privately,
you'd always set it through the Obj-C setter, which would of course
turn around and set the C++ value (and implicitly raise the
appropriate KVO notifications).
Basically, it seems to me that the first step you need to address is
how to inform the Obj-C object of changes from within the C++ code.
Until you've solved that aspect, I think it's premature to wonder what
the precise mechanism for raising a KVO notification is, should be, or
can be.
As for the question as to whether it's kosher to execute the
"willChange…" and "didChange…" methods explicitly (assuming that's a
question you're asking...as you can see, I'm not entirely sure about
that :) ), since the docs say "You invoke this method when
implementing key-value observer compliance manually", I'd say that's
exactly what Apple expects you to do. :)
If you don't use the second approach I describe (always going through
the Obj-C setter, even from your C++ code), one thing you should
probably be careful of is the question of updating the value before
the "willChange…" method has been executed. In other words, you
probably don't want to just have the C++ code sending a single
notification to the Obj-C object; if the value change is going to be
handled privately within the C++ code, the C++ code needs to provide a
notification both before and after the value has changed.
Obviously if you always go through the Obj-C setter, even to set the
value from within the C++ code, then the KVO notifications will be
handled automatically and in the correct order. :)
Pete_______________________________________________
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