¿Qué es Jetpack Compose?

Imagen
Jetpack Compose es la biblioteca de IU de Android más reciente que ha tomado la plataforma de desarrollo móvil de Android por sorpresa. Con Jetpack Compose, los desarrolladores pueden construir aplicaciones de alta calidad y sofisticadas que son más fáciles de mantener y escalar. La introducción de Jetpack Compose representa un cambio significativo en la forma en que se crea la interfaz de usuario de una aplicación de Android. En lugar de trabajar con una jerarquía de vistas de Android, Jetpack Compose utiliza un enfoque de programación declarativa para definir la IU de una aplicación. Esto significa que los desarrolladores pueden escribir código que describe cómo debe verse la interfaz de usuario de una aplicación, en lugar de manipular directamente los objetos de vista. Jetpack Compose también viene con una serie de herramientas que facilitan el diseño y la personalización de la interfaz de usuario de una aplicación. Desde una amplia variedad de widgets personalizados hasta la capaci

Build Variants | Variantes de compilación de Android Studio.

Android Studio es una herramienta maravillosa con muchas características que facilitan el desarrollo de nuestras aplicaciones.

Hoy les quiero hablar sobre las variantes de compilación o Build Variants en inglés, quizá no sea la mejor traducción pero es la que me parece correcta

Las variantes de compilación te permiten generar diferentes versiones de tu aplicación según sea la necesidad de tu proyecto. El ejemplo que tiene la documentación de Android sería una aplicación que tiene la versión full y la versión demo. Voy a crear estas dos variantes de compilación en el siguiente tutorial.

Una vez creado nuestro proyecto, lo primero que vamos a hacer es abrir la configuración del módulo de la aplicación. Hacemos clic derecho en app -> Open Module Settings o en Mac, presionamos Command + Flecha hacia abajo.

Open Module Settings

Esto nos mostrará el dialogo de la estructura del proyecto.

Project Structure

Este dialogo tiene las pestañas Properties, Signing, Flavors, Build Types y Dependencies. Voy a explicar un poco para qué es cada pestaña

Properties

Sirve para configurar las propiedades del proyecto.

Compile SDK Version. Aquí seleccionamos la versión del SDK de compilación, para este ejemplo estoy usando 6.0 Marshmallow.
Build Tools Version. La versión de Android build tools.
Library Repository. Esto no se qué hace. Lo dejamos en blanco.
Ignore Assets Pattern. Tampoco sé qué hace. Lo dejamos en blanco.
Incremental Dex, true o false para activar o desactivar la compilación incremental dex.
Source compatibility, Es la versión de java compatible.
Target compatibility, Es la versión de java que se usará en el proyecto. 

Estas dos últimas por defecto son la 1.7 pero si queremos por ejemplo desarrollar para android N y java 8, podríamos seleccionar target compatibility en 1.8 

Signing 

Sirve para configurar los certificados con los que se firmará la aplicación. Les describo un ejemplo de su uso.

Para la empresa donde trabajo uno de sus clientes tiene configurado su perfil de desarrollador en Google Play, y la compañía también. Cuando el cliente sube la aplicación a Google Play hay que firmar la app con el certificado que ellos usaron inicialmente. En la empresa tenemos la misma aplicación para propósitos de pruebas pero firmada con otro certificado. Recuerden que una vez subida una aplicación a Google Play siempre se tiene que firmar con el mismo certificado sino Google Play nos va mostrar un error como este


Dicho esto, vamos a suponer que necesitamos que la versión full tenga un certificado y la versión demo tenga otro. 

Para agregar los certificados, le damos clic al botón más y llenamos los datos que se pide.

Certificado para la versión demo

Certificado para la versión Full
Key Alias, es el alias del certificado
Key Password, el password del certificado
Store File, la ubicación del certificado, en este caso la agregué dentro del directorio app/ luego esto se reemplazará, en el .gradle
Store password, el password del key store.

Flavors



Luego los sabores o flavors de nuestra aplicación.
Flavor + Build Type = Build Variant
La fórmula lo que quiere decir es que por cada Flavor y Build Type obtendremos un Build Variant. 

Comenté que la aplicación tendría dos variantes: Demo y Full. En esta pestaña definimos estos valores, por defecto todos los proyectos tienen un sabor llamado defaultConfig es importante saber que NO debemos borrar este sabor, puesto que los demás van a heredar de defaultConfig.

Para agregar un sabor hacemos clic en el botón + y llenamos los datos que nos pide.

Flavor demo

Flavor full

 Cada campos significa lo siguiente. 

