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

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

将SharedPrefs编辑器放在Utility类中？

2 个答案: