将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特定的细节，并为适合您的域的存储访问创建一个干净，可读的界面。

e.g：

   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实际上是一个糟糕的选择，您可以将实现切换为使用例如一个 。而是SQLite数据库或ObjectBox。再次，不改变其余的代码。

毋庸置疑，在某些情况下，这可能是过度杀伤（又称过度工程），但在较大的项目中，这种做法非常快。

Answer 2

它不一定是个坏主意，它会清理代码。但它会减慢你的应用程序。 虽然时间是你项目中的一个问题，但是并没有明显的数量，所以不要这样做。如果没有，那就继续吧。