KVO and an array of dictionaries
KVO and an array of dictionaries
- Subject: KVO and an array of dictionaries
- From: Johan Kool <email@hidden>
- Date: Tue, 22 Feb 2005 02:05:27 +0100
Hello all,
I am working on a little graphing view. I want its input to be an
array of dictionaries (one point on the graph per dictionary). I've
made it so that I store two strings that represent the keys from the
dictionary that are used to retrieve the x and y value. This leaves as
much freedom to the model as I can and not letting my model adhere to
my view's requirements.
I have been able to register using KVO for changes in the array, such
as adding and removing. That works well. But I can't figure out how to
register for KVO observing of changes to the dictionaries. Is there
some way that I can ask the dictionary to notify me of any changes in
any of its keys. That way when I observe the change I can check if
it's any of the keys I use and then reconstruct my graph if necessary.
The only thing I can think of now is to send an addObserver::: to each
dictionary for both keys and keep on doing so when I get notified of
changes in the array. Then when the key for say the x-value is changed
I can send removeObserver::: to each dictionary followed my
addObserver:::.
It seems like an ugly construction to me. Is there an easier way?
If I am not mistaken what I describe above is what was suggested here
as number 2 in a thread to a related issue:
>As for tracking the individual attribute changes ("subject", for
>example), you have a few options.
>
>1. Implement the accessors as you outlined (a perfectly practical
>solution)
>
>2. Subscribe for KVO notifications for "properties.subject" each time
>an Email is created (you can use the KVO stuff above to find out when a
>new Email is added to the Mailbox)
>
>3. Make up a fake key like "anyChange" and subscribe to KVO notices for
>it, then make "anyChange" dependent on all other keys. This works great
>for a database since it's often easier to keep things in sync if you
>update the entire record at once, rather than just individual fields.
>
>What I find stylistically displeasing about option #1 is that you can
>end up with a lot of methods that do essentially the same thing. I'd
>rather implement one KVO method that saves changes to the db, but
>that's a personal choice to some degree.
What approach do you advice?
Thanks in advance again!!
Johan
_______________________________________________
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