I keep dagger out of my library modules
# android
u
I keep dagger out of my library modules
👍 1
d
i regret not doing this. i did some research before i started and found people describing how to do it, and arguing in favor of it, but it gets really ugly. especially when you want to use
internal
classes. i would like an alternative that still lets me use dagger or something dagger-like, ’cause i’d prefer not to go back to manually constructing objects.
u
Yeah, well. It is a minor inconvenience to manually wire your library classes in your app module, but I can live with that. The library classes themselves look the same anyways (just without any @Inject annotations), ie standard constructor injection.
p
I really want dagger in my modules as well; some are just too complex to not use dagger. Especially if they need some dependencies from the outside.
I kind of need subcomponents which are generated in the modules where they are declared and which just take the dependencies from their parent component but handle the dependencies that are declared in their modules themselfes because these modules are internal.
u
no idea if that is a fit for your case, but it sounded quite similar
d
I use component-to-component dependencies where each of the gradle-modules has a top level @Component. I can then control what consumer gradle-modules can inject from the library module by exposing it in the Component. This controls the API surface. With this approach you "loose" the ability to use Dagger Scoping in child modules unless you use @Subcomponents (which aren't aware of any parent scopes).
a
I just use module per library module. the main app component wires together all of the modules and only modules depending on each other can access the others dependencies
d
Yep module-to-module (no components) is another way 👍
a
And if you’re worried about exposing something of one module to another, I can abstract with an interface that each module depends on and the providing module supplies the dependency to the consuming module
d
Ah interesting so a kind of ModuleComponent hybrid? (As in the
interface
, contract enforcing side of a @Component)
a
not sure? but it makes one module not directly depend on another. They indirectly depend on each other,. but that common module between the two might not change often, so they dont need to recompile.
d
I see. Would be interested to have a look at that arrangement if you have a repo. It's a shame that there isn't more formal (not just individuals!) advice here. I've just decided that my gradle module library deps can't scope with Dagger in my soln & then hand craft the Double Checks for important scopes like Singleton. Your approach I assume allows you to continue scoping through the tree at the expense of having to build "something around Dagger" for it to work without inadvertently exposing objects through the tree that aren't meant to leave the module?
1
a
dont have a public example of that, but heres a multimodule example with a dagger module in a few modules that get tied together by the app: https://github.com/art-institute-of-chicago/aic-mobile-android
d
That is a well layered app. Kudos. Looking at https://github.com/art-institute-of-chicago/aic-mobile-android/blob/dev/app/src/main/kotlin/edu/artic/AppComponent.kt it reminds me of how I used to use Dagger 1. 🤔 You've made me think @agrosner...
a
thanks! yeah
h
What if I need to Inject dependency from module B inside module A's platform class(Service, BroadcastReceiver, Worker)? How can you do it without components in library?
r
I did module to module dependencies. Or we can let module has no dagger at all, but let app module wire it by creating dependencies.
u
Yes, that. In my case the app module creates the entire dependency graph.
p
That doesn't work for me 😕
I have my
app
gradle module and it depends on a library gradle module
GradleB
. Now my module
GradleB
needs to create a component
DaggerComponentB
. However it has a dependency on a
DaggerModuleC
declared in
GradleModuleC
. Now I can't use a subcomponent for
DaggerComponentB
because the app has no dependency on
GradleModuleC
and it's
DaggerModuleC
.
🤔 2
Dagger Dependency Nightmare
s
https://github.com/cerberusv2px/android-modular Not sure if it helps.. but i did something like this.. not efficient though
r