Código común para diferentes sabores de Android
Estoy construyendo 4 diferentes sabores de mi aplicación para Android.
Tengo una clase Customization.java
que es la misma para 3 de ellos y diferente para 1.
- ¿Cómo publicar las fuentes .aar de Android para que Android Studio las encuentre automáticamente?
- Resolver avisos NDK obsoletos en Android Studio
- Android: Skip Gradle "testClasses" tarea para un proyecto de dependencia
- Volley no funciona con Gradle 2.0 e Instant run
- Edición de problemas apk file
Puesto que no puedo poner la misma clase en la carpeta principal y en la carpeta del sabor, ahora tengo que mantener 3 copias de la misma clase exacta para esos 3 sabores.
¿Hay alguna manera que podría hacer con mantener sólo dos versiones de esta clase?
Cosas que he considerado hasta ahora:
- Miré las dimensiones del sabor, pero resulta que no son aplicables en este caso.
- Mantener sólo un archivo en uno de los sabores y copiarlo a través de mi secuencia de comandos de creación.
Me pregunto si hay algo más limpio fuera de la caja.
- IllegalArgumentException: ya añadido: Landroid / support / v4 / accessibilityservice / AccessibilityServiceInfoCompat $ AccessibilityServiceInfoIcsImpl;
- Cómo crear la biblioteca de soporte v4 desde el origen
- DexIndexOverflowException después de actualizar a la última appcompat y la biblioteca de soporte
- Instalar manualmente Gradle y usarlo en Android Studio
- Gradle error con un signo de dólar
- Gradle Android No se pudo encontrar el método testPackage ()
- No se puede ver la tarea del archivo de asignación de carga de Firebase
- Archivos duplicados copiados en APK META-INF cuando se construye Gradle
Me gustaría convertir el comentario de CommonsWare en una respuesta. Luego explicaré cómo debería ser la configuración final del directorio. Espero que esto ayude a la gente tropezando con esta pregunta a través de la búsqueda.
Bueno, puedes anular recursos en sabores. Por lo tanto, tiene el común en
main/res/layout/
y el sabor específico enyourFlavorHere/res/layout/
.
Por lo tanto, si el archivo de diseño de la actividad de Customization
se llama activity_customization.xml
, dejará su copia común compartida entre los tres sabores en el directorio src/main/res/layout
y colocará el xml modificado que utilizará, por ejemplo, flavorFour
en Su directorio de origen correspondiente directorio src/flavorFour/res/layout
.
La forma en que esto funciona es que, puesto que el sabor uno a tres (a diferencia del sabor cuatro) no han proporcionado sus propias versiones de activity_customization.xml
, heredarán el procedente del conjunto de fuentes main
.
Es la clase de Java de la actividad que consigue complicado. Otra posibilidad para ello es configurar los sabores con la misma implementación de actividad para extraerlos de dos directorios de origen: uno específico del sabor y uno común con la implementación de la clase común.
A diferencia de los recursos, los archivos de código Java no se fusionan ni se reemplazan. Por lo tanto, no puede tener archivos Java con el mismo nombre de clase totalmente calificado bajo main
, así como en cualquiera de sus conjuntos de fuentes de sabor. Si lo hace, recibirá un error de clase duplicado .
Para resolver este problema, la solución más simple es mover la actividad de Customization
fuera de la main
y en cada conjunto de fuentes de sabor. Esto funciona porque los directorios de sabor son mutuamente excluyentes (entre sí, no con el main
) evitando así el conflicto.
Pero esto significa que tres de los cuatro sabores tienen una copia duplicada de la actividad – una pesadilla de mantenimiento – sólo porque uno de los sabores requiere algunos cambios en ella. Para resolver este problema podemos introducir otro directorio de origen que mantiene sólo los archivos de código comunes compartidos entre los tres sabores.
Por lo tanto, el script build.gradle
sería algo así como
android { ... productFlavors { flavorOne { ... } flavorTwo { ... } flavorThree { ... } flavorFour { ... } } sourceSets { flavorOne.java.srcDir 'src/common/java' flavorTwo.java.srcDir 'src/common/java' flavorThree.java.srcDir 'src/common/java' } }
Observe el uso de java.srcDir
(y no de srcDirs
) que añade otro directorio de origen Java al ya existente src/flavorX/java
.
Ahora todo lo que necesitamos hacer es dejar caer el archivo de la actividad de Customization
común en src/common/java
para ponerlo a disposición de los sabores de uno a tres. La versión modificada requerida por flavorFour
iría bajo su propio conjunto de fuentes en src/flavorFour/java
.
Por lo tanto, la estructura final del proyecto sería algo así como
+ App // module |- src |- common // shared srcDir |- java |- path/to/pkg |- CustomizationActivity.java // inherited by flavors 1, 2, 3 + flavorOne + flavorTwo + flavorThree + flavorFour |- java |- path/to/pkg |- CustomizationActivity.java // per-flavor activity class |- res |- layout |- activity_customization.xml // overrides src/main/res/layout |- main + java |- res |- layout |- activity_customization.xml // inherited by flavors 1, 2, 3
- Android Share Intent para un mapa de bits – ¿es posible no guardarlo antes de compartir?
- Cómo diseñar un SearchView en la barra de acciones de Android