IssueTracker

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).

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().

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).

@ #4:

I think that is intended for Animator. If you set the currentPlayTime to 0 or the total duration the animator completes. We do some special checks in fragments to handle it.

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.

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.

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...

There appears to be a problem with the order of operations. I'm going to look into fixing that.

The following release(s) address this bug.It is possible this bug has only been partially addressed:

• androidx.transition:transition:1.5.0-alpha05

Was just commenting about the fact that those 2 events are not the same for dialog fragment despite the link you gave.

Since I'm rewriting a lot of stuff, I wonder what will be the final target for 1.3?

• onViewCreated will be attached for every cases
• onViewStateRestored will be attached for every cases
• This is still not determined and maybe not done for 1.3 so I should not bother yet.

This bug is solely about onActivityCreated. If you want to talk about onViewCreated, let's move the conversation onto that bug, linked in comment#9.

If you want a foolproof signal for the View being attached, you should look at the View layer and doOnAttach from core-ktx. You don't need anything at the Fragment layer.

I think there's a communication issue here :) My issue is about onActivityCreated I don't care what is the replacement I just need to know what it will be :)

You tell me that onActivityCreated and onViewCreated are the same as called side by side, this is as proven unfortunately not true for dialog fragments that are fragments.

onActivityCreated is the only callback that is made after the view is properly attached and things are all tied up.

Since you deprecate onActivityCreated my question is unchanged what is / will be the proper callback for dialog fragment that ensure the same state as currently.

I think the main communication issue is that I'm talking about the View moving to the attached state and you're talking about when the view has been added to its parent ViewGroup. While related (a View cannot be attached unless it is added to a ViewGroup that is attached), they are absolutely not the same thing.

For a non-dialog Fragment, the View is added to its container (but not always attached) right before onViewCreated() is called. The other bug is about ensuring that it is both added and attached before running onViewCreated().

For a dialog Fragment, there is no container. FragmentManager does nothing before onViewCreated(). This is likely to continue to be the case in Fragment 1.3.0 and beyond. DialogFragment currently adds the View to the dialog in onActivityCreated(), but still does not wait for the View to be attached. We'll need to continue to do that for backward compatibility, but will rewrite DialogFragment to allow for an eventual removal of onActivityCreated() entirely. That's the work I mentioned in #12.

Like I mentioned, you should really use doOnAttach in onCreateView or onViewCreated if you want to get a callback for when your View has been attached and, by prerequisite, added to its parent. That will work consistently across all cases, Fragment, DialogFragment, or non-Fragment use cases.

Thanks for clarification effectively I had no idea about added to parent being different from attached at the view level. Is there some doc page outside of raw API description that better cover that point?

This has been fixed internally and will be available in the Fragment 1.3.0-alpha02 release.

In my project, I currently use onActivityCreated() to show/hide the app toolbar (with activity.supportActionBar.show()/activity.supportActionBarHide()). Is it safe to move that logic to onViewCreated() (as it is similar as onActivityCreated() from my understanding of previous comments), or should I add a lifecycle observer on the Activity?

Re #21 - certainly sounds like you want onViewCreated().

Re #23 - sounds like onViewCreated() is what you're looking for.