Fixed
Status Update
Comments
il...@google.com <il...@google.com>
ro...@sparkistic.com <ro...@sparkistic.com> #2
Hi Ed, Thank you so much for these suggestions. I've been reviewing them and merging them in. Hopefully it should be live. I've included a thank you note too in the article.
cu...@pocketprep.com <cu...@pocketprep.com> #3
Great! Thanks a lot, I'll look for the live updates soon!
al...@gmail.com <al...@gmail.com> #4
Using androidx.navigation:navigation-fragment-ktx:2.5.0 and running into the same issue, please provide a workaround
al...@gmail.com <al...@gmail.com> #5
Comment has been deleted.
ap...@google.com <ap...@google.com> #6
Project: platform/frameworks/support
Branch: androidx-main
commit 937fa523a427c942b00b9dcb5f056b5d03454160
Author: Jeremy Woods <jbwoods@google.com>
Date: Wed Jul 20 16:56:50 2022
Move all Fragment animations in the same direction
Say you have 3 fragments, A, B, and C. If you add A and B with one set
of entering and exiting animations. And then pop B, before adding C with
an different set of entering and exiting animations while using the
recommended setReorderingAllowed=true flag on your fragment
transactions, it is possible to get in a scenario where the visible
exiting fragment, B, uses the animations from the popping opertion to A
instead of the adding operation with C.
The reason for this is that the animations for B are set during the
first operation with the pop from B to A. The system is then
techinically doing a replace operation from A to C, since B has already
been popped, so it sets the proper animations on A and leaves B
untouched. This causes B to run the stale animations from the pop
instead of the current animations from the replace.
We should ensure that we always run the animations from the operation
that determines what will be visible to user on the screen.
RelNote: "Fragments will now run the proper animations when mixing pop
and replace operations."
Test: added FragmentAnimationTest
Bug: 214835303
Change-Id: Ib1c07bd0e05c0c1a3d785e29456bad9afb183e2d
M fragment/fragment/src/main/java/androidx/fragment/app/DefaultSpecialEffectsController.java
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentAnimationTest.kt
https://android-review.googlesource.com/2161123
Branch: androidx-main
commit 937fa523a427c942b00b9dcb5f056b5d03454160
Author: Jeremy Woods <jbwoods@google.com>
Date: Wed Jul 20 16:56:50 2022
Move all Fragment animations in the same direction
Say you have 3 fragments, A, B, and C. If you add A and B with one set
of entering and exiting animations. And then pop B, before adding C with
an different set of entering and exiting animations while using the
recommended setReorderingAllowed=true flag on your fragment
transactions, it is possible to get in a scenario where the visible
exiting fragment, B, uses the animations from the popping opertion to A
instead of the adding operation with C.
The reason for this is that the animations for B are set during the
first operation with the pop from B to A. The system is then
techinically doing a replace operation from A to C, since B has already
been popped, so it sets the proper animations on A and leaves B
untouched. This causes B to run the stale animations from the pop
instead of the current animations from the replace.
We should ensure that we always run the animations from the operation
that determines what will be visible to user on the screen.
RelNote: "Fragments will now run the proper animations when mixing pop
and replace operations."
Test: added FragmentAnimationTest
Bug: 214835303
Change-Id: Ib1c07bd0e05c0c1a3d785e29456bad9afb183e2d
M fragment/fragment/src/main/java/androidx/fragment/app/DefaultSpecialEffectsController.java
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentAnimationTest.kt
de...@gmail.com <de...@gmail.com> #7
Good day, was this solved with the latest version or by changing the code itself?
de...@gmail.com <de...@gmail.com> #8
I am still experiencing `exitAnim` not working when using `popUpTo` with the latest fragment-ktx:1.6.0 and navigation-fragment-ktx:2.5.1
jb...@google.com <jb...@google.com> #9
This has been fixed internally and will be available in the Fragment 1.5.2
release.
de...@gmail.com <de...@gmail.com> #10
How about for fragment-ktx:1.6.0 ?
Description
Component used: Fragment
Version used: 1.3.0, 1.4.0. Does not reproduce on 1.2.5.
Devices/Android versions reproduced on: Android Emulator.
Issue description
Given the following navigation graph:
Expected result:
I expect the following transition for the action
action_fragmentB_to_fragmentC
:@anim/fadeout
@anim/fadein
See
expected.mp4
attachment.This is what actually happens with fragment:1.2.5, but is broken in 1.3.0 and 1.4.0.
Actual result
From fragment:1.3.0 onwards, what happens is that, when
app:popUpTo="A"
is used, and while A is in the backstack, the transition for the actionaction_fragmentB_to_fragmentC
is different:@anim/slide_out_to_left
- Unexpected!@anim/fadein
It seems that the navigation component uses the
exitAnim
transition from the previously executed action,@id/action_fragmentA_to_fragmentB
.Removing
app:popUpTo="A"
from the action resolves the issue.See
actual.mp4
attachment.Reproducer
Attached minimal reproducer project:
NavigationAnimationTest.zip
.For swapping fragment versions, comment/uncomment the following
app/build.gradle
lines: