Благодарю Кирилл! Кратко, понятно и все по делу! Удачный формат подачи материала. Гораздо понятнее чем на платных курсах что я проходил ранее. Пожалуйста удели побольше внимания жц компонентов в будущих уроках, как и когда их билдить, где хранить и когда убивать. Если это вопрос архитектуры и нет единого мнения, освети пару подходов на выбор.
Спасибо за видео! @Singleton vs @Reusable добавлю еще одно пояснение, можно посмотреть какой код они генерируют. @Singleton - double checked singleton с использованием synchronized @Reusable - простой singleton
Сабкомпоненты можно использовать всегда, чтобы явно не пробрасывать зависимости между компонентами. Либо когда у вас есть разные временные жизни для зависимостей.
Насчет Reusable он какое-то странное пояснение дал, типа нет гарантии.. если 2 раза запросите.. какое-то время хранит.. Короче, почитал статьи, работает так: @Reusable - аннотация похожа на обычный @Scope, но действует в рамках одного компонента. То есть, при такой иерархии: Component (провайдит A) Subcomponent_1 (инжектит в Frag_1) Subcomponent_2 (инжектит в Frag_2 и Frag_3) Объект А будет создан ► без использования аннотаций: 3 раза ► c испольозованием @Scope: 1 раз ► с испольозованием @Reusable: 2 раза
Спасибо за видео) а FeatureComponent (не сабкомпонент) можно использовать для построения Dynamic Feature? Чтоб модуль подгрузился позже, по необходимости
Когда компоненты в отдельных модулях, только один знать о другом может. И обычно это AppComponent знает о FeatureComponent. Промежуточный интерфейс добавляется возле FeatureComponent, чтобы описать требования к входящим зависимостям и не знать об AppComponent.
Вопрос про ту часть видео где речь идет о сабкомпонентах: Зачем в аннотации @Module() нужно указывать subcomponents = [FeatureComponent::class] ? Без этого все прекрасно работает вроде
Спасибо за урок! Но не совсем раскрыта тема "жесткой связи" между компонентом и сабкомпонентом. Ну генерируется инстанс класса внутрь другого класса, почему это плохо?
У меня два вопроса появилось: 1) Чтобы при повороте экрана презенторы не инжектились повторно их нужно держать в AppComponent? 2) В BottomNavigationView есть скоуп для пары фрагментов одного таба, его компонент должен переживать поворот экрана, значит его надо храниться в Application и при нажатии на таб создавать его, а при переходе на другой таб ставить null?
1) Мне кажется под словом "инджектались" вы понимаете создание зависимости? 2) Местом хранения может выступить Activity или Fragment, где это NavView расположен. Да, придется вам его чистить руками, либо привязаться к каким-то Callback. Например, можно отслеживать переключение элементов в NavView
@@AndroidBroadcast Да, создание зависимостей. В презенторе работает интерактор, экран поворачивается и создаётся новый презентер с новым интерактором, мне нужно, чтобы оставался старый презентор, значит компонент хранящий презенторы должен быть в Application?
@@AndroidBroadcast можно на пальцах? У меня есть активити с вьюмоделью. У них есть зависимости. Как мне описать компонент чтобы он жил пока жива активити?
УРА!!!!!! Compose вышел. Пишу на нем уже неделю и ненарадуюсь: фрагменты, xml, binding, обнулить observer, binding, onViewCreated......- тьфу, в помойку этот шлак!!!!
![Dagger Multibindings. Plugin architecture [RU]](http://i.ytimg.com/vi/vGmnrB8yHHA/mqdefault.jpg)
![Dagger Multibindings. Plugin architecture [RU]](/img/tr.png)
Чувак, ты просто ТОП!
Спасибо
Вот прям лучше и не скажешь!
спасибо! это видео улучшило мое понимание про работу с зависимостями и про скоупы
Спасибо за новое видео, Кирилл!
Спасибо за урок
Как раз было несколько моментов которые я не знал во время прошлых интервью.
Теперь позакрывал пробелы)
Спасибо за видео!
Thank you . It was very useful!
огонь выпуск
Благодарю Кирилл! Кратко, понятно и все по делу! Удачный формат подачи материала. Гораздо понятнее чем на платных курсах что я проходил ранее.
Пожалуйста удели побольше внимания жц компонентов в будущих уроках, как и когда их билдить, где хранить и когда убивать. Если это вопрос архитектуры и нет единого мнения, освети пару подходов на выбор.
Я покажу это в рамках многомодульного приложения и Hilt. Там будет с конкретными примерами.
огонь!
Как всегда топ!
Спасибо за видео!
@Singleton vs @Reusable добавлю еще одно пояснение, можно посмотреть какой код они генерируют.
@Singleton - double checked singleton с использованием synchronized
@Reusable - простой singleton
Круто, я только учусь андроиду, по началу вообще не понял что тут и как, но сделал в учебном приложении как показано и всё работает! Спасибо!)
🔥🔥🔥🔥
спасибо(пока очень тежело) хотел попечатать но тут сразу в бой ))
Спаcибо! Отличный ролик
Спасибо!
в следующем ролике было бы неплохо показать жизненный цикл фича компонента, это неоднозначная тема
5ый урок будем посвящен модуляризации, Там и будет освещаться тема. Но это архитектура и очень неоднозначен взгляд на это
Спасибо!
Крутотень!
Только про сабКомпоненты не совсем понял, когда их нужно использовать?
Или их вообще лучше не использовать? Депенденсис хватает.
Сабкомпоненты можно использовать всегда, чтобы явно не пробрасывать зависимости между компонентами. Либо когда у вас есть разные временные жизни для зависимостей.
Насчет Reusable он какое-то странное пояснение дал, типа нет гарантии.. если 2 раза запросите.. какое-то время хранит.. Короче, почитал статьи, работает так:
@Reusable - аннотация похожа на обычный @Scope, но действует в рамках одного компонента. То есть, при такой иерархии:
Component (провайдит A)
Subcomponent_1 (инжектит в Frag_1)
Subcomponent_2 (инжектит в Frag_2 и Frag_3)
Объект А будет создан
► без использования аннотаций: 3 раза
► c испольозованием @Scope: 1 раз
► с испольозованием @Reusable: 2 раза
Супер. А hilt и dagger-android планируешь в рамках этих сессий рассказать?
6 лекция будет
Спасибо за видео) а FeatureComponent (не сабкомпонент) можно использовать для построения Dynamic Feature? Чтоб модуль подгрузился позже, по необходимости
Да, зависимости компонентов не имеют завезут на код из модулей куда подключаются. Поэтому для dynamic feature этот способ будет работать
Спасибо за видео. По dependencies видел уже такой вариант, но пока не понял зачем промежуточный интерфейс нужен..
Когда компоненты в отдельных модулях, только один знать о другом может. И обычно это AppComponent знает о FeatureComponent. Промежуточный интерфейс добавляется возле FeatureComponent, чтобы описать требования к входящим зависимостям и не знать об AppComponent.
Спасибо. Вроде понял. На практике попробую.
Как я понял это из-за того, что feature модуль не знает про app, и собственно не знает про AppComponent.
Вопрос про ту часть видео где речь идет о сабкомпонентах:
Зачем в аннотации @Module() нужно указывать subcomponents = [FeatureComponent::class] ? Без этого все прекрасно работает вроде
Да работает, но тогда он не добавляется как сабкомпонент к компоненты, где подключен модуль
Спасибо за урок! Но не совсем раскрыта тема "жесткой связи" между компонентом и сабкомпонентом. Ну генерируется инстанс класса внутрь другого класса, почему это плохо?
Проблема в том что при любом изменение будет меняться сгенерированный исходник на Java, что приводит к повторной компиляции всего в файле (
У меня два вопроса появилось:
1) Чтобы при повороте экрана презенторы не инжектились повторно их нужно держать в AppComponent?
2) В BottomNavigationView есть скоуп для пары фрагментов одного таба, его компонент должен переживать поворот экрана, значит его надо храниться в Application и при нажатии на таб создавать его, а при переходе на другой таб ставить null?
1) Мне кажется под словом "инджектались" вы понимаете создание зависимости?
2) Местом хранения может выступить Activity или Fragment, где это NavView расположен. Да, придется вам его чистить руками, либо привязаться к каким-то Callback. Например, можно отслеживать переключение элементов в NavView
@@AndroidBroadcast Да, создание зависимостей. В презенторе работает интерактор, экран поворачивается и создаётся новый презентер с новым интерактором, мне нужно, чтобы оставался старый презентор, значит компонент хранящий презенторы должен быть в Application?
@@user-fc9gt6dl2i Необязательно в Application. Главное чтобы это было там где он будет жить дольше чем ваш Fragment в табе NavView
@@AndroidBroadcast Спасибо!
Не очень понял где начинается, а где заканчивается жизненный цикл пользовательского scope
Scope - это связка с Component, который кэширует все Scoped зависимости. Пока вы храните Component в памяти, хранятся и Scoped зависимости
@@AndroidBroadcast можно на пальцах? У меня есть активити с вьюмоделью. У них есть зависимости. Как мне описать компонент чтобы он жил пока жива активити?
@@y2kot привет, ты разобралался как это сделать?
Hilt все еще завязан на сабкомпонентах или это уже пофиксили за год?
Да, все также
@@AndroidBroadcast Спасибо за ответ
viewModel aфабрике scope нужен ?
Тут опять надо отталкивать от того, объект это с состоянием или без. Обычно фабрика не должна быть scoped зависимость
это всё базовые вещи или уже продвинутый уровень использования? пытаюсь понять насколько мне надо все это запоминать
Это базовые вещи, их точно надо знать
@@AndroidBroadcast А можно сразу продвинутый уровень ? Просто не могу приставить какой будет продвинутый, если это базовые вещи ))
УРА!!!!!! Compose вышел. Пишу на нем уже неделю и ненарадуюсь: фрагменты, xml, binding, обнулить observer, binding, onViewCreated......- тьфу, в помойку этот шлак!!!!
А ветки в репеозитрии нету?
Нет, подолью позже. И так с видосом получилось долго
Добавил
у кого-нить есть конспектик?
Спасибо!
Спасибо!