Kotlin Android Extensions deprecated. Что делать? Инструкция по миграции

[@anegin]

Весьма странно, что сделали deprecated, а не оставили как альтернативу. Если пользоваться правильно, то и проблем можно избежать. С таким же успехом можно и findViewById задепрекейтить.

[@Spyman]

Согласен. Учитывая что по факту dataBinding не является альтернативой, а совсем другой подход, и его применение в парадигме отличной от mvvm может вызвать проблемы.

[@anegin]

Тут предлагают на замену ViewBinding, а не DataBinding)

[@andreikr79]

Более того, использование View Binding в некоторых моментах усложняет а не упрощает разработку. В результате вместо синтетики и view binding прийдется использовать старый добрый findViewById. Простой пример — мы используем базовый класс в котором знаем, что для наследников может использоваться View с определенным id. В этом случае использовать View Binding не получится, так как в базовом классе мы не знаем, какая разметка будет. Синтетика же давала элемент если он существует либо null если его нет во вью иерархии

[@deinlandel]

Забавно, что в ходе их постоянного цикла «текущее решение — плохое, придумываем новое» у них даже не возникает мысли, что если они постоянно генерируют плохие недолговечные решения, то может им стоит чуть больше внимания уделять их продумыванию

[@angryrobot]

Объясните пожалуйста более подробно неочевидный момент: Зачем занулять _binding в onDestroyView? (многие пишут про утечку памяти, но я так и не понял как она может возникнуть здесь)

[@term-light]

потому что binding держит ссылки на вьюхи, фрагмент уничтожается, а binding живет. Но фрагмент не может быть обработан gc

[@Pan_brigadir]

Потому что View фрагмента имеет свой жизненный цикл, отличный от фрагмента. Когда фрагмент уходит в бэкстэк его View уничтожается, но она не может быть собрана Garbage Collector'ом, потому что binding фрагмента держит ссылку на неё.

[@deinlandel]

Как же они задрали постоянно депрекейтить одно в пользу другого. Пока с одного мигрируешь, надо уже мигрировать на что-то еще.

[@First_Spectr]

Что-то я только одни минусы вижу:

• Вместо одной строчки «setContent», теперь надо минимум 2
• Надо явно сохранять binding в поле класса
• Нельзя вынести inflate в базовый класс
• Нельзя задать одинаковую логику для наследников с одинаковым id

В предпоследнем пункте имел ввиду следующий код, который с необходимость биндинга будет выглядеть уже не так красиво.

abstract class BaseActivity : AppCompatActivity() {
    @LayoutRes
    abstract fun getLayout(): Int

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(getLayout())
    }
}

Как можно было депрекейтнуть такую крутую фичу как synthetic?