Re: KVO query
Re: KVO query
- Subject: Re: KVO query
- From: Jonathan Mitchell <email@hidden>
- Date: Thu, 14 Aug 2014 10:33:22 +0100
On 13 Aug 2014, at 23:40, Ken Thomases <email@hidden> wrote:
>
> You have to issue the -willChange… _before_ the property has changed. That's because that's KVO's only opportunity to get the value that's about to become "old" and remove its observations for the properties of that old object.
>
> So, that pattern of issuing -willChange… followed immediately by -didChange… with nothing actually changing in between is a sure sign of a problem.
>
> The solution is annoying but relatively simple. You need to hold a strong reference to the old object in a property of your own. So, you need a property "status" that is _not_ just a pass-through to some other API. It needs to be backed by an instance variable (e.g. _status) that is a strong reference to the object. Then, when you receive the notification from the underlying API that something has changed, you fetch the new object from that API and assign it to self.status. That assignment is KVO-compliant. You can/should then eliminate your manual -will/didChange… invocations.
>
That all makes sense.
I am effectively just propagating the C# PropertyChanged event. This is fundamentally not KVO compliant.
C# also provides a PropertyChanging event, though it is not so commonly implemented.
For managed event changes to be KVO compliant in managed code I will have to ensure that the managed layer events are sent in a may that is KVO compliant when they emerge in unmanaged code.
Thanks
Jonathan
_______________________________________________
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
| References: | |
| | >KVO query (From: Jonathan Mitchell <email@hidden>) |
| | >Re: KVO query (From: Ken Thomases <email@hidden>) |