https://kotlinlang.org logo
Title
d

doubov

02/08/2023, 11:28 PM
I'm seeing the following behavior, wondering why it could be happening: 1. Start with Child A 2. Modify Child A state 3. Navigate to Child B 4. Rotate the device 5. Go back to Child A 6. The state is lost The state gets retained properly if we rotate the device on Child A. Setting
backStackCreateDepth
to 1 does fix the bug, but I'm pretty sure this shouldn't be required. 🙏
Looking at the backstack while on Child B: when Child B is launched, backstack consists of a single Created(ChildA) when device is rotated, backstack consists of a single Destroyed(ChildA) Since ChildA is destroyed, I'm assuming all instances that it kept inside of
InstanceKeeper
get destroyed as well, and we get a new instance when we navigate back to Child A. Is this expected? Should
backStackCreateDepth
be set to
Int.MAX
to ensure that state is retained for all the components? 🤔
from the documentation, that seems to be the expected behavior:
Child Stack automatically preserves the stack when a configuration change or process death occurs. By default, only the active component is recreated, components in the back stack remain destroyed and are created on demand.
... but I'm still not sure why a new
InstanceKeeper.Instance
is created when I navigate back to Child A
a

Arkadii Ivanov

02/09/2023, 10:34 AM
As you mentioned, this is indeed by design. Retained instances are destroyed when the hosting component is destroyed and not automatically recreated. Use
backStackCreateDepth
to have the behaviour you want, this would also match the behvaiour of Android Fragments.
Now I'm wondering, maybe we should always recreate components in the back stack? I remember that Android fragments were not recreated automatically in the back stack, but now they are. This would also simplify the API, e.g. child type in the back stack would always be
Child.Created
. I will think about it.
d

doubov

02/09/2023, 4:39 PM
👍 That behavior makes the most intuitive sense to me
a

Arkadii Ivanov

02/09/2023, 4:41 PM
Please vote in the issue. This however would likely require API changes, so maybe in
v2.0.0
I will see if there is a way to avoid breaking changes.