Fix onBackPressed() deprecation In Card Browser #17594
Conversation
david-allison
added
the
Needs Author Reply
There was a problem hiding this comment.
The goal of the new predictive back navigation is to have distinct back callbacks for any actions you may want on BACK pressed and to enable/disable those callbacks dynamically so the system knows ahead of time if you are managing the back action or the system should handle it(and show animations).
Using OnBackPressedCallback and permanently have it enabled is equivalent with the current onBackPressed() so the changes in this PR are not an improvement. I would rather keep the deprecated onBackPressed callback present because it stands out as needing to be fixed, instead of the callback which is going to make it harder to see there's an issue.
|
Hi David, I will address the review points |
Prince-kushwaha
force-pushed
the
deprecation
branch
from
7487ddf to
08e0bf6
Compare
david-allison
added
Needs Review
and removed
Needs Author Reply
There was a problem hiding this comment.
I don't feel this code matches the logic of the previous implementation. It feels like it should be the following (please disagree, you're closer to the code than I am)
- If the drawer is open, the drawer should take prioirty
- If multiselect is open, it should be closed
If neither happen, there shouldn't be an active back dispatcher, and the activity should close normally, with the provided result set somewhere before the back button was pressed (fail + reload required should be the default).
A test here would also be great, regarding the exit + exit intent.
| val data = Intent() | ||
| // Add reload flag to result intent so that schedule reset when returning to note editor | ||
| data.putExtra(NoteEditor.RELOAD_REQUIRED_EXTRA_KEY, reloadRequired) | ||
| closeCardBrowser(RESULT_OK, data) |
There was a problem hiding this comment.
This seems... unusual. It feels like it shouldn't be in the callback and should be the default of pressing 'back', unless there's documentation to disagree.
| updateBackPressedCallBackMethodsStatus( | ||
| isDrawerOpen = true, | ||
| isInMultiSelectMode = false, | ||
| ) |
There was a problem hiding this comment.
I don't get why these are combined. It would make more sense for me that opening the drawer is responsible for the drawer callback, and that opening multiselect is responsible for the multiselect callback
Then the order in which the callbacks are applied affects the action which is reversed first.
Purpose / Description
Fix onBackPressed() deprecation In Card Browser
Fixes
How Has This Been Tested?
Physical Device
Checklist
Please, go through these checks before submitting the PR.