14
Potrzebuję klasy, która obsługuje moje SharedPreferences i wymyśliłem 3 sposoby na zrobienie tego, jednak po pewnych badaniach wydaje się, że większość z nich jest uważana za "anti-patterns".Najbezpieczniejszy sposób korzystania z SharedPreferences
Type 1
public final class MyPrefs {
private MyPrefs(){ throw new AssertionError(); }
public static void setFavoriteColor(Context context, String value){
SharedPreferences prefs = PreferenceManager.getDefaultSharedPreferences(context);
prefs.edit().putString("color_key", value).apply();
}
public static void setFavoriteAnimal(Context context, String value){
// ...
}
// ...
}
/* Usage */
MyPrefs.setFavoriteColor(this, "yellow");
// Reason why it might be considered "Bad"
// Class is not OO, just collection of static methods. "Utility Class"
Type 2
public class MyPrefs {
private SharedPreferences mPreferences;
private static volatile MyPrefs sInstance;
public static MyPrefs getInstance(Context context){
if(sInstance == null){
synchronized(MyPrefs.class){
if(sInstance == null){
sInstance = new MyPrefs(context);
}
}
}
return sInstance;
}
private MyPrefs(Context context){
mPreferences = PreferenceManager.getDefaultSharedPreferences(context);
}
public void setFavoriteColor(String value){
mPreferences.edit().putString("color_key", value).apply();
}
public void setFavoriteAnimal(Context context, String value){
// ...
}
// ...
}
/* Usage */
MyPrefs myPrefs = MyPrefs.getInstance(this);
myPrefs.setFavoriteColor("red");
// Reason why it might be considered "Bad"
// Singleton's are frowned upon especially
// in android because they can cause problems and unexpected bugs.
Type 3
public class MyPrefs {
SharedPreferences mPreferences;
public MyPrefs(Context context){
mPreferences = PreferenceManager.getDefaultSharedPreferences(context);
}
public void setFavoriteColor(String value){
mPreferences.edit().putString("color_key", value).apply();
}
public void setFavoriteAnimal(Context context, String value){
// ...
}
// ...
}
/* Usage */
MyPrefs myPrefs = new MyPrefs(this);
myPrefs.setFavoriteColor("green");
// Reason why it might be considered "Bad"
// Lots of boilerplate and must create object every
// time you want to save a preference.
Teraz moje preferencji owijarki oczywiście nie składa się tylko z 2 ustawiaczy, mają wiele pobierające i setery, które wykonują pewne przetwarzanie boczne przed zapisaniem wartości, więc mając preferencje zapisane i przetworzone w ramach th Główna działalność spowodowałaby wiele bałaganu i błędów.
Teraz, które z tych podejść nie będą miały negatywnego wpływu na wydajność/powodować nieoczekiwane błędy?
to ty problem został rozwiązany? –
@SumitYadav tak prawie. Wygląda na to, że wszystkie działają i można ich bezpiecznie używać, jednak niektóre (np. Singleton) mogą powodować problemy, z którymi trzeba się uporać. Po prostu pozostanę bezpieczny i użyję 1 lub 3. – Linxy
Nie używaj metody .apply(), używaj metody .commit() w osobnym wątku. Powodem jest to, że .apply() planuje zapisywanie w tle i nie możesz być pewien, że dane są zapisywane przed innym .apply(). Może to spowodować utratę danych. Zamiast tego użyj .commit(), powiedzmy, w łańcuchu rxJava: –