Developing Apps with Jetpack Compose for Android【02】 - DI Injection

Introduction

* This is the second part of this series

Continuing from the previous part

Mainly focusing on the basic construction of the initial project

For future development

I will consider starting to integrate DI injection

This time I am using Hilt

Project Setup

* The libraries used are as follows:

{% include table/compose-use.html %} {% include table/compose-category.html %}

Integrating DI Injection - Hilt

step1. Integrate Hilt & KSP

* To use Hilt, the following toml configuration is required

Mainly the Hilt library and KSP for Hilt integration

Add the plugin in build.gradle.kts(:app)

Import in build.gradle.kts(:yourAppName):

Import in build.gradle.kts(:app):

step2. Implement Hilt Application

* The official documentation mentions

Adding Hilt must include @HiltAndroidApp

So implement an Application

Testing shows that if not added, the following error will occur:

Caused by: java.lang.IllegalStateException: Hilt Activity must be attached to an @HiltAndroidApp Application. Did you forget to specify your Application's class name in your manifest's application 's android:name attribute?

step3. Start Injecting Classes

* Once the above configuration is done

Hilt will provide injection functionality in classes annotated with @AndroidEntryPoint

Let's try creating a ViewModel using Hilt

Actual usage:

Adding Modules

* DI can add modules to provide the required classes

and generate instances for you through DI

like the example below

mainly used for network request-related modules

provideKotlinxJsonConverter is used to provide a converter for parsing JSON format

provideCustomConverter is used to provide the response format definition for HTTP requests

provideBaseRetrofitBuilder is used to provide an instance of Retrofit

In the source code above, you will see a line @Named("xxx")

This is used to indicate the name of this instance

Suppose your project happens to have multiple different configurations to generate

You can add @Named("yourName") at the top of the function

This allows Hilt to determine which instance to inject during compilation

Whether it's an internal company backend API or an external third-party service API

You might encounter APIs with different response situations

So you can use this form to generate instances for you

You can also build without adding @Named

But Hilt will just find the only one available to inject for you

Actual usage:

After using DI injection, you don't need to actively initialize and obtain the class instance yourself

DI handles it for you, and if used well

It will also make the code look cleaner and more readable

Like in the example above, I defined kotlinx.serializer to parse fixed JSON to class

old-custom environment contains content left by the old server

So I use the old defined format to parse it

un-auth defines an OkHttpClient that only adds HttpLoggingInterceptor in the Debug environment to parse logs

Finally, the API Service provided by provideFeedbackUcService has the features I mentioned above

Through this example, you can understand

No matter how the server changes

We can easily

assemble the desired final shape using the above method

After writing it

You can also avoid writing a lot of repetitive code

For example: network requests

If the specifications provided by the server are the same

Then you only need to focus on developing the API service

Finally, when you need to use these instances, just inject them directly in the constructor

Back to Contents