Shulou(Shulou.com)06/03 Report--

This article mainly explains "what are the pitfalls and optimization methods you will encounter when using Dagger in Kotlin". The content in the article is simple and clear, and it is easy to learn and understand. please follow the editor's train of thought to study and learn "what are the pitfalls and optimization methods you will encounter when using Dagger in Kotlin".

Improve construction efficiency

To shorten build time, Dagger added support for gradle incremental annotation processing (gradle's incremental annotation processing) in v2.18. This feature is enabled by default in Dagger v2.24. If you are using an earlier version, you need to add the following lines of code to activate the feature.

In addition, you can configure Dagger so that it does not format the generated code. This option was added in Dagger v2.18 and is the default behavior in v2.23 (no more formatting code is generated). If you are using an earlier version, you can also add the following code to disable formatting code to reduce build time.

Add the following compilation parameters to build.gradle to improve the performance of Dagger at build time:

Allprojects {afterEvaluate {extensions.findByName ('kapt')? .customers {arg ("dagger.formatGeneratedSource", "disabled") arg ("dagger.gradle.incremental", "enabled")}

In addition, if you are using a Kotlin DSL script file, you need to include the following in the build.gradle.kts file:

Kapt {arguments {arg ("dagger.formatGeneratedSource", "disabled") arg ("dagger.gradle.incremental", "enabled")}}

Use Qualifier as a property of field

When you add a comment to a property in Kotlin, it is not clear whether the final Java will be able to get the comment in the field or method of that property. Adding the field: prefix before the comment ensures that qualifier works in the right place (see the official documentation for more details).

The correct way to apply qualifier to an injected field is as follows:

@ Inject @ field:MinimumBalance lateinit var minimumBalance: BigDecimal

The following is wrong:

@ Inject @ MinimumBalance lateinit var minimumBalance: BigDecimal / / @ MinimumBalance is ignored

Forget to add field: if there is an instance in Dagger that does not match this type, it may result in injection into the wrong object.

This issue has been fixed in Dagger v2.25, and if you are using this version, there will be a problem with the previous writing, but not now.

@ Inject @ MinimumBalance lateinit var minimumBalance: BigDecimal / / fixed: @ MinimumBalance is no longer ignored

Use static @ Provides methods to improve performance

If you use the static @ Provides method, the code generated by Dagger will have better performance. To achieve this, use object in Kotlin instead of class, and add the @ JvmStatic annotation before the method. This is the best practice you should follow as much as possible.

@ Module object NetworkModule {@ JvmStatic @ Provides fun provideOkHttpClient (): OkHttpClient {return OkHttpClient.Builder () .build ()}}

If you need to use abstract methods, you need to add @ JvmStatic to the companion object and add the @ Module annotation.

@ Module abstract class NetworkModule {@ Binds abstract fun provideService (retrofitService: RetrofitService): Service @ Module companion object {@ JvmStatic @ Provides fun provideOkHttpClient (): OkHttpClient {return return OkHttpClient.Builder () .build ()}

Alternatively, you can extract the object module code and include it in the abstract module:

@ Module (includes = [OkHttpClientModule::java]) abstract class NetworkModule {@ Binds abstract fun provideService (retrofitService: RetrofitService): Service} @ Module object OkHttpClientModule {@ JvmStatic @ Provides fun provideOkHttpClient (): OkHttpClient {return OkHttpClient.Builder () .build ()}}

In Dagger v2.25, you no longer need to use @ JvmStatic to mark the @ Provides function, Dagger will recognize it correctly.

Generic injection

Kotlin compiles generics using wildcards so that Kotlin API and Java can be used together. When a parameter or field is of generic type, it is automatically generated in the Java code. For example, the code List parameter for Kotlin is displayed as List in Java.

But this feature can cause problems in Dagger because it expects the type to match exactly (also known as invariant). Using @ JvmSuppressWildcards will ensure that Dagger sees types that do not have wildcards.

This is a common problem when you use the multiple binding feature of Dagger, such as:

Class MyVMFactory @ Inject constructor (privateval vmMap: Map) {.}

In Dagger v2.25, you will no longer need to use @ JvmSuppressWildcards, and Dagger will recognize it correctly.

Inline method body

Dagger determines the type configured by the @ Provides method by checking the return value type. The return type in the Kotlin function is optional, and even IDE sometimes recommends that your refactoring code use an inline method body to hide the declaration of the return type.

If the inferred type is not consistent with what you expect, it will cause the bug to appear. Let's look at some examples:

If you want to add specific types to Dagger, using inline would be the best choice. Let's take a look at another way to achieve the same effect in Kotlin:

Provides fun provideNetworkPrinter () = NetworkPrinter () @ Provides fun provideNetworkPrinter (): NetworkPrinter = NetworkPrinter () @ Provides fun provideNetworkPrinter (): NetworkPrinter {return NetworkPrinter ()}

If you need to provide an implementation of the interface, you must display the specified return type. If you don't do this, something will go wrong:

@ Provides / / configure Printer fun providePrinter (): Printer = NetworkPrinter () @ Provides / / configure NetworkPrinter, not an ordinary Printer fun providePrinter () = NetworkPrinter ()

Dagger is basically compatible with Kotlin, but you still need to be careful to make sure that the code doesn't go wrong: use @ field: to qualify field properties, inline method bodies, and use @ JvmSuppressWildcards annotations when injecting collections.

The optimizations brought about by this Dagger do not incur additional wear and tear, and following these best practices, such as enabling incremental annotation processing, disabling formatting settings, and using the static @ Provides method, can reduce the build time of a project.

Thank you for your reading, these are the contents of "what are the pitfalls and optimization methods encountered in using Dagger in Kotlin?" after the study of this article, I believe you will have a deeper understanding of the traps and optimization methods that will be encountered in the use of Dagger in Kotlin, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.