Хранение данных приложения iphone в нехватке памяти

У меня есть некоторые структуры данных в моем приложении, которые мне нужно сохранить после получения уведомления didReceiveMemoryWarning. Данные представляют собой текущий журнал всех действий, которые пользователь выполнил с приложением (которое является игрой).

Данные, которые у меня есть, могут быть небольшими (возможно> несколько сотен КБ), поэтому списки не кажутся правильным решением.

Первая из двух возможностей — это архивирование объектов и обеспечение поддержки этими объектами протокола NSCoding. Я не уверен, что это правильный путь.

Второй вариант, похоже, с CoreData, с использованием NSManagedObjectModel и NSPersistentStoreCoordinator. Это хороший способ хранить эти объекты? Или это перебор? (Я использую пример приложения «Рецепты» от Apple для справки).

Мои объекты представляют собой настраиваемые типы объектов, которые в конечном итоге содержат NSString, NSNumber, NSInteger и другие простые типы.

Пример некоторых типов данных, которые у меня есть:

// 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;
}

Пользователь может играть в кучу разных игр, и для каждой игры у меня есть журнал активности, в котором указаны сделанные им ходы. Пользователь может видеть сделанные до сих пор ходы в каждой игре во время игры, а также может переключаться между активными и неактивными играми, чтобы просматривать прошлые ходы.


person Alexi Groove    schedule 24.08.2009    source источник
comment
Было бы уместно опубликовать, для чего вы собираетесь использовать данные. То, как вы хотите получить доступ/получить данные, повлияет на то, какое решение является лучшим.   -  person Jay    schedule 25.08.2009
comment
изменил мой исходный пост, чтобы включить эту информацию.   -  person Alexi Groove    schedule 25.08.2009


Ответы (2)


Предупреждение, вот. Если ваше приложение начинает получать эти сообщения, и вы используете обработчик для записи огромных объемов данных, ядро ​​​​может не позволить вашему приложению закончить сохранение материала, если ситуация будет ужасной (из POV ядра). Какой бы подход вы ни использовали к своему журналу, вы должны постепенно передавать эти данные в резервное хранилище, чтобы вы могли быть уверены, что не потеряете данные, если возникнет такая ситуация.

person Shaggy Frog    schedule 24.08.2009
comment
Спасибо. Я забыл упомянуть, что планирую периодически сохранять данные в приложении. Я просто не знаю, какой из них лучше использовать. - person Alexi Groove; 25.08.2009

Я бы предложил несколько вещей.

  1. Сколько данных на самом деле используется для чего-либо прямо сейчас? Если есть большая вероятность, что он не используется, сохраните его.

  2. Что можно воссоздать/реконструировать?

Взгляните на пример книги SQLite, предоставленный Apple.

Я работаю над приложением, которое по пути создает кучу данных. Большая часть не используется, но я понятия не имею, какие данные будут использоваться. Что я делаю, так это храню небольшой кеш данных, которые, скорее всего, будут использоваться, а остальные отправляются в базу данных SQLite в режиме реального времени. Мои требования к памяти остаются очень маленькими, 100 КБ или около того. В прошлом это были меги (и сбои).

person John Smith    schedule 25.08.2009
comment
В каждой игре часто используются данные, связанные с активной игрой, а также журнал действий. Все остальные игровые данные будут сохранены. Периодически в активной игре мне приходилось сохранять самые последние сгенерированные данные. - person Alexi Groove; 25.08.2009