https://kotlinlang.org logo
u

ursus

07/16/2020, 4:17 AM
in dagger, can a module say "single instance per whatever component this module gets attached to,"?
g

gildor

07/16/2020, 4:24 AM
Maybe just use
@Reusable
?
u

ursus

07/16/2020, 4:30 AM
Uhm never heard of it
a

allan.conda

07/16/2020, 4:30 AM
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

ursus

07/16/2020, 4:33 AM
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

gildor

07/16/2020, 4:33 AM
but question is how to have 1 instance
Reusable is way to go, it will just keep 1 instance per every component
a

allan.conda

07/16/2020, 4:34 AM
it’s not guaranteed however
g

gildor

07/16/2020, 4:34 AM
yes, it’s not guaranteed
u

ursus

07/16/2020, 4:34 AM
Reusable from what I read can be destroyed, so its just sort of a cache
g

gildor

07/16/2020, 4:35 AM
but (sub)component also can be destroyed
u

ursus

07/16/2020, 4:35 AM
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

gildor

07/16/2020, 4:35 AM
attach?
u

ursus

07/16/2020, 4:35 AM
to any component graph
g

gildor

07/16/2020, 4:35 AM
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

ursus

07/16/2020, 4:39 AM
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

allan.conda

07/16/2020, 4:53 AM
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

ursus

07/16/2020, 4:56 AM
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

gildor

07/16/2020, 5:04 AM
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

allan.conda

07/16/2020, 5:07 AM
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

ursus

07/16/2020, 4:19 PM
@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
2 Views