in dagger, can a module say "single instance per whatever component this module gets attached to,"?

# android-architecture

[ursus]

in dagger, can a module say "single instance per whatever component this module gets attached to,"?

[gildor]

Maybe just use @Reusable?

[ursus]

Uhm never heard of it

[allan.conda]

you can keep it unscoped, if you meant you need a separate instance for every dependent class
scratch that, just saw your other message

[ursus]

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

[gildor]

but question is how to have 1 instance

[gildor]

Reusable is way to go, it will just keep 1 instance per every component

[allan.conda]

it’s not guaranteed however

[gildor]

yes, it’s not guaranteed

[ursus]

Reusable from what I read can be destroyed, so its just sort of a cache

[gildor]

but (sub)component also can be destroyed

[ursus]

I want something sort of like

class FooModule {
    val fooManager by lazy { .. }
}

you can now attach this anywhere, in a daggerless world

[gildor]

attach?

[ursus]

to any component graph

[gildor]

you want to cache on level of module?

[gildor]

just create instance of this module

[gildor]

and assign it manually

[gildor]

actually you can do the same with dagger

[gildor]

with no changes

[gildor]

just expose fooManager using @Provides or @Bind

[ursus]

well, yea, so Ill end up with 2 exact same module definitions per app, which is stupid

[ursus]

which leads me to the idea what dagger modules are app's responsibility

[ursus]

and I mean.. Retrofit doesnt include no dagger module..why is this different

[allan.conda]

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

[ursus]

where, across apps processes? haha of course not

[ursus]

but @Singleton on a module function, hardcodes this module to be only used on @Singleton component

[gildor]

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

[gildor]

Singleton is indeed strict, you will have only 1 instance. It really depends on you use case

[gildor]

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)

[allan.conda]

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).

[allan.conda]

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).

[ursus]

@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"

[ursus]

@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