BackPressDispatcher callback wrong order
See original GitHub issueCallback registered in a component gets called only after the system onBackPressed
Also nested routers stopped working, which might be related to this issue
Looks like a regression from 0.1.0, because the same code works on that version
Issue Analytics
- State:
- Created 3 years ago
- Comments:5 (5 by maintainers)
Top Results From Across the Web
OnBackPressedCallback is being called, but app is not going ...
However, I have noticed that the addCallback() for the fragment must be called in onResume(). If I add prior to this lifecycle callback,...
Read more >OnBackPressedDispatcher - Android Developers
Trigger a call to the currently added callbacks in reverse order in ... if onBackPressed is called when hasEnabledCallbacks returns false.
Read more >BackPress handling in Android Fragments, The old and the new!
Now the fragment can respond to BackPress events and do something and based on if the event was consumed or not they can...
Read more >Navigation Component — Common issues we can face
I'd suggest to add callback to BackPressedDispatcher by giving viewLifecycleOwner since this will ensure that the callback will only be added ...
Read more >NullpointerException in NavigationUI.kt [232348785]
handleCallback (Handler.java:900) at android.os. ... We fixed this erroneous use of back press dispatcher in the activity and just relied ... findNode(item.
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
So both cases (nested routers and “whatever is in
backPressedDispatcher.register
in theTodoEditImpl
doesn’t get executed when doingunregister
inonDestroy
”) are because of the wrong iteration order of the registered handlers. This regression was introduced in version0.1.1
. This is now fixed via 9103261ccfdb33e9c64fce3eb459d793e45a4968.The case “without
unregister
ing it does get called, but only after navigating back” is because of a memory leak, which was there for a long time actually. This is now fixed via fcbfa4bb00676ce2269d4f549b47abace65e2392. So there is no need tounregister
handlers, unless you really need.Thanks! I will fix it.