Так в Model вы и не знаете про View ни чего. Две реализации только в том случаи если вы имеете два разных виджета т.е в первом случаи вы получаете текст запроса из edittext-а, а во втором из spinner-а, при этом интерфейс доступа к данным у вас один и тот же, а каждая реализация оборачивает свои UI элементы в Model, представляя общий интерфейс доступа к данным.
Если мы говорим о действительно разном наборе виджетов, что чем вас не устраивает самый тривиальный вариант:
Model model = isTable ? new TableModelImpl(...) : new PhoneModelImpl(...)
View view = isTable ? new TableViewImpl(...) : new PhoneViewImpl(...)
Presenter presenter = new Presenter(model, view);
В данном случаи ссылаются на одни и те же UI элементы конкретные реализации, поэтому действительно фраза не совсем верная, хотя дальше видно по примеру что имелось ввиду.
По поводу разделение — оно делается, что бы представить программу в простом линейном виде: получение данных -> обработка данных -> отображение данных
Так как UI элементы в данном случаи будут выступать и как источник данных и элементы для отображение, то ссылки естественно возникают в реализации Model и View, Presenter связывает Model с View.
В итоге получаем схему:
Presenter {
Model model = ...
View view = ...
onCreate(...) {
model.getData(...).flatMap(...).subscribe(view.show());
}
}
Задача работы с сетью в рамках android-а предполагает наличие отдельного патока и его правильного старта, учитывающая повороты, закрытие экрана. Далее идут задачи по обработке отсутствие сети (как, в общем-то, было указано в статье) и т.д
Все выше сказанное проистекает из одного факта, задача ввести что-то -> отправить на сервер и загрузить что-то -> отобразить не является такой уж тривиальной, как может показаться на первый взгляд.
?
По поводу разделение — оно делается, что бы представить программу в простом линейном виде: получение данных -> обработка данных -> отображение данных
Так как UI элементы в данном случаи будут выступать и как источник данных и элементы для отображение, то ссылки естественно возникают в реализации Model и View, Presenter связывает Model с View.
В итоге получаем схему:
Все выше сказанное проистекает из одного факта, задача ввести что-то -> отправить на сервер и загрузить что-то -> отобразить не является такой уж тривиальной, как может показаться на первый взгляд.