Жизненный цикл синглтона на основе enum на Android

Question

Несколько дней назад я обнаружил, что синглтон может стать анти-паттерном в Android. Мой синглтон (класс с закрытым конструктором и экземпляр, хранящийся в статическом поле) был удален (экземпляр был удален, несмотря на тот факт, что другие операции все еще использовали этот синглтон (с помощью метода getInstance ()), поэтому необходимо было создать другой экземпляр), поскольку операция, из которой он был впервые вызван, был удален (после завершения вызова только для этого одного действия).

Я уже читал, как можно решить эту проблему, но я также только что прочитал «Эффективная Java». Говорят, что «одноэлементный тип перечисления - лучший способ реализации синглтона».

Так что теперь мне интересно, каков будет жизненный цикл синглтона, созданного таким образом в приложении для Android? Будет ли это так же, как в случае «стандартной реализации синглтона», поэтому после уничтожения действия, из которого он был вызван в первый раз, оно будет уничтожено (даже если оно использовалось также в других действиях)?

Я не спрашиваю о правильной реализации синглтона Android или о самом шаблоне синглтона (это шаблон или анти-шаблон и т. Д.), Но я хотел бы знать, каков жизненный цикл такого одноэлементного объекта enum и когда он будет уничтожен .

Answer 1

Во всех случаях используемые вами классы связаны с ClassLoader, который их загрузил.Это верно для Java в целом, а не только для Android.Android будет изолировать действия, используя каждый раз новые ClassLoader - по крайней мере, он не обещает этого, и, насколько я могу судить, делает это.

Любой синглтон или другойсостояние уровня класса, связано с Class, которое связано с ClassLoader.Вот почему ваше состояние "исчезает";на самом деле ваш вызывающий код видит новый Class в новом ClassLoader.

Итак, ваш трюк на основе enum или что-то еще в этом духе будет иметь точно такое же поведение.Вы просто не можете «сохранять» информацию об активности таким образом.Вы можете и должны писать в БД SQLite.Возможно, вы могли бы спрятать его и в SharedPreferences.

Answer 2

Объект приложения является хорошим местом для хранения информации, которая должна быть доступна для различных видов деятельности или служб. Вы можете получить его следующим образом (где это действие или служба):

личное приложение MyApplication;

в onCreate (...) { ... this.app = (MyApplication) this.getApplication (); ... }

Не забудьте указать имя также в манифесте: Установите атрибут «name» тега «application»: Значение - это путь к классу относительно пакета вашего приложения.

Объект приложения создается при запуске приложения, его можно инициализировать как в действии или сервисе с помощью метода onCreate ().

Одна вещь, которую нужно запомнить: объект приложения может выжить, закрыв вашу «последнюю» активность. В этом случае вы можете получить тот же объект приложения с состоянием из предыдущего взаимодействия с вашим приложением. Если это проблема, вы должны каким-то образом определить начальный запуск вашего приложения (например, с помощью специальной операции запуска без UI, которая инициализирует объект приложения, а затем запускает новое намерение). Кстати, то же самое может случиться с синглетами, если они еще не потеряны для сборки мусора.

Answer 3

Моя безопасная одноэлементная реализация выглядит так:

Я создаю одноэлементный класс с атрибутом boolean 'didReceiveMemoryWarning';

public class SingleTon(){
     public boolean didReceiveMemoryWarning = true;
     ...
     ...
}

На первом экране приложения (это точно первыйэкран запуска) (у меня есть заставка, которая видна через 3 секунды)

SingleTon.getInstance().didReceiveMemoryWarning = false;

И в методе onCreate () каждого занятия проверьте эти логические данные,

@Override
public void onCreate(Bundle savedInstanceState) {
     super.onCreate(savedInstanceState);

     if(SingleTon.getInstance().didReceiveMemoryWarning){
          { Load your data from local to your SingleTon class, 
             because your app was released by OS};
     }
}

это мойосуществление.