Dagger 2 - @Provides, @Module. Полный обзор. [RU, Android] / Мобильный разработчик 

Да )) кратко и точно )

Лучший ответ. Этот коммент мне помог понять эту библиотеку. Ну и спасибо Алексею за видео)

Отличная идея)) Обязательно сделаю, спасибо!

@@MobileDeveloper А когда? А то, кажется, я не справляюсь)

Хм ) пока не могу сказать. Как только будет вы об этом узнаете.

Вот думаю, полезно ещё будет сделать именно с особенностями андроида, допустим Context инжектить. Не знаю, плохая ли практика, дабы в фрагментах не писать длинные вызовы к контексту

@@user-ie6vj3ok7v Во фрагментах контекст вызывается очень просто. getContext() или просто context если котлин

Спасибо!

Пожалуйста ) Не пропустите новые видео про Kotlin Native на патреоне)

Пожалуйста )

Спасибо )

Ну вы поймите что я не могу себе позволить создавать постоянно проекты это ведь вагон времени. Я итак это делаю все на голом энтузиазме )

Да, есть такое видео в плане, но оно достаточно объемное (как и сама библиотека), так что прошу запастись терпением :)

Приятного просмотра :)

Бейбут Тукибаев вам огромное спасибо! Да такое у меня было как раз с даггером

Рад, что помогло )

Спасибо большое! )

это точно, мне очень сложно( help

Я не знаю как можно ещё это доступнее объяснить в видео 🤷‍♂️

@@MobileDeveloper Возможно, тогда, это не ваше - писать уроки. Раз сами удивляетесь почему так мало просмотров. Вот простой и краткий пример по реализации для новичка, чтобы ввести в курс дела Dagger2: 1. Создать "Модули" (поставщик объекта). Каждый модуль помечается @Module. В модуле должен быть метод, который создает и возвращает (return new _) желаемый объект (другой класс из другого файла). Получается связка: Модуль - Возвращаемый объект (2 файла). Каждый такой метод в модуле помечается аннотацией @Provides. 2. Создается интерфейс AppComponent с аннотацией @Сomponent. Интерфейс наполняется сигнатурами методов. 1 модуль с 1 возвращаемым объектом = 1 сигнатура метода в Компоненте. Возвращаемый объект - один из тех, что возвращает один из модулей. 3. Есть два способа получения объектов: get, injection и пошел урок далее. Вся МАГИЯ Dagger 2 в том, что он сам создаст реализацию интерфейса AppComponent и назовет класс DaggerAppComponent. В дальнейшем при желании получить объект - Dagger 2 будет использовать данный класс. Нам его трогать вообще не обязательно. Для комфортного понимания лекции необходимо использовать графику, таблицы, показывать взаимосвязи, а не просто писать пример из классов A, B, C...

@@dentor2005снимите свое видео я вам запрещаю что ли?)

Круто )) рад что помог ))

Спасибо )

Всегда, пожалуйста )

Можно инжектить в презентер для этого нужно в компоненте прописать соответствующую функцию inject и в ините презентера сделать appComponent.inject

@InjectPresenter это из мокси аннотация, тоже di, только к даггеру отношения не имеет. Вставит туда то, что запровайдится методом @ProvidePresenter

Будут такие видео)

Пожалуйста))

Спасибо )

Пожалуйста)

Ну в момент вызова inject дерево зависимостей имплантируется в класс, то есть не обязательно их конкретно в одном файле AppComponent прописывать но да прописывать надо

Отчасти все это есть на патреоне в видео про TransportApp

Про scopes расскажу обязательно раньше не использовал, теперь вот начал.

Вам спасибо ) Да я не гонюсь прям сильно за просмотрами. Именно за их количеством. Мне важнее качество, то есть, чтобы люди, которые смотрят им было это интересно и полезно.

На пустом проекте есть видео на патреоне.

Да если у вас один компонент на приложении в аппликейшне ему самое место. Что значит ресурсозатратное? Аппликейшн существует всегда ))

Да, спасибо, запишу :)

Спасибо большое!

Mobile Developer хочу понять одну вещь, если бы я писал mvp без мокси, то мне бы приходилось в активити(view) создавать экземпляр презентора и соответственно можно было бы это все запихать в модуль и заинжектить во вьюхе. Но когда я использую мокси, то там все работает по другому. И как быть тогда? Т.е. Экземпляр презентора инжектировать с помощью дагера не надо, т.к. он инжектируется с помощью мокси. Правильно понял? Или очень сильно ошибаюсь?

Да все правильно. Для Инжекта мокси используется аннотация @InjectPresenter, а аннотация даггера выглядит как @Inject. Они визуально похожи, но их можно смело использовать в одном классе view без проблем. То есть даггер для этого использовать не нужно, а использовать для других вещей. То есть часть с mvp оставляем Moxy, а все остальное даггеру.

@@MobileDeveloper спасибо большое!

Спасибо )

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

Mobile Developer Вот и хотелось бы глянуть, ты бы хоть раз кликнул на ревлизацию

Ну нужно уметь создавать хотя бы один аппкомпонент и прописывать инъекции, уметь их читать, представлять дерево зависимостей. Уметь искать ошибки. В общем, все как всегда )) Спасибо, рад, что понравилось!

Да, все верно) По-моему за исключением если вы в модуль что-то передаете параметром.

Спасибо большое, очень рад, что видео оказалось полезным!

блин тоже читал игру престолов, почему автор подумал что если он возьмет какую-то хайповую вещь и приложит к непонятной то тогда все поймут

Я тоже ее читал и нифига не понял )) возможно потому что в самой игре престолов нихрена не понятно

А мне как раз видео не зашло, а в статье там всё по шагам разобрано)

В этом прелесть видеороликов )

Пожалуйста ) да была у меня мысль сделать ещё одну часть про даггер. Скоупы там и так далее. Вы можете ускорить этот процесс за небольшой донат в группе в вк

Поздравляю вас с этим )) Да Application хорош если у вас не 1) Разбитый на модули проект 2) Нет огромного дерева подзависимостей 3) Нет подменямых для разных мест реализаций одного интерфейса)

@@MobileDeveloper Спасибо за ответ. Не по теме. Мне тут инфа проскочила что запланирован вебинар ч.2. Будем доделывать наших героев доты? Когда?

Да, к сожалению, у меня был форс мажор, поэтому пока точную дату не могу сказать

Спасибо, да в этом видео есть такая проблема. Дальше я тише музыку делал.

Bohdan Serdyuk спасибо! Будут новые видео

Да, слышал про нее, но уже настолько привык к Dagger, что не хочу переходить. Но в целом все тоже самое можно и без библиотеки сделать, тут главное сам архитектурный подход

Если у тебя косяк в зависимостях, с Koin приложение упадет во время исполнения, а с даггером еще на этапе компиляции, что лучше само собой

Да есть такая мысль

А что конкретно вы хотите увидеть?

Думал об этом сделать, но в целом можно глянуть видео про Room. Там отчасти посветил этому время

@@MobileDeveloper Посмотрю, спасибо

Добрый вечер, нет, я этот проект никому не даю.

Вероятно вы не тот Inject юзаете )) у меня такое было ) удалите все import и попробуйте подставить правильный )

В app component можно прописать инжект в презентер ) насчёт примеров я сейчас делаю некое такое ультимативное видео где будут охвачены все технологии ) Первое видео уже на канале, но оно вводное, второе про запросы к серверу доступно для патреонов. Третье видео где будет работа с бд и di появится на выходных, но опять же для патреонов

Там насколько я помню куски из закрытых репозиториев )

Не понял )

Да занимаюсь напишите мне в ВКонтакте пожалуйста )

Жаль что не удалось мне передать) но вообще с лёгким примером вы абсолютно правы это хорошая практика

Ничего страшного - здоровая критика только поможет улучшению контента ) Музыку сделаю потише. Возможно вообще ее уберу. Насчет экономии времени - я тут скорее имел ввиду, что оно экономит время при моем подходе к архитектуре. В целом для меня реально ускорение было существенным, особенно с учетом того, что модули у меня тянутся из одного проекта в другой. В целом, я всегда говорю, что библиотеки/фреймворки или какие-то скрипты - это не более чем инструмент. Хороший мастер использует подходящие инструменты и не использует не подходящие. Поэтому, я вполне верю вам, что в вашем проекте он не зашел. Моя задача была объяснить физику процесса этой библиотеки. Работа с аннотациями и как именно он строит зависимости, как раз потому что (тут вы абсолютно правы) ошибки Даггера очень и очень не очевидны для новичка. На это убивается цела гора времени.В целом все ошибки, которые я видел в даггере сводятся к тому, что где-то чего-то не "запровайжено" и дальше ты, как правило, сидишь и распутываешь дерево зависимостей до того момента, где собственно не запровайжено. Я могу легко сделать проект без нее, я даже в видео об этом говорил. Собственно в iOS такой нет библиотеки, поэтому я использую свой подход. В целом можно сделать фабрики классов с уже встроенными зависимостями (это даже гибче будет), но в целом если проблем с даггером не возникает (тут вопрос практики и опыта), то даггер все равно добавляется быстрее. Особенно если ты копируешь из проекта в проект ) Насчет синглтона, в одну строчку, наверное, не получится (если только вы не enum используете - это грамотный подход :) ). Но я использую не для синглтона (это побочный эффект), а именно, для инжекта класса с кучей подзависимостей. Допустим у вас есть модель данных (условно репозиторий) и UI (условно presenter) и репо используется в 3-4 презентерах, тогда я свои репки добавлю в каждый из них двумя строчками. Для подготовки этого нужно будет совсем немного времени (по сравнению с созданием собственных фабрик классов) и в таком ключе должно по идее дать прирост по времени. По крайне мере, мне дает ) Огромное вам спасибо за такой развернутый комментарий!

Большое спасибо вам за подробный ответ! Очень приятно услышать мнение знатока. Вижу, вы в Андроид-разработке достаточно глубоко разбираетесь. Будет здорово увидеть ваши новые видео.

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

и как делить на сабкомпоненты.

и @Bind

Да есть такое в планах ) но чуть позже )

Во второй части TransportApp есть даггер как раз. И в третьей будет

@@MobileDeveloper о это круто! Есть еще одно маленькое пожелание, MokWebServer на примере проекта разобрать и как делать ответы на определенный запрос)

Возможно вы неверно понимаете смысл даггера. Зачем вам передавать данные извне? Даггер нужен для создания дерева зависимостей

@@MobileDeveloper чет я затянул с ответом:) извне это был общий пример) вот допустим мне надо в репозиторий пробросить калбэк, который реализуется презентером. т.е. по сути мне надо в репозитории получить текущую реализацию, а не создавать новою. Как это можно реализовать даггером? пока я придумал колхозный(на мой взгляд) метод, в интерфейсе репозитория описываю метод setCallback() и при инициализации презентера, пробрасываю его в репозиторий

Лев апарин вам прям в конструктор надо прокинуть что ли? А зачем?

@@MobileDeveloper в репозитории получаю данные из сети, мне надо вернуть их в презентер

Ну так делайте callback в конкретном методе интерфейса

Тут все очень просто ) можно попробовать написать крупный проект без использования какого-либо DI и тогда сразу все станет ясно 😂

Хм, спасибо за идею - запишу продолжение.

@@MobileDeveloper если продолжение ещё планируется, то хотелось бы увидеть как правильно, и правильно ли вообще, провайдить объекты, в конструкторы которых нужен контекст. А по поводу видео - очень круто и интересно, большое спасибо! Лично мне было бы интересно ещё посмотреть об архитектуре, слои - data/domain/presentation,что куда надо, как правильно написать контракт и т.д. Ещё раз, большое спасибо.

Daniel Yakovenko да это все будет. Насчёт контекста тут опасная тема ) заострю на этом внимание ) насчёт архитектуры я думаю после управления памятью пойду архитектуру делать )

Рад, что помог ) насчёт музыки спасибо, однако, это довольно старое видео - сейчас музыка тише

Одной из реализаций инверсии управления в применении к управлению зависимостями является внедрение зависимостей (англ. dependency injection)[2][3]. Внедрение зависимости используется во многих фреймворках, которые называются IoC-контейнерами. Скопирую и для вас тоже )

Вы предлагаете мне во все это погрузиться?)

​@@MobileDeveloper понял) думал на примере показать) если по простому, то как мне передавать интерфейс в конструктор презентора используя даггер?

Написать соответствующую провайд функцию которая бы в типе возвращала интерфейс а в теле реализацию

:(

А куда его еще?

@@MobileDeveloper я в том плане, что вы не разбиваете AppComponent -> Subcomponents с другими скоупами)

Видео довольно старое + я здесь хотел показать принцип работы даггеровских аннотаций (с этим больше всего проблем обычно). А то, что вы говорите есть в видео про TransportApp

@@MobileDeveloper спс, как раз гляну)

Я уже где то объяснял что я провожу индивидуальные занятия и консультации где мы смотрим код и я на более реальных проектах показываю. Так я свои исходники не выкладываю

@@MobileDeveloper ты сеньор-многостаночник, двухплатформенник, и что даже гитхаба своего нет?) просто странно ты потратил на создание ролика наверное больше усилий, чтобы запилить свой майнинговый андроид-клиент, я так понял из фрагментов, что это нечто завязанное на крипту какие кстати расценки на индивидуалки?

Конечно у меня есть правда битбакет. С кучей приватных репозиториев, часть из которых я в некритичных кусках демонстрирую в ролике, но доступ к ним я открывать не буду. Клиент я пилил не для ролика он в качестве демонстрационного материала. По расценкам напишите мне в вк. vk.com/neura

Котлин объективно во всем превосходит Java) Поэтому зачем писать на старом и неудобном?)

Спасибо, учту!

@@MobileDeveloper Чтобы код был лучше виден на видео попробуй Presentation mode в IDEA из меню View

