Storing iphone application data on low memory

Question

I have some data structures in my app that I need to persist upon receiving 'didReceiveMemoryWarning' notification. The data is kind of a running log of all of the actions the user has performed with the app (which is a game)

The data I have may not be a small amount (possible > few hundred KB) so plists don't seem to be the right solution.

The first of two possibilities is archiving objects and making these objects support NSCoding protocol. I'm not sure if this is the right path to choose.

The second option seems to be with CoreData, using NSManagedObjectModel and NSPersistentStoreCoordinator. Is this a good way to store these objects? Or is it overkill? (I'm using the 'Recipes' sample app from Apple for reference).

My objects are custom object types which eventually hold NSString, NSNumber, NSInteger and other simple types.

Sample of some of the data types I have:

// this the base object I need to start with to persist
@interface MyDataObject : NSObject
{
    MyScore        *aScore;
    // Contains an object of type 'MyAction'
    NSMutableArray *allActions; 
}

@interface MyScore : NSObject
{
    NSInteger  currentScore;
    NSDate     lastUpdated;
}

@interface MyAction
{
    NSNumber   *actionId;
    NSString   *description
    MyUser     *associatedUser;
}
@interface MyUser
{
    NSNumber *id;
    NSString *name;
    NSString *email;
}

User can play a bunch of different games and for each game, I have an activity log of what moves they've made. The user can see the moves they've made so far in each game while they're playing it and they can also switch between active & inactive games so they can review the past moves as well.

Answer 1

A warning, here. If your app starts getting these messages, and you're using the handler to write out huge gobs of data, the kernel may not let your app finish saving stuff if the situation is dire (from the kernel's POV). Whatever approach you use with your log, you should be dripping this data to the backing store gradually, so you can be confident that you won't lose any data if this situation occurs.

Answer 2

I'd suggest several things.

1. How much of the data is actually being used for anything right now? If there's a good chance it's not being used then save it.

2. How much can be recreated/reconstructed?

Take a look at the SQLite book example provided by Apple.

I am working on an app which creates gobs of data along the way. Most is not used, but I have no idea which data will be used. What I do is keep a small cache of the data most likely to be used and the rest goes to the SQLite database in realtime. My memory requirements stay very small, 100K or so. In the past it was megs (and crashes).