A
Не, пока сижу в их чатике и слушаю как пользуются другие)
Вообще это не Фреймворк, дак что чичероне впилить/выпилить - не больно вовсе
Size: a a a
2017 January 25
EM
Я думаю, что подобное чувство у всех. Я вот на Moxy подсел и тем не менее, как гласит вики, даже у Moxy не MVP. Но тут уже вопрос о целях. Так как смысл строить MVP ради MVP, ведь как и у любого шаблона то ли проектирования или ещё чего, есть одна большая проблема - желание строго следовать этому шаблону.
тут кстати есть один из создателей moxy @xanderblinov
думаю, он всегда будет рад подсказать =)
думаю, он всегда будет рад подсказать =)
A
Снова упомяну Moxy, ведь с помощью неё можно добиться того же что и с Чичероне
EM
Снова упомяну Moxy, ведь с помощью неё можно добиться того же что и с Чичероне
там есть типа Router?
AK
Снова упомяну Moxy, ведь с помощью неё можно добиться того же что и с Чичероне
Это как это?
A
там есть типа Router?
Да, там две основные сущности: Router, Navigator. Навигатор осуществляет саму навигацию (логика) и каждая Активити его инициализирует по своему учитывая свой жизненный цикл. А между всем этим там ещё и стек, который позволяет сохранить намерение перехода (команду) если вдруг нет навигатора (в ситуации, когда экран к примеру свернут), а после накатить ее.
A
Router - взаимодействие со стеком команд. Он и манипулирует очередью и через него и осуществляется (через него и отсылаются) команды в навигатор.
ВБ
Да, там две основные сущности: Router, Navigator. Навигатор осуществляет саму навигацию (логика) и каждая Активити его инициализирует по своему учитывая свой жизненный цикл. А между всем этим там ещё и стек, который позволяет сохранить намерение перехода (команду) если вдруг нет навигатора (в ситуации, когда экран к примеру свернут), а после накатить ее.
Вы о разном, Евгений спросил про Moxy, а ты рассказываешь про Чичероне
A
Это как это?
Дак разницы между ними то и нет почти.
A
Да, там две основные сущности: Router, Navigator. Навигатор осуществляет саму навигацию (логика) и каждая Активити его инициализирует по своему учитывая свой жизненный цикл. А между всем этим там ещё и стек, который позволяет сохранить намерение перехода (команду) если вдруг нет навигатора (в ситуации, когда экран к примеру свернут), а после накатить ее.
Ой, да, это я про Чичероне.
AK
Дак разницы между ними то и нет почти.
Если вы про чичероне и абсолютли, то согласен, если же Мокси и одна из этих двух, то не согласен))
A
Что качается Moxy. Там нет навигации и Router, ну дак в итоге хоть это и выглядит не явно, но Moxy умеет решать ту же задачу
A
До Чичероне я выполнял всю навигацию через Moxy (стратегию лишь написал свою для этого) и проблем не было. Узнал о Чичероне, ну да, теперь более наглядно, визуально видно, некоторые моменты решаются элегантнее, но по сути ничего не изменилось.
A
Тем не менее, не жалею и даже советовал бы попробовать)
EM
что ж, попробуем =)
AB
Всем привет, в основе Чичероне лежит идея из Мокси про буфер команд. Отличие только в распределении ответственности - отделился роутер. Это удобно для нелинейных сценариев. Для линейных немного оверхэд
AB
На самом деле все решения в архитектуре - это трейдоф между гибкостью, прозрачность и тем, как много кода придется писать
AB
К вопросу выше про MVP:
Попробуйте сделать, чтобы все методы интерфейса (в широком смысле) взаимодействия презентера и вью были void
Попробуйте сделать, чтобы все методы интерфейса (в широком смысле) взаимодействия презентера и вью были void
AB
Самая частая ошибка - путаница с потоками данных. Презентер становится хелпером для вью. Void методы помогут этого избежать
EM
И появляются методы типа
Object presenter.get.. и
Object view.get...
Да, полностью поддерживаю. Данные методы должны быть void
Object presenter.get.. и
Object view.get...
Да, полностью поддерживаю. Данные методы должны быть void