Auto-save with Cocoa and Core Data?

At the end of each event in an AppKit app, CoreData will run a -processPendingTransactions for you One side-effect of this is that if you've registered with your NSManagedObjectContext to receive change notifications, you'll get called at the end of each event So, for instance, in your notification handler, you could call just tell the context to save However, you might be paranoid about doing a save on a context while in a callback from that same context, so you'd probably feel better if you did a performSelector:@selector(save:) afterDelay: to push the save until after the -processPendingTransactions is done You could even do a cancel previous on the -save: selector and have the delay be like 5 seconds, so if the user or app is in the middle of a BUNCH of changes they'll all coalesce into a single save And, in fact, that's exactly how Delicious Library 1.0-1.09 worked Wil.

At the end of each event in an AppKit app, CoreData will run a -processPendingTransactions for you. One side-effect of this is that if you've registered with your NSManagedObjectContext to receive change notifications, you'll get called at the end of each event. So, for instance, in your notification handler, you could call just tell the context to save.

However, you might be paranoid about doing a save on a context while in a callback from that same context, so you'd probably feel better if you did a performSelector:@selector(save:) afterDelay: to push the save until after the -processPendingTransactions is done. You could even do a cancel previous on the -save: selector and have the delay be like 5 seconds, so if the user or app is in the middle of a BUNCH of changes they'll all coalesce into a single save. And, in fact, that's exactly how Delicious Library 1.0-1.09 worked.

-Wil.

Thanks for the tip. Both your suggestion and the idea of piggybacking onto the undo manager seem excellent. Of course, your comment begs a question: why do more recent versions of Delicious Library no longer use this technique?

– Pierre Bernard Oct 2 '09 at 13:32 I decided to try saving immediately instead of after a delay, because I am running in multiple threads at once and when, for instance, you create a cover in the main thread, you REALLY want the background graphic threads' managedObjectContexts to see the cover immediately, not in three seconds when you auto-save. – Wil Shipley Oct 3 '09 at 5:13 So Wil do you still call performSelector:@selector(save:) afterDelay: at all or are you using some other method to autosave the context? – John Wright Oct 24 '09 at 16:55 I manually processPendingChanges and save at certain choke points in my code, since processPendingChanges is needed to update the UI when I add or remove and object anyhow.

– Wil Shipley Oct 26 '09 at 8:28 I used this method in an iPhone/iPad app just now. At first I saved right away without using the "performSelector" technique and it seemed fine - but I got too nervous after reading the docs (they say that will cause in infinite loop), so I changed to the performSelector method with a 0.05s delay. – Jason Apr 22 '10 at 20:27.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.