Comments 11
В реальной жизни нету понятия синглтон — у каждой вещи (объекта) должен быть владелец. И в разработке будет намного лучше если выбросить этот антипаттерн из головы.
Я понимаю если целью использования Dagger является облегчение тестирование, но не уловил сути использования его в статье.
Я понимаю если целью использования Dagger является облегчение тестирование, но не уловил сути использования его в статье.
0
По неведомой причине не отображаются первые картинки… Возможно, это только у меня, но проверьте, пожалуйста доступность для обитателей хабра вне Вашей сети…
0
Зачем ListComponent хранить в Application, если он должен разрушатся вместе с фрагментом, может стоит хранить его во фрагменте?
0
К ListComponent может обращаться не только сам фрагмент, но и другие «участники» уровня данного экрана.
Именно для такого совместного использования мы описали в классе App метод getListComponent().
Например, тому же Adapter'у может понадобиться собственный метод inject() вместо передачи зависимостей в конструктор. В таком случае его вызов будет App.getListComponent().inject(this);
Если же хранить ListComponent во фрагменте, появляется необходимость хранения instance фрагмента,
как статической переменной класса ListFragment, чтобы обеспечить общий доступ. И даже если не углубляться, в то, почему так категорически не стоит делать, наш компонент все равно не разрушится сам, т.к. появляется необходимость занулять instance фрагмента руками.
Именно для такого совместного использования мы описали в классе App метод getListComponent().
Например, тому же Adapter'у может понадобиться собственный метод inject() вместо передачи зависимостей в конструктор. В таком случае его вызов будет App.getListComponent().inject(this);
Если же хранить ListComponent во фрагменте, появляется необходимость хранения instance фрагмента,
как статической переменной класса ListFragment, чтобы обеспечить общий доступ. И даже если не углубляться, в то, почему так категорически не стоит делать, наш компонент все равно не разрушится сам, т.к. появляется необходимость занулять instance фрагмента руками.
0
Смысла хранить сабкомпоненты экранов я не вижу в принципе, время жизни таких компонентов равно времени жизни активити/фрагмента.
К ListComponent как раз таки должен обращаться только фрагмент. Остальные зависимости данного скоупа ничего знать про компонент не должны, соответственно, в адаптере собственного метода inject() тоже быть не должно. Все его внутренние зависимости можно предоставить либо через модуль, либо повесить Inject на конструктор + методы/филды.
К ListComponent как раз таки должен обращаться только фрагмент. Остальные зависимости данного скоупа ничего знать про компонент не должны, соответственно, в адаптере собственного метода inject() тоже быть не должно. Все его внутренние зависимости можно предоставить либо через модуль, либо повесить Inject на конструктор + методы/филды.
0
Спасибо за Ваш комментарий. Много думал, для чего же нам в действительности может понадобиться сабкомпонент экрана.
На моей практике он пригождался в случае, когда две зависимости (например адаптер и vhFactory) нуждались в ссылке на друг друга (если adapter реализовывал listener для событий vh). До того, как познакомиться с Lazy, я использовал отложенную инъекцию именно ленивым вызовом inject из адаптера. Ну, а сейчас я, наверно, соглашусь с Вами, функциональной нагрузки хранение сабкомпонента не несёт.
Однако, я бы оставил такую реализацию в статье просто для того, чтобы читатель понял, что за время жизни он отвечает самостоятельно.
Еще раз спасибо.
На моей практике он пригождался в случае, когда две зависимости (например адаптер и vhFactory) нуждались в ссылке на друг друга (если adapter реализовывал listener для событий vh). До того, как познакомиться с Lazy, я использовал отложенную инъекцию именно ленивым вызовом inject из адаптера. Ну, а сейчас я, наверно, соглашусь с Вами, функциональной нагрузки хранение сабкомпонента не несёт.
Однако, я бы оставил такую реализацию в статье просто для того, чтобы читатель понял, что за время жизни он отвечает самостоятельно.
Еще раз спасибо.
0
Следует отметить, что для такой реализации сабкомпонентов стоит воспользовать расширением для андроида https://google.github.io/dagger//android.html
0
А как поступать в случае архитектуры похожей на mvp? В любом случае большая часть зависимостей даггера будет прокидываться именно в презентер, а не в fragment/acrtivity и компонент будет выглядеть очень аляписто на мой взгляд если inject методы компонента будут содержать аргументы как презентеров так и вью (activity/fragment). Или я ошибаюсь и это будет корректным подходом?
Просто иных выходов для предоставления зависимости андроид компонентов я не вижу (ну кроме как прокидывать в презентер адаптер, что не есть хорошо со стороны mvp)
Просто иных выходов для предоставления зависимости андроид компонентов я не вижу (ну кроме как прокидывать в презентер адаптер, что не есть хорошо со стороны mvp)
0
Если ваша архитектура подразумевает разделение ui от business-логики, отличным решением будет также разделить ваши Singletone-зависимости на два компонента — ui и business соответственно. С помощью Component dependency предоставляем из ui-компонента business-компоненту только необходимые общие зависимости (например Context) и интерфейсы для взаимодействия с вашими View (если, конечно, вы не используете фреймворки на типо Mosby).
Таким образом вы добьетесь независимости ваших слоёв друг от друга + разграничите их доступ к layer-специфичным зависимостям.
В общем-то, сочетание Dagger с различными архитектурами — это, наверно, тема для отдельной статьи. (Если, конечно, кому-то это будет интересно)
Таким образом вы добьетесь независимости ваших слоёв друг от друга + разграничите их доступ к layer-специфичным зависимостям.
В общем-то, сочетание Dagger с различными архитектурами — это, наверно, тема для отдельной статьи. (Если, конечно, кому-то это будет интересно)
0
Sign up to leave a comment.
Dagger 2. Subcomponents. Best practice