Muy buenas, les saluda Miguel y en esta ocasión les traigo otro post.
Trabajo en un proyecto que ha asumido una estructura interesante, así que quiero compartir la experiencia. El requisito es que se distribuyan dos aplicaciones diferentes, pero además, se supone que una de las aplicaciones contiene toda la funcionalidad de la segunda aplicación.
Una forma más sencilla de decirlo es que queremos que alguna funcionalidad particular de la aplicación principal se distribuya como una aplicación independiente separada.
Al hacer clic en un botón dentro de la aplicación A, se debe iniciar una nueva tarea con la actividad de inicio de la aplicación B. Sin embargo, solo se debe distribuir un único archivo apk para la aplicación A.
Vi esto como un desafío de:
- Configurar recursos compartidos para dos aplicaciones. (Esto es necesario porque, por diseño, las aplicaciones
AyBcompartirían varios componentes de la interfaz de usuario) - Hacer que el código y los recursos de la segunda aplicación estén disponibles en la primera / principal aplicación.
Después de tropezar con varias opciones, diseñé esto al tener los dos módulos de aplicación en un solo proyecto.
Como es bien sabido, en Android Studio, un proyecto normalmente contiene módulos donde uno es un módulo de aplicación («: app») y quizás uno o más son módulos de biblioteca.
Además, un módulo de aplicación no se puede agregar como dependencia a otra aplicación. Entonces, ¿cómo pude hacer que esta estructura de módulo de múltiples aplicaciones funcionara? En este artículo, describiré el proceso para crear dos aplicaciones simples con una estructura de módulo similar.
Luego hablaré sobre algunos de los comportamientos (no) esperados que encontramos con esa estructura y cómo los manejamos.
app en su lugar. El primer paso es agregar el segundo módulo de aplicación, al que llamaremos side-app.
Entonces Archivo > Nuevo > Nuevo módulo ... Por tipo, Seleccione el módulo de teléfono y tableta. En el siguiente formulario, elegimos el nombre del módulo para ser side-app.
Luego, en el siguiente formulario, elegimos una actividad vacía. Siguiente formulario, llamamos Actividad SideActivity. (Recuerde que el objetivo es tener acceso a esta actividad en el módulo app). Termina la creación de side-app.
Luego tenemos que crear dos módulos de biblioteca más. Uno debería ser nombrado common-lib para contener recursos compartidos entre los dos módulos de la aplicación, luego otro módulo de biblioteca para ser un módulo sombra para side-app en el módulo app.
Llamaremos a este módulo de sombra side-app-shadow.
Ahora abra los archivos build.gradle de los cuatro módulos para gestionar las interdependencias.
Primero, side-app debería implementar common-lib.
implementation project(“:common-lib”)
App necesita el common-lib también, pero lo haría a través del side-app-shadow. Entonces obtiene side-app-shadow:
api project(“:common-lib”)
Mientras consigue app.
implementation project(“:side-app-shadow”)
Ahora, para hacer el real "shading" de la aplicación lateral, usamos conjuntos de fuentes de Gradle. Básicamente, le diremos a side-app-shadow que obtenga su código, recursos y archivos de activos del directorio del módulo de la aplicación lateral.
Para hacer esto, vaya a build.gradle para side-app-shadow y agregue el siguiente código dentro del bloque {} de android
Las encima eficazmente sincroniza archivos desde el lado de la aplicación de lado la aplicación de sombras .
Se ve ahora que side-app-shadow contiene el paquete com.example.side_app además de su propio com.example.side_app_shadow.
Esto es bueno. Sin embargo, los archivos gradle y los archivos de manifiesto para estos dos módulos aún deben mantenerse sincronizados manualmente.
Cualquier dependencia nueva agregada a la aplicación lateral debe agregarse a la sombra de la aplicación lateral (usando el alcance de la api si el módulo de la aplicación también lo requiere).
De manera similar, cualquier permiso, actividad, servicio o receptor nuevo agregado al manifiesto para la aplicación lateral La aplicación debe agregarse a side-app-shadow.
Después de esto, SideActivity (junto con cualquier otra clase, recurso o activo que se cree en la aplicación lateral) se puede hacer referencia dentro del módulo de la aplicación y se puede iniciar con una intención.
Ambas aplicaciones ahora aparecen en las configuraciones para la depuración en un dispositivo. Además, los dos apks se generan cuando compila apk (s) de depuración desde el menú de compilación.
En las siguientes partes, discutiré algunos problemas que surgieron debido a esta arquitectura y cómo se manejaron en el proyecto. La primera es con las clases de aplicaciones.
Varias clases de aplicaciones
Necesitábamos tener clases que extendieran la aplicación tanto en la aplicación como en la aplicación lateral, y ambas clases contienen código que queremos que se ejecute en el lanzamiento.
Para el módulo de aplicación lateral, la clase se abre.
open class App : Application()
Para el módulo de la aplicación, ampliamos la aplicación lateral.
class App : com.example.side_app.App()
Y añadir.
android:name=".App"
A los manifiestos de aplicaciones y aplicaciones laterales ( pero no a la sombra de aplicaciones laterales ) entre las etiquetas de la aplicación.
Glide's GlideModule
El segundo problema persistente que enfrentamos fue con la biblioteca de carga de imágenes Glide. Ambos módulos de aplicación hacen uso de deslizamiento y tienen una clase cada uno que amplía AppGlideModule y está anotado con @GlideModule.
Encuentro que Glide se queja de que: El tipo com.bumptech.glide.GeneratedAppGlideModuleImpl se define varias veces.
Traté de resolver esto agregando una exclusión al scrDir de java.
exclude '**/MyGlideModule.kt'
Pero, por razones desconocidas, esto no lo resolvió. La solución que utilicé implicó tener solo un GlideModule, en el módulo de sombra, y luego algunos otros ajustes que son peculiares de mi uso de Glide, por lo que no lo compartiré aquí.
Si cree que existe una forma más eficiente de lograr el mismo objetivo, deje una nota en los comentarios.
Gracias por leer este post.
Añadir comentario