https://kotlinlang.org logo
Join Slack
Powered by
Looking at the `PredictiveBackHandler` in the CMP ...
# compose
s
Looking at the 
PredictiveBackHandler
in the CMP sources here, they mention that one should "Use NavigationEventHandler instead". However I do not see a way to setup that in a CMP context while still being able to get a hold of the progress percentage of the predictive back etc. What is it that I am missing here?
i
cc @Konstantin Tskhovrebov
k
Together with CMP 1.10 there will be published a new library: NavigationEvent https://developer.android.com/reference/androidx/navigationevent/NavigationEvent This is a multiplatform analog of the Android BackHandler
Before 1.10 we supported 
PredictiveBackHandler
on non-android just for Nav2 iOS navigation animation
So, if you need to handle predictive back, the NavigationEvent is what you need
s
Alright so the easiest path from our perspective is to keep using the old 
PredictiveBackHandler
since we're using Nav2 already anyway. And then wait for CMP 1.10 to drop which will have support for predictive back using the new APIs and migrate to that? When that happens, I will assume that you will want it to work with both nav2 and nav3 right?
k
in CMP 1.10 
PredictiveBackHandler
is migrated to NavigationEvent already
s
Right, is that the function I am linking to in the original message? The one with the @Deprecated annotation?
k
yes
s
Okay so the suggestion is to just ignore the deprecation notice, and I assume a new function with the new name will come sometime in the future which will also just use 
NavigationEvent
internally?
I haven't tried if it works yet, I just saw the 
@Deprecated("Use NavigationEventHandler instead")
notice at the top so I came here asking 😄
k
you are supposed to use this one
s
Aha hm, I think I just didn't understand how to use this new api then, I'm not sure where I'd be getting the flow updates on the progress etc. I'll go back to the android docs perhaps they show that there.
i
The Compose API is much more just reading state directly: you create one via 
rememberNavigationEventState()
, pass that to 
NavigationBackHandler
to get completion signals, then read the 
transitionState
directly to get Compose State for the progress, etc.
s
Is the idea that a higher level API which looks more like the old one will be in place at least for the common case? Or are you trying to move away from that approach to let people use the new apis and potentially have more control over what they're doing? And by the old API I mean just calling smth like one predictive back composable and getting the progression flow inside its lambda.
i
No, the old API is actively terrible and can't be fixed ever (it is a race condition with Compose itself): https://issuetracker.google.com/issues/384186542#comment22
👍 1
s
Alright that is great! In that case I do think some samples linked in the docs of the 
NavigationEventHandler
function would go a long way. Being linked to that as a deprecation replacement is good, but then without for example knowing about this m3 impl, I don't think I would've easily (if ever) figured it out myself.
plus1 1
k
image.png
thank you color 1
i
The whole point of the 
transitionState
being State is that you don't need to use LaunchedEffect in many cases, since many of the APIs you'd want to trigger are state based also
a
Good thing this thread exists. Migrated over my predictive back dialog wrapper and a stepper flow that relied on predictive back, seek-able transitions, and old back (for irrecoverable steps) into the new system. Very interesting API surface, it slimmed down some of the code written, feels a little more ergonomic to compose. Just different 🙂
Also, let me use some newer kt features too like guarded when for that irrecoverable step system.
138 Views
Open in Slack
PreviousNext
Powered by