Size: a a a

Android Architecture

2017 January 31

AE

Alexey Elisov in Android Architecture
у меня так получилось в активити-контейнере
class GameActivity extends AppCompatActivity implements GameContract.View, GameContract.Router

и в фрагментах
mPresenter = new LevelsPresenter();
mPresenter.attachView(this);
mPresenter.attachRouter((GameActivity) getActivity());
источник

DC

Denis Chuvasov in Android Architecture
тут смотря, что ты подразумеваешь под роутером. По мне это отдельный класс, который разруливает навигацию и отвечает только за навигацию
источник

AT

Andrey T in Android Architecture
VIPER - это MVP с интеракторами и роутерами, разве не так?
источник

DC

Denis Chuvasov in Android Architecture
именно так
источник

AD

Andrew Dementiev in Android Architecture
Там еще model нет
источник

DC

Denis Chuvasov in Android Architecture
по моему мнению
источник

EM

Eugene Matsyuk in Android Architecture
А Репозиториев там нет, шоли?
источник

DC

Denis Chuvasov in Android Architecture
там все есть, просто все это domain уровень и на нем рулит интерактор
источник

AD

Andrew Dementiev in Android Architecture
Eugene Matsyuk
А Репозиториев там нет, шоли?
Оно не входит в стандартную поставку, буква Е это entity, тупо объект, описывающий сущность
источник

DC

Denis Chuvasov in Android Architecture
Интеракторы скрывают в себе бизнес-логику. Звучит довольно страшно, ведь за этим кроется много работы, которую стоит разделять между специализированными классами. К тому же часто один и тот же код нужно переиспользовать в нескольких интеракторах. Нам было нужно общее понимание того, как это делать, чтобы не изобретать свои велосипеды в каждом проекте.

Мы решили ввести дополнительный слой сервисов. Сервис - объект, отвечающий за работу со своим определенным типом модельных объектов. Например, сервис новостей отвечает за получение списка новостей в определенной категории, а так же подробной информации о каждой новости. Сервис авторизации отвечает за, собственно, авторизацию, восстановление пароля, обновление сессии и так далее. У сервисов, в свою очередь, есть зависимости на объекты нижнего уровня, отвечающие за работу с сетью или базой данных.

Сервисы инжектируются в интерактор. В итоге интерактор в основном служит фасадом, взаимодействующим с сервисами и передающим полученные от них данные презентеру
источник

DC

Denis Chuvasov in Android Architecture
выдержка из книги от рамблера https://etolstoy.gitbooks.io/the-book-of-viper/content/
источник

EM

Eugene Matsyuk in Android Architecture
ну это же пропоганда врагов! =)
источник

AD

Andrew Dementiev in Android Architecture
Я так к единому мнению не пришел по поводу випера, он без либ абстрактно моим мозгом не реализуется
источник

EM

Eugene Matsyuk in Android Architecture
это же iOS)
источник

AD

Andrew Dementiev in Android Architecture
Я изучать иос сейчас
источник

AD

Andrew Dementiev in Android Architecture
Как в делфи вернулся
источник

EM

Eugene Matsyuk in Android Architecture
совсем мрак?
источник

AD

Andrew Dementiev in Android Architecture
Нет, но гибкосте нехватает
источник

AD

Andrew Dementiev in Android Architecture
Тоесть либо так, либо костыли
источник

EM

Eugene Matsyuk in Android Architecture
Denis Chuvasov
Интеракторы скрывают в себе бизнес-логику. Звучит довольно страшно, ведь за этим кроется много работы, которую стоит разделять между специализированными классами. К тому же часто один и тот же код нужно переиспользовать в нескольких интеракторах. Нам было нужно общее понимание того, как это делать, чтобы не изобретать свои велосипеды в каждом проекте.

Мы решили ввести дополнительный слой сервисов. Сервис - объект, отвечающий за работу со своим определенным типом модельных объектов. Например, сервис новостей отвечает за получение списка новостей в определенной категории, а так же подробной информации о каждой новости. Сервис авторизации отвечает за, собственно, авторизацию, восстановление пароля, обновление сессии и так далее. У сервисов, в свою очередь, есть зависимости на объекты нижнего уровня, отвечающие за работу с сетью или базой данных.

Сервисы инжектируются в интерактор. В итоге интерактор в основном служит фасадом, взаимодействующим с сервисами и передающим полученные от них данные презентеру
У себя я реализовывал кстати схожим образом.
Если большая бизнес-логика, то есть Интерактор-фасад, а он уже дергает вспомогательные классы только по сути. Так все получается довольно изолированно и легко подменяемо. Только я не называл эти вспомогательные классы сервисами, ибо это как-то не совсем подходящее название.
Джависты с серверным прошлым, поправьте меня по сервисам
@sandrb @kirillf
источник