Hola a todos hace ya tiempo no escribo artículos para Medium por buena causa. He tenido que aprender sobre el desarrollo multiplataforma con Flutter por motivos laborales (demanda creciente de flutter devs en Cuba). Cualquier tecnología que escojamos para la creación de apps frontend casi seguro que vamos a tener que consumir alguna API y Flutter no es la excepción. Hoy no vamos a ver como consumir un API, sino como bien anuncia el titulo, vamos a tratar sobre el error handling.

Uno de los principios que más me ha costado adaptar a Flutter desde nativo, es este, y es que la comunidad de devs de Flutter por limitaciones del propio lenguaje ha tomado varios caminos al momento de crear un manejo adecuado de errores. En mi búsqueda de la solución mas parecida a lo que hago en nativo con Kotlin me topé con todo. Desde el simple try-catch hasta soluciones mas complejas como el uso de programación funcional (generalmente con el uso de fpdart package ). Gracias a Dart 3.0 y la inclusión de las sealed class obtuve la solución adecuada para mí,
un manejo de errores al estilo de Kotlin.

Manos a la obra.

Lo primero es crearnos una sealed class que represente una respuesta del API, tendríamos los 3 estados que tenemos en una petición a un API (Loading, Success y Failure).

sealed class Result<S, E extends Exception> {
  const Result();
}
final class Loading<S, E extends Exception> extends Result<S, E>{}

final class Success<S, E extends Exception> extends Result<S, E> {
  const Success(this.value);
  final S value;
}

final class Failure<S, E extends Exception> extends Result<S, E> {
  const Failure(this.exception);
  final E exception;
}

Esta clase hace uso de genéricos, S representa el tipo de retorno satisfactorio y E representa el tipo de retorno de Failure ,que hereda de la clase Exception y así limitamos que solo puedan ser usadas exceptions.

Podemos explotar más nuestro dominio y crear clases que representen los
errores más comunes que puede lanzar un API. Tendríamos algo como esto.

class AppException implements Exception{
  final String message;
  final int statusCode;

  AppException(this.message, this.statusCode);

  static AppException fromStatusCode(int statusCode){
    switch(statusCode){
      case 400: return BadRequest();
      case 401: return UnAuthenticated();
      case 404: return NotFound();
      default: return UnKnown();
    }
  }
}

class UnAuthenticated extends AppException{
  UnAuthenticated({String message = 'no authenticated'}): super(message, 401);
}

class BadRequest extends AppException{
  BadRequest({String message = 'bad request'}): super(message, 400);
}

class NotFound extends AppException{
  NotFound({String message = 'not found'}): super(message, 404);
}

class UnKnown extends AppException{
  UnKnown({String message = 'unknown error'}): super(message, 0 );
}

class NoConnection extends AppException {
  NoConnection({String message = 'no internet connection'}): super(message,-1);
}

Como el código suele ser más claro que las palabras muchas veces, seré breve. Tenemos exceptions personalizadas que representan errores comunes como (unAuthenticated, Bad Response, Not Found, No Connection…) y un método que nos va a retornar una Exception según su status code(que reconozco podría convertirse en algo molesto de escalar, pero para este ejemplo esta bien).

Ahora podemos codificar un datasource como el siguiente. Este nos retorna nuestra selead class Result. Por tanto si la petición falla tendremos un Failure() como respuesta y si es satisfactoria tendremos un Success()

class MovieDbDatasource extends RemoteMovieDatasource {
  MovieDbDatasource(this._api);

  final RestClient _api;

  @override
  Future<Result<Movie,AppException>> getMovieById(int movieId) async{
    try {
      final movieDb = await _api.getResponse(movieId);
      final movie = MovieMapper.toDomain(movieDb);
      return Success(movie);
    } catch (e) {
      final dioException = (e as DioException);
      return dioException.handlingError<Movie>();
    }
  }

  @override
  Future<Result<List<Movie>,AppException>> getPopularMovies({int page = 1})async {
    try {
      final response = await _api.getPopularMovies(page: page);
      final listOfMovie = response.results?.map((movieDb) => MovieMapper.toDomain(movieDb)).toList() ?? [];
      return Success(listOfMovie);
    } on Exception catch (e) {
      final dioException = (e as DioException);
      return dioException.handlingError<List<Movie>>();
    }
  }
}

