Lifecycle and retaining stores in memory #266
|
So I'll try and properly articulate my confusion. Basically, Decompose via routers handles which child/ configuration is currently on top of the stack so their lifecycle as well is understandable. We can pop the stack so the lifecycle of Decompose components is pretty clear. Now MVIKotlin, stores can be preserved entirely or we can preserve an object, from all of the examples I've seen (from what I remember) we used Also, how does the Lifecycle fit in this story? From what I've seen it's mostly used for binders, and if I follow a Single Activity Approach, I'd basically subscribe/ unsubscribe when my app is opening/ closing (and perhaps configuration changes)? Is there anything more to it that I am missing? |
Replies: 1 comment 1 reply
|
Hello @Nikola-Milovic and thanks for your questions!
As per documentation, As of Decompose, when you pop a component, its retained instances are destroyed (
In general, the If you follow the Single Activity approach, then you probably have something like Fragments or Decompose components, for each "screen". Each Fragment/Component has its own |
Hello @Nikola-Milovic and thanks for your questions!
As per documentation,
InstanceKeeperretains things (not onlyStores) over their scope recreation. This means that objects are not retained in memory forever, but only until its scope (e.g. a Decompose component, or a Fragment) is alive or is being recreated due to Android configuration changes. So it is very similar to AndroidXViewModels.As of Decompose, when you pop a component, its retained instances are destroyed (
InstanceKeeper.Instance.onDestroymethod is caled). If there is a stack of components and you rotate the screen, only the currently active component is recreated and itsInstanceKeeperinstances are …