Android In App Review

Whenever you have multiple objects you need to create and pass around the application, you generally speak about something called dependency injection and dependency graphs.

Dependency graphs help you connect all your objects together, and resolve any dependency between them, such as a ViewModel requiring SharedPreferences and a database to work.

One of the reasons you chose Hilt is that you can provide dependencies more easily across multiple modules within a project.

Hilt allows you to specify in which component you want to install each modules, and you use monolithic components that let you connect everything to your Application, Activity or Fragment scopes. That way you have the reusable and lifecycle-aware power of Dagger, while using smart and concise syntax of Hilt. Let’s connect all the dependencies for your In App Review feature!

To connect everything through Hilt, you only need to do two small things. You need to create two appropriate modules for your dependencies, one for each type of providing dependencies. Then you need to write bind or provider functions that let Hilt know how to build the objects.

Let’s start off with the providers module. Create a new package named di and add a new class to the package, named InAppReviewProviders:

@Module
@InstallIn(ApplicationComponent::class)
class InAppReviewProviders {

}

Notice how you added the @Module and the @InstallIn(ApplicationComponent::class) annotations. These two annotations let Hilt know that this class represents a module and that you want it to be bound to the ApplicationComponent. Now add the following functions, to provide some of the Android-based dependencies to your project:

@Provides
@Singleton
fun provideInAppReviewPreferences(@ApplicationContext context: Context): SharedPreferences {
  return context.getSharedPreferences(KEY_IN_APP_REVIEW_PREFERENCES, Context.MODE_PRIVATE)
}

@Provides
@Singleton
fun provideReviewManager(@ApplicationContext context: Context): ReviewManager {
  return ReviewManagerFactory.create(context)
}

Using @Provides and @Singleton, you tell Hilt you want to connect these dependencies to the graph and that you want them to be created only once. This saves valuable operations to create these objects multiple times, if you want to reuse them. You provided two notable dependencies here. The SharedPreferences you need to store data in and read data from and the ReviewManager, that you’ll use to start the In App Review flow.

Both of these dependencies require a Context to create them. You’ll get the Context from Hilt, using the @ApplicationContext annotation. Hilt then connects these dependencies to the App class and builds them using its Context.

This all might seem a bit complicated, so make sure to check out our: Dependency Injection With Hilt course, to learn more about Hilt!

Now let’s continue to the second module, that you’ll use to provide your own dependencies and not Android-based ones. Create a new class in the di package called InAppReviewBinds:

@Module
@InstallIn(ApplicationComponent::class)
abstract class InAppReviewBinds {

}

Notice how you’re using an abstract class here. This is because binds functions need to be within an abstract class. The rest is the same, in terms of Hilt setup. Now add the preferences binds function:

@Binds
@Singleton
abstract fun bindInAppReviewPreferences(
  inAppReviewPreferencesImpl: InAppReviewPreferencesImpl
): InAppReviewPreferences

Again, it’s using Singleton to reuse the dependency, but instead of Provides it uses the Binds annotation. Binds works a bit differently, because you need to use an abstract function. Then it applies certain optimizations, because it generates less code for the abstract function.

To write the function, you need to pass in the implementation you want as a parameter and you return the interface type, or the abstraction. That way Hilt connects the two and lets you use either of the two for dependency injection. Pretty cool! You should now be able to build & run the app without any errors!