5

基本的に設計上の質問-PreferenceActivityそれを実装するOnSharedPreferenceChangeListener必要があるのか​​、それとも別のクラスでこの機能を定義する必要があるのか​​-内部クラスで言うのですか?他のアプローチよりも一方を好む理由はありますか?

また、リスナーをどこに登録する必要がありますか?つまり、ドキュメントと常識はそれぞれに登録/登録解除するように指示していますが、無数の登録onResume/onPauseたので、 何かが足りないのではないかと思います。 onCreate

また、登録解除の失敗(たとえば、ここonStopでは登録解除が呼び出されない可能性があり、呼び出されることが保証されていない)が必ずしもリークにつながるかどうかはよくわかりません。だから私が例えば持っているなら

class MyPref extends PreferenceActivity implements
            OnSharedPreferenceChangeListener {
    SharedPreferences sharedPreferences;
    // init sharedPreferences
    onStart(){
        sharedPreferences.registerOnSharedPreferenceChangeListener(this);
    }
    // no unregistration
}

MyPref他のアクティビティの1つに戻ると、インスタンスがリークしますか?

最後に-同じ考慮事項が適用されOnPreferenceChangeListenerますか?

編集:それに戻って、実際に登録を解除する方法がわかりませんOnPreferenceChangeListener-私は盲目ですか??

4

2 に答える 2

1

個人的な好みは別として、リスナーにとって特定の場所を好む主な理由はないと思います。実装するか、内部クラスをActivity使用するか(匿名かどうかに関係なく)、すべて問題ありません。

唯一のことは、リスナーとして自分のような既存のオブジェクトを使用していない場合はActivity、リスナーオブジェクトへの参照を保持する必要があるということです。この回答によると、ガベージコレクションを行わないと、ガベージコレクションが実行されます(したがって、実際には何もリッスンされません)。


ソースを少し掘り下げてみると、登録済みのリスナー(ソース、行72-73、186-196)を含めるためにをSharedPreferencesImpl使用しているようです。つまり、登録解除に失敗してもリークは発生しません。WeakHashMap

あなたが言うように、ドキュメントはonResume()/を使用することをお勧めしonPause()ます; これはおそらくリークとは関係ありませんが、代わりにバックグラウンドアプリが不要な処理を行うのを防ぐためです-それでもフォローする価値があります!

于 2013-12-10T11:44:18.767 に答える
0

onPause/で登録と登録解除を行うことonResumeは、無料で多くの余分な作業です。

次のように、クラスの一部としてリスナーの匿名実装を作成できます。

[class level]
...
OnSharedPreferenceChangeListener mListener = new OnSharedPreferenceChangeListener () {
    onSharedPreferenceChanged(SharedPreferences sharedPreferences, String key) {
        // your code here
    }
};
...
[class level]

次に、必要に応じて設定します。これを行うと、リスナーはonPause/の間の別のオブジェクトとして再作成されないためonResume(アプリが強制終了され、Activityサブクラスを再度ロードする必要がある場合を除く)、常に参照するため、リスナーを割り当てることは無意味です。同じオブジェクト。一方、アプリが強制終了された場合は、onCreateが再度呼び出されます。

内部クラスの実装に関しては、コードのクリーン性が向上しているため、(上記のように)匿名の実装を好む傾向があります。クラス名を気にする必要がなく、入力する括弧の数も少なくて済みます。しかし、それは本当に好みのことなので、あなたがより良いと感じることは何でもしてください。

于 2013-03-25T01:07:46.350 に答える