ActivityLifecycleCallbacks — слепое пятно в публичном API

[uncle_doc]

Добрый день. Лучше расскажите про ваш опыт использования этой возможности в Яндекс.Деньгах. Потому что приведенные примеры, в некотором роде, относятся к категории «вредных советов», вы наверное их для того и выделили отдельной строкой "Повторяйте этот трюк ТОЛЬКО дома". Сейчас реально хороший пример только с инициализацией dagger2.

[Lynnfield]

Добрый день.
На самом деле эта статья построена на примерах из нашего приложения, хотя они и переписаны с целью привлечь внимание к конкретным вариантам использования. В прошлом году мы провели серию крупных рефакторингов, связанных с отказом от базовых Activity и некоторых singleton'ов. Часть кода, которая связана с жизненным циклом Activity как раз была заменена на решения на основе ActivityLifecycleCallbacks.
Если кратко по каждому, то:

• мы пока не используем решение с setTheme(), но планируем его внедрение;
• для ряда задач мы используем решение с диалогом, но фильтрация организована так, чтобы диалоги отображались на конкретных экранах;
• отправка событий экранов у нас построена именно так, как в статье;
• внедрение зависимостей используется в обоих вариантах в разных приложениях.

[uncle_doc]

Вы не против если я вас еще поспрашиваю? Всегда хочется использовать чужой опыт, чем изобретать собственные велосипеды (:

• А почему вы вообще планируете использовать setTheme() в таком контексте? Ведь существует стандартный механизм переопределения тем. Это для тех случаев когда один и тот же диалог на разных экранах имеет разное отображение?
• Я так понял что «решение с диалогом» и «отправка событий экранов» раньше была в базовых классах, а теперь это все живет в ActivityLifecycleCallbacks. С какими вы столкнулись проблемами что решили применить такой подход или какие он дал вам преимущества по сравнению логикой основанной на базовых классах?

[Lynnfield]

А почему вы вообще планируете использовать setTheme() в таком контексте? Ведь существует стандартный механизм переопределения тем. Это для тех случаев когда один и тот же диалог на разных экранах имеет разное отображение?

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

Я так понял что «решение с диалогом» и «отправка событий экранов» раньше была в базовых классах, а теперь это все живет в ActivityLifecycleCallbacks. С какими вы столкнулись проблемами что решили применить такой подход или какие он дал вам преимущества по сравнению логикой основанной на базовых классах?

Да, раньше это было в базовых классах. Мы перешли на многомодульное приложение и не хотели вытаскивать базовую Activity в корневой модуль. К тому же так не приходится думать о соблюдении соглашения «все Activity должны наследоваться от базовой», мы можем просто добавлять общий функционал во все приложение сразу, не переписывая код.

[uncle_doc]

Спасибо большое! И последний вопрос: У вас в приложении можно выбрать отдельно тему для всего Activity и отдельно темы для диалогов? Просто в теме Activity можно создать пользовательский атрибут для темы диалога, в диалоге сослаться на него и дальше все переопределять стандартными методами. На первый взгляд — отличное решение или есть какие-то «подводные камни»?

[Lynnfield]

У вас в приложении можно выбрать отдельно тему для всего Activity и отдельно темы для диалогов?

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

Просто в теме Activity можно создать пользовательский атрибут для темы диалога, в диалоге сослаться на него и дальше все переопределять стандартными методами. На первый взгляд — отличное решение или есть какие-то «подводные камни»?

Да, можно попробовать. Можно даже просто переопределить в теме аттрибуты android:dialogTheme и dialogTheme, если хотите повлиять на все диалоги, которые запущены на Вашем Activity.

[agent10]

Полагаю, что уже относительно ненужная штука из-за single activity подхода.

[Makentoshe]

У SingleActivity подхода можно использовать FragmentManager.FragmentLifecycleCallbacks()
Тогда можно использовать такую штуку

supportFragmentManager.registerFragmentLifecycleCallbacks(
    InjectingFragmentLifecycleCallback(), true
)

[Lynnfield]

Привет, это хорошее замечание. Это как раз была тема для следующей статьи.
А вот и она https://habr.com/ru/company/yamoney/blog/492272/