Dagger2 activity scope, how many modules/components do i need?

Question

I have a couple of questions about custom scopes:

1. I'm using MVP architecutre and I need to inject different presenters to different activities. For that purpose I've created @ActivityScope. Does it mean that I must create a separate module/component for every activitiy?
2. What is the purpose of custom scope annotations if I'm still responsible for creating and releasing those dependencies? Not sure if I'm right but I can use @Scope123 in all my modules/components and it won't make any difference.

Answer 1

Does it mean that I must create a separate module/component for every activitiy?

Yes. And no.

At the very least you need to create a new component object for each activity if you want to provide activity scoped dependencies, like the Activity itself, the LoaderManager, or similar things, because the scope will just live as long as the activity.

The question of whether you need a module and component for each and every single one of your activities depends strongly on your architecture. Also you might be able to make a generic ActivityModule providing your model, presenter, and view which you could reuse.

You could also be fine with just one Component e.g. if only basic dependencies of the activity are needed like the LoaderManager or the Activity itself then you can write one ActivityModule to just provide those base objects. You can then just use this module with your component to supply the dependencies. If your Presenter (and its dependencies) can be created by constructor injection you could be fine with a single component and module for all of your activities.

If your presenter and view are interfaces that get implemented you would need to create a module that provides the actual implementation, though.

What is the purpose of custom scope annotations if I'm still responsible for creating and releasing those dependencies?

Scopes are used to make managing of those dependencies easier. As mentioned, the activity scope dies with the activity being destroyed. By having those scoped dependencies you can be sure that nothing depends on your activity that has a higher scope / lifetime and could cause memory leaks.

Also, I like to think of it as bundles of dependencies you can hot swap and just 'throw out'. A good example is a @UserScope that would hold the user data, his login, session data, ...
If I switch users I just need to throw everything out with a user scope or less (close activity, remove UserComponent) and everything concerning the user is gone. The next one can login, and there is low risk of side effects.

Scopes are mostly compile time checks that help you bring hierarchy into your dependencies, since all the compiler does is check that there are no cycles in it and that nothing requests dependencies from a scope it can't access.

Answer 2

1. The easiest way to do what you need is to create an application level component in wish you provide each type of presenter. The problem is that you will have all the classes of all you project at the same level which is kind of ugly. The nice way is to create a module for an activity that injects the dependencies for the current Activity/fragment

2. Using @ActivityScope or any other just show the module has a lifetime different from @Singleton, as long as it is not a singleton, consider you module will die the same your activity that created it will.