将SharedPrefs编辑器放在Utility类中？

Question

将静态共享首选项编辑器放在实用程序类中是一个好主意/实践,这样我可以在需要时调用它吗？实用程序类中的方法如下所示:

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();

Answer 1

至少我不会说这是一个坏主意。

但这里有一个更好的想法：抽象出 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 应该更改（或者当您想要从使用转移commit到apply使用时，反之亦然，或者更改用于首选项的标签），您只需在一个文件中进行更改，而不是在代码中的任何地方进行更改。
但还有更多：如果您后来认为这SharedPreferences实际上是一个糟糕的选择，您可以切换实现以使用例如 a 。而是使用 SQLite 数据库或 ObjectBox。同样，无需更改其余代码。

不用说，在某些情况下这可能有点矫枉过正（又名过度设计），但在更大的项目中，这会很快得到回报。