Комментарии 12
Зачем нужен Dagger, если есть buildTypes и productFlavors?
Как productFlavors помогут контролировать жизненный цикл компонентов?
flavors, конечно, не для этого. Нужно что б для каждого активити или фрагмента создавался новый экземпляр класса? Создавайте. Разве для этого нужна библиотека?
Если суть в простом провайдинге экземпляров класса в нужное место, то Даггер и вправду не нужен. Но когда захочется чего-то большего то без него уже не обойтись.
Приведите, пожалуйста, пример.
О, минусов нахватал, я тоже рядом постою ) А примеров в андроид разработке маловато — там инжекты сильно требуются только при тестировании, но в купе с тем, что основные строительные компоненты имеют свои жизненные циклы (сервисы, активити, ресиверы, фрагменты те же) и с тем, что даггер в тестировании подключить весьма сложно (testApt у кого работает?) то каноничное использование даггера выглядит больше как попытка натягивания совы на глобус.
buildTypes productFlavors решают другую проблему, dagger по свой сути обычное дерево объектов и способ их внедрения в классы
Ничего плохого не хочу сказать про статью, но интересующимся Dagger лучше обратить внимание на серию статей от Евгений Мацюк (@xoxol_89)
Кстати можно наследовать активити и фрагменты от DaggerAppCompatActivity и DaggerFragment из пакета dagger.android.support что бы уйти от ручной инъекции.
Красивей сделать ActivityLifecycleCallbacks, повесить его в Аппликейшене и инжектить в нем.
Как пример: goo.gl/9bm9WT
Как пример: goo.gl/9bm9WT
Спасибо за хорошую статью
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Dagger 2.11 & Android