Thread
#compose
    ziv kesten

    ziv kesten

    1 year ago
    Is there a way to add transition animations to the new navigation library for compose?
    i

    Ian Lake

    1 year ago
    No, not yet
    ziv kesten

    ziv kesten

    1 year ago
    Thank you, is it planned to be released within the next few versions?
    It works great by the way 👏
    i

    Ian Lake

    1 year ago
    Yep, it is on the short list for upcoming features 😃
    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
    I'd love to get your thoughts on what exactly you'd like to see in an ideal world
    ziv kesten

    ziv kesten

    1 year ago
    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

    Colton Idle

    1 year ago
    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.
    g

    Guy Bieber

    1 year ago
    When you add transitions I will ditch my current nav implementation.
    I really want to be able to do a blur when an action is happening, like login.
    i

    Ian Lake

    1 year ago
    @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)
    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

    Doris Liu

    1 year ago
    I suspect the blur effect that @Guy Bieber is going after is an enter transition goes from blur to crisp?
    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

    ziv kesten

    1 year ago
    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
    i

    Ian Lake

    1 year ago
    Would you declare it at
    navigate
    time? Or as part of your
    composable
    ?
    composable("profile", enterAnimation=fadeIn(), exitAnimation=fadeOut()) { }
    ziv kesten

    ziv kesten

    1 year ago
    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,
    )
    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) {
    }
    fun navigate(
            destination: T,
            enter: NavigationAnimationType,
            exit: NavigationAnimationType,
            vararg sharedElement: @Composable () -> Unit) {
    }
    i

    Ian Lake

    1 year ago
    Shared elements aren't yet a thing in Compose in general, but yes, we're thinking about those as a longer term thing
    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
    But yep, totally understand what you mean by customizing it by where you're coming from/going to
    ziv kesten

    ziv kesten

    1 year ago
    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.
    i

    Ian Lake

    1 year ago
    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

    ziv kesten

    1 year ago
    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

    Javier

    1 year ago
    @Ian Lake should not be better to use always with compose the next snippet?
    android:configChanges="orientation|screenLayout"
    And using Compose to create a responsive design
    i

    Ian Lake

    1 year ago
    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

    Colton Idle

    1 year ago
    I wish AS had an easy way to trigger process death
    Doris Liu

    Doris Liu

    1 year ago
    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?
    d

    dagomni

    1 year ago
    g

    Guy Bieber

    1 year ago
    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.
    i

    Ian Lake

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

    Guy Bieber

    1 year ago
    Not if the blurred screen login screen is its own thing.
    its own screen
    i

    Ian Lake

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

    Guy Bieber

    1 year ago
    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?
    i

    Ian Lake

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