но это такое, билет в один конец. Этот кастомный класс у тебя вместо почти ВСЕХ строк тогда будет.

Вот полное обсуждение с примерами: https://kotlinlang.slack.com/archives/C5GB1NDGE/p1550527639020200?thread_ts=1550527639.020200&cid=C5GB1NDGE

А если закрыть получение ресурсов интерфейсом?

Вроде бы тематический чатик, чего бы не по ныть) Другие люди увидят сколько боли это вызывает и обойдут стороной этот компонент - профит

Найдите хоть один компонент, по которому нет боли и нытья в чятиках. Так себе подход к выбору инструмента

не, прислушиваться к попаболи других очень здравый подход. Вот человек прочтёт, выкинет Databindings и заживёт как-будто и не стрелял себе в ногу. Я, к сожалению, лошара, никого не слушал и потом долго его выковыривал. Зато с каналами из корутин уже не торопился, почитал слак богов, сделал "уу... так у вас тут работы ещё..." и теперь каждый день себя одобрительно по плечу хлопаю.

А на что поменяли  ? Тоже хочу выпелить, но пока не знаю чем заменить

котлин синтетики заменяют биндинги, а котлин расширения заменяют адаптеры (что в разы лучше, потому что это не магия, а обычный код, который дебажится и тестируется)

конечно, итог будет более олдскульный, не реактивный. Что имхо лучше, потому что меньше сюрпризов

👍 спасибо

можно загнаться по чистому MVI, с полным кольцом, где клики это ивенты и тд. Тогда какой-то RxBindings, но там своя атмосфера, можно утопнуть не хуже, чем в Databindings

Про какие адаптеры идёт речь, уж очень интересно, но не понимаю о чем вы
И как эти адаптеры можно заменить extensions?

Databindings адаптеры

(спойлер: разговор про Databindings)

Спасибо, уже понял
Я когда решил заюзать эти биндинги, то тимлид сказал сразу же удалить из кода и больше никогда не юзать

Вопрос в статистике

в похожем треде я когда-то как-то так написал:

Nope, not buying it again) Expectations about Databindings don't meet reality. As a concept, it plays nicely with MVVM, that's something I'd say on a conference. But it's a cognitive illusion to automatically imply that android implementation is good. It was always shit and it's still shit. Without thinking about theoretical abstractions, my expectation is that I have fewer headaches after I move to DB. And I'm not getting this feeling of something light and smooth in my project. It's the opposite. Chains of notifyProperty, notifyall,  another Observable interface in the project (like the third one?), BR files, stupid behaviour like this one, that you can debug for months without knowing what's going on https://stackoverflow.com/questions/46680862/android-databinding-onlongclick-not-working. Terrible IDE support, yeah, yeah, it's getting better, but my layout is still red unless I compile/recompile 10 times. Compilation errors because of broken compatibility with gradle plugin. Bad navigation from xml to source (to adapters). Sometimes it's possible, sometimes not. And with kotlin you don't need adapters at all, because it's basically an extension. The difference is that kotlin extension is better from any point of view and adapters are hard to debug. You can't easily copy & paste layouts, because they're coupled with models.. etc, etc.
I prefer to think of my UI as of something very thin and static. With DB I'm getting something liquid, heavy, buggy, non-debuggable... something is happening somewhere. Reminds me of EventBus days a little.

Observable fields - действительно боль, немного облегчалась через проперти делегаты в котлине а сейчас ушла в прошлое. Адаптеры нужны крайне редко, в основном для закрытия кривого поведения вьюх. Да, биндинги позволяют писать разную дичь вроде кода в xml, но этого просто не надо делать

Хочу напомнить что с датабиндингом очень изящно работать со списками. 1 раз сделать базовый адаптер и все. Для разных списков только разные xml

конечно кроме случая когда в одном списке айтемы разных типов