Name, nombre del sabor
Min SDK version, al estar definido en defaultConfig, los demás sabores no tienen por qué llenarse a menos, que estemos creando una versión de la aplicación específica para una versión de Android.
Application Id, para que nuestra app se compile con diferente id. Si se fijan en las dos imágenes anteriores, los id son com.pedrovarela.android.demo com.pedrovarela.android.full 
Proguard File, es el archivo Pro Guard que se usa para reducir el tamaño de la aplicación eliminado código y recursos que no se utilizan para más información lee Shrink Your Code and Resources.
Signing Config, el certificado con el que se firmara cada versión, estos los creamos anteriormente.
Target Sdk Version, la versión máxima de android en la que correrá nuestra app, la dejamos en blanco puesto que ya está definida en defaultConfig, a menos claro, que sea un caso específico. 
Test Instrumentation Runner, esto es nuevo pero es para configurar pruebas unitarias 
Test Application Id, el id de la app para las pruebas.
Version Code, el código de versión.
Version Name, el nombre de la versión.
Version Name Suffix, el sufijo del nombre de la versión.

Build Types


Los Build Types son los tipos de compilación, siempre tendremos estos dos no hay necesidad de agregar más. Tenemos,  debug que se usa para las versiones de depuración y release que se usa para la versión de producción.

Dependencies

Las dependencias y librerías de nuestro proyecto


Bien, ya tenemos configurado nuestro proyecto para trabajar con build variants pero eso no es todo amigos!!

Android studio no crea la estructura de directorios necesaria para que las variantes funcionen correctamente, lo que quiere decir que hay que agregarlas manualmente. Para esto, hacemos lo siguiente:


Cambiamos la vista del proyecto de Android a Project Files


Seleccionamos src, hacemos click derecho, y creamos un nuevo directorio. 


Para este ejemplo tenemos dos Flavours, así que serían dos directorios. Los directorios se tienen que llamar igual que los Flavours, es decir demo y full, quedando lo así.


Listo, ahora si tenemos todo casi listo para que nuestro proyecto funcione con Build Variants. En la imagen anterior vemos un archivo que se llama build.gradle.  Este archivo contiene todo lo que acabamos de configurar en el dialogo de la estructura del proyecto al abrirlo veremos algo como esto.



Si se fijan, tenemos todo los definido signingConfig, defaultConfig, buildTypes, productFlavors y dependencies. 

Bien, ahora cómo usamos todo esto. 

Supongamos que los nombres de nuestras aplicaciones tienen que ser diferentes para cada variante. Demo, se llamará Aplicación Demo, y Full se llamará Aplicación Full. 

Cada flavor puede tener sus propios archivos de strings, drawables, inclusive reemplazar actividades, fragmentos y clases. Para este ejemplo sencillo solo vamos a cambiar el nombre de la aplicación. ¿Qué hacemos? copiamos y pegamos los archivos que necesitamos en cada directorio del flavor, en este caso sería strings.xml. Es importante saber que todos los flavor tienen que reemplazar el archivo strings.xml. Por cierto, si hay algo que no queremos reemplazar o que se mantenga igual en ambos flavours, el directorio main es el principal (qué sería el que estuviésemos usando si no usamos los build variants) 

Una vez copiados y pegados los recursos que queremos abrimos cada strings.xml y modificamos el nombre,  quedando lo siguiente.



Para verificar que está funcionando, buscamos el panel que se llama Build Variants, yo lo tengo a la izquierda de Android Studio. Al abrirlo, vamos a ver dos columnas, Module y Build Variant. Aquí se aplica la fórmula que les comente anteriormente. Flavor + BuildType = BuildVariant. Tenemos entonces demoDebug, demoRelease, fullDebug, fullRelease.  Al seleccionar un Build Variant podemos ver automáticamente cambia todo. Abran el archivo main.xml y cambien de variant en variant para que vean como cambia el texto Hello World y el título de la actividad.

Aplicación Demo

Aplicaión Full

Listo ya esta todo funcional, si quieren correr la aplicación en su equipo, tienen que ver qué BuildVariant está seleccionada. La variante seleccionada es la que va a instalarse.

Al correr las dos variantes vemos en el equipo los dos iconos.



 


¿Cómo compilar las Build Variants?


Fácil, abrimos el terminal y escribimos (esto en Mac) ./gradlew assembleRelease


El resultado será los apk de las variantes de compilación. Los buscamos en

RutaDelProyecto/app/build/outputs/apk



Saludos, espero sus comentarios y les sea de utilidad. Código Fuente Aquí

Comentarios

Entradas más populares de este blog

Hacer la barra de status transparente en Android.

¿Qué es Jetpack Compose?

Solicitar permisos en Android en tiempo de ejecución más fácilmente