Material-components-android: [MaterialFadeThrough] Transition does not take in account target view alpha values

[Tolriq]

Description:

When using MaterialFadeThrough as enterTransition = MaterialFadeThrough() for fragment transition the target view alpha status is not taken in account.

Expected behavior:

The transition should take in account the target views alpha status.
When having a view with alpha=0 defined in XML that transition will animate the alpha to 1.0f (Took me a while to understand why the view was now visible)

The workaround is to excludeTarget those view manually. But 1) it's really hard to figure out what is happening 2) it should not be necessary as actual alpha could be computed and if the final alpha is 0.5 then the transition should do 0 to 0.5 and not 0 to 1.
Source code:

In fragment transition just use enterTransition = MaterialFadeThrough() and in final fragment have a view defined as

    <View
        android:id="@+id/placeholder"
        android:layout_width="match_parent"
        android:layout_height="24dp"
        android:alpha="0"
        android:background="?attr/colorPrimaryDark"
        android:translationZ="4dp" />

Proper solution is probably that start / end values from https://github.com/material-components/material-components-android/blob/master/lib/java/com/google/android/material/transition/FadeThroughProvider.java are properly get from the view if set (But don't know the internal to know when the values should be computed)

Android API version: Android API version 10 and 11 but probably all.

Material Library version: Material Android Library version you are using : 1.2.1

Device: Device on which the bug was encountered : All including emulators

To help us triage faster, please check to make sure you are using the latest version of the library.

We also happily accept pull requests.

[hunterstich]

Hey @Tolriq,

Thanks for filing an issue! I see what you're saying. I'll start looking into this

[Tolriq]

That was fast thanks 👍

@hunterstich Just to be sure when are those getter called during fragment transition?

Like if we have enterTransition = MaterialFadeThrough and a sharedElement transition, and in the onMapSharedElements of the sharedElementCallback I change the alpha of a target view is it too late or not? If yes when should it be done for the cases that are more dynamic ?

[Gericop]

@hunterstich @ymarian
I've just spent hours trying to figure out what's wrong with my transitions in 1.3.0-alpha03 until I found this change. This messes up MaterialSharedAxis (and possibly any of the other transitions that use the FadeThroughProvider) in the following situation:

• my layout has two groups: state and progress views
• initially the state progress with "waiting" icon / text is displayed
• "work in progress" event comes in, transitioning to the progress views with MaterialSharedAxis along the X axis to make it look good
• "done" event comes in, transitioning to the state views once again, updating the icon / text to whatever represents the event

This is where nothing is shown because the first transition gave these views the alpha value 0 so transitioning to them again means 0 to 0, so they remain invisible. There should be a flag or some other way that considers the situation where previously transitioned items are being re-introduced into the layout without explicitly setting their alpha to 1.

[hunterstich]

@Gericop

I initially though this could be related to https://github.com/material-components/material-components-android/issues/1771.

But, I'm not sure I fully understand the situation you're describing. Are you able to attach a sample that reproduces your scenario?

[Gericop]

@hunterstich
I will as soon as I'm able to. Until then, here's the description of the scenario:
You have 2 views: P (for Progress) that is displayed while there's work in progress, and S (for State) that is displayed essentially any other time for different states like default, error, success, etc.
Initially default (S) is shown, then for a network request P is shown with transition from S to P. When the request is done, S gets displayed again (in either error or success state) with transition from P to S. This is where the problem occurs as the previous transition set the alpha value of S to 0. Thus, the captured "end value" of S will be 0, which results in a 0 -> 0 alpha transition. If the S state was error and there's a retry button, and S -> P transition happens, where P's alpha value will be 0 due to the previous reason and will not appear on the screen.

TL;DR:
Any time there's an S -> P -> S transition, the _desired ending_ alpha value of S at the second transition is 0 because the first transition sets it to zero during the animation.

One way to overcome this would be possibly to reset the alpha value to the initial value when the view's visibility is set to GONE / INVISIBLE eventually.

[hunterstich]

@Gericop Okay! Now I understand what's happening. I've made a small demo and can repro this. No need to submit your own sample!

I'll look into ways we can fix this and hopefully get a solution submitted soon

[hunterstich]

@Gericop this should be fixed in 49ad522!