Kotlin 35. Introducción a Android Gradle

Aprendamos Kotlin juntos: concepto: 22. Introducción a Android Gradle

Cuando comenzamos a desarrollar Android, nadie le prestó atención a Gradle. Nuestro enfoque principal es escribir código Kotlin y aplicaciones de Android que se vean lo mejor posible. Pero a medida que el tiempo ha cambiado, yo mismo me he vuelto cada vez más curioso acerca de Gradle. ¿Qué es exactamente Gradle? ¿Cómo debo usarlo exactamente?

Mientras creamos estas aplicaciones, a veces nos topamos con un problema que ha sido resuelto por otra persona en Internet, y han tenido la amabilidad de compartir su proyecto como una biblioteca que podemos implementar en nuestra aplicación, y en función de nuestra necesidad de personalizarlo. Para hacer esto, usamos build.gradlearchivos para implementar las bibliotecas que nos ayudan a construir nuestras aplicaciones especificando sus nombres y versiones de paquetes únicos. Este es probablemente el caso de uso más común en el que usamos Gradle para proyectos de Android.

¿Pero qué más? Cuando yo mismo estaba escribiendo código, todos los archivos de gradle se mantenían a una distancia respetuosa, y no me atrevía a modificarlos, ni quería modificarlos, lo que me hizo sentir cada vez más curiosidad por gradle. Si eres como yo y quieres saber más sobre gradle, puedes leer este blog.

---

---

1 ¿Qué es Gradle?

Gradle, nuestra herramienta de creación para el desarrollo de Android, automatiza el proceso de creación y publicación de aplicaciones. Podríamos pensar que crear y ejecutar una aplicación es tan simple como presionar el botón ejecutar en Android Studio. Bueno, en realidad, detrás de escena, este botón activa las tareas (funciones) integradas de Gradle que son responsables de ejecutar la aplicación en nuestro emulador o dispositivo real. Este proceso toma varios pasos para completarse con éxito y que podamos ver la aplicación en acción. Estos son los pasos generales que suceden cuando presionamos el botón ejecutar:

• Gradle lee el archivo de configuración de compilación de la aplicación (build.gradle), que contiene información sobre dependencias, tipos de compilación y más.
• Gradle descarga y resuelve las dependencias de la aplicación.
• Gradle compila el código de la aplicación, incluida la conversión del código Java o Kotlin en código de bytes.
• Gradle luego empaqueta el código compilado y los recursos en un archivo APK.

Gradle viene con una gran cantidad de funciones integradas, pero también nos permite escribir nuestra propia lógica. Proporciona su propio lenguaje específico de dominio (lenguaje específico de dominio/DSL), que es un lenguaje de programación diseñado para el campo de la automatización de compilación, que se basa en Groovy o Kotlin para describir el script de compilación.

No importa qué lenguaje de programación usemos, la estructura del archivo gradle es la misma, todos están construidos a partir de las mismas partes del DSL.

2 build.gradle y configuraciones.gradle

Un proyecto de Android consta de un settings.gradlearchivo y dos build.gradlearchivos, uno ubicado en el directorio raíz y el otro incluido en el módulo de la aplicación. ProjectEsto puede confundirnos fácilmente cuando abrimos la estructura de nuestro proyecto en el diseño de Android, pero contendrán una pequeña descripción en forma de y al lado de sus nombres Module.

2.1 configuración.gradle

Vemos que además de estos dos, también hay un settings.gradlearchivo en el directorio raíz. Comencemos desde allí para comprender el proceso del archivo gradle.

La imagen de arriba muestra el archivo settings.gradle escrito en Groovy a la izquierda y el mismo archivo escrito en Kotlin a la derecha. Tiene dos partes principales:

• administración de complementos
• Gestión de resolución de dependencias

Ambas partes son funciones regulares, pero dado que solo toman un argumento y ese argumento tiene la forma de una función lambda, podemos omitir los paréntesis.

pluginManagementLa función contiene una función lambda como parámetro, que proporciona un PluginManagementSpecparámetro al que se puede Groovyacceder mediante "it" o "this" en las palabras clave del lenguaje Kotlin (pero no es necesario especificarlas explícitamente). En PluginManagementSpec, podemos encontrar una repositoriesnueva función llamada , que toma la nueva función lambda como parámetro e internamente proporciona un RepositoryHandlerparámetro. Ahí es donde pasamos la lista de repositorios. Los repositorios mencionados aquí básicamente representan lugares donde Gradle intentará encontrar complementos (los que necesita nuestro proyecto) y descargar los que encuentre. Más adelante, veremos dónde debemos especificar los complementos necesarios.

dependencyResolutionManagementLa función pluginManagementes similar a la función, pero proporciona una lista de repositorios donde Gradle buscará las dependencias requeridas por el proyecto.

Entonces, ¿cuál es la diferencia entre complementos y dependencias? Las dependencias son todas las bibliotecas de terceros que podemos usar en el código de Kotlin mientras desarrollamos la aplicación. Los complementos, por otro lado, son similares a las dependencias; la gran diferencia es que los complementos proporcionan todas las tareas (funcionalidad) que Gradle usa al construir nuestro proyecto. Entonces, básicamente es una biblioteca de terceros para nuestro archivo gradle.

Funciones gradle Groovy vs Kotlin

En settings.gradlela parte inferior del archivo hay una línea que especifica qué módulos se incluyen en el proyecto, que se ve similar en Groovy include ':app'. Esta oración en realidad se refiere a una función regular include, que recibe una variable de tipo String. GroovyTiene una función que permite a los desarrolladores llamar a funciones que requieren un argumento sin paréntesis. En Groovy, podemos definir cadenas usando comillas simples y dobles. Entonces, la línea equivalente en Kotlin es include(”:app”).

2.2 build.gradle (Proyecto)

Los archivos a nivel de proyecto build.gradlese utilizan para definir la configuración y los ajustes globales para todo el proyecto. También se usa para implementar dependencias y complementos en el nivel superior. De forma predeterminada, build.gradle (Project)todos los módulos del proyecto deben heredar todas las configuraciones y configuraciones del proyecto, y build.gradle (Module)el archivo debe poder anularlas.

Las cosas más comunes establecidas a nivel de proyecto build.gradleson los complementos necesarios para crear aplicaciones de Android, por ejemplo:

• Android Gradle
• kotlin
• Empuñadura

A veces, también necesitamos agregar bibliotecas que queremos usar en todos los módulos, por ejemplo:

• Biblioteca de soporte de Android
• Biblioteca de servicios de Google Play

Este es un ejemplo del build.gradle a nivel de proyecto que tenemos al iniciar un nuevo proyecto de Android.

// Top-level build file where you can add configuration options common to all sub-projects/modules.
plugins {
    id 'com.android.application' version '7.2.1' apply false
    id 'com.android.library' version '7.2.1' apply false
    id 'org.jetbrains.kotlin.android' version '1.6.10' apply false
}

task clean(type: Delete) {
    delete rootProject.buildDir
}

La parte importante para nosotros es el método de complementos, que nos permite definir los complementos principales que son esenciales para nuestro proyecto de Android. A continuación, echemos un vistazo a la sintaxis para definir estos complementos: Primero, llamamos ida la función y pasamos un parámetro de tipo String que representa el nombre de paquete único del complemento que queremos usar. Esto es equivalente a id(”com.android.application”). El siguiente paso es configurar la versión del complemento anterior; esta también es una función que acepta un parámetro de tipo cadena. El truco aquí es que la función de versión solo PluginDependencySpecse puede llamar desde objetos, y el objeto que recibimos es id("...")el resultado de la función. Lo mismo se aplica a applyla palabra clave; también es una función, al versionigual que , pero toma un valor booleano como argumento. Si quisiéramos migrarlo a Kotlin para mejorar la legibilidad de este código, la línea sería así id(“com.android.application”).version(“7.2.1”).apply(false).

2.3 build.gradle (Módulo)

El último y más utilizado es build.gradle en nuestro módulo de aplicación. Se utiliza para definir la configuración y los ajustes utilizados para este módulo en particular. En términos de funcionalidad, tiene opciones similares a build.gradle a nivel de proyecto, pero trae separación de preocupaciones. Por lo tanto, todas las bibliotecas y marcos que queramos usar en el código Kotlin colocado en nuestros módulos de aplicación, deben definirse en el bloque de dependencias de este archivo gradle. Todos los complementos necesarios para que estas bibliotecas funcionen también deben definirse en el mismo archivo gradle.

Si nos fijamos build.gradle (Module), podemos encontrar tres apartados principales:

• Complementos
• Androide
• dependencias

Ya estamos familiarizados con la sección de complementos y dependencias (son muy similares a los que ya hemos cubierto). Lo nuevo aquí es la parte de Android. Aquí es donde podemos hacer muchos cambios de configuración en nuestra aplicación. Las cosas más comunes que los desarrolladores establecen aquí son:

• Versiones de minSdk, targetSdk y compileSdk.
• El código de versión y el nombre de la aplicación.
• Sabores de productos y tipos de construcción.

A continuación se muestra build.gradle (Module)un ejemplo de .

plugins {
    id 'com.android.application'
    id 'org.jetbrains.kotlin.android'
}

android {
    compileSdk 32

    defaultConfig {
        applicationId "com.example.myapplication"
        minSdk 28
        targetSdk 32
        versionCode 1
        versionName "1.0"

        testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
    }

    buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
        }
    }
    compileOptions {
        sourceCompatibility JavaVersion.VERSION_1_8
        targetCompatibility JavaVersion.VERSION_1_8
    }
    kotlinOptions {
        jvmTarget = '1.8'
    }
}

dependencies {

    implementation 'androidx.core:core-ktx:1.7.0'
    implementation 'androidx.appcompat:appcompat:1.5.1'
    implementation 'com.google.android.material:material:1.6.1'
    implementation 'androidx.constraintlayout:constraintlayout:2.1.4'
    testImplementation 'junit:junit:4.13.2'
    androidTestImplementation 'androidx.test.ext:junit:1.1.3'
    androidTestImplementation 'androidx.test.espresso:espresso-core:3.4.0'
}

Ahora, hemos cubierto la mayoría de las cosas básicas mencionadas en nuestro archivo gradle.