現在開発中のプロジェクトでは、多くの構成設定があります。のようなもの
- 目覚まし時計
- サーバーから取得するアイテムの量
- 最小位置などのLocationManager整数
これらはすべて静的finalであり、値に対応するクラスにすべて含まれています。
私の質問は、これらすべての値を単一の静的クラスに移動することに問題はありますか?
私の考えでは、アプリのテストと調整に関しては、管理が容易になると思います。
@Snicolasの答えに基づいて...
コード(ファイルまたはデータベース)の外で CONFIGURATION 設定を保持する必要があります。ただし、値が必要になるたびにその構成を「読み取る」べきではありません。これは非効率的です。
クラスを使用して構成 (つまり、AppSettings) を管理することをお勧めします。静的にすることは、シングルトンのようなアクセスを提供する 1 つの方法です。C# と ASP.NET では、Web アプリは静的クラスのインスタンスを 1 つだけ保証するため、異なるユーザーからの関連のない複数の要求がまったく同じ静的値を共有します。
しかし、あなたの場合(「android」というタグが表示されます)、Javaを使用する場合、最善の策はSingletonアプローチかもしれません。Java でガベージ コレクションがどのように機能するかはわかりませんが、シングルトンを使用して、設定の唯一無二のインスタンスを確保する必要があると思います。シングルトンは、インスタンスが存在することを確認し (存在しない場合は作成し)、それを呼び出し元に提供します。
これにより、アプリの実行中に構成値を変更する機能のサポートが容易になる場合もあります。定期的に設定の変更を「監視」できます。
私は Java の専門家ではありませんが、この問題を処理するためのライブラリがまだなかったとしたら、驚くことでしょう (そうではありません)。
アラーム時間について言及したように、定数について話しているのではないと確信しています。
専用クラス内で静的フィールドのみを使用する場合の問題は、デバイスがメモリ不足になっている場合にクラスがガベージ コレクションされる可能性があることです。その場合、それらは単に失われ、再度使用するときにリセットされます。
したがって、保存するデータの量に応じて、ファイルまたはデータベースに永続化することを検討する必要があります。SharedPreferences は、少量のデータに役立ちます。それ以外の場合は、データベースの使用を検討してください。これははるかにスケーラブルなソリューションであり、アクセス時間はより大きなデータ セットに適しています。
Rails の世界では、構成情報を遅延ロードしてキャッシュする構成モデル クラスを実装することをお勧めします。構成情報は、単純な 2 列 (キーとシリアル データ値) のテーブルまたは (頻度は低いですが) フラットにシリアル化された形式で永続的に格納されます。ファイル。構成エディターは、このモデルの単なるビューです。
これは、Android でも良い解決策になるはずです。
別のアイデアは、これらの定数をproperties
ファイルに保存することです。そして、必要なときに定数をロードします。http://viralpatel.net/blogs/loading-java-properties-files/
便利だと思うなら、それは良い習慣です。