Re: Removing object as observer in -willTurnIntoFault
Re: Removing object as observer in -willTurnIntoFault
- Subject: Re: Removing object as observer in -willTurnIntoFault
- From: Jerry Krinock <email@hidden>
- Date: Sun, 30 Mar 2014 23:29:59 -0700
On 2014 Mar 29, at 11:44, Dado Colussi <email@hidden> wrote:
> If you have undo/redo going on, then restart observing in awakeFromSnapshotEvents when NSSnapshotEventUndoDeletion flag is present. Check out the other flags, too.
Thank you, Dado. I’d never noticed that method. I found a couple references to developers doing as you suggest, such as the code snippet by ozpowell (Michael?) in here…
http://stackoverflow.com/questions/4737615/does-nsmanagedobject-willturnintofault-disable-kvo-notifications
Anyhow, you gave me quite a homework assignment! I considered each of the flags and tested some situations. Although I may not have covered all corner cases, I think I’ve eliminated at least one edge case and therefore done some good.
* * *
Question: You do some initialization, adding observers for example, in -awakeFromInsert and -awakeFromFetch, and you tear down these initializations, removing observers for example, in -willTurnIntoFault. Do you need to do anything in -awakeFromSnapshotEvents: ?
To answer, consider each of the event types which may be passed to -awakeFromSnapshotEvents:
NSSnapshotEventUndoInsertion. Don't do anything because -willTurnIntoFault will also be received.
NSSnapshotEventUndoDeletion. You must do whatever initializaiton you do in the other two -awakeFromXxxx methods, because -willTurnIntoFault was received when the object was deleted, and neither of the other two -awakeFromXxxxxx messages will be received.
NSSnapshotEventUndoUpdate. Don't do anything because only object properties were affected, not object existence.
NSSnapshotEventRollback, if this is due to an unsaved object being deleted because it was unsaved. You can't do anything because you won't receive this message. However, you will receive -willTurnIntoFault, so it's OK.
NSSnapshotEventRollback, if this is due to a deleted object being resurrected because the deletion was unsaved. Don't do anything, because you will also receive -awakeFromInsert. Seems weird, but that's what happens.
NSSnapshotEventRefresh and NSSnapshotEventMergePolicy. I have not tested these because my app does not do this refreshes nor have other contexts or processes sharing the database file. I presume/hope that, for example, if an object was deleted or resurrected as a result of a refresh from the disk or conflict resolution, behavior would be the same as NSSnapshotEventRollback; that is, either -willTurnIntoFault or -awakeFromInsert would be received, so no action is necessary.
SUMMARY:
The only event type we need to worry about is NSSnapshotEventUndoDeletion. In that case, one should (re)do whatever initialization is done in -awakeFromInsert and -awakeFromFetch. This is apparently the same conclusion reached by ozpowell.
Of course, you could get away without implementing -awakeFromSnapshotEvents: if the object is not being used in a context that supports Undo, but for “good practice”, implement it.
* * *
Reading Apple's documentation of -awakeFromSnapshotEvents: raises another question. Doc says:
"Invoked automatically by the Core Data framework when the receiver is reset due to an undo, redo, or other multi-property state change.”
The *receiver* here is a managed *object*, so this is referring to when a managed *object* is reset. The Core Data Programming Guide makes no reference to such a thing, so I presume that the writer meant “when the receiver’s *context* is reset” ? Someone please correct me if I’m wrong.
_______________________________________________
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