Varias variantes de compilación en Android tienen un código fuente común

Hubble Connected, la certificación ISO 27001: 2013 y el cumplimiento de GDPR es una tecnología digital para bebés interconectada y una plataforma de IoT de vida inteligente que permite a los padres y familias acceder fácilmente a las tecnologías más complejas por primera vez. El objetivo de Hubble es permitir que los usuarios establezcan conexiones durante el viaje de su vida y se conviertan en sus socios inteligentes y confiables, desde el embarazo hasta el nacimiento, los niños pequeños, la construcción de una familia más grande, etc.

Hubble, no solo tiene su propia aplicación f○r Es compatible con sus kits de equipos de control y salud, así como con otras marcas de monitores para bebés para ayudar a sus clientes a mantenerse en contacto. Por lo tanto, se requieren múltiples aplicaciones con código fuente común.

Las variantes de compilación nos ayudan a crear diferentes versiones de aplicaciones utilizando un código fuente común. Por ejemplo, es posible que deseemos versiones gratuitas y de pago de la aplicación, o es posible que deseemos admitir varios clientes con requisitos similares pero diferentes temas de aplicación. Entendamos cómo podemos hacer esto.

Primero, entendamos la nomenclatura común.

Tipo de construcción:

El tipo de compilación se puede configurar en el archivo build.gradle de nivel de módulo. La depuración y la publicación son los tipos más comunes de compilaciones. De hecho, cada vez que se crea un nuevo módulo, Android Studio creará automáticamente los tipos de compilación Debug y Release.

buildTypes {
debug{
debuggable true
}
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
}

Sabor del producto:

Los sabores de productos nos ayudan a crear diferentes variantes de la aplicación utilizando el mismo código fuente. Por ejemplo, es posible que necesitemos que la versión de ensayo y la versión de producción de la aplicación apunten a los servidores de ensayo y de producción, respectivamente. O, es posible que deseemos versiones gratuitas y de pago de nuestra aplicación, donde la versión gratuita tiene un conjunto de funciones limitado y la versión de pago tiene un conjunto de funciones completo.

flavorDimensions "main"productFlavors {free {dimension "main"applicationIdSuffix ".free"

}

paid {dimension "main"applicationIdSuffix ".paid"

}

}

Las variantes de construcción no son más que el producto cartesiano de tipos de construcción y estilos de producto.

Tenga en cuenta que si necesitamos estas variantes de compilación como una lista de aplicaciones separada en PlayStore, necesitamos una ID de aplicación Para cada variante.

Dimensión del sabor

Si necesitamos combinar configuraciones de varios conjuntos de sabores de productos, podemos usar dimensiones de sabor.

Por ejemplo, para cada sabor de producto, podemos agrupar nuestras variantes de compilación de acuerdo con el servidor al que apunta (es decir, preparación o producción).

flavorDimensions "main", "server"productFlavors {free {
dimension "main"
applicationIdSuffix ".free"
}paid {
dimension "main"
applicationIdSuffix ".paid"
}staging{
dimension "server"
}prod{
dimension "server"
}

}

Agregar una nueva dimensión de sabor aumentará el número de variantes de compilación al crear un producto cartesiano de tipo de compilación, sabor de producto y dimensiones de sabor.

Por lo tanto, obtendremos las siguientes variantes de compilación:

Ahora que hemos entendido todos los términos, intentemos resolver nuestro problema de atender a varios clientes con el mismo código fuente.

Si tenemos 3 clientes, podemos crear directamente 3 sabores de productos, como se muestra a continuación:

flavorDimensions "main"productFlavors {
client1 {
dimension "main"
applicationIdSuffix ".client1"
}client2 {
dimension "main"
applicationIdSuffix ".client2"
}client3 {
dimension "main"
applicationIdSuffix ".client3"

}

}

Con esta configuración, podemos tener la siguiente estructura de código:

El código fuente común a todas las variantes se encuentra en la carpeta principal. El código fuente específico del cliente se encuentra en la carpeta del cliente correspondiente. Tenga en cuenta que puede haber archivos de recursos con el mismo nombre en la carpeta principal y en la carpeta del cliente, pero no archivos de clase (Java / Kotlin).

Aunque esto pueda parecer simple, se vuelve importante a medida que aumenta el número de clientes.

desafío:

Por ejemplo, necesitamos algunos módulos. Estos módulos necesitan más de un cliente, pero no todos los clientes lo necesitan. Es decir, no podemos mover el código fuente a main porque todos los clientes no necesitan este código y no podemos Hay código duplicado en ambos clientes. Entonces, ¿cuál es la solución a este problema?

solución:

Conjunto de fuentes:

Android Studio crea el conjunto de fuentes principal y el directorio para todo el contenido que debe compartirse entre todas las variantes de compilación. Sin embargo, también podemos crear nuevos conjuntos de código fuente para controlar con precisión qué directorios deben compilarse para qué tipos de compilación, estilos de producto y variantes de compilación.

De esta manera, podemos configurar nuestros módulos para diferentes clientes, y podemos agregar / eliminar fácilmente cualquier módulo de cualquier variante.

El conjunto fuente se puede definir de las siguientes formas:

sourceSets {client1 {
manifest.srcFile 'src/client1/AndroidManifest.xml'
java.srcDirs += 'src/client1/java'
resources.srcDirs += 'src/client1/res'
}client2 {
manifest.srcFile 'src/client2/AndroidManifest.xml'
java.srcDirs = ['src/client2/java', 'src/common/java', 'src/client2/kotlin']
res.srcDirs = ['src/client2/res', 'src/common/res']
}client3 {
manifest.srcFile 'src/client3/AndroidManifest.xml'
java.srcDirs = ['src/client3/java', 'src/common/java', 'src/client3/kotlin']
res.srcDirs = ['src/client3/res', 'src/common/res']
}
}

Como hemos visto, client2 y client3 pueden compartir un conjunto de fuentes común sin agregarlo a main porque client1 no lo necesita.

Especificar el conjunto de fuentes de esta manera nos proporciona mucha flexibilidad para agregar nuevas funciones / módulos, evitando la duplicación de código y manteniendo el código limpio y modular.

Resumen:

Por lo tanto, la creación de variantes y conjuntos de fuentes nos proporciona una forma limpia y ampliable de admitir varias versiones de aplicaciones con el mismo código fuente.