Да

у нас в команде стараются придерживаться другого принципа относительно презентеров:
презентер должен быть написан так, чтоб если я его закину, допустим, в десктопное приложение, то он и там работал так же без изменения кода.

У нас немного по-другому, мы подгоняем наши подходы с учетом шероховатостей фреймворка чтобы в конечном итоге было удобно работать. К тому же точно известно что этот код нигде кроме Андроида использоваться не будет

@IgorOzerkin @mansonheart
форвардните итого с канала мокси
думаю, будет интересно тут =)

Решил форварднуть таки :)

Для DI используем вот такой подход: в Application есть ссылка на ComponentManager. Его задача инициализировать и отдавать компоненты по запросу. Есть BaseComponent который предоставляет базовые зависимости, которые нужны везде. Его мы обычно singleton скопом помечаем. Далее используем subComponent с другими скопами, жизненым циклом которых мы управляем сами через componentManager. SubComponent продумываем таким образом, чтобы он использовался для конкретных задач логически связанных. Например нам нужен компонент, который будет предоставлять зависимости только для работы с новостройками (это из нашего проекта). Т.е этот компонент предоставляет нам модели для работы с новостройками/конкретной новостройкой, фильтрами и т.д. Соответственно нужно понимать когда и как нам инициализировать компонент. Для этого нужно понять кто в связке MVP кого создает. Презентер создает View, соответственно и вью должна позаботиться о его иниализации так, как нужно. Пускай это будет даггер. Но нам нужен компонент. Вот тут идет в ход componentManager и subComponent. Мы открываем активити и в методе onCreate просим componentManager предоставить нужный компонент. Пусть будет BuildingsComponent. Чтобы память не текла нужно сабкомпоненты занулять когда активити финиширует (это делает все тот же componentManager, т.к ссылки на компоненты хранятся в нем). Через аннотацию providePresenter мы создаем презентер и инжектим в него то, что нам нужно либо через конструктор, либо через Component.injext(Presenter), либо через сеттеры. Тут дело вкуса. Если хотите тестами покрывать презентеры, то делайте через конструктор или сеттеры. Елсли не хотите тестами покрывать и усложнять себе жизнь методами с аннотацией providePresenter то делайте инжект прямо в презентере. Тут кто-то уже показывал кусок кода.  Вьюхолдеры у нас без презентеров. Нам всегда хватает одного презентера на экран.

Презентер создает вью - имеется ввиду что ВьюхА создает Презентер (она его) =)

В нашем проекте мы не используем чичероне, так как в этом нет необходимости. Все решается через IntentStarter который запускает активити. Если используем фрагменты внутри активити, то делаем  интерфейсы навигации которые реализуют активити и фрагменты используют их для навигации между экранами

Для передачи событий между экранами(презентерами/моделями) используем subject-ы

А мокси - это просто ооочень хорошее дополнение, которое делает вашу жизнь слащщще=)

@IgorOzerkin а если один сабкомпонент нужен на двух активити подряд?

Как компонент менеджер разруливпет?

Если логика такая что из первой активити запускается вторая, то первая активити запускает инициализацию сабкомпонента через componentManger и делает его release если в onDestory метод isFinishing == true

А вторая активити просит компонент менеджер дать ей нужный компонент

Там нужно конечно смотреть на логику что да как. Чтобы компоненты могли восстановиться если процесс убит будет

Хотяы по цепочке пытаться восстановить компоненты

А как понять какая активити первая?

Ты имеешь ввиду что мы из какого-то экрана А можем запустить активити B или C и какой из экранов B или C считать первым?

Да, b и c хотят один и тот же компонент. Из логики приложения мы можем запустить раньше и то и другое. Как понять когда грохать сабкомпонент

из B в C и наоборот попасть можно?