Status Update
No update yet.
Comments
il...@google.com
da...@google.com
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
il...@google.com
da...@google.com
I have a crash workaround that just set all the transitionName again upon click the button.
It still has issue that it does not animate the right panel of the action list.
da...@google.com
For debugging: add this line to frameworks/support/samples/SupportLeanbackDemos/build.gradle to force it build from fragment library source: implementation(project(":fragment:fragment"))
Then install the sample app on TV emulator: ./gradlew support-leanback-demos:installDebug
There are two menus in the demo app home screen: "Guided Step" and "Guided Step (Support Version)", first is the framework fragment that doesn't crash, second is the support library version fragment that will crash with latest fragment source code.
jb...@google.com
Based on the videos, it looks like fragment 1.3.0 is doing the shared element transition for the next button and fragment 1.2.5 is not. In the 1.3.0, you see the text "Next" does not move, indicating that it is being shared between the two transitioning fragments. From the description, it seems like you don't want all of the transitions in the onAddSharedElementTransition method action_fragment_background, (guidedactions_list_background, or guidedactions_list_background2, etc.) in other cases.
For the other issue of the shared element being null. It looks like we could be accidentally clearing the transition names of views that were marked as shared element transitions, but actually aren't. This isn't an issue if you use ViewCompat.setTransitionName() before adding your shared element transition, but if you set it in the view xml as leanback does, it never gets set again. Only adding shared elements for views that are actually doing a sharedElementTransition or calling setTransitionName before adding shared elements will always work regardless of what fragments does.
jb...@google.com
da...@google.com
The fragment replace fragment transition is defined here
The reason that GuidedStepFragment want *all* of that to be shared element transition is because ChangeBounds transition needs to change bounds of every view in the hiearchy, from the RecyclerView, up to the root.
da...@google.com
jb...@google.com
We are going to address the issue with clearing the transition names that is causing the crash.
The transitions themselves are working as intended. The old system would only look at named views, not the children at all when targeting the shared element transition. We now look at the entire view hierarchy so children are transitioned properly.
ap...@google.com
Branch: androidx-main
commit ae6aff9326ce2b4f25731635230f600be18a3ba6
Author: Jeremy Woods <jbwoods@google.com>
Date: Thu Mar 04 15:28:27 2021
Ensure Fragments do not clear view transitionNames
When transitioning views are nested within ViewGroups that have
transitionNames but are not transitioning groups, the views are captured
as sharedElement views multiple times within the DefaultSpecialEffects
controller. As a result of this, as we collect and clear the transition
names, we capture a null name and end up restoring the null name to the
view once the shared element transition has finished.
We should only capture each shared element view once and therefore we
only restore it once, with the proper transition name.
RelNote: "Views within in a shared element hierarchy will no longer have
their transition name cleared when doing a shared element transition."
Test: testNestedSharedElementView
Bug: 179934757
Change-Id: I4d4a6d7770d5c6d54e4c647559d5cabae71f0051
A fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentSharedElementTransitionTest.kt
A fragment/fragment/src/androidTest/res/layout/nested_transition_groups.xml
M fragment/fragment/src/main/java/androidx/fragment/app/DefaultSpecialEffectsController.java
jb...@google.com
This has been fixed internally and will be available in the next version of Fragments.
Description
Component used:
When using the above components together, there are two problems:
GuidedSupportFragment.add.When using Fragment 1.2.5, there is no problem.
Sample project attached.