Is it worth generating a playlist file for an android music player?

Question

I'm going to write a music player for android which satisfies specific needs (which doesn't matter to my question).

I'd like to identify internal playlists with directories (inside of one main directory) on sdcard because I know my users will set up organized directories. So simply reading all audio files in a single list to let the user create playlists manually afterwards would probably be annoying.

I'm wondering whether it's worth to generate a hierarchical playlist file for this purpose.

My current plan is to run a "library inspector" when the app is started. This inspector will use a "library state" containing of hierarchical data of the form

String filename;
long   modified; // timestamp of last modification

to check the library recursive for the need of creating a new playlist file. If this matching check fails, this hierarchical file (metadata: title, artist, album, ... - for example xml) is created including a new "library state". This file should prevent to read all the metadata every single run of the app.

To make that clear: I'm searching for an efficient way to play music - but safe battery!

Since I'm new to the development of mobile apps, I'm not very familiar with battery saving. Is it that more saving to read one file instead of recursive metadata reading? Or maybe I'm about to overdo things? Do you know some strategies of established applications?

I'm very interested in your thoughts :) and I hope my bad english doesn't prevent your understanding ... I'm sorry for that.

Thank you!

Max

Answer 1

I can't answer from the perspective of using MediaStore or SQLite, but can give you some suggestions about minimizing battery usage.

• Don't use recursion. Recursion is structurally compact but awful in terms of efficiency. Every call is very expensive due to accessing stacks, possible doing context switches, etc. If the recursion is very deep, there are also issues with regards to disk usage, page swapping, etc.
• Use an efficient searching algorithm for any large list. The faster you complete what you're doing, the more the processor is idle, the deeper the power state, the more power savings.
• Gather your searches / accesses together as much as possible. For example, if you have to do 3 searches, each 1 second apart and taking .5 seconds to execute, you'll keep the processor active in a high power state for over 4.5 secs before letting it rest and drop into a lower power state. If you gather your queries together, you spend 1.5s in a high power state, and 3 seconds in a lower power state. Roughly speaking, you use <1/3 the power.
• Use on board memory as much as possible. I don't know how slow accesses to sdcards are, but it'll slow down your algorithm and possibly increase your power consumption.
• Try to setup your database entries and other data structures so that they are naturally aligned with your processor's caches (e.g. 16B aligned). That will speed up routines by a significant amount (L1 cache access might be 1 cycle, L2 10 cycles, and memory 100 cycles - these values are illustrative but ballpark). And the fast your routine, the more idle, and the greater the power savings.

My timing durations (e.g. 1 sec apart) are just for illustration purposes. There are multiple idle states and different rules for dropping into those states that can make a real illustration very complicated.

I don't know much about the power efficiency of databases. I do know there are some data bases designed for mobile and low power devices. Unfortunately, I don't recall what they are. (Don't quote me on this, but I recall something about Berkeley and real time.

PS Your English seems excellent.