ankidroid
Refactor: Move deck operations business logic from DeckPicker to DeckPickerViewModel
Purpose / Description
This PR moves 8 deck-related business logic functions from DeckPicker.kt to DeckPickerViewModel.kt to improve code architecture and follow MVVM pattern properly.
Fixes
- Related #18886
Approach
Moved business logic functions to ViewModel:
1. getDeckName() - Gets deck name for rename operations
2. onSubDeckCreated() - Notifies when subdeck is created
3. rebuildFilteredDeck() - Rebuilds filtered deck with current settings
4. exportDeck() - Handles deck export requests
5. createIcon() - Prepares data for deck shortcut creation
6. disableDeckAndChildrenShortcuts() - Gets deck IDs for disabling shortcuts
7. findDeckPosition() - Finds deck position in flattened list
8. isDeckAndSubdeckEmpty() - Checks if deck and subdecks are empty
Added reactive flows for UI communication:
- flowOfExportDeck - For export requests
- flowOfCreateShortcut - For shortcut creation with ShortcutData
- flowOfDisableShortcuts - For shortcut disabling
- flowOfSubDeckCreated - For subdeck creation notifications
Updated DeckPicker.kt: - Modified methods to use ViewModel instead of direct collection access - Added flow listeners for reactive UI updates
How Has This Been Tested?
Physical Device (Redmi)
Checklist
Please, go through these checks before submitting the PR.
- [x] You have a descriptive commit message with a short title (first line, max 50 chars).
- [x] You have commented your code, particularly in hard-to-understand areas
- [x] You have performed a self-review of your own code
- [ ] UI changes: include screenshots of all affected screens (in particular showing any new or changed strings)
- [ ] UI Changes: You have tested your change using the Google Accessibility Scanner
DeckPickerTest > [0] > ContextMenu creates deck shortcut when selecting CREATE_SHORTCUT[0] FAILED
Uff, I'll resolve this tomorrow
Replying to a comment
@david-allison Not sure I get this — looks like you haven’t replied to the comments
@sanjaysargam Please don't add the Needs reviewer reply, this label is to be used by reviewers when requesting the attention of a another reviewer about something to discuss. Things will be reviewed as possible.
wait until the start of 2.24alpha
I have something else - permissions system redo - which is set to merge and also should not go in 2.23
I say, merge at will. I will branch on whatever commit is before either of those (or anything else unstable merges). You can merge first and I branch later, no need to wait or worry about coordination issues. I'm happy to figure it out and cherry pick later.
