https://kotlinlang.org logo
Join Slack
Powered by
in dagger, can a module say "single instance per w...
# android-architecture
u
in dagger, can a module say "single instance per whatever component this module gets attached to,"?
g
Maybe just use 
@Reusable
?
u
Uhm never heard of it
a
you can keep it unscoped, if you meant you need a separate instance for every dependent class scratch that, just saw your other message
u
Well easiest would be to imagine say FooManager, and in AppA it needs to be app scoped, and in AppB it needs to be user scoped
g
but question is how to have 1 instance
Reusable is way to go, it will just keep 1 instance per every component
a
it’s not guaranteed however
g
yes, it’s not guaranteed
u
Reusable from what I read can be destroyed, so its just sort of a cache
g
but (sub)component also can be destroyed
u
I want something sort of like
Copy code
class FooModule {
    val fooManager by lazy { .. }
}
you can now attach this anywhere, in a daggerless world
g
attach?
u
to any component graph
g
you want to cache on level of module?
just create instance of this module
and assign it manually
actually you can do the same with dagger
with no changes
just expose fooManager using @Provides or @Bind
u
well, yea, so Ill end up with 2 exact same module definitions per app, which is stupid
which leads me to the idea what dagger modules are app's responsibility
and I mean.. Retrofit doesnt include no dagger module..why is this different
a
if you could share scopes across app it would be possible. I doubt you need a totally different scope in each app. Anyway if you are working with multiple apps the instances won’t be shared anyway, you could just use 
@Singleton
u
where, across apps processes? haha of course not
but @Singleton on a module function, hardcodes this module to be only used on @Singleton component
g
well, yea, so Ill end up with 2 exact same module definitions per app, which is stupid (edited)
no, the same module in 2 components
Singleton is indeed strict, you will have only 1 instance. It really depends on you use case
For example there is no reason why for example mentioned instance of Retrofit must be 
@Singleton
instead of being 
@Reusable
(it rather important for OkHttp client)
a
There’s this bit in Android Hilt, I would assume some of these are true for classic Dagger
There are three rules to follow when installing a module in multiple components:
• Providers can only be scoped if all of the components support the same scope annotation. For example, a binding provided in 
ViewComponent
 and 
ViewWithFragmentComponent
 can be 
@ViewScoped
 because they both support that scope annotation. A binding provided in 
Fragment
 and 
Service
 can not be scoped with any of the standard scopes. • Providers can only inject bindings if all of the components have access to those bindings. For example, a binding in 
ViewComponent
 and 
ViewWithFragmentComponent
 can inject a 
View
, whereas something bound in 
FragmentComponent
 and 
ServiceComponent
 could not inject either 
Fragment
 or 
Service
. • A child and ancestor component should not install the same module. (Just install the module in the ancestor, and the child will have access to those bindings).
I would assume installing modules in different scopes would have ambiguity in dependency resolution. Imagine a parent scope and a subscope both install the same module, there would be a conflict with the scope of the dependency (It can’t be both Singleton or FragmentScoped).
u
@gildor "no, the same module in 2 components" how so? if the provider method already has @AppScope on it, you cannot attach such module to @UserScope component, canyou? retrofit ok sure, but its incorrect to use @Reusable for some state holder, @Reusable is just a "please cache this for perf reasons, but if not, I dont mind"
@allan.conda not sure what you wanted to say with that, I'm complaining about needing to explicity say which scope is the given provider method scoped to, which limits reusability saf we can see here
18 Views
Open in Slack
PreviousNext
Powered by