I have been getting my feet wet with Core Data. I’m writing a card game and I’m able to store and retrieve game statistics. I’m also storing the game’s state after each move to allow the application to resume a game that was in progress when the application quit and to also facilitate my home-brew undo system.
Unfortunately, the longer I play my game the slower it feels. I think this is because after each move I’m storing 52 cards and their specific states in SqlLite. I suspect that this just gets slower the more data I cram into the DB.
Because of this, I plan to try using the built-in undo management in Core Data. (I didn’t remember this was there until it was too late on my initial implementation.) My question is, if the app is closed mid game, can it be restarted with the undo management in the same state?
IE: Imagine a user makes ten moves in this game. They would be able to undo ten times. If they quit the app and close it entirely and then restart the app, can I return Core Data to a state where the user will still be able to do the ten undo steps?
A little bit of research suggests I might be able to simply use NSCoding to persist the NSManagedObjectContext to a serialized file when the app is closed and then restore it’s state from this file when the app is restarted.
Am I on the right path? Any suggestions?
Thanks!
NO UndoManager is not persistent.
Yes you may use NSCoding or even a Plist for saving the state.
For more information on this topic you may refer
http://www.cimgf.com/2011/10/11/core-data-and-the-undo-manager/