Let’s look at the PresentationComponent more closely. One strange thing is that PresentationModule has ActivityComponent as its dependency, and it @Provide all the objects provided by ActivityComponent already. This is rather ugly, can we do something about it? The answer is Component Dependencies. The idea is that we can make PresentationComponent depends on ActivityComponent. That way, PresentationComponent automatically gets access to all the objects exposed by ActivityComponent. After this change, it looks like this:
Android + Dagger2
In previous post, we replaced our Pure Dependency Injection with Dagger2. But, the conversion is without too much thoughts. One improvement we can do is to follow Dagger’s convention of using Component as Injector. We can make the following mental models: Dagger’s @Module is for creating objects. Dagger’s @Component is for injecting objects into application classes.
Previous post we set up the so called Pure Dependency Injection. Now let’s replace that with Dagger2 balantly. Convert the composition roots into dagger’s @Modules. Create @Component to hold each @Module. Create @Scopes and use it to scope the objects we want only 1 instance in the component. Now it looks like this:
This series of posts are my summary notes from the online course Dependency Injection in Android with Dagger 2 and Hilt. I do believe if you have any doubts about Dagger2 in Android, run to get that course and watch it 3 times, I bet you will be better than 90% of the android developers on the market on this topic. The first 1⁄3 of the course introduces the so called Pure Dependency Injection, which means not using any library like Dagger.