@Singleton vs @InstallIn(SingletonComponent::class)

Question

What's the difference between these two? I think they both annotate a singleton object/instance, but somehow @Singleton can be used to annotate methods, instead of classes. I'm really confused about both of them.

Nationwide

Answer 1

@InstallIn(X) indicates in which (X here) DI container (generated by HILT automatically) the module bindings should be available. It's related to the lifetime of the dependencies.

For example:

@InstallIn(SingletonComponent::class)
object ApiModule {
    @Provides
    fun provideRetrofit(){
        ...
    }
}

The above example means the ApiModule is bound to the application class, so this will exist as long as the application exists, but every time the Hilt tries to provide the Retrofit instance it will create a new object. However, if we add @Singleton then it will return the same Retrofit instance every time:

@InstallIn(SingletonComponent::class)
object ApiModule {
    @Provides
    @Singleton
    fun provideRetrofit(){
        ...
    }
}

Valma

Answer 2

@SingletonComponent specifies that it can be used in the entire application.

@Singleton is a software design pattern causes the object to be initialized once.

Radiotransparent

Answer 3

Instances of components provided in the modules specified as @InstallIn(SingletonComponent::class) live throughout the application lifecycle.So, it refers component's lifetime.

While using injections(such as field or constructor), Hilt provides the instance of the components. If we want these components also created only once, we should add the @Singleton scope annotation. If we do not add this, a new instances are constantly created.

However scoping a binding to a component can be costly because the provided object stays in memory until that component is destroyed. That's why by default, all bindings in Hilt are unscoped, you need to use them according to your needs. You can read the details in Android official website.

Ichinomiya

I have some binds or provides relations for ActivityComponent and some for SingletonComponent in one Hilt Module class .... how could i achieve that? – Ptyalin

Answer 4

ApplicationComponent being renamed to SingletonComponent, to allow usage of Hilt in non-Android Gradle modules link

but @Singleton is a software design pattern link

Ruminate

Cool, I was thinking about ApplicationComponent too, but I thought it wasn't relevant so I didn't ask about it. – Overfill

Then are @Singleton and @InstallIn(SingletonComponent::class) effectively the same? Because there can be only 1 SingletonComponent/ApplicationComponent (I think so). – Overfill

@MinhNghĩa actually no. they are not same. – Ruminate

I mean they're effectively the same, as there's only 1 instance of the class annotated with either annotation. Or I'm I missing something? For example, if the constraint of a single instance @Singleton only applies to 1 "container", then there can be n instances across n different containers, and in that case, I'm definitely wrong. – Overfill

@MinhNghĩa the @Singleton used in dagger is singleton double check pattern and in the app you just have a instance, but multithreading can cause the have n instance without @Singleton – Ruminate

I also want to know the answer to this question. When our app module is already singleton then why annotate its methods with a singleton? – Bituminous

The answer doesn't really explain what's the difference? – Marconigraph