Dialogfragment android жизненный цикл

Памятка по жизненному циклу Android — часть I. Отдельные Activity

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

Чтобы обеспечить такое взаимодействие с пользователем, вы должны знать, как управлять жизненными циклами компонентов. Компонентом может быть Activity, Fragment, Service, класс Application и даже сам процесс приложения. Компонент имеет жизненный цикл, в течение которого он проходит через различные состояния. Всякий раз, когда происходит переход, система уведомляет вас об этом при помощи методов жизненного цикла.

Чтобы нам было легче объяснить, как работает жизненный цикл в Android, мы определили несколько сценариев (примеров из жизни), которые сгруппированы по компонентам:

Часть 1: Activity — ЖЦ одного активити (этот пост)

Диаграммы также доступны в виде шпаргалки в формате PDF для краткого ознакомления.

Примечание: эти диаграммы соответствуют поведению в Android P/Jetpack 1.0.

Следующие сценарии демонстрируют поведение компонентов по умолчанию, если не указано иное.

Если вы обнаружили ошибки в статье или считаете, что не хватает чего-то важного, напишите об этом в комментариях.

Часть 1: Activity

Одно Aсtivity — Сценарий 1. Приложение завершено и перезапущено

Будет вызван, если:

Пользователь нажимает кнопку Назад или

Вызван метод Activity.finish()

Самый простой сценарий показывает, что происходит, когда приложение с одним активити запускается, завершается и перезапускается пользователем:

Управление состоянием

onSaveInstanceState не вызывается (поскольку активити завершено, вам не нужно сохранять состояние)

onCreate не имеет Bundle при повторном открытии приложения, потому что активити было завершено и состояние не нужно восстанавливать.

Одно Aсtivity — Сценарий 2. Пользователь уходит

Будет вызван, если:

Пользователь нажимает кнопку «Домой»

Пользователь переключается на другое приложение (через меню «Все приложения», из уведомления, при принятии звонка и т. д.)

В этом случае система остановит активити, но не завершит его сразу.

Управление состоянием

Когда ваше активити переходит в состояние Stopped, система использует onSaveInstanceState для сохранения состояния приложения на тот случай, если впоследствии система завершит процесс приложения (см. ниже).

Предполагая, что процесс не был убит, экземпляр активити сохраняется в памяти, сохраняя все состояние. Когда активити возвращается на передний план, вам не нужно повторно инициализировать компоненты, которые были созданы ранее.

Одно Aсtivity — Сценарий 3. Изменение кофигурации

Будет вызван, если:

Изменена конфигурация, такие как поворот экрана

Пользователь изменил размер окна в многооконном режиме

Управление состоянием

Изменения конфигурации, такие как поворот или изменение размера окна, должны позволить пользователям продолжить работу с того места, где они остановились.

Активити полностью уничтожено, но состояние сохраняется и восстанавливается при создании нового экземпляра.

Bundle в onCreate тот же самый, что и в onRestoreInstanceState .

Одно Aсtivity — Сценарий 4. Приложение приостановлено системой

Будет вызван, если:

Включён многооконный режим (API 24+) и потерян фокус

Другое приложение частично покрывает работающее приложение: диалоговое окно покупки (in-app purchases), диалоговое окно получения разрешения (Runtime Permission), стороннее диалоговое авторизации и т. д.

Появится окно выбора приложения (при обработке неявного интента), например диалоговое окно шейринга.

Этот сценарий не применим к:

Диалогам в том же приложении. Отображение AlertDialog или DialogFragment не приостанавливает базовое активити.

Уведомлениям. Пользователь, получающий новое уведомление или открывающий панель уведомлений, не приостанавливает текущее активити.

Источник

Свежий взгляд на отображение диалогов в Android

На картинке первая мысль читателя, который недоумевает, что можно написать про такую простую задачу как отображения диалога. Аналогично думает и менеджер: «Тут ничего сложного, наш Вася за 5 минут сделает». Я, конечно, утрирую, но на самом деле всё не так просто, как кажется на первый взгляд. Особенно если мы говорим про Android.

Итак, на дворе шёл 2019 год, а мы всё ещё не умеем нормально показывать диалоги.

Давайте всё по порядку, и начнем с постановки задачи:

Требуется показать простой диалог с текстом для подтверждения действия и кнопками «подтвердить/отмена». По нажатию на кнопку «подтвердить» — совершить действие, по кнопке «отмена» — закрыть диалог.

Решение «в лоб»

Я бы назвал этот способ джуниорским, потому что не первый раз сталкиваюсь с непониманием, почему нельзя просто использовать AlertDialog, как показано ниже:

Довольно распространенный способ для начинающего разработчика, он очевиден и интуитивно понятен. Но, как и во многих случаях при работе с Android, этот способ совершенно неправильный. На ровном месте мы получаем утечку памяти, достаточно повернуть устройство, и вы увидете в логах такую ошибку:

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

Можно, конечно, вызывать dismiss у диалога в onPause или onDestroy активити, как советуют в ответе по ссылке. Но это не совсем то, что нам нужно. Мы хотим, чтобы диалог восстанавливался после поворота устройства.

Устаревший способ

До появления фрагментов в Android диалоги должны были отображаться через вызов метода активити showDialog. В этом случае активити правильно управляет жизненным циклом диалога и восстанавливает его после поворота. Создание самого диалога нужно было реализовать в коллбэке onCreateDialog:

Не очень удобно, что приходится заводить идентификатор диалога и передавать параметры через Bundle. И мы все ещё можем получить проблему «leaked window», если попытаемся отобразить диалог после вызова onDestroy у активити. Такое возможно, например, при попытке показать ошибку после асинхронной операции.

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

Способ из документации

В Android Honeycomb появились фрагменты, и описанный выше способ устарел, а метод showDialog у активити помечен как deprecated. Нет, AlertDialog не устарел, как ошибаются многие. Просто теперь появился DialogFragment, который оборачивает объект диалога и управляет его жизненным циклом.

Родные фрагменты тоже устарели начиная с 28 API. Теперь следует использовать только реализацию из Support Library(AndroidX).

Давайте реализуем нашу задачу, как это предписывает официальная документация:

1. Для начала нужно наследоваться от DialogFragment и реализовать создание диалога в методе onCreateDialog.
2. Описать интерфейс событий диалога и инстанцировать слушатель в методе onAttach.
3. Реализовать интерфейс событий диалога в активити или фрагменте.

Если читателю не очень понятно, почему нельзя передавать слушатель через конструктор, то он может почитать подробнее об этом тут

Код фрагмента диалога:

Достаточно много кода получилось, не так ли?

Как правило, в проекте есть какой-нибудь MVP, но я решил, что вызовы презентера можно опустить в данном случае. В примере выше стоит ещё добавить статический метод создания диалога newInstance и передачу параметров в аргументы фрагмента, всё как полагается.

И это всё ради того, чтобы диалог вовремя скрывался и правильно восстанавливался. Не удивительно, что появляются такие вопросы на Stackoverflow: один и два.

Поиск идеального решения

Текущее положение дел нас не устраивало, и мы стали искать способ, как сделать работу с диалогами более комфортной. Было ощущение, что можно сделать проще, почти как в первом способе.

Ниже сформулированы соображения, которыми мы руководствовались:

• Нужно ли сохранять и восстанавливать диалог после убийства процесса приложения?
  В большинстве случаев это не требуется, как и в нашем примере, когда нужно показать простое сообщение или что-то спросить. Такой диалог актуален пока не потеряно внимание пользователя. Если его восстановить после долгого отсутствия в приложении, то пользователь потеряет контекст с планируемым действием. Поэтому нужно только поддержать повороты устройства и правильно обрабатывать жизненный цикл диалога. Иначе от неловкого движения устройства пользователь может потерять только что открытое сообщение, не прочитав его.
• При использовании DialogFragment появляется слишком много boilerplate-кода, теряется простота. Поэтому было бы неплохо избавиться от фрагмента как обёртки и использовать Dialog напрямую. Для этого придется хранить состояние диалога, чтобы показать его вновь после пересоздания View и скрывать, когда View умирает.
• Все привыкли воспринимать показ диалога как команду, особенно если работаешь только с MVP. Задачу последующего восстановление состояния берет на себя FragmentManager. Но можно посмотреть на эту ситуацию иначе и начать воспринимать диалог как state. Это намного удобнее при работе с паттернами PM или MVVM.
• Учитывая, что большинство приложений сейчас используют реактивные подходы, появляется потребность в том, чтобы диалоги были реактивными. Основная задача — не разрывать цепочку, которая инициирует показ диалога, и привязать реактивный поток событий для получения результата от него. Это очень удобно на стороне PresentationModel/ViewModel, когда манипулируешь несколькими потоками данных.

