Skip to content

feat: parallel or sequential download mode#32

Merged
Promises merged 1 commit into
Promises:mainfrom
kvmgithub:feat/download-mode-setting
Jul 15, 2026
Merged

feat: parallel or sequential download mode#32
Promises merged 1 commit into
Promises:mainfrom
kvmgithub:feat/download-mode-setting

Conversation

@kvmgithub

Copy link
Copy Markdown
Contributor

Summary

Adds a Download Mode setting (parallel or one at a time), makes queued books visible in sequential mode, and gives the in-app Cancel action the same cleanup as the notification Cancel.

What changed

  • Added a Download Mode row in Settings:
    • Parallel - up to the native concurrency limit
    • One at a time - sequential
  • In sequential mode the download service holds newly enqueued books and starts the next only when the active one finishes, fails, or is cancelled.
  • Held books are surfaced to the UI: the library list marks them as Queued, and the download action refuses to re-select a book that is already downloading or queued.
  • The summary notification shows the queued count and titles.
  • The in-app Cancel now runs the same service-side cleanup as the notification Cancel: it clears the book's notification, removes it from the active and pending queues, and advances the queue. Previously the in-app path called only the native cancel, so the notification lingered and the next queued download did not start.
  • Queued books can be removed from the queue from the library list (their Cancel action dequeues them).
  • Parallel mode is unchanged; the native semaphore still caps concurrency.

User impact

Users can choose one-at-a-time downloads; queued books are clearly marked and cannot be selected twice, and the notification lists what is still queued. Cancelling a running download from the library now also dismisses its notification and starts the next queued book, and a queued book can be removed before it starts.

Implementation notes

Sequential gating lives in the download service, composing with the native queue without changing the concurrency limit. Queued books are exposed through the same in-memory stage-progress store the library screen already polls, marked with a queued stage that is cleared when the book starts, is removed, or the queue drains. The in-app cancel path previously called nativeCancelDownload directly, bypassing the service; it now also sends a stop-monitoring signal so the service performs the notification and queue cleanup, unifying it with the notification Cancel path.

Validation

Automated validation:

  • npm run typecheck

Manual Android validation:

  • Parallel mode: multiple simultaneous downloads run at once (unchanged).
  • Sequential mode: one download runs; the next starts on completion or cancel.
  • Queued books show as Queued, cannot be re-selected, and are listed in the notification.
  • Cancelling a running download from the library dismisses its notification and starts the next queued book.
  • Removing a queued book from the library takes it out of the queue.

Simultaneous downloads always ran in parallel up to the native concurrency
limit. A new Download Mode setting chooses between parallel and one at a time;
in sequential mode the download service holds newly enqueued books and starts
the next only when the active one finishes or is cancelled, so a freed slot
advances the held queue.

Held books are surfaced to the UI: the library list marks them as Queued and
refuses to re-select them, and the summary notification shows the queued count
and titles.

The in-app Cancel action now runs the same service-side cleanup as the
notification Cancel — it clears the notification, drops the book from the active
and pending queues, and advances the queue — instead of only cancelling the
native task. Queued books can be removed from the queue from the library list.
@Promises
Promises merged commit 9c3d72b into Promises:main Jul 15, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants