4

An object needs to be submitted to the server, and I want to indicate to the user that the object needs to be submitted by displaying the lastModified date/time, and lastSubmitted date/time.

(Yes, the record must be manually submitted.)

I'm currently listening for NSManagedObjectContextObjectsDidChangeNotification, checking if the object's entity is RetailLocation, and if so, setting its lastModified date/time (of course, only if lastModified is not the only property being modified). Since this seems to highly confuse the undo manager, I use performSelector:SOMESEL withObject:retailLocation afterDelay:0.0 to set the lastModified property.

Sadly, this is almost even worse: this results in two actions being added to the undo stack!

Can someone recommend a nice way to implement a lastModified attribute in a Core Data-managed record? Alternatively, what am I missing?

Ivan Vučica
  • 9,529
  • 9
  • 60
  • 111
  • Check out Martin R's answer to a similar question here: http://stackoverflow.com/questions/20098544/set-a-lastmodificationdate-attribute-after-nsmanagedobjectsdidchangenotification. That solution worked perfectly for me. – stuckj Dec 09 '13 at 06:14

1 Answers1

1

If you don't want the modification date to be undoable, you can call disableUndoRegistration on your NSUndoManager before making changes, and enableUndoRegistration when you're done.

If you need one, you can get a pointer to the NSUndoManager by calling undoManager on your NSManagedObjectContext, but if you're working in iOS you should have one already.

Also, note Apple recommends using the NSManagedObjectContextWillSaveNotification notification for this, since changes might not necessarily be saved.

Aaron Brager
  • 65,323
  • 19
  • 161
  • 287
  • I'm using `NSPersistentDocument`'s undo manager (which is the same as `NSManagedObjectContext`'s), on OS X. Disabling undo registration does not seem to help, but that's not the ideal solution anyway; if the user performs undo, both modification time and the action should undo within the same undo operation. Ideally this would be done via undo groups, but that's not an option here, considering Core Data is the one that adds operations to undo stack, based on changes triggered by Cocoa Bindings, which are triggered based on user input deep in main runloop... :/ – Ivan Vučica Mar 18 '13 at 12:47
  • I'd go for the `...WillSaveNotification` solution, but the user needs to immediately see that a submission of updated data to the server is necessary. This mildly complex set of requirements is why I ran to SO; I don't see a clean way to do this except by either: 1) not integrating modification tracking as a Core Data attribute, or 2) doing tracking by overriding every single setter of existing Core Data attributes (thus ensuring that tracking is done within the same undo group). I don't like either of the solutions. – Ivan Vučica Mar 18 '13 at 12:50
  • Yeah, it sounds like you might need to override every setter and make a new custom undo group. – Aaron Brager Mar 18 '13 at 14:06
  • Just curious, what did you end up doing? – Aaron Brager Mar 24 '13 at 09:56
  • I'm still sticking with the flawed solution where I have two undo actions on the stack. Never got around to adding custom setters into the class for the entity, but that's the planned route… It's nasty, but it should work. – Ivan Vučica Mar 25 '13 at 10:46
  • Shouldn't you use `NSManagedObjectContextDidSaveNotification`? From the [NSManagedObjectContext](https://developer.apple.com/library/mac/documentation/Cocoa/Reference/CoreDataFramework/Classes/NSManagedObjectContext_Class/NSManagedObjectContext.html#//apple_ref/c/data/NSManagedObjectContextWillSaveNotification) docs it looks like `NSManagedObjectContextWillSaveNotification` doesn't pass a userInfo dictionary while `NSManagedObjectContextDidSaveNotification` does. – stuckj Dec 09 '13 at 04:25
  • FYI, just verified...I'm not seeing a userInfo dictionary for `NSManagedObjectContextWillSaveNotification`, but I do see one for `NSManagedObjectContextDidSaveNotification` in iOS 7. – stuckj Dec 09 '13 at 05:21