NEWS ROOM

Android preferences tutorial

Let’s fill our Knowledge shops!

In Android apps, we usually retailer easy knowledge units utilizing native preferences. These preferences are easy, quick, and straightforward to entry. Or we do it with SharedPreferences or DataStore Preferences. In a use case the place we’re utilizing SharedPreferences and wish to migrate to DataStore Preferences then it might have an effect on many elements of our code.

So on this article we’re going to:

• Create a separate module for our preferences and we’ll maintain the remainder of the modules no matter the kind of preferences we’re utilizing.
• Use Hilt for dependency injection from our desire module to our essential app module

We are going to contemplate that:

• Our app merely accepts a username
• Because the person varieties the identify, it’s instantly saved and up to date and displayed over a textual content view on the identical display screen.

We are going to create a brand new module as an android library module and identify it as native desire. To create a brand new module, proper click on in your venture identify -> New -> Module

Then choose Android Library and fill within the particulars as anticipated.

Click on end and we are going to create our native desire module.

Though this appears quite simple, we will have various kinds of preferences, for instance, UserDevicePreference, LoginPreference, AppPreference, and many others.

On this structure, now we have uncovered solely the endpoints required for our essential :app module associated to a person’s preferences by means of the UserPreference interface. Now him :app don’t fret about how and the place the info is saved.

Setting DataStore preferences

So as to add knowledge storage preferences, we have to add the dependency in local-preference construct.gradle

// inside local-preference construct.gradle
implementation "androidx.datastore:datastore-preferences:1.0.0"

We outline our UserPreference interface as follows

interface UserPreference 
/**
* returns person identify stream
* */
enjoyable userName(): Circulate<String>
/**
* saves person identify in knowledge retailer
* */
droop enjoyable saveUserName(identify: String)

The features are self-explanatory. We offer your UserDataStore implementation as:

class UserDataStore @Inject constructor(
personal val dataStore: DataStore<Preferences>
): UserPreference 
override enjoyable userName(): Circulate<String> 
return dataStore.knowledge
.catch 
emit(emptyPreferences())

.map  desire ->
desire[KEY_USER_NAME] ?: ""

override droop enjoyable saveUserName(identify: String) 
dataStore.edit  desire ->
desire[KEY_USER_NAME] = identify

Getting knowledge from the datastore returns a stream that could be a nice deal. Right here we merely return our saved username as a stream. That is useful as a result of any change to the username will replace our stream immediately and we will work on the newest adjustments.

Saving the username can also be fairly easy, however word that this can be a sleep perform and should be known as inside a routine scope.

Grip Configuration

We inject the datastore object into the UserDataStore utilizing Hilt. So as to add Hilt we have to add a plugin and dependency in native desire construct.gradle as under (identical for :app module)

plugins 
...
id 'kotlin-kapt'

...
dependencies 
...
// hilt
implementation "com.google.dagger:hilt-android:2.44"
kapt "com.google.dagger:hilt-compiler:2.44"

And since this can be a completely different module than :app and each modules will use Hilt, so we outline the Hilt plugin generally throughout the construct.gradle file on the venture degree as follows:

plugins 
...
id 'com.google.dagger.hilt.android' model '2.44' apply false

Going again to our native desire module, we offer our knowledge storage object as a single as follows:

@InstallIn(SingletonComponent::class)
@Module
object DataStoreModule 
@Offers
enjoyable provideDataStore(@ApplicationContext context: Context) : DataStore<Preferences> 
return PreferenceDataStoreFactory.create(
corruptionHandler = ReplaceFileCorruptionHandler(
produceNewData =  emptyPreferences() 
),
produceFile =  context.preferencesDataStoreFile("user_data") 
)

And we offer the implementation of the UserPreference object as follows:

@InstallIn(ViewModelComponent::class)
@Module
summary class UserPreferenceModule 
@Binds
summary enjoyable bindUserPreferences(impl: UserDataStore): UserPreference

To notice that we offer UserPreference inside ViewModelComponent, it is because this desire object shall be legitimate till our view mannequin lives.

Since now we have our preferences set, we will now use them in our essential software. First we add the native desire module to our :app module including the dependency as follows:

// Native preferences
implementation venture(path: ':local-preference')

Then we add hilt on our essential :app module in the identical manner we did for the native desire. We mark our essential software as HiltApplication.

@HiltAndroidApp
class DataStoreApplication: Software()

We then create our MainViewModel view mannequin and inject a UserPreference into it. We additionally mark it as HiltViewModel and it seems to be like this:

@HiltViewModel
class MainViewModel @Inject constructor(
personal val userPreference: UserPreference
) : ViewModel() 

We then outline our strategies within the view fashions to learn and write the username as proven:

/**
* username stream to look at adjustments in person identify
* */
val userName: StateFlow<String> = userPreference.userName().filter 
it.isNotEmpty()

.stateIn(
viewModelScope,
SharingStarted.WhileSubscribed(),
"No saved knowledge"
)
/**
* save person identify
* */
enjoyable saveUserName(identify: String) 
viewModelScope.launch 
userPreference.saveUserName(identify)

userName is a stream that’s transformed to a dynamic stream utilizing stateIn and is collected within the UI with the lifecycle state as proven under.

val userName: String by viewModel.userName.collectAsStateWithLifecycle()

We might have used the conventional stream, however then we must make a unique association to take a look at it with the UI lifecycle.

The username is just saved in a coroutine scope utilizing the UserPreference object.

Word: To make use of the collectAsStateWithLifecycle() perform, we have to add a dependency as follows:

implementation "androidx.exercise:activity-ktx:1.6.1"

Then lastly we use all of the settings in our composable UI and show the info as it’s saved and up to date.

bam! We create a separate layer for our preferences. This additionally helps velocity up development time on a large-scale venture. You may attempt to do extra with it and mess around with completely different eventualities.

You could find the total code on GitHub.

Join with me (if the content material is beneficial to you) at

Till subsequent time…

Well being!