in the back handling section, I would assume if my...

# decompose

[Adam Brown]

in the back handling section, I would assume if my BackCallback didn't do anything, then the back would do nothing, the UI wouldn't go back. is that correct?

private val backCallback = BackCallback { /* do nothing */ }

[Adam Brown]

also I see it is applied in init, but I would expect to need to unregister it in a lifecycle callback, is that not needed?

[Adam Brown]

basically I'm trying to prevent the back action in certain cases

[Adam Brown]

ah, I think it's due to other back handlers being registered

[Adam Brown]

hhmmm... so i was unregistering a backhandler in onStop for a component that was getting pushed on top of in a stack. But that doesnt appear to be getting called. Are components lower down in a stack (not active) to be considered "started"?

[Arkadii Ivanov]

Unfortunately, due to the way the predictive back gesture works on Android, it's not possible to intercept the back button press. This was the case a while ago, when the back handler was returning a boolean. But I had to align the API with the AndroidX OnBackPressedDispatcher.

So you have to update the callback's isEnabled property according to your state.

[Adam Brown]

okay, so updating that state as things change, not when a back event is propagating?

[Adam Brown]

way to make things more difficult google 😛 but thats fine

[Adam Brown]

the next thing here is the started/resumed state though, this seems off to me

[Arkadii Ivanov]

Yeah! Turned out there are technical limitations on Android. There was an interesting conversation about it which explains everything https://twitter.com/ianhlake/status/1553433732329009152

[Adam Brown]

oh, nvm

[Adam Brown]

I think i discovered my state issue here

[Adam Brown]

but last question, do I really not need to worry about calling unregister ever?

[Arkadii Ivanov]

Usually you don't. It's the same as unsubscribing from Lifecycle.

[Adam Brown]

ah okay

[Adam Brown]

what I've been digging around the edges of here, is that the backhandler in Comp A always fires, but never the backhandler in Comp B. Maybe the order of operations I'm expecting is different? I would expect a bottom up propagation, so a child could steal the event first.

[Arkadii Ivanov]

That's because the component's BackHandler has the same scope as the component itself.

[Adam Brown]

if both handlers are enabled that is

[Arkadii Ivanov]

By default, back callbacks are called in reverse order. If you register a callback after creating your Child Stack, it has higher priority. Starting with Essenty 1.2.x alpha, you can specify a priority for your callback.

[Adam Brown]

oohhh

[Adam Brown]

up that was it, my init block doing the registering was lower down in the file than my call to componentContext._childStack()_

[Adam Brown]

thanks !

[Arkadii Ivanov]

Perhaps, it would be nice to have this documented. I will add this.

[Arkadii Ivanov]

Add this to the doc. Thanks. https://arkivanov.github.io/Decompose/component/back-button/#callback-order

[Adam Brown]

looks great, thanks!