El método handlingError es una extensión de DioException que luce así.

extension DioExceptionExtension on DioException{
  Failure<S,AppException> handlingError<S>(){

    if (error.runtimeType == SocketException) {
      return Failure(NoConnection());
    }
    final appException = AppException.fromStatusCode(response?.statusCode?? 0);
    return Failure(appException);
  }
}

En fin nos retorna el Failure correspondiente a nuestro status code. Cero (0) es el valor por defecto si no tenemos status code, este corresponde a nuestra UnKown() exception.

Ahora viene la magia y por lo que nos es útil el uso de las sealed class. El siguiente es un método dentro del viewModel, controller o bloc como lo quieras llamar, de acuerdo a tu Arch o gestor de estados favorito.

Future<void> loadMovie()async {
    final result = await _getMovieById(movieId);
    switch(result){
      case Loading(): emit(state.copyWith(isLoading: true));
      case Success(): emit(state.copyWith(isLoading: false, movie: result.value , error: null));
      case Failure(): emit(state.copyWith(error: result.exception, isLoading: false));
    }
  }

Ya que result es una sealed class tenemos un switch con ramas exhaustivas. Quizá podías haber ideado una solución donde switch retorne un valor de estado y luego sea emitido, es válido también. En tu vista es solo consumir este estado, que en caso de ser un Failure ya tenemos un status code y un message acorde al tipo de error y así poder dar un feedback adecuado al usuario.

Conclusión

Podemos crear un manejo de errores al puro estilo de Kotlin, que tanto me gusta, gracias a las sealed class de Dart y poder asi dar un feedback adecuado, según el error lanzado por la request a nuestra API. Destacar que no siempre es útil el uso de este tipo de solución y con un simple try-catch tenemos, ya que en casos de uso más complejos podemos llegar a crear un código muy ilegible. Gracias espero le halla ayudado este post.

Hola otra vez , soy yo Jander, tu programador favorito :)

Estructurar los datos es una de las tareas fundamentales y básicas a la hora de programar. Pasa que siempre vamos a tratar con datos en los problemas cotidianos de la programación, más vale tenerlos organizados. Lo primero que nos topamos cuando empezamos a conocer estructuras de datos son los arreglos o vectores. Un vector no es más que un conjunto de datos del mismo tipo al cual podemos acceder a través de un índice que representa su posición (Podemos crear arreglos de tipos de datos diferentes pero estos son menos usados ). Cuando tenemos una agrupación dígase un conjunto de nombres de estudiantes:

nombres = [“Samuel”,”Juan”,Pedro”,”Miguel”,”Alejandro”]

relacionados por un único aspecto en este caso nombres de estudiantes (Es un aula pequeña :)) nos encontramos ante un vector de una única dimensión unidimensional. Estos son sencillos porque para acceder a ellos ya sea para leer, escribir o actualizar es tan sencillo como conocer su
índice por ejemplo “Samuel” corresponde al índice 0 (la mayoría de lenguajes inician los índices desde 0). samuel = nombres[0]. Hasta aquí todo bien hasta que todo se empieza a enredar con el multiverso. Si, leíste bien, tenemos multiverso en la programación.

Los arreglos multidimensionales suelen ser un dolor de cabeza para los que inician en la programación, al menos para mí lo fue. Cuando comencé a estudiarlos me los aprendí de una manera rígida y poco aplicable a la práctica. Hoy te voy a enseñar una manera en la que más nunca se olvidarán y comenzarás a aplicarlos a la práctica y resolver problemas con ellos. Vamos a ver los casos más comunes

¿Que son los arreglos bidimensionales?

Son sencillamente una tabla de filas y columnas. Supongamos que ahora queremos relacionar este listado de estudiantes que tenemos con las notas que han adquirido en las materias Matemáticas, Español, Historia

materias = [Matemáticas, Español, Historia]

Cada estudiante tendría ahora asignado un array de 3 índices que representan las notas en cada asignatura. Tendríamos una tabla donde cada columna representa un estudiante y cada
fila una asignatura o materia cada celda entonces representaría la nota de un estudiante en determinada asignatura.

