Ever wonder how to organize dependency injection in a multi-module app? In this presentation, we'll look at the production solution that is used in the 150+ module app

1. DI in multi-module
application
Oleg Mazhukin
Senior Android Developer

2. DI has many faces
● IoC – Inversion of Control
● DI(P) – Dependency Inversion Principle
● DI – Dependency Injection

3. Inversion of Control
Design principle inverts the flow of control as compared to traditional
control flow. E.g.
To create user screen we extend Activity class with generic
functionality can be selectively changed by additional user-written
code i.e. Android framework provides custom-written portions of a
computer program receive the flow of control from a generic
framework

4. Dependency Inversion Principle
● High-level modules should not depend on low-level modules. Both
should depend on abstractions (e.g. interfaces). e.g. Clean
Architecture
● Abstractions should not depend on details. Details (concrete
implementations) should depend on abstractions.

5. Dependency Injection
Design pattern used to implement IoC. It allows the creation of dependent objects
outside of a class and provides those objects to a class through different ways.

6. Design pattern vs design principle
● Design principles provide high level guidelines to design better software
applications. They do not provide implementation guidelines and are not
bound to any programming language.
Examples: SOLID, GRASP
● Design Pattern suggests a specific implementation for the specific object-
oriented programming problem i.e provides reliable solution in the specific
context.
Examples: Observer, Factory, Adapter, etc.

7. Multi-module application
app module
● combines all feature modules
● provides common dependencies
○ OkHttpClient, RoomDao, Preferences, etc.
feature modules
● contains feature specific module
● can have one of more scopes
core modules
● utils/common module solutions

8. Do you need multi-module app?
● Modules can be reused in different apps
● Instant apps, app bundles
● Faster build time ( in theory )
● Separate modules are more convenient for big developers teams

9. Creating our own DI Framework
- injection implementation
- same types/different target solution
- lifecycle/visibility markes
- providers

10. Meet JSR-330: javax.inject.*
● @Inject - target for dependency
● @Qualifier (i.e @Named ) - same types/different target solution
● @Scope (i.e @Singleton ) - lifecycle/visibility markes
JSR-330 Implementations
● dagger2
● spring
● toothpick

11. Component dependency vs submodules
● Submodules have access to all objects from all modules it possesses without
an explicit declaration of those dependencies in the parent Component
SubComponent plus(SubcomponentModule module)
● Component dependency requires explicit dependency declaration
@Component(
dependencies = [ComponentDependencies::class],..
) interface Component {

12. Example app
Features
● login
● content

13. Dagger graph
● Features ask for dependencies
● Feature can use common Injector or create its own
● App module provides dependencies
● Component destroyed based on lifecycle

14. App Module

15. Feature App Dependencies

16. Feature App Modules

17. Core Module

18. Core Module

19. Main App class

20. Main App class

21. Feature component usage

22. Resolving common module dependencies
● moving dependency to app module
● moving dependency to core module
● using interfaces

23. Tips
● use feature prefixes
● don’t use direct feature dependencies
● split feature on data/feature modules
● use android free modules if possible
● use feature scopes only on objects with state
● use composite builds

24. Resources
Google recommends https://developer.android.com/training/dependency-injection/dagger-multi-module
Best Dagger Article https://habr.com/ru/post/279125/
Composite builds https://docs.gradle.org/current/userguide/composite_builds.html