I am using dagger 2.11 for an MVP app. Naturally, I want to write unit tests for my application, but I have run into some problems. I have an activity that has a presenter. When testing that activity I want to inject a mock presenter so I can verify that certain methods are called. The presenter is injected via Dagger 2.11 in the activity. My dagger setup is exactly the same as is described in these two articles:
https://medium.com/#iammert/new-android-injector-with-dagger-2-part-1-8baa60152abe
https://medium.com/#iammert/new-android-injector-with-dagger-2-part-2-4af05fd783d0
I use the annotations described in the latter, meaning I use the #ContributesAndroidInjector in a BuildActivity file instead of separate subcomponents.
My question is: How would I go about injecting the mock of the presenter?
Related
I have been using Dagger for a while and now I'm starting to migrate to Hilt, but I don't understand the benefits of injecting Activity and Fragment.
In Dagger, it is AndroidInjection.inject(this) and something like HasActivityInjector
Sorry if it was a stupid question.
It is not a benefit, it is a constraint imposed by Android. Activities and Fragments are instantiated by Android, not by the developer or the DI framework, and as such, they require special treatment. It is the same in Dagger actually.
In Hilt you don't need to write that code manually anymore, you can just annotate the Application, Activity and Fragment using special notations, the library will take care of generating the corresponding code.
I saw this question, but it was from the point of testability.
In my case, I see Dagger as an additional complexity for code (create #Provides methods, inject methods, remember all the right annotations). Should I still use Dagger if I just want to inject singletons like SharedPrefUtils? Is it really faster for this case?
Dagger was not made for creating Singletons and if creating a singleton is the reason you want to add Dagger to your project, then its an overkill. Dagger is a dependency injection framework that helps make the process of providing and injecting dependencies easier in a complex project. The #Singleton would help you ensure that only a single instance of a class is created when satisfying your dependencies it is not an alternative to the Kotlin object, they could even be used together. So like other answers and comments suggest if you have a small project and you could use simple design patterns like Singleton, Factory, and Abstract factory pattern.
Dagger is a dependency injection framework. For very simple applications, you can go with manual injection which will save you time because dagger can be difficult to set up and work with from the beginning. However, if you are planning on a production application which has a very long life span and will contain multiple UIs and multiple classes, then you are definitely going to need a dependency injection framework or strategy along the line.
There is an alternative for Kotlin which is Koin. Koin works more like a Service Locator and is easier to set up than Dagger but I will prefer dagger because it has survived the test of time.
It is up to you whether you want to use automatic dependency injection or manual injection so in the end you weigh your options and see what best fits your use case.
I have a little problem with designing DI architecture of my app. I am using Architecture Components ViewModels and I was inspired how to provide ViewModels via Dagger in their own GitHub repository .. I want to create scoped component/module for example for product detail that would provide ViewModels/Repositories and other stuff dependent on that single product.. problem is that all ViewModels are provided from the same ViewModelModule as in given example. But ProductViewModel needs ProductRepository that is provided from scoped subcomponent ProductModule. And apparently thats not possible because Dagger throws error at build time that I need to provide ProductRepository with #Provides annotation.
Ok so I thought that I would provide ProductViewModel in my ProductModule but then it crashes at runtime, because provider of my ViewModel can't be found in this method
Is it possible at all to have this architecture or do I need to redesign it to not use the same method as Google in their sample?
I was able to solve a similar problem by removing the #Singleton annotation on the ViewModelProvider.Factory subclass.
It shouldn't matter whether the factory is a singleton or not; it's only a performance issue, really. I ended up using #Reusable instead, which tells Dagger that the factory instance can be safely reused if needed, but without the restrictions of a specific scope.
After a recent migration to Dagger 2, the app I am working on is using an #ActivityScope for every feature. Each app feature is implemented using MVP pattern and has it's own local dagger Component setup which depends on the Application component for the dependencies that are required during the entire app lifecycle (provided by the App). Each feature’s Activity extends a base class which provides the main application component to a method that is overridden by each activity in order to set up the local dagger component (builds the local component and instantiates the local module).
The issue I am trying to solve is how to inject mocks into the Activity under test. The main problem I am experiencing is that I cannot swap the original local component and corresponding module with mocked ones at runtime. There are many articles on Espresso testing with Dagger 2 that I read, but they are not promoting clean architecture. For the most part they rely on the AppComponent to inject all Activities, where in my case, each feature’s component is responsible for injecting it’s own activity.
So far the best approach that I came up with was to introduce a component builder that is only initialised as part of the test setup and in the Activity code to go with this setup if initialised, otherwise set up the real component. However, I am reluctant to mix production and test code.
Here is a schematic which represents the Dagger setup:
Dagger 2 Setup
The approach that I took at the end was to create a custom AndroidJUnitRunner as described here and to create Components/Modules which provide mocks for each app feature, including the Application module check Google doc for best practices. Furthermore, each activity under test has to be overridden to inject the mocks (just the method that injects the mocked dependencies).
In order to keep the main app manifest clean, the overridden test activities are declared in a debug manifest.
Hope this approach helps people with a similar to my Dagger 2 setup to do their testing with Espresso and Dagger 2.
Have a rock ’n’ roll day!
When using Dagger, I found that I'm getting multiple instances of a singleton when I inject it wherever I need it. I've annotated the class and the provides method with #Singleton. Can anyone think of why this is happening?
Edit:
If it helps, I have followed the same structure for my app as the sample application in Dagger's GitHub (https://github.com/square/dagger/tree/master/examples/android-activity-graphs). I'm trying to get the Singleton in the base activity and a couple of third party classes provided using #Provides at the custom Application class. Is it because I'm plus-ing modules at each activity to the original object graph?
(PS : I'm new to Dagger and DI in general, so I'll be grateful if you could provide an explanation so that I may learn. Thanks.)
#Singleton, in Dagger 1.x, acts differently than you might think. The JSR-330 spec definition in the #Singleton javadoc is "one per graph" and that is how Dagger interprets it.
So if you have something that is marked as #Singleton, and it is materialized in your application graph (as opposed to a shorter-lifetime graph), then you get one instance per application.
If you have an item annotated #Singleton that's in the modules you use to configure your activity graph (i.e., that is obtained from the part of a graph specified by a module used in the plus() operation) then you will get one-per-activity-graph.
If you need something to be once-per-application, you need to make sure it gets created as a part of the application graph. You can do this in one of two ways. Either explicitly provide it with an #Provides method from your application module(s), or you can list it as a one of the classes in #Module(injects=...) in an application module.
(If you do not mark it with #Singleton than you will get one per injection site.)
So remember, the graph created by plus() is seen as a separate graph that points to the graph from which it was spawned, and wraps it, can access instances within it, but is not the same graph.
Note - Dagger 2.x improves this, and supports custom scoping annotations, though the mechanism is similar, with one graph (component) per scope annotation, with a parent/child relationship between graphs of wider/narrower lifetimes