SharedPreferences 监听变化Listener 的onSharedPreferenceChanged方法没有调用
来源:互联网 发布:蛙5火箭知乎 编辑:程序博客网 时间:2024/06/05 20:57
android.content.SharedPreferences
public abstract void registerOnSharedPreferenceChangeListener (SharedPreferences.OnSharedPreferenceChangeListener listener)
frameworks/base/core/java/android/content/SharedPreferences.java
/** * Registers a callback to be invoked when a change happens to a preference. * * <p class="caution"><strong>Caution:</strong> The preference manager does * not currently store a strong reference to the listener. You must store a * strong reference to the listener, or it will be susceptible to garbage * collection. We recommend you keep a reference to the listener in the * instance data of an object that will exist as long as you need the * listener.</p> * * @param listener The callback that will run. * @see #unregisterOnSharedPreferenceChangeListener */ void registerOnSharedPreferenceChangeListener(OnSharedPreferenceChangeListener listener);
frameworks/base/core/java/android/app/SharedPreferencesImpl.java
private final WeakHashMap<OnSharedPreferenceChangeListener, Object> mListeners = new WeakHashMap<OnSharedPreferenceChangeListener, Object>();//... public void registerOnSharedPreferenceChangeListener(OnSharedPreferenceChangeListener listener) { synchronized(this) { mListeners.put(listener, mContent); } } public void unregisterOnSharedPreferenceChangeListener(OnSharedPreferenceChangeListener listener) { synchronized(this) { mListeners.remove(listener); } }
注册监听变化Listener的时候,不要使用匿名内部类,一个OnSharedPreferenceChangeListener对象实际上是放到了一个WeakHashMap的容器中,执行完示例中的onCreate方法,这个监听器对象很快就会成为垃圾回收的目标,由于放在WeakHashMap中作为key不会阻止垃圾回收,所以当监听器对象被回收之后,这个监听器也会从mListeners中移除。所以就造成了onSharedPreferenceChanged不会被调用。
如何解决
改为对象成员变量(推荐)
将监听器作为Activity的一个成员变量,在Activity的onResume进行注册,在onPause时进行注销。推荐在这两个Activity生命周期中进行处理,尤其是当SharedPreference值发生变化后,对Activity展示的UI进行处理操作的情况。这种方法是最推荐的解决方案。
private OnSharedPreferenceChangeListener onSharedPreferenceChangeListener = new OnSharedPreferenceChangeListener() { @Override public void onSharedPreferenceChanged(SharedPreferences sharedPreferences, String key) { String value = sharedPreferences.getString(key, "default_value_string"); Log.d("bearyang", "key: " + key + ", value: " + value); Toast.makeText(PreferenceTestActivity.this, "key: " + key + ", value: " + value, Toast.LENGTH_LONG).show(); }};@Overrideprotected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_preference_test); mSharedPreferences = getSharedPreferences(PREF_NAME, MODE_PRIVATE);}@Overrideprotected void onResume() { super.onResume(); mSharedPreferences.registerOnSharedPreferenceChangeListener(onSharedPreferenceChangeListener);}@Overrideprotected void onPause() { super.onPause(); mSharedPreferences.unregisterOnSharedPreferenceChangeListener(onSharedPreferenceChangeListener);}
附 Android中SharedPreference.Editor 的commit和apply方法的区别:
在Android 中存储数据时经常用SharedPreference, 并且在提交数据时一直用的是Editor的commit方法, 今天无意了看到了系统用了apply,看了方法的介绍, 原来这个方法也是可以提交数据的.
apply方法在官方SDK说明如下:
Commit your preferences changes back from this Editor to the SharedPreferences object it is editing. This atomically performs the requested modifications, replacing whatever is currently in the SharedPreferences.
Note that when two editors are modifying preferences at the same time, the last one to call apply wins.
Unlike commit, which writes its preferences out to persistent storage synchronously, apply commits its changes to the in-memory SharedPreferences immediately but starts an asynchronous commit to disk and you won’t be notified of any failures. If another editor on this SharedPreferences does a regular commit while a apply is still outstanding, the commit will block until all async commits are completed as well as the commit itself.
As SharedPreferences instances are singletons within a process, it’s safe to replace any instance of commit with apply if you were already ignoring the return value.
You don’t need to worry about Android component lifecycles and their interaction with apply() writing to disk. The framework makes sure in-flight disk writes from apply() complete before switching states.
The SharedPreferences.Editor interface isn’t expected to be implemented directly. However, if you previously did implement it and are now getting errors about missing apply(), you can simply call commit from apply().
这两个方法的区别在于:
1. apply没有返回值而commit返回boolean表明修改是否提交成功
2. apply是将修改数据原子提交到内存, 而后异步真正提交到硬件磁盘, 而commit是同步的提交到硬件磁盘,因此,在多个并发的提交commit的时候,他们会等待正在处理的commit保存到磁盘后在操作,从而降低了效率。而apply只是原子的提交到内容,后面有调用apply的函数的将会直接覆盖前面的内存数据,这样从一定程度上提高了很多效率。
3. apply方法不会提示任何失败的提示。
由于在一个进程中,sharedPreference是单实例,一般不会出现并发冲突,如果对提交的结果不关心的话,建议使用apply,当然需要确保提交成功且有后续操作的话,还是需要用commit的。
即简单地说,commit保证线程安全,apply不保证线程安全,后面有调用apply的函数的将会直接覆盖前面的内存数据,但是效率高。
测试代码位置:https://github.com/YoungBear/AndroidUI
选择PreferenceListener
参考:
http://droidyue.com/blog/2014/11/29/why-onsharedpreferencechangelistener-was-not-called/?utm_source=tuicool&utm_medium=referral
http://www.cnblogs.com/xingfuzzhd/p/3925442.html
http://www.tuicool.com/articles/jYj6zu
- SharedPreferences 监听变化Listener 的onSharedPreferenceChanged方法没有调用
- 监听SharedPreference变化的方法
- android监听联系人变化的方法
- Vue2实时监听表单变化的方法
- 数据库变化监听方法
- Listener的使用(监听用户请求,ServletRequest范围内属性的变化)
- oracle启动显示no listener没有监听
- 监听EditText的变化
- 监听EditText的变化
- 监听EditText的变化
- 监听EditText的变化
- 监听EditText的变化
- 监听网络的变化
- 监听EditText的变化
- 关于没有listener.ora文件,监听依然正常启动并使用的问题
- RAC其中一个节点监听没有起来的解决方案【ora.LISTENER.lsnr INTERMEDIATE】
- 各种 Listener 监听的动作
- 接受短信广播和监听短信数据库变化的方法
- 取出一个字符串中字母出现的次数。如:字符串:"abcde%^kka27qoq" ,输出格式为: a(2)b(1)k(2)...
- Alice and Bob
- POJ 2406 Power Strings (kmp求循环节)
- Android中的事件分发和处理
- Android 补间动画
- SharedPreferences 监听变化Listener 的onSharedPreferenceChanged方法没有调用
- Iframe实现Ajax文件上传Servlet响应上传结果
- C#:网络通信(TCP)
- 第一章.对象导论之方法的重写和重载
- HDOJ 5744 Keep On Movin(最大化最短回文串长度)
- 使用新浪SAE平台的Storage存储,如何将存入的数据,下载到本地。爬坑之旅。
- mongodb_修改器($inc/$set/$unset/$push/$pop/upsert......)
- std::unique (去重)
- 欢迎使用CSDN-markdown编辑器