Una red útil para desarrolladores de Android (parte 1) autor: Dinorah Tovar | Conoce Android | Octubre de 2020

Capa de datos sencilla para cada aplicación

Aquí hay una lista de blogs de esta serie:

  • Parte 1: HTTP y capa de red
  • Parte 2: TSL, certificados y adjuntos
  • Parte 3— Autenticadores e interceptores
  • Parte 4: rendimiento, redundancia y simultaneidad
  • Parte 5 – Prueba, simulación e integración
Una red útil para desarrolladores de Android

Esta es la primera parte de esta serie. «Una red útil para desarrolladores de Android» cuando hablamos de la capa de datos de la red con una visión diferente, que suele abordarse, es difícil trabajar con la red en Android, con múltiples operadores, contenido diferente y rico, streaming y todo esto debe llegar a nuestros usuarios sin perder un solo detalle.

«Un.» capa de aplicación protocolo para distribuido, colaborativo, hipermedia Sistemas de información»

Eso significa muchas cosas, básicamente, si crea un sitio web, una aplicación de teléfono inteligente, IoT, incluso simplemente descarga un archivo, usa este protocolo, ha crecido de un sitio web con HTML simple a una aplicación web a una aplicación móvil, ha evolucionado para convertirse en una capa de API que se usa comúnmente.

Las solicitudes de Http las generan nuestros usuarios, cuando un usuario interactúa con nuestra aplicación móvil, comenzamos a solicitar información al servidor, cuando hacemos algunos clics, posible desplazamiento o eliminación, por ejemplo, imagina Gmail, cada vez que ingresas en la aplicación Http se envía una solicitud a e- correos electrónicos reanudados. Si elimina, responde o incluso abre un correo electrónico, se genera una solicitud Http, esas solicitudes Http van al servidor original o al servidor de caché proxy, y ese servidor genera una respuesta Http. Cualquier conjunto de solicitud / respuesta generalmente tiene:

  • Demanda – Ingrese una solicitud HTTP para una URL
  • Retroalimentación – La solicitud devuelve una respuesta, que puede ser un error o un éxito.
  • Datos que se pueden analizar – En dispositivos móviles tenemos que analizar la respuesta a un objeto, clase de datos o estructura que podemos usar en la aplicación, utilizando algunos terceros como Moshi, Json, Gson *, incluso puedes crear el tuyo propio, pero cuando llega al teléfono es una simple cadena .

Cualquier solicitud / respuesta Http generalmente tiene varias otras cosas:

  • Buscador de recursos unificado: Una URL es una ubicación específica, una dirección en algún lugar de Internet con un tipo específico de método.
  • Encabezamiento: El da el cliente y el servidor pasan información adicional con una solicitud o respuesta HTTP. El encabezado HTTP consta de un nombre que no distingue entre mayúsculas y minúsculas y dos puntos (:), luego según su valor.
  • Cuerpo: La respuesta real, una cadena simple que expone el contenido del cuerpo, no puede ser nada para un método, como Unit.

Para cada solicitud a la que recibimos una respuesta, ya sea que no sea exitosa, tenemos un código de estado que conocemos:

  • 1xx – Todo está bien, solo espera un minuto
  • 2xx – Todo está bien, es una respuesta completamente consecutiva
  • 3xx – La respuesta está en otro lugar, estás perdido
  • 4xx: la solicitud del cliente no se cumplió correctamente, por lo que este es un error móvil
  • 5xx: el servidor no pudo cumplir con la solicitud correcta, por lo que este es un error de backend
  • @GET: Se utiliza para leer o recuperar información sobre recursos. Las solicitudes GET se utilizan solo para leer datos y no los modifique, se consideran seguros
  • @POST: Se utiliza para crear nuevos recursos. En particular, se utiliza para crear recursos secundarios. No es ni seguro ni idempotente. Por tanto, se recomienda para solicitudes de fondos no idempotentes. Es muy probable que la creación de dos solicitudes POST idénticas dé como resultado que dos fuentes contengan la misma información.
  • @PUT: Se usa para las opciones de actualización, PUT-ing a un URI de recurso conocido con el cuerpo de la solicitud que contiene una representación actualizada del recurso original. PUT no es una operación segura porque cambia (o crea) un estado en el servidor, pero es idempotente. En otras palabras, si crea o actualiza un recurso usando PUT y luego hace la misma llamada nuevamente, el recurso todavía está allí y aún tiene el mismo estado que la primera llamada.
  • @DELETE: Se utiliza para eliminar un recurso identificado por una URL.
  • @PATCH: Se usa para ajustar habilidades. La solicitud PATCH debe contener solo cambios de recursos, no el recurso completo. PATCH no es seguro ni idempotente.

Cualquier modificación dentro de cualquiera de estos métodos para una aplicación móvil puede ser significativamente peligrosa, permitiendo que la imagen de una aplicación acepte una variable como doble en respuesta, si cambia a booleano, el análisis de datos se interrumpirá, esto es un gran error que los técnicos de backend deben tomar en cuenta siempre que cambie el endpoint que se consulta durante la producción.

Dentro de Android, tenemos una biblioteca increíble que creará un HttpClient nombrado en unos segundos OkHttpClient, se crea un Cliente con readTimeOut y ConnectionTimeOut, si el servidor no entrega ninguna respuesta dentro de este límite de tiempo, terminaremos con una conexión fallida.
Hay una parte realmente importante para este cliente, también podemos darle un constructor para Cache (y muchas otras cosas de las que hablaremos más adelante en esta serie)

La caché está diseñada para mejorar las llamadas de red para todos, incluso para los usuarios, porque termina sin requisitos de red innecesarios. La captura nunca reemplaza la llamada original a su DNS, por ejemplo, la caché nunca reemplaza la recuperación de datos de su fuente.

Caché de base de datos
No es realmente la capa de red, le pedimos información a nuestras API y la almacenamos en SharedPreferences, DataStore o cualquier base de datos que pueda ser relacional o no relacional. El rendimiento, tanto en velocidad como en rendimiento, que proporciona su base de datos puede ser el factor más eficaz en el rendimiento general de su aplicación.

Red de entrega de contenidos
Cuando el tráfico de su servidor es mundial, no siempre es un método fácil y rentable de replicar toda su infraestructura en todo el mundo, y tenemos una CDN que le brinda la capacidad de usar su red de borde global para proporcionar copias en caché de su contenido API, incluidas imágenes, transmisión. y videos

sistema de nombres de dominio
En principio, cada solicitud de dominio ingresada en Internet requiere consultas a los servidores de caché de DNS para resolver la dirección IP asociada con el nombre de dominio. El almacenamiento en caché de DNS puede tener lugar en muchos niveles, incluido el sistema operativo, a través de ISP y servidores DNS.

Específicamente para la red, podemos procesar nuestro HttpClient Canche (verifique el código anterior) y Non-Cache, por ejemplo, en algunas aplicaciones podemos tener un movimiento para restaurar, puede ser necesario omitir el caché y recuperar datos directamente desde el servidor. Para forzar una restauración completa, agregue no-cache directamente en su Cache Builder para su OkHttpClient, la decisión de realizar este tipo de llamada específicamente de forma productiva es más que técnicamente sabia.

Eso es todo por esta parte de la publicación. En la siguiente parte nos ocuparemos de los certificados, la fijación y TSL.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *