Forging the Dagger for the modern Android world

8811358daa790e2a882bf6bc668c8f04?s=47 Lorenzo Quiroli
April 04, 2019

Forging the Dagger for the modern Android world


Lorenzo Quiroli

April 04, 2019


  1. 6.

    Dependency Inversion of control class Presenter { val useCase =

    UseCase( Repository( Retrofit.Builder() .baseUrl(BASE_URL) .addConverterFactory(GsonConverterFactory.create()) .build() .create( ) ) }
  2. 8.

    Dagger is not the only solution Smaller apps don’t really

    need dependency injection You can build your own solution if your app is rather small Service Locator Frameworks
  3. 10.

    Dagger: yes or no? Yes Compile time safety It scales

    with your app Advanced features (Scope, Multibindings, …) No Steep learning curve Build time impact Too much boilerplate?
  4. 11.

    Making it simpler class Presenter(private val useCase: UseCase) class PresenterModule

    { @Provides fun presenter(usecase: UseCase) : Presenter = Presenter(useCase) }
  5. 12.
  6. 13.

    Advices to avoid boilerplate Keeping the Dagger Sharp - Py Dagger 2 on Android: the official guidelines you should be following - Fred Porciùncula
  7. 15.

    How build time became a problem The wider adoption of

    Kotlin made annotation processing slower and generally worse
  8. 16.

    How we can improve it Kapt will get better (incremental

    support) The Dagger team is working hard to make it faster Modularise!
  9. 19.

    Why should I modularise? Faster build time (with or without

    Dagger). Better separation and encapsulation of your code. Access to Dynamic Delivery. The time you take to modularise today is time you are saving tomorrow.
  10. 23.

    What do you want your module to be? Dynamic Feature

    Depends on app Creates a separate apk Allows you to use Dynamic Delivery Easier to do at the beginning Build time impact affects especially the new modules Library App depends on it Only one apk No Dynamic Delivery Complicated refactor Build time impact affects especially the old modules
  11. 24.

    Modularising by libraries The app module should be basically empty,

    containing only the manifest. You will also need a core module containing the component for the dependencies used in different features. Easy to do when you start a new app, difficult and time consuming when you have an ongoing project.
  12. 30.
  13. 31.

    Modularising with dynamic features The app module can be the

    same and act as a base module. The refactor is easier because the new module will implement the app module, so it will have access to all the classes inside it. You can keep them as included in the App Bundle and decided in the future to use dynamic delivery. Navigation between modules is more tricky.
  14. 35.
  15. 37.

    You can use Dagger Android but... Be careful about build

    time! Each module could expose a module containing the @ContributesAndroidInjection bindings. This would lead to a giant component in the app modules that would be regenerated after every change.
  16. 38.


  17. 39.

    Dagger in a dynamic feature You cannot use Dagger-Android. You

    cannot use @Subcomponent (at least not directly with ApplicationComponent, as the ApplicationComponent will be upstream) The generated code cannot be referenced in the base module.
  18. 41.

    Dagger in a library feature You can technically use Dagger-Android,

    but it might be better to avoid it. Avoid also @Subcomponent to improve build time performances. The generated code can be referenced in the app module, but there’s no reason to (and the app module should be empty!)
  19. 43.

    Dagger in dynamic features vs libraries Dynamic Feature Cannot use

    @Subcomponent and Dagger Android Generated code cannot be referenced in the base module The base module should contain as little as possible code Library Can use @Subcomponent (but better not to) and Dagger Android Generated code can be referenced in the base module (but shouldn’t) The app module should be empty
  20. 47.