Pull to refresh

Comments 24

View Binding отличается от Butter Knife типобезопасностью и отсутствием бойлерплейта.

Погодите, а чем собственно отличается от текущего механизма DataBinding?
Ок, Build speed impact… так а в чём отличие кодогенерации для DataBinding и ViewBinding?
В официальной доке в самом конце указаны отличия от DataBinding. Вкратце:
1) DataBinding работает только с вью которые строятся через layout тег.
2) ViewBinding не поддерживает биндинг переменных и выражения в разметке.

Использование в RecyclerView.ViewHolder — это решение отсебятины вы ведь сами написали, в отличии от всего того что выше прямиком пришедшее из документации?


UPD: добавьте тег перевод, пожалуйста

Да, про использование в RecyclerView.ViewHolder написал я, так как это распространенный случай получения view в коде.

тем, что View Binding обеспечивает Null Safety, например, в ситуации, когда view есть в одной конфигурации, но нет в другой.

Всё что описано больше именно технические моменты. Но, мне кажется, всё немного глубже, видимо Гугл понял, что не очень хорошо добавлять логику внутрь xml.
А ViewBindings выглядит как некий промежуточный вариант между текущим DataBinding и вероятным будущим Jetpack Compose

Зачем нужен велосипед? Есть же databindig, отличная вещь

Не во всех проектах используется databinding, а View Binding решает очень распространенную задачу, и начать его применять достаточно легко.

А в чем проблема начать использовать DataBinding? Включается он так-же. Добавить тег layout вроде-бы не сильно сложно. Не нравятся лямбды в xml или привязка данных и методов из ViewModel? Так в чем сложность? Их можно не использовать. Хотя, честно говоря, я не совсем понимаю, кто в здравом уме откажется от этого. Когда нужно в старом проекте что-то посмотреть или исправить, то без того-же DataBinding-а чувствуешь себя так, как будто тебе обрезали крылья и дали костыли.
DataBinding влючается в два клика буквально. Необязательно сразу же использовать его фичи вроде переменных. И он ни с чем не конфликтует.
ResultProfileBinding.inflate(layoutInflater)

А там только 1 параметр передать можно? Без родительского контейнера как в обычном inflate(id, viewGroup, attach)? Таким образом не потеряются ли LayoutParameters, которые я описал в xml? Например в том же примере с RecyclerView, если я задам item_person.xml высоту в 50dp, то разве она не будет заменена на WRAP_CONTENT, поскольку он является значением по-умолчанию для LinearLayoutManager? Или если этот layout – кусок ConstraintLayout'a, который я добавляю в рантайме?

Сгенерированный метод ResultProfileBinding.inflate имеет перегрузку с параметрами (inflater, viewGroup, attach)

Тогда используйте эту перегрузку в примере с RecycleView. Иначе складывается впечатление, что такой важной функциональности нет, и заданные в xml LayoutParameters безнадежно теряются.

Джва года ждал этого, но с DataBinding перелезать уже не хочется, так как привык в разметке задавать переменные и утилитарные классы непосредственно оттуда вызывать.

Проект не компилируется, если добавить один layout в другой через include и добавить id

Спасибо, не забываем что viewBinding доступен с версии Android Studio 3.6 (пока в canary state).
Создатель Butter Knife уже рекомендует переключаться на View Binding
а можно пожалуйста ссылку на то, где он рекомендует?
да, сразу после коммента глянул и нашел, а коммент был на модерации, не мог поправить или удалить(

Больше предпочитаю KTX, поскольку boilerplate заключается только в добавлении интерфейса для ViewHolder.
Здесь единственный boilerplate это


private lateinit var binding: ResultProfileBinding
binding = ResultProfileBinding.inflate(layoutInflater)

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

Sign up to leave a comment.

Articles