(
Плюс, как вы верно заметили, редьюс должен работать на Schedulers.single, и если редьюс работает ощутимо медленнее, чем приходят ивенты, юай будет выглядеть странно
Size: a a a
2020 February 21
U
Плюс, как вы верно заметили, редьюс должен работать на Schedulers.single, и если редьюс работает ощутимо медленнее, чем приходят ивенты, юай будет выглядеть странно
А как он у тебя окажется медленнее ивентов?
(
Не то чтобы будет проседать фпс, просто если обновления состояния приходят на 500-600 миллисекунд позже ивента, это заметно
(
А как он у тебя окажется медленнее ивентов?
Например, если ты там ещё будешь статик леяуты межурить 🌚
U
Например, если ты там ещё будешь статик леяуты межурить 🌚
Ну так не делай зла в редюсере, ну
(
Ну так не делай зла в редюсере, ну
Кто делает? Никто не делает
I
В MVI явно прописан стейт, и это офигенно. А в MVP/MVVP мы фигачим какие-то события в View, и надеемся, что там оно как-нибудь нормально отобразится. Уровень детерминированности очень разный получается)
согласен про уровень детерминированности, но другие паттерны работают и все ок отображают, тут уже зависит от опыта программиста не отображать условно ошибку и вью одновременно
АЕ
не понял
I
Придётся запариться с производительностью и крутить всякие странного вида вещи, чтобы подружить декларативный by-design рендер с императивным андроидом
можно на конкретном примере?
U
можно на конкретном примере?
Нельзя просто взять и отобразить стейт
U
Я, например, дроблю его на части при рендере, чтобы при изменении, например, заголовка, не перерисовать изображения
I
не понял
детерминированность скорее зависит не от паттерна, а от опыта программиста, понятно, что MVI как раз её четко ограничивает, а в MVVM и MVP ты её контролируешь сам
АЕ
детерминированность скорее зависит не от паттерна, а от опыта программиста, понятно, что MVI как раз её четко ограничивает, а в MVVM и MVP ты её контролируешь сам
да, и получается, что если всё делать правильно и честно, MVP и MVVM оба превращаются в MVI :)
U
А ещё MVP и mvvm с большей вероятностью могут поймать гонку, но это уже сильно крайности
(
детерминированность скорее зависит не от паттерна, а от опыта программиста, понятно, что MVI как раз её четко ограничивает, а в MVVM и MVP ты её контролируешь сам
Простая математика. Юай - это машина Мура, в случае MVI - well-behaved, в случае МВП машина становится блэкбоксом, в который вы кидаете транзишены, надеясь, что он находится в правильном состоянии, чтобы по нему перейти
(
MVVM под вопросом, но лично меня этот паттерн вполне устраивает, особенно с каким-нибудь Lychee
AA
Простая математика. Юай - это машина Мура, в случае MVI - well-behaved, в случае МВП машина становится блэкбоксом, в который вы кидаете транзишены, надеясь, что он находится в правильном состоянии, чтобы по нему перейти
а как в мвп может быть неправильное состояние?
з.ы. я понимаю о чем ты, я не могу представить такую ситуацию
з.ы. я понимаю о чем ты, я не могу представить такую ситуацию
I
да, и получается, что если всё делать правильно и честно, MVP и MVVM оба превращаются в MVI :)
))) да MVI является неким логическим продолжением MVP MVVM))
(
а как в мвп может быть неправильное состояние?
з.ы. я понимаю о чем ты, я не могу представить такую ситуацию
з.ы. я понимаю о чем ты, я не могу представить такую ситуацию
Так куча же примеров. Например, у вас на экране могут быть данные, прогрессбар и ошибка, из прогрессбара можно перейти в данные или в ошибку, из ошибки в прогрессбар, данные - конечное состояние
Ничего не защищает вас от попытки перехода, например, из ошибки в данные. Да, в мвиай это тоже на вашей совести, но вы хотя бы об этом знаете
Ничего не защищает вас от попытки перехода, например, из ошибки в данные. Да, в мвиай это тоже на вашей совести, но вы хотя бы об этом знаете
(
Ну и пример конечно тривиальный, но наверняка нетрудно представить, насколько все становится хуже, когда состояния не три, а тридцать