Pull to refresh

Comments 22

В методе inject компонента обязательно указывать конкретный класс MainActivity? Нельзя ли вместо конкретного класса использовать просто Object, чтобы один компонент можно было использовать везде? Откуда появились методы appModule, utilsModule, receiversModule и т.д.?
В методе inject компонента обязательно указывать конкретный класс MainActivity?

Обязательно. Иначе Даггер не поймет, куда ему инжектить зависимости.

Нельзя ли вместо конкретного класса использовать просто Object, чтобы один компонент можно было использовать везде?

Что значит использовать один компонент везде? И зачем это? Поясните, пожалуйста.

Откуда появились методы appModule, utilsModule, receiversModule и т.д.

Не понял вопрос. Уточните, пожалуйста.
Если нужно внедрять зависимости в другой класс, например, SecondActivity, получается нужно для него создать еще один метод inject в AppComponent, который принимает SecondActivity в качестве параметра. Вопрос был в том, нельзя ли в качестве параметра inject указать Object и использовать один метод inject в обоих классах.
Последний вопрос был связан с методом buildComponent:

DaggerAppComponent.builder()
   .appModule(this)
   .utilsModule()
   .receiversModule()
   .build()

Предполагаю, что методы appModule, utilsModule, receiversModule генерируются даггером используя названия конструкторов модулей в качестве названий методов.
Вопрос был в том, нельзя ли в качестве параметра inject указать Object и использовать один метод inject в обоих классах.

Нельзя. Для SecondActivity нужно создавать в Компоненте новый метод.

Последний вопрос был связан с методом buildComponent

Абсолютно верно. Плюс я нашел ошибку в статье благодаря вам. Спасибо! Код инициализации AppComponent немного отличается. Плюс есть более сокращенная форма. Поправил в статье.
Хорошие диаграммы, таких сильно не хватает в доках Dagger2 и всех статьях о нем.
Каким образом лучше разбивать компоненты?

Поясню: У меня в проекте есть 1 огромный компонент, который по сути инжектит во все, где это требуется. Его реализация хранится в Application и используется повсюду, где нужно что-то заинжектить. Я понимаю, что такой подход неправильный, но пока не могу понять каким образом лучше разбить компонент и какие приемущества мне это даст.
например, по экранам? Есть некий экран со своей функциональностью, который требует каких-то зависимостей — их и стоит включать в данный конкретный компонент.
Для примера: есть такая библиотека Mortar от Square и она использует Dagger. В терминологии Mortar каждый экран — это Screen, в который объединены кастомная View, презентер и Dagger-модуль. Со 2-м даггером можно иметь какие-то зависимости на уровне Application, а остальные инжектить только в нужных местах
В таком случае каждый экран будет сам ответственен за создание своего компонента или компоненты для всех экранов будут лежать в нашем Application? И еще раз, в чем проблема одного большого компонента для всего?
Конечно, никто не запрещает вам создать один большой компонент для всего. Но с точки зрения архитектуры — это не очень хорошо, ведь вы создаете God-object. Разбивка компонент должна соответствовать вашей архитектуре.
Например, глобальные данные, утилиты вы храните в ApplicationComponent. Далее в приложении у вас может быть какой-нибудь модуль, типа Чата. Этот модуль содержит свои данные. Плюс он включает в себя несколько экранов (например, одиночный чат, групповой чат, настройки). В этом случае лучше создать компонент ChatComponent (subcomponent от ApplicationComponent), отвечающий за весь чат в целом. А также создать компоненты для каждого экрана (которые будут subcomponent от ChatComponent).
В итоге у вас получится четкая иерархия компонент, где у каждого строго своя зона ответственности.
Про все это я опишу более подробно в следующей статье. Там будет и про создание зависимостей между компонентами, и про "локальные" компоненты, и про примеры архитектуры с компонентами.
а никак нельзя переголосвать? а то нажал не на ту стрелочку
эх…
раньше можно было… теперь заблочили эту возможность…
странно, конечно
лучше отредактировать текст и добавить ссылки на все статьи в начале
Не знаю, лучшая ли, но то, что одна из лучших русскоязычных статей по даггеру — это точно.
А кокой именно паттерн Singletone он использует? Можно ли выбрать конкретный или как-то заоверайдить что-ли, как вообще он определяет нужный паттерн и определяет ли?
Под Singleton понимается просто один экземпляр класса. Без статики и вот этого всего.
А зачем оверрайдить, не совсем понял.
Я просто хочу понять какой именно патерн синглтона использует дагер и можно-ли как-то опционально выбрать нужный, к примеру Synchronized Accessor, Double Checked Locking & volatile, On Demand Holder Idiom
Посмотрите сгенерированный код, там найдете ответ =)
С ходу не вспомню.
Only those users with full accounts are able to leave comments. Log in, please.