что за баундари классы? не совсем понял

Boundary

Обсуждалось как-то, что в простом приложение каких уровней абстракций может не быть, к примеру интерактор и презентер могут объединиться.

+1

Я ха

За))

Кто где хранит appComponent (singleton) для даггера?

В sample Moxy app ребята используют статическую переменную и статические же геттеры сеттеры. Удобно - не надо доставать объект application и кастовать его. В добавок, можно делать инъекцию из метода onFirstViewAttach() презентера, получив статический компонент приложения.

Есть ли в этом подходе минусы относительно хранения компонента в обычном, не статическом, поле Application?

Лучше делать отдельный класс ComponentManager. Обычно его инициализируешь в Application. Это разгрузит Application класс

О, я как раз по вашей статье сейчас и пытаюсь построить основу приложения)

"I prefer to inject a model into a presenter with Dagger (good method for injecting a model into a presenter is onFirstViewAttach) and make communication using Rx."

@gaketo лучше вообще в конструкторе инжектить

это позволит раньше начать инициализацию

метод onFirstViewAttach довольно специфичен. Обычно все что хочется им решить решается OneExecuteStrategy стратегией

Спасибо, перенесу в конструктор. Component manager - штука, которая нужна для  DI. А как его инжектировать?) Или просто ограничиться статическими методами?

Стоит ли сделать его полем Application и доставать через него?

можно сделать метод Component.from(context), тогда неважно где будет лежеть сам компонент

У меня в  котлине это реализовано через object (сущность в котлине синглтон)

кстати, как решается вопрос сохранения кастомного даггер скоупа (не PerApplication/PerActivity) когда андроид убивает/восстанавливает процесс приложения?

Именно
Application очень быстро загрязняется