Я использую aproach для предоставления модулей Dagger, описанных в ответе на этот вопрос Рабочий процесс настройки Android для продукта Ароматизаторы
Наш подход немного отличается - у нас есть Modules
в debug
тип сборки в src/debug/java
и release
тип сборки в src/release/java
. Наш основной модуль называется ApplicationModule
, он включает в себя все остальные.
Modules
в src/debug/java
обеспечивает некоторое настраиваемое поведение для отладки, ведения журнала и т. Д. И переопределяет ApplcationModule
.
Теперь у нас есть потребность в настраиваемом поведении, основанном на вкусе приложения.
Какой будет правильный подход к этому?
Например, варианты от A до C должны обеспечивать настраиваемое поведение, а варианты от D до F должны обеспечивать базовое поведение по умолчанию.
Пока что придумал такой.
- Все разновидности (не типы сборки) имеют один и тот же класс в
src/flavorX/java/com.application.FlavorModule
- Чтобы избежать дублирования кода, только варианты от A до C обеспечивают настраиваемое поведение, в то время как другие полностью пусты, чтобы проект мог компилироваться. И поведение по умолчанию предоставляется моему модулю в
src/main/java
Есть ли лучший способ добиться такого результата? Потому что я не люблю пустые src/flavorX/java/com.application.FlavorModule
и не люблю дублирование кода ...