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 Components, Modules and others.

Hilt setup

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 AndroidManifest.xml:

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 CorruptionException is 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 DataMigration for 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 File object for Preferences DataStore based on the provided Context and name, stored in this.applicationContext.filesDir + datastore/ subdirectory

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 @HiltAndroidApp for Application and @HiltViewModel for 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 Fragment.

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 TaskActivity 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.

You can find all posts from our Jetpack DataStore series here:
Introduction to Jetpack DataStore
All about Preferences DataStore
All about Proto DataStore
DataStore and dependency injection
DataStore and Kotlin serialization
DataStore and synchronous work
DataStore and data migration
DataStore and testing