永続的な Android サービスでは、BroadcastReceivers で最終的に使用するために、静的文字列を宣言して SharedPreferences を参照するのに最適な場所はどこですか?
public final static String KEY_ENABLE_LOCKSCREEN = "key_enable_lockscreen";
以下で宣言します。
- サービス?
- アクティビティ?
- シングルトン?
永続的な Android サービスでは、BroadcastReceivers で最終的に使用するために、静的文字列を宣言して SharedPreferences を参照するのに最適な場所はどこですか?
public final static String KEY_ENABLE_LOCKSCREEN = "key_enable_lockscreen";
以下で宣言します。
次のような個別のクラスを作成するためのより良いアプローチと実践
/**
*
*/
package com.comapnyname.projectname.utility;
/**
* @author Rakesh.Jha
* All static member variable will be listed here
*/
public class MyPreferences {
/*
* @Declare all static variables here
*/
public final static String KEY_ENABLE_CODE = "0001";
}
設定を使用したいときはいつでも、次のように使用できます-
MyPreferences.KEY_ENABLE_CODE
したがって、コードを高速化するためのマネージド コードが提供されます。
シングルトン!
その方がずっときれいです。
通常、パッケージ名utilsで宣言します。
mycustom.package.com.utils
ここに例があります。
public class MyUtility{
public final static String KEY_ENABLE_LOCKSCREEN = "key_enable_lockscreen";
}
そして、それを使用するときは、次のようにどこでも参照してください。
SharedPreferences prefs = getSharedPreferences( MyUtility.KEY_ENABLE_LOCKSCREEN, Context.MODE_PRIVATE);
静的クラス以外で宣言する理由はありません。彼らは本当に定数です。それらを変更するつもりはありません (例で示したように)。シングルトンでそれらをインスタンス化するのはなぜですか? 静的クラスは、C のヘッダー ファイルのように機能します。さらに優れたトリックは、それらをインターフェイス定義に配置することです。このように、1 つのクラスに複数のインターフェイスを実装することで、定数を組み合わせることができます。メソッドを持たないインターフェイスを実装すると、定数が継承されます。
このような定数は、必要最小限のスコープ (たとえば、必要に応じてパッケージのプライベートまたはパブリック) を持つ最終的な静的文字列としてサービスに配置するのが最善だと思います。
シングルトンは完全に不要です(インスタンスは必要ありません)。
別の utils クラスは不要です。これは好みの問題かもしれませんが、関連するクラスから定数定義を分離することで得られるものはほとんどありません。それらは、他の任意のクラスからアクセスできるのと同じように、サービスからも簡単にアクセスできます。長期的には、MyService の定数がどこにあるかを覚えるのが簡単になると思います。名前を覚えておく必要がある他のユーティリティクラスもあります。
個別の utils クラスはネーミングを複雑にします。複数のサービス/ブロードキャストがあると仮定すると、すべての定数を単一の個別のクラスに入れると、名前を装飾する必要があります。つまり、複数のサービスで定数に同じ名前を明確に使用することはできません。
例えばこんな感じ。
public class PlaylistManager extends IntentService {
public static final String BROADCAST_ERROR = "@package.name@.PlaylistManager.broadcast.ERROR";
// can be referenced within this class as BROADCAST_ERROR
private void broadcastError() {
Intent broadcastIntent = new Intent();
if(broadcastIntent != null) {
broadcastIntent.setAction(BROADCAST_ERROR);
// etc.
sendBroadcast(broadcastIntent);
}
}
}
public class AudioCacheLoader extends IntentService {
public static final String BROADCAST_ERROR = "@package.name@.AudioCacheLoader.broadcast.ERROR";
// can also be referenced within this class as BROADCAST_ERROR
private void broadcastError() {
Intent broadcastIntent = new Intent();
if(broadcastIntent != null) {
broadcastIntent.setAction(BROADCAST_ERROR);
// etc.
sendBroadcast(broadcastIntent);
}
}
}
// naming pattern:
// PlaylistManager.BROADCAST_ERROR
// AudioCacheLoader.BROADCAST_ERROR
// etc.
...これよりも望ましい:
public class MyUtils {
public static final String PLAYLIST_MANAGER_BROADCAST_ERROR = "@package.name@.PlaylistManager.broadcast.ERROR";
public static final String AUDIO_CACHE_LOADER_BROADCAST_ERROR = "@package.name@.AudioCacheLoader.broadcast.ERROR";
}
public class PlaylistManager extends IntentService {
private void broadcastError() {
Intent broadcastIntent = new Intent();
if(broadcastIntent != null) {
broadcastIntent.setAction(MyUtils.PLAYLIST_MANAGER_BROADCAST_ERROR);
// etc.
sendBroadcast(broadcastIntent);
}
}
}
public class AudioCacheLoader extends IntentService {
private void broadcastError() {
Intent broadcastIntent = new Intent();
if(broadcastIntent != null) {
broadcastIntent.setAction(MyUtils.AUDIO_CACHE_LOADER_BROADCAST_ERROR);
// etc.
sendBroadcast(broadcastIntent);
}
}
}
// naming pattern:
// MyUtils.PLAYLIST_MANAGER_BROADCAST_ERROR
// MyUtils.AUDIO_CACHE_LOADER_BROADCAST_ERROR
// etc.
最初の例では、サービス クラス間でコードを簡単にコピー アンド ペーストできることに注意してください。
また、を使用していない限り、BroadcastReceivers には一意の文字列を使用する必要があることに注意してくださいLocalBroadcastManager
。
Intent 名前空間はグローバルです。インテント アクションの名前やその他の文字列が、所有する名前空間に記述されていることを確認してください。そうしないと、他のアプリケーションと誤って競合する可能性があります。
(参照: http://developer.android.com/reference/android/content/BroadcastReceiver.html )
Application
して独自のものを作成し、そこで宣言することができます。Context
ので、そこに安全に住むことができます。このクラスは、インスタンスを持つ必要がないため、静的最終変数を保持するためにシングルトンである必要はありません。クラスのAndroidデベロッパーリファレンスから:Application
グローバルなアプリケーションの状態を維持する必要がある人のための基本クラス。AndroidManifest.xml のタグでその名前を指定することにより、独自の実装を提供できます。これにより、アプリケーション/パッケージのプロセスが作成されるときに、そのクラスがインスタンス化されます。
通常、Application をサブクラス化する必要はありません。ほとんどの場合、静的シングルトンは、よりモジュール化された方法で同じ機能を提供できます。シングルトンにグローバル コンテキストが必要な場合 (ブロードキャスト レシーバーを登録する場合など)、それを取得する関数に、シングルトンを最初に構築するときに Context.getApplicationContext() を内部的に使用する Context を指定できます。
この質問は意見に基づくものであり、適切な答えはありません。