Was playing with the idea of wrapping some screen’...

# compose

[Stylianos Gakis]

Was playing with the idea of wrapping some screen’s content in an AnimatedContent block to make the transitions between content-error-loading states a bit nicer and I got a code block that looks something like this

AnimatedContent(uiState) { uiState ->
  when(uiState) {
    us Error -> { ErrorComposable() } 
    is Loading -> { Spinner() } 
    is Content -> { ScreenContent(uiState) } 
  }
}

Now thing is, when my uiState goes from being Content with some parameters, to still being content, but with some changed state, (like from Content(someState = true) to Content(someState = false) ) my AnimatedContent animation still plays, which is of course not what I am looking for here.

Is there some approach I am missing here as to how to not make AnimatedContent consider these two Content cases things that it needs to animate between?

[Stylianos Gakis]

Oh hmm, might’ve rubber ducked myself again, since looking inside AnimatedContent, it doesn’t take a key for the content by itself, but just 1 layer deeper, when using updateTransition, the transition.AnimatedContent function does seem to take a contentKey: (targetState: S) -> Any? = { it }, parameter, which should allow me to pass the same key for the cases that the AnimatedContent should consider as the same state

[Filip Wiesner]

Yes, the contentKey is definetly what you are looking for 👍 I had the same problem recently

[Stylianos Gakis]

Thanks for confirming! Trying it out atm 👀

[Filip Wiesner]

But I think I remember seeing the contentKey in regular animated content somewhere 🤔 Maybe some beta version of Compose

[Stylianos Gakis]

yeah could be, because I don’t see it ATM. Not on the latest BOM either though unfortunately, so it may be me who’s a bit behind on versions here

[Stylianos Gakis]

Yes! Did this

contentKey = { uiState ->
  when (uiState) {
    is HomeUiState.Error -> "Error"
    HomeUiState.Loading -> "Loading"
    is HomeUiState.Success -> "Success"
  }
},

And it works exactly as I wanted it to, super nice!
Maybe I could make this a bit simpler, like uiState::class in the lambda, but idk if I wanna rely on something like that after r8 runs etc.
What did you do when you had to use it?

[Filip Wiesner]

Yeah, it's fine as it is now. This is my setup

[Stylianos Gakis]

Right, should still pose no problem even after minification as they still will be distinct classes so I should worry about that I suppose.
It’s just that I read this thread the other day https://twitter.com/theapache64/status/1693527840401379491 and now I am unreasonably scared for these things 😅

[Filip Wiesner]

Yeah, I had this on production for maybe a month and no problems so far

[Alex Vanyo]

For reference, 1.5.0-alpha04 is the version that introduced the contentKey argument on the main AnimatedContent call (without having to go a level deeper to transition.AnimatedContent) https://developer.android.com/jetpack/androidx/releases/compose-animation#1.5.0-alpha04

[Stylianos Gakis]

Nice, thank you Alex!

Been slacking on updating things and am on a bit of an older version of compose ever since I've encountered this https://issuetracker.google.com/issues/291524052 basically. Now I'm reluctant to upgrade because I don't want to go through the work of copying again an entire material3 dependency just to make one internal thing not be internal anymore 🫣🫣

I'm hoping to skip upgrading until and if this is ever addressed, or until I finally take the L and put in the effort to do what I just said.