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

• 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
  

• The libraries used are as follows:

• 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):

• 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?

• 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:

• 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