Question

I have a simple approach question about Android design.

I envision a scenario where I provide a service and an activity. Both the service and the activity need to read/write to the same data. The basic idea is a live playlist: the service that is playing the list “pops” a song from the list when it’s done playing, but the the app can also edit the list by adding or deleting songs.

I considered using a ContentProvider for the actual playlist, thinking it would be simple, but all ContentProvider examples I can find on the internet seem morbidly overcomplicated or involve solely SQLite.

Another approach would be to keep a simple file in my resources, and access that from both the service and the app.

Which approach seems to be better here? If I should indeed use a ContentProvider, can someone please direct me to the simplest possible implementation, preferably not involving SQLite? From my prior looks, ContentProvider seems overcomplicated for my simple purpose.

Thanks for any opinions!
-Chase

Answer 1

A ContentProvider may persist the data it’s entrusted with however it likes. Typically, that means SQLite, because the mapping to the ContentProvider interface is intuitive.

However, as long as your ContentProvider implements the insert(), update(), delete() and query() operations, (or implements as much as the app that uses the provider needs to have implemented to do it’s job) you can persist the data that goes in and out using whatever mechanism you like. Feel free to store it in a SQLite database, a file, or whatever.

Just keep in mind that your ContentProvider may be subject to being killed and restarted, maybe even being garbage collected and re-constructed later, so you need to use something that’s robust against the class going away and being reinitialized.

In your case, you probably don’t care about persisting across reboots (who cares about the playing music list being there after you reboot) so some sort of list in a static variable ought to be sufficient.