PreferenceDataStore in Android O

Question

I read this article https://medium.com/@ianhlake/hidden-gems-of-android-o-7def63136629 . This is what is written there:

SharedPreferences is dead. Long live SharedPreferences.

Will SharedPreferences keep working in Android O ? Do we need to implement own mechanism for storing data in key value pairs by implementing PreferenceDataStore

Can anyone help how would be approach to implement new SharedPreferences using PreferenceDataStore& What is use case of developing own implementation ? Any drawback in current approach ?

Kimes

Please do not down-vote the question here before giving any suggestion to the questioner – Ibby

Did you follow the link there to the docs? – Neysa

Answer 1

I can't think of a case where it's applicable only to use PreferenceDataStore instead of SharedPreferences completely but i do think that this can be helpful if you would like to use them together.

SharedPreferences provide you with a great service which is when your app is updated the data still stays in the preferences, but with PreferenceDataStore you also store the data in the same format as in SharedPreferences. Now suppose if you want to use the same preference interface but you would like to store these values in the cloud instead of the device, well because, devices can break down.

What PreferenceDataStore can help you with is that it provides you with the flexibility to store data in any place and write your own implementation. It's not meant to replace SharedPreferences completely though you can do it if you like.

For an example you can use access token of the app in shared preferences, and all the other data in cloud or local db or cloud or maybe file system if you want, and you can use the PreferenceDataStore interface, write down your own implementation and then use it.

even in the link of developer documentation in Google PreferenceDataStore https://developer.android.com/reference/android/preference/PreferenceDataStore.html it's written

In most cases you want to use SharedPreferences as it is automatically backed up and migrated to new devices. However, providing custom data store to preferences can be useful if your app stores its preferences in a local db, cloud or they are device specific like "Developer settings". It might be also useful when you want to use the preferences UI but the data are not supposed to be stored at all because they are valid per session only.

So you can see that even google doesn't want you to use PreferenceDataStore all the time, it's only for the time that when you need to use the same Preferences style of storing key value pairs, but you want to implement your own data store which will provide you with more flexibility then you currently have in SharedPreferences.

For example what if you want to do get SharedPreferences and then put the SharedPreferences data on a cloud server. You want it on the device but also backed up on cloud, In this scenario PreferenceDataStore can help you out.

Genital

Thanks @Ankit Arora. Good answer, do you have a snippet of code how would be implementation if I want my data should be saved on cloud – Kimes

not at this moment regarding PreferenceDataStore, Though it should be very simple to do. You just have to implement the interface in a class and write down the code to save data on cloud, you can go to google drive api link here developers.google.com/drive/android/appfolder this will give you instructions on how to integrate google drive in the app you're working on. Then in the implementation of PreferenceDataStore you can use google drive api. – Genital

Answer 2

You should abandon bad habit of judging the book by its cover and instead of drawing conclusions from just catchy chapter title, simply read the mentioned post fully.

Shared Preferences are not even deprecated in Android Oreo and what Ian Lake mentions is an improvement, which allows your app to keep the same simple key/value pair API as it has now, but additionally be able to provide your own implementation of data store for said data (i.e. in Firebase, remote server, etc). If you do not need that, then you can simply use Shared Preferences as you did so far w/o any change in your code and with such use case nothing really changed.

Llewellyn

Yes. I read. How would be approach to implement new SharedPreferences using PreferenceDataStore – Kimes

What is use case of developing own implementation ? any drawback in current approach ? – Kimes

@yes, it is helpful – Sarah

Answer 3

I think you're reading between the lines here. SharedPreferences are not being deprecated. However they come with their fair share of problems, so in Android O the PreferenceDataStore interface is meant to give the developer an option of developing their own implementation which will be used instead of SharedPreferences. From the docs you can call setPreferenceDataStore and

if the data store is set, the Preferences will no longer use SharedPreferences.

So I think what he meant inside the post was that you now have a built in way of rolling out your own provider to overcome shortcomings of SharedPreferences

Archlute

Thanks. What is use case of developing own implementation ? any drawback in current approach ? – Kimes

Added in API level 26... Deprecated in API level 29. – Confront

Answer 4

I think you have drawn a wrong conclusion, Shred Preferences is working fine in Android O.

In Android O, individual preferences or even the entire PreferenceManager can call setPreferenceDataStore(), allowing your app to keep the same simple key/value pair API, but provide your own mechanism for storing the underlying data.

Read from this link

Smothers

Yep. I know but question is What is use case of developing own implementation ? any drawback in current approach ? – Kimes