Комментарии 6
Можно немного улучшить. Не всегда нужно биндинг делать только через Fragment.requireView(). Иногда нужно немного кастомного поведения. Для этого можно в конструктор FragmentViewBindingProperty передавать инициализатор, который по-умолчанию будет делать то что и сейчас, а при необходимости можно изменить это поведение.
Будет классно если опишешь такой сценарий. В голову приходит только использование не корневой View. Добавлю возможность в библиотеку.
Я пока только добавил возможность избавиться от рефлексии при создании ViewBinding.
Я пока только добавил возможность избавиться от рефлексии при создании ViewBinding.
В голову приходит только использование не корневой View
Именно так и есть.
Мне это понадобилось когда пришлось сделать биндинг на корневой view кастомизированного UI для ExoPlayer. Там хитрая система с override layout в xml и прямого доступа к контролям через биндинг не будет. Т.е. как раз нужно делать биндинг через requireView().findViewById(..id..)
А есть ли какие-нибудь преимущества у 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
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Делаем Android View Binding удобным c Kotlin