Hola, me llamo Luis y hoy les traigo un nuevo tutorial.
A medida que los proyectos comienzan a crecer y se agregan nuevas capas de especificaciones y configuración, podemos comenzar a usar sabores y sus dimensiones para admitir un mayor nivel de personalización.
No obstante, cada vez que agregamos un nuevo sabor, la cantidad de posibilidades para compilar la aplicación se duplica automáticamente.
Sabores
sustantivo: sabor
1. el sabor distintivo de una comida o bebida.
2. una indicación del carácter esencial de algo.
Podemos ver los sabores de la misma manera: son un conjunto de reglas y comportamientos que hacen que su aplicación se comporte de manera diferente dependiendo de si la está compilando utilizando el código escrito para saborA o el de saborB.
Un ejemplo simple puede ser el caso de uso en el que una aplicación está disponible en Google Play Store con versiones gratuitas y de pago. Si el usuario compra la versión paga, queremos que tenga acceso a todas sus funciones, que normalmente no estarán disponibles en la aplicación gratuita. Además, no queremos enviar ese código en la versión gratuita. De lo contrario, aumentamos el riesgo de que el usuario encuentre una forma de acceder a esas funciones sin haber pagado por ellas. Esto se puede hacer explorando vulnerabilidades en la aplicación o incluso mediante un error del desarrollador. Así que es mejor ir seguro.
Cuando iniciamos un nuevo proyecto, normalmente tenemos una configuración similar:
android { buildTypes { debug { ... } release { ... } } }
Con esto, podemos compilar nuestra aplicación como depurar o lanzamiento.
Ahora, agreguemos un sabor específico:
flavorDimensions "app"
productFlavors {
free {
dimension "app"
}
}
Mirando la lista de variantes de compilación, podemos compilar el mismo número de versiones, pero ahora se llaman freeDebug y freeRelease.
Si ahora agregamos un segundo sabor duplicaremos el número de posibilidades:
flavorDimensions "app"
productFlavors {
free {
dimension "app"
}
paid {
dimension "app"
}
}
Ahora tenemos freeDebug, freeRelease, pagadoDebug y pagadoRelease.
A la lista inicial de tipos de construcción, podemos agregar un tercero y un cuarto aumentando el número de posibilidades aquí:
buildTypes { debug { ... } dev { ... } staging { ... } release { ... }
Y con esto empezamos a tener una lista interminable de posibilidades: freeDebug, freeDev, freeRelease, freeStaging, pagadoDebug, pagadoDev, pagadoRelease y pagado.
Y la lista puede seguir y seguir a medida que seguimos agregando nuevas funcionalidades.
Ignore
A medida que sigamos agregando nuevos sabores y tipos de compilación, Gradle agregará automáticamente esas nuevas combinaciones a la lista. No obstante, no todas las posibilidades pueden tener sentido; por ejemplo, es posible que no necesitemos un freeStaging versión.
Entonces, ¿cómo podemos eliminarlo de la lista? Solo necesitamos ignore
ellos.
Podemos ignorar un tipo de construcción completo:
variantFilter { variant -> def names = variant.flavors*.name if (variant.buildType.name == "staging") { setIgnore(true) } }
O simplemente una combinación específica:
variantFilter { variant -> def names = variant.flavors*.name if (variant.buildType.name == "staging") { if (names.contains("free") { setIgnore(true) } } }
Añadir comentario