Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 22
В методе inject компонента обязательно указывать конкретный класс MainActivity? Нельзя ли вместо конкретного класса использовать просто Object, чтобы один компонент можно было использовать везде? Откуда появились методы appModule, utilsModule, receiversModule и т.д.?
В методе inject компонента обязательно указывать конкретный класс MainActivity?
Обязательно. Иначе Даггер не поймет, куда ему инжектить зависимости.
Нельзя ли вместо конкретного класса использовать просто Object, чтобы один компонент можно было использовать везде?
Что значит использовать один компонент везде? И зачем это? Поясните, пожалуйста.
Откуда появились методы appModule, utilsModule, receiversModule и т.д.
Не понял вопрос. Уточните, пожалуйста.
Если нужно внедрять зависимости в другой класс, например, SecondActivity, получается нужно для него создать еще один метод inject в AppComponent, который принимает SecondActivity в качестве параметра. Вопрос был в том, нельзя ли в качестве параметра inject указать Object и использовать один метод inject в обоих классах.
Последний вопрос был связан с методом buildComponent:
Предполагаю, что методы appModule, utilsModule, receiversModule генерируются даггером используя названия конструкторов модулей в качестве названий методов.
Последний вопрос был связан с методом buildComponent:
DaggerAppComponent.builder()
.appModule(this)
.utilsModule()
.receiversModule()
.build()Предполагаю, что методы appModule, utilsModule, receiversModule генерируются даггером используя названия конструкторов модулей в качестве названий методов.
Вопрос был в том, нельзя ли в качестве параметра inject указать Object и использовать один метод inject в обоих классах.
Нельзя. Для SecondActivity нужно создавать в Компоненте новый метод.
Последний вопрос был связан с методом buildComponent
Абсолютно верно. Плюс я нашел ошибку в статье благодаря вам. Спасибо! Код инициализации
AppComponent немного отличается. Плюс есть более сокращенная форма. Поправил в статье.
где же локальные синглтоны? во второй части?
Хорошие диаграммы, таких сильно не хватает в доках Dagger2 и всех статьях о нем.
Каким образом лучше разбивать компоненты?
Поясню: У меня в проекте есть 1 огромный компонент, который по сути инжектит во все, где это требуется. Его реализация хранится в Application и используется повсюду, где нужно что-то заинжектить. Я понимаю, что такой подход неправильный, но пока не могу понять каким образом лучше разбить компонент и какие приемущества мне это даст.
Поясню: У меня в проекте есть 1 огромный компонент, который по сути инжектит во все, где это требуется. Его реализация хранится в Application и используется повсюду, где нужно что-то заинжектить. Я понимаю, что такой подход неправильный, но пока не могу понять каким образом лучше разбить компонент и какие приемущества мне это даст.
например, по экранам? Есть некий экран со своей функциональностью, который требует каких-то зависимостей — их и стоит включать в данный конкретный компонент.
Для примера: есть такая библиотека Mortar от Square и она использует Dagger. В терминологии Mortar каждый экран — это Screen, в который объединены кастомная View, презентер и Dagger-модуль. Со 2-м даггером можно иметь какие-то зависимости на уровне Application, а остальные инжектить только в нужных местах
Для примера: есть такая библиотека Mortar от Square и она использует Dagger. В терминологии Mortar каждый экран — это Screen, в который объединены кастомная View, презентер и Dagger-модуль. Со 2-м даггером можно иметь какие-то зависимости на уровне Application, а остальные инжектить только в нужных местах
В таком случае каждый экран будет сам ответственен за создание своего компонента или компоненты для всех экранов будут лежать в нашем Application? И еще раз, в чем проблема одного большого компонента для всего?
Конечно, никто не запрещает вам создать один большой компонент для всего. Но с точки зрения архитектуры — это не очень хорошо, ведь вы создаете God-object. Разбивка компонент должна соответствовать вашей архитектуре.
Например, глобальные данные, утилиты вы храните в ApplicationComponent. Далее в приложении у вас может быть какой-нибудь модуль, типа Чата. Этот модуль содержит свои данные. Плюс он включает в себя несколько экранов (например, одиночный чат, групповой чат, настройки). В этом случае лучше создать компонент ChatComponent (subcomponent от ApplicationComponent), отвечающий за весь чат в целом. А также создать компоненты для каждого экрана (которые будут subcomponent от ChatComponent).
В итоге у вас получится четкая иерархия компонент, где у каждого строго своя зона ответственности.
Про все это я опишу более подробно в следующей статье. Там будет и про создание зависимостей между компонентами, и про "локальные" компоненты, и про примеры архитектуры с компонентами.
Например, глобальные данные, утилиты вы храните в ApplicationComponent. Далее в приложении у вас может быть какой-нибудь модуль, типа Чата. Этот модуль содержит свои данные. Плюс он включает в себя несколько экранов (например, одиночный чат, групповой чат, настройки). В этом случае лучше создать компонент ChatComponent (subcomponent от ApplicationComponent), отвечающий за весь чат в целом. А также создать компоненты для каждого экрана (которые будут subcomponent от ChatComponent).
В итоге у вас получится четкая иерархия компонент, где у каждого строго своя зона ответственности.
Про все это я опишу более подробно в следующей статье. Там будет и про создание зависимостей между компонентами, и про "локальные" компоненты, и про примеры архитектуры с компонентами.
Не знаю, лучшая ли, но то, что одна из лучших русскоязычных статей по даггеру — это точно.
А кокой именно паттерн Singletone он использует? Можно ли выбрать конкретный или как-то заоверайдить что-ли, как вообще он определяет нужный паттерн и определяет ли?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Dagger 2. Часть первая. Основы, создание графа зависимостей, Scopes