DataStore and dependency injection
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 aCorruptionException
is thrown by the serializer when the data cannot be de-serialized which instructs DataStore how to replace the corrupted datamigrations
(optional) — a list ofDataMigration
for moving previous data into DataStorescope
(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 oneproduceFile
— generates theFile
object for Preferences DataStore based on the providedContext
andname
, stored inthis.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