AD
Есть, разумеется, просто она там не так явна, что, на мой взгляд, ещё хуже.
Да вот как раз-таки в данном случае нет проблем
Size: a a a
2019 December 10
KD
Да вот как раз-таки в данном случае нет проблем
Её и в MVP нет, т.к. задача не правильно поставлена.
Презентер не работает с несколькими вью.
Презентер не работает с несколькими вью.
AD
Её и в MVP нет, т.к. задача не правильно поставлена.
Презентер не работает с несколькими вью.
Презентер не работает с несколькими вью.
Вот, а VM может 🙂
IG
Вот, а VM может 🙂
Только это вероятнее всего кривая архитектура. 🙂
KD
Вот, а VM может 🙂
И от этого идут проблемы неявной работы, что ужасно
KD
А именно "мочь" и презентер может, только это никому в здравом уме не нужно.
AD
Не согласен с вами, но кого это не волнует
И
Да вот как раз-таки в данном случае нет проблем
Данный кейс, изначально кривой. И по нему сравнивать, как минимум - неправильно
2019 December 11
AD
Данный кейс, изначально кривой. И по нему сравнивать, как минимум - неправильно
Да почему кривой?)
Для меня данный кейс выглядит так, что товарищ хочет одни и те же данных в двух разных местах отображать. Что-то а-ля состояние сети в списке диалогов и в конкретном диалоге.
Допускаю, конечно, что он хочет одним презентером две несвязанные вьюхи контролировать, но кто его знает. В этом случае мне уже не нравится идея.
Для меня данный кейс выглядит так, что товарищ хочет одни и те же данных в двух разных местах отображать. Что-то а-ля состояние сети в списке диалогов и в конкретном диалоге.
Допускаю, конечно, что он хочет одним презентером две несвязанные вьюхи контролировать, но кто его знает. В этом случае мне уже не нравится идея.
IG
Да почему кривой?)
Для меня данный кейс выглядит так, что товарищ хочет одни и те же данных в двух разных местах отображать. Что-то а-ля состояние сети в списке диалогов и в конкретном диалоге.
Допускаю, конечно, что он хочет одним презентером две несвязанные вьюхи контролировать, но кто его знает. В этом случае мне уже не нравится идея.
Для меня данный кейс выглядит так, что товарищ хочет одни и те же данных в двух разных местах отображать. Что-то а-ля состояние сети в списке диалогов и в конкретном диалоге.
Допускаю, конечно, что он хочет одним презентером две несвязанные вьюхи контролировать, но кто его знает. В этом случае мне уже не нравится идея.
Потому что пусть в таком случае сделает отдельный преиспользуемый виджет.
IG
В противном случае это две разных вьюхи и два разных презентера
AD
Потому что пусть в таком случае сделает отдельный преиспользуемый виджет.
Два виджета, одни данные 🙄
IG
Два виджета, одни данные 🙄
Два виджета - два презентера/vm - одни данные
C
Сейчас дописываю под Андроид проект на c#/xamarin, все не успеваю реальные примеры на мокси поизучать, но параллельно думаю над ним и вот что мне не понятно. Получается что есть некий один метод у презентера, точнее у ViewState в котором вызваются все методы рендеринга UI View друг за другом
C
Но это тоже не правильно, когда скопом вся графика отрисовывается в одном методе каждый раз
AD
Сейчас дописываю под Андроид проект на c#/xamarin, все не успеваю реальные примеры на мокси поизучать, но параллельно думаю над ним и вот что мне не понятно. Получается что есть некий один метод у презентера, точнее у ViewState в котором вызваются все методы рендеринга UI View друг за другом
Нет, получается совсем не так) Есть ViewState, у которого вызываются разные методы
C
Нет, получается совсем не так) Есть ViewState, у которого вызываются разные методы
По событиям от модели через презентер так?
L
вьюСтэйт по сути является буфером команд которые надо выполнить после пересоздания вьюхи
C
вьюСтэйт по сути является буфером команд которые надо выполнить после пересоздания вьюхи
Насчет пересоздания тоже не понятно, ведь можно просто выставить флаги и активити послеи поворота не будет пересоздаваться
L
ну это типа ламерский способ и использовать его не рекомендуется, хотя на самом деле используется в разных крупных приложениях. я о нем узнал не так давно, поэтому не могу в полной мере дать оценку такому решению)