Hi <@UNH9ZT3NZ>, I was reading around Transition S...

# compose

[Archie]

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]

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]

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

[Doris Liu]

What specific animation do you have in mind? Enter and exit?

[Archie]

Yes, I was thinking if the same thing could be done for it?

[Doris Liu]

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]

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... 🙂

[Archie]

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]

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]

Alright! Thank you very much! 😄 I try and play around and expirement with it :D

[Doris Liu]

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]

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]

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]

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]

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]

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 :D

[Archie]

@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]

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]

Alright thank you very much!

[Archie]

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]

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]

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]

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]

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]

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]

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]

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]

Alright! Thank you very much :) I really appreciate it :)