In the following posts from our Jetpack DataStore series, we will cover several additional concepts to understand how DataStore interacts with other APIs, so that you’ll have everything at your disposal to use in a production environment. In this post specifically, we will be focusing on dependency injection with Hilt. We will be referring to the DataStore Preferences and Proto codelabs throughout this post for code samples.
Dependency injection with Hilt
In these codelabs, we interacted with our DataStore instances through the Preferences and Proto delegate construction once at the top level of a Kotlin file. We would then use the same instance throughout your application, as a singleton:
We require a singleton because creating more than one instance of DataStore for one given file can break all DataStore functionality. However, in a production environment we would usually obtain the DataStore instance via dependency injection. So let’s take a look at how DataStore works with Hilt, a dependency injection library that will help us reduce the boilerplate of doing manual dependency management. If you’re not familiar with Hilt, we encourage you to first go through the Using Hilt in your Android app codelab to learn the basic concepts such as
Modules and others.
First, make sure you’ve added all the necessary setup steps to enable Hilt:
All apps that use Hilt must contain an
Application class that is annotated with
@HiltAndroidApp to trigger Hilt’s code generation, including a base class for your application that serves as the application-level dependency container. In our case, we will create a simple
TasksApp and add it to our
Injecting Preferences DataStore
To obtain a Preferences DataStore instance through injection, we need to tell Hilt how to properly create it. We use the
PreferenceDataStoreFactory and add it to a Hilt module:
We’ve mentioned these parameters previously in the series, but let’s quickly recap:
corruptionHandler(optional) — invoked if a
CorruptionExceptionis thrown by the serializer when the data cannot be de-serialized which instructs DataStore how to replace the corrupted data
migrations(optional) — a list of
DataMigrationfor moving previous data into DataStore
scope(optional) — the scope in which IO operations and transform functions will execute; in this case, we’re reusing the same scope as the DataStore API default one
produceFile— generates the
Fileobject for Preferences DataStore based on the provided
name, stored in
Now that we have a module to instruct Hilt on how to create our DataStore, we need to make a few more adjustments to be able to build successfully.
Hilt can provide dependencies to other Android classes that have the
@AndroidEntryPoint annotation, along with
ViewModel classes. If you annotate an Android class with
@AndroidEntryPoint, then you also must annotate other Android classes that depend on it. For example, if you annotate a
Fragment, then you must also annotate any activities where you use that
That means we need to add the following:
In this sample, we don’t have any other complex injections, such as custom builders, factories, or interface implementations. So we can rely on Hilt and constructor injection for any other dependencies that we need to pass. We will use the
@Inject annotation in the constructor of a class to instruct Hilt how to provide its instances:
Finally, let’s completely remove the
preferencesDataStore delegate from the top of our
TasksActivity as we don’t need it anymore. We will also change how our
viewModel is provided in
onCreate, as its dependencies will now be injected:
Injecting Proto DataStore
Proto DataStore would follow a very similar pattern — you’d additionally need to provide a
UserPreferencesSerializer and a precise instruction on how to migrate from
SharedPreferences, which we’ve covered in more detail in the Proto DataStore post:
That’s it! Now you’ll be able to run the app and verify that all the dependencies are now being injected properly.
To be continued
We’ve covered steps on how to inject DataStore with Hilt for better dependency management, setting up Hilt, using the
PreferenceDataStoreFactory in our
DataStoreModule to instruct Hilt on how to provide our DataStore instance correctly, and finally, providing it to classes that require it.
Join us for the next post of our series where we will be looking into how to use Data Store with Kotlin Serialization.