Мы учли все вышеописанные требования и придумали способ реактивного показа диалогов, который успешно реализовали в нашей библиотеке RxPM (про нее есть отдельная статья).

Само решение не требует библиотеки и может быть сделано отдельно. Руководствуясь идеей «диалог как state» можно попробовать построить решение на основе модных ViewModel и LiveData. Но я оставлю это право за читателем, а далее речь пойдет уже о готовом решении из библиотеки.

Реактивный способ

Я покажу, как исходная задача решается в RxPM, но сначала пару слов о ключевых понятиях из библиотеки:

• PresentationModel — хранит реактивный стейт, содержит UI-логику, переживает повороты.
• State — реактивный стейт. Можно воспринимать как обертку над BehaviorRelay.
• Action — обертка над PublishRelay, служит для передачи событий от View в PresentationModel.
• State и Action имеют observable и consumer.

За состояние диалога отвечает класс DialogControl. Он имеет два параметра: первый для типа данных, которые должны отображаться в диалоге, второй — для типа результата. В нашем примере тип данных будет Unit, но это может быть сообщение пользователю или любой другой тип.

В DialogControl есть следующие методы:

• show(data: T) — просто отдает команду на отображение.
• showForResult(data: T): Maybe — показывает диалог и открывает поток для получения результата.
• sendResult(result: R) — отправляет результат, вызывается со стороны View.
• dismiss() — просто скрывает диалог.

В DialogControl хранится состояние — есть диалог на экране или нет (Displayed/Absent). Вот так это выглядит в коде класса:

Создадим простую PresentationModel:

Обратите внимание, что обработка кликов, получение подтверждения и обработка действия реализованы в одной цепочке. Это позволяет сделать код сфокусированным и не раскидывать логику по нескольким коллбэкам.

Далее просто привязываем DialogControl во View с помощью экстеншена bindTo.
Собираем обычный AlertDialog, а результат отправляем через sendResult:

При типичном сценарии под капотом происходит примерно следующее:

1. Кликаем на кнопку, событие через Action «buttonClicks» попадает в PresentationModel.
2. По этому событию запускаем отображение диалога через вызов showForResult.
3. В результате состояние в DialogControl меняется с Absent на Displayed.
4. При получении события Displayed — вызывается лямбда, которую мы передали в привязке bindTo. В ней создается объект диалога, который затем показывается.
5. Пользователь нажимает, кнопку «Confirm», срабатывает слушатель и результат нажатия отправляется в DialogControl посредством вызова sendResult.
6. Далее результат попадает во внутренний Action «result», а состояние с Displayed меняется на Absent.
7. При получении события Absent текущий диалог закрывается.
8. Событие от Action «result» попадает в поток, который был открыт вызовом showForResult и обрабатывается цепочкой в PresentationModel.

Стоит отметить, что диалог закрывается и в момент, когда View отвязывается от PresentationModel. В этом случае состояние остается Displayed. Оно будет получено при следующей привязке и диалог будет восстановлен.

Как видите, необходимость в DialogFragment пропала. Диалог показывается, когда View привязывается к PresentationModel и скрывается, когда View отвязывается. За счёт того, что состояние хранится в DialogControl, который в свою очередь хранится в PresentationModel, диалог восстанавливается после поворота устройства.

Пишите диалоги правильно

Мы с вами рассмотрели несколько способов отображения диалогов. Если вы все ещё показываете первым способом, то прошу вас, не делайте больше так. Для любителей MVP ничего не остается, как использовать стандартный способ, который описан в официальной документации. К сожалению, склонность к императивности этого паттерна не позволяет сделать по-другому. Ну, а фанатам RxJava рекомендую присмотреться к реактивному способу и нашей библиотеке RxPM.

Источник