Hi everyone, we've recently redesigned `Transition...

# compose

[Doris Liu]

Hi everyone, we've recently redesigned Transition animation to make it easier to use and more extensible. tl;dr No more `PropKey`s and `transitionDefinition`s, and instead animations can be declared dynamically. 🎉 Please give the new Transition (available since alpha 09) a try. I would love to hear what you think! 🙏 (P.S. Seeking isn't supported yet, but dynamic target values (e.g. theme-specific values) are now supported.)

[rsktash]

throws error on build when used alpha 09

[Doris Liu]

Can you share the code that caused this error? Or is it just a plain migration to alpha09?

[rsktash]

@Doris Liu Sorry. I’ve forgot to update composeOptions.kotlinCompilerExtensionVersion

[rsktash]

@Doris Liu Is there a sample of transition between buildin vector icons?

[Doris Liu]

Great question. Transitioning between vector icons would require the same amount of path nodes for the purpose of path morphing. Not all built-in vector icons have the same number of path nodes AFAIK. So the solution can't be easily generalized. Maybe @Alexjlockwood could have a Transition<S>.animateVectorIcons(...) extension with ShapeShifter? 😛

[rsktash]

There is no standard path morphing solution for all vector drawables. So It would be nice to have build-in animations for ArrowBack and Search, Edit and Done, etc

[Doris Liu]

Agreed. For some of the built in vectors, we'll probably offer built-in animations like we do with AnimatedVectorDrawable. Meanwhile, we have some ongoing work that is a more general solution for creating custom animated vectors using Transition . Stay tuned! 🙂 @Nader Jawad may be able to share more.

[Alexjlockwood]

haha adding compose support to shapeshifter is something that crossed my mind and i would definitely want to do it eventually (probably wouldn’t be hard either lol). been holding off though since the APIs are constantly changing.

[Alexjlockwood]

also because converting AnimatedVectorDrawable resources to a compose format sounds like not that much fun 😄

[Doris Liu]

We might be able to solve the AVD resources conversion headache for you. 😉

[rsktash]

@Alexjlockwood What a wonderful idea 🤪

[Nader Jawad]

Like @Doris Liu mentioned, stay tuned ;-)

[rsktash]

@Doris Liu Is There a sample for top appbar menu to searchview transition?

https://i.stack.imgur.com/oLG2Y.gif▾

[Doris Liu]

I don't think there's an existing sample for this. The white ripple/reveal seamlessly transitioning into the background is not super straight forward to implement. I played around a bit, and came up with this. Not pixel perfect, more of a quick proof of concept. I haven't seen this sort of reveal transition in the latest material design. Is this on the material design site?

[rsktash]

Thank you @Doris Liu. No it is not. I found it googling.
What about the suggestion list?
Do we have to render it in separate place in order to overlay the content of screen?

[rsktash]

I tried it with Scaffold but when suggestion appears content is being pushed down

[Doris Liu]

Have you tried DropDownMenu 🙂 : https://developer.android.com/reference/kotlin/androidx/compose/material/package-summary#dropdownmenu

[Afzal Najam]

Converted an Exploding Fab that used v1 transitions to v2:
https://gist.github.com/AfzalivE/46e0460aacbd3c04268d4446b3a7f2b1

Some thoughts:
• v2 seems less boilerplate to define all states (even though the number of lines ended up being about the same for the whole code)
• v2 feels more deliberate about all transition states, in my v1, the Initial to Normal transition was automatic and I didn't expect that in the beginning. Although, it would be great to know what the recommended way is to have a transition that runs immediately after the view has been rendered the first time.
• I can see easily see how one can convert a set of "animate()" calls to transitions, which is great!
• Personal preference but this function for defining the transition spec between the initial -> target state was more readable
transition(FabState.Normal to FabState.Exploded)
as compared to
if (it.initialState == FabState.Initial && it.targetState == FabState.Normal)

[Afzal Najam]

Btw, is it intentional that if I write this:

val fabSize by transition.animateDp(
        transitionSpec = {
            keyframes {
                durationMillis = 500
                58.dp at 0
                48.dp at 200
                1500.dp at 500
            }
        }
    ) {
        when (it) {
            initialState -> 20.dp
            normalState -> 56.dp
            explodedState -> 1500.dp
            else -> 56.dp
        }
    }

The animation always goes to 1500.dp even if the state is normalState ?

[Doris Liu]

@Afzal Najam Thanks for the feedback and for sharing the code! I really appreciate that!
• We are evaluating a few different ways to support a different initial state than the first state being passed in. Having initialState be a parameter to transition like in v1 has led to some confusion around what should happen when initialState changes during a transition animation (i.e. restart everything or ignore it, both of which make sense). For v2 we are trying to avoid such confusion, yet provide the support through other solutions. Stay tuned on that. 🙂
• I'm glad you see it as a straightforward conversion from animate. We aim to make it minimum effort to animate things.😁 So we expect folks to start with animate and progress to Transition as needed.
• Very insightful feedback on the ergonomics of transitionSpec ! 🙏 I'm also considering a transition spec builder that supports selective overwrites of the default animations. This feedback is very helpful.👍

[Doris Liu]

The expected behavior for the code snippet above is to animate to 1500.dp (as defined by keyframes) then snap to whatever value defined for the state. It shouldn't "rest" at 1500.dp for any state other than explodedState. I'll file a bug to fix this. Thanks for reporting it. 🙂

[Afzal Najam]

Looking forward to seeing future updates to this!

And yes, that's what was happening. It went all the way to 1500.dp then reset the value to the size defined for normalState so I guess that was working as intended.

[rsktash]

@Doris Liu via dropdown inputfield loosing focus when suggestions shown