T
Плохая практика, как по мне. Нужно стараться писать небольшие методы, которые отвечают за одно логически обособленное действие. Лучше отдельный метод для каждой кнопки
внутри свитча как раз и вызываются потом "небольшие методы"
Size: a a a
2020 November 01
I
V
внутри свитча как раз и вызываются потом "небольшие методы"
И вот представь теперь, будет свитч , в который подставляют айдишник, и который сетит действия кнопкам. Каждый раз, для каждой кнопки его прийдётся дернуть. Каждый раз будет сравнение переданного айдишника с кейсом. Зачем лишняя нагрузка?
T
И вот представь теперь, будет свитч , в который подставляют айдишник, и который сетит действия кнопкам. Каждый раз, для каждой кнопки его прийдётся дернуть. Каждый раз будет сравнение переданного айдишника с кейсом. Зачем лишняя нагрузка?
не вижу никакой нагрузки. нормальный паттерн проектирования, где у тебя есть один метод onClick который хендлить все нажатия и дюжина функциональных методов, там, deleteVideo(), renameVideo() - тебе не важно как их вызвали - кнопкой или событием
СП
Я хуже видел. В onBind ресайклера на каждый из 100500 элементов вешается свой, персональный слушатель из анонимного класса.
VA
И вот представь теперь, будет свитч , в который подставляют айдишник, и который сетит действия кнопкам. Каждый раз, для каждой кнопки его прийдётся дернуть. Каждый раз будет сравнение переданного айдишника с кейсом. Зачем лишняя нагрузка?
Нагрузки никогда не будет, а ты говоришь про практику CLEAN CODE каждый метод отвечает за одну задачу а вот это одна задача ты решаешь какая и она абстрактная в общем там нагрузки не может быть из-за кода
VA
не вижу никакой нагрузки. нормальный паттерн проектирования, где у тебя есть один метод onClick который хендлить все нажатия и дюжина функциональных методов, там, deleteVideo(), renameVideo() - тебе не важно как их вызвали - кнопкой или событием
Скажи немного про практику, конечно ты должен следовать паттерну MVVM не только для того чтобы у тебя код был организован хорошо и чтоб твой activity не был заселен функциями которые не имеет отношения к UI
ES
Скажи немного про практику, конечно ты должен следовать паттерну MVVM не только для того чтобы у тебя код был организован хорошо и чтоб твой activity не был заселен функциями которые не имеет отношения к UI
Не только для этого
VA
Плохая практика, как по мне. Нужно стараться писать небольшие методы, которые отвечают за одно логически обособленное действие. Лучше отдельный метод для каждой кнопки
А про отдельными для каждой кнопки Да согласен
VA
Не только для этого
Я это чересчур абстрактно написал
ES
Как минимум для правильной работы в команде и удобной тестируемости каждых компонентов архитектуры
VA
Как минимум для правильной работы в команде и удобной тестируемости каждых компонентов архитектуры
Как я и сказал это чересчур абстрактно написано только потому что я увидел что там есть методы которые должны отвечать за какие-то удаление видео этому подобное то сразу хотел написать что их нужно перебрасывать из activity в другие места ну уж точно не в VIEWMODEL
V
не вижу никакой нагрузки. нормальный паттерн проектирования, где у тебя есть один метод onClick который хендлить все нажатия и дюжина функциональных методов, там, deleteVideo(), renameVideo() - тебе не важно как их вызвали - кнопкой или событием
И будет под сотню проходов по свичу для дюжины методов. Зачем?
Если можно засетить кнопке действие и все. Зачем свитч?
Если можно засетить кнопке действие и все. Зачем свитч?
СП
В активности хорошо бы вообще никакого кода не иметь кроме обработчиков онКриэйт/онСтоп
СП
И будет под сотню проходов по свичу для дюжины методов. Зачем?
Если можно засетить кнопке действие и все. Зачем свитч?
Если можно засетить кнопке действие и все. Зачем свитч?
Ну, к примеру, кнопки в контейнере как у управления медиаплеером - логичнее их в одном месте обрабатывать и отдельно от кода скажем клика по сикбару
СП
Может быть общий код который обрабатывает все кнопки в любом случае, а потом индивидуально.
ES
В активности хорошо бы вообще никакого кода не иметь кроме обработчиков онКриэйт/онСтоп
Кстати имея лайфсайклер обсервера в вм можно вообще пробросить всю логику жц активити в вм.
T
И будет под сотню проходов по свичу для дюжины методов. Зачем?
Если можно засетить кнопке действие и все. Зачем свитч?
Если можно засетить кнопке действие и все. Зачем свитч?
>И будет под сотню проходов по свичу для дюжины методов.
ну... если у тебя сто кнопок, только если
ну... если у тебя сто кнопок, только если
VA
>И будет под сотню проходов по свичу для дюжины методов.
ну... если у тебя сто кнопок, только если
ну... если у тебя сто кнопок, только если
Нет @v_ladyshka правильно говорит скажем у тебя Ты под котлин да работаешь? Ну так завижи листенеры на каждой кнопке и все, а вот код скинешь своего активити
VA
Кстати имея лайфсайклер обсервера в вм можно вообще пробросить всю логику жц активити в вм.
Логику чего?