r

    Rob

    1 year ago
    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?
    I'm also using navigation component so I don't know if that's causing the issue.
    i

    Ian Lake

    1 year ago
    r

    Rob

    1 year ago
    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.
    Thanks @Ian Lake! You're awesome 😄
    i

    Ian Lake

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

    Rob

    1 year ago
    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.
    i

    Ian Lake

    1 year ago
    It absolutely does use fragment transactions, that's the only way to interact with fragments
    I don't know what a "simple fragment transaction" is though
    r

    Rob

    1 year ago
    i

    Ian Lake

    1 year ago
    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?
    r

    Rob

    1 year ago
    Yes, my nav component does animations.
    And NavigationUI
    i

    Ian Lake

    1 year ago
    Add animations to your fragment transaction and you'll see the same behavior
    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)
    So you should see the same issue if you use activity transitions; it isn't something fragment specific
    r

    Rob

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

    Ian Lake

    1 year ago
    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.
    So if you have
    navigation-ui
    as a dependency, try it with
    R.animator.nav_default_enter_anim
    and the other public Animators it provides
    (there's an
    enter
    ,
    exit
    ,
    pop_enter
    , and
    pop_exit
    )
    r

    Rob

    1 year ago
    I see. NavComponent action enterAnim etc use Animator. I thought it would use Animation.
    i

    Ian Lake

    1 year ago
    Ah no, there's a number of infeasible to fix problems with
    Animation
    that make it a terrible choice in general
    Which is why the entire
    Transition
    system is built on
    Animator
    r

    Rob

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

    Manuel Vivo

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