Playlists still need to be tested and updated

[Benji377]

Is your feature request related to a problem? Please describe.
In almost every music player there is the ability to create playlists. I understand that's it not something we really need, but if you have a lot of songs it can be realkly hard to organize them without playlists.

Describe the solution you'd like
There are actually multiple ways to manage this. We could use online databases, but thats against our goal of keeping the app 100% offline. Another way could be to use .m3u files, but they are unreliable when songs get moved or deleted. The last, but deprecated option would be to use the Mediastore.
I already started to use the .m3u files, but somehow Android denies the permission to write such files.

Additional context
Here are a couple links that might or might not be useful:

• Github example
• Android reference
• Android Mediasession
• Exoplayer
• Exoplayer example

[squivix]

Do we have to use the M3U format for saving playlists? It seems cumbersome.

[Benji377]

We don't need to, here is what I found on how to save playlists:

• Database: Some people store playlists in databases online(recommend) or offline
• Textfile: Pure txt file -> Very simple but not compatible with other apps and paths are not dynamic
• M3U: Similar to txt files -> Has a fixed structure to add compatibility with other apps, still not dynamic because the paths of the songs are written in the file and not changed after(User moves/deletes song = playlist breaks)
• Mediastore: this was actually what I wanted to use, but then I saw that it will be deprecated and that is suggests to use m3u.

I agree on you that M3U format isn't that great. Databases aren't good either because they might become very large and "heavy". Textfiles might be a solution, but they aren't dynamic with paths. Mediastore is a mystery; I have no idea if it works or how it stores playlists.
I am open for suggestions. I will also search for other solutions myself, but I didn't have much luck till now.

What I thought with using M3U files is to read the paths from the files, see if the file exists in that destination and add it to a queue. Nice thing about M3U files is that you can export it to other apps, or save it while reinstalling the app. The m3u files are saved in the internal storage of the app, which means only the app can access it and they would be deleted when the app gets uninstalled, just like the preferences.
Mediastore playlists seem to be stored on a local database I think. Reference this

[Benji377]

The problems I am facing with every method are basically:

• Not dynamic: If a user moves the songs or deletes them, the playlist might not work anymore and we would need to update the playlist by somehow searching for the song
• Deleted on update or reinstall: Since we store files in the internal storage of the app to prevent users from manually modifying the files and corrupt them, the files will be deleted if you reinstall the app or maybe even on update.
• Storage unfriendly: The app's main goal is to stay 100% offline and that would just not be possible if decide to store playlists somewhere online
• Weak documentation: Especially with Mediastore stuff there isn't much documentation. We don't know where the playlists get stored, why it suggestst M3U files instead or how it handles playlists in general.

Main functionality of a playlist:
The playlist should have a title, display the amount of songs it contains and the total length of all the songs combined (aka how long it would take for you to listen to the whole playlist). Furthermore the playlist should be played like a queue where you can repeat it and shuffle it.
Aaand I can already hear @squivix tell me I am too ambitious hahaha. Soo actually, here is the basic part I would really like to have: Title, songcount, separate queue.

And this rises a question: Is Mediastore flexible enough to allow us do this? Is it possible to achieve this with normal textfile like files?

[Benji377]

The built-in SQL database doesn't seem too bad.
We could create one database for all playlists which would look like this:

ID	Name	Songcount	length	songs
0	Playlist1	12	0:01:03	[...]
1	Favorites	28	0:04:54	[...]

We could then retrieve the playlists by ID and update the data easily with the already available functions.
The only problem that persists is how to store Songs there. With their path?
At least this would allow us to retrieve the playlist as array and change its sorting

[squivix]

I think storing paths is fine. We'd have to check every playlist every time or we can check when the user attempts to play (similar to how we currently do with all songs).

I can do it with text files and I can do it with SQLite database. I'm not so sure I can do it with MediaStore.

The difference between the first two is that SQLite database is probably better optimized than whatever code I could put together. Also SQLite lets you add code that updates the database for different versions so we can always make it compatible. It'd need to be well-designed though. For example, the proper way to handle many to many relationships is to create separate tables and link their ids. Storing lists in a single cell is generally discouraged. Also I thinks songCount and length don't need to be stored because they can be queried or calculated. So maybe:

Playlists

ID	Name
p0	Playlist1
p1	Playlist2
p2	Favorites

Songs

ID	Name	Path
s0	Song1	/path/to/song1
s1	Song2	/path/to/song2
s2	Song3	/path/to/song3

Playlist_Song

Playlist ID	Song ID	Index
p0	s0	0
p0	s2	1
p1	s1	0
p1	s1	1
p1	s0	2

From this we can query which songs are in which playlists and where.

I don't know if it's worth doing for a small app but I feel like we'd be essentially recreating an aspect of the MediaStore. If we end up doing that, we might wanna store all songs in there so loading them is faster and we wouldn't have to go digging in the files every time. We could have a button for updating library and also reload every time a song is not found, but besides that the app would only check its database to find the path.

[Benji377]

Great! SQLite it is then

[Benji377]

I went to the Android SQL page to learn more about how to use SQLite in our app and I got welcomed with a big warning. So I followed the link and came to The Room library. I will read a little bit about it, but maybe you are better off with those things @squivix, would you suggest use it?

[squivix]

On the one hand, I've worked with SQL and SQLite before and I haven't worked with The Room.

On the other hand, writing your own code from scratch when there's a library written by more competent people than you is almost always a bad idea.

So I feel like it's best to get out of my comfort zone and try it out. Sure I'll give it a look. If it turns out as frustrating to use or understand as MediaStore, I'll switch back to SQLite from scratch.

Oh and by the way, good thing you told me now. I was just getting started with SQLite so thankfully I won't waste much progress.

[Benji377]

And good thing you told me you are working on it because I was about to test the Room library lmao. I will focus on getting the pop-up in his place then. It seems harder than I thought because the text refuses to get formatted as I wish. Afterward, I will try to make the action bar keep the theme color on night mode instead of becoming black. It looks really odd.

[Benji377]

Oh and if you are working on it, may I suggest you this plugin for Android Studio? Maybe it helps you.

[Benji377]

This has been implemented beautifully by squivix using SQL, well done. All left to do now is test it.