Хабрахабр

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

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

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

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

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

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

AlertDialog.Builder(this) .setMessage("Please, confirm the action") .setPositiveButton("Confirm") .setNegativeButton("Cancel", null) .create() .show()

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

stacktrace

E/WindowManager: android.view.WindowLeaked: Activity com.example.testdialog.MainActivity has leaked window DecorView@71b5789[MainActivity] that was originally added here at android.view.ViewRootImpl.<init>(ViewRootImpl.java:511) at android.view.WindowManagerGlobal.addView(WindowManagerGlobal.java:346) at android.view.WindowManagerImpl.addView(WindowManagerImpl.java:93) at android.app.Dialog.show(Dialog.java:329) at com.example.testdialog.MainActivity.onCreate(MainActivity.kt:27) at android.app.Activity.performCreate(Activity.java:7144) at android.app.Activity.performCreate(Activity.java:7135) at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1271) at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2931) at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:3086) at android.app.servertransaction.LaunchActivityItem.execute(LaunchActivityItem.java:78) at android.app.servertransaction.TransactionExecutor.executeCallbacks(TransactionExecutor.java:108) at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:68) at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1816) at android.os.Handler.dispatchMessage(Handler.java:106) at android.os.Looper.loop(Looper.java:193) at android.app.ActivityThread.main(ActivityThread.java:6718) at java.lang.reflect.Method.invoke(Native Method) at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:493) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:858)

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

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

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

public class MainActivity extends Activity { private static final int CONFIRMATION_DIALOG_ID = 1; // ... @Override protected Dialog onCreateDialog(int id, Bundle args) { if (id == CONFIRMATION_DIALOG_ID) { return new AlertDialog.Builder(this) .setMessage("Please, confirm the action") .setPositiveButton("Confirm", new DialogInterface.OnClickListener() { @Override public void onClick(DialogInterface dialog, int which) { // handle click } }) .create(); } else { return super.onCreateDialog(id, args); } }
}

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

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

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

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

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

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

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

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

class ConfirmationDialogFragment : DialogFragment() { interface ConfirmationListener { fun confirmButtonClicked() fun cancelButtonClicked() } private lateinit var listener: ConfirmationListener override fun onAttach(context: Context?) { super.onAttach(context) try { // Instantiate the ConfirmationListener so we can send events to the host listener = activity as ConfirmationListener } catch (e: ClassCastException) { // The activity doesn't implement the interface, throw exception throw ClassCastException(activity.toString() + " must implement ConfirmationListener") } } override fun onCreateDialog(savedInstanceState: Bundle?): Dialog { return AlertDialog.Builder(context!!) .setMessage("Please, confirm the action") .setPositiveButton("Confirm") { _, _ -> listener.confirmButtonClicked() } .setNegativeButton("Cancel") { _, _ -> listener.cancelButtonClicked() } .create() }
}

Код активити:

class MainActivity : AppCompatActivity(), ConfirmationListener { private fun showConfirmationDialog() { ConfirmationDialogFragment() .show(supportFragmentManager, "ConfirmationDialogFragmentTag") } override fun confirmButtonClicked() { // handle click } override fun cancelButtonClicked() { // handle click }
}

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

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

Не удивительно, что появляются такие вопросы на 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<R> — показывает диалог и открывает поток для получения результата.
  • sendResult(result: R) — отправляет результат, вызывается со стороны View.
  • dismiss() — просто скрывает диалог.

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

class DialogControl<T, R> internal constructor(pm: PresentationModel) { val displayed = pm.State<Display>(Absent) private val result = pm.Action<R>() sealed class Display { data class Displayed<T>(val data: T) : Display() object Absent : Display() } // ...
}

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

class SamplePresentationModel : PresentationModel() { enum class ConfirmationDialogResult { CONFIRMED, CANCELED } // Создаем контрол диалога без данных и с enum для возвращаемого результата val confirmationDialog = dialogControl<Unit, ConfirmationDialogResult>() val buttonClicks = Action<Unit>() override fun onCreate() { super.onCreate() buttonClicks.observable .switchMapMaybe { // по клику на кнопку запускаем диалог и ожидаем нужный результат confirmationDialog.showForResult(Unit) .filter { it == ConfirmationDialogResult.CONFIRMED } } .subscribe { // обрабатываем действие } .untilDestroy() }
}

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

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

class SampleActivity : PmSupportActivity<SamplePresentationModel>() { override fun providePresentationModel() = SamplePresentationModel() // В этом методе связываем View и PresentationModel override fun onBindPresentationModel(pm: SamplePresentationModel) { pm.confirmationDialog bindTo { data, dialogControl -> AlertDialog.Builder(this@SampleActivity) .setMessage("Please, confirm the action") .setPositiveButton("Confirm") { _, _ -> dialogControl.sendResult(CONFIRMED) } .setNegativeButton("Cancel") { _, _ -> dialogControl.sendResult(CANCELED) } .create() } button.clicks() bindTo pm.buttonClicks }
}

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

  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.

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

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

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть