Dagger в Android на практике с MVVM

[@TimofeyKovalenko]

СОДЕРЖАНИЕ: 00:00:00 - введение 00:01:24 - подключаем библиотеку Dagger 00:02:29 - пишем модули Dagger 00:17:04 - конфиг Dagger в App классе 00:24:45 - запускаем приложение с Dagger 2 00:26:15 - вариант без провайдеров 00:30:54 - заключение

[@SpRaT92]

Почти два дня и сидела и не могла правильни заинджектить зависимости с вьюмоделью в чистой архитектуре... Уже отчаялась к часу ночи, и наткнулась на это видео, сделала по образцу и заработало, спасибо вам за этот урок Т_Т Впереди ещё много всего предстоит понять, разобраться и доделать, но теперь у меня хотя бы что-то работает))

[@siarheisudakou4455]

Тимофей, спасибо большое за все Ваши видео! Актуальные темы излагаются просто, понятно и без "воды", поэтому уроки получаются очень полезными. Успехов Вам и Вашему каналу!

[@TimofeyKovalenko]

Спасибо).

[@ДеваЕва-м7ю]

урааа новое видео!!! хочется также видеть продолжение видео по Clean Architecture

[@ramilskl]

Мало кто так подробно объясняет! Спасибо!

[@malis5850]

Все максимально понятно и ваше объяснение не оставляет не толики сомнений в пройденном материале. Спасибо)

[@PavelStr-x5w]

Тимофей, спасибо большое за все Ваши видео!

[@АлексейМандрыкин-ч7е]

Спасибо за понятное объяснение сложного материала!

[@РоманМатохин]

Всё-таки правильно не ложить, класть:) А за видео спасибо большое!

[@bestrelaxationmusic763]

Всё просто и понятно изложено, спасибо!

[@OlegsPliska]

Спасибо большое за весь курс, очень помогает)

[@hestonic5114]

Лучшее объяснение на ютубе для меня

[@БатразДзампаев-г3у]

Все классно) Спасибо! Хочется видео по тестированию)

[@TimofeyKovalenko]

Скоро будет.

[@БатразДзампаев-г3у]

@@TimofeyKovalenko В этом году?)

[@f.uckeng]

да, можно писать круто код, но если ты не умеешь объяснять так же, как и Тимофей, то я отказываюсь с тобой обсуждать разработку!) классно, друг. очень нравятся твои уроки, давай больше!)

[@ivanstrelka3448]

От души!! Спасибо! Ждём еще

[@эмильискаков-в9с]

ООО, надо будет повторить и закрепить знания=)

[@Chybakut2004]

Респект за явные провайды и приватные проперти! 😁👍

[@digoMass]

Полезно! Класс!

[@ulmaxy]

На 30:40 вы говорите что параметры конструктора не могут быть приватными, но это не верно. Приватными не могут быть отдельные поля/методы, которые вы инжектите по отдельности с помощью аннотации @Inject. В случае с конструктором ограничение на приватность накладывается только на сам конструктор, т.е. нельзя написать @Inject private constructor(...). Но параметры конструктора (они же поля) могут быть приватными

[@TimofeyKovalenko]

Да, все верно, пропустил это 👍

[@lirjarmuhametova8516]

Да уж, конечно после koin - dagger сложновато даётся, но думаю если попрактиковаться несколько раз, то смогу освоить. Спасибо большое за урок 👍

[@dervanowsky]

понравилось) осталось попробовать ручками

[@trolofoks]

очень хотелось бы ролика про подробный разбор android dagger а не только ядра dagger'a

[@Silveryization]

Спасибо

[@oliakurcheuskaya1757]

Супер!

[@denislopatkin6996]

Шикарные видео! Пересматриваю каждые по несколько раз. Возник вопрос. В конце вы начинаете инжектить вьюмодели и юзкейсы через конструкторы, но разве юзкейсы не должны быть очищены от разных магических штук (в данном случае инжектов) для максимально прозрачного тестирования? Получается в конце чистая архитектура в данном проекте стала работать не на полную мощность…?

[@TimofeyKovalenko]

Аннотация @Inject не часть Dagger. Это стандарт javax.inject, который вполне допустимо использоватьт в domain.

[@antonbobrov6230]

Подскажите, на моменте 21:48, откуда переменная applicationContext? Спасибо за видео.

[@TimofeyKovalenko]

Из родительского класса активити от которого мы унаследовали нашу активити.

[@dr.padding4087]

спасибо огромное!

[@Arman_127]

Было очень полезно спасибо

[@СергейБеляков-д5в]

Главный плюс кодо-генерации не только в том, что позволяет обнаружить ошибку на этапе компиляции, но и в том, что несмотря на то, что проект дольше билдится - он запускается гораздо быстрее у юзера, нежели Koin. У Koin нет кодо-генерации, граф зависимостей выстраивается по сути при запуске приложения, а вот у Dagger (благодаря кодо-генерации) - граф уже выстроен.

[@gazim_soliev]

блин, чёт зависимости не хотят работать, у меня градл не видит такие зависимости, он видит только версию 2.28.3

[@МагомедРашидов-э3д]

Ииууу, спасибо! ПОЛЕЗНО

[@luckydevil1601]

Подскажите, пожалуйста, почему удалили private из юз кейсов? У меня и с private работает. Но у меня конечно версия либы поновее.

[@TimofeyKovalenko]

Можно было не удалять. Переменные в конструкторе могут быть приватными, а вот вот отдельные переменные нет

[@vd1009]

класно и доступно

[@gendalin6075]

Здравствуйте. На 10 минуте возник вопрос Допустим у нас бы была ещё локальная БД, куда мы при желании также могли бы сохранять наши данные Получается у нас для UserRepository будет ещё один Storage(DBUserStorage например) Как сделать в даггере так чтобы он на давал тот UserStorage, который нам нужен?

[@logangrimnar3042]

Я не спец, но возможно следует немного переписать репозиторий, добавив в него больше абстракции. Таким образом репозиторию должно быть все равно с какой бд он работает

[@TimofeyKovalenko]

Если вы о том, что-бы репозиторий работал с разными Storage в зависимости от ситуации, то внимательно подумайте, действительно вам это нужно), как правило не нужно. Это может пригодится, если вы решили в проекте поменять способ хранения данных, например были файлы, а стала база данных. В этом случае Dagger не причем. Если все же хотите локально менять, то тоже не проблема, есть разные способы, например можно прописать ключи для провайдеров. А репозиторий мы не должны трогать, в этом и суть подобных архитектур, меняется только реализация необходимого класса и провайдеры.

[@Artur_Maji]

Смотрел внимательно, но вы только здесь из трёх видео про di не поворачиваете экран, почему? Спасибо!

[@TimofeyKovalenko]

Что вы имеете ввиду под "переворачиваете экран"? На эмуляторе? Возможно просто пропустил это.

[@Artur_Maji]

@@TimofeyKovalenko да, именно это, поворот экрана, уточнил для ясности!думал, если вьюмодель сложно в Даггер создать, и с поворотом данные не сохраняются, может я что-то не уловил!, хотя "мы" же фабрику используем) спасибо!

[@TimofeyKovalenko]

Так мы же там вью модель через дагер не предоставляем, мы фабрику получаем из дагера, а дальше используем стандартный подход. Что-бы получать VM от дагера нужно заморочиться, на мой вгляд это того не стоит, к тому же видел часто, где в проектах в итоге этих заморочек VM не работает, как должна.

[@abumusa8887]

спасибо за урок кротко, изй и ундерстандэбл))

[@СергейБеляков-д5в]

Автор подскажи, почему ты убрал private модификатор в useCase?

[@TimofeyKovalenko]

Можно было не удалять. Переменные в конструкторе могут быть приватными, а вот вот отдельные переменные нет

[@vdrmkr]

А время жизни юз кейсов или чего то ещё не надо контролировать?

[@TimofeyKovalenko]

Нет, это же простой объект

[@АлександрК-ш]

Здравствуйте. Есть ли исходники кода к урокам?

[@СергейБеляков-д5в]

А исходники автор не прикрепил?

[@TimofeyKovalenko]

Неа ;)

[@agentr227]

Почему в Provides-методе с Usecase в параметрах мы указываем интерфейс репозитория? А если у нас от одного интерфейса будет имплементироваться два репозитория? Аналогичная ситуация со Storag-ами. Объясните, пожалуйста, почему Вы используете интерфейсы в параметрах provides-методов, а не конкретный класс.

[@TimofeyKovalenko]

Просто в примере нет необходимости в нескольких реализациях, да и на практике это не так часто встречается. Всегда лучше применять по максимум интерфейсы вместо реализаций, если это возможно. А когда уже понадобится разбить на конкретные реализации, вот тогда можно и поменять.

[@Стас-с4ю5т]

Вопрос, все провайды находятся в модуле App, а если мне нужно будет что то инжектить в data то мне нужно создавать папку под Di и dagger модули в них отдельно для модуля data или их можно создавать так же app/di?

[@TimofeyKovalenko]

Имеете ввиду случай, когда data хочет что-то внутри себя инжектить? Имею ввиду инжектить что-то внутренне, а не то, что прихоит из другого модуля? Если да, то тут можно конечно затянуть dagger в data модуль, сделать в нем свой Module, в котором описать нужные провайдеры. Это вполне рабочий вариант, и так часто делают. Но я лично не очень люблю затягивать DI в модули, мне больше нравится, что-бы модули вообще никак не знали, как их будут создавать, и как конструировать, то есть все собираем в app снаружи, даже внутренние какие-то зависимости. Но нужно учитывать специфику проекта, если проект очень большой, особенно если с фича командами, то скорей всего у каждого модуля будет свой DI Module.

