5

私が管理しているいくつかのコードで、共有設定変更リスナーを登録する 2 つの異なる方法に気付きました。

(1) 登録されたメンバー関数を含むクラスがSharedPreferences.OnSharedPreferenceChangeListenerを実装する単純なアプローチ。

preferences.registerOnSharedPreferenceChangeListener(mImageView);

(2) 登録されたメンバー関数を含む可能性のあるクラスが何らかの理由でSharedPreferences.OnSharedPreferenceChangeListenerを実装しないことを好み、代わりにこのリスナー専用のまったく新しいクラスを定義してインスタンス化することを選択する間接的なアプローチ:

SharedPreferences.OnSharedPreferenceChangeListener mPreferencesListener = 
  new SharedPreferences.OnSharedPreferenceChangeListener() {
    public void onSharedPreferenceChanged(SharedPreferences prefs, String key) {
      // do here what's needed to do
    }
  };


....

preferences.registerOnSharedPreferenceChangeListener(mPreferencesListener);

どちらもうまく機能しますが、今は疑問に思っています:一方のアプローチが他方よりも好ましいですか?

これら 2つのアプローチのうちの 1 つだけを実際に使用できる状況はありますか?

4

1 に答える 1

2

これは実装次第です。保守性の観点から、一部の人々は自分の意図に対して何らかの方法でより良いと感じるかもしれませんし、一部の人々は読みやすさ、自然医学などをさらに考えます.

一方、もちろん、リークやガベージ コレクションの問題を防ぎたい場合があります。作成されたメンバーmPreferencesListenerが、いくつかの問題で実行される可能性のある囲んでいるインスタンス メソッドのいずれかにアクセスしている場合、善良な市民として、それを知った後でリスナーを登録解除する必要があります。それら（onPause、onDestroyなど）を使用せず、メンバー内部クラスの代わりに静的内部クラスを選択し、匿名およびローカル内部クラスが囲んでいるインスタンスメソッド/プロパティにアクセスする場合は注意してください。

最後に、今のところSharedPreferencesImplはリスナーにWeakHashMapを使用していることに言及する価値があります。

于 2012-08-25T19:08:48.413 に答える