Dentro de cada estudiante hay un arreglo de notas, entonces, si queremos conocer la nota de Pedro en Español solo es saber que Pedro es nombres[3] y Español es materias[1]
si esta tabla o matriz le diéramos el nombre de alumnosRelacion, sería tan sencillo como indicarle fila y columna (alumnosRelacion[3][1]). Pero qué pasa si queremos crear otra dimensión a esta tabla y añadir el parámetro de curso. Supongamos que esta es una escuela secundaria y queremos registrar cada año de secundaria 1º, 2º y 3º cada asignatura tiene tres años diferentes en las que se imparte. Sencillamente es agregar otro arreglo dentro de cada materia. Tendríamos una tabla como esta:

La estructura que tenemos es algo común en programación que son los listados anidados, al final esto son los arreglos: un listado. Array<Array<Array<Type>>>>. Para acceder al valor de la nota de un estudiante es determinada asignatura en determinado año sería: matrizMultidimensional[3][1][2] , en nuestro ejemplo es Miguel en Español en el 3º año de secundaria que son 4 puntos.

Imagínate la magia que podemos hacer con esto en programación :-)

Pero como entiendo todo esto? La forma que te enseñaré es algo propio, una conclusión a la que llegue yo mismo, no la he visto en otro sitio pero puede que ya se haya explicado de esta forma. También puede que no sea la forma más correcta de explicar pero así fue que la entendí.

1- Primero necesitamos un tipo de dato único que gestionar, al final todo este embrollo se trata de lograr un manejo de datos no? Puede ser primario dígase carácter, entero, double, buleano o un objeto de una clase creada por nosotros mismos, en nuestro ejemplo el dato es un entero , la nota.

2- La cantidad de dimensiones depende de los parámetros que queremos relacionar, podemos pensar en decenas de ellos para aplicarlos al dato, en nuestro caso: la nota:

• el estudiante que la obtuvo
• la asignatura
• el profesor que la imparte
• el curso
• la escuela
• el tipo de escala (5/5 10/10 100/100)
• la clave que se usó para otorgarla
• etc...

Pero para poder crear las dimensiones de una manera correcta estos parámetros deben tener una relación jerárquica entre sí de uno es a muchos, un tema que extraje a medias de las bases de datos relacionales. Te explico mejor:

Una jerarquía son niveles donde cada elemento está más arriba/afuera o más abajo/adentro que otro. La relación uno es a muchos es cuando el 1º elemento tiene muchos o varios de los 2º elementos. Ejemplo un estudiante cursa muchas asignaturas, cada asignatura tiene muchos años en
los que se imparte. Si quieres seguir continuar con la jerarquía pero usualmente no hay tantos niveles. Tenemos la jerarquía creada y el tipo de dato que queremos manejar, es solo unir las piezas: Un array que representa los estudiantes contiene un array q representa las asignaturas que a su vez contiene un array que representa los años, cada celda formada por estas dimensiones contiene nuestro tipo de dato
Array<Array<Array<Int>>>>.

Tanto para asignar valores a todas estas casillas q se han creado como para recuperarlos podemos hacerlo manualmente, XD eso sería infernal, en nuestro caso 5 x 3 x 3 veces = 45 líneas de código repetitivas. O podemos usar bucles anidados, uno por cada dimensión. Si ya sé, eso es muy costoso a nivel se recursos pero no hay de otra. Por eso debemos
usar estas estructuras solo cuando se necesiten realmente

¿Como se ve esto en código ?

// Creando el array multidimensional y estableciendo el valor
// de cada celda a 0
val multidimensionalArray : Array<Array<Array<Int>>> =
 Array(5){ Array(5){Array(3){0} } }

// leer un valor de manera individual 
val value = multidimensionalArray[1][2][3]

// iterando por cada celda 

for (i in 0..4){
        for (j in 0..2){
            for (k in 0..2){
                val celda = multidimensionalArray[i][j][k]
                  // leer, escribir o cualquier otra lógica aplicada
                  // a la celda
            }
        }
    }

Bueno esto es el primer paso, pero si entendiste la lógica de la estructura de datos puedes resolver problemas complejos usándola. Espero también que lo hallas entendido explicado de esta forma, así que cuando tengas que manejar datos donde tengas que relacionarlos a parámetros que identifiques que los puedas ordenar en una jerarquía con una relación entre ellos de uno a muchos (1:N) piensa que una de las soluciones podría ser usando arreglos multidimensionales.

Chao y hasta proto.

