A couple months ago, during MCE³conference, Gregory Kick in his presentationshowed a new concept of providing Subcomponents (e.g. to Activities). New approach should give us a way to create ActivitySubcomponent without having AppComponent object reference (which used to be a factory for Activities Subcomponents). To make it real we had to wait for a new release of Dagger: version 2.7.
Before Dagger 2.7, to create Subcomponent (e.g. MainActivityComponentwhich is Subcomponent of AppComponent) we had to declare its factory in parent Component:
Thanks to this declaration we Dagger knows that MainActivityComponenthas access to dependencies from AppComponent.
Having this, injection in MainActivitylooks similar to:
The problems with this code are:
Activity depends on AppComponent(returned by ((MyApplication) getApplication()).getComponent())— whenever we want to create Subcomponent, we need to have access to parent Component object.
AppComponenthas to have declared factories for all Subcomponents (or their builders), e.g.: MainActivityComponent plus(MainActivityComponent.ModuleImpl module);.
Starting from Dagger 2.7 we have new way to declare parents of Subcomponents. @Moduleannotation has optionalsubcomponents field which gets list of Subcomponents classes, which should be children of the Component in which this module is installed.
ActivityBindingModuleis installed in AppComponent. It means that both: MainActivityComponentand SecondActivityComponentare Subcomponents of AppComponent.
Subcomponents declared in this way don’t have to be declared explicitly in AppComponent(like was done in first code listing in this post).
Let’s see how we could use Modules.subcomponentsto build Activities Multibinding and get rid of AppComponent object passed to Activity (it’s also explained at the end of this presentation). I’ll go only through the most important pieces in code. Whole implementation is available on Github: Dagger2Recipes-ActivitiesMultibinding.
Our app contains two simple screens: MainActivityand SecondActivity. We want to be able to provide Subcomponents to both of them without passing AppComponentobject.
Let’s start from building a base interface for all Activity Components builders:
Example Subcomponent: MainActivityComponentcould look like this:
Now we would like to have Mapof Subcomponents builders to be able to get intended builder for each Activity class. Let’s use Multibindingfeature for this:
ActivityBindingModuleis installed in AppComponent. Like it was explained, thanks to this MainActivityComponentand SecondActivityComponentwill be Subcomponent of AppComponent.
Now we can inject Map of Subcomponentsbuilder (e.g. to MyApplicationclass):
To have additional abstraction we created HasActivitySubcomponentBuildersinterface (because Mapof builders doesn’t have to be injected into Applicationclass):
And the final implementation of injection in Activity class:
It’s pretty similar to our very first implementation, but as mentioned, the most important thing is that we don’t pass ActivityComponentobject to our Activities anymore.
##Example of use case — instrumentation tests mocking
Besides loose coupling and fixed circular dependency (Activity <-> Application) which not always is a big issue, especially in smaller projects/teams, let’s consider the real use case where our implementation could be helpful — mocking dependencies in instrumentation testing.
Currently one of the most known way of mocking dependencies in Android Instrumentation Tests is by using DaggerMock(Github project link). While DaggerMock is powerful tool, it’s pretty hard to understand how it works under the hood. Among the others there is some reflection code which isn’t easy to trace.
Building Subcomponent directly in Activity, without accessing AppComponent class gives us a way to test every single Activity decoupled from the rest of our app.
Sounds cool, now take a look at code.
Application class used in our instrumentation tests:
Method putActivityComponentBuilder()gives us a way to replace implementation of ActivityComponentBuilder for given Activity class.
Now take a look at our example Espresso Instrumentation Test:
Step by step:
We provide Mock of MainActivityComponent.Builderand all dependencies which have to be mocked (just Utilsin this case). Our mocked Builderreturns custom implementation of MainActivityComponentwhich injects MainActivityPresenter(with mocked Utilsobject in it).
Then our MainActivityComponent.Builderreplaces the original Builder injected in MyApplication(line 28): app.putActivityComponentBuilder(builder, MainActivity.class);
Finally test — we mock Utils.getHardcodedText()method. Injection process happens when Activity is created (line 36): activityRule.launchActivity(new Intent());and at the and we’re just checking the results with Espresso.
And that’s all. As you can see almost everything happens in MainActivityUITest class and the code is pretty simple and understandable.
If you would like to test the implementation on your own, source code with working example showing how to create Activities Multibindingand mock dependencies in Instrumentation Tests is available on Github: Dagger2Recipes-ActivitiesMultibinding.
Thanks for reading!