Explore en Android ahora: complementos de la convención de Gradle | de Adam Ahmed | julio 2022

Fuente de la imagen: Github Más bien no, los proyectos terminan en una de estas situaciones:

  1. Muchos scripts *.gradle(.kts) aleatorios que no todos entienden.
  2. Subproyectos muy complicados y bloques de todos los proyectos.
  3. Un directorio buildSrc que contiene la mayor parte de la lógica de compilación.

Los dos primeros pueden causar muchos problemas más adelante, ya que termina con una gran cantidad de código duplicado, ya que los desarrolladores tienden a copiar y pegar estos scripts al crear nuevos módulos, o termina con bloques de configuración masivos que aplican innecesariamente la mayor parte de su compilación. lógica para cada módulo. La tercera opción es un poco mejor en términos de duplicación de código, pero buildSrc no es excelente, ya que invalida el caché de compilación cada vez que realiza cambios en él, lo que resulta en una compilación limpia con cada cambio. Los complementos de convenciones son la forma en que Gradle crea lógica entre submódulos y aborda los problemas anteriores, y la aplicación Now in Android (NiA) aprovecha esto al máximo.

Estos complementos son aditivos y componibles, e intentan realizar una sola tarea. Los módulos pueden entonces seleccionar las configuraciones que necesitan.

Lo primero que vemos aquí son algunos archivos de lógica de configuración que pueden aplicar varios complementos, como AndroidCompose.kt, KotlinAndroid.kt y Flavor.kt. Algunos ejemplos realmente buenos del código base que muestran cómo se relaciona todo esto son los siguientes:

  1. AndroidLibraryConventionPlugin aplica los complementos com.android.library y org.jetbrains.kotlin.android, usa la función configureKotlinAndroid() de KotlinAndroid.kt para configurar elementos como compileSdk , compileOptions, kotlinOptions y Flavor para configurar. kt archivo para configurar variantes del proyecto.

2. AndroidFeatureConventionPlugin aplica los mismos complementos anteriores más org.jetbrains.kotlin.kapt, ya que todos los módulos de características en NiA usan bibliotecas como Hilt que necesitan KAPT para la generación de código. También agrega muchas dependencias comunes como los módulos :core y algunas bibliotecas.3. AndroidLibraryComposeConventionPlugin usa la función configureAndroidCompose() para configurar Compose para que funcione en cualquier módulo al que se aplique. El resultado es que, la mayoría de las veces, los scripts de compilación del módulo de características terminan luciendo como deberían. Sin duplicaciones ni scripts innecesarios que sean difíciles de entender más adelante. Exactamente lo que su módulo necesita.Puede ver de inmediato lo que significa que estos complementos son aditivos y combinables. ¿Quieres un módulo que no use Compose? Simplemente aplique los dos primeros complementos. ¿Quieres usar Redactar? Solo agrega el tercero. Un buen ejemplo de esto en NiA es el script build.gradle.kts en el módulo :feature-author, que puedes ver aquí. Aquellos de ustedes con un buen ojo pueden haber notado que las ID de los complementos son diferentes de sus nombres de archivo, esto se debe a que cuando registra sus complementos personalizados para que estén disponibles para el resto de su proyecto, les da una ID y se da una implementación. Esto se puede ver aquí.Agrégame Linkedin y Gorjeo para hablar de Gradle y Android! 🙂

Deja una respuesta

Tu dirección de correo electrónico no será publicada.