hi everyone, I want to ask regarding memory usage between `single` and `factory` AFAIK, `single` is...

# koin

[bobby]

hi everyone, I want to ask regarding memory usage between single and factory

AFAIK, single is used to create only one instance during the application lifetime, so when there is a request about the class instance, it will receive the same one, and only disposed when the application get terminate. while factory instance will be created new one every time there is a request with the class, but it’s not clear to me when will it dispose. moreover, there is no explanation (after some research) for the memory usage for those two

can someone please explain about the memory usage? really appreciate it

my colleague really care about the memory usage, since our app is quite large, we try to save every memory we could

thank you

[Pedro Francisco de Sousa Neto]

`Single`/`factory`/`scoped` it will be disposed when you unloadKoinModule that was holding/declaring.

[arnaud.giuliani]

factory just create a new instance for you.

[arnaud.giuliani]

scoped and single will retain it until we ask to drop it

[Pedro Francisco de Sousa Neto]

@arnaud.giuliani just to confirm my experiment, when you’re saying “ask to drop it” it’s the same as unloadKoinModules. Am I right?

[bobby]

scoped and single will retain it until we ask to drop it

so under the hood, for the memory management is the same, right? the difference is in the instance, factory will create a new one, while scoped and single will retain until it got dropped

[bobby]

`Single`/`factory`/`scoped` it will be disposed when you unloadKoinModule that was holding/declaring.

this will be the case if you explicitly unload the module. but what if you not state it explicitly? it’s quite rare for me to do like you mentioned

[arnaud.giuliani]

yeah, unloading a module can be an alternative to complex scopes

[Pedro Francisco de Sousa Neto]

Thanks for the answers, guys!

[Pedro Francisco de Sousa Neto]

I agree with you @bobby. It’s not a normal case but sometimes we discover some modules in fragments that was loaded and not unloaded.

[Pedro Francisco de Sousa Neto]

To add some context, we have more than 60 squads with 2 🤖 developers working on the same project.
We can’t cover all the cases in code review. 😅

[arnaud.giuliani]

perhaps more a scope usage in such context? 🤔

[Pedro Francisco de Sousa Neto]

You gave me other doubt, Arnaud! 🙂

If developer scope some modules in a fragment and use fragmentScope() extension fuction.
It’ll be necessary to load and unload module these modules in fragment?

[Pedro Francisco de Sousa Neto]

In my head, I can inject in application module in this case. To avoid use load and unload inside fragment. With this scope will handle when create and destroy. But I’m not sure of this!

[arnaud.giuliani]

fragmentScope() will hold instances for Fragment’s lifetime. You don’t have to drop things by hand - https://proandroiddev.com/understanding-android-scopes-with-koin-cfe6b60ca579

[arnaud.giuliani]

this article can perhaps help you see better about scopes

[arnaud.giuliani]

by using factory instances, you will follow android lifecycle naturally. If you need more complex assembling, perhaps scopes can be useful

[Pedro Francisco de Sousa Neto]

@arnaud.giuliani I think this question now it’s a end game rsrs.
[1] When you’re using AndroidScopeComponent, you don’t need to load or unload Koin Modules?
[2] If yes, how Koin find your module to instantiate?

[bobby]

I agree with you @bobby. It’s not a normal case but sometimes we discover some modules in fragments that was loaded and not unloaded.

this is interesting, since my team want implement single activity that recommended by Google, it’s important to not leak anything on fragment once it destroy. if i’m not wrong, leaving unload scope could become a leak in a fragment (please validate this)