Android O中的PreferenceDataStore

我读了这篇文章https://medium.com/@ianhlake/hidden-gems-of-android-o-7def63136629 。 这是写在那里的:

SharedPreferences已经死了。 万岁SharedPreferences。

SharedPreferences继续在Android O中工作吗? 我们是否需要通过实现PreferenceDataStore来实现自己的机制来将数据存储在键值对中

任何人都可以帮助如何将方法来实现新的SharedPreferences使用PreferenceDataStore &什么是开发自己的实现的用例? 目前的做法有什么缺点?

我想不出一个只适用于PreferenceDataStore而不是SharedPreferences的情况,但是我认为如果你想一起使用它们会有帮助。

SharedPreferences为您提供了一个很好的服务,即当您的应用程序更新时,数据仍保留在首选项中,但PreferenceDataStore还可以使用与SharedPreferences相同的格式存储数据。 现在假设你想要使用相同的首选项接口,但是你想把这些值存储在云端而不是设备中,那么就是因为设备可能会崩溃。

PreferenceDataStore可以帮助您的是它提供了在任何地方存储数据并编写自己的实现的灵活性。 这并不意味着完全替代SharedPreferences,尽pipe你可以做到这一点,如果你喜欢。

例如,您可以使用共享首选项中应用程序的访问令牌,以及云中或本地数据库或云中的所有其他数据,也可以使用文件系统(如果需要),并且可以使用PreferenceDataStore接口,写下您自己的实现,然后用它。

即使在Google PreferenceDataStore https://developer.android.com/reference/android/preference/PreferenceDataStore.html中的开发人员文档链接

在大多数情况下,您希望使用SharedPreferences,因为它会自动备份并迁移到新设备。 但是,如果您的应用程序将其首选项存储在本地数据库,云中,或者它们是特定于“开发人员设置”的设备,则提供自定义数据存储到首选项可能会很有用 当您要使用首选项UI时,它可能也很有用,但数据不应该被存储,因为它们仅在每个会话中有效。

所以你可以看到,即使谷歌不希望你一直使用PreferenceDataStore,只是当你需要使用相同的Preferencestypes的存储键值对,但是你想实现你自己的数据存储将为您提供更多的灵活性,那么您目前在SharedPreferences中拥有的灵活性。

例如,如果您想要获得SharedPreferences,然后将SharedPreferences数据放在云服务器上。 你想在设备上,但也备份在云上,在这种情况下,PreferenceDataStore可以帮助你。

你应该放弃用书来判断封面的坏习惯,而只是简单地阅读上面提到的这个post,而不是从上传的章节标题中得出结论。

在O中甚至不推荐使用共享首选项,而Ian Lake提到的是对这个特性的改进 ,允许你的应用程序像现在一样保持简单的键/值对API,但是提供你自己的机制来存储底层数据Firebase,远程服务器等)。 如果你不错过这个function,那么你可以简单地使用共享首选项,就像你没有任何改变你的代码一样。

我认为你在这里阅读。 SharedPreferences不被弃用。 然而,他们带来了公平的问题,所以在Android O中, PreferenceDataStore接口意味着开发人员可以select使用自己的实现来代替SharedPreferences。 从文档中你可以调用setPreferenceDataStore

如果设置了数据存储,则首选项将不再使用SharedPreferences。

所以我认为他在post里的意思是说,现在你已经build立了自己的提供者来克服SharedPreferences缺点

我认为你得出了一个错误的结论,Shred Preferences在Android O中工作正常。

在Android O中,个人偏好甚至整个PreferenceManager都可以调用setPreferenceDataStore(),允许应用程序保持简单的键/值对API,但提供自己的机制来存储底层数据。

从这个链接阅读