Dagger в Android на практике с MVVM
Vložit
- čas přidán 30. 06. 2024
- Показываю реальный пример c Dagger в Android на практике, как для "чайников" :). Все показываю на практике в коде с архитектурой Clean Architecture (Чистая архитектура), а так же разбираем, как использовать Dagger 2 c MVVM.
Записаться ко мне на индивидуальные занятия или групповые курсы по Android можно на: ✅ KIPARO.COM.
Оф. документация по Dagger: github.com/google/dagger
СОДЕРЖАНИЕ:
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 - заключение
На канале также есть и другие уроки по программированию.
Так же, найти меня можно вот тут:
✅ Linkedin: / timofeykovalenko
✅ Instagram: / ttimofey
✅ На моем сайте: kiparo.com/teacher/timofey-ko...
✅ FB с анонсами видео: / kiparocom
#dagger #android #kiparo
СОДЕРЖАНИЕ:
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 - заключение
Мало кто так подробно объясняет! Спасибо!
Все максимально понятно и ваше объяснение не оставляет не толики сомнений в пройденном материале. Спасибо)
Тимофей, спасибо большое за все Ваши видео! Актуальные темы излагаются просто, понятно и без "воды", поэтому уроки получаются очень полезными. Успехов Вам и Вашему каналу!
Спасибо).
урааа новое видео!!! хочется также видеть продолжение видео по Clean Architecture
Всё просто и понятно изложено, спасибо!
Спасибо за понятное объяснение сложного материала!
Спасибо большое за весь курс, очень помогает)
От души!! Спасибо! Ждём еще
Почти два дня и сидела и не могла правильни заинджектить зависимости с вьюмоделью в чистой архитектуре... Уже отчаялась к часу ночи, и наткнулась на это видео, сделала по образцу и заработало, спасибо вам за этот урок Т_Т Впереди ещё много всего предстоит понять, разобраться и доделать, но теперь у меня хотя бы что-то работает))
Полезно! Класс!
Тимофей, спасибо большое за все Ваши видео!
Лучшее объяснение на ютубе для меня
Было очень полезно спасибо
ООО, надо будет повторить и закрепить знания=)
Все классно) Спасибо!
Хочется видео по тестированию)
Скоро будет.
@@TimofeyKovalenko В этом году?)
Всё-таки правильно не ложить, класть:) А за видео спасибо большое!
понравилось) осталось попробовать ручками
Супер!
Респект за явные провайды и приватные проперти! 😁👍
класно и доступно
Ииууу, спасибо! ПОЛЕЗНО
спасибо огромное!
Спасибо
очень хотелось бы ролика про подробный разбор android dagger а не только ядра dagger'a
да, можно писать круто код, но если ты не умеешь объяснять так же, как и Тимофей, то я отказываюсь с тобой обсуждать разработку!) классно, друг. очень нравятся твои уроки, давай больше!)
Здравствуйте. Есть ли исходники кода к урокам?
Шикарные видео! Пересматриваю каждые по несколько раз.
Возник вопрос. В конце вы начинаете инжектить вьюмодели и юзкейсы через конструкторы, но разве юзкейсы не должны быть очищены от разных магических штук (в данном случае инжектов) для максимально прозрачного тестирования? Получается в конце чистая архитектура в данном проекте стала работать не на полную мощность…?
Аннотация @Inject не часть Dagger. Это стандарт javax.inject, который вполне допустимо использоватьт в domain.
спасибо за урок кротко, изй и ундерстандэбл))
На 30:40 вы говорите что параметры конструктора не могут быть приватными, но это не верно. Приватными не могут быть отдельные поля/методы, которые вы инжектите по отдельности с помощью аннотации @Inject. В случае с конструктором ограничение на приватность накладывается только на сам конструктор, т.е. нельзя написать @Inject private constructor(...). Но параметры конструктора (они же поля) могут быть приватными
Да, все верно, пропустил это 👍
Подскажите, на моменте 21:48, откуда переменная applicationContext?
Спасибо за видео.
Из родительского класса активити от которого мы унаследовали нашу активити.
И есть такой общий вопрос по чистой архитектуре, почитал стать по этой теме (правда в контексте бэкенда а не андроида), в вашм примере entity/domain это классы содержащие только данные и больше походят на dto, но вроде как согласно ЧА entity могут содержать не только данные, но и поведение (Rich Domain Model). Вопрос, используется ли такая практика в андроид и если да то какие методы можно описать в entity?
При необходимости можно и поведение описать в ентити, тут никаких проблем нет, domain он как раз и создан, что-бы там было сосредоточено максимально много логики.
Спасибо за видео! В прошлых уроках говорили что SharedPrefUserStorage желательно сделать internal классом, как и наверное UserRepositoryImpl. Но если мы так сделаем, то не сможем провайдить их. Получается, что эти внутренние классы все равно видят другие модули, что нежелательно. Как этого избежать? Спасибо
Как минимум можно сделать провайдеры в data слое, которые вернут реализацию для DI. Но как правило в этом нет необходимости, потому, что о них знает только app. А если выносить функционал по разным модулям, то тем более это не проблема.
Да уж, конечно после koin - dagger сложновато даётся, но думаю если попрактиковаться несколько раз, то смогу освоить. Спасибо большое за урок 👍
Главный плюс кодо-генерации не только в том, что позволяет обнаружить ошибку на этапе компиляции, но и в том, что несмотря на то, что проект дольше билдится - он запускается гораздо быстрее у юзера, нежели Koin. У Koin нет кодо-генерации, граф зависимостей выстраивается по сути при запуске приложения, а вот у Dagger (благодаря кодо-генерации) - граф уже выстроен.
Вопрос, все провайды находятся в модуле App, а если мне нужно будет что то инжектить в data то мне нужно создавать папку под Di и dagger модули в них отдельно для модуля data или их можно создавать так же app/di?
Имеете ввиду случай, когда data хочет что-то внутри себя инжектить? Имею ввиду инжектить что-то внутренне, а не то, что прихоит из другого модуля? Если да, то тут можно конечно затянуть dagger в data модуль, сделать в нем свой Module, в котором описать нужные провайдеры. Это вполне рабочий вариант, и так часто делают. Но я лично не очень люблю затягивать DI в модули, мне больше нравится, что-бы модули вообще никак не знали, как их будут создавать, и как конструировать, то есть все собираем в app снаружи, даже внутренние какие-то зависимости.
Но нужно учитывать специфику проекта, если проект очень большой, особенно если с фича командами, то скорей всего у каждого модуля будет свой DI Module.
@@TimofeyKovalenko Спасибо за ответ! Теперь с нетерпением жду видео по hilt
Здравствуйте. На 10 минуте возник вопрос
Допустим у нас бы была ещё локальная БД, куда мы при желании также могли бы сохранять наши данные
Получается у нас для UserRepository будет ещё один Storage(DBUserStorage например)
Как сделать в даггере так чтобы он на давал тот UserStorage, который нам нужен?
Я не спец, но возможно следует немного переписать репозиторий, добавив в него больше абстракции. Таким образом репозиторию должно быть все равно с какой бд он работает
Если вы о том, что-бы репозиторий работал с разными Storage в зависимости от ситуации, то внимательно подумайте, действительно вам это нужно), как правило не нужно. Это может пригодится, если вы решили в проекте поменять способ хранения данных, например были файлы, а стала база данных. В этом случае Dagger не причем. Если все же хотите локально менять, то тоже не проблема, есть разные способы, например можно прописать ключи для провайдеров. А репозиторий мы не должны трогать, в этом и суть подобных архитектур, меняется только реализация необходимого класса и провайдеры.
Почему в Provides-методе с Usecase в параметрах мы указываем интерфейс репозитория? А если у нас от одного интерфейса будет имплементироваться два репозитория? Аналогичная ситуация со Storag-ами. Объясните, пожалуйста, почему Вы используете интерфейсы в параметрах provides-методов, а не конкретный класс.
Просто в примере нет необходимости в нескольких реализациях, да и на практике это не так часто встречается. Всегда лучше применять по максимум интерфейсы вместо реализаций, если это возможно. А когда уже понадобится разбить на конкретные реализации, вот тогда можно и поменять.
блин, чёт зависимости не хотят работать, у меня градл не видит такие зависимости, он видит только версию 2.28.3
ждем уроки про необхоимие и последный технологии
Автор подскажи, почему ты убрал private модификатор в useCase?
Можно было не удалять. Переменные в конструкторе могут быть приватными, а вот вот отдельные переменные нет
А у меня проект не запустился. Пишет, что версия котлина 1.8 и Dagger 2.41 не совместимы
А время жизни юз кейсов или чего то ещё не надо контролировать?
Нет, это же простой объект
Смотрел внимательно, но вы только здесь из трёх видео про di не поворачиваете экран, почему? Спасибо!
Что вы имеете ввиду под "переворачиваете экран"? На эмуляторе? Возможно просто пропустил это.
@@TimofeyKovalenko да, именно это, поворот экрана, уточнил для ясности!думал, если вьюмодель сложно в Даггер создать, и с поворотом данные не сохраняются, может я что-то не уловил!, хотя "мы" же фабрику используем) спасибо!
Так мы же там вью модель через дагер не предоставляем, мы фабрику получаем из дагера, а дальше используем стандартный подход. Что-бы получать VM от дагера нужно заморочиться, на мой вгляд это того не стоит, к тому же видел часто, где в проектах в итоге этих заморочек VM не работает, как должна.
Подскажите, пожалуйста, почему удалили private из юз кейсов? У меня и с private работает. Но у меня конечно версия либы поновее.
Можно было не удалять. Переменные в конструкторе могут быть приватными, а вот вот отдельные переменные нет
А насколько корректно предоставлять вообще все зависимости через applicationContext? Получается же, что в нем будет скапливаться какое-то нереальное количество методов для каждого класса...
Хм, не совсем вас понял, почему там будут скапливаться методы? ApplicationContext по сути используется, как точка входа только.
Тимофей, здравствуйте
И просто понравилось и вопросы есть, но по дальнейшим видео
Расскажите пожалуйста философию разбития на фиче модули как правильно и как не правильно и почему, хотя бы базу
И расскажите про рх джаву пожалуйста. По ней дофига всего в инете что она вся очень крутая, но чем она лучше эвент бас, чем она лучше чем стартАктивитиФоРезалт (и подобного) почти нет. Чем она хороша для много модульных проектов?
Спасибо
Про фича модули будут видео, по rx пока планов нет, но подумаю )
А причем здесь собственно "евент бас" и "стартАктивитиФоРезалт" ? Не знаю, насколько принципиален для вас выбор именно RxJava , но по моему мнению, лучше использовать корутины, а RxJava заносить в проект, если у вас есть на это какие-то жесткие требования/правила, обязующие использование именно RxJava или большой опыт использования их. С корутинами намного проще всё, читабельнее. Да и многие сторонние библиотеки, из коробки поддерживают работу с ними уже (а библиотеки из Jetpack так вообще, даже примеры использования у гугла давно демонстрируются с корутинами).
А по поводу фиче-модулей, то как правильно их разбивать, зависит от вас и вашей архитектуры проекта. Нужно определить для себя, что по вашему мнению есть фича?Многие держатся подхода, что фиче-модуль = это какой-то целый, завершенный экран вашего приложения. Можете зайти тоже с этой стороны. Но на сколько сильно вы решите дробить (разбивать) ваше приложение на фичи, и выносить их в отдельные модули, зависит только от вас и конкретно от вашего проекта. То есть нет единого правильного ответа именно под вас и прям так сразу, сходу..
@@TimofeyKovalenko спасибо, буду ждать!
@@tequilaonelove спасибо за ответ, меня интересует какие нибудь шаблоны и рекомендации от которых можно думать и делать под себя. Сейчас стоит вопрос больше научиться архитектуре для меня
А исходники автор не прикрепил?
Неа ;)
Когда новое видео ?
)), стараюсь делать как только появляется свободная минута, но пока к сожалению не так быстро как хотелось бы.
Так коин это обертка на даггером)
Где вы такую бредовую информацию взяли?))), посмотрите исходники.
Какие-то костыли, Я бы лучше написал этот даггер
Конечно можно написать, возможно даже короче выйдет. Но сколько других программистов будут понимать ваш подход? ). Поэтому с точки зрения развития проекта и надежности, на случай если вы решите уволиться, намного выгоднее применять популярные и устоявшиеся решения. Также делая свое решение вы перекладываете на себя обязанность поддерживать, исправлять и развивать этот код.