Как стать автором
Обновить

Комментарии 6

Можно немного улучшить. Не всегда нужно биндинг делать только через Fragment.requireView(). Иногда нужно немного кастомного поведения. Для этого можно в конструктор FragmentViewBindingProperty передавать инициализатор, который по-умолчанию будет делать то что и сейчас, а при необходимости можно изменить это поведение.

Будет классно если опишешь такой сценарий. В голову приходит только использование не корневой View. Добавлю возможность в библиотеку.

Я пока только добавил возможность избавиться от рефлексии при создании ViewBinding.
В голову приходит только использование не корневой View

Именно так и есть.
Мне это понадобилось когда пришлось сделать биндинг на корневой view кастомизированного UI для ExoPlayer. Там хитрая система с override layout в xml и прямого доступа к контролям через биндинг не будет. Т.е. как раз нужно делать биндинг через requireView().findViewById(..id..)

Добавлено в версии 0.3. Буду рад обратной связи

А есть ли какие-нибудь преимущества у View Binding перед kotlinx synthetic, кроме возможности использовать в мультимодульном проекте?

Лично для меня преимущества следующие:


  • все View, которые есть в рамках одного layout, собраны в одном классе
  • kotlinx.synthetic используется через статические импорты и позволяет легко ошибиться, если view с одним и тем же id есть в разных layout
  • Особенности работы кэша в kotlinx.synthetic зависит от того где он используется: Activity, Fragment, View, RecyclerView.ViewHolder и другие мест
  • Преобразование id в название код в View Binding есть и работает по принятым стилям кода в каждом из типов файлов (xml и kt). В kotlinx.synthetic такое же, как и в layout, что не является каноничным стилем кода для переменных в java
Зарегистрируйтесь на Хабре , чтобы оставить комментарий