-1

私の音楽アプリは永続的に保存されているデータを参照しています。現在、すべてがテキストファイルとして保存されています。

お気に入り-単一のテキストファイル配列。アプリが起動し、テキストファイルを読み取り、メモリに保存します。ListViewが展開されると、配列がチェックされます。配列が変更されると、テキストファイルが書き換えられます。

最終再生-単一のテキストファイル配列リスト。5秒ごとに更新されます。再生された曲の履歴を保持して、ユーザーが任意のアルバムに戻って位置を再開できるようにします。

プレイリスト-現在、リストごとに1つずつ、個別のテキストファイル。必要に応じてファイル名から生成されたプレイリストのリスト。各プレイリストテキストファイルには、配列リストが含まれています。読み取り必要に応じて書き込み。

最も再生された-単一のテキストファイル配列リスト。再生した曲ごとに1回更新されます。

このデータがデータベースに変更する必要があるのか​​、それとも私が正しいアプローチを取っているのか疑問に思っています。データを追加する必要があるとは思わないので、これが最も必要なデータになるはずです。

アドバイスをお願いします！

4

3 に答える 3

3

SharedPreferenceにテキストファイルを保存でき、うまく機能するはずです。

大量のデータを保存する必要がある場合は、データベースが望ましい。文字列を解析するよりも、データベースを使用する方が最適です。

于 2012-09-23T07:58:03.523 に答える
2

正しいアプローチは、お気に入りなど、表現したいものごとにクラスを作成することです。各クラスには、save（）メソッドとreload（）メソッドがあります。重要なのは、残りのコードを変更することなく、save（）メソッドとreload（）メソッドで基盤となるストレージメカニズムを変更できることです。将来、Dropboxへの保存を有効にしたいとします。これらのメソッドを変更するだけで、アプリは機能します（OK、Dropboxアカウントの詳細を取得するには何かを追加する必要がありますが、アイデアは得られます）。

さらに進んで、ロードおよび保存するためのインターフェースを定義することができます。そのインターフェースは、保存とロード以外の責任を負わない単一のクラスを使用できます。コンシューマークラスとプロバイダークラスがインターフェイスに準拠している限り、アプリを再コーディングしなくても、組み合わせて使用​​でき、まだ発明されていないストレージアプローチを実装することもできます。ストレージアプローチを変更した場合、いつでも使用できるクラスは1つだけです。

class StorageManager(){

     enum DataType {Favourites, MostPlayed, PlayList };

     ...

     public save(DataType dataType){

           if (dataType == DataType.Favourites){

              saveFavouritesToDB();

           ...

           ...

}

このアプローチにより、最大限の柔軟性、将来の保証、および保守性が向上します。

于 2012-09-23T08:13:07.227 に答える
1

データベースを使うほうがいいと思います。

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.

于 2012-09-23T08:09:43.553 に答える