Hola soy yo nuevamente Jander tu programador favorito : ). Sé que prometí la segunda parte de los testing unitarios, pero he tenido q mirar este tema recientemente y decidí hacer un post del mismo. Sin más muela (“charla”) como decimos en buen cubano, empecemos.

MockWebServer es una herramienta que nos ayuda a probar cómo nuestra aplicación Android interactúa con las APIs que consume. Con MockWebServer podemos crear un servidor falso que intercepta las peticiones HTTP que hacemos desde nuestra app y devuelve las respuestas que nosotros queramos. De esta forma, podemos verificar si nuestra app se comporta correctamente ante diferentes situaciones, como por ejemplo, errores del servidor, datos inválidos o tiempos de espera. Además, al usar MockWebServer no necesitamos tener una conexión real con un servidor externo, lo que hace nuestras pruebas más rápidas y fiables. Puedes usarlo como cualquier otro mock y simular la respuesta del servidor.

Esta respuesta la almacenamos en el directorio de androidTest, en un nuevo archivo q vamos a crear llamado networkresponses.json que se recomienda tenga la siguiente ruta src/debug/assets/. El mismo representa la response del servidor, (nos lo podemos crear o podemos usar una respuesta real del servidor(copy/paste))

Ejemplo:

{
    "marcadores": [
      {
        "latitude": 40.416875,
        "longitude": -3.703308,
        "city": "Madrid",
        "description": "Puerta del Sol"
      },
      {
        "latitude": 40.417438,
        "longitude": -3.693363,
        "city": "Madrid",
        "description": "Paseo del Prado"
      },
      {
        "latitude": 40.407015,
        "longitude": -3.691163,
        "city": "Madrid",
        "description": "Estación de Atocha"
      }
    ]
}

Este código representa la respuesta de un servidor en formato JSON. El json debe estar en correspondencia a la lógica de nuestra app. En este caso se trata de una lista de localizaciones

Para acceder al archivo debes configurar el build.grdle del módulo y sincronizarlo:

testOptions {
  unitTests {
  includeAndroidResources = true
  }
}

De esta forma ahora tus test unitarios pueden acceder a todos los recursos. El próximo paso es poder leer este archivo.json que contiene la respuesta del servidor y recuperarlo como un String. Te puedes crear un objeto como el siguiente:

object JsonReader {
  fun getJson(path: String): String {
    return try {
      val context = InstrumentationRegistry.getInstrumentation().context
      val jsonStream: InputStream = context.assets.open(path)
      String(jsonStream.readBytes())
    } catch (exception: IOException) {
      Logger.e(exception, "Error reading network response json asset")
      throw exception
    }
  }
}

¿Como crear nuestro test con el servidor mockeado?

1- Configuremos nuestra clase para los test donde mockearemos el server

Anotar la clase test con @RunWith(RobolectricTestRunner::Class) te permitira usar el framework de android sin tener que lanzar un emulador gracias a la librería de Robolectric

2- Crear la dependencia de MockWebServer y configurarla
Inicia el servidor en el puerto 8080 antes del test y apágalo luego que finalice el test

private lateinit var mockWebServer: MockWebServer

@Before()
fun setup(){
 mockWebServer = MockWebServer()
 mockWebServer.start(8080)

}

@After
fun teardown() {
mockWebServer.shutdown()
}

3- Configurar la response del server

Para ello tenemos la propiedad MockWebServer.dispatcher que podemos configurar con un objeto de la Clase Dispatcher que nos provee la librería de MockWebServer.
Por ejemplo en este trozo de código estamos configurando el dispatcher para recibir una respuesta mockeada con código 200 cuando reciba determinado endpoint

...
 private val endpointPath = "/endpoinpath"
...
private fun getDispatcherForValidToken() = object : Dispatcher() {
    override fun dispatch(request: RecordedRequest): MockResponse {
      return when (request.path) {
        endpointPath -> { MockResponse().setResponseCode(200) }
        else -> { MockResponse().setResponseCode(404) }
      }
    }
  }

En este próximo ejemplo estamos configurando la respuesta, pero esta vez estamos añadiendo un Body apoyándonos en el objeto q habíamos creado previamente que nos devuelve un json en forma de String desde el archivo src/debug/assets/networkresponses.json en nuestros recursos

