docs(openspec): archive android-auto-local-music-paging
Merges its delta requirements into the android-auto-media base spec. This closes out Phase-1 polish for local music; Phase 2 (metadata, sort/filter, real art) and Phase 3 (subfolder scoping, shuffle) remain the only planned future work for this feature.
This commit is contained in:
@@ -236,16 +236,63 @@ Selecting a `pista:<id>` item MUST resolve to the corresponding `PistaLocal` and
|
||||
- WHEN resolution fails
|
||||
- THEN playback does not start and no unhandled exception propagates from the handler
|
||||
|
||||
### Requirement: Local Music Folder Item Cap
|
||||
### Requirement: Local Music Folder Item Cap and Paging
|
||||
|
||||
A local-music folder (root or nested) whose immediate children exceed `_maxItemsPorCarpeta` (50) MUST be capped to that limit rather than returning unbounded results; pagination is out of scope for this delta.
|
||||
A local-music folder (root or nested) whose immediate children exceed `_maxItemsCarpetaLocal` (50) MUST NOT silently truncate the excess items. `getChildren` MUST return at most 50 items for the requested page, followed by a trailing non-playable, browsable "more" item whenever additional items remain beyond that page. Selecting the "more" item MUST invoke `getChildren` again and reveal the next page of up to 50 items, continuing until every item in the folder has been reached; no item may be permanently unreachable. A page that exhausts the folder's remaining items MUST NOT include a "more" item.
|
||||
(Previously: folders exceeding 50 immediate children were capped to 50 with the remainder silently dropped; pagination was explicitly out of scope.)
|
||||
|
||||
#### Scenario: Folder exceeds the item cap
|
||||
|
||||
- GIVEN a picked or nested local-music folder contains more than 50 immediate children (subfolders and/or tracks combined)
|
||||
- WHEN `getChildren` is called with that folder id for the first page
|
||||
- THEN exactly 50 items are returned for that page, followed by a trailing "more" item
|
||||
- AND no error or crash occurs, and no item is permanently unreachable
|
||||
|
||||
#### Scenario: Folder has exactly 50 items (boundary)
|
||||
|
||||
- GIVEN a local-music folder contains exactly 50 immediate children
|
||||
- WHEN `getChildren` is called with that folder id
|
||||
- THEN at most 50 items are returned, consistent with the existing `_maxItemsPorCarpeta` cap applied to station folders
|
||||
- AND no error or crash occurs as a result of the truncation
|
||||
- THEN all 50 items are returned
|
||||
- AND no "more" item is appended, since nothing remains to reveal
|
||||
|
||||
#### Scenario: Folder with 51-100 items pages in two steps
|
||||
|
||||
- GIVEN a local-music folder contains between 51 and 100 immediate children
|
||||
- WHEN `getChildren` is called with that folder id
|
||||
- THEN the first page returns 50 items plus a trailing "more" item
|
||||
- AND WHEN the user selects that "more" item, `getChildren` is invoked again
|
||||
- THEN it returns the remaining items with no further "more" item, since that is the last page
|
||||
|
||||
#### Scenario: Folder with 100+ items chains across 3+ pages
|
||||
|
||||
- GIVEN a local-music folder contains more than 100 immediate children
|
||||
- WHEN the user repeatedly selects each returned page's "more" item
|
||||
- THEN each intermediate page returns 50 items plus a trailing "more" item
|
||||
- AND the final page returns only the remaining items with no "more" item
|
||||
- AND every item in the folder is reachable through this chain, none dropped
|
||||
|
||||
#### Scenario: Only the requested page's items are resolved into MediaItems
|
||||
|
||||
- GIVEN a local-music folder contains more than 50 immediate children
|
||||
- WHEN `getChildren` is called for a given page
|
||||
- THEN only that page's items (at most 50, plus the "more" item) are constructed into full `MediaItem`s (art, resolved title)
|
||||
- AND items belonging to pages not yet requested are NOT constructed into `MediaItem`s as part of that call
|
||||
|
||||
### Requirement: Local Music Folder Friendly Name Display
|
||||
|
||||
The settings UI MUST display a human-readable label for the picked local-music root folder instead of the raw SAF `content://` tree URI. If a friendly name cannot be derived from the persisted URI, the settings UI MUST fall back to a clear, non-empty label rather than showing a broken, blank, or raw-URI value.
|
||||
|
||||
#### Scenario: Folder picked and friendly name derivable
|
||||
|
||||
- GIVEN a local-music root folder has been picked and its URI persisted
|
||||
- WHEN the settings screen displays the current folder
|
||||
- THEN it shows a human-readable name derived from the folder, not the raw content URI
|
||||
|
||||
#### Scenario: Friendly name cannot be derived
|
||||
|
||||
- GIVEN a persisted local-music root URI whose friendly name cannot be derived (e.g. a malformed or unexpected SAF documentId shape)
|
||||
- WHEN the settings screen displays the current folder
|
||||
- THEN it falls back to a non-empty, non-broken label instead of an empty or corrupted value
|
||||
|
||||
### Requirement: Playable Item Metadata
|
||||
|
||||
|
||||
Reference in New Issue
Block a user