Гибкость NSUserDefaults для обновлений версий

Я использую api NSUserDefaults api -registerDefaults api для регистрации заводских настроек моего приложения. Все отлично подходит для первой версии приложения. Но когда я предоставляю обновление для приложения iPhone, у меня есть 3 критерия:Гибкость NSUserDefaults для обновлений версий

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

Api -registerDefaults не регистрирует заводские настройки по умолчанию в обновлениях новой версии, поскольку файл plist, содержащий пользовательские настройки, уже существует в/Library/Preferences песочницы. И если мы сбросим настройки с новыми заводскими настройками, пользовательские предпочтения предыдущей версии будут потеряны.

Я думаю, что для таких случаев должен быть шаблон дизайна, так как вообще мы можем справиться с такими ситуациями? Разве Apple не предоставляет какой-либо неотъемлемой поддержки для этого? Или мне не хватает некоторых ссылок, я пробовал работать без каких-либо успехов.

Спасибо, Радж

источник

2010-07-14 Raj Pawan Gumdal

Если этот список элементов, о которых вы говорите, является массивом, зарегистрированным под одним ключом, то да, массив большего размера, переданный в -registerDefaults:, будет игнорироваться в пользу меньшего массива, хранящегося в постоянном plist. NSUserDefaults отслеживает материал по принципу «ключ» и не делает никакой интерпретации содержимого, которое вы храните там, поэтому он не будет пытаться автоматически объединить предыдущие значения массива с новыми значениями массива или что-нибудь подобное.

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

источник

2010-07-14 15:35:37

Это проблема, с которой я столкнулся. Я подумал о вашем подходе, явно поддерживая bool, чтобы указать, что обновление выполнено, скорее я попытался поддерживать версию приложения в пользовательских настройках по умолчанию. Теперь еще одно препятствие: в моей базовой версии приложения есть 10 элементов, если я добавлю 2 элемента в v 1.1 и еще 2 в v1.2, и если пользователь попытается напрямую обновить v1.2, не пройдя через v1.1 , он пропускает элементы v1.1, поэтому я бы внутренне обновил v1.1, а затем до v1.2 в таких случаях. Но так ли это стандарт? Как другие приложения решают эту проблему? Thanx –

Я не знаю, как «стандартный» вы бы это рассмотрели, но я использовал этот шаблон хотя бы один раз раньше. Еще один более простой способ сделать это - просто сдуть любое пользовательское переупорядочение, которое сделал пользователь, и просто установить весь массив при обновлении, а не просто добавлять новые объекты по частям. Меньше удобство для пользователя. –

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

В чем проблема? Если пользователь никогда не изменяет (или точнее: устанавливает) предпочтение, будет использоваться заводская настройка по умолчанию. Если обновление вашего приложения изменит заводские настройки по умолчанию, они будут использоваться вместо этого. Если пользователь установил свое предпочтение, это будет продолжать использоваться.

Новый заводской настройкой по умолчанию не является (и не должен) перезаписывать предпочтение пользователя. NSUserDefaults делает именно то, что вам кажется.

источник

2010-07-14 06:57:12

У меня есть список предметов для отображения, которые я поддерживаю в настройках по умолчанию, в первой версии есть 10 элементов. Я в основном поддерживаю их в настройках, чтобы порядок этих элементов, если они менялись, изменился для следующего запуска. Теперь в новой версии, скажем, я добавил еще 2 пункта. Всего предметов 12 сейчас. Если я сейчас использую -registerDefaults с 12 элементами, то 2 элемента не будут добавлены, потому что настройки параметров уже существуют! Это было бы катастрофой, так как количество элементов не обновляется в новой версии. Кроме того, предметы являются лишь одним из аспектов этого. –

Я согласен с Johan Kool. Пользовательские настройки по умолчанию работают так, как должны. Если есть предпочтение, которое вы хотите изменить (по какой-либо причине) в обновленной версии приложения, просто немного переименуйте предпочтение. Например, если someValue был предпочтительнее в версии 1, то в версии 2 имя будет иметь значение someValue_v2 и ваш новый заводский завод по умолчанию.

источник

2010-07-14 08:12:58 regulus6633

Гибкость NSUserDefaults для обновлений версий

ответ

Смежные вопросы