Я работаю над приложением для Android, которое использует некоторые фоновые задачи (AsyncTasks), и я хочу использовать лучшие практики, касающиеся сохранения данных на протяжении жизненного цикла приложения и обратных вызовов задач.
До сих пор у меня есть смесьиз практики относительно этого:
1) У меня есть некоторые статические поля в классах, где AsyncTasks используются в виде:
private static String str1;
private static String str2;
private static int int1;
...//=>no more than 6 static fields
2) Я использую экземпляр приложения sinleton со многими получателями /сеттеры в виде:
package xxx.xxx.xxx
import xxx.xxx.xxx
...
public class AppSettings {
private static AppSettings singleton;
private String _field1;
...//=>many fields
public void setField1(String field1) { _field1 = field1; }
public String getField1() { return _field1; }
...//=>many getters/setters
private AppSettings() {}
public AppSettings getInstance(){
if (instance== null) {
synchronized(AppSettings.class) {
if (instance == null)
instance = new AppSettings();
}
}
return instance;
}
}
Я определенно знаю, что злоупотребление статическими полями совсем не годится, поэтому я решил заменить их все, но я не совсем уверен, что мой второй подход - естьэкземпляр приложения в единственном экземпляре со многими получателями / установщиками - считается хорошим способом, и в случае нет, я хотел бы узнать о лучших альтернативах.
Большое спасибо.
Edit 1: Просто чтобы уточнить.
Для того, чтобы вы более четко поняли, для чего я использую свой одноэлементный класс AppSettings, я приведу вам два примера:
1) Я использую i• хранить настройки приложения / значения конфигурации (поэтому имя), чтобы быть доступным в любом месте. Например, цвет шрифта, размер шрифта, что угодно.
2) Я использую его для хранения временных данных / значений. Например, мое основное действие создает небольшое видео в фоновом режиме с использованием класса VideoHelper и вызывается через AsyncTask, а поскольку процессу генерации видео требуются некоторые параметры из основного действия, я использую средства получения / установки AppSettings для их отправки.
Редактировать 2: Лучшее объяснение всего.
Благодаря @a_local_nobody я понял, что мой "случай использования" не так ясен, поэтому я добавлю еще несколько вещей.
МойAppSettings не используется для хранения пользовательских настроек, я использую SharedPreferences для этого, но вместо этого параметры конфигурации приложения по умолчанию.
Чтобы привести пример, я сохраняю цвет фона действий (и это только пример), так что если вВ будущем я передумал и решил использовать другой цвет фона, этот параметр (и многие другие) там централизован. Это похоже на «контейнер» для многих настроек приложения по умолчанию.
Что касается использования геттеров и сеттеров в этом одноэлементном классе приложения, я думаю, что я предложу @a_local_nobody предложение, связанное с определением некоторых статических переменных в каждом классе ииспользуйте их по мере необходимости, вместо того, чтобы иметь несколько несвязанных методов получения / установки по всему миру.
В любом случае, все комментарии приветствуются.