#android #kotlin #dagger-2 #android-productflavors
Вопрос:
У меня есть приложение с 5 вкусами. Я просто хочу, чтобы один из них предоставил другую реализацию модуля dagger (с тем же интерфейсом). Я не хочу создавать этот модуль в каждом вкусе, я просто хочу иметь модуль, специфичный для вкуса, и модуль по умолчанию для всех других вкусов. Поэтому я попытался использовать каталог main , чтобы сохранить модуль по умолчанию, реализуя другой в одном из вариантов. Конечно, это не работает, так как возникает ошибка повторного объявления.
Есть ли способ достичь такого подхода, чтобы создать модуль кинжала по умолчанию для всех вариантов, но альтернативную реализацию только для одного из них?
Ответ №1:
Для этого есть 2 варианта:
- Добавьте определенные модули исходного набора (
src/flavorA/java,src/flavorB/java) для всех вариантов продукта и не определяйте модуль в основном исходном наборе (так как это приведет к ошибке из-за повторного объявления). - Вы можете добавить модуль dagger в
main source setкласс иif elseпроверить константу вкуса продукта вBuildConfigклассе, чтобы обеспечить соответствующую реализацию для вашего интерфейса.
PS: Ароматизаторы продуктов в Gradle работают путем объединения исходного кода для основного и исходного набора, специфичного для вкуса, следовательно, любой класс в исходных наборах, специфичных для вкуса, должен быть определен специально для всех наборов источников вкуса и никогда в основном, чтобы избежать ошибки компиляции.
Ресурсы также объединяются аналогичным образом, но в случае столкновения между основным и исходным набором, последний переопределяется без каких-либо ошибок
Комментарии:
1. Привет @rahul.taicho, я не хочу вводить логику для выбора реализации, я просто хочу иметь возможность предоставить правильную реализацию из самого модуля
2. Я расширил свой ответ, пожалуйста, дайте мне знать, если варианты неясны
3. Я думал о чем-то вроде «общей» папки набора исходных текстов, чтобы реализация по умолчанию шла туда. Затем я добавляю эту папку к остальным вкусам, за исключением последнего, который имеет другую реализацию. Таким образом, мне не нужно повторять одну и ту же реализацию во всех вариантах.
4. Это выполнимо, но вводит в заблуждение, поскольку
commonподразумевает, что он будет использоваться совместно для разных вариантов, а также решает вашу текущую проблему путем настройки сценариев сборки, но может не очень хорошо масштабироваться.Предположим, что позже у вас будет другой вариант использования, когда вам нужно будет по-другому подготовить реализации. TL;DR Если вы работаете с командой, вам следует избегать этого, работая над сольным проектом, у вас будет небольшая путаница, так что все еще может получиться. (в долгосрочной перспективе вы все равно можете рассматривать это как технический долг, хотя)