Re: KVO and array item observation
Re: KVO and array item observation
- Subject: Re: KVO and array item observation
- From: Ashley Clark <email@hidden>
- Date: Tue, 28 Oct 2008 18:27:37 -0500
I've made a test project that exhibits this behavior if anyone cares
to look and filed a bug rdar://6327051
http://idisk.mac.com/aclark78-Public/KVONotificationBug.zip
Ashley
On Oct 28, 2008, at 4:30 PM, Ashley Clark wrote:
On Oct 28, 2008, at 2:13 AM, Ashley Clark wrote:
I have a bid revision object that holds a to-many NSSet reference
to a group of items that constitute a tree. Some of those items are
roots and have a nil parent. In my bid revision object I've set up
a rootItems method that uses a predicate to return a filtered set
of the items with nil parents and uses
keyPathsForValuesAffectingRootItems to be aware of changes to the
items set as a whole and generate appropriate KVO notifications.
I have a problem though that when an item that's already in the
set, but not a root, becomes a root by having its' parent set to
nil. This does not cause KVO notifications to be sent out for the
rootItems property because technically the items set as a whole has
not changed.
I naïvely tried to add @"items.parent" to the keyPathsForValues...
method which of course didn't work since you can't observe groups
of properties in a set or array. Right now, I'm sending a
willChange/didChange method pair after performing parent changes of
subitems and after undo/redo events and it *seems* to be working
fine. This seems grotesque though and sure to cause me problems
later.
Is there any way to force a KVO update of a property besides a
willChange/didChange method pair?
Is there a better way?
I've re-architected my design somewhat to work around the issue I
described before and avoid issuing empty willChange/didChange pairs
but I think I'm seeing a bug (in Apple's framework?) now that I'm
not sure how to track.
My object hierarchy looks like this:
JTBidRevision maintains a set of JTBidItem objects that represent
the top items of the tree.
These JTBidItem objects in turn reference a JTInventory object.
And these JTInventory objects each reference a set of
JTInventoryDependency objects.
My JTBidItem class has a method that returns a coalesced ordered
array of objects that it displays as children, some of them are the
JTInventoryDependency objects referenced through its JTInventory
object and others are direct JTBidItem descendants of the node.
The set of dependency objects returned also depends on the state of
a variable in the parent JTBidRevision object. Depending on this
variable some dependency objects will be or will not be part of the
orderedChildren method result.
I've set up my set of keyPaths that affect the orderedChildren set
and it appears to be working in the general case in that if I change
the watched value in my JTBidRevision instance the appropriate
notifications are sent and the tree reloads correctly the first time
for all elements. If I then change that value a second time, one of
my objects has its orderedChildren method invoked twice while
another of the objects gets skipped and the display of the tree is
not updated correctly from that point on.
The JTBidItem objects that are exhibiting this behavior both
maintain a reference to the same JTInventory object.
My keyPathsForValues... method looks like this for my JTBidItem's
orderedChildren:
+ (NSSet *)keyPathsForValuesAffectingOrderedChildren {
return [NSSet setWithObjects:@"children",
@"inventoryItem.dependentInventoryItems", @"owningRevision.piping",
nil];
}
The owningRevision itself is a derived value also with this
keyPathsForValues..., the owningRevision method walks up the tree to
find the owning revision object.
+ (NSSet *)keyPathsForValuesAffectingOwningRevision {
return [NSSet setWithObjects:@"parent", @"bidRevision", nil];
}
Everything else appears to be working fine and the problem only
occurs when two or more bid item objects in my tree both reference
the same JTInventory object. Ideas?
_______________________________________________
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