Issue with subcomponent repeated modules: "Is bound multiple times"

I’m developing an android app and I’m facing an issue when using subcomponents.

1. There’s a Fragment A, which has its own Component, which installs Module A and injects a class ClassFoo.
2. There’s nested fragment (Fragment B), which has a Subcomponent, which also installs Module A and injects the same class as Fragment A: ClassFoo.
3. The Fragment A instantiates Fragment B inside of it and one of its modules installs the Subcomponent of Fragment B.

When in the nested fragment (Fragment B) I want to inject the ClassFoo I’m having issues. The repeated modules seem to be instantiated as new ones and Dagger complains saying:

[Dagger/DuplicateBindings] com.mypackage.ClassFoo is bound multiple times

My Subcomponent builder method:

@Subcomponent.Builder
    interface Builder {
        fun build(): AppBannerDialogComponent
    }

The moduleA has a constructor with no args. Ps: I know if I remove ModuleA from my subcomponent modules list that it will work, but I’d like to be explicit so I can use in other contexts that may or may not have ModuleA installed. I also know that if I remove ClassFoo from FragmentA that it works.

[douglasiacovelli]

Oh wow! I’m sorry I didn’t mention that earlier. My thought was that it wouldn’t make such a difference.

So I believe the first suggestion you gave still applies. I’ll take that into consideration.

Thank you for helping me figuring that out, @Chang-Eric! I’m closing the issue for now 😃

[Chang-Eric]

I’m assuming ModuleA has a binding for ClassFoo? If so, the issue here is that bindings in subcomponents are inherited from the parent. Even though both bindings come from the same module, Dagger treats them differently because some things are based on the context of the component they binding is installed in like which scope annotations are allowed. You’ll want to just install modules at the widest scope they are needed.

From your PS, I think the way to think about it is figuring out if FragmentB’s API is that it comes with a definition for ClassFoo or if it requires a ClassFoo from its user. It kind of needs to be one or the other. If you want to set up a default that can be overridden, you would have to do that with some extra machinery with optionals.