TargetSdkVersion 34 replaces onBackPressed() with OnBackInvokedCallback about simple-stack HOT 4 CLOSED

It seems like ScopedServices.HandlesBack has now been superseded by the OnBackPressedCallback (any service can just use Google's callback instead of simple stack's one). Maybe it's time to deprecate that functionality and suggest to use the official callback solution instead?

That gets rid of the scoped services issue. For the rest, extra boolean canGoBack() method could be added to the Navigator. Then OnBackInvokedCallback can be implemented by installing a CompletionListener and enabling/disabling callback based on the result of the canGoBack method.

from simple-stack.

I have a sincere dislike for the "new" notifications UI in Github. Back in the day, I never had to bulk-process 5 pages of notifications before I get important ones...

Anyways, the official callback alone wouldn't work, as a scoped service lives within the non-config scope. To intercept back in a scoped service, Simple-Stack will need to intercept it and implement the same dispatch behavior in ScopeNodes by default so that if either ScopeNode has an active back handler that wants to handle back, it would get it in "VM layer".

I had been trying to think of a way to introduce a new "back mode" to opt-in into the ahead-of-time model, so that there is a migration path and transition process + the original Back processing made perfect sense until suddenly Google changed the way it works with targetSdkVersion 34.

But I admit, this is getting more and more important to handle. Considering we use Simple-Stack in our apps, it will be done eventually.

from simple-stack.

Huh, is there a use case where a non-config-scope service would need to intercept back? It seems like these two shouldn't mix.

from simple-stack.

I actually did it with only "breaking" ScopedServices.HandlesBack and it's opt-in.

Eheheheh

from simple-stack.