private fun getDispatcherForExpiredToken() = object :Dispatcher() {
  override fun dispatch(request: RecordedRequest): MockResponse{
    return when (request.path) {
      authEndpointPath -> { MockResponse().setResponseCode(200).setBody(
JsonReader.getJson("networkresponses/validToken.json")
      }
      endpointPath ->{ MockResponse().setResponseCode(200) }
      else -> { MockResponse().setResponseCode(404) }
    }
  }
}

Finalmente podemos recuperar la respuesta de nuestro server de la siguiente forma:

val request = mockWebServer.takeRequest()

Podríamos hacer algunas verificaciones en el test tales como:

with(request) { // 2
  assertThat(method).isEqualTo("GET")
  assertThat(path).isEqualTo(animalsEndpointPath)
  assertThat(getHeader(ApiParameters.AUTH_HEADER)).isEqualTo(ApiParameters.TOKEN_TYPE + validToken)
}

Repasemos lo que hemos visto hasta aquí. Primero vimos que es MockWebServer y para nos ayuda en nuestros tests. Luego aprendimos como añadir un archivo .json con el contenido de la respuesta de nuestro servidor ficticio, además de crear un objeto que nos ayuda a convertir este json en un String reconocible para nuestro código. Lo siguiente fue como añadir la dependencia del servidor a nuestro test y como configurarla
Finalmente tocamos como personalizar la respuesta de nuestro server usando el dispatcher.

El uso de este server en nuestro test depende de la lógica en nuestra app.

Si has llegado hasta este punto tienes las bases para iniciarte en el testing del network de tu app. Sé que hay mucho más de que hablar pero cómo te dije estas son las bases. Sígueme que estaré publicando más contenido de testing y del mundo del desarrollo de Android. Gracias : )

Agradeceré cualquier comentario constructivo

Hola a todos los que se han tomado tiempo para leer este post, espero poder ayudarlos en sus dudas acerca de testing en Android. Al tratarse del primer post permítanme una pequeña presentación. Mi nombre es Jander Laffita graduado de Ciencias Médicas pero apasionado del código y programador de vocación y profesión : ). Actualmente trabajando para Jade Innovaciones Informáticas, una empresa de desarrollo de Software en general. Esta será una serie de artículos cortos basados en las guías de Google, que en principio comenzaron siendo mis notas de estudio y quiero compartir con ustedes.

El testing es una parte integral del proceso de desarrollo. Al ejecutar pruebas puedes verificar la corrección, el comportamiento funcional y la usabilidad de la app antes de lanzarla públicamente.

Categorías de pruebas:
1- Pruebas de nivel inferior (pruebas de unidades) 70%
2- Pruebas de nivel medio (pruebas de integración) 20%
3- Pruebas de nivel superior (pruebas de extremo a extremo) 10%

El porcentaje representa la distribución recomendada por Google de los test en tus apps.

Vamos a dar un breve repaso a cada tipo de test.

Pruebas de nivel inferior: deben ser pruebas unitarias q validen la funcionalidad de cada clase dentro de la app. Si las pruebas dependen del framework de android usa una API unificada independiente del dispositivo (androidx.test).Esta te permite ejecutar la prueba de forma local sin un dispositivo físico ni un emulador.

Pruebas de nivel intermedio: Validan la colaboración y la interacción de un grupo de unidades

Ejemplos:
-> interaccion vista modelo (Fragment-XML, Fragment-ViewModel)
-> repositorio (data sources — DAO)
-> porciones verticales (todas las capas de una pantalla determinada)
-> varios fragmentos en un área específica de la app

Pruebas Unitarias: Ejercitan la funcionalidad de la unidad de código más pequeña posible (que puede ser un método, una clase o un componente) de manera repetible. Debes crear pruebas de unidades cuando necesites verificar la lógica de un código específico en tu app. Por ejemplo, si pruebas una unidad en una clase, la prueba podría verificar que la clase esté en el estado correcto.

Se dividen en: Pruebas locales, pruebas de unidades que se ejecutan solo en la máquina local. Pruebas instrumentadas, pruebas que se ejecutan en un dispositivo o en un emulador.

En esta primera parte de esta serie vamos a acercarnos a las pruebas locales.
Si tienes dependencias del framework de android se recomienda usar Robolectric. Si tienes dependencias mínimas del framework de android o solo dependen de sus propios objetos, usa Mockito

Añade al archivo gradle a nivel de módulo las dependencias q vallas a necesitar según lo expuesto en el párrafo anterior

 dependencies {
        // Required -- JUnit 4 framework
        testImplementation 'junit:junit:4.12'
        // Optional -- Robolectric environment
        testImplementation 'androidx.test:core:1.0.0'
        // Optional -- Mockito framework
        testImplementation 'org.mockito:mockito-core:1.10.19'
    }

Para crear una clase de prueba, crea una clase q contenga uno o más métodos de prueba ( Anotación @Test )

Ejemplo:

import com.google.common.truth.Truth.assertThat
    import org.junit.Test

    class EmailValidatorTest {
        @Test
        fun emailValidator_CorrectEmailSimple_ReturnsTrue() {
            assertThat(EmailValidator.isValidEmail("name@email.com")).isTrue()
        }
    }

¿ Como añadir dependencias del Framework ?

Si tus pruebas interactúan con varias dependencias del framework de Android usa las clases q proporciona Robolectric

import android.content.Context
    import androidx.test.core.app.ApplicationProvider
    import com.google.common.truth.Truth.assertThat
    import org.junit.Test

    private const val FAKE_STRING = "HELLO_WORLD"

    class UnitTestSample {
        val context = ApplicationProvider.getApplicationContext<Context>()

        @Test fun readStringFromContext_LocalizedString() {
            // Given a Context object retrieved from Robolectric...
            val myObjectUnderTest = ClassUnderTest(context)

            // ...when the string is returned from the object under test...
            val result: String = myObjectUnderTest.getHelloWorldString()

            // ...then the result should be the expected one.
            assertThat(result).isEqualTo(FAKE_STRING)
        }
    }

¿ Como incluir dependencias ficticias o mocks ?

Las llamadas a clases del framework de android desde un test arrojará una excepción. Esto es para asegurarse q solo estás probando código y no comportamientos de Android.

¿ Como generar dependencias de android “mockeadas” :) ?

Mockito es una librería donde puedes configurar objetos ficticios para mostrar un valor especifico cuando se les llama

Para agregar un mock sigue estos pasos:
1- Incluye la dependencia de Mockito en el gradle
2- Al comienzo de la definición de la clase agrega la anotación @RunWith(MockitoJUnitRunner.class) este objeto le indica a Mockito
que el uso de tu framework es correcto y simplifica la inicialización de los mocks.
3- A fin de crear un mock para una dependencia de andorid agrega la anotación @Mock antes de la declaración de campo
4 Para indicar el comportamiento de la dependencia puedes especificar una condición y el valor mostrado cuando se cumpla la condición
mediante los métodos when() y thenReturn(). Este when no se refiere al bucle sino a un método público de Mockito.

El siguiente ejemplo muestra cómo crear un mock de Context:

import android.content.Context
    import com.google.common.truth.Truth.assertThat
    import org.junit.Test
    import org.junit.runner.RunWith
    import org.mockito.Mock
    import org.mockito.Mockito.`when`
    import org.mockito.junit.MockitoJUnitRunner

    private const val FAKE_STRING = "HELLO WORLD"

    @RunWith(MockitoJUnitRunner::class)
    class UnitTestSample {

        @Mock
        private lateinit var mockContext: Context

        @Test
        fun readStringFromContext_LocalizedString() {
            // Given a mocked Context injected into the object under test...
            `when`(mockContext.getString(R.string.hello_word))
                    .thenReturn(FAKE_STRING)
            val myObjectUnderTest = ClassUnderTest(mockContext)

            // ...when the string is returned from the object under test...
            val result: String = myObjectUnderTest.getHelloWorldString()

            // ...then the result should be the expected one.
            assertThat(result, `is`(FAKE_STRING))
        }
    }

Hasta este punto has podido añadir context como dependencia en tus test usando Robolectric y Mockito. Para mas detalles mira la documentación de Mokito aquí

La lógica a usar en tus test depende claramente del método q estés testeando en tu app. En otro post veremos más de cómo se implementa esta a más detalle. En la parte 2 de esta serie veremos como usar las pruebas de unidades instrumentadas. Gracias por llegar hasta esta parte del post. Sígueme si quieres aprender más del mundo de android y la programación en general.