Archie

    Archie

    1 year ago
    Hi @Doris Liu, I was reading around Transition Samples and found this:
    @Composable
    fun PoppingInCard() {
        // Creates a transition state with an initial state where visible = false
        val visibleState = remember { MutableTransitionState(false) }
        // Sets the target state of the transition state to true. As it's different than the initial
        // state, a transition from not visible to visible will be triggered.
        visibleState.targetState = true
        ...
    }
    I was wondering whether doing:
    visibleState.targetState = true
    is fine? Like to create an "Intro Animation"? or is it better to put that inside a
    SideEffect
    ? or is there a better way?
    Doris Liu

    Doris Liu

    1 year ago
    visibleState.targetState = true
    is perfectly fine. You can even do a
    val visibleState = remember { MutableTransitionState(false).apply{ targetState = true } }
    if you never intend to change the
    targetState
    again. 🙂
    Archie

    Archie

    1 year ago
    Awesome! On a different topic, is there a way to add animation into LazyColumn or LazyRow? are there any samples on that?
    Doris Liu

    Doris Liu

    1 year ago
    What specific animation do you have in mind? Enter and exit?
    Archie

    Archie

    1 year ago
    Yes, I was thinking if the same thing could be done for it?
    Doris Liu

    Doris Liu

    1 year ago
    I assume with LazyColumn you'd want to animate in the same item only once, rather than every time you it appears through scrolling. If that's the case, you could consider hoisting the
    MutableTransitionState
    . I suspect it won't work well if you scroll away during the animation, because
    MutableTransitionState.currentState
    doesn't change until the animation is finished. So when you scroll back, the animation will restart from the beginning. This is a good feature request. 🙂
    Archie

    Archie

    1 year ago
    hmmmm... interesting... so is this like the official way to do "Intro Animation" for composables? I'm still kind of confuse.. I try and play around it more... 🙂
    Im still quite confuse about adding animation for lazy columns or rows... like added enter animation when items are added or exit animation when removed or changed... are there existing samples on that as well?
    Doris Liu

    Doris Liu

    1 year ago
    For LazyFoo, we don't have a good solution to animate things that get added or changed yet. 😞 It is on our roadmap though. For non-lazy composable, using the
    MutableTransitionState
    is recommended way to go for enter animation using
    Transition
    .
    Archie

    Archie

    1 year ago
    Alright! Thank you very much! 😄 I try and play around and expirement with it 😄
    Doris Liu

    Doris Liu

    1 year ago
    Right now the solution requires some manual wire up on the call site. For example, you'd need to manually track which item has been shown, so as to know whether there should be an enter animation for it when it re-enters composition. LazyFoo works differently than the other composables, a lot of the assumptions for the enter/exit transition don't apply.
    Archie

    Archie

    1 year ago
    Sorry @Doris Liu, may I ask another question.. completely unrelated.. I was tryin to do a "vibration" animation... something like the image attached. But I cant seem to think of how to define the animation to start and end at the same position??
    Doris Liu

    Doris Liu

    1 year ago
    I'd suggest
    launch
    a new coroutine to animate the offset of the container when you need it to shake. My recommendation is using
    Animatable.animateTo
    with either
    keyframes
    , or an initial velocity + a high bouncy
    spring
    . 🙂
    Archie

    Archie

    1 year ago
    That means.. animate it to a certain value and then animate it back to 0? right something like:
    offsetAnim.animateTo(IntOffset(10))
    // then immediately set it back to 0
    offsetAnim.animateTo(IntOffset.ZERO)
    is this correct? or is there a better way in the existing api? (Im really sorry if this was a stupid question)
    Doris Liu

    Doris Liu

    1 year ago
    keyframes is a special type of
    AnimationSpec
    . You could do something like:
    // Assuming offset is Animatable<Dp>
    offset.animateTo(0.dp, keyframes<Dp> {
        durationMillis = 300
        0.dp at 0
        80.dp at 100
        -30.dp at 200
        0.dp at 300
    }
    Archie

    Archie

    1 year ago
    Oh I see now!! Thank you very much.. I also missed "or an initial velocity + a high bouncy 
    spring
    " Sorry about that... thank you very much 😄
    @Doris Liu sorry I have another question about the Transition API. Is there an important difference between using
    MutableTransitionState
    over
    MutableState
    +
    updateTransition(mutableState)
    ?? Also is there a way to do
    Transition
    based on a composable size? for example translating a composable based on it size.. I would like to have a similar effect to
    AnimatedVisibility
    's
    slideInHorizontally()
    where it could translate the whole composable's based on it width.
    Doris Liu

    Doris Liu

    1 year ago
    Is there an important difference between using 
    MutableTransitionState
     over 
    MutableState
     + 
    updateTransition(mutableState)
    ??
    Right now the difference is
    MutableTransitionState
    1) allows an initial state different than the first target state. 2) can be intentionally recreated to tigger the re-creation of the transition animation (i.e. forcing it to restart).
    Also is there a way to do 
    Transition
     based on a composable size? for example translating a composable based on it size.. I would like to have a similar effect to 
    AnimatedVisibility
     's 
    slideInHorizontally()
      where it could translate the whole composable's based on it width.
    Not at the moment, but it's high on my feature list. 😄
    Archie

    Archie

    1 year ago
    Alright thank you very much!
    Hi @Doris Liu, just another random question. I was wondering if you have recommendation about shared UI? This is kind of our UseCase: We have multiple Screen A, B, C, D, E, F, G. Screen A, B and C uses the same TopAppBar but the title changes from screen to screen. When getting to screen D and E the used TopAppBar is different. then F and G also uses different TopAppBar. My question is whether I should have a Single AppBar (3 AppBar for this case) for each section and "change its visibility" when screen changes or Define the AppBar for each screen and simply "cheat" that the appbar is staying in place by using animation. I'm kind of stuck between which approach is better in compose and if the second approach is even possible. I apologize in advance if this question doesn't really fit this channel.
    Doris Liu

    Doris Liu

    1 year ago
    Hey, this is a great question! It's a very helpful use case for us to consider. I'm glad you asked! 🙂 I would encourage you to ask questions like this in the open chat room as others might have solutions that I wasn't aware of. Also the collective answers to these questions may benefit everyone reading them. Ideally compose should handle the shared content, but that's unfortunately not yet available. 😅 Between the two options that are presented, I think option 1 may give you more control on animating the app bar. I'm not sure option 2 would allow you to enable/disable animation for the app bar ad-hoc. So until we provide a out-of-the-box solution in compose, I'd recommend option 1. 🙂
    Archie

    Archie

    1 year ago
    Alright! The thing that confuse me the most with option one though is that if a state that is defined in the scope of the screen needs to change the state of the AppBar (or shared UI). It breaks the concept of push the state down and pushing events up. For example: Screen A, B, C shares an AppBar But in Screen C, we need an "Edit" button, the state to enable edit or disable is defined in the Screen C. Its possible to work around this scenario but it limits alot of things. It also doesn't help that existing official samples, specifically JetNews, doesn't do a shared UI approach but instead define an AppBar for each screen. I really appreciate your answer. It gives me more confidence on what approach to take. Thank you very much.
    Doris Liu

    Doris Liu

    1 year ago
    Without looking at the code, it sounds like perhaps the state to enable/disable edit can be hoisted. I'm happy to take a look at your code if you don't mind sharing. 🙂
    Archie

    Archie

    1 year ago
    I'll try to create a small sample since I can't share the whole code as its company code but ill try to replicate the usecase in a smaller project. I really appreciate your replies. Thank you very much. I hope I am not wasting too much of your time.
    Doris Liu

    Doris Liu

    1 year ago
    I'll try to create a small sample since I can't share the whole code as its company code but ill try to replicate the usecase in a smaller project.
    Sounds good.
    I really appreciate your replies. Thank you very much. I hope I am not wasting too much of your time.
    No worries. 🙂
    Archie

    Archie

    1 year ago
    Hi @Doris Liu, Here's the sample. https://github.com/qrezet/SharedUiSample/blob/master/app/src/main/java/com/sample/sampleapp/MainActivity.kt I added my concerns in the comment. Thank you very much.
    Doris Liu

    Doris Liu

    1 year ago
    Hey @Archie, just took a look at the gist. Thanks for sharing. It seems to me the wire-up is inevitable between the TopBar and ScreenC. The two options are: 1) Hoist onClick/save action like you did, 2) hoist the state such as the ViewModel, which you expressed concerns with in the comments. I can't think of other ways to do it aside from these two. Perhaps others would have different ideas? Might be worth creating a new thread in the chat room. 🙂
    Archie

    Archie

    1 year ago
    Alright! Thank you very much 😃 I really appreciate it 😃