PreferenceDataStore в Android O

Ответ 1

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

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

Что может вам помочь PreferenceDataStore, так это то, что он обеспечивает гибкость хранения данных в любом месте и создает собственную реализацию. Он не должен полностью заменить SharedPreferences, хотя вы можете сделать это, если хотите.

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

даже в ссылке документации разработчика в Google PreferenceDataStore https://developer.android.com/reference/android/preference/PreferenceDataStore.html он написал

В большинстве случаев вы хотите использовать SharedPreferences, поскольку он автоматически резервное копирование и перенос на новые устройства. Однако предоставление пользовательских данных сохранение предпочтений может быть полезно, если ваше приложение сохраняет свои предпочтения в локальном db, облаке или они специфичны для устройства, такие как "Разработчик настройки". Это может быть полезно также, когда вы хотите использовать пользовательский интерфейс предпочтений, но данные не должны храниться вообще потому что они действительны только для сеанса.

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

Например, что делать, если вы хотите получить SharedPreferences, а затем поместить данные SharedPreferences на облачный сервер. Вы хотите его на устройстве, но также резервное копирование в облаке. В этом случае PreferenceDataStore может вам помочь.

Ответ 2

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

Общие настройки не устаревают в O, и то, о чем упоминает Озеро Яна, является улучшением, что позволяет вашему приложению поддерживать тот же простой API-интерфейс пары ключ/значение, какой он есть сейчас, но предоставить собственный механизм для хранения базовых данных (например, в Firebase, удаленном сервере и т.д.). Если вы не пропустите эту функцию, вы можете просто использовать Shared Preferences так, как вы это делали, без каких-либо изменений в вашем коде.

Ответ 3

Я думаю, вы читаете между строк здесь. SharedPreferences не устарели. Однако они приходят с их большой долей проблем, поэтому в Android O интерфейс PreferenceDataStore призван дать разработчику возможность разработать собственную реализацию, которая будет использоваться вместо SharedPreferences. Из docs вы можете вызвать setPreferenceDataStore и

если хранилище данных установлено, настройки больше не будут использовать SharedPreferences.

Итак, я думаю, что он имел в виду, что у вас теперь есть встроенный способ развертывания собственного провайдера для преодоления недостатков SharedPreferences

Ответ 4

Я думаю, что вы сделали неверный вывод, Shred Preferences отлично работает в Android O.

В Android O индивидуальные предпочтения или даже весь PreferenceManager могут вызывать setPreferenceDataStore(), позволяя вашему приложению поддерживать один и тот же простой API-интерфейс пары ключ/значение, но предоставить свой собственный механизм для хранения базовых данных.

Читайте на этом ссылка