Is there a better way to create singletons than cr...

# kotlin-inject

[Daniel Weidensdörfer]

Is there a better way to create singletons than creating a new scope notation for each component?

[eygraber]

It's varies by project, but in my experience there shouldn't be as many Components as the documentation makes it seem.

@evant maybe that's something that can be improved on? Early on I found myself using @Component a lot because the docs showed things like RealNetworkComponent.

However, structuring your component hierarchy like that means that other parent components of AppComponent wouldn't be able to inject anything from RealNetworkComponent.

My solution to that (and answer to @Daniel Weidensdörfer) has been to use a hierarchy of AppComponent, ActivityComponent and ScreenComponent, with a corresponding scope for each one (obviously an Android solution, but the concept extends to any other system).

Instead of having a NetworkComponent I declare a NetworkModule interface and have the appropriate component implement it (or more recently just use kotlin-inject-anvil and ContributesTo).

[Daniel Weidensdörfer]

That was my first approach as well, how would you handle it in a multi module project? Say there are domain, data, feature1, feature2, app modules. With obvious dependencies data <- `domain`<- features <- app .

Currently I have a component for each of the gradle modules. Since there is no "Master" component that contains everything, each feature gets its references from its own component FeatureXComponent which in turn reference the DomainComponent (if needed).

The DomainComponent cannot be a "Module" interface as two different trees would be generated for each child feature.

So with this architecture, I'm creating a new scope XXXSingleton for each component. While I'm asking myself why there is no global Singleton annotation provided by the framework.

[Marcelo Gobetti]

@eygraber thank you so much, I've been searching all over GitHub to understand how other projects are using kotlin-inject, and I was seeing so many interfaces, when the README hinted me on the @Component abstract class path.

there are a few drawbacks with using interfaces, especially when `internal`s are involved (to Daniel's point on modularization), but after some time trying your idea out:

a hierarchy of AppComponent, ActivityComponent and ScreenComponent

I finally got to a place that feels familiar with other projects, and while boilerplate exists in different forms, it's smaller and easier to handle than the other options, it seems.

------

@Daniel Weidensdörfer thank you for the original post, I had the same question and struggle, and was going the same route of components being 1:1 with gradle modules. I think what Eliezer is suggesting is we wouldn't have `@Component`s per module, but interfaces, and then only a few "master" components that implement them: those 3 he pointed out

(where I understand ScreenComponent
means N of those for N screens, i.e. HomeScreenComponent, SettingsScreenComponent etc.)

by having fewer components, you automatically have fewer scopes, as all the interfaces implemented by 1 component can use that 1 scope

@ApplicationScope
@Component
abstract class ApplicationComponent(
  @get:Provides val context: Context
) : DataComponent, NetworkComponent

...

@ActivityScope
@Component
abstract class ActivityComponent(
  @Component val applicationComponent: ApplicationComponent
) : InAppReviewComponent, SplashScreenComponent

...

@HomeScreenScope
@Component
abstract class HomeScreenComponent(
  @Component val activityComponent: ActivityComponent
) : HomeStuffComponent

this is one of the repos that helped shape my ideas. While learning, I like to start simple, so it's been helpful to me that it doesn't use Anvil, which would be another thing for me to learn from zero

[Daniel Weidensdörfer]

I see, however, if I'm not mistaken there are still some issues here. For example there is a DomainModule as interface and ScreenAComponent and ScreenBComponent that use that interface.

If you want to mark a use case binding in DomainModule as singleton, would you mark it with ScreenAScope and ScreenBScope? The thing is that if the module as interface is used by 2 components, it will be 2 different dependency trees and the usecase which is supposed to be a singleton in the whole application is effectevly created once for each component.

I'm currently doing very well with having a component for each module with its own scope. Also because I created some scoping in form of having one component for a user for example (To clean up coroutines when user logs out).

[eygraber]

I would make it a singleton in ScreenScope which is the parent of each screen's scope, and maintains separate singletons for each screen. It exists for exactly that purpose; to provide a screen level scope outside of the screen module.

[Daniel Weidensdörfer]

Alright, how do manage global singletons then?

[eygraber]

AppScope

[Marcelo Gobetti]

@eygraber just making sure I understand, it makes sense to me at least: different screens share the same scope name, because there's no parent-child relationship between them, they're siblings, so sharing a scope name is unambiguous, per dagger docs

so in Daniel's example, his DomainModule can use ScreenScope, and the two different screen components that implement that interface use that scope too. Right?

[eygraber]

Yes, that's correct