Ваш комментарий шляпа и вот почему: в комменте которое вроде как срывает покровы вы много раз проговариваете одну и ту же мысль - видео плохое потому то, что кажется понятно и так (под подобными видео уже есть такие комменты) и для моего видео сделали отдельный коммент. Это все приводит к мысли, что ваш коммент тут не нужен, ведь в интернете полно таких критиков. Ну и критикуя - предлагай, поэтому я предлагаю вам уйти с этого канала и не тратить своё драгоценное время больше на комментарии и просмотр моих видео :) Спасибо!

Более пошагово есть на патреоне, в проекте TransportApp. Там же скоро будет про хилт )

вот например с тем же gson конвертером, о котором вы упоминаете в видео. без даггера я просто беру и передаю туда gsonconverter .addConverterFactory(GsonConverterFactory.create()) и мне не нужны никакие инжекты, модули, компоненты, даггеры. я не понимаю, о какой экономии речь?

Отвечу сразу на оба вопроса. Впрочем, ответ есть и в видео, но поясню. Полезность библиотеки даггер прям пропорциональна глубине зависимостей. То есть если у вас класс А зависит от Б и В это просто можно создать А(Б(), В()), а если зависимости на 10 уровней глубже? Да в любом месте где вам понадобится верхнеуровневый класс вы замучаетесь создавать его зависимости. Проще их прописать один раз и дёргать везде где надо. Это можно сделать и благодаря фабрике конечно, но зачем велосипедить + даггер даёт и другие преимущества. Ну и ещё скажу что никто вас не принуждает использовать именно эту библиотеку для инверсии контроля или вообще использовать какую либо другую библиотеку. Решение, как за инженером, закреплено за вами. Я лишь делюсь своим опытом.

@@MobileDeveloper так и вправду почему не сделать фабрику? что там ее делать? перечислить все зависимости и выдать объект.

@@MobileDeveloper единственное, с даггером код тестируемее. но с тестами я еще не работал, поэтому хз в чем прелесть пока.

Вас ведь никто не заставляет использовать даггер ) если вам удобнее фабрика используйте фабрику ) заодно лишних зависимостей в проект не затащите )

Чуть позже

@@MobileDeveloper а уже можно пожалуйста?

Мне ещё раз здесь продублировать про связь паттерна и инъекций? Только не удаляйте больше свой комментарий

@@MobileDeveloper Тогда при чем тут di библиотека, к инверсии ? Была показана по сути иньнекция, и вскользь упомянуто про интерфейс. Или я не внимательно смотрел? P.S. Удалил изза того что кнопкой промахнулся.

skynetif все просто одной из реализаций инверсии управления в применении к управлению зависимостями является внедрение зависимостей (англ. dependency injection). А тут нам помогает даггер

@@MobileDeveloper инверсия управления - да, но не инверсия зависимостей , IoC и dependency inversion на англ. А вы в видео говорили про инверсию зависимости.

Тогда значит оговорился, конечно я имел ввиду либо инверсию контроля либо инъекцию зависимостей в зависимости от контекста. Скиньте тайм метку если не сложно

Это печально, значит мне не удалось донести. Может вы какой-то вопрос зададите? Ну что конкретно непонятно. Не бывает так, чтобы непонятно было все )

@@MobileDeveloper самое печальное, что даже не могу поясснить что именно не понял) наверное просто в целом непонятно пока зачем это нужно, сначала кажется что только усложняет разработку dagger этот, хотя разумеется это не так) наверное мне лично не хватает каких то примеров типа вот без даггера мы будем писать это так и это будет долго а с даггером вот так и это будет быстро, удобно и изящно)

Alex Petrov попробуйте посмотреть google architecture samples на гитхабе есть. Мб что-то прояснится. Как я уже говорил - жить можно и без даггера, но вам все равно придётся все зависимости протягивать

@@alexpetrov6700 “вот без даггера мы будем писать это так и это будет долго а с даггером вот так“ да, было б круто такое видео глянуть))

EW8S Alex многие жаловались, поэтому в следующих роликах она сильно тише

Ну возьми да сделай

Создание с нуля с использованием современного даггера есть на патреоне

Возможно, но ей очень многие (почему-то) пользуются ) Например все те, у кого приложения до сих пор на Java. Поэтому видео может кому-то пригодиться)

@@MobileDeveloper согласен, например мне пригодилось, я не использовал Dagger, но увидел разницу

Он, со времен этого видео несколько трансформировался )

По пунктам: Спасибо большое буду еще рад профессиональным советам по раскрутке канала :) Насчет музыки отдельное спасибо - проверю. А насчет Dagger 2 очень жаль, что вы не смогли понять, что это такое, но вы можете задать вопрос в комментарии - я постараюсь более разжевано и развернуто объяснить ) Спасибо еще раз за критику )

музыка хорошая

Спасибо большое ))