Android с помощью Gradle Создавайте ароматы в коде, как в случае if
Я пытаюсь работать со сборщиками. В моем build.gradle я определил 2 аромата, нормальный вкус и аромат администратора.
В основном у администратора есть дополнительная кнопка для основного действия.
Я понимаю, что я могу определить разные пакеты/классы для разных вкусов. Но есть ли способ сделать какой-то случай, чтобы добавить/удалить кусок кода в зависимости от вкуса?
В основном мне нужны две версии Activity. Но я не хочу двух разных версий деятельности и поддерживаю их.
Итак, в моей деятельности я хотел бы сделать
= > gradle проверьте, является ли вкус "администратором"
= > если да, добавьте этот код кнопки
Это возможно? Или вам понадобятся две разные физические действия и, таким образом, поддерживайте их оба, добавив после этого функциональность.
Ответы
Ответ 1
BuildConfig.FLAVOR
дает вам комбинированный вкус продукта.
Поэтому, если у вас есть только один размер аромата:
productFlavors {
normal {
}
admin {
}
}
Затем вы можете просто проверить его:
if (BuildConfig.FLAVOR.equals("admin")) {
...
}
Но если у вас есть несколько вариантов аромата:
flavorDimensions "access", "color"
productFlavors {
normal {
dimension "access"
}
admin {
dimension "access"
}
red {
dimension "color"
}
blue {
dimension "color"
}
}
есть также поля BuildConfig.FLAVOR_access
и BuildConfig.FLAVOR_color
, поэтому вы должны проверить это следующим образом:
if (BuildConfig.FLAVOR_access.equals("admin")) {
...
}
И BuildConfig.FLAVOR
содержит полное название аромата. Например, adminBlue
.
Ответ 2
Чтобы избежать простой строки в условии, вы можете определить логическое свойство:
productFlavors {
normal {
flavorDimension "access"
buildConfigField 'boolean', 'IS_ADMIN', 'false'
}
admin {
flavorDimension "access"
buildConfigField 'boolean', 'IS_ADMIN', 'true'
}
}
Затем вы можете использовать его следующим образом:
if (BuildConfig.IS_ADMIN) {
...
}
Ответ 3
Вы можете определить либо разные поля конфигурации сборки, либо разные значения ресурсов (например, строковые значения) для каждого варианта, например (согласно советам и рецептам Google gradle), например,
android {
...
buildTypes {
release {
// These values are defined only for the release build, which
// is typically used for full builds and continuous builds.
buildConfigField("String", "BUILD_TIME", "\"${minutesSinceEpoch}\"")
resValue("string", "build_time", "${minutesSinceEpoch}")
...
}
debug {
// Use static values for incremental builds to ensure that
// resource files and BuildConfig aren't rebuilt with each run.
// If they were dynamic, they would prevent certain benefits of
// Instant Run as well as Gradle UP-TO-DATE checks.
buildConfigField("String", "BUILD_TIME", "\"0\"")
resValue("string", "build_time", "0")
}
}
}
Так что в этом случае что-то вроде
productFlavors {
normal {
flavorDimension "access"
buildConfigField("boolean", "IS_ADMIN", "false")
}
admin {
flavorDimension "access"
buildConfigField("boolean", "IS_ADMIN", "true")
}
}
а затем использовать его как
if (BuildConfig.IS_ADMIN) {
...
} else {
...
}
или если это просто иметь разные строковые значения для разных вкусов, это можно сделать с разными resValues
и тогда вам даже не понадобится if/then