InstanceKeeper behaviour changed from 2.1.4 to 2.2.2 to be destroyed in component graph about decompose

[Burtan]

I did some more tests, it only happens after also changing from @Parcable to @Serializable, I will make a reproducer.
Using 3.0.0-alpha05, it works again, although I had to add @Serializable to WebHistoryController, in case that matters.
3.0.0-alpha01 also works.
Thanks for the fast response!

[arkivanov]

There should be no behaviour change, though there could a bug that was fixed. Could you please provide more information? In particular, what you mean by "the main instance keeper seems to be inherited to child components"?

Also a reproducer (a project, a test, etc) would be very helpful.

[arkivanov]

Looking at the changes between 2.1.4 and 2.2.2, I don't see anything that could affect the behaviour.

[arkivanov]

Glad it works on the latest versions. Though, it would be still nice to double check what's the issue.

[Burtan]

I found the reason for the problem.
Have a look at this sample project, branch decompose-2.2.2.
It has a root component with 3 child components. One child component's config has a value "token". When this config is not a data class, this config is always treated as new on recreation regardless of its value and therefore a new InstanceKeeper is created. If it is a data class, the config is compared correctly with the old config, e.g. the same value means the config is not new and therefore the old InstanceKeeper is kept alive. I think the comparison of configs with non data classes in decompose 2.2.2 does not work correctly, but works again with 3.0.0+.

The associated test is here:

I hope this helps :-)

[arkivanov]

Thank you very much for the detailed explanation! Now it's al clear. This behaviour is by design, and it was like this from the very beginning. I'm surprised that it worked in some versions. This is documented - configurations must "Correctly implement equals() and hashCode() methods".

[Burtan]

I just checked my stable branch and this is actually working. It makes sense that equals() and hashCode() should be implemented, but I wonder if comparing the serialized data is an option.

    sealed interface Config : Parcelable {
        @Parcelize class Case(val token: String) : Config
        @Parcelize data object Scanner : Config
        @Parcelize data object History : Config
        @Parcelize data object About : Config
    }

[arkivanov]

Yes, both kotlin-parcelize and kotlinx-serialization handle object classes just fine - there is always just one instance, and so it's always equal. The new data object also generates equals and hashCode functions, just like data class. So it also works with JVM Serialization, though not used by Decompose. Anyway, data object is the safest and preferable way.

[arkivanov]

Closing this for now. Feel free to reopen if there are any issues or questions.