Is there a way to add transition animations to the new navigation library for compose?

# compose

[ziv kesten]

Is there a way to add transition animations to the new navigation library for compose?

[Ian Lake]

No, not yet

[ziv kesten]

Thank you, is it planned to be released within the next few versions?

[ziv kesten]

It works great by the way 👏

[Ian Lake]

Yep, it is on the short list for upcoming features :-)

[Ian Lake]

I don't think we have a tracking issue for this yet, do you mind creating one? https://issuetracker.google.com/issues/new?component=409828&template=1093757

[Ian Lake]

I'd love to get your thoughts on what exactly you'd like to see in an ideal world

[ziv kesten]

I'll sit down Sunday and write down my thoughts on it so I can communicate them best to you (and to create the issue tracker 😁...)
Thank you so much for the work and the fast reply 🙏🙏

[Colton Idle]

Looking forward to starring the issue. So far the mdc animations work great with the legacy android view system + fragments + AAC nav, so I'm hoping compose is also really similar in that regard.

[Guy Bieber]

When you add transitions I will ditch my current nav implementation.

[Guy Bieber]

I really want to be able to do a blur when an action is happening, like login.

[Ian Lake]

@Guy Bieber - do you mind explaining what you mean by "do a blur when an action is happening, like login"? Wouldn't login be a separate screen in your app? If you mean "blur while you wait for a server response from a login attempt", I'm not sure what that has to do with Navigation (that seems like a more general animation that you'd do within just that login screen)

[Ian Lake]

I suspect that basing animations on AnimatedVisibility (https://developer.android.com/reference/kotlin/androidx/compose/animation/package-summary#AnimatedVisibility(kotlin.Boolean,%20androidx.compose.ui.Modifier,%20androidx.compose.animation.EnterTransition,%20androidx.compose.animation.ExitTransition,%20kotlin.Boolean,%20kotlin.Function0)) which already has the concept of entering and exiting transitions is going to be the easiest / most concise implementation that will cover the 90% of cases, but I'm equally interested in what those 10% cases are

[Doris Liu]

I suspect the blur effect that @Guy Bieber is going after is an enter transition goes from blur to crisp?

[Doris Liu]

I'd be also interested in the types of enter/exit transitions that would be helpful. Especially ones that are not already covered in AnimatedVisibility that @Ian Lake linked above. 🙂

[ziv kesten]

AnimatedVisibility, as well as Crossfade, works great but when implementing the Compose Navigator, i would expect some “Transition” animation.

So basically i would want to be able to provide enter and exit animations as parameters for the navigate method, like this:
navController.navigate(
destination: T,
enter: NavigationAnimationType,
exit: NavigationAnimationType,
)

Where NavigationAnimationType is some enum or sealed class with types like crossfade, crossBlur (like with the login screen mentioned

crossBlur slow.mp4crossblue fast.mp4

[Ian Lake]

Would you declare it at navigate time? Or as part of your composable?


composable("profile", enterAnimation=fadeIn(), exitAnimation=fadeOut()) { }

[ziv kesten]

The declaration would be at navigate time, that way you would decouple the composable from the animation type, ands that could be dynamic based on the flow its used at

navController.navigate(
destination: T,
enter: NavigationAnimationType,
exit: NavigationAnimationType,
)

[ziv kesten]

Also i was thinking how awsome it could be to provide a list of composables as shred ellemnt transitions.

They would be included in both the enter and the exit composables but with diffrent modifier and the system would animate between the modifiers.

navController.
fun navigate(
        destination: T,
        vararg sharedElement: @Composable () -> Unit) {
}

ContactsAnim.mp4

[ziv kesten]

fun navigate(
        destination: T,
        enter: NavigationAnimationType,
        exit: NavigationAnimationType,
        vararg sharedElement: @Composable () -> Unit) {
}

[Ian Lake]

Shared elements aren't yet a thing in Compose in general, but yes, we're thinking about those as a longer term thing

[Ian Lake]

The biggest issue with declaring things at navigate time is around the exiting side of things given that you could rotate your screen (/any config change) or go through process death+recreation before you actually exit. That is extremely limiting in what we can store to actually consistently run when you exit

[Ian Lake]

But yep, totally understand what you mean by customizing it by where you're coming from/going to

[ziv kesten]

I may be off here but wouldn't using the navigate() method in the viewModel take care of the config change issue in exit?
The way I am structuring my app is by having a viewModel that is passed down the chain to composables.
Basically one viewModel per activity, and multiple screens represented by composables.

When navigating screens in a flow scope (within the same activity) I will call navigation in the viewModelScope.

I haven't tested it thoroughly yet but it seems to survive config changes well this way.

[Ian Lake]

No, ViewModels don't help, nor do they help with the process death/recreation case. navigate() is at entering time; your app code isn't involved when the user hits the system back button when using NavController and that system back button press can be arbitrarily later than the enter

[ziv kesten]

I see, I definitely was off then with my thinking, that means that declaring the animations in the composable itself would definitely be the right approach for now.

Although I do think that if it could be worked out, declaring at navigate time is the best approach. 🙏

[Javier]

@Ian Lake should not be better to use always with compose the next snippet?

android:configChanges="orientation|screenLayout"

[Javier]

And using Compose to create a responsive design

[Ian Lake]

There's a lot more config changes that affect the space your app is provided, but yes, that's definitely an option in a pure Compose app. That still doesn't help you with process death and recreation (keep in mind that on many devices, just launching the camera app and coming back to your app is enough to trigger those cases)

[Colton Idle]

I wish AS had an easy way to trigger process death

[Doris Liu]

Curious whether there's a need to specify different enter animation for the same destination when the starting screen is different. E.g. Fade in screen B when going A->B, but slide in B when going from screen C->B. Would that be a useful case to support?

[dagomni]

@Colton Idle there's a useful library for that
GitHub - YarikSOffice/venom: A lightweight tool that simplifies testing of the process death scenario.

[Guy Bieber]

For the transition after they click login, I want to blur the login screen until I get a positive or negative response. If successful I would navigate to the home screen. If unsuccessful the unblurred login screen would come back.

[Ian Lake]

That type of transition would be something completely independent of Navigation, given that it is all scoped to one screen in your app

[Guy Bieber]

Not if the blurred screen login screen is its own thing.

[Guy Bieber]

its own screen

[Ian Lake]

I don't see why it would be? Sounds like it would be val blurred = mutableStateOf(false) in your login screen

[Guy Bieber]

Could be. However, I haven’t found an easy way to blur a screen without doing a pixel capture. Has something been added to support this in compose?

[Ian Lake]

There's an existing feature request for a blur modifier: https://issuetracker.google.com/issues/166927547