Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow to open files with the app #108

Open
nt4f04uNd opened this issue May 5, 2023 · 0 comments
Open

Allow to open files with the app #108

nt4f04uNd opened this issue May 5, 2023 · 0 comments
Labels
enhancement New feature or request native Involves writing native code

Comments

@nt4f04uNd
Copy link
Owner

Suggestion

The main problem here is to decide how it should work.

  1. A standalone player.

It opens an independent Sweyer instance in a separate activity, with a separate audio_service and player. The main app still could be launched and interfere with the playback of a standalone one.

I already experimented with a UI for this feature, which I kept unifinished under a StandalonePlayer class.

  1. The main app is launched and a file from Intent is fed into the main player.

This breaks the paradigm of accesing all the content through the MediaStore.
In its turn, this leads to the uncertainty of what we should do with the queue, as a major problem, but certainly not limited.

But this example poses a deeper thought of how we should handle a case with different song sources in the future.
It's very likely this could happen.
For example, if the app becomes a Spotfiy/YT music/whatever else client.

Should the queue be united and allow multiple sources of songs?
Should it fundamentally allow only one source in it?
Something else?

Answering these questions should be done very carefully, since this is a major architechtural decision and could inflict very big problems down the road, if not done right.

For example YT music doesn't allow you mixing local and non-local songs.

@nt4f04uNd nt4f04uNd added enhancement New feature or request native Involves writing native code labels May 5, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request native Involves writing native code
Projects
None yet
Development

No branches or pull requests

1 participant