I have a ComposeView in a Fragment, that doesn't get it's state restored when from popping the back ...

# compose

[Rob]

I have a ComposeView in a Fragment, that doesn't get it's state restored when from popping the back stack for a fragment transaction. I've tried using an XML with an id set on the ComposeView which normally would save view state for non-compose views. This is resetting my LazyColumn position to the top. I can work around it by having a LazyListState in the Fragment ViewModel. Having to save all view state in the VM to be restored when popping the back stack doesn't seem optimal. Am I doing something wrong?

[Rob]

Untitled

[Rob]

I'm also using navigation component so I don't know if that's causing the issue.

[Ian Lake]

Are you setting the right ViewCompositionStrategy on your ComposeView? https://kotlinlang.slack.com/archives/CJLTWPH7S/p1619714525127100?thread_ts=1616835899.254600&cid=CJLTWPH7S

[Rob]

I'll look into that. I made a test app that just did a fragment transaction and it does save the LazyColumn state. I'm losing the ComposeView state when using NavComponent to navigate to another view and popping back.

[Rob]

Thanks @Ian Lake! You're awesome 😄

[Rob]

@Ian Lake Maybe that should be mentioned here? https://developer.android.com/jetpack/compose/interop/interop-apis?authuser=1

[Ian Lake]

I know @Manuel Vivo was looking at that exact page just recently. Yes, you should always be using ViewCompositionStrategy.DisposeOnViewTreeLifecycleDestroyed when in a fragment

[Rob]

I thought NavComponent uses fragment transactions under the hood. I confused why I need to change the composition strategy using NavComponent but not when doing a simple fragment transaction.

[Ian Lake]

It absolutely does use fragment transactions, that's the only way to interact with fragments

[Ian Lake]

I don't know what a "simple fragment transaction" is though

[Rob]

Untitled.cpp

[Rob]

Untitled.cpp

[Ian Lake]

And it gets a lot more complicated when it comes to running animations and transitions - that's really where the issues come in. Does your Navigation code use those / are you using NavigationUI?

[Rob]

Yes, my nav component does animations.

[Rob]

And NavigationUI

[Ian Lake]

Add animations to your fragment transaction and you'll see the same behavior

[Ian Lake]

The default strategy is tied to the view being detached from the window, which makes it quite incompatible with how transitions and animators work (by detaching your view from the hierarchy and operating on an overlay containing those views)

[Ian Lake]

So you should see the same issue if you use activity transitions; it isn't something fragment specific

[Rob]

I tried a transaction with an animation and it did save the ComposeView's state when popping.

Untitled.cpp

[Ian Lake]

Ah, sorry, I should have been more clear - in the View system, there's two entirely, completely separate systems - Animation (introduced in API 1, what you're using) and Animator (introduced in API 11 as a replacement for Animation which is what Navigation, Transitions, and everything else uses). Animator is the only one that does the detaching behavior.

[Ian Lake]

So if you have navigation-ui as a dependency, try it with R.animator.nav_default_enter_anim and the other public `Animator`s it provides

[Ian Lake]

(there's an enter , exit, pop_enter, and pop_exit)

[Rob]

I see. NavComponent action enterAnim etc use Animator. I thought it would use Animation.

[Ian Lake]

Ah no, there's a number of infeasible to fix problems with Animation that make it a terrible choice in general

[Ian Lake]

Which is why the entire Transition system is built on Animator

[Rob]

Yeah, I saw an IO talk about all the different animation systems. I'd need to rewatch it to refresh my memory.

[Manuel Vivo]

Thanks for raising this, yeah, I’m updating the docs to include this. In fact, Ian has an email in his inbox regarding this 😄