АЕ
Если получается инкапсулировать достаточно сложный элемент как полностью самостоятельный кусок UI - честь вам и хвала.
Size: a a a
2020 January 27
AD
Почему? Элементы списка могут быть сложные, Инстаграм тот же.
не такие уж там и умные элементики
научить ViewHolder кидать в Presenter 12 событий - не проблема
научить ViewHolder кидать в Presenter 12 событий - не проблема
DE
А как-же ViewPager?
это уже более сложный вариант. Я говорю про обычные списки, про которые и был вопрос
DE
Почему? Элементы списка могут быть сложные, Инстаграм тот же.
фотка и подпись?)
АЕ
не такие уж там и умные элементики
научить ViewHolder кидать в Presenter 12 событий - не проблема
научить ViewHolder кидать в Presenter 12 событий - не проблема
ага, и умножить на 10 видов вьюхолдеров в ленте ВК) Это плохая декомпозиция.
AD
Если получается инкапсулировать достаточно сложный элемент как полностью самостоятельный кусок UI - честь вам и хвала.
это уже про
ViewGroup + ViewGroupViewModel/ViewGroupPresenterАЕ
Да, конечно.
АЕ
это уже более сложный вариант. Я говорю про обычные списки, про которые и был вопрос
Разумеется, надо вовремя грань провести, когда список "умнеет" :)
IM
ViewHolder должен быть тупой. Если приходится делать презентер для ViewHolder, то где-то допущена ошибка
эм... не вижу противоречия. Вью-холдер остается тупым. Но вместо одной вью, которая занимается задачами типа отобрози вот это состояние на элементе по такому индексу, появляется две вью. Одна умеет добавить\удалить итем, другая - отобразить состояние.
Обе работают как обычные вью.
Единственная сложность - делегирование onBind() и определение OnResume. Но это сложность конкретно моя. Т.К. я у себя принимаю за дефолт, что все View : LifecycleOwner.
При типичных attach()\detach() ее не должно возникать
Обе работают как обычные вью.
Единственная сложность - делегирование onBind() и определение OnResume. Но это сложность конкретно моя. Т.К. я у себя принимаю за дефолт, что все View : LifecycleOwner.
При типичных attach()\detach() ее не должно возникать
IM
казалось бы, откажитесь просто от рх, нет, они продолжают доказывать, что нужен
Кто тебе доказывает, что он нужен? Он удобен. Те, кому он удобен - могут использовать. Если тебе не нравится - приверженцы реактивного программирования не будут искать тебя ночами с факелами)
(
Ihor Martyniuk
Кто тебе доказывает, что он нужен? Он удобен. Те, кому он удобен - могут использовать. Если тебе не нравится - приверженцы реактивного программирования не будут искать тебя ночами с факелами)
вот ты и попался в ловушку постмодерна
IM
вот ты и попался в ловушку постмодерна
А теперь то же самое , только на русском и без выебонов, если можно)
(
Ihor Martyniuk
А теперь то же самое , только на русском и без выебонов, если можно)
ща бы на набросы про рх отвечать
DE
Ihor Martyniuk
эм... не вижу противоречия. Вью-холдер остается тупым. Но вместо одной вью, которая занимается задачами типа отобрози вот это состояние на элементе по такому индексу, появляется две вью. Одна умеет добавить\удалить итем, другая - отобразить состояние.
Обе работают как обычные вью.
Единственная сложность - делегирование onBind() и определение OnResume. Но это сложность конкретно моя. Т.К. я у себя принимаю за дефолт, что все View : LifecycleOwner.
При типичных attach()\detach() ее не должно возникать
Обе работают как обычные вью.
Единственная сложность - делегирование onBind() и определение OnResume. Но это сложность конкретно моя. Т.К. я у себя принимаю за дефолт, что все View : LifecycleOwner.
При типичных attach()\detach() ее не должно возникать
ViewHolder должен уметь просто представить данные (готовые данные) в удобной пользователю форме. Адаптер тоже должен получать уже готовые данные. Если нужно, то ViewHolder может кинуть эвент, что на него где-то нажали. Этот эвент ты можешь обработать, где хочешь. По факту api у твоего списка должно быть такое: myAdapter.updateData(data). Если приходится накручивать какую-то сложную логику, то надо делать это со стороны. Инкапсулируй свой список в какой-нибудь контроллер и используй его. Но делать презентер для каждого вью холдера - это жестко. Хотя мб я чего-то не понимаюю
AD
ViewHolder должен уметь просто представить данные (готовые данные) в удобной пользователю форме. Адаптер тоже должен получать уже готовые данные. Если нужно, то ViewHolder может кинуть эвент, что на него где-то нажали. Этот эвент ты можешь обработать, где хочешь. По факту api у твоего списка должно быть такое: myAdapter.updateData(data). Если приходится накручивать какую-то сложную логику, то надо делать это со стороны. Инкапсулируй свой список в какой-нибудь контроллер и используй его. Но делать презентер для каждого вью холдера - это жестко. Хотя мб я чего-то не понимаюю
> мб я чего-то не понимаюволшебная фраза, которая весь негатив сводит на нет
DE
> мб я чего-то не понимаюволшебная фраза, которая весь негатив сводит на нет
да, особенно когда негатива нет
DE
эта фраза говорит о том, что я не являюсь источником истины, а просто выражаю свое мнение
DE
по факту я могу ошибаться
МE
> мб я чего-то не понимаюволшебная фраза, которая весь негатив сводит на нет
😂👍
IM
ща бы на набросы про рх отвечать
Возникает смутное подозрение, что ты, парень склонен к спору ради спора