[criticalAY]

Note

Assisted-by: opus 5.5

Purpose / Description

Adding or cloning a note type still ran its collection work inside the dialog. This moves both into ManageNoteTypesViewModel, next to rename and delete.

• Follow-up to feat(manage-note-types): show progress from the ViewModel #22564

Fixes

• Part of architecture: support withProgress in ViewModels #19460

Approach

See commit. Add and clone now reload the list under the same progress dialog, and failures go through the screen's error state like the other operations.

How Has This Been Tested?

• New ViewModel tests: adding a stock note type, cloning one, cloning a missing note type, and progress for both
• A dialog test that adding from the dialog shows the new note type in the list (green before and after the move)

Learning (optional, can help others)

NA

Checklist

Please, go through these checks before submitting the PR.

• You have a descriptive commit message with a short title (first line, max 50 chars).
• You have commented your code, particularly in hard-to-understand areas
• 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

[github-actions]

Snapshot diff report: Previous regressions were resolved by the latest commit.

[mikehardy]

Assisted-by: grok-4.7-medium

Thanks for moving add/clone into the ViewModel — centralizing progress and errors should make this screen much easier to follow.

Checked out the PR branch, rebased cleanly onto current ankidroid/main, and did not push (reviewed GitHub head 8a7ca21690d80c057b00090f1b0c0dfb2c377e05). Locally ran buildSrc tests, lintAll / ktlintCheck / lint-rules:test, jacocoUnitTestReport, and release emulator tests on API 36 Google APIs Play 16K (emulator-5554); all green on the rebased replay.

Add and clone now run through ManageNoteTypesViewModel with a single progress dialog, and failures surface on the same error state as delete. New unit tests cover the ViewModel path.

Screenshot changes have been detected, so leaving this for a good manual look.

[criticalAY]

• @david-allison I think this review was meant for feat(export): pick the deck with the deck selection dialog #22678?

[david-allison]

LGTM, few stylistic nits

[david-allison]

extension method please. The intent isn't immediately clear

context(activity: FragmentActivity)
fun Deferred<*>.awaitCatchingTask(): Job =
    activity.launchCatchingTask { await() }

// Then, inside ManageNotetypes:

viewModel.pendingAdd?.awaitCatchingTask()

[mikehardy]

Assisted-by: Grok 4.7

Thank you — the dialog no longer owns the collection write, and the recreation tests cover both a successful add and the validation and corruption failures David asked for.

Checked out the PR branch for a clean replay at 36f6f4af; did not push. Locally ran lint, unit tests, and release emulator tests on emulator-5556 (API35_GAPI); all passed.

Add and clone now run in ManageNoteTypesViewModel under one progress op: the dialog validates the name and calls addStockNoteType or cloneNoteType, which withProgress the collection write and reload the list; pendingAdd lets a recreated activity re-await the same Deferred via awaitCatchingTask, so in-flight failures still reach launchCatchingTask for validation or corruption dialogs. Unit and Robolectric tests cover the ViewModel path, dialog wiring, error handling, and recreation for success and failure.

some acceptable findings, no action required, just leaving for posterity: the commit subject is a 70-character refactor: though behavior includes progress plus error reattachment; pendingAdd clears when the async completes, not when the new activity has shown an error (tests hold the dispatcher across the recreation gap).

Merge pending CI on a few GitHub jobs; local lanes were green on the replayed tip.