First of all, thanks for reading the post ;). Then let’s go talking about the scope composition.
As you said, we are used to compose the activity graph based on the application one when we are working with
Dagger. By doing that, we allow the graph to resolve bigger scoped dependencies that can live under the application scope.
Reader approach, we could just apply the same strategy. You could create an ApplicationContext with all the app scope dependencies resolved, and just compose all the contexts created in activities using that one. That would be more than enough to get the same behavior. So classes needing to use the application scoped dependencies would just do
ctx -> ctx.app.whatever().
We cannot use simple inheritance here since we don’t just need the appContext methods inside our activity context scope, we also need to keep it’s state. That means we the instances for all the dependencies provided by the app scope, are not created every time you create a new activity context, but just right when
Application class gets created (so we emulate singleton scope by doing that). So I would most probably just build the app ctx inside the
Application class, and then add a getter to request the app context from the activities when I am creating activity contexts, like:
As you can see, the strategy you use to compose graphs is detached from the framework you are using for DI. Both are different subjects since that’s more like a design decision.