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

Comment #12: Thanks, I'm going to do that.

Comment #12: So if I understood you correctly, I should just ignore java.lang.IllegalStateException before emitting? There isn't much else to asLiveData.

  @InternalCoroutinesApi
  val newCycle: LiveData<Boolean> = liveData {
        cycleRepo.newCycleAvailable
                .catch {
                    // ignore IllegalStateException and log cause
                }
                .collect {
                    emit(it)
                }

    }

catching exceptions thrown from the pipeline is not a great idea as it might leave it in an inconsistent state (because the code that is intended to run after it won't run). It is better to just copy it w/o the check

comment #15:

Okay, I'm clearly missing something; when I open the code (ctrl+click) for asLiveData (from FlowLiveData.kt), it seems very simple, and I don't see any checks. This is it:

@JvmOverloads
fun <T> Flow<T>.asLiveData(
    context: CoroutineContext = EmptyCoroutineContext,
    timeoutInMs: Long = DEFAULT_TIMEOUT
): LiveData<T> = liveData(context, timeoutInMs) {
    collect {
        emit(it)
    }
}

If I do the following am I not just duplicating the above?

val newCycle: LiveData<Boolean> = liveData {
        cycleRepo.newCycleAvailable
                .collect {
                    emit(it)
                }
    }

sorry the check is in the liveData function.

https://cs.android.com/androidx/platform/frameworks/support/+/androidx-master-dev:lifecycle/lifecycle-livedata-ktx/src/main/java/androidx/lifecycle/CoroutineLiveData.kt;l=183

so you need to copy a couple :(

comment #17:

Thanks. That makes more sense to me :)

Comment #17: Sorry to be a pain. I considered depending on a snapshot (if only for a few weeks) to be the lesser of two evils.

So I changed my code back to using .asLiveData() and modified my gradle scripts to include

allprojects {
  repositories {
    ...
    maven { url 'https://androidx.dev/snapshots/builds/6603247/artifacts/repository' }
  }
}

and

def lifecycle_version = "2.3.0-SNAPSHOT"

I compared the CoroutineLiveData.kt for the different versions (alpha4, snapshot) and they are identical. I take it the fix is elsewhere? Is it publicly available? Sorry I don't normally use snapshot builds of libraries.

yea the fix is actually in core.

https://android-review.googlesource.com/c/platform/frameworks/support/+/1323278/7/lifecycle/lifecycle-livedata-core/src/main/java/androidx/lifecycle/LiveData.java

i was recommending just removing the check for now, it won't hurt as it is more of a state check to catch these bugs.

but i'm thinking, maybe you should just move to snapshot. also a new version is coming w/ the fix soon (i think next week)

#20,

Thank you.