В чем разница между использованием add(). AddToBackStack(), add(). Detach() и replace(). AddToBackStack() в FragmentTransaction?

В элементе FragmentTransaction на Android docs описано, что метод replace() такой же, как вызов метода remove() для всех фрагменты, добавленные в текущий вид, а затем вызванные методом add(). В этом случае, чтобы восстановить предыдущий фрагмент, мы могли бы использовать addBackToStack(), это означает, что состояние транзакции все еще управляется менеджером фрагментов и будет отменять его операцию, когда мы выскочили из стека.

С другой стороны, когда мы реализуем транзакцию с использованием add(), помимо использования add().addBackToStack(), мы можем использовать метод detach() и восстанавливать фрагмент с помощью attach(), которые имеют такое же поведение, что addBackToStack().

Так в чем разница между сценами между этими сценариями?

Ответы

Ответ 1

Я исследовал больше и, по-видимому, разница между detach() и addToBackStack () заключается в жизненном цикле фрагмента. Когда мы добавляем фрагмент в задний стек, вызывается последовательно методы onPause(), onStop() и после onDestroyView(). В этом состоянии фрагмент очищает ресурсы, связанные с его просмотром, и "остается" там в ожидании повторного вызова. Возвращение к макету из заднего стека называется методом onCreateView() только для фрагмента, чтобы нарисовать его пользовательский интерфейс. На самом деле, фрагмент не уничтожен.

С другой стороны, когда мы используем detach() для удаления или замены фрагмента, вызываются последовательно все те же методы, которые цитировались первыми (onPause(), onStop(), onDestroyView()), добавляя эти два метода: onDestroy(), чтобы выполните окончательную очистку состояния фрагмента и onDetach(), чтобы отделить фрагмент от того, что он больше не связан с его активностью.

По сути, за кадром у них не одинаковое поведение: при использовании addToBackStack() фрагменты остаются инстанцированными, а detach() - нет.