Forging the Dagger for the modern Android world

Transcript

1. Forging the Dagger for the modern Android world Lorenzo Quiroli @lorenzoquiroli
2. Why Dagger?
3. Dependency Inversion of control class Presenter
4. Dependency Inversion of control class Presenter { val useCase = UseCase() }
5. Dependency Inversion of control class Presenter { val useCase = UseCase(Repository()) }
6. Dependency Inversion of control class Presenter { val useCase = UseCase( Repository( Retrofit.Builder() .baseUrl(BASE_URL) .addConverterFactory(GsonConverterFactory.create()) .build() .create(MyService::class.java) ) ) }
7. Dependency Inversion of control class Presenter(private val useCase: UseCase)
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
9. Small issues become bigger at scale
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?
11. Making it simpler class Presenter(private val useCase: UseCase) class PresenterModule { @Provides fun presenter(usecase: UseCase) : Presenter = Presenter(useCase) }
12. Making it simpler: now with less boilerplate! class Presenter @Inject constructor(private val useCase: UseCase)
13. Advices to avoid boilerplate Keeping the Dagger Sharp - Py https://bit.ly/2HTIyvE Dagger 2 on Android: the official guidelines you should be following - Fred Porciùncula https://bit.ly/2FPz40H
14. Build time and modules
15. How build time became a problem The wider adoption of Kotlin made annotation processing slower and generally worse
16. How we can improve it Kapt will get better (incremental support) The Dagger team is working hard to make it faster Modularise!
17. Why should I modularise?
18. Don’t do it for Dagger, do it for yourself
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.
20. First steps into modularisation
21. First steps into modularisation
22. Feature modules Dynamic Feature com.android.dynamic-feature Library com.android.library
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
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.
25. Modularising by libraries app home Implements
26. Modularising by libraries app home Implements You make a change to app
27. Modularising by libraries app home Implements You make a change to home
28. Modularising by libraries (in reality) app home Implements You make a change to home Implements core
29. Modularising by libraries (in reality) app home Implements You make a change to core Implements core
30. Modularising by libraries (in reality) app home Implements If app is empty, this is fine Implements core
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.
32. Modularising with dynamic features home app Implements
33. Modularising with dynamic features home app Implements You make a change to home
34. Modularising with dynamic features home app Implements You make a change to app
35. In the end... Both approaches lead to a very similar result: a solid improvement!
36. About Dagger Android...
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.
38. No
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.
40. Dagger in a dynamic feature @Component(dependencies = [ApplicationComponent::class]) interface HomeComponent { fun inject(activity: HomeActivity) }
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!)
42. Dagger in a library feature @Component(dependencies = [ApplicationComponent::class]) interface HomeComponent { fun inject(activity: HomeActivity) }
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
44. Tomorrow at 1.40 pm “Best practises for a modularised app” by Ben Weiss
45. An example of a modularised app https://github.com/nickbutcher/plaid/
46. We are hiring! lorenzo@busuu.com https://www.busuu.com/jobs/
47. Thanks!