I have two NSManagedObject subclasses: Parent and Child. Parent contains many Child(ren) in an OrderedSet. When state changes in a Child I want the parent to know about it.
If I was programming in another language I might use events, having the Parent listening for events from each of its children, however given that target-action is limited to view components, all Objective C offers me is use of a global NSNotificationCenter. I definitely don’t like the idea of a Model tapping into global notifications (listening directly via events is Ok in my book), so it seems my only alternative is Delegation. However using delegation between two NSManagedObjects seems like a dangerous idea, given the difficulty in ensuring one party does not lose its reference to the other.
Does anyone have any suggestions as to how I should be handling this?
Another option is key-value observing. Set it up like this:
the weird constant definition exists because every observing context should be unique so that you don’t tread on superclass or subclass observation contexts. To see what options you need to set, consult the manual and compare with your specific needs. Now whenever that property on your child object changes, your parent will receive:
Check that you have the correct context for your observation, then handle the change. If you get a different context here, forward the message to
super.When you’re done observing the path, you remove the parent as an observer of the child:
Use the same context pointer you used in
-addObserver:forKeyPath:options:contextso that the correct instance of the observation is removed.Delegating, observing and watching for notifications from specific objects all suffer from this problem. You need to make sure that the lifetime of your interest in the notifications matches the lifetimes of the objects involved, otherwise you could easily “leak” observation info or – and this is worse – send notifications to stale object pointers. None of these solutions is immune to that, though in the case of the Delegate pattern you can use a zeroing weak reference to ensure that when the parent object disappears, the child will no longer try to delegate to it.