[@Стас-с4ю5т]

@@TimofeyKovalenko Спасибо за ответ! Теперь с нетерпением жду видео по hilt

[@Алексей-й4ж6с]

Спасибо за видео! В прошлых уроках говорили что SharedPrefUserStorage желательно сделать internal классом, как и наверное UserRepositoryImpl. Но если мы так сделаем, то не сможем провайдить их. Получается, что эти внутренние классы все равно видят другие модули, что нежелательно. Как этого избежать? Спасибо

[@TimofeyKovalenko]

Как минимум можно сделать провайдеры в data слое, которые вернут реализацию для DI. Но как правило в этом нет необходимости, потому, что о них знает только app. А если выносить функционал по разным модулям, то тем более это не проблема.

[@abumusa8887]

ждем уроки про необхоимие и последный технологии

[@Стас-с4ю5т]

И есть такой общий вопрос по чистой архитектуре, почитал стать по этой теме (правда в контексте бэкенда а не андроида), в вашм примере entity/domain это классы содержащие только данные и больше походят на dto, но вроде как согласно ЧА entity могут содержать не только данные, но и поведение (Rich Domain Model). Вопрос, используется ли такая практика в андроид и если да то какие методы можно описать в entity?

[@TimofeyKovalenko]

При необходимости можно и поведение описать в ентити, тут никаких проблем нет, domain он как раз и создан, что-бы там было сосредоточено максимально много логики.

[@НикитаСоболев-й5к]

А насколько корректно предоставлять вообще все зависимости через applicationContext? Получается же, что в нем будет скапливаться какое-то нереальное количество методов для каждого класса...

[@TimofeyKovalenko]

Хм, не совсем вас понял, почему там будут скапливаться методы? ApplicationContext по сути используется, как точка входа только.

[@PandaTop.]

Когда новое видео ?

[@TimofeyKovalenko]

)), стараюсь делать как только появляется свободная минута, но пока к сожалению не так быстро как хотелось бы.

[@alexkoty5877]

Тимофей, здравствуйте И просто понравилось и вопросы есть, но по дальнейшим видео Расскажите пожалуйста философию разбития на фиче модули как правильно и как не правильно и почему, хотя бы базу И расскажите про рх джаву пожалуйста. По ней дофига всего в инете что она вся очень крутая, но чем она лучше эвент бас, чем она лучше чем стартАктивитиФоРезалт (и подобного) почти нет. Чем она хороша для много модульных проектов? Спасибо

[@TimofeyKovalenko]

Про фича модули будут видео, по rx пока планов нет, но подумаю )

[@tequilaonelove]

А причем здесь собственно "евент бас" и "стартАктивитиФоРезалт" ? Не знаю, насколько принципиален для вас выбор именно RxJava , но по моему мнению, лучше использовать корутины, а RxJava заносить в проект, если у вас есть на это какие-то жесткие требования/правила, обязующие использование именно RxJava или большой опыт использования их. С корутинами намного проще всё, читабельнее. Да и многие сторонние библиотеки, из коробки поддерживают работу с ними уже (а библиотеки из Jetpack так вообще, даже примеры использования у гугла давно демонстрируются с корутинами).

[@tequilaonelove]

А по поводу фиче-модулей, то как правильно их разбивать, зависит от вас и вашей архитектуры проекта. Нужно определить для себя, что по вашему мнению есть фича?Многие держатся подхода, что фиче-модуль = это какой-то целый, завершенный экран вашего приложения. Можете зайти тоже с этой стороны. Но на сколько сильно вы решите дробить (разбивать) ваше приложение на фичи, и выносить их в отдельные модули, зависит только от вас и конкретно от вашего проекта. То есть нет единого правильного ответа именно под вас и прям так сразу, сходу..

[@alexkoty5877]

@@TimofeyKovalenko спасибо, буду ждать!

[@alexkoty5877]

@@tequilaonelove спасибо за ответ, меня интересует какие нибудь шаблоны и рекомендации от которых можно думать и делать под себя. Сейчас стоит вопрос больше научиться архитектуре для меня

[@asp424]

Так коин это обертка на даггером)

[@TimofeyKovalenko]

Где вы такую бредовую информацию взяли?))), посмотрите исходники.

[@y9maly]

Какие-то костыли, Я бы лучше написал этот даггер

[@TimofeyKovalenko]

Конечно можно написать, возможно даже короче выйдет. Но сколько других программистов будут понимать ваш подход? ). Поэтому с точки зрения развития проекта и надежности, на случай если вы решите уволиться, намного выгоднее применять популярные и устоявшиеся решения. Также делая свое решение вы перекладываете на себя обязанность поддерживать, исправлять и развивать этот код.