многомодульном проекте через dagger2, но сначала контекст: Разбираю пример из книги "dagger by tutorial". Там есть модуль, который предоставляет retrofit-класс. Этот модуль также предоставляет интерфейс конфигурации клиента (базовый url, размер кэша), который должен реализовать модуль, который будет использовать этот ретрофит-класс. В примере это :app модуль.
Так вот, в книге эта реализация внедрения конфигурации клиента сделана через атрибут dependencies ApplicationComponent. Плюс ко всему, для того, чтобы это решение заработало потребовалось добавить в функцию create Component.Factory реализацию этого интерфейса.
Автор не объясняет почему именно этот подход выбрал и мне он показался странным. Ведь можно убрать этот атрибут dependencies и добавить аннотацию @BindsInstance в Component.factory.create() и все также будет работать.
Сам вопрос - есть ли какая либо разница между добавлением обычного класса в граф зависимостей через dependencies и @bindsInstance?
А новая книга? Есть вероятность, что на момент её написания в даггере ещё не было bindinstance
а, понял в чем вопрос. Думаю, что при использовании component dependenciesв граф добавляются все прописанные в этом компоненте биндинги, не нужно потом писать что-то типа networkConfiguration.okhttp. Вот здесь они хорошо описаны: https://dagger.dev/semantics/#:~:text=Component%20dependencies%20are%20simply%20syntactic%20sugar%20for%20a%20certain%20use%20case%20for%20bound%20instances.
Я пытаюсь понять, но пока туго. Надо вникать мне, как всегда. Спасибо за ссылку
На скрине использование даггера не для android, а чистой java) для андроида класс App должен наследоваться от класса DaggerApplication
не должен, DaggerApplication - это из мира dagger-android, он не обязателен, это один их подходов, который в целом был признан неудачным и переделан в hilt
Пруф об неудачности в студию? На таком подходе у нас куча проектов работает, включая и пос системы. Если люди не правильно его реализовывали это не значит неудачный подход, руки должны расти с плещей ))
Здесь, например, разработчики рассказывали: https://youtu.be/o-ins1nvbDg?t=537 (ссылка из статьи Василия)
Ну и так разберу статью по полкам 1.Статья 2019 года, когда пишут Даггер андроид мертв. Версия 2.47 вышла в прошлом мец 2. Автор пишет что разработчики DI хотели прийти к решению того что бы упростить новичкам его использование, и это не значит что он не удачен( упрощение его использование стоит в hilt) и то если начнем разбивать на компоненты в ручную у новичков думаю будут снова проблемы, я уже молчу про очистку ссылок про которые новички забывают, если их не чистить вам и хилт думаю не поможет с утечками памяти 3. Автор четко в статья подчеркивает что это его мнение, и много уважаемые его коллеги с ним не согласны.
Версия даггера вышла, но ту часть, которая именно dagger-android же не развивают, она просто в режиме совместимости живет. А рекомендуют и разрабатывают хилт.
Я бы вообще не использовал DI фреймворки. В небольшом проекте уж точно.
А что ещё в MainActivity делать? Только DI и wiring. Ну можно в класс вынести.
Почему нет? Даггер живее всех живых, и много где используется, знать его полезно. Скорее всего в первую очередь хилт, чистый даггер сложен в управлении компонентами. Реальной пользы в пет проекте скорее всего будет мало, только для практики. Брать ли в большой продакшен - очень дело вкуса, кто-то любит даггер, кто-то коин, кто-то вообще без фреймворка делает зависимости.
https://javadoc.io/doc/com.google.dagger/dagger-android/latest/dagger/android/package-summary.html
Ещё как развивается
Обсуждают сегодня