¿Cuál es la estructura / architecture para la aplicación de label blanca?

Estoy preparando una aplicación de label blanca (llamada producto más adelante en esta publicación) y quiero configurar una muy buena architecture. Esto configurará fácil y rápidamente un nuevo cliente cambiando el layout, activando funciones …

Tengo varios serveres (dev, pre-prod, prod) para que el server flavorDimensions esté presente en el producto y el client flavorDimension esté en el lado del cliente.

Pensé en esta solución: configure un git por cliente y un git para el producto.

Los clientes tendrán acceso al código de producto por el submodule git. Esto me permite separar el código específico de mi cliente y el código fuente del producto.

 Git -> Client 1 Submodule -> Product v1 Git -> Client 2 Submodule -> Product v1.2 ... Git -> Product v1.4 

Pero tengo un problema sobre cómo ejecutarlo todo correctamente. El uso del client flavorDimensions es difícil porque necesito hacer un copyr y pegar (con gradle) desde mi submodule al module de la aplicación antes de la compilation. La generación de esta estructura rompe Gradle porque necesita sincronizarse todo el time. (Siempre sincronizar ahora bandera en Android Studio)

Entonces me pregunto, ¿es una buena architecture o no? Qué piensas ?

¿O tienes otras ideas y cómo implementarlas?

Gracias por su apoyo.

Hmm interesante asumirlo. He hecho cosas similares, pero no del todo así. Yo uso sabores solo para los deltas. Por ejemplo, themes, skins, app_icons y Strings.xml. Tal vez algunas variaciones en el layout o las actividades, pero hago todo lo posible para mantenerlo genéricamente servido para minimizar el mantenimiento del código para varias implementaciones de clientes, ya que cada sabor adicional ralentiza significativamente el process de CI.

Sin embargo, una diferencia key en lo que está haciendo es que no está construyendo una plataforma (si todos usan el mismo repository de GIT y server de API per se, está creando aplicaciones independientes para suministrar código completo y todo lo demás a clientes individuales).

Parece que podría ser una pesadilla de mantenimiento, pero si su situación requiere que los clientes obtengan acceso a la base de códigos para el sabor de sus productos, entonces creo que tiene sentido. Sin embargo, no estoy seguro de por qué tendrían acceso al código, ya que es su producto el que está haciendo el seguimiento para los clientes, ¿verdad?

En cualquier caso, no me está pidiendo que le pregunte a su razonamiento jaja, usted está preguntando sobre soluciones arquitectónicas. Entonces aquí están mis pensamientos.

Realice una tarea que copie las carpetas respectivas en una nueva estructura de module exactamente como los modules que tiene ahora, pero con cambios en el nombre del package para que todos difieran ligeramente, luego ejecute su inserción de GIT. Puede ejecutar files bash desde Gradle, por lo que puede escribir scripts y ejecutarlos desde routes relativas o puede escribirlo directamente en su file Gradle.

Así que actualizaría mi Gradle para tener un file de dependencia separado como libs.gradle

-> Poner dependencies en ese file como ext.libs {gson: "com.whatever: version"} -> apply from ../libs.gradle -> dependencies {libs.gson, etc.}

Así que supongo que su tarea de compilation lo haría

-> Crear un nuevo Módulo de Todas las Fuentes copyndo files correctamente con nuevos nombres si es necesario para cambiar el nombre -> si usa el server maven, luego implementar aar o jar para el nuevo module comstackdo -> Crear un nuevo file dynamic Gradle libs.gradle para replace el actual file libs.gradle que es un puntero fuente actualizado para desplegar artefactos o module creado -> ejecutar gradlesync, cuando termine ejecutar assembleRelease, entonces puede hacer su git push, etc.

Todo esto se puede sincronizar y hacer desde el terminal y localizado en commands. Es posible que Flavours no ayude mucho en esta área, ya que son parte del process de compilation, por lo que necesitas processs previos a la creación que puedes crear para hacer pre-build, pero la key es empaquetar dependencies y actualizar tu file libs.gradle. y asegúrate de replacelo por sabor. O si ha arreglado sabores, puede crear un libs.gradle específico para cada sabor y actualizarlo en function de las dependencies comstackdas.

No conozco tu image general, pero es posible. Espero que ayude. Buena suerte.