• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: an oldie but a goodie: observing properties of collected objects
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: an oldie but a goodie: observing properties of collected objects


  • Subject: Re: an oldie but a goodie: observing properties of collected objects
  • From: Matt Neuburg <email@hidden>
  • Date: Thu, 17 Jun 2010 18:16:00 -0700
  • Thread-topic: an oldie but a goodie: observing properties of collected objects

On Thu, 17 Jun 2010 14:51:04 -0700, Jerry Krinock <email@hidden> said:
>
>On 2010 Jun 17, at 12:21, Matt Neuburg wrote:
>
>> My question is, does anyone have a *simple* approach to this common problem?
>
>Not necessarily any simpler, but another technique which may be better than
observing each object in some situations, (although not yours, without
modification).  Implement custom setters for properties you want to observe, and
in them check for value changes and post notifications.  Improve efficiency by
coalescing.  Watch for infinite loops; posting styles can be helpful.
>
>Not a good idea with NSMutableDictionary, though

Yes, I was afraid that might be the way: Don't use NSMutableDictionary,
implement your own model object so you have some more control.

It's a pity that key paths break down when they hit an array.
@"theArray.name" accesses all "name" properties of whatever's in the array,
but @"theArray[0].name" is not a valid path, if you see what I mean... :)

On Thu, 17 Jun 2010 17:33:46 -0500, Ken Thomases <email@hidden> said:
>I'm not sure to which example of mmalc's you're referring, but you should
implement the mutating indexed accessors for your to-many relationship
properties, and always go through those.  So, for example (typed in mail):
>
>-(void)insertObject:(id) object inWidgetsAtIndex:(NSUInteger)index
>{
>    [_widgets insertObject:object atIndex:index];
>    [object addObserver:self forKeyPath:@"name" options:0
context:myUniqueContext];
>}

That's pretending that "self", who owns the array, is also the one who wants
to do the observing, that it always wants to do it, etc. Obviously that's
easy.

I'm talking about the general problem of any object registering through the
array's vendor to get notified about changes in the array's items'
properties. The mmalc solution (in GraphicsBinding) is clear enough -
register for changes in the array, and register for changes in the
properties of every item in the array individually, and then register on
added items or unregister on removed items whenever you hear that the array
has altered - but a beginner might find it heavy going. m.

--
matt neuburg, phd = email@hidden, <http://www.tidbits.com/matt/>
A fool + a tool + an autorelease pool = cool!
AppleScript: the Definitive Guide - Second Edition!
http://www.tidbits.com/matt/default.html#applescriptthings



_______________________________________________

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

  • Follow-Ups:
    • Re: an oldie but a goodie: observing properties of collected objects
      • From: Ken Thomases <email@hidden>
  • Prev by Date: Re: an oldie but a goodie: observing properties of collected objects
  • Next by Date: Re: mutableArrayValueForKey: truth or dare
  • Previous by thread: Re: an oldie but a goodie: observing properties of collected objects
  • Next by thread: Re: an oldie but a goodie: observing properties of collected objects
  • Index(es):
    • Date
    • Thread