A
Выходит странная ситуация. Там где время сборки и объемы кода становятся проблемой используем даггер, а там где пэт проект или чёт маленькое, где мы и не заметим этого - ищем другие решения
Size: a a a
2018 May 29
KT
Да, все верно, для небольшого проекта норм. Для коммерческого продакшена - Даггер наше всё
Тузпик - наше все 😉
YA
Тузпик - наше все 😉
Многомодульность поддерживает?
KT
Да. Все поддерживает
KT
И с последней версии и прогвард тоже полностью поддерживает
AR
Прогвард же вроде скоро всё, R8 придет
AE
Прогвард же вроде скоро всё, R8 придет
никакой разницы, описание правил и api идентичны
AP
Но у даггера все ещё лучше сделана компайл тайм валидация графа, чем у тузпика. Есть тут спецы по тузпику кто поправит если я ошибаюсь?
AV
Но у даггера все ещё лучше сделана компайл тайм валидация графа, чем у тузпика. Есть тут спецы по тузпику кто поправит если я ошибаюсь?
у тузпика рантайм валидация графа, поэтому да))
ST
Тузпик - наше все 😉
Ему разве капт не нужен?
AP
у тузпика рантайм валидация графа, поэтому да))
Разве ? У него что-то есть в компайл тайме. Потому что в рантайме валидация была ещё в старых более несовершенных di либах.
ST
у тузпика рантайм валидация графа, поэтому да))
В рантайме?
AV
Да, у него рантайм полностью.
KT
Вы ещё скажите, что в даггере все при компиляции проверяется))
KT
а капт ему конечно нужен, так как код генерится, но гораздо меньше чем у даггера
KT
поэтому быстрее
KT
а еще фича: можно при разработке отключить генерацию кода
AP
ну циклические зависимости проверются у даггера в компайл тайме.
ST
Вы ещё скажите, что в даггере все при компиляции проверяется))
Да в баню это даггер.))