Re: KVO and Core data
Re: KVO and Core data
- Subject: Re: KVO and Core data
- From: Dave Fernandes <email@hidden>
- Date: Mon, 9 Aug 2010 16:51:25 -0400
Ah. OK. keyPathsForValuesAffecting<Key> wouldn't be directly helpful there. But KVO is easier to use with NS*Controller objects than directly with managed objects. Can you bind your view to one of the standard controllers instead, and have that controller track your managed object?
On 2010-08-09, at 1:03 PM, Gideon King wrote:
> It's a graphical application, and when things change in the back end, I often need to move things around on the screen, so need to invalidate the drawing rect at the old location, perhaps remove some bezier paths, and then need to set it to need display at the new location. I was just thinking that it may be handy for situations like this where I may have a whole lot of different things that could happen in the back end, which all lead to the same action required at the front end (though I will probably still need to use something like a notification queue and coalescing to make sure that I only do the expensive calculations once for a bunch of related changes in the back end.
>
>
> Gideon
>
> On 10/08/2010, at 2:38 AM, Dave Fernandes wrote:
>
>>
>> On 2010-08-09, at 11:13 AM, Gideon King wrote:
>>
>>> Dave's idea of using + (NSSet*)keyPathsForValuesAffecting<Key> may help in some situations, but I don't think it's practical for all, especially where I'm using KVO for my front end to observe changes in the back end and react, where I sometimes need to know the before and after values. I'd have to think about that some more...
>>
>> Actually, it's particularly effective for keeping the UI updated and works with bindings. You provide an accessor method for your attribute and when called, the method first checks toOne's attributes that it depends on and then updates itself to be consistent before returning the new value. However, if you want the 'before' value, you will need your own caching/messaging in there somewhere. How is this information used?
>>
>> Dave
>
_______________________________________________
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