🔗 Код из видео clck.ru/YRpyC 💰 Поддержать проект на Boosty bit.ly/3sratqQ или Patreon patreon.com/android_broadcast 🔗 Telegram канал "Android Broadcast" ttttt.me/android_broadcast
В целом довольно интересно, но что если в проекте Мокси + Dagger + Navigation Component + Многомодульность + Clean Arhitecture хотелось бы посмотреть как можно сделать красиво, + настроить модули внутри модулей транзитивно, чтобы постоянно implementation не писать от одних и тех же библиотек в разных фиче модулях к примеру
Для чего компонент фичи во вью модель класть, если его единственная зависимость в синглтоне хранится? Может есть решение как зависимость не в синглтоне хранить и ограничить жизненным циклом фичи?
Показалось маловато, прошёлся по верхам. Хотелось бы увидеть более глубокий разбор. Динамическое создание фичамодулей в реалтайме. Связи между двумя фичамодулями.
Google - сделал Dagger 2 и показал что в андроиде можно в нормальный и быстрый DI, выкатил к нему два разных "extension" что бы облегчить создание этого самого DI так что бы он оставался в рамках концепции DI. Андроид разработчики - продолжают использовать singleton.
Интересует, каким образом фича будет вызывать другую фичу, если фичемодули не должны знать друг о друге. Тот же NewsList должен открывать NewsDetails. В видео и в коде этот момент не описан
Это что же, мы в фича модуле создаем синглтон хранилище, в которое Application пишет записывает свой компонент? Не считается ли это за утечку? Буквально не утечет конечно, компонент должен прожить столько же, сколько и процесс, но если пользователь на этот экран не собирается идти, то мы получаем ненужный указатель в памяти.
Кирилл, привет. Скажи, пожалуйста, а как реализовать такое: Нужно получить @inject класса из модуля Б, в модуль А. Если модуль Б это сабкомпонент модуля А.
Доставить зависимость из сабкомпонент в комплект нельзя. Если сталкивается с тако задачей, то вы неправильно сделали архитектуру графа. Модули не могут доставлять зависимости, а уже тем более быть компонентами! Не путайте терминологию
Супер!!! Отдельное спасибо за ссылку на гитхаб) Огромная просьба не затягивайте с уроком про hilt, интересно послушать ваше мнение. На сколько я знаю hilt не саппортит динамик фичерс, было бы интересно послушать обо всем что он не умеет в отличии от даггера, чтоб не нарваться на неприятный нежданчик во время разработки)
5:29 Интересная фраза🤔 9:51 ArticlesDeps - это разве модуль? 12:59 Непонятно - слышится как "ArticlesDeps у меня фактически ... [ это и есть ] ... Application Component, который ... [ так же ]... живет". Я правильно расслышал? Странно тогда. Ибо сначала(9:03) ArticlesDeps презентуется зрителям, как простой интерфейс, потом(9:51) как модуль, теперь уже это граф? Возникает вопрос, чтобы обойти такое непростое тройственное понятие, можно ли обойтись оригинальной "кодлабой" по Dagger в части к чему привязать жизненный цикл того, чего вы по вашему решили хранить во ViewModel? Я не пробовал сам пока, в процессе, хотелось бы узнать ваше мнение. А то у вас вышло не очень понятно, а разобраться хочется. 13:10 При инициализации графа используется вызов .application(this) - это случаем не избыточно? Хотелось бы пример того, где вызов будет действительно полезен
Очень уж на профессиональном уровне, а можно простенко как-то. Ну например зделать приложения с двумя фрагментами или вьювсами и применить даггер, а то очень уж как-то не на земном языке. Хотя может это толька я тут такой :) Но все же спасибо!)
Возможно это глупый вопрос, но я не понял одного, почему при повороте экрана ArticlesFragment, стейт вьюмодельки не сохраняется и он опять билдит компонент
ViewModel (при правильном использовании) не будет пересоздаваться, поэтому там и хранится компонент. Возможно оговорка в ролике. Скиньте таймкод про какой момент говорите, пожалуйста
@@AndroidBroadcast я скачал ваш код из репозитория, и поставил одну точку для дебага в ArticlesComponentViewModel (время на видео 12:02), а вторую в ArticlesFragment(время на видео 15:03)в методе onAttach на ViewModelProvider, и попробовал повернуть экран для изменения состояния, и при каждом повороте экрана я дебагом заходим в ArticlesComponentViewModel и в метод onAttach в ArticlesFragment, получается что компонент каждый раз пересоздавался в ArticlesComponentViewModel?
Есть очень хорошый цикл статей про многомодульность на хабре. От Лаборатории Касперского. Там тоже очень хорошие материалы. Но насколько я понимаю, концептуально вся "магия" для провайда зависиместей для фичи делается в основном руками.
Спасибо большое, каким образом фича будет вызывать другую фичу, если я использую NewsDetails нескольким страницам. Для каждого viewmodel fragment/activity NewsDetails надо реализовать? Как будет этого правильно реализовать?
Я создаю в каждой фиче интерфейс с необходимым функционалом. Например, фича "news_list" будет иметь специальный интерфейс для навигации в детали, который должен будет предоставлен в зависимостях ArticlesComponent. app модуль знает все модули и сможет реализовать этот навигатор и перенаправлять в нужное русло При шаринге данных нужно все делать через слой данных
Спасибо за выпуск. Если у нас будет много фича-модулей и мы будем для каждого модуля предоставлять зависимости, имплементируя интерфейсы, не разрастётся ли наш основной компонент до огромных размеров?
@@AndroidBroadcast Ну ты в примере указал ArticleDes как dependencies для ArticleComponent. Даггер автоматом сгенерирует метод в билдере для articleDeps . Других кастомных параметров я не вижу в конкретном примере.
а в чем разница между: val newDetailsComponent = DaggerArticlesComponent.builder().deps(ArticlesDepsProvider.deps).build() и val newDetailsComponent = DaggerArticlesComponent.builder().deps(ArticlesDepsStore.deps).build() ?
![ILLSLICK - KILLSHOT REMIX [FULL VERSION]](http://i.ytimg.com/vi/RIK8RrqIAzE/mqdefault.jpg)
🔗 Код из видео clck.ru/YRpyC
💰 Поддержать проект на Boosty bit.ly/3sratqQ или Patreon patreon.com/android_broadcast
🔗 Telegram канал "Android Broadcast" ttttt.me/android_broadcast
В целом довольно интересно, но что если в проекте Мокси + Dagger + Navigation Component + Многомодульность + Clean Arhitecture хотелось бы посмотреть как можно сделать красиво, + настроить модули внутри модулей транзитивно, чтобы постоянно implementation не писать от одних и тех же библиотек в разных фиче модулях к примеру
Супер! Спасибо большое) действительно не сложно)
Ещё классно, у вас в видео все время какие-то Котлин-плюшки вижу - типа by notNull() =)
Наконецто!!!
Спасибо,Кирилл,очень полезные видео !
Ура-а-а! Спасибо большое!
большое спасибо, очень доступно. Футболки - супер :)
Спасибо!
Интересно было бы послушать про клин архитектуру, и как она дружит с даггером
Думаю многие уже заждались этого выпуска :)
Да, скоро будет больше
супер
Для чего компонент фичи во вью модель класть, если его единственная зависимость в синглтоне хранится? Может есть решение как зависимость не в синглтоне хранить и ограничить жизненным циклом фичи?
спасибо
Показалось маловато, прошёлся по верхам. Хотелось бы увидеть более глубокий разбор. Динамическое создание фичамодулей в реалтайме. Связи между двумя фичамодулями.
Я связь между фичамодулями не делаю, так как это усложняет архитектуру
Крутоь!
Google - сделал Dagger 2 и показал что в андроиде можно в нормальный и быстрый DI, выкатил к нему два разных "extension" что бы облегчить создание этого самого DI так что бы он оставался в рамках концепции DI.
Андроид разработчики - продолжают использовать singleton.
13:05:
упоминаются другие подходы реализации интерфейса Provider( отличные от синглтона) . А можно пример привести?
Нет, но это будет простой объект с каким-то временем существования и он должен заниматься в какой-то момент
Интересует, каким образом фича будет вызывать другую фичу, если фичемодули не должны знать друг о друге. Тот же NewsList должен открывать NewsDetails. В видео и в коде этот момент не описан
Это не тема этого видео, но будет показано в отдельном
Можешь сделать api модули для каждого фича модуля.
Там будут реквесты и резалты для работы с конкретным модулем.
Это что же, мы в фича модуле создаем синглтон хранилище, в которое Application пишет записывает свой компонент? Не считается ли это за утечку? Буквально не утечет конечно, компонент должен прожить столько же, сколько и процесс, но если пользователь на этот экран не собирается идти, то мы получаем ненужный указатель в памяти.
Кирилл, привет. Скажи, пожалуйста, а как реализовать такое: Нужно получить @inject класса из модуля Б, в модуль А. Если модуль Б это сабкомпонент модуля А.
Доставить зависимость из сабкомпонент в комплект нельзя. Если сталкивается с тако задачей, то вы неправильно сделали архитектуру графа.
Модули не могут доставлять зависимости, а уже тем более быть компонентами! Не путайте терминологию
Супер!!! Отдельное спасибо за ссылку на гитхаб) Огромная просьба не затягивайте с уроком про hilt, интересно послушать ваше мнение. На сколько я знаю hilt не саппортит динамик фичерс, было бы интересно послушать обо всем что он не умеет в отличии от даггера, чтоб не нарваться на неприятный нежданчик во время разработки)
Он умеет все то же что и Dagger просто удобнее и больше генерирует кода, что упрощает интеграцию с Jetpack библиотеками
@@AndroidBroadcastзначит лучше юзать Hilt?
5:29 Интересная фраза🤔
9:51 ArticlesDeps - это разве модуль?
12:59 Непонятно - слышится как "ArticlesDeps у меня фактически ... [ это и есть ] ... Application Component, который ... [ так же ]... живет". Я правильно расслышал? Странно тогда. Ибо сначала(9:03) ArticlesDeps презентуется зрителям, как простой интерфейс, потом(9:51) как модуль, теперь уже это граф?
Возникает вопрос, чтобы обойти такое непростое тройственное понятие, можно ли обойтись оригинальной "кодлабой" по Dagger в части к чему привязать жизненный цикл того, чего вы по вашему решили хранить во ViewModel? Я не пробовал сам пока, в процессе, хотелось бы узнать ваше мнение. А то у вас вышло не очень понятно, а разобраться хочется.
13:10 При инициализации графа используется вызов .application(this) - это случаем не избыточно? Хотелось бы пример того, где вызов будет действительно полезен
Про модуль ArticleDeps - оговорка
Хранить компонент можно где вам угодно, ViewModel тоже подойдёт
application(this) передается в графе для того чтобы там был Context приложения, никакой избыточности
Очень уж на профессиональном уровне, а можно простенко как-то. Ну например зделать приложения с двумя фрагментами или вьювсами и применить даггер, а то очень уж как-то не на земном языке. Хотя может это толька я тут такой :)
Но все же спасибо!)
ссылка на код из видео не открывается :-( пишет "Your connection is not private" и не пускает. это я что-то неправильно делаю?
Наверное ссылка пытается в http открываться
Отличное решение хранить компоненты во вьюмодели!вопрос : как расшарить компоненты из вюмодели, чтоб можно было их видеть из любой точки приложения?
Можно сделать вот так gist.github.com/kirich1409/3fb3371703b8ed3b9d019f1b00625bca
Возможно это глупый вопрос, но я не понял одного, почему при повороте экрана ArticlesFragment, стейт вьюмодельки не сохраняется и он опять билдит компонент
ViewModel (при правильном использовании) не будет пересоздаваться, поэтому там и хранится компонент. Возможно оговорка в ролике. Скиньте таймкод про какой момент говорите, пожалуйста
@@AndroidBroadcast я скачал ваш код из репозитория, и поставил одну точку для дебага в ArticlesComponentViewModel (время на видео 12:02), а вторую в ArticlesFragment(время на видео 15:03)в методе onAttach на ViewModelProvider, и попробовал повернуть экран для изменения состояния, и при каждом повороте экрана я дебагом заходим в ArticlesComponentViewModel и в метод onAttach в ArticlesFragment, получается что компонент каждый раз пересоздавался в ArticlesComponentViewModel?
Нет, он получается. Там же нет вызова создания объекта. Обратите внимание на ссылку на ViewModel, что это один и тот объект в памяти
@@AndroidBroadcast спасибо
Есть очень хорошый цикл статей про многомодульность на хабре. От Лаборатории Касперского. Там тоже очень хорошие материалы. Но насколько я понимаю, концептуально вся "магия" для провайда зависиместей для фичи делается в основном руками.
Верно. Каждый выбирает свой подход и универсального решения нет
Больше абстракций - больше свободы принятия решений)
Дайте ссылочку на хабр, плиз)
@@alekseyblekot119 щас приеду в прекрасный пустой утренний офис и скину ссылочку)
А погуглить в хабе Лаборатории Касперского? Не ленитесь!
Спасибо большое, каким образом фича будет вызывать другую фичу, если я использую NewsDetails нескольким страницам.
Для каждого viewmodel fragment/activity NewsDetails надо реализовать?
Как будет этого правильно реализовать?
Я создаю в каждой фиче интерфейс с необходимым функционалом. Например, фича "news_list" будет иметь специальный интерфейс для навигации в детали, который должен будет предоставлен в зависимостях ArticlesComponent. app модуль знает все модули и сможет реализовать этот навигатор и перенаправлять в нужное русло
При шаринге данных нужно все делать через слой данных
Спасибо за выпуск. Если у нас будет много фича-модулей и мы будем для каждого модуля предоставлять зависимости, имплементируя интерфейсы, не разрастётся ли наш основной компонент до огромных размеров?
Необязательно их должен основной компонент реализовывать. Это может кто угодно делать
+
Так и не понимаю, зачем ты каждый раз пишешь Component.Builder - он же сам генерится.
Он у меня используется с кастомными параметрами
@@AndroidBroadcast Ну ты в примере указал ArticleDes как dependencies для ArticleComponent. Даггер автоматом сгенерирует метод в билдере для articleDeps . Других кастомных параметров я не вижу в конкретном примере.
dd
а в чем разница между:
val newDetailsComponent = DaggerArticlesComponent.builder().deps(ArticlesDepsProvider.deps).build()
и
val newDetailsComponent = DaggerArticlesComponent.builder().deps(ArticlesDepsStore.deps).build() ?
Разница в том что разные классы предоставляют зависимость для построения Dagger компонента