Вопросы о подходе

[RomanTruba]

Здравствуйте. Посмотрел ваш доклад с Mobius, тема очень интересная и полезная. У меня по демо проекту пара вопросов.

1. Вы говорили, что вьюшка не должна сама управлять ничем, а у вас главная вьюшка получается сама рулит фрагментами. Нехорошо.
2. Из этого исходит, что должен быть какой-то роутер, или другая бизнес логика, управляющая переходами. Как она может выглядеть?
3. Для проекта на три экрана выходит невероятное количество файлов и классов. Можно ли было бы использовать какие-то средства автогенерации кода? Во всей этой истории меня больше всего смущает это. Кажется, что мы одну сложность, переводим в другую, хоть и более архитектурно верную. Спасибо.

[matzuk]

Добрый вечер! С удовольствием отвечу.

1. Да, вьюшка ничего сама не делает. Presenter ей просто говорит, что нужно показать такой-то экран. Но так как в Presenters и Interactors мы не используем Android классы (за исключением Context, например), то весь android код, который необходим для запуска другого фрагмента, будет во View. Да, получается несколько двоякая ситуация. По идее Presenter говорит, что делать. Но в самой View находится код, позволяющий осуществить переход.
2. Плавно переходим ко второму вопросу. Если управление переходами тривиальное, например, с первого экрана перейти на второй, потом на третий, то я считаю, что приведенный в примере код вполне подходит. View же не сама принимает решение, ей Presenter приказал. А как выполнить, это дело View. Но если логика переходов более сложная, то имеет смысл ввести Router. Но вопрос в том, на каком именно уровне он должен располагаться. А самое интересное - а как протестировать то. Вообщем тема для исследований и дум. Может у вас есть наработки и свое видение в этом отношении? Буду рад послушать.
3. Для интереса, напишите без всяких абстракций и прочего и сравните количество строчек кода. Уверен, что с чистой архитектурой у вас выйдет не намного более. Разница будет минимальной на самом деле. Другое дело, что вы получаете разделенную на вертикальные и горизонтальные слои приложение, где легко можете каждый модуль подменить или поправить. Кроме того такой код намного проще сопровождать. Что касается автогенерации, то я ее использую только в рамках Dagger 2. Автоматическую генерацию Presenters, Interactors и прочего даже не встречал. Но есть всякие абстракции, позволяющие убирать дублирующий код типа bindView, unbindView. По мне это все несколько усложнение понимания.