Отлично, тогда мы о нём забываем)

Ещё столкнулся с проблемой, что я не знаю, каким образом передать в @Inject-конструктор презентера параметры дополнительные. Приходится передавать компонент и в каждом презентере в конструкторе делать component.inject(this)

Точнее знаю, но для каждого презентера создавать отдельный модуль в даггере это ад, по-моему

Короче, для того, чтобы делать @inject через кастомный конструктор, нужно сделать просто кастомный конструктор. только тогда встаёт вопрос — как сделать так, чтобы moxy исопльзовала именно его? для этого есть аннотация @ProvidePresenter, которая применяется к методу, который должен возвращать новый экземпляр требуемого презентера. гайдик тут: https://github.com/Arello-Mobile/Moxy/wiki/Custom-Presenter-constuructor ну или тут https://github.com/Arello-Mobile/Moxy/wiki/Provides-Presenter-and-its-Tag

Не, это я знаю) Я про то, что я не могу при использовании даггера передать в конструктор какие либо аргументы помимо тех, которые есть в графе зависимостей. Например не могу передать репозиторий, и идеентификатор сущности одновременно, т.к. идеентификатор не провайдится даггером. Чтобы реализовать то, что я хочу, мне придётся делать отдельный модуль для каждого презентера, в который я буду передавать идеентификатор.

@senneco так может пометить onFirstViewAttach() как @Deprecated?

я уже сделал в локальной версии =))

Отлично)

На счет onFirstViewAttach(). А как допустим тогда сделать подгрузку данных при первом аттаче?

А нужно её делать сразу в конструкторе

Не комильфо

Конструктор это конструктор

Он нужен чтобы сконструировать объект. Другую логику туда не нужно пихать

Конструктор отвечает за инициализацию. Если для работы экрана необходим запрос - то вполне резонно делать его в конструкторе.

Бизнес логика в конструкторе уровня презентации это писос, имо

Хм, а в этом что-то есть. Надо подумать. Возможно метку deprecated сниму

Я один не понимаю?)

Ну представь: ты же можешь сделать экземпляр презентера, но не аттачить его куда-то. Например, сложить его в даггер. А потом, когда какая-нибудь View подоспеет, она будет приаттачена. И введь только тогда имеет смысл начинать работать презентеру.

И можно это представлять впринципе для любого презентера, когда ты продумываешь его интерфейс. Тогда получается не совсем логично начинать что-то делать в конструкторе. Правильней только инициализировать презентер.

+ получается такой локальный single responsibility — конструктор отвечает за конструирование, а методы - за его работу =)

Всё, въехал

Ну тут зависит от ситуации, да. У меня компонент создаётся на Activity, так что такой проблемы не будет, презентер тут же цепляется.