https://kotlinlang.org logo
Join Slack
Powered by
Many examples have `SeekableTransitionState` with ...
# compose
z
Many examples have 
SeekableTransitionState
with just the current value specified: 
val seekingState = remember { SeekableTransitionState(BoxSize.Small) }
However, when I try to use it... it requires both 
initialState
and 
targetState
. Why is that? Imports are correct, I am using CMP 1.6.1 though (documentation states that it was added in 1.6.0). If its a version thing, can I pass in the same value as the first initial and targetState?
s
Could it be that the CMP source is lacking behind a bit here? Here’s where they use it inside androidx.navigation for example, only with the initial state https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:navigati[…]gation/compose/NavHost.kt;l=550-555?q=SeekableTransitionState And here is the function itself https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:compose/[…]mation/core/Transition.kt;l=218-220?q=SeekableTransitionState At least from the google sources
z
Thats my suspicion too. Although, if thats the current implementation I take it that Ill be fine specifying the same state for initial & target!
s
The one in google sources also is no longer experimental. I suspect they simply haven’t yet had the time to adopt the new API shape here
But as you say, they seem to just do
Copy code
override var targetState: S by mutableStateOf(initialState)
        internal set
    override var currentState: S by mutableStateOf(initialState)
        internal set
initially there in the google sources. You should be able to do the same. Or even provide a new function which does not take target state but defaults it to the initial state so that you don’t have to think about it each time
z
Yeah, that code looks perfectly fine; the CMP code does something different! I think its still worth a shot, if it fails.. at least once they catch up - it will work (famous last word) 😃
😅 1
Well, it worked 🙂
s
🎉 🎉
z
And it made me realize that predictive back animations are easy to implement, and should look nice most of the time. They just look really weird together with the animations that I use 😄
s
Seekable transitions + predictive back is definitely the wombo combo. Add in shared transitions in the mix and you get magic https://x.com/GakisStylianos/status/1776691881243553937 If you get something cool working with predictive back + this then I’d love to see it 😊
z
Oh, your tweets are a big part of why Im doing this now 😄 fist bump I havent looked into using shared transitions, mostly due to CMP, not sure if that works yet! But from what I call tell thus far, its API is very elegant and easy to use, so looking forward to diving in as soon as I can!
🥳 1
Do you have a go-to animation that you use when navigating with predictive back? Im using a stack like transition, basically sliding new content over the old; it looks good normally.. but as you might be able to guess, pressing back and having the entire screen slide down/out relative to the back progress.. is a bit weird! I might be able to create my own easing function so that the predictive back progress only animates between 1 - 0.9f until youve reached like 90% of the back event and the rest of the animation just runs normally.
s
androidx.navigation just plays the pop animation as-is so I haven’t explicitly changed anything there actually. And for lateral movements we mostly just do something like this https://m3.material.io/styles/motion/transitions/applying-transitions#a1e4273c-c23f-4ea1-b03b-b18b269a459f And when changing top level tabs we do something like this https://m3.material.io/styles/motion/transitions/applying-transitions#4a60664f-a481-4c38-845b-fa9f746647b9
z
I actually missed docs about transitions, thank you! By pop as-is, from what I can tell its just a fade? Maybe I dont understand how it all plays together, from my understanding you would then just have a fade between the different screens (in relation to your back press progress)? I havent used compose navigation ever, so not sure if thats actually the behavior seen or even wanted 😄
s
Indeed it’s a fade. And also that’s exactly it, it plays this fade animation but progresses it from 0% to 100% of what it was gonna do in sync with the back gesture. Here is what we do https://github.com/HedvigInsurance/android/blob/7e85f0db5781027e32700587c32c517454[…]ig/android/core/designsystem/material3/motion/MotionDefaults.kt -> https://github.com/HedvigInsurance/android/blob/a8e5ad2c510bae0a2414f75a00a101dec1[…]droid/core/designsystem/material3/motion/FadeThroughDefaults.kt ->
Copy code
const val DurationMedium1 = 250.0
val EasingStandardCubicBezier = CubicBezierEasing(0.2f, 0.0f, 0.0f, 1.0f)
val EasingStandardAccelerateCubicBezier = CubicBezierEasing(0.3f, 0.0f, 1.0f, 1.0f)
Which are here https://github.com/HedvigInsurance/android/blob/7e85f0db5781027e32700587c32c517454[…]dvig/android/core/designsystem/material3/motion/MotionTokens.kt
Don’t ask me where I got these from, I really don’t remember. I scoured some internal material3 code, and stuff like that. I just think that I remember that it was not all in one nice place.
z
I recognize the variable names, I think theres a thread in reddit somewhere.. and a library somewhere else, that has these 😄
So when youre in predictive back mode, the screens are just fading between each other?
s
Yes, albeit with the SNAPSHOT versions (not sure about alphas, didn’t check lately) of androidx.navigation for now. This is not stable and released yet.
z
Ah, gotcha, thats inline with my understanding of it at least. I sort of assumed the default animation does this slight shift too, similar to what Tivi (or the circuit library) does. It does not 😃
s
Yep, here it is for androidx.navigation https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:navigati[…]va/androidx/navigation/compose/NavHost.kt;l=463-479?q=NavHost And speaking of Circuit, here is a sample https://github.com/StylianosGakis/circuit/blob/10a489cebec908ef369aca4dfc594cd7745[…]src/main/kotlin/com/slack/circuit/shared/shapes/MainActivity.kt I wrote in the Circuit repo itself for predictive + shared elements, by breaking their public API of course 😅 But I was just testing what it’d take to support it there too, and the answer was not too much 😄 This sample is this UI.
z
Thats the source I was using to test it out earlier as well! I really like that youre just using the transition to animate between the pages (in circuit), thats what Id like to do as well. Seems like its important to have tighter animation values with predictive back, when Im using slideInVertically{ it } the range is just too long, and it feels really weird 😄
s
Yeap, sliding the entire screen with predictive back may be way too much movement indeed 😄 Here’s a relevant topic in the m3 transition docs https://m3.material.io/styles/motion/transitions/applying-transitions#912e549a-e239-4bfd-a87c-c24466194bd1 The “Don’t” in “Lateral”
z
Yea definitely too much movement 😅 The transition docs are a gold mine, but I wonder if theres any actual implementations for the transitions somewhere?
s
Not of all of them for sure, since the shared element ones haven’t even dropped yet. For the animation specs used I suppose the things inside m3 are what were used https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:compose/[…]MotionToken&sq=&ss=androidx%2Fplatform%2Fframeworks%2Fsupport but you gotta try and find which one is which maybe? I do not know of a place where they describe it in details tbh
z
Ultimately I stashed the code for this and reverted to my old golden animation. Will check back when I feel that all the pieces of the puzzle fit 😃 Super good info though and I appreciate the discussions around it and everything else we went into! The shared transition stuff is just 🤌🏽
🎉 1
144 Views
Open in Slack
PreviousNext
Powered by