Comments 10
Весьма странно, что сделали deprecated, а не оставили как альтернативу. Если пользоваться правильно, то и проблем можно избежать. С таким же успехом можно и findViewById задепрекейтить.
+1
Согласен. Учитывая что по факту dataBinding не является альтернативой, а совсем другой подход, и его применение в парадигме отличной от mvvm может вызвать проблемы.
0
Более того, использование View Binding в некоторых моментах усложняет а не упрощает разработку. В результате вместо синтетики и view binding прийдется использовать старый добрый findViewById. Простой пример — мы используем базовый класс в котором знаем, что для наследников может использоваться View с определенным id. В этом случае использовать View Binding не получится, так как в базовом классе мы не знаем, какая разметка будет. Синтетика же давала элемент если он существует либо null если его нет во вью иерархии
0
Забавно, что в ходе их постоянного цикла «текущее решение — плохое, придумываем новое» у них даже не возникает мысли, что если они постоянно генерируют плохие недолговечные решения, то может им стоит чуть больше внимания уделять их продумыванию
+1
Объясните пожалуйста более подробно неочевидный момент: Зачем занулять _binding в onDestroyView? (многие пишут про утечку памяти, но я так и не понял как она может возникнуть здесь)
0
потому что binding держит ссылки на вьюхи, фрагмент уничтожается, а binding живет. Но фрагмент не может быть обработан gc
0
Потому что View фрагмента имеет свой жизненный цикл, отличный от фрагмента. Когда фрагмент уходит в бэкстэк его View уничтожается, но она не может быть собрана Garbage Collector'ом, потому что binding фрагмента держит ссылку на неё.
+1
Как же они задрали постоянно депрекейтить одно в пользу другого. Пока с одного мигрируешь, надо уже мигрировать на что-то еще.
+2
Что-то я только одни минусы вижу:
В предпоследнем пункте имел ввиду следующий код, который с необходимость биндинга будет выглядеть уже не так красиво.
Как можно было депрекейтнуть такую крутую фичу как synthetic?
- Вместо одной строчки «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?
0
Sign up to leave a comment.
Kotlin Android Extensions deprecated. Что делать? Инструкция по миграции