Fixed
Status Update
Comments
il...@google.com <il...@google.com>
ro...@sparkistic.com <ro...@sparkistic.com> #2
Project: platform/frameworks/support
Branch: androidx-main
commit 57ca221882695bd6a52549f4d9ea3b812e6fe87c
Author: Simon Schiller <simonschiller@users.noreply.github.com>
Date: Mon Mar 22 16:09:30 2021
[GH] [FragmentStrictMode] Detect <fragment> tag usage
## Proposed Changes
- Detect `<fragment>` tag usage inside XML layouts
## Testing
Test: See `FragmentStrictModeTest#detectFragmentTagUsage`
## Issues Fixed
Fixes: 153738235
This is an imported pull request fromhttps://github.com/androidx/androidx/pull/141 .
Resolves #141
Github-Pr-Head-Sha: 4ea052596e4341b9f11bcf335e2bc38045a91f19
GitOrigin-RevId: 62e7487aa4874eef6bb556490e193717cf937251
Change-Id: Iae48578e85e4e4897f806d7ade2e2a660adf9479
M fragment/fragment/api/public_plus_experimental_current.txt
M fragment/fragment/api/restricted_current.txt
M fragment/fragment/src/androidTest/java/androidx/fragment/app/strictmode/FragmentStrictModeTest.kt
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentLayoutInflaterFactory.java
M fragment/fragment/src/main/java/androidx/fragment/app/strictmode/FragmentStrictMode.java
A fragment/fragment/src/main/java/androidx/fragment/app/strictmode/FragmentTagUsageViolation.java
https://android-review.googlesource.com/1649748
Branch: androidx-main
commit 57ca221882695bd6a52549f4d9ea3b812e6fe87c
Author: Simon Schiller <simonschiller@users.noreply.github.com>
Date: Mon Mar 22 16:09:30 2021
[GH] [FragmentStrictMode] Detect <fragment> tag usage
## Proposed Changes
- Detect `<fragment>` tag usage inside XML layouts
## Testing
Test: See `FragmentStrictModeTest#detectFragmentTagUsage`
## Issues Fixed
Fixes: 153738235
This is an imported pull request from
Resolves #141
Github-Pr-Head-Sha: 4ea052596e4341b9f11bcf335e2bc38045a91f19
GitOrigin-RevId: 62e7487aa4874eef6bb556490e193717cf937251
Change-Id: Iae48578e85e4e4897f806d7ade2e2a660adf9479
M fragment/fragment/api/public_plus_experimental_current.txt
M fragment/fragment/api/restricted_current.txt
M fragment/fragment/src/androidTest/java/androidx/fragment/app/strictmode/FragmentStrictModeTest.kt
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentLayoutInflaterFactory.java
M fragment/fragment/src/main/java/androidx/fragment/app/strictmode/FragmentStrictMode.java
A fragment/fragment/src/main/java/androidx/fragment/app/strictmode/FragmentTagUsageViolation.java
cu...@pocketprep.com <cu...@pocketprep.com> #3
Ran into the same issue today with Fragment version 1.4.1.
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: