DEV Community: disced

Lo Mejor De NestJS

disced — Wed, 19 Mar 2025 14:47:28 +0000

Índice

¿Por qué me gusta NestJS para el desarrollo backend con TypeScript?
Módulos en NestJS
1. Controladores
2. Servicios
3. Datos (Repositorios)
4. Resumen
Inyección de Dependencias
1. @Injectable
2. Inyección en el constructor
3. Inyección en propiedades
Documentación oficial Módulos NestJS
Documentación oficial Inyección de dependencias NestJS

¿Por qué me gusta NestJS para el desarrollo backend con TypeScript?

Si eres como yo y prefieres tener las cosas bien estructuradas y organizadas, es probable que también te gusten los lenguajes más estrictos, como TypeScript en lugar de JavaScript, o los frameworks que imponen una forma estándar de trabajar, como Angular en vez de React. Esto no significa que una opción sea mejor que otra, simplemente son diferentes enfoques, y personalmente me inclino más por este tipo de herramientas (aunque no descarto las demás).

Recientemente he descubierto también Encore.ts, creo que no es tan estructurado pero no lo he trabajado

Bajo esta premisa, NestJS me resulta atractivo porque proporciona una estructura clara y organizada para el desarrollo backend. A veces puede dar dolores de cabeza, su enfoque basado en principios sólidos como la inyección de dependencias y la arquitectura modular hace que el código sea más mantenible y escalable.

A continuación, haré un breve resumen de la arquitectura básica que sigue NestJS.

Módulos en NestJS

La idea principal en NestJS es dividir el proyecto en módulos. Pero, ¿qué es exactamente un módulo?
Lo podemos entender como una unidad fundamental que encapsula una parte de la lógica de negocio.

Por ejemplo, si el requisito del cliente es desarrollar un blog con entradas y usuarios, en un primer análisis podríamos identificar dos módulos principales:

Módulo de Usuarios
Módulo de Entradas

Cada módulo, a su vez, se organiza en distintos componentes esenciales:

Controlador: Maneja las solicitudes HTTP y define los endpoints del módulo.
Servicio: Contiene la lógica de negocio y actúa como intermediario entre el controlador y los datos.
Datos: Generalmente representados por entidades, repositorios o modelos que interactúan con la base de datos.

Para definir un módulo se hace de la siguiente forma:

Controladores

El controlador de un módulo es una clase cuya única función es exponer los endpoints del módulo e interactuar con el cliente. Se encarga de recibir las requests y devolver las responses, pero no implementa ninguna lógica de negocio.

El controller debe implementar el servicio, pero en el anterior ejemplo no lo usamos para que sea más sencillo de comprender.

Servicios

Los servicios son clases encargadas de ejecutar la lógica de negocio. Reciben los datos desde el controlador, los procesan y realizan las operaciones necesarias antes de devolver una respuesta.

Son el núcleo de la aplicación y permiten mantener una arquitectura limpia y bien organizada.

El servicio implementará la clase encargada de acceder a los datos, en este caso no lo hacemos para que sea más sencillo de entender. Pero el servicio nunca accederá directamente a los datos.

Datos (Repositorios)

Los datos o repositorios son clases dedicadas exclusivamente** al acceso y gestión de datos**. Pueden obtener información desde bases de datos, ficheros, otras APIs, o cualquier otra fuente externa.

Su función es desacoplar la lógica de acceso a datos del resto de la aplicación, facilitando la mantenibilidad y escalabilidad del proyecto.

En este caso no proporcionaré un ejemplo, ya que la implementación de la clase varía dependiendo de la biblioteca utilizada (mongoose, typeorm, prisma) y la base de datos empleada.

Resumen

En un módulo de NestJS, contamos con tres clases bien diferenciadas, cada una con una responsabilidad específica:

Cada clase cumple su función sin invadir la responsabilidad de las demás, manteniendo una separación clara de responsabilidades.

Además, siguen una jerarquía en la que cada capa solo interactúa con la inferior:

El controlador utiliza el servicio, pero el servicio no tiene conocimiento del controlador.
El servicio utiliza los repositorios o fuentes de datos, pero estos no conocen al servicio.

Te habrás dado cuenta de que esta estructura sigue los principios de Domain-Driven Design (DDD) y Clean Architecture. Esto es una gran ventaja, ya que nos permite mantener una clara separación de responsabilidades, lo que facilita la organización del código y mejora la testabilidad de cada componente de forma independiente.

Inyección de Dependencias

Otra de las características fundamentales de NestJS es su sistema de inyección de dependencias, un concepto utilizado en frameworks como Spring Boot. Este mecanismo es clave para lograr una mayor flexibilidad y modularidad en nuestras aplicaciones.

Al aplicar este patrón, evitamos la necesidad de instanciar manualmente las clases. Es decir, nunca crearemos objetos con new UserService(). En su lugar, simplemente indicamos que necesitamos una clase del tipo UserService, y NestJS se encargará de gestionar su instancia.

De forma predeterminada las clases que inyectemos son tipo Singleton (DEFAULT), hay que tenerlo en cuenta en ciertas ocasiones.

Cuando una clase es requerida, Nest verifica en su registro interno si ya existe una instancia disponible. Si es así, la reutiliza; de lo contrario, la crea automáticamente. Por defecto, todas las clases inyectadas son Singleton, lo que significa que se instancian una única vez y se comparten en toda la aplicación, optimizando el uso de recursos.

Este enfoque no solo hace que el código sea más limpio y mantenible, sino que también facilita la escalabilidad del proyecto.

Injectable

Cualquier clase anotada con @Injectable es gestionada por el contenedor de dependencias (IoC) de NestJS. Si, por ejemplo, tenemos una clase de utilidades que queremos usar en el módulo de User, debemos importar dicha clase en el módulo y declararla dentro del array de providers. Una vez hecho esto, ya podremos aprovechar la inyección de dependencias.

Existen dos formas principales de inyectar dependencias:

En el constructor: la forma recomendada y por defecto.
En las propiedades: utilizada en casos específicos, como cuando trabajamos con herencia y necesitamos llamar al método super() de la clase padre.

Inyección en el constructor

Esta es la forma más común y sencilla de hacerlo. Cuando encuentres una clase con un constructor que tenga uno o más argumentos, estos generalmente serán otras clases (o valores) que NestJS inyecta automáticamente en esa clase.

En el ejemplo anterior, tenemos el controlador UserController y el servicio UserService. Según la arquitectura propuesta, el controlador debería utilizar el servicio. Para lograr esto, inyectamos el servicio en el constructor del controlador, y NestJS se encargará automáticamente del resto.

Inyección en propiedades

Aunque menos común, esta técnica también es válida. La usamos en situaciones específicas, como cuando una clase hereda de otra y necesitamos llamar al método super() del padre. Esto evita que tengamos que modificar ambas clases. Para hacerlo, usamos el decorador @Inject() y le pasamos el token o la clase que queremos inyectar en la propiedad.

Esta opción también es válida para la inyección:

Documentación oficial Módulos NestJS

Documentation | NestJS - A progressive Node.js framework

Nest is a framework for building efficient, scalable Node.js server-side applications. It uses progressive JavaScript, is built with TypeScript and combines elements of OOP (Object Oriented Programming), FP (Functional Programming), and FRP (Functional Reactive Programming).

docs.nestjs.com

Documentación oficial Inyección de dependencias NestJS

Documentation | NestJS - A progressive Node.js framework

docs.nestjs.com

Arquitectura Limpia

disced — Sun, 15 Oct 2023 09:50:23 +0000

Índice

Introducción
Tipos
Estructura
- Enterprise Business Rules
- Application Business Rules
- Interface Adapters
- Frameworks and Drivers
Regla de la dependencia
Diagrama desglosado

Introducción

En este post no voy a explicar para que utilizar la Arquitectura Limpia, ni que ventajas tiene ni las características.

Lo que sí voy a explicar es como utilizarlo y que contiene cada capa.

Lo que pretendo es que tú como lector no tengas que recurrir a tantas fuentes como yo para saber poner en práctica el concepto, que en última instancia, es lo más importante sobre este tema.

Tipos

Seguramente te suenen cosas como DDD, Arquitectura Hexagonal, Arquitectura Onion, etc.

Todos estos ejemplos tienen que ver en como estructurar el código de nuestros programas. Son distintos tipos de arquitecturas de software.

El problema que yo he encontrado a medida que aprendía sobre el tema, es que, en multitud de ocasiones se explica de forma muy general los conceptos (definiciones muy de Wikipedia), en otras ocasiones me he encontrado que se mezclan términos de una arquitectura a otra o se cambia el nombre de las cosas y todos estos hechos al final confunden mucho.

Dicho esto, yo explicaré solamente Clean Architecture propuesto por Robert C. Martin (el Tío Bob). Como es la estructura, que contiene cada capa y poniendo algunos ejemplos reales para cada capa. También he desglosado el gráfico para hacerlo como una especie de cheatsheet que está al final del artículo.

Estructura

El modelo propuesto por el tío Bob imagino que lo habrás visto en multitud de ocasiones y también todas sus variaciones (al final todas las arquitecturas tienen similitudes) y es el que tenemos en la siguiente imagen:

Yo cuando veía esta imagen aun conociendo Clean Architecture me costaba entenderla y dependiendo del stack que utilices puedes entenderla aún menos.

Los nombres reales de cada círculo o capa son los de la leyenda de la derecha y no lo que hay en cada círculo 💥.

Yo no entendía que era que, por muchas definiciones de Entities que leyera, o Enterprise Bussiness Rules seguía sin comprenderlo porque todo el mundo usa la misma definición.

Es decir, que lo que está escrito dentro de los círculos son simplemente ejemplos (lo menciono por si a alguien le ha pasado como a mí).

La estructura es la siguiente (desde dentro hacia afuera):

Enterprise Business Rules
Application Business Rules
Interface Adapters
Frameworks and Drivers

Perfecto! no se entiende nada o muy poco.

Enterprise Business Rules

En este círculo vas a almacenar cosas como:

interface (typescript)
data class (kotlin)
record (c#)
record (java)

Te habrás dado cuenta de que solamente se engloban clases de datos o en algún casual una clase con atributos y métodos, pero que no salga al exterior.

Que no salga al exterior quiere decir que no deberá utilizar cosas como la base de datos, APIs o cualquier otra conexión con elementos externos.

Estas clases solo se conocen a ellas mismas, son como Narciso, no ven más allá de su ombligo.

Application Business Rules

En este círculo guardarás el código relacionado con la aplicación, API, web o lo que sea que programes.

Si mi aplicación cuenta con un carrito de compra, aquí harás las operaciones necesarias con el carrito de compra.
Si mi backend debe generar un PDF lo harás aquí.
Si la app calcula cuantos coches pueden entrar en un aparcamiento (todavía inexistente el aparcamiento) conociendo los m² del aparcamiento, el cálculo lo harás aquí.

Algunos ejemplos concretos de que deberás englobar aquí son los siguientes:

controllers (expressjs)
service (java spring boot)
Servicios (.net)
Injectable (nestjs)

En muchos programas las 2 capas internas (Enterprise Business Rules y Application Business Rules) se engloban en una única que la llaman Dominio o Domain.

El nombre se refiere al núcleo del negocio o al propósito principal de la aplicación.

Interface Adapters

Este círculo funciona como puente entre el anterior y el siguiente.

El círculo contendrá cosas como:

router (expressjs)
controller (java spring boot)
ApiController (.net)
controller (nestjs)

También se utilizarán los repositorios inyectándolos por ejemplo en los controladores o servicios, así el controlador/servicio podrá utilizar la base de datos pero no directamente. O podrá hacer peticiones a una API externa.

Disclaimer ⚠

Como harás observado en ExpressJS existen Controllers y Routers y en los demás framworks a estos elementos se les llama Servicios y Controllers, pero vienen a ser lo mismo con distintos nombres.

ExpressJS	Spring Boot	.Net	NestJS
Controller	Service	Servicios	Injectables
Router	Controller	ApiController	Controller

Frameworks and Drivers

Este puede llegar a ser algo confuso, ya que engloba cosas como la base de datos y la web y esto es raro porque al verlo así, en nuestra cabeza ponemos en el mismo nivel el código de la base de datos y el de la web.

Aquí guardarás cosas como los DTOs, las consultas a base de datos, las tablas, el cliente web.

Regla de la dependencia

Una vez entendemos la estructura debemos entender como usar los elementos entre sí. Para utilizar de forma correcta cada elemento siempre nos guiaremos por la Regla de la Dependencia.

Y esta regla en esencia es que los elementos del interior se conocen solamente a ellos mismos y a nadie de fuera.

Es decir, que los círculos de fuera siempre van a conocer (y usar) a los de dentro y nunca al revés.

Por lo tanto, podemos afirmar:

Las consultas a bases de datos pueden hacer uso de un data class.

Ya que se encuentran en Frameworks & Drivers
Un controller (expressjs) puede usar un interface.

El controller en este caso forma parte de Application Business Rules
Un ApiController usará los servicios.

Forma parte de Interface Adapters

Pero nunca al revés, desde dentro hacia afuera:

En una data class nunca se utilizará un controller o la base de datos.

Diagrama desglosado

Comprendiendo lo anterior he intentado desglosar el gráfico y hacerlo más entendible para mí con la esperanza de que para ti también sea más entendible:

ViewModel en Android

disced — Fri, 15 Sep 2023 08:32:07 +0000

Índice

Qué es
Para qué sirve
Beneficios de uso
Ciclo de vida
Implementación básica
- Dependencias
- Clase ViewModel
- Composable
Implementación con DI
ViewModel Cheatsheet
Referencias

Qué es

El ViewModel en Android forma parte del patrón arquitectónico Model-View-ViewModel, siendo éste el ultimo de dicho patrón.

Es decir que es una forma de organizar el código para que sea mas entendible, mas estructurado y mas testable.

Para qué sirve

La idea fundamental es tener la parte lógica y las variables fuera de la vista (fuera del codigo de jetpack compose por ejemplo).

Por ejemplo si vamos a hacer una petición a una API HTTP u obtener datos de una base de datos, esta funcionalidad deberíamos realizarla desde el ViewModel. De esta manera conseguimos que en la vista solo se rendericen datos para que el usuario los vea, en ningún momento tenemos lógica.

El ViewModel no debe interactuar directamente con una API o una base de datos, utilizaremos el patrón Repository. Solo debe utilizar el repositorio, obtener los datos en "crudo" y realizar las modificaciones oportunas para enviarlas a la view.

Beneficios de uso

Las ventajas principales de utilizar ViewModel en Android son:

El ciclo de vida del ViewModel tiene mas alcance que un Activity

Esto nos permite almacenar datos (variables) y si hay un cambio en el dispositivo, como rotación de pantalla, los datos seguirán presentes en el ViewModel. Conserva el estado de las vistas.

Nos proporciona acceso a la lógica empresarial

Ciclo de vida

El ViewModel no consta de un ciclo de vida tradicional como el que encontramos en las Activity o Fragment. En su lugar, tiene un alcance específico dentro del ciclo de vida, y este alcance es más extenso.

A diferencia del ciclo de vida de una Activity o Fragment, el ViewModel ofrece un alcance más amplio. Esta particularidad nos permite conservar datos en el ViewModel a pesar de que ocurran cambios en la interfaz, como rotaciones de pantalla o si la Activity pasa por cambios de estado, entre otros eventos.

La siguiente imagen muestra el flujo de una Activity y los métodos que se activan en respuesta a diversos eventos. A la derecha, se puede observar el amplio alcance del ViewModel.

Implementación básica

En este ejemplo voy a mostrar como implementar el ViewModel junto a Jetpack Compose de forma básica.

También haré uso de elementos como MutableLiveData y LiveData (son implementaciones para clases observables, es decir que nos subscribimos a la clase y si ocurre un cambio, reaccionamos haciendo lo que sea)

Dependencias

Link oficial

app/build.gradle.kts

dependencies {
    ...
    val lifecycle_version = "2.6.1"  
    implementation("androidx.lifecycle:lifecycle-viewmodel-compose:$lifecycle_version")
}

Clase ViewModel

class GreetingViewModel : ViewModel() {  
    /*  
     * Variable (_randomvm) que observamos y podemos modificar, se usa a nivel interno en     * los ViewModels     */  
    private val _randomvm: MutableLiveData<Int> = MutableLiveData<Int>(0)  
    val randomvm: LiveData<Int> = _randomvm  

    init {  
        _randomvm.value = Random.nextInt(0, 2023)  
    }  
}

En el ViewModel hemos creado dos variables, ambas son clases observables. La única diferencia es:

MutableLiveData nos permite modificar el valor que almacena.
LiveData no nos permite modificar el valor almacenado.

Siempre nos interesa que solo el ViewModel modifique los valores de las variables observables. Por este motivo utilizamos MutableLiveData de forma privada y LiveData de forma pública. Así solo se cambia el contenido dentro del ViewModel.

Al instanciarse la clase GreetingViewModel se ejecutará el método init. Éste método genera un número aleatorio y modifica el valor del MutableLiveData. randomvm al ser igual que MutableLiveData, también cambiará su valor, y allá donde se observe la variable, se reaccionará a los cambios.

Composable

@Composable  
fun Greeting(  
    name: String,  
    modifier: Modifier = Modifier,  
    viewModel: GreetingViewModel = viewModel()  
) {  
    val randomFromVM = viewModel.randomvm  
    val random: Int = Random.nextInt(0, 2023)  

    Log.d("Random", "From ViewModel: ${randomFromVM.value}")  
    Log.d("Random", "From local composable's scope: $random")  

    Text(  
        text = "Hello $name!",  
        modifier = modifier  
    )  
}

En el composable instanciamos el viewModel utilizando el metodo viewModel() (que se encuentra en las dependencias instaladas en el primer paso) como argumento de la función, y dentro del composable ya podemos utilizar los métodos y atributos públicos.

Las variables que tenemos son:

randomFromVM: es lo mismo que la variable randomvm del viewmodel
random: una variable en el ámbito local de la función.

Si ejecutamos el programa, vemos que cada vez que rotemos el dispositivo el valor de random será diferente, y el valor de randomFromVM será siempre el mismo, ya que este dato se almacena en el viewmodel y este tiene un mayor alcance.

Implementación con DI

Al utilizar inyección de dependencias con Hilt la implementación de un viewmodel es diferente, ya que deberemos proveer el ViewModel a hilt y después utilizar un método propio de hilt.

La única diferencia es que anotamos la clase con @HiltViewModel y en el @Composable lo inyectamos mediante el método hiltViewModel().

Clase ViewModel

@HiltViewModel  
class GreetingViewModel @Inject constructor() : ViewModel() {  
    private val _randomvm: MutableLiveData<Int> = MutableLiveData<Int>(0)  
    val randomvm: LiveData<Int> = _randomvm  

    init {  
        _randomvm.value = Random.nextInt(0, 2023)  
    }  
}

Composable

@Composable  
fun Greeting(  
    name: String,  
    modifier: Modifier = Modifier,  
    viewModel: GreetingViewModel = hiltViewModel()  
) {  
    val randomFromVM = viewModel.randomvm  
    val random: Int = Random.nextInt(0, 2023)  

    Log.d("Random", "From ViewModel: ${randomFromVM.value}")  
    Log.d("Random", "From local composable's scope: $random")  

    Text(  
        text = "Hello $name!",  
        modifier = modifier  
    )  
}

Para implementar el viewModel junto a Hilt es necesario agregar nuevas dependencias en gradle, yo en el ejemplo no lo he hecho, pero la documentación oficial es la siguiente: Androidx Releases

ViewModel Cheatsheet

Adjunto una imagen de un cheat sheet de la documentación oficial de Android, dejo el enlace al pdf web.

Referencias

Descripción general de ViewModel | Android Developers

ViewModel te permite administrar los datos de tu IU de forma optimizada para ciclos de vida.

developer.android.com

Mi Guía De Commits📝

disced — Wed, 02 Aug 2023 09:41:27 +0000

📯 Introducción
Estructura
Elementos
- Tipo
- Ámbito
- Breve título
- Cuerpo
- Pie
Prompt ChatGPT
- Prompt

Introducción

Guía básica de como redacto los mensajes de los commits para saber que hace el commit y tener una estructura definida para los mismos. También saber que cambios se han realizado en el código sin tener que verlo.

Está basada en Conventional Commits que ésta a su vez se basa en la guía de commits de Angular.

Estas dos anteriores guías o estándares yo no los sigo al pie de la letra, son una simple base la cual seguir pero si veo necesarios cambios para mi caso concreto, los implementaré, y tu deberías hacer lo mismo, adaptarlo para tu caso concreto y como mejor te funcione

Estructura

La estructura de los mensajes es la que vemos a continuación (los elementos que van dentro de corchetes [] son opcionales)

<TIPO>([ámbito opcional]): <BREVE_TÍTULO>
<SALTO_DE_LINEA>
[CUERPO]
<SALTO_DE_LINEA>
[PIE]

Elementos

Tipo

Indica de manera general que hace el commit y es obligatorio. En mi caso los tipos de commits que suelo utilizar son los siguientes:

feat: indica que el commit implementa una nueva feature.
fix : indica la resolución de un fallo/bug/issue.
docs: indica cambios o nueva documentación.
refactor: indica que se ha refactorizado código, sin cambios en la funcionalidad.
remove : indica que se ha eliminado algo del proyecto.
test : indica cambios o nuevas implementaciones de tests.

Ámbito

El ámbito va entre paréntesis después del tipo, y es opcional. Hace referencia a una determinada parte del código, por ejemplo: gui, database, hilt, di.

Breve título

Es una breve descripción de lo que hace el commit, es obligatorio y se deben usar verbos imperativos, es decir que se debe leer de la siguiente manera:

Commit	Como se lee
Modifica el boton de login	Este commit modifica el boton de login
Implementa inyeccion de dependencias	Este commit implementa la inyeccion de dependecias

Evitar escribir commits en primera persona: He cambiado la forma de hacer login, he cambiado los colores...

Cuerpo

Después del titulo insertar un salto de linea y añadir el cuerpo. Este elemento es opcional y se usa en el caso de querer dar mas información de lo que hace el commit.

Pie

El pie debe ir seguido de un salto de linea y se utiliza para dar información sobre quien ha realizado el commit, quien lo ha revisado, cual es la issue que arregla. Yo por el momento no utilizo esta parte

Prompt ChatGPT

Para redactar el commit de forma mas rápida yo utilizo ChatGPT donde le indico lo que quiero que haga (escribir el commit) y a continuación le proporciono la salida del comando git diff para que genere el mensaje.

En Ubuntu la salida de git diff la copio directamente al clipboard usando xclip y después la pego en el chat.

dragos@home git diff | xclip -sel clip

Y si es windows, lo podemos hacer en powershell de forma parecida:

PS C:\Users\dragos> git diff | clip

Prompt

En esta conversación te vas a comportar como desarrollador de software. Necesito que escribas los mensajes de los commits por mi. Te indicaré la forma en la que debes escribirlos.

Características:

Escribe los mensajes en inglés muy básico y de la manera mas corta posible.
El mensaje debe hablar de lo que hace este commit, arregla, modifica, implementa, etc.
Todo mensaje debe incluir la estructura que te proporcionaré a continuación.

La estructura que debes seguir es la siguiente:

<tipo>([ámbito opcional]): <breve descripción>
<SALTO DE LINEA>
[Cuerpo]
<SALTO DE LINEA>
[pie]

Los tipos son los siguientes:

fix
feat
remove
ui
test
refactor
docs

Ejemplos:

feat: allow provided config object to extend other configs

BREAKING CHANGE: `extends` key in config file is now used for extending other config files

feat(api): send an email to the customer when a product is shipped

fix: prevent racing of requests

Introduce a request id and a reference to latest request. Dismiss
incoming responses other than from latest request.

Remove timeouts which were used to mitigate the racing issue but are
obsolete now.

Reviewed-by: Z
Refs: #123

Yo te pasare la salida del comando git diff y tu deberas generar el commit teniendo en cuenta todo lo anterior. No hagas nada mas aparte de generar el mensaje del commit, no respondas a nada mas y no escribas nada mas. Deberas ceñirte en todo momento solo a generar el commit.
Ten en cuenta también lo siguiente:

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.

Commits MUST be prefixed with a type, which consists of a noun, feat, fix, etc., followed by the OPTIONAL scope, OPTIONAL !, and REQUIRED terminal colon and space.
The type feat MUST be used when a commit adds a new feature to your application or library.
The type fix MUST be used when a commit represents a bug fix for your application.
A scope MAY be provided after a type. A scope MUST consist of a noun describing a section of the codebase surrounded by parenthesis, e.g., fix(parser):
A description MUST immediately follow the colon and space after the type/scope prefix. The description is a short summary of the code changes, e.g., fix: array parsing issue when multiple spaces were contained in string.
A longer commit body MAY be provided after the short description, providing additional contextual information about the code changes. The body MUST begin one blank line after the description.
A commit body is free-form and MAY consist of any number of newline separated paragraphs.
One or more footers MAY be provided one blank line after the body. Each footer MUST consist of a word token, followed by either a :<space> or <space># separator, followed by a string value (this is inspired by the git trailer convention).
A footer’s token MUST use - in place of whitespace characters, e.g., Acked-by (this helps differentiate the footer section from a multi-paragraph body). An exception is made for BREAKING CHANGE, which MAY also be used as a token.
A footer’s value MAY contain spaces and newlines, and parsing MUST terminate when the next valid footer token/separator pair is observed.
Breaking changes MUST be indicated in the type/scope prefix of a commit, or as an entry in the footer.
If included as a footer, a breaking change MUST consist of the uppercase text BREAKING CHANGE, followed by a colon, space, and description, e.g., BREAKING CHANGE: environment variables now take precedence over config files.
If included in the type/scope prefix, breaking changes MUST be indicated by a ! immediately before the :. If ! is used, BREAKING CHANGE: MAY be omitted from the footer section, and the commit description SHALL be used to describe the breaking change.
Types other than feat and fix MAY be used in your commit messages, e.g., docs: update ref docs.
The units of information that make up Conventional Commits MUST NOT be treated as case sensitive by implementors, with the exception of BREAKING CHANGE which MUST be uppercase.
BREAKING-CHANGE MUST be synonymous with BREAKING CHANGE, when used as a token in a footer.

Conventional Commits

A specification for adding human and machine readable meaning to commit messages

conventionalcommits.org

Angular Commit Guide

TDD Sencillo

disced — Mon, 17 Jul 2023 11:00:58 +0000

Introducción
Qué es el TDD
Qué nos ofrece
Para qué utilizarlo
Cómo se pone en marcha
- Las Tres Leyes
  - Primera ley
  - Segunda ley
  - Tercera ley
Cómo funciona en la práctica
- Ciclo uno
- Ciclo dos
- Ciclo tres
- Ciclo cuatro
Referencias

Introducción

Este post lo he basado en el libro del Tio Bob (Robert C. Martin), La artesanía del código limpio. Es una lectura muy recomendable ya que amplía muchos conceptos y se desarrollan de forma más extensa de lo que yo pretendo con este post.

Si te apasiona tanto como a mi el desarrollo de software, te darás cuenta que siempre vas a querer ser mejor desarrollador/a, por lo tanto llegarás a la conclusión de que el TDD aumentará tu habilidad en este sentido y vas a querer ponerlo en práctica.

Qué Es El TDD

Es una forma más de escribir código, podemos decir que es una metodología a la hora de programar. El enfoque principal de este proceso son los (temidos) tests, pero no es para tanto, además, nos ofrece muchas ventajas.

Qué Nos Ofrece

Las ventajas que nos ofrece esta metodología de programar las podemos ver en la siguiente lista:

Tener un código fácil de leer y entender.
Tener un código poco interconectado entre sí.
Tener un código corto y muy segmentado.
Tener un código fácil de testear.
Asegurarnos que nuestro código funciona bien.
Tener un código escalable.
En ocasiones se llega al desarrollo de algoritmos complejos que sin realizar TDD es difícil llegar a la misma solución.

Para Qué Utilizarlo

Los programadores lo utilizamos para asegurar que nuestro trabajo está bien hecho y no falla.

En el peor de los casos se utiliza para evitar muertes (como bien ha ocurrido en el pasado por fallos de software, Boeing, Tesla...)

Cómo Se Pone En Marcha

Las Tres Leyes

Para entender y aplicar el TDD se describe mediante 3 leyes o principios básicos que siempre debemos seguir para llevarlo a la práctica.

En mi caso lo entendí al leer dichas leyes y ver ejemplos.

Primera Ley

No escribir nunca un código de producción hasta haber escrito una prueba que falle debido a la falta de dicho código.

Vamos a testear la clase persona por ejemplo, pero en nuestro desarrollo de momento no existe dicha clase, lo que haremos será escribir un test que instancie un objeto de la clase persona.

Segunda Ley

Escribir de un test lo mínimo posible para conseguir que falle o que no compile o ejecute. Resolver el fallo escribiendo código de producción.

En el ejemplo, escribimos una línea de código y el test fallará (no existe la clase persona). A continuación, como hemos escrito lo mínimo posible en el test, ahora escribimos código de producción para que pase la prueba, por lo tanto creamos una clase persona.

Tercera Ley

No escribir más código de producción que el que sea suficiente para pasar la prueba que falla en ese momento. Una vez ha pasado la prueba, escribimos más código de prueba *(volver a la primera ley)*

Para pasar la prueba solo se crea la clase persona y se ejecuta el test, debería de funcionar, entonces ahora hay que escribir otra prueba. Por ejemplo utilizar un método de la clase persona, setName por ejemplo. Esta nueva prueba fallará, esto es bueno y es lo que esperamos que ocurra. Ahora volvemos a la primera ley.

Tercera Ley*

Después de poner en práctica las tres leyes cumplimos el ciclo del TDD, pero antes de empezar un nuevo ciclo lo que debemos hacer si corresponde es refactorizar el código, hacerlo más corto, más sencillo o lo que corresponda en cada caso.

La refactorización del anterior código no debe modificar el comportamiento del código, solo debe modificar el código en sí, y debería de pasar todas las anteriores pruebas.

En este breve ejemplo podemos observar dos cosas:

Hemos testeado que nuestro código falla.
Hemos testeado que nuestro código funciona.

Estos dos conceptos son importantes porque por lo general, nosotros, los programadores, casi siempre testeamos código para que funcione, en este caso obligamos a que falle para después arreglar el fallo y así asegurarnos que no falla.

Cómo Funciona En La Práctica

Vamos a ver el ejemplo anterior de manera práctica y en varios ciclos.

Ciclo Uno

1. Creamos el test que falla

Test clase persona
En este caso uso Javascript y hay que tener en cuenta que si importas un modulo que no se exporte, el test no falla, por lo tanto vamos a escribir un poco mas de código de test para que falle.

person.test.js

import { Person } from "./person.js"

describe('Person Suite', () => {
    test('Create Person', () => {
        const p1 = new Person()
    })
})

Si ejecutamos el test mediante jest veremos que falla, estamos importando un módulo que no existe (esto no falla) y estamos intentando instanciar una clase que no existe, aquí es donde falla.

2. Añadimos código mínimo de producción para arreglar el fallo

Creamos clase persona
person.js

class Person {
}

export { Person }

Con este cambio, el test ya pasa y sabemos que nuestra última versión de código funciona.

3. Fin del ciclo (refactorizar código)

De momento no hay nada que refactorizar, así que volvemos a empezar el ciclo.

Ciclo Dos

1. Creamos el test que falla

Ahora quiero añadir un nombre al objeto persona, así que voy a escribir un test que me permita añadir el nombre utilizando un método de la clase (que aún no existe)

person.test.js

...

    test('Should set person name', () => {
        const p1 = new Person()
        p1.setName('Alice')
})

Al ejecutar la suite de tests, el primer test sigue pasando, pero el nuevo no pasa, no existe el método setName. Por lo tanto vamos a arreglar el código de producción para que pase este test.

2. Añadimos código de producción para arreglar el fallo

person.js

class Person {
    setName(name) {}
}
...

Con este sencillo cambio todos nuestros tests pasan y estamos seguros que nuestra última versión de código funciona correctamente.

3. Fin del ciclo (refactorizar código)

En este paso podríamos refactorizar guardando el nombre en un atributo de la clase por ejemplo, pero vamos a evitar saltar pasos y vamos a otro ciclo.

Ciclo Tres

1. Test qué falla

Obtener el nombre de la persona
person.test.js

...
    test('Should get the name of person', () => {
        const p1 = new Person()
        p1.setName('Alice')

        const name = p1.getName()
        expect(name).toEqual('Alice')
    })

2. Arreglar fallo

person.js


class Person {
    setName(name) {
    }

    getName() {
        return 'Alice'  
    }
}

Ahora el test pasa y sabemos que la última versión de nuestro código funciona correctamente.

Ciclo Cuatro

1. Test qué falla

person.test.js

...
    test('Should get the assigned name of person', () => {
        const name = 'Bob'
        const p1 = new Person()
        p1.setName(name)

                // Parte en la que falla
        const pName = p1.getName()
        expect(pName).toEqual(name)
    })

2. Arreglar el fallo

person.js

class Person {
    name = ''
    setName(name) {
        this.name = name
    }

    getName() {
        return this.name
    }
}

Y de esta manera podemos ir progresando en el desarrollo de la clase persona hasta complicarla lo máximo posible y sabiendo siempre que la última versión de nuestro código funciona.

También estaremos obligados de manera implícita a escribir código correcto, el tdd nos obliga a ello.

Referencias

La artesanía del código limpio - Anaya Multimedia

Anaya Multimedia , Cómo escribir código del que se sienta orgulloso... todos los días En \'La artesanía del código limpio\' el legendario Robert C

anayamultimedia.es

Inyección de Dependencias en Android (skel) 💉

disced — Thu, 01 Jun 2023 07:56:12 +0000

La principal idea de dicho post es tener un esqueleto básico de la Inyección de Dependencias en Android mediante Dagger Hilt.

Por lo tanto, obviaré explicaciones sobre dicho patrón y que problemas resuelve.

Adjunto un enlace de una publicación de freeCodeCamp en la que se explica: Dependency Injection: what it is

Dependencias Dagger Hilt
Clase Application
Proporcionar las dependencias
Inyección en constructor
Inyección en atributos
Módulos
- Proveer dependencias en módulos
Testing de la Inyección de Dependencias
- Dependencias Testing
- testInstrumentationRunner
- CustomRunner
- Clase de Test

Dependencias Dagger Hilt

Documentación Oficial

project/build.gradle

plugins {  
    ...
    id 'com.google.dagger.hilt.android' version '2.44' apply false  
}

project/app/build.gradle

...  
plugins {  
    id 'kotlin-kapt'  
    id 'com.google.dagger.hilt.android'  
}  

dependencies {  
    implementation "com.google.dagger:hilt-android:2.44"  
    kapt "com.google.dagger:hilt-compiler:2.44"  
}  

kapt {  
    correctErrorTypes true  
}

Clase Application

Documentación Oficial

Obligatoria

@HiltAndroidApp  
class BaseApp: Application() { }

Propiedad nombre (AndroidManifest.xml)

<?xml version="1.0" encoding="utf-8"?>  
<manifest ... >
    <application
        android:name=".BaseApp" />

</manifest>

Proporcionar las dependencias

Documentación Oficial

@HiltViewModel
class MyCustomViewModel: ViewModel() { ... }

@AndroidEntryPoint
class MyActivity: ComponentActivity() { ... }

Inyección en constructor

(mejor)

Documentación Oficial

@HiltViewModel
class MyCustomViewModel @Inject
constructor(private var myRepo: MyRepository) : ViewModel()

Inyección en atributos

(peor)

@HiltViewModel
class MyCustomViewModel: ViewModel() {

    @Inject
    lateinit var myRepo: MyRepository

}

Módulos

Documentación Oficial

@Module  
@InstallIn(SingletonComponent::class)  

class AppModule {  
    // Funciones para proveer clases
}

Opciones @InstallIn

Proveer dependencias en módulos

@Singleton  
@Provides  
fun providesDatabase
    (@ApplicationContext context: Context): UsersDb {  
        return Room
            .databaseBuilder(
                context, 
                UsersDb::class.java, "users_db")  
        .build()  
}

@Provides  
fun provideApplicationContext(@ApplicationContext context: Context): Context {  
    return context  
}

Testing de la Inyección de Dependencias

(androidTests/)

Importar dependencias
Cambiar el testInstrumentationRunner en app/build.gradle
Crear un CustomRunner de testing utilizando la clase HiltTestApplication
Anotar la clase de test con @HiltAndroidTest

Dependencias Testing

app/build.gradle

dependencies {

    testImplementation 'com.google.dagger:hilt-android-testing:2.44'  
    kaptTest 'com.google.dagger:hilt-android-compiler:2.44'  
    androidTestImplementation 'com.google.dagger:hilt-android-testing:2.44'  
    kaptAndroidTest 'com.google.dagger:hilt-android-compiler:2.44'
}

testInstrumentationRunner

app/build.gradle

android {

    testInstrumentationRunner "com.package.name.CustomRunner"
}

CustomRunner

class CustomRunner : AndroidJUnitRunner() {  
    override fun newApplication(  
        cl: ClassLoader?,  
        className: String?,  
        context: Context?  
    ): Application {  
        return super.newApplication(cl, HiltTestApplication::class.java.name, context)  
    }  
}

Clase de Test

@HiltAndroidTest
@RunWith(AndroidJUnit4::class)  
class DITests {  
    // Es la clase que inyecta dependencias en los tests
    @get:Rule  
    var hiltRule = HiltAndroidRule(this)  

    // Inyección (pero no se inyecta)
    @Inject  
    lateinit var context: Context  

    // Aqui es donde se inyecta
    @Before  
    fun setUp() {  
        hiltRule.inject()  
    }  

    @Test  
    fun testContextInjection() {  
        val cacheDir = context.cacheDir.name  
        assertEquals(cacheDir, "cache")  
    }  
}

Testing en Android

disced — Mon, 22 May 2023 14:27:21 +0000

Tipos de Tests
Directorios del proyecto
- Directorio tests
- Directorio androidTests
Ejemplos
- Test unitarios
- Test de integración
- Test de IU

Tipos de Tests

Los tres tipos de tests que se realizan en Android (en general en cualquier lenguaje/framework son iguales) son los siguientes:

Unit Tests: tests por unidad, es decir testear las clases o funciones de forma individual y verificar que cada una haga lo que se supone que debe hacer.
Integration Tests: tests que validan la integración entre diferentes módulos
UI Tests: tests de la interfaz del usuario, o end to end

Google recomienda dividir los tipos de tests de la siguiente forma:

Tipo Test	Porcentaje
Unit tests	70%
Integration Test	20%
UI Tests	10%

Directorios del proyecto

Existen dos formas de ejecutar los tests en Android:

En la maquina local, mediante la JVM.
En un dispositivo real (o emulado).

Dependiendo de donde se quieran ejecutar las pruebas (en local o real) existen dos directorios en el proyecto:

com/example/project/tests/: local
com/example/project/androidTests/: real

Directorio tests

En dicho directorio se guardaran todos los test relacionados con la ejecución en la maquina local.

Por lo general serán los tests unitarios los que se guarden en dicho directorio porque no acceden a recursos del dispositivo y tampoco tienen que interactuar con el dispositivo.

Directorio androidTests

En este directorio se guardaran todos los tests que se vayan a ejecutar en el dispositivo real o en un emulador.

Los tipos de tests que se guardarán en dicho directorios son tests de integración y e2e (end-to-end).

Ejemplos

En los ejemplos siguientes, no muestro como añadir las dependencias necesarias para los tests y tampoco menciono que dependencias son necesarias. Consultar la guía oficial en las referencias para ver la implementación completa.

Test unitarios

Estos tipos de tests a mi parecer son los mas sencillos de entender, ya que pruebas cosas de forma individual, funciones o métodos de clases.

Imagina que vamos a querer comprobar dos métodos de la clase MyFunctions:

El primer método se encarga de sumar dos números.
El segundo devuelve la fecha de hoy en formato dd-MM-yyyy

Son dos métodos muy básicos pero útiles para entender las pruebas unitarias

Clase a testear

class MyFunctions {
    fun add(a: Int, b: Int): Int {
        return a + b
    }

   fun getCustomDate(): String {
        val date = Date()
        val format = SimpleDateFormat("dd-MM-yyyy", Locale.getDefault())
        return format.format(date)
    }
}

Para testear dichas funciones vamos a crear el fichero com.example.project/tests/MyFuncionsTests.kt y dentro estará la lógica que comprobará que cada función hace lo que debe hacer.

Una buena práctica para realizar tests es provocar que la aplicación falle de cualquier manera. Es decir utilizarla de la forma en la que no se había pensado.

Por ejemplo, si un input está pensado para introducir números, vamos a introducir texto a ver que ocurre. Debemos pensar como un usuario y no como el desarrollador que ha implementado dicha funcionalidad.

Para realizar los tests utilizamos JUnit que nos provee de las anotaciones @Before, @After y @Test entre otras.

class MyFunctionsTest {
    private lateinit var myFunctions: MyFunctions

    // Se ejecuta antes de ejecutar cada test
    @Before
    fun setUp() {
        myFunctions = MyFunctions()
    }

    /*             Tests            */

    @Test
    fun `add function correct addition`() {
        val resultado = myFunctions.add(3, 2)
        assertEquals(5, resultado)
    }

    @Test
    fun `add function incorrect addition`() {
        val resultado = myFunctions.add(3, 2)
        assertNotEquals(6, resultado)
    }

    @Test
    fun `get custom date format dd-MM-yyyy`() {
        val fechaEsperada = SimpleDateFormat("dd-MM-yyyy").format(Date())
        val fechaObtenida = myFunctions.getCustomDate()
        assertEquals(fechaEsperada, fechaObtenida)
    }
}

Las anotaciones se utilizan para indicar que es cada método de la clase, ya que si no se indica mediante las anotaciones de JUnit, son simples métodos dentro de una clase.

Anotaciones comunes de JUnit:

Anotacion	Descripcion
`@Test`	Indica que el método es un Test
`@Before`	El método se ejecutará antes de cada test. Si hay 3 tests se ejecuta 3 veces
`@After`	Igual que `@Before` pero después de cada test
`@BeforeClass`	Se ejecutará dicho método una vez antes de ejecutar los tests
`@AfterClass`	Se ejecutará el método al finalizar la ejecución de todos los tests

Existen mas anotaciones pero las básicas son las de la tabla.

Un punto importante es que las anotaciones BeforeClass y AfterClass deben anotar a métodos estáticos y públicos; en java con poner el método como public static funciona, en kotlin el método debe estar dentro de un companion object (para que sea static) y utilizar la anotación @JvmStatic aparte de @BeforeClass o @AfterClass.

Se puede observar que los nombres de las funciones en los tests pueden ir nombradas entre comillas inversas y con espacios en blanco, para que quede mas entendible.

El primer test utiliza la función add con dos parámetros a sumar y verifica que el resultado de la suma es el esperado.
El segundo, verifica la misma función pero que el resultado a comprobar no coincida con el esperado.
El ultimo verifica que la fecha devuelta por la función getCustomDate es igual que nuestro resultado esperado.

Test de integración

Los tests de integración en la teoría parecen sencillos de entender, pero a mi, en la practica me han resultado mas complejos, ya que no me quedaba claro cuando se pasaba de pruebas unitarias a pruebas de integración.

Por ejemplo, si vamos a verificar que un ViewModel interactúa adecuadamente con una base de datos (como Room) o con una API, estaríamos realizando un test de integración.

Del mismo modo, si el ViewModel interactúa con un repositorio (patron repository), y este repositorio a su vez se comunica con un DataStore, este escenario también seria un test de integración.

Pongamos el caso de testear la integración entre ViewModel <--> API, en esta prueba, lo que se pretende verificar es el funcionamiento entre los dos componentes. Es decir que el test seguirá siendo de integración si accedemos a los datos reales de la API o utilizamos un Mock.

Si accedemos a los datos reales de la API estamos testeando la integración real.
Si utilizamos un Mock para la API, estamos testeando como el ViewModel maneja los datos recibidos desde la API.

Otro ejemplo podría ser probar la clase que interactúa con la API. Si dicha clase utiliza el patrón Repository lo que vamos a testear es el repositorio de la API, entonces seria un test de integración ya que se verifica nuestro código con un componente externo. En cambio, si vamos a querer testear la lógica interna del repositorio, podríamos mockear los datos y esto pasaría a ser un test unitario.

En este ejemplo tenemos lo siguiente:

Acceso a base de datos (Room).
- El objeto que configura la base de datos.
- El obtejo entity (referente a la tabla)
- El DAO (Data Access Objetc) las consultas sql
- La implementación al acceso a datos mediante el patrón Repository
  - Un interface (repository)
  - La implementación del interface
El ViewModel que utiliza el Repository para acceder a los datos.

Y lo que vamos a testear es la integración entre el ViewModel y la Base de Datos.

ViewModel

@HiltViewModel
class UserViewModel @Inject  
constructor(/*Inyeccion Dependencias*/var userRepo: UserRepository) : ViewModel() {  

    private val _user = MutableStateFlow<UserEntity?>(null)  
    val user: StateFlow<UserEntity?> = _user  

    fun getUser(id: Int) {  

        // Ejecutamos una corutina en el scope del ViewModel
        viewModelScope.launch {  

            // Utilizamos el método getUser del Repository
            userRepo.getUser(id).collect { user ->  
                _user.value = user  

            }  
        }  
    }  

    fun saveUser(newUser: UserEntity) {  
        viewModelScope.launch {  
            userRepo.saveUser(newUser)  
        }  

    }  
}

Acceso a datos

DB

La definición de la base de datos, especificando la tabla (entity) y las consultas (el DAO como abstract fun)

@Database(entities = [UserEntity::class], version = 1)  
abstract class UsersDb : RoomDatabase() {  

    abstract fun usersDao(): UserDao  

    companion object {  

        private var instance: UsersDb? = null  
        fun getInstance(ctx: Context): UsersDb {  
            if (instance == null) {  
                instance =  
                    Room.databaseBuilder(ctx.applicationContext, UsersDb::class.java, "users_db")  
                        .build()  
            }  

            return instance!!  
        }  
    }  
}

Entity (tabla)

La tabla con su schema

@Entity(tableName = "users")  
data class UserEntity(  
    @PrimaryKey val id: Int,  
    @ColumnInfo(name = "name") val name: String,  
    @ColumnInfo(name = "mail") val mail: String  
)

DAO

Las consultas a la base de datos

@Dao  
interface UserDao {  

    @Query("SELECT * FROM users WHERE id = :id")  
    fun getUser(id: Int): Flow<UserEntity>  

    @Insert(onConflict = OnConflictStrategy.REPLACE)  
    suspend fun saveUser(user: UserEntity)  
}

Implementación acceso a datos

Repository

interface UserRepository {

    // Declaración de los métodos
    fun getUser(id: Int): Flow<UserEntity>  
    suspend fun saveUser(user: UserEntity)  
}

Repository Implementation

class UserImpl(private val userDao: UserDao) : UserRepository {  

    // Definición de los métodos
    override fun getUser(id: Int): Flow<UserEntity> {  
        return userDao.getUser(id)  
    }  

    override suspend fun saveUser(user: UserEntity) {  
        return userDao.saveUser(user)  
    }  
}

Por no añadir más código y hacer la explicación las complicada he optado por omitir la Inyección de Dependencias. Saber que la realizo con Dagger Hilt y proveo las clases UsersDb, UserDao y UserImpl.

Tests

class UserViewModelTest {  
    private lateinit var database: UsersDb  
    private lateinit var user: UserEntity  
    private lateinit var userDao: UserDao  
    private lateinit var userRepository: UserRepository  

    private lateinit var viewModel: UserViewModel  

    @Before  
    fun setUp() {  
        // Contexto de la app en modo Test  
        val context = InstrumentationRegistry.getInstrumentation().context  

        // Creamos la BBDD ficticia en RAM  
        database = Room.inMemoryDatabaseBuilder(context, UsersDb::class.java).build()

        userDao = database.usersDao()  
        userRepository = UserImpl(userDao)  
        viewModel = UserViewModel(userRepository)  

        user = UserEntity(1, "Alice", "alice@mail.com")  
    }  

    @After 
    fun tearDown() {
        // Este metodo se ejcutará después de cada test
        database.close()  
    }  

    @Test  
    fun shouldViewModelSaveUserInDB() = runBlocking {  
        // Al ser un metodo 'suspend' debemos utilizar 'runBlocking' para ejecutar la corutina y  
        // bloquear el hilo.  

        // El ViewModel guarda el usuario        
        viewModel.saveUser(user)  

        // Obtenemos usuario con id: 1
        val savedUser = userRepository.getUser(1).first()  

        // Verificamos que el usuario es el mismo que el de la base de datos.  
        // Si es el mismo, el viewmodel ha funcionado correctamente a la hora        
        // de guardar el usuario en bbdd.        
        assertEquals(user, savedUser)  
    }  

    @Test  
    fun saveUser() {  
        runBlocking {
            // Probamos a guardar un usuario desde el ViewModel
            viewModel.saveUser(user)  

            // Obtenemos un usuario con id: 1
            val userFromDb = userDao.getUser(1).first()  

            // Verificamos que los usuarios son iguales
            assertEquals(userFromDb, user)  
        }  
    }  
}

Test de IU

En este ejemplo testearé un botón en Jetpack Compose, para realizarlo lo haremos como en el ejemplo.

Composable

@Composable  
fun Greeting(name: String) {  
    var showDialog by remember { mutableStateOf(false) }  
    Button(onClick = { showDialog = !showDialog }  
    ) {
        Text(text = "Click me!")  
    }  

    if (showDialog) {  
        Log.d("Saludo","showDialog")  
        onClickDialog()  
    }}  

@Composable  
fun onClickDialog() {  
    Dialog(onDismissRequest = { /*TODO*/ }) {  
        Text(text = "Dialogo")  
    }

Test

class GreetingComposableTesting {  

    private val name = "TEST"  

    // Creamos una regla de JUnit para un Composable
    @get:Rule
    val rule = createComposeRule()  

    @Before
    fun setContent() {  
        // A la regla le añadimos el composable a testear
        rule.setContent { Greeting(name) }  
    }  

    @Test  
    fun buttonExists() {  
    // Comprobamos que el nodo con el texto "Click me!" existe.  
        rule  
            .onNodeWithText("Click me!")  
            .assertExists("No existe")  
    }  

    @Test
    fun clickButton() {  
        rule  
            .onNodeWithText("Click me!")  
            // Verificamos que el nodo es clickable
            .assertHasClickAction()  
            // Hacemos click en el botón
            .performClick()  
    }  

}

Adjunto cheatsheet de testing en Jetpack Compose:

Referencias

Cómo probar apps en Android | Desarrolladores de Android | Android Developers

developer.android.com

Aspectos básicos de las pruebas | Desarrolladores de Android | Android Developers

developer.android.com

Cómo probar tu diseño de Compose | Jetpack Compose | Android Developers

developer.android.com

Servicios en Android🛸

disced — Wed, 19 Apr 2023 11:30:09 +0000

Definición
Diferencias
Para que se usan
- Background
- Foreground
Implementación
- Background Services
- Foreground Services
Tareas Programadas
Referencias

Definición

Un servicio en Android se asemeja a un demonio en sistemas GNU/Linux, es decir que es un programa en ejecución en segundo plano sin necesidad de interactuar con el usuario. Por lo tanto un servicio no tiene interfaz gráfica.

El termino 'segundo plano' en el contexto de servicios en android puede crear confusión ya que existen los servicios en segundo plano (background) y los servicios en primer plano (foreground).

La creación y ejecución de un servicio en Android no es como en un sistema GNU/Linux (que creas un fichero con la configuración para systemd y utilizando systemctl lo pones en ejecución) en este caso el servicio siempre lo deberá ejecutar la aplicación principal.

En Android existen dos tipos de servicios, los Background Services y los Foreground Services. Los dos son muy parecidos pero tiene diferencias notables.

Diferencias

Background Services	Foreground Services
No es necesario notificar al usuario de su ejecución	Es obligatorio mostrar una notificación al usuario (parte superior)
Tienen baja prioridad para el SO	Alta prioridad para el SO
El SO lo puede parar	El SO no lo suele parar
Consume menos recursos	Consume más recursos
Tiempo de vida corto	Tiempo de vida largo
No afectan la experiencia del usuario	Afectan la experiencia del usuario

Para que se usan

Un servicio se puede utilizar para cosas que no tenga que intervenir el usuario y que sea transparente para el. También se puede utilizar para ejecutar funcionalidades en segundo plano con una interacción con el usuario.

Background

Son útiles para tareas que no requieren interacción con el usuario y pueden ejecutarse sin su intervención.

Como casos de uso pueden ser la sincronización de datos, copias de seguridad automáticas y actualización de bases de datos.

Evitar realizar tareas de larga duración ya que el sistema lo puede parar cuando lo vea necesario

Foreground

Al tener que mostrar una notificación permanente cuando se encuentra en ejecución un servicio como este, algunos ejemplos de uso pueden ser: la reproducción de música, al usuario se le informa mediante una notificación de que se reproduce música, permitiendo interactuar con el reproductor parando, pausando, avanzando, retrocediendo.

También se puede utilizar para descargas de ficheros de gran tamaño, donde se muestra al usuario el progreso de la descarga y también se permite la pausa o la cancelación de la misma. (Por ejemplo cuando una aplicación se actualiza, se muestra una notificación de este estilo).

Otro uso que se le puede dar es el seguimiento del usuario mediante GPS e informándole que se están capturando los datos.

En una ocasión he utilizado este tipo de servicio para grabar Audio y Video en segundo plano.

El Audio lo grababa mediante MediaRecorder y video mediante CameraX, la implementación que realicé fue un Foreground Service ya que MediaRecorder a partir del API 28 no permite el acceso al micrófono desde un Background Service.

Cuando ocurría determinado evento, otro servicio ejecutaba este servicio (el de grabación) y comenzaba a grabar. Era obligatorio mostrar una notificación al usuario de que estaba siendo grabado.

Implementación

Background Services

Ejemplo de como crear un Background Service que se ejecuta desde un Composable

Servicio

Heredar de Service y sobrescribir los métodos onBind, onStartCommand y onDestroy.

En el método onStartCommand si queremos que el servicio se ejecute si se cierra la aplicación retornar la constante START_STICKY.

class MyBackgroundService : Service() {

    override fun onBind(intent: Intent): IBinder? {
        return null
    }

    override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {
        // Tarea que va a realizar el servicio
        return START_STICKY
    }

    override fun onDestroy() {
        super.onDestroy()
    }
}

El Composable

El composable es un botón que recibe dos funciones por parámetro, para iniciar el servicio y para parar el servicio.

Estas funciones en este caso están creadas en la clase main, lo ideal es tenerlas creadas en un ViewModel

@Composable
fun StartStopServiceButton(
    onStartService: () -> Unit, 
    onStopService: () -> Unit
) {
    var isServiceRunning by remember { mutableStateOf(false) }

    Button(onClick = {
        isServiceRunning = !isServiceRunning
        if (isServiceRunning) {
            onStartService()
        } else {
            onStopService()
        }
    }) {
        Text(if (isServiceRunning) "Detener Servicio" else "Iniciar Servicio")
    }
}

Fichero `manifest`

Hay que declarar el servicio en el manifest del proyecto.

Exported es para permitir o no que otra aplicación pueda ejecutar el servicio.

<manifest ...>
    <application ...>
        ...
        <service
            android:name=".MyBackgroundService"
            android:exported="false" />
    </application>
</manifest>

Main Activity

La clase main consta de dos funciones , una para ejecutar el servicio y otra para parar el servicio.

También muestra el botón y pasa las funciones por parámetro al composable.

class MainActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContent {
            MaterialTheme {
                Surface {
                    // Boton
                    StartStopServiceButton(
                        onStartService = {
                            startMyBackgroundService() 
                        },
                        onStopService = {
                            stopMyBackgroundService() 
                        }
                    )
                }
            }
        }
    }

    private fun startMyBackgroundService() {
        val intent = Intent(
            this, 
            MyBackgroundService::class.java
        )
        startService(intent)
    }

    private fun stopMyBackgroundService() {
        val intent = Intent(
            this, 
            MyBackgroundService::class.java
        )
        stopService(intent)
    }
}

Foreground Services

Servicio

La declaracion de un foreground service es muy similar al background service, lo unico que cambia es lo siguiente:

Crear la notificación para mostrar al usuario
En el método onStartCommand hay que ejecutar el método startForeground con la notificación creada.

Para versiones iguales o superiores a Android 8 (API 26) hay que crear el canal para la notificación como en el método createNotificationChannel().

La notificación se crea mediante NotificationCompat.Builder en el método createNotification(), dicho método retorna una Notification que la recibirá el método startForeground()

class MyForegroundService : Service() {

    companion object {
        const val CHANNEL_ID = "my_channel_id"
        const val NOTIFICATION_ID = 1
    }

    override fun onCreate() {
        super.onCreate()
        createNotificationChannel()
    }

    override fun onStartCommand(
            intent: Intent?, 
            flags: Int, 
            startId: Int): Int {

        val notification = createNotification()

        startForeground(NOTIFICATION_ID, notification)
        return START_NOT_STICKY
    }

    override fun onBind(intent: Intent?): IBinder? {
        return null
    }

    // Crea el canal para la notificación
    private fun createNotificationChannel() {
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
            val channel = NotificationChannel(
                CHANNEL_ID,
                "My Foreground Service Channel",
                NotificationManager.IMPORTANCE_DEFAULT
            )
            val notificationManager =
             getSystemService(NotificationManager::class.java)

            notificationManager
                .createNotificationChannel(channel)
        }
    }

    // Crea la notifcación
    private fun createNotification(): Notification {
        return NotificationCompat.Builder(this, CHANNEL_ID)
            .setContentTitle("Foreground Service")
            .setContentText("Servicio en primer plano...")
            .setSmallIcon(R.drawable.ic_notification_icon)
            .build()
    }
}

Composable

El composable recibe por parámetro una función que al hacer click en el botón se ejecuta dicha función.

@Composable
fun MyButton(onStartService: () -> Unit) {
    Button(onClick = { onStartService() }) {
        Text("Iniciar Foreground Service")
    }
}

Fichero `manifest`

Para versiones iguales o superiores a la API 28 hay que añadir el permiso FOREGROUND_SERVICE.

Cada servicio se declara dentro de application mediante la etiqueta service.

<manifest ... >

    <uses-permission
        android:name="android.permission.FOREGROUND_SERVICE"/>

    <application ...>
        <service
            android:name=".MyForegroundService"
            android:enabled="true"
            android:exported="false" />

        ...

    </application>
</manifest>

Main Activity

La clase main se encarga de mostrar el botón y vincular el método privado que inicia el servicio, muy parecido en el anterior ejemplo.

class MainActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContent {
            MyButton(
                onStartService = { startMyForegroundService() }
            )
        }
    }

    private fun startMyForegroundService() {
        val intent = Intent(
                this, MyForegroundService::class.java
            )
        startService(intent)
    }
}

Tareas Programadas

Si necesitas gestionar notificaciones, como un aviso programado en una fecha específica, lo ideal es utilizar un WorkManager en lugar de los servicios. Dicha funcionalidad solo está disponible para Android Jetpack.

Referencias

Descripción general de los servicios | Desarrolladores de Android | Android Developers

developer.android.com

Service | Android Developers

developer.android.com

Foreground services | Android Developers

developer.android.com

Context en Android

disced — Thu, 13 Apr 2023 17:59:04 +0000

Indice

Definición
Como obtener el context
Uso
- Iniciar Activity
- Inicir Servicios
Utilizarlo en Composables
Utilizarlo en ViewModels
Referencias

Definición

Es una clase abstracta que la implementa Android, y cuya función es proporcionar acceso al entorno de la aplicación.

Así se define en la documentación oficial pero en mi caso no entiendo a que se refiere.

Si tenemos acceso al entorno de la aplicación, vamos a tener acceso a las siguientes funciones:

Acceder a una base de datos
Al sistema de notificaciones
Al sistema de ficheros
Lanzar actividades, servicios
Trabajar con permisos
Mostrar cuadros de diálogo

Como obtener el Context

La obtención del Context se puede realizar desde varios puntos en una app:

Desde cualquier Activity
Desde un Service
Desde cualquier View (si utilizas el modelo xml)
Desde cualquier Composable
O cualquier clase que extienda de Context

Existen dos métodos para acceder al contexto. Cada uno de ellos devuelve un contexto diferente y las principales diferencias son las siguientes:

`getContext()` (en views xml)	`getApplicationContext()`
Contexto ligado a la Activity	Contexto ligado a toda la Aplicación
Depende del ciclo de vida de la Activity	Depende del ciclo de vida de la Aplicacion
Si muere la activty el context tambien	Todas las actividades tienen acceso al mismo contexto (aparte del suyo propio)
Cada activty tiene el suyo propio

Usos

A continuación detallaré como se utiliza el context para varias tareas.

Iniciar Activity

Si vamos a iniciar una actividad diferente a la que se está ejecutando, deberemos hacer uso del Context.

En el ejemplo accederemos al context desde un Composable, en dicho composable tendremos acceso al contexto de la activity (es decir que dependerá del lifecycle de la activity) utilizando LocalContext.current.

Por ejemplo vamos a querer ejecutar en determinado momento la actvity SecondActivity

class SecondActivity : ComponentActivity() {  
    override fun onCreate(savedInstanceState: Bundle?) {  
        super.onCreate(savedInstanceState)  

        setContent {  
            Text("Esta es la segunda actividad")  
        }  
    }  
}

La actividad principal, MainActivity contiene un único Composable

class MainActivity : ComponentActivity() {  
    override fun onCreate(savedInstanceState: Bundle?) {  
        super.onCreate(savedInstanceState)  

        setContent {  
            MyComposable()  
        }  
    }  
}

La implementación del Composable que se utiliza en la actividad principal:

@Composable  
fun MyComposable() {  
    val context = LocalContext.current  

    Button(onClick = {  val intent = 
        Intent(context, SecondActivity::class.java)  
        context.startActivity(intent) }
    ) {  
        Text("Iniciar Activity")  
    }  
}

En este ejemplo nuestro composable tiene un botón cuya única función es obtener el contexto y ejecutar la SecondActivity.

Al ejecutarse accedemos al contexto vinculado a la activity para poder iniciar una segunda actividad en caso de que el usuario pulse el botón.

Si se ha iniciado la segunda actividad y, por cualquier motivo, el SO decide detener la primera actividad, el contexto utilizado en MyComposable dejará de ser válido. Por este motivo, es importante evitar enviar el mismo contexto a la segunda actividad (mediante un Bundle), para prevenir posibles problemas relacionados con la gestión incorrecta del ciclo de vida del contexto y posibles fugas de memoria.

En Jetpack Compose se suele utilizar una única actividad para la aplicación.

Iniciar Servicios

Si queremos ejecutar un servicio en segundo plano (background) o en primer plano (foreground) también usaremos el Context.

Tenemos el siguiente servicio:

class MyBackgroundService : Service() {  
    override fun onBind(intent: Intent?): IBinder? {  
        return null  
    }  

    override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {  
        // { ... la logica del servicio }  
        return START_STICKY  
    }  
}

Su ejecución dentro de una actividad sería de la siguiente forma

class MainActivity : ComponentActivity() {  
    override fun onCreate(savedInstanceState: Bundle?) {  
        super.onCreate(savedInstanceState)  

        // Iniciar el servicio  
        val intent = Intent(this, MyBackgroundService::class.java)  

        startService(intent)  
    }  
}

En este caso el contexto lo utilizamos para instanciar un Intent (que este a su vez ejecutará el servicio). El primer parámetro del Intent es el contexto, como ComponentActivity extiende de la clase Context, se puede referenciar la misma clase (MainActivity) mediante this.

Utilizarlo en Composables

En el apartado Iniciar Activity se muestra como utilizar el contexto dentro de un composable, la implementación es de la siguiente forma:

@Composable  
fun MyComposable() {  
    val context = LocalContext.current  
    ...
}

Esta es la forma en la que accedemos al contexto dentro de un composable, dicha forma nos devolverá el contexto ligado a la activity a la que pertenece dicho composable.

Utilizarlo en ViewModels

Al utilizar el patrón de diseño MVVM no deberíamos utilizar el Context dentro del ViewModel ya que podría haber fugas de memoria y otra razón es mantener la separación de responsabilidades. También nos ayuda a mantener el código y testearlo mucho mas fácil.

El ViewModel solo debe encargarse de almacenar datos relacionados con la vista (el composable) y manejar los datos de la vista pero sin implementar el manejo de dichos datos.

Es decir que él no debe manejar el acceso a una API o una BBDD o a cualquier recurso del sistema Android.

El ViewModel solo implementará la lógica ligada a la IU y la implementación la hará un Repository y el ViewModel hará uso del Repository.

Si se necesita utilizar el context dentro del ViewModel se hará de la misma forma, con un Repository que implemente las acciones necesarias y en el ViewModel se utilizará el Repository (inyectándolo por ejemplo).

PRACTICA POCO RECOMENDADA!

Si realmente quieres utilizarlo dentro del ViewModel puedes utilizar inyección de dependencias con Hilt por ejemplo e inyectar el Context en el ViewModel

Referencias

Context | API reference | Android Developers

developer.android.com

Context In Android Application

In this blog, we will learn about the context in Android application.

outcomeschool.com

What is Context in Android and which one should you use? | by Ban Markovic | Medium

Ban Markovic ・ Jan 19, 2020 ・
Medium

Scaffold en Jetpack Compose

disced — Tue, 04 Apr 2023 10:08:29 +0000

Indice

Definición
Elementos de scaffold
Uso básico
- Función que define el Scaffold
- Barra superior
- Barra inferior
- Botón flotante
- Contenido principal
Resultado
Referencias

Definición

Es un componente de diseño en Android mediante Jetpack Compose (un kit de desarrollo de IU basado en kotlin, una de sus principales funciones es accelerar el desarrollo, usar menos código, que sea mas sencillo, etc).

El uso fundamental de este composable es tener una estructura estándar para los elementos visuales de la app, no es un elemento visual, más bien es un layout. Nos ayuda de manera muy rápida a posicionar elementos comunes en la pantalla sin programarlo de cero. También sigue el patrón de diseño Material Design.

Elementos de scaffold

Los elementos que se pueden utilizar en un scaffold son los siguientes:

Top app bar: es la barra de la parte superior
Content: el contenido principal de la aplicación
FAB (Floating Action Button): botón flotante
Bottom Bar: es la barra de la parte inferior, o barra de navegación
Drawer: es el menú lateral que se expande/contrae

Todos ellos son opcionales y personalizables, para hacer utilizar cada elemento, debemos generar un Composable para dicho elemento, como veremos en el uso básico.

Uso básico

Función que define el Scaffold

// Función Composable que crea un Scaffold personalizado
@Composable
fun CustomScaffold() {
    Scaffold(
        // Barra superior
        topBar = { CustomTopBar() },

        // Barra inferior
        bottomBar = { CustomBottomBar() },

        // Botón flotante personalizado
        floatingActionButton = { CustomFAB() }, 

        // Contenido principal
        content = { padding ->
            CustomContent(padding)
        }
    )
}

La función Scaffold tiene bastantes parámetros, yo en este caso he utilizado los siguientes:

topBar: hace referencia a la barra superior, acepta un Composable de tipo TopAppBar
bottomBar: hace referencia a la barra inferior, por lo general su uso está destinado a la navegación dentro de la aplicación, acepta un Composable BottomAppBar
floatingActionButton: es el botón flotante que se encuentra por encima de todos los demás elementos, se permite fusionar con la barra inferior, acepta un FloatingActionButton
content: hace referencia al contenido principal de la aplicación, se puede poner cualquier Composable pero se suelen poner filas, columnas, surface, box, etc. En el ejemplo he utilizado Column

Estos cuatro parámetros aceptan funciones de tipo @Composable las que muestro a continuación

Barra superior

@Composable
fun CustomTopBar() {
    TopAppBar(
        // Título de la barra superior
        title = { Text(text = "Hello World!") }, 
    )
}

Barra inferior

@Composable
fun CustomBottomBar() {
    BottomAppBar(content = {
        // Contenido de la barra inferior
        Text(text = "Item One")
    })
}

Botón flotante

@Composable
fun CustomFAB() {
    FloatingActionButton(
        // Color de fondo
        backgroundColor = MaterialTheme.colors.primary,
        // Acción al hacer clic en el botón (sin definir)
        onClick = { /*TODO*/ }) { 
        Text(
            fontSize = 24.sp, // Tamaño de fuente del texto del botón
            text = "+" // Texto del botón
        )
    }
}

Contenido principal

@Composable
fun CustomContent(padding: PaddingValues) {
    Column(
        // Modificadores de estilo de la columna
        modifier = Modifier
            // Ocupar todo el espacio disponible
            .fillMaxSize() 
            .padding(padding),

        // Contenido de la aplicación
        content = {
            Text(text = "My app content") 
        }
    )
}