Android и привязка к жизненному циклу компонентов

[mike114]

Подход интересен, но, может, просто стоит использовать data binding для большей части вещей из примера?

[ConstOrVar]

Если вы про data binding, который предоставляет Google из коробки, то, насколько я знаю, он не позволяет настроить запуск действий в определенные моменты жизненного цикла (а такое иногда требуется, хоть и не очень часто). Поправьте, если не прав.
Если вы про data binding как концепцию в целом, то тут все зависит от реализации — возможно, где-то по умолчанию есть такая возможность. Буду благодарен за пример.

[mike114]

Я о том, что вместо

bindState(color, binding.root) { view, color ->
    txtView.text = "$time"
}

можно в xml привязать ваш UI к liveData

android:text="@{time.toString()}"

и это покроет большую часть использования.

Для привязки вы передаете в binding две вещи: ваши переменные (которые могут быть LiveData) и LifecycleOwner, а binding уже сам подписывается где-то внутри сгенерированного кода и следит за обновлениями.

В последнем проекте я использую такой подход:

• Создаю ViewModel c набором LiveData и, если надо, запускаю процесс выборки данных
• Создаю xml layout, декларирую в нем переменную типа моей модели и привязываю декларативно все, что я хочу из нее показать
• В onCreateView фрагмента делаю inflate нужному binding и присваиваю значение задекларированной переменной модели
• Чтобы данные были действительно live выставляю binding.lifecycleOwner в viewLifecycleOwner там же в onCreateView

[ConstOrVar]

Подход, который вы описали, применяем в части проектов. Но не все проекты хотят завязываться на data binding от Google (по разным причинам). Вы правы, что это упростит привязку состояния к определенным элементам отображения. Но к сожалению, есть вещи, ради которых имеет смысл встраиваться в жизненный цикл родительского компонента. Классический пример (есть и другие) — компонент получения местоположения пользователя: пока activity/fragment в состоянии STARTED, нужно подписываться на датчики; если это делать при создании view, то скажется на расходе батареи.
Хочу подчеркнуть, что рассматриваю подход, разобранный в статье, как лишь один из инструментов в арсенале разработчика. Если он избыточен в большинстве случаев, то применять его не стоит. Но есть экраны, где он поможет структурировать код и сделать более читаемым. Поэтому и решил поделиться с сообществом)