Android txt files v's database

Question

My music app is referencing persistently stored data. All are currently stored as text files:

Favorites - single text file array. App starts, reads the text file, stores in memory. Array is checked when ListView is expanded. If array changes text file is rewritten.

Last Played - single text file array list. Updated every 5 seconds. Retains the history of the played songs to allow the user to return to any album and resume position.

Playlists - currently individual text files, one for each list. List of playlists generated from file names when required. Each playlist text file has array list inside it. Read Write when required.

Most Played - single text file array list. Updated once per song played.

I am wondering whether this data would warrant the need to change to a database, or whether I have taken the right approach. I don't foresee the need for adding additional data so this should be the most I would need.

Advice please!

have a look at my [answer](http://stackoverflow.com/a/9141116/996493) for brief information on **txt files v's database**. — Lucifer, Sep 23 '12 at 08:07

Anurag Ramdasan · Answer 1 · 2012-09-23T08:04:09.640

3

You can store the text files in SharedPreference and it should work well.

Database if preferable if a lot of data needs to be stored. Using a database is more optimal than parsing a string.

edited Sep 23 '12 at 08:04

answered Sep 23 '12 at 07:58

Anurag Ramdasan

4,189
4
31
53

Simon · Accepted Answer · 2012-09-23T08:35:28.263

The correct approach is to create a class for each of the things you want to represent, e.g. favourites. Each class has a save() and reload() method. The point is that you can change the underlying storage mechanism in the save() and reload() methods without having to change the rest of your code. Imagine in the future, you want to enable saving to Dropbox. You would simply change these methods and your app would just work (OK, you'd need to add stuff to get Dropbox account details but you get the idea).

You could go further and define Interfaces for loading and saving. That interface can use a single class responsible for nothing except saving and loading. As long as any consumer and provider classes adhere to the interface, you can mix and match, and even implement storage approaches yet to be invented, without recoding your app. You only have one class to work with if, and whenever, you change your storage approach.

class StorageManager(){

     enum DataType {Favourites, MostPlayed, PlayList };

     ...

     public save(DataType dataType){

           if (dataType == DataType.Favourites){

              saveFavouritesToDB();

           ...

           ...

}

This approach gives you maximum flexibility, maximum future proofing and better maintainability.

score 1 · Answer 3 · answered Sep 23 '12 at 08:09

I think it would be better to go with Database.

The database should provide you with some optimizations, performance improvements and basically you don't have to reinvent the wheel (doing read / write operations on the disk, use some buffers before rewriting, and the like).

Plus, I think you will love the way all code will be organized and split into its own layers once you start using this way.

Android txt files v's database

3 Answers3