DC
А вот это точно херня
Size: a a a
2017 January 25
DC
хотя может это грубо))
DC
но опять же из песни, смысл нам провайдит презентер, если у нас мокси следит за его жизненым циклом. А если у нас презентер типа должен жить все приложение, то значит в нем лишняя логика, которую надо вынести в модель
DC
Не факт
DC
а вот если презентер использует зависимости, то тут вопрос как красиво их подсунуть
DC
через конструктор, это самое красиво
DC
зависимости или компонент?
DC
зависимости конечно
DC
если у тебя все зависимотсти инжектятся даггером, то презентер можно создать через компонент
interface ApplicationComponent {
fun provideContext() : Context
}
interface ApplicationComponent {
fun provideContext() : Context
}
DC
DC
нет
DC
типо так?
DC
это дописываешь в компонент
@Provides
fun yourPresenter(all presenter dependencies) : Presenter{
return Presenter(all presenter dependencies)
}
@Provides
fun yourPresenter(all presenter dependencies) : Presenter{
return Presenter(all presenter dependencies)
}
DC
и получаешь через компонент, я писал выше как
DC
сразу скажу, что мне не нравится в варианте, что на скриншоте это то что мы инжектим во вью, а используем в презентере. Не оч красиво))
DC
может я еще не понял, как правильно надо внедрять зависимости
IB
на самом деле все проблемы из-за архитектуры sdk андроидовской
IB
и как бы любые попытки завести норм di сводятся к попытке сгородить из говна дворец :)
AZ
архитектура SDK накладывает свои ограничения да, идеальный DI получится только в консольном приложении разве что) ни одна мобильная платформа не даст этого сделать
AZ
да и не только мобильная