Android. Общие настройки. Поврежденные данные извлечены в случае сбоя - PullRequest
0 голосов
/ 03 апреля 2012

Это скорее запрос вашего мнения в чем-то, а не вопрос. Это будет вроде длиной , так что не беспокойтесь, если у вас не хватает терпения прочитать все это. Остановитесь здесь, если вы этого не сделаете:)

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

Проблема, с которой я столкнулсяМысль о том, что если по какой-либо причине приложение принудительно закрывается, например, батарея умирает, пока сохраняются значения, то когда пользователь пытается возобновить с того места, на котором он остановился, данные не будут действительными, как это было раньше.Ранее полностью не сохранялось (например, удалось сохранить только 2 из 5 значений).

Как я решил преодолеть эту проблему, это сохранить данные дважды, в «ДВЕ СЛОТА» (что я имею в видуПо слоту каждое значение, как я уже говорил, есть несколько значений, будет храниться либо в «valueName_1», либо «valueName_2»), и наряду с обычными хранилищами значений, я также сохраню два значения в настройках, которые будутиспользуется для проверки, были ли данные полностью сохранены или нет.Одно из этих двух значений curSavingSpot будет относиться к позиции в одном из этих двух слотов, в которых я LAST сохранил (или имейте TRIED для сохранения в случае сбоя) значенийа другой curSavedSuccessfully будет отслеживать , если сохраненные в LAST значения ВСЕ хранили успешно .

Например:

  • изначально каждое поле в Shared Pref равно нулю.curSavingSpot указывает на 1 (первый «слот»), а curSavedSuccessfully ложно.
  • я начинаю сохранять значения в слоте 1 и сохраняю их без каких-либо прерываний, поэтому curSavedSuccessfully будетБудьте верны, поскольку мы успешно сохранили все значения

  • через 2 секунды, я начинаю сохранять новые значения.На этот раз в слоте 2. Но сначала я установил значение curSavingSpot в 2 И curSavedSuccessfully в false.Скажем, когда я сохраняю 3 из 5 значений (осталось еще 2), устройство вылетает.Когда я перезагружаю его, я сначала проверю, успешно ли завершился последний сеанс сохранения, в соответствии с curSavedSuccessfully, что не произошло, поэтому я смотрю на curSavingSpot и принимаю противоположное значение, в этом случае я знаю 2не завершился успешно, поэтому это означает, что 1. имеет правильные значения.

Что вы думаете?Это хороший способ сделать это?Есть ли лучший способ убедиться, что он сохранил все необходимые значения?

Есть предложения?Есть ли недостатки этой идеи?

Извините за длинный пост.

Ответы [ 2 ]

4 голосов
/ 04 апреля 2012

Честно говоря, для меня это звучит так, будто вы слишком обдумываете это. Методы commit () и apply () SharedPreferences утверждают, что они атомарные, это означает, что либо все изменения в SharedPreferences происходят, либо ни одно из них не происходит. Пока вы не вызываете commit () более одного раза (после того, как вы внесли все свои изменения), все будет в порядке. По сути, ваш сценарий, в котором вы можете зафиксировать только некоторые настройки, никогда не будет реализован. Если ваши значения недействительны при индивидуальной фиксации, нет смысла фиксировать их одну за другой, просто зафиксируйте их, когда они все будут готовы для фиксации.

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

1 голос
/ 03 апреля 2012

Я бы посоветовал вам использовать «Внутреннее хранилище» для резервного копирования. Я предполагаю, что это немного медленнее, чем «общие предпочтения», но внутреннее хранилище предназначено для хранения данных в большем количестве, а общие предпочтения, как следует из названия, предназначены для предпочтений (конечный набор информации, часто не меняющийся).

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

И, вероятно, пользователи не убивают свои запущенные приложения только потому, что, я думаю, ваше приложение убивается довольно редко. А для всего остального есть onDestroy (), где вы можете сохранить все свои вещи.

ура!

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...