Комментарии 30
Сэкономила и ещё сэкономит кучу времени в поисках нужной информации и её осмысления.
Спасибо за хорошую статью. Подобного материала действительно мало, и собирать его приходится с многих источников.
У меня вопрос по тестированию. Кроме подхода Артема Зиннатулина, есть еще библиотека от Фаббио Коллини — DaggerMock. Приходилось ли Вам смотреть ее раньше? И если да, то чем не подошла?
Возник вопрос с Binds. Может ли сабкомпонент иметь абстрактный модуль в качестве зависимости? Если да, то как создать такой модуль?
Смущают вызовы MyApplication.getInstance().getFirstComponent().inject(this) — не ясно, куда вставлять эти вызовы в обычном приложении.
Вызовы эти вставлять в зависимости от вашей логики. Обычно в onCreate() Активити или фрагмента.
Несмотря на то, что Даггер второй писался для андроида, явно андроидовские зависимости Даггер нигде не тянет. Вся его андроидо-ориентированость — это неиспользование рефлексии и меньшее потребление ресурсов, правда за счет большего оверхеда в написании кода. Так что теоретически должен работать и вне его.
Будет работать, юзаю для бекенд приложений.
MyApplication.getInstance().getFirstComponent().inject(this) — не ясно, куда вставлять эти вызовы в обычном приложении.Зависит от того, как построено ваше приложение, если на каком-то фреймворке типа Spring/Jersey — там так же есть объекты приложения, можно завязаться на них, в простейшем случае с public static void main() вы можете просто таскать component сквозь все функции и обойтись вообще без классов!
Google изначально делали Dagger2 для своих бекендов.
Экономия и минус лишние вызовы. Собственно у нас выигрыш по производительности. Также пишут, что вызов статического метода на 15-20% быстрее вызова аналогичного нестатического метода. Если я ошибаюсь, iamironz поправит меня. Уж он то точно знает, а если нужно, и замерит.
Данный тезис правдив скорее до Android API 19. На данный момент invokestatic почти ничем не отличается от invokevirtual т.к. в ART он девиртуализируется достаточно эффективно.
Вот, скажем, провайдим мы в AppModule сингельтон ApiClient, который далее много где планируется использовать.
И в итоге чтобы его заюзать нужно везде дергать что-то вроде?:
App.get(context).getComponent().inject() или App.get(context).getComponent().getApiClient()
т.е везде тянется зависимость от Application
чем это отличается от того, чтобы просто дергать App.get(context).getApiСlient() без использование Dagger?
Т.е весь код в итоге все равно будет обвязан App.getComponent, это смущает
Возмодно я что пропустил, но пока не понял можно ли избавиться от привязки к Application везде где нужно сделать inject
Может эта статья прояснит больше — https://habrahabr.ru/company/tcsbank/blog/312196/
То? Или вы несколько про другое?
Есть ParentClass1 и ParentClass2 которые реализуют интерфейс MyCallback
Есть ChildClass
конструктор класса ChildClass выглядит вот так
public ChildClass(MyCallback callback) {...}
т.е. Child имеет связь с Parent через интерфейс
Я бы хотел в классе ParentClass1 и ParentClass2 указать
Inject
ChildClass childClass;
Конечно, никто не запрещает вам подменять код через flavors. Но dagger — это не только лишь возможность подмены кода.
Иначе вам придется вручную создавать и прокидывать зависимости.
Поясните пожалуйста.
Очевидно, что вот это тоже пишется не автоматически:
@Inject
@Named("SingleThread")
Executor singleExecutor;
/*далее в onCreate*/
Executor singleExecutor = singleExecutorProvider.get();
При этом lazy load вообще выглядит громоздким. Я смутно могу себе представить, зачем нам понадобился ThreadPoolExecutor в activity, но допустим. Без даггера мы могли бы например написать просто:
Executor singleExecutor = ThreadPoolFactory.getSigleExecutor();//одна строчка!!!
RxJava ты могуч, ты гоняешь стаи туч… Скажите на ваш взгляд если нужно что то вроде Supplier только для поздней инициализации, но не хочется тянуть по тем же причинам Guava и если сделать это как:
Observable<String> lazyString = Observable.just("Just do it");
// Usage
lazyString.toBlocking().first();Насколько нарушается кошерность и можно ли это сделать по другому, без ретро ламбда?
JFYI Observable.just("Just do it") не lazy, вы вычисляете аргумент во время вызова just, а не во время подписки. Observable.fromCallable — lazy, defer() тоже и тп.
В вашем случае, что нибудь вроде Callable<String> подойдет, если не нужно кеширование результата. Если нужно кеширование, то это классик строк на 10, который будет вычислять значение если его еще нет в кеше, и отдавать из кеша если уже есть. Если вы используете Kotlin, в его stdlib есть lazy.
Dagger 2. Часть третья. Новые грани возможного