Поместить редактор SharedPrefs в служебный класс?

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

   ...

 }

Это дает вам более читаемый код, и вы можете обеспечить реализацию заглушки / макета в своих тестах! Если API SharedPreferences должен измениться (или когда вы хотите отказаться от использования commit в apply или наоборот, или изменяя теги, которые вы использовали для предпочтений) вы должны изменить его только в одном файле, а не везде в своем коде.
Но есть еще кое-что: если позже вы решите, что SharedPreferences На самом деле это был плохой выбор, вы можете переключить реализацию, например, на. База данных SQLite или ObjectBox вместо этого. Опять же, без изменения остальной части кода.

Излишне говорить, что в некоторых ситуациях это может быть излишним (или чрезмерным), но в более крупных проектах это окупается довольно быстро.

Answer 2

Это не обязательно плохая идея, и это очистит код. Но это замедлит ваше приложение.
Не на заметную сумму, но тем не менее - если время в вашем проекте - проблема, не делайте этого. Если нет, то иди вперед.