Hey everyone, as showcased in Google samples makin...

# android-architecture

[bhatnagarm]

Hey everyone, as showcased in Google samples making Repository class as Singleton seems to be bit confusing. So as per my understanding a Singleton class doesn't get Garbage collected as it's instance being stored into static variable. Doesn't this seems kind of anti-pattern. Until it's some common repository what's the use case for it to outlive it's scope which may be just within a smaller scope. So what do you guys think?? How many of you consider making Repository class as Singleton. If yes, then I'm really Keen to understand.

[streetsofboston]

A Repository implementation that never changes during the lifetime of the app can be singleton, no problem.

[streetsofboston]

But if you use Dependency Injection, such as Dagger, and your Repo has dependencies, you may not want to make your Repo be an object , but a plain class instead that is only instantiated once (a Dagger @Singleton)

[bhatnagarm]

Well isn't dagger Singleton follows the same principle. It's just dagger instantiating it for you once.

[streetsofboston]

Same principle, indeed, but different flavor 🙂. Dagger can only instantiate `class`es, not `object`s.

[bhatnagarm]

Correct I got your point but what I mean is any class being Singleton will not be Garbage collected. Now Singleton class can either be created by developer explicitly or by dagger marking it as Singleton

[tschuchort]

Singleton is practically always an anti-patterm, at least if it has state or isn't used as an interface implementation. Use a dependency injection framework for object lifetime management instead.

[bhatnagarm]

The fact that Singleton doesn't gets gc still holds true

[bhatnagarm]

Is what I'm confused with.

[bhatnagarm]

So for your reference if you checkout Sunflower all by google, you'll see garden repository being Singleton

[bhatnagarm]

@tschuchort could you please elaborate, sorry I didn't get you

[aipok]

I think, it more depends on how you will use the instance and what will be its lifecycle.
I’m using single instance with Koin for components that are required to be accesible in whole app.
If lifecycle is different it is better to wrap it to some scope.
Previously instances, that were needed across the app, were holded by Application class.
Nowdays DI could handle single instance of the class and inject it to the right place. Basic different between object and single in DI is that single is not holded as static instance. The DI usually has static access, but all the instances that defined by DI are holded inside the DI as regular fields.
In Android world I don’t have anything against object if you don’t plan to test the instance or reload it. object will leave same time as you application class, so whats the difference 😄

[tschuchort]

@bhatnagarm A singleton with state is equivalent to global variables. There are situations where it makes sense to use global variables but usually it's not a good idea. A singleton without state is basically a record of functions and there is really no reason why it has to be a singleton since all instances are equivalent anyway (we only make it singleton for convenience). If this singleton implements any advanced functionality and you want to inject it into a dependent class, then the dependent class should always depend on an interface implemented by the singleton or else you won't be able to use any other implementation which defeats the purpose of dependency injection.