Configuración de dependencias en Android Studio

Configurar bien las dependencias al inicio de un proyecto Android te ahorra horas de depuración. Aquí aprendes cómo dejar listo tu proyecto en Android Studio con Jetpack Compose, agregando las librerías que vas a usar para navegación, inyección de dependencias, llamadas de red y persistencia de datos.

¿Cómo organizar las versiones en el archivo libs.versions.toml?

El archivo libs.versions.toml funciona como un catálogo central donde declaras todas las versiones de las librerías y plugins de tu proyecto. Centralizar esto evita inconsistencias y facilita actualizar dependencias en un solo lugar.

Dentro del proyecto Platzi Calories, abre la carpeta Gradle y entra al archivo. Ahí vas a declarar las versiones de las librerías que acompañarán todo el desarrollo [00:34].

¿Qué librerías vas a necesitar y para qué sirven?

Cada librería resuelve un problema específico. Estas son las que se agregan al catálogo:

• Coil: carga de imágenes de forma asíncrona.
• Android Lifecycle: soporte para ViewModels.
• Navigation Compose: navegación entre pantallas en Jetpack Compose.
• Hilt: inyección de dependencias.
• Moshi, Retrofit y OkHttp: llamadas de red, serialización de JSON y transformaciones.
• Room: persistencia de datos local.
• KSP: generación de código en tiempo de ejecución.

¿Qué es KSP en Android? Es Kotlin Symbol Processor, el reemplazo moderno de kapt. Genera scripts y clases necesarias en tiempo de ejecución, por ejemplo para que Room funcione correctamente [02:30].

¿Cómo declarar librerías y plugins en el catálogo?

Después de las versiones, declaras cada librería con su grupo, nombre y referencia a la versión que ya creaste. La sintaxis es repetitiva: la copias de la documentación oficial y la pegas dentro de tu archivo.

Luego agrega los plugins que el proyecto necesita en este punto:

• Plugin de Hilt.
• Plugin de Room.
• Plugin de KSP.

Antes de pasar a los archivos build.gradle.kts, ejecuta File → Sync Project with Gradle Files. Esta sincronización hace que las librerías declaradas queden disponibles para implementarse en los archivos de build [03:30].

¿Cómo aplicar los plugins en los archivos build.gradle.kts?

El proyecto tiene dos niveles de configuración Gradle: la raíz y el módulo de aplicación. Cada uno cumple un rol distinto.

¿Qué va en el build.gradle.kts raíz?

En la raíz del proyecto declaras los plugins con apply false. Esto registra los plugins a nivel global sin aplicarlos todavía:

• hilt.gradle.plugin apply false.
• ksp apply false.
• room apply false.

¿Qué va en el build.gradle.kts del módulo app?

Dentro del módulo de aplicación llamas los mismos plugins, pero esta vez sin apply false porque sí los vas a aplicar. Aquí también ajustas el compileSDK y el targetSDK a 35, que corresponde a Android 15, para deshacerte del warning de versión [04:35].

Además, agregas un script extra para Room. Aunque aparezca en rojo al escribirlo, al compilar funciona. Su propósito es crear la base de datos de Room dentro del directorio del proyecto bajo un path llamado Esquemas.

¿Por qué usar apply false en la raíz? Porque registras el plugin en el classpath del proyecto sin activarlo. Lo activas solo en los módulos donde realmente lo necesitas, como el módulo app.

¿Cómo implementar las dependencias en el módulo app?

Una vez declarados los plugins, llega el momento de implementar las librerías dentro del bloque dependencies del módulo. Una buena práctica es separar las librerías de testing de las librerías de la aplicación con un espacio visual.

El orden de implementación que sigue la clase es:

1. Hilt para inyección de dependencias.
2. Navigation Compose para navegar entre pantallas.
3. Coil para cargar imágenes.
4. Moshi, Retrofit y OkHttp para la capa de red.
5. Room para persistencia local.

Después de cada bloque de implementación, vuelve a sincronizar Gradle. Si la barra de progreso termina sin errores y los textos en rojo pasan a amarillo, el proyecto quedó listo para consumir las librerías [06:40].

¿Qué sigue después de la configuración inicial?

Con el catálogo de versiones, los plugins aplicados y las dependencias implementadas, tu base está lista. Esta configuración es la que sostiene todo el código que escribirás más adelante: navegación, ViewModels, llamadas a APIs y guardado local de datos.

En la sección de recursos encuentras la rama inicial del repositorio para clonarla y arrancar la siguiente clase desde el mismo punto. ¿Qué librería de las mencionadas te interesa más explorar a fondo? Cuéntame en los comentarios.