Status Update
Comments
il...@google.com <il...@google.com>
ti...@gmail.com <ti...@gmail.com> #2
Jeremy, is this still an issue? I think the problem was that you had two transitions targeting the same View for the same action (e.g. two Slide() transitions).
il...@google.com <il...@google.com> #3
I have a similar issue with plain AnimatorSet:
set.start()
set.pause()
set.setCurrentPlayTime(100)
set.setCurrentPlayTime(0)
set.setCurrentPlayTime(100)
set.resume()
doesn't play animation in resume().
gm...@gmail.com <gm...@gmail.com> #4
Should clarify that if I filter out setCurrentPlayTime(0)
(or replace it with setCurrentPlayTime(1)
) it works well.
Also even with setCurrentPlayTime(0)
, onAnimationEnd
is notified with correct delay (as if the animation has played).
jb...@google.com <jb...@google.com> #5
@
I think that is intended for Animator. If you set the currentPlayTime
to 0 or the total duration the animator completes. We do some
gm...@gmail.com <gm...@gmail.com> #6
Did some investigation on the Fragment side and it seems like the merged transition is targeting correctly.
Exiting Transition: Slide@aa9288e: tgts(android.widget.LinearLayout{f9add3d})
>>>>> ExitingViews <<<<<
View: android.widget.LinearLayout{f9add3d}
Entering Transition: Slide@35b8af: tgts(android.widget.LinearLayout{b7f24bc})
>>>>> EnteringViews <<<<<
View: android.widget.LinearLayout{b7f24bc}
Final merged transition: TransitionSet@7bc1c45:
TransitionSet@e133f9a:
Slide@aa9288e: tgts(android.widget.LinearLayout{f9add3d})
Slide@35b8af: tgts(android.widget.LinearLayout{b7f24bc})
merged transition passed to controlDelayedTransition: TransitionSet@7bc1c45:
TransitionSet@e133f9a:
Slide@aa9288e: tgts(android.widget.LinearLayout{f9add3d})
Slide@35b8af: tgts(android.widget.LinearLayout{b7f24bc})
Still digging.
de...@gmail.com <de...@gmail.com> #7
Branch: androidx-main
commit 567b7459329d1ec8d27a8c6fe1c4a86442065d7d
Author: Jeremy Woods <jbwoods@google.com>
Date: Tue Sep 26 20:06:54 2023
Add additional logging for transitions
Adding more debug logging in transitions to track the entering and
exiting transitions as well as the final merged transition and its
targets.
Test: added logging
Bug: 300157785
Change-Id: I0d9ad72b865422493c6c895ddb6115abf85eed16
M fragment/fragment/src/main/java/androidx/fragment/app/DefaultSpecialEffectsController.kt
eu...@gmail.com <eu...@gmail.com> #8
So I have isolated this outside of fragment into something much simpler and I think it breaks down when it comes to the adding and removing of Views with animateToStart.
The attached sample is a simple add that goes between two screens BLUE
and GREEN
. It has code for both the 1.5.0-alpha03
and 1.5.0-alpha04
versions, but I think alpha04 is currently broken in another way so I will upload the alpha03 version here.
This is integrated with predictive back similar to how fragment is, so upon cancelling we call animateToStart
, then we do a beginDelayedTransition
on a 0
duration Fade()
and we reverse the view visibility back to what it was prior to starting the transition.
If you only do visibility, cancel always works the view never goes away, it is wonderful, but when you do adding and removing views like we need to in fragment it fails.
First the code for beginDelayedTransition goes from this:
TransitionManager.beginDelayedTransition(container, Fade().apply {
duration = 0
})
reverseViews()
to this:
TransitionManager.beginDelayedTransition(container, Fade().apply {
duration = 0
addListener(onEnd = {
reverseViews()
blueScreen.visibility = View.VISIBLE
greenScreen.visibility = View.VISIBLE
})
})
reverseViews(useVisibility = true)
We need to make this change because after the animateToStart()
view is still parented by the overlay, so we call reverseViews(useVisibility = true)
to only change the visibility and then once the transition finishes we can call reverseViews()
to parent the view properly, then we make both views visible again.
From our perspective after the 0
duration transition our views are back in the proper state, but they do not transition properly after a cancel.
If the app is doing this wrong and we can make the appropriate fixes, doing the same in fragment should resolve this. There is logging available that shows the state of the views when we start the transition.
ve...@gmail.com <ve...@gmail.com> #9
The API has changed since that project was created in a way that makes the API more robust. I'm hoping that has fixed this...
tf...@gmail.com <tf...@gmail.com> #10
There appears to be a problem with the order of operations. I'm going to look into fixing that.
sm...@gmail.com <sm...@gmail.com> #11
Branch: androidx-main
commit e57dd5f9ac6cbb8cf83b221e2d5b3fbd3e88ce6b
Author: George Mount <mount@google.com>
Date: Thu Nov 09 14:33:53 2023
Fix animateToStart with Slide.
Fixes: 300157785
Slide was not repositioning the View to its proper
translation after animating it to the start position.
This fixes that so that it is moved.
Test: new test
Change-Id: I698f4dbcef46304f9aa545847d205f7b70c80d63
M transition/transition/src/androidTest/java/androidx/transition/SlideEdgeTest.java
M transition/transition/src/androidTest/java/androidx/transition/TranslationAnimationCreatorTest.java
M transition/transition/src/main/java/androidx/transition/TranslationAnimationCreator.java
ti...@gmail.com <ti...@gmail.com> #12
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.transition:transition:1.5.0-alpha05
de...@gmail.com <de...@gmail.com> #13
ap...@google.com <ap...@google.com> #14
Branch: androidx-main
commit 06769a572f7003fb662109b595952d6ff5c63a74
Author: Jeremy Woods <jbwoods@google.com>
Date: Tue Jun 08 16:35:28 2021
Fix fragment transitions in new state manager
In aosp/1679887 we attempted to fix doing shared element transitions on
ViewGroups with the transitionGroup="false" attribute set. That change
caused a regression in enter and exit transitions, and could also cause
errors if the entering fragment attempted to transition more views than
the exiting fragment.
This change makes it so that fragments no longer looks at all of the
views in the hierarchy of sharedelement views. We depend on transition
names to determine if a view is a shared element, and if a shared
element is a viewgroup with transitionGroup="true", the entering/exiting
transition should ignore that viewgroup and transition its unnamed
children.
RelNote: "Fixed regression in shared element transtions caused by
aosp/1679887. Setting transitionGroup=\"true\" will now work correctly and
shared elements will no longer throw `IndexOutOfBoundsException`s."
Test: FragmentSharedElementTransitionTest
Bug: 188679569
Bug: 188969304
Change-Id: I164845639cae1f64cf54e4e89b2a24d7eb649beb
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentSharedElementTransitionTest.kt
A fragment/fragment/src/androidTest/res/layout/scene6.xml
A fragment/fragment/src/androidTest/res/layout/scene7.xml
M fragment/fragment/src/main/java/androidx/fragment/app/DefaultSpecialEffectsController.java
jb...@google.com <jb...@google.com> #15
This has been fixed internally and will be part of the Fragment 1.4.0-alpha03
release. You can verify that it works with your app by following the instructions at SNAPSHOT
s and using a buildId of 7444280
+.
os...@gmail.com <os...@gmail.com> #16
I had the crash starting from 1.3.4
on animation SharedAxis
:
java.lang.UnsupportedOperationException: removeView(View) is not supported in AdapterView
at android.widget.AdapterView.removeView(AdapterView.java:543)
at android.view.ViewOverlay$OverlayViewGroup.add(ViewOverlay.java:198)
at android.view.ViewGroupOverlay.add(ViewGroupOverlay.java:72)
at androidx.transition.TransitionUtils.createViewBitmap(TransitionUtils.java:108)
at androidx.transition.TransitionUtils.copyViewImage(TransitionUtils.java:64)
at androidx.transition.Visibility.onDisappear(Visibility.java:404)
at androidx.transition.Visibility.createAnimator(Visibility.java:257)
at androidx.transition.Transition.createAnimators(Transition.java:744)
at androidx.transition.TransitionSet.createAnimators(TransitionSet.java:480)
at androidx.transition.TransitionSet.createAnimators(TransitionSet.java:480)
at androidx.transition.Transition.playTransition(Transition.java:1808)
at androidx.transition.TransitionManager$MultiListener.onPreDraw(TransitionManager.java:300)
at android.view.ViewTreeObserver.dispatchOnPreDraw(ViewTreeObserver.java:1088)
at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:2769)
at android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:1745)
at android.view.ViewRootImpl$TraversalRunnable.run(ViewRootImpl.java:7772)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:967)
at android.view.Choreographer.doCallbacks(Choreographer.java:791)
at android.view.Choreographer.doFrame(Choreographer.java:726)
at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:952)
at android.os.Handler.handleCallback(Handler.java:883)
at android.os.Handler.dispatchMessage(Handler.java:100)
at android.os.Looper.loop(Looper.java:214)
at android.app.ActivityThread.main(ActivityThread.java:7356)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:491)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:940)
But it disappeared on 1.4.0-SNAPSHOT
starting from 7444280
. Is this crash relates to this issue? And will it be included to 1.3.5
?
Thanks!
gm...@gmail.com <gm...@gmail.com> #17
Seems to be fixed in 1.3.5, thanks!
Description
Component used: Fragment
Version used: 1.3.4
Devices/Android versions reproduced on: Pixel 3 running Android 11
Sample project:https://github.com/tfcporciuncula/playground/tree/transition-issue (branch
transition-issue
)I've learned from this codelab that
transitionGroup=true
can be important in some cases, even when no shared element is involved in the transition, and from my experience it usually makes my Material motion fragment transitions (e.g.MaterialSharedAxis
) look better.Starting from fragment 1.3.4, most likely because of this change , whether I have
transitionGroup=true
or not doesn't make a difference anymore, and now I have to set atransitionName
instead to get the same effect I used to get withtransitionGroup=true
.I'm attaching two videos, both recorded with fragment 1.3.4 and transition 1.4.1, and you can compare the difference between running a material shared axis transition with and without a
transitionName
defined. There are no shared elements involved in the transition, but defining or not atransitionName
in the root of the fragment layouts have a big impact in the transitions, and that seems to be wrong.