Pull to refresh

Comments 11

В реальной жизни нету понятия синглтон — у каждой вещи (объекта) должен быть владелец. И в разработке будет намного лучше если выбросить этот антипаттерн из головы.
Я понимаю если целью использования Dagger является облегчение тестирование, но не уловил сути использования его в статье.
Цель использования Dagger в рамках данной статьи — это чистота и модульность кода. А уже из этих двух составляющих следуют такие преимущества, как тестируемость, переиспользуемость и т.д.
По неведомой причине не отображаются первые картинки… Возможно, это только у меня, но проверьте, пожалуйста доступность для обитателей хабра вне Вашей сети…
Постарались оперативно исправить
Зачем ListComponent хранить в Application, если он должен разрушатся вместе с фрагментом, может стоит хранить его во фрагменте?
К ListComponent может обращаться не только сам фрагмент, но и другие «участники» уровня данного экрана.
Именно для такого совместного использования мы описали в классе App метод getListComponent().
Например, тому же Adapter'у может понадобиться собственный метод inject() вместо передачи зависимостей в конструктор. В таком случае его вызов будет App.getListComponent().inject(this);

Если же хранить ListComponent во фрагменте, появляется необходимость хранения instance фрагмента,
как статической переменной класса ListFragment, чтобы обеспечить общий доступ. И даже если не углубляться, в то, почему так категорически не стоит делать, наш компонент все равно не разрушится сам, т.к. появляется необходимость занулять instance фрагмента руками.
Смысла хранить сабкомпоненты экранов я не вижу в принципе, время жизни таких компонентов равно времени жизни активити/фрагмента.

К ListComponent как раз таки должен обращаться только фрагмент. Остальные зависимости данного скоупа ничего знать про компонент не должны, соответственно, в адаптере собственного метода inject() тоже быть не должно. Все его внутренние зависимости можно предоставить либо через модуль, либо повесить Inject на конструктор + методы/филды.
Спасибо за Ваш комментарий. Много думал, для чего же нам в действительности может понадобиться сабкомпонент экрана.

На моей практике он пригождался в случае, когда две зависимости (например адаптер и vhFactory) нуждались в ссылке на друг друга (если adapter реализовывал listener для событий vh). До того, как познакомиться с Lazy, я использовал отложенную инъекцию именно ленивым вызовом inject из адаптера. Ну, а сейчас я, наверно, соглашусь с Вами, функциональной нагрузки хранение сабкомпонента не несёт.
Однако, я бы оставил такую реализацию в статье просто для того, чтобы читатель понял, что за время жизни он отвечает самостоятельно.

Еще раз спасибо.
Следует отметить, что для такой реализации сабкомпонентов стоит воспользовать расширением для андроида https://google.github.io/dagger//android.html
А как поступать в случае архитектуры похожей на mvp? В любом случае большая часть зависимостей даггера будет прокидываться именно в презентер, а не в fragment/acrtivity и компонент будет выглядеть очень аляписто на мой взгляд если inject методы компонента будут содержать аргументы как презентеров так и вью (activity/fragment). Или я ошибаюсь и это будет корректным подходом?
Просто иных выходов для предоставления зависимости андроид компонентов я не вижу (ну кроме как прокидывать в презентер адаптер, что не есть хорошо со стороны mvp)
Если ваша архитектура подразумевает разделение ui от business-логики, отличным решением будет также разделить ваши Singletone-зависимости на два компонента — ui и business соответственно. С помощью Component dependency предоставляем из ui-компонента business-компоненту только необходимые общие зависимости (например Context) и интерфейсы для взаимодействия с вашими View (если, конечно, вы не используете фреймворки на типо Mosby).
Таким образом вы добьетесь независимости ваших слоёв друг от друга + разграничите их доступ к layer-специфичным зависимостям.

В общем-то, сочетание Dagger с различными архитектурами — это, наверно, тема для отдельной статьи. (Если, конечно, кому-то это будет интересно)
Sign up to leave a comment.

Articles