Skip to content

Add selectable download storage location with embedded song metadata#951

Open
agupta07505 wants to merge 4 commits into
ArchiveTuneApp:devfrom
agupta07505:feat/download-to-localStorage
Open

Add selectable download storage location with embedded song metadata#951
agupta07505 wants to merge 4 commits into
ArchiveTuneApp:devfrom
agupta07505:feat/download-to-localStorage

Conversation

@agupta07505

Copy link
Copy Markdown

Pull Request

Summary

Adds a selectable downloaded-song export location under Settings > Storage. New completed downloads are exported as locally accessible audio files named SongName - ArtistName.ext. Supported metadata is embedded directly into the exported audio file.

Linked Work

  • Closes:
  • Related:

Change Type

  • Feature
  • Bug fix
  • UI / UX
  • Performance / memory
  • Playback / Media3
  • Lyrics / provider integration
  • Search / YouTube / network data
  • Local library / Room database
  • Widgets / notification / shortcuts
  • Settings / preferences / DataStore
  • Discord / Last.fm / ListenBrainz / external integration
  • Localization / strings / fastlane metadata
  • Build / Gradle / CI / release packaging
  • Dependency update
  • Documentation only

Affected Surfaces

  • :app
  • :core
  • :lyrics
  • :lastfm
  • :canvas
  • :shazamkit
  • :spotifycore
  • Other:

Screenshots / Recordings

Before After
before after

Video Link:

refer-this-video.mp4

Behavior Notes

Users can open Settings > Storage > Downloaded songs > Select location and choose a folder using Android's system folder picker. Completed downloads are exported to the selected folder as normal audio files named SongName - ArtistName.ext; if no folder is selected, the app falls back to its internal exported songs folder. Metadata is embedded into supported audio formats where possible, and no new .json sidecar file is created.

Architecture Checklist

  • The change preserves UDF flow: UI -> ViewModel -> UseCase/domain -> Repository/data.
  • Screen state is represented structurally with Loading, Success, Empty, and Error where this PR introduces or changes screen state.
  • Composables receive immutable, UI-specific domain models instead of raw Room, network, or service entities.
  • Business work is not triggered directly from composition.
  • Exceptions are surfaced through explicit state or result types instead of being swallowed.
  • No runBlocking is introduced in app execution paths.

Compose / Material Checklist

  • UI state is hoisted out of composable layout code.
  • Reactive state is collected with collectAsStateWithLifecycle().
  • New UI models are annotated with @Immutable or @Stable.
  • Lazy layouts use stable key values and explicit contentType.
  • Non-primitive constants, structural lambdas, and allocation-heavy objects in hot paths are remembered.
  • Rapidly changing inputs such as scroll, gesture, animation, or playback progress use derivedStateOf where appropriate.
  • UI strings come from stringResource() and duplicated visible strings on the same screen are avoided.
  • Interactive elements keep a minimum 48dp touch target.
  • Material 3 / Material 3 Expressive tokens are used for color, typography, shape, and motion instead of hardcoded UI values.
  • Edge-to-edge layouts handle and consume WindowInsets correctly when this PR changes screen layout.

Concurrency / Performance Checklist

  • Business coroutines are scoped to viewModelScope or an existing lifecycle-owned application/service scope.
  • Disk, database, network, parsing, and heavy mapping work is dispatched to Dispatchers.IO or Dispatchers.Default.
  • Cancellation is handled explicitly where long-running work, playback, downloads, sync, lyrics fetching, or recognition is involved.
  • The change avoids blocking the main thread.
  • The change avoids unnecessary allocations in recomposition loops, playback loops, polling loops, and provider parsing paths.
  • Large lists, images, lyrics payloads, and network responses are bounded, streamed, cached, paged, or mapped off the main thread as appropriate.

Data / Persistence Checklist

  • Room entity, DAO, or database changes include a schema update under app/schemas.
  • Database migrations preserve existing user data and fail clearly when migration is impossible.
  • DataStore or preference-key changes are backward compatible.
  • Network DTOs remain isolated from UI models.
  • Provider responses handle missing, malformed, regional, or rate-limited data without crashing the app.

Playback / Integration Checklist

  • Media3 playback, queue, cache, and service behavior remains stable across foreground, background, notification, and process recreation paths.
  • Audio focus, notification controls, widgets, shortcuts, and media session actions are considered when playback behavior changes.
  • External integrations handle absent credentials, revoked auth, network failure, and API changes.
  • Native, AAR, or ABI-sensitive changes account for mobile/tv and universal, arm64, armeabi, x86, and x86_64 variants.

Localization / Assets Checklist

  • User-facing strings are added to the base resources and translated resources are updated or intentionally left for translation follow-up.
  • Unused string resources, drawables, and metadata are removed when replaced.
  • Image assets have explicit display dimensions and are decoded at the displayed size.
  • Fastlane metadata, screenshots, icons, or release text are updated when user-facing store behavior changes.

Privacy / Security Checklist

  • No secrets, keys, tokens, keystores, signing files, private certificates, or local machine paths are committed.
  • Logs do not expose access tokens, cookies, auth headers, user identifiers, listening history, or local file paths.
  • New network calls are justified by the feature and use existing client, proxy, timeout, and error-handling patterns.
  • User data remains local unless the PR explicitly documents the integration and consent path.

Verification

  • Android Studio sync: Not run.
  • Manual device/emulator verification: Not run.
  • UI screenshot/recording attached: Not attached.
  • Accessibility or touch-target review: Settings row uses existing preference component behavior.
  • Regression areas checked: Download completion export path, selected-folder DataStore preference, file naming, embedded metadata path.
  • CI expectation: assembleGmsMobileUniversalDebug should pass after the Kotlin receiver fix in DownloadedSongExporter.kt.

Reviewer Focus

Please review StorageSettings.kt for the folder picker UX and persisted URI permission handling, DownloadUtil.kt for completed-download export hooks, and DownloadedSongExporter.kt for file naming, selected-folder export behavior, and embedded metadata writing.

Release Notes

Downloaded songs can now be exported to a folder you choose, with metadata saved inside supported audio files.

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.

1 participant