将静态共享首选项编辑器放在实用程序类中是一个好主意/实践,这样我可以在需要时调用它吗？实用程序类中的方法如下所示：
public static SharedPreferences.Editor editor (Context context){
final SharedPreferences sharedPrefs = PreferenceManager.getDefaultSharedPreferences(context);
return sharedPrefs.edit();
}
并在不同的类中使用它：
Utility.editor(mContext).putBoolean(categoryId,true);
Utility.editor(mContext).apply();
最佳答案
至少我不会说这是个坏主意.
原文链接：https://www.f2er.com/android/430199.html但这里有一个更好的想法：抽象出Android特定的细节,并为适合您的域的存储访问创建一个干净,可读的界面.
例如：
interface UserSettings {
void setAutoReloadEnabled(boolean enabled);
boolean isAutoReloadEnabled();
...
}
然后使用SharedPreferences实现它
class SharedPreferencesUserSettings implements UserSettings {
final SharedPreferences sharedPrefs;
public SharedPreferencesUserSettings(Context ctx) {
sharedPrefs = ...;
}
@Override void setAutoReloadEnabled(boolean enabled) {
sharedPrefs.editor().putBoolean("...",enabled).commit();
}
...
}
这为您提供了更易读的代码,您可以在测试中实际提供存根/模拟实现！如果SharedPreferences的API应该更改(或者您希望从使用提交移动到应用或反之亦然,或者更改用于首选项的标记),则只需在一个文件中更改它,而不是在代码中的任何位置更改它.
但还有更多：如果您以后应该确定SharedPreferences实际上是一个糟糕的选择,您可以将实现切换为使用例如一个 .而是sqlite数据库或ObjectBox.再次,不改变其余的代码.
毋庸置疑,在某些情况下,这可能是过度杀伤(又称过度工程),但在较大的项目中,这种做法非常快.
