Re: Design Question
Re: Design Question
- Subject: Re: Design Question
- From: Kaelten <email@hidden>
- Date: Thu, 6 Aug 2009 09:46:06 -0500
Fair enough. I guess what I'm wondering then is how do I handle the
following case. I have several loosely coupled properties which can
read somewhat like this.
(ProjectInstall *)projectInstall {
return [ProjectInstallController projectInstallWithProjectId:projectId];
}
And in some cases it's completely legit for the loose coupled
properties to return nil
What's the right way for this property to be KVO/KVC compliant? I
really do like bindings and believe that it's absolutely possible to
get it done right I'm just trying to figure it out.
Thanks for the input,
Bryan McLemore
Kaelten
On Thu, Aug 6, 2009 at 12:35 AM, Quincey
Morris<email@hidden> wrote:
> On Aug 4, 2009, at 11:35, Kaelten wrote:
>
>> I have an application I'm working on where I'm using mainly Bindings
>> for communicating with the UI, but I find myself in situations where
>> I'm not getting all the data updates to the UI.
>>
>> These lack of updates seem to stem either from dependent keys, loose
>> coupling between objects, to-many relationships, and nullable
>> relationships.
>>
>> I work around the first one mostly with
>> setKeys:triggerChangeNotificationsForDependentKey: (I'm targeting
>> 10.4).
>>
>> It's the other three cases that I'm having a slight issue with. One
>> thought I had is that I could craft notifications so that the loosely
>> coupled objects and nullable relationships can listen for something
>> that'd cause them to need to update.
>
> It's all about KVO compliance. If you update your data model
> KVO-compliantly, then its observers (e.g. the user interface) will notice
> the changes.
>
> The documentation isn't very clear, but the "granularity" of KVO compliance
> isn't obvious. An *object* (an instance) is KVO-compliant for a *property*
> (a string name) or its not. Typically, all objects of a class have the same
> KVO-compliance for their properties, due their shared class implementation,
> so it's reasonable to talk about the KVO compliance of a class for a given
> property. If you have a lot of properties, you have a lot of compliance
> issues to deal with.
>
> So, it's not an issue of loose couplings, or to-many relationships or
> nullable relationships -- they'll all work fine if the corresponding
> properties are updated KVO-compliantly, and that has to be taken on a
> case-by-case basis. Sorry.
>
> If you want ask specifically about certain of the malfunctioning properties,
> you might get answers you can adapt to the others. I just don't think
> there's a general answer, except that it really does work, if you Do It
> Right(tm).
>
>
> _______________________________________________
>
> 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
>
_______________________________________________
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