K2GO-382 fix(ui): deep-op notifications return to the op screen; run-in-background lands on Home - #556
Merged
Merged
Conversation
…in-background lands on Home Tapping a deep-op foreground notification opened a bare LibraryActivity, which fell back to the last tab (Settings) instead of the running op's screen; opening LibraryActivity mid-op also fights the boot gate. Run in background did a bare finish(), popping to whatever launched the screen instead of Home. Add OpReturnNavigator: the single owner of the op -> its progress screen mapping. It is stateless -- forActiveOp reads the existing run-state repositories (module queue, deep-op), which stay the source of truth for what is live. Notification callers wrap a per-op intent with notify() (one flag policy; also supplies the NEW_TASK clone was missing). - DeepOpService (backup/restore): -> the backup/restore job screen. - InstallService (ongoing): -> install progress (EXTRA_INSTALLING). - CloneShareService: -> the clone tab (now with NEW_TASK). - DashboardRebuildService + Zim/Books/KolibriSeedService: routed through the navigator (behavior unchanged; the reference pattern now shared). - LibraryActivity relaunch re-route: now calls forActiveOp, so the which-op -> which-screen logic lives in one place instead of duplicated here. - SetupProgressActivity Run in background: goHome(false) -- lands on Home and keeps the download sessions running (was finish()). Part C (setProgress on the notification) is deferred: it depends on the progress model (T2/T3). Compiles clean.
…ead home() Two-pass review of the deep-op notification change: - install() no longer sets EXTRA_INSTALLING. That flag forced LibraryActivity.installing=true, which suppressed the !installing module-queue re-route, so a proot/module install's notification tap stranded on the boot gate instead of the install index. A bare LibraryActivity is correct: a rootfs install is detected by InstallProgressRepository.isRunning(); a module install is forwarded by forActiveOp. - Remove OpReturnNavigator.home(): it was unused (Run-in-background uses SetupProgressActivity.goHome) and was a second builder of the leave-to-Home intent -- the duplicated truth the one-source refactor set out to remove.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Tapping a deep-op foreground notification opened a bare LibraryActivity, which
fell back to the last tab (Settings) instead of the running op's own screen;
opening LibraryActivity mid-op also fights the boot gate. "Run in background"
did a bare finish(), popping to whatever launched the screen instead of Home.
Intent mapping. Stateless -- forActiveOp reads the run-state repositories
(module queue, deep-op), which stay the source of truth for what is live.
notify() wraps a per-op intent with one flag policy (and supplies the NEW_TASK
clone was missing).
-> LibraryActivity (rootfs progress / module re-route); clone -> the clone tab;
dashboard rebuild + kiwix/books/kolibri downloads -> their existing screens,
now sharing the one mapping.
"which op -> which screen" logic lives in one place instead of duplicated.
keeps the download sessions running.
Part C (setProgress on the notification) is deferred -- it depends on the
progress model (T2/T3).
Verification
Device (OnePlus, arm64): tapping the notification for a content download, a
backup, and a restore each returns to that op's own progress screen (was
Settings); "Run in background" lands on Home and the download keeps running.
Two-pass review applied (fixed a module-install routing regression and removed a
dead duplicate helper).