GR
долго ждать что-то, та компоуз это ж про интерфейс больше, в идеале все что ниже вообще изменяться не должно
Presenter{
State getState();
}
Где- то тут видел, что Presenter всегда должен возвращать void, но не понимаю, чем это обусловленноSize: a a a
2020 September 28
JF
Добрый день, есть ли нарушения архитектурных принципов, в таком методе?
P
Однозначно есть. Презентер не должен возвращать state
NT
Добрый день, есть ли нарушения архитектурных принципов, в таком методе?
Presenter{
State getState();
}
Где- то тут видел, что Presenter всегда должен возвращать void, но не понимаю, чем это обусловленноВ принципе ни что не мешает вам так сделать, но в таком случае получается что появляется лишняя логика во вью, а её лучше держать как можно тупее. Плюс получается явная зависимость на презентер. Кажется в таком случае лучше все же чтобы у вью был метод displayState(State) и отрабатывать Стейт уже там. То есть чтобы презентер пинал вью
P
Добрый день, есть ли нарушения архитектурных принципов, в таком методе?
Presenter{
State getState();
}
Где- то тут видел, что Presenter всегда должен возвращать void, но не понимаю, чем это обусловленноВ презентере не должно быть ничего кроме onУВьюЧтоЧтоСлучилось()
JF
у меня подключаются Fragment'ы через viewPager, и они должны отобразить части текущей модели (цвет и иконка).
Presenter делается платформо-независимым и дазайно-независимым (будет перенос на другую платформу)
Когда создается Activity - фрагменты еще не подключены к ней, поэтому в
Presenter делается платформо-независимым и дазайно-независимым (будет перенос на другую платформу)
Когда создается Activity - фрагменты еще не подключены к ней, поэтому в
onResume() не могут получить вызов showColor()/showIcon()P
onResume() делегируй презентеру. И уже презентер дёрнет методы вьюшки для установки состояния
ES
Добрый день, есть ли нарушения архитектурных принципов, в таком методе?
Presenter{
State getState();
}
Где- то тут видел, что Presenter всегда должен возвращать void, но не понимаю, чем это обусловленноЕдинственное, что может возвращать презентер это подготовленные данные, которые сразу юзаются во вью, но никак не обрабатываются там.
CN
В презентере не должно быть ничего кроме onУВьюЧтоЧтоСлучилось()
А если мне в oncreate нужно инициализировать рекуклер, а для этого вызвать презентер и т.д,то как назвать метод для этого?
P
onViewCreated()
CN
Аа, логично
CN
Ребят, не могу понять, мы ведь в презентер выносим всю логику, а в представлении оставляем только функции для изменения ui, но тогда почему автор в статье по mvp пишет такой код в активити...
CN
Разве это не логика?
P
Думаю, тут действительно не правильно. Эту логику лучше вынести в презентер
CN
Боже, как тут вообще разобраться, в статьях по mvp все предлагают разные архитектуры и подходы, ещё и ошибки.
P
Для MVP используй библиотеку Moxy. Она не даст накосячить :)
CN
Подскажи ещё, пожалуйста, в примере выше, как нам передать drawer и прочие компоненты view в презентер. Через аргументы соответствующего метода в презентере, или новую функцию в view писать?
P
Drawer, как и другие View ни в коем случае не надо передавать в презентер.
Это должно быть примерно так:
View.onBackPressed() { presenter.onBackPressed() }
Presenter.onBackPressed() {
view.closeDrawer()
}
View.closeDrawer() {
/// Найти Drawer и закрыть
}
Это должно быть примерно так:
View.onBackPressed() { presenter.onBackPressed() }
Presenter.onBackPressed() {
view.closeDrawer()
}
View.closeDrawer() {
/// Найти Drawer и закрыть
}
Kd
стэйт дровера передай а не его самого, даже если это просто флаг
CN
Да, это я понимаю, нов примере выше чел проверяет состояние drawer, чтобы дальше че-то делать . Мы не можем перенести эту строчку в презентер, но и не можем оставить во view