Tutorial de Android: Cómo simular un backend en una aplicación sin servidor | de Michael Ganchas | Noviembre de 2020

Imagen de https://www.manypixels.co/gallery/

¡Hola a todos!

Hoy me gustaría compartir con ustedes cómo podemos diseñar una aplicación sin servidor para poder invocar API de terceros fuera de su alcance nativo, sin la necesidad de un backend dedicado y administración de servidor relacionada.

Cuando podría ser útil

Supongamos que tenemos una aplicación móvil escrita de forma nativa para Android y estamos a punto de lanzar una versión de iOS. Excluyendo el uso de algunas tecnologías multiplataforma, sería útil abstraer la lógica empresarial de nuestras aplicaciones nativas y tenerla disponible, para ambos, en un lugar dedicado.

Por esto, nosotros metroEs posible que desee implementar algunas (o todas) de las siguientes características:

  • Reaccionar a la edición de un documento en una base de datos (desencadenar)
  • Ejecute periódicamente un fragmento de código (programado)
  • Llame a una función para ejecutar la lógica empresarial o para invocar una API de terceros (llamada)

Para simplificar cada caso, usemos el trabajo de un camarero como analogía para lograr esto:

  • Cuando llegan nuevos clientes a la puerta, se acerca a ellos y los acompaña a su mesa (desencadenar)
  • Cada media hora irá a comprobar si los baños están impecables (programado)
  • Ser llamado por parte del cliente para recibir su pedido y transmitir esta información al personal de cocina * de terceros * (llamada)
  • Ser requerido por el cliente para la cuenta (llamada)

Para lograr lo anterior, usaremos Firebase y lo que ahora se llama Cloud Functions. Ciertamente, existen otras buenas opciones, pero, para una plataforma gratuita, tiene muchas características que podemos usar para crear un entorno de desarrollo robusto, rápido y escalable.

Actualmente lo estoy usando en mi aplicación MapCrumbs y funciona de maravilla.

En cuanto a la parte de codificación, usaremos Kotlin para el código nativo y Node.js para el código de Cloud Functions.

Lo primero que debemos hacer es configurar el proyecto para que incluya las dependencias necesarias de Firebase. Para evitar desviarse del propósito de este artículo, siga los pasos que se enumeran aquí.

Nuestra backend reside en el archivo “índice” (.js o .ts) recién creado. Aquí es donde escribiremos las funciones expuestas a nuestra aplicación y desde donde ejecutar la lógica empresarial.

Desencadenar

Uno de los requisitos es tener una función que reacciona a cuando llegan nuevos clientes a la puerta.

Para este ejercicio, significa cuando se crea un nuevo documento para los “clientes” de la colección de Cloud Firestore. Luego verificaremos si hay una mesa disponible para ese número de clientes y reservaremos la mesa si hay una. Algo como esto:

Nota: para saber mas promesas y cómo consultar y actualizar colecciones de Cloud Firestore.

Programado

Para ello, queremos una función que ejecute un fragmento de código cada media hora. Una posible implementación para esto podría ser algo como lo siguiente:

Nota: No pude encontrar un algoritmo para esto 🙂

Llamada

Para mí esta es la característica más interesante. Realmente imita el propósito principal de un backend, donde expondrá características de lógica empresarial que deberían tener su implementación abstracta de la aplicación nativa.

Podemos usar estas llamadas funciona para ambos dispara y olvida o para recuperar algo de su invocador.

Veamos cómo se puede implementar esto en el nuestro. backend.

La función “ReceiveMealOrder” es un ejemplo de dispara y olvida , mientras que cuando llamamos a la función “askForTheBill”, esperaremos un valor de retorno.

En el lado nativo, necesitaremos un componente para acceder a las funciones de llamada, para pasarles datos relevantes y esperar su resultado (si corresponde).

Modelos

Necesitamos una representación de una comida ordenada, que podría verse así:

Cuando solicitemos la factura, esperaremos un resultado que coincida con la siguiente representación:

Nota: para saber mas clases de datos.

los objetos asociados Mantener el nombre de cada propiedad almacenada como claves se explicará más adelante.

API de backend

Aunque actualmente estamos usando Cloud Functions, es útil desconectar nuestros componentes de acceso a la API de proveedores específicos, de modo que si un día queremos cambiarlo por otro proveedor, solo tenemos que cambiar la implementación, pero mantener la abstracción como está. es. Lea más sobre esto aquí.

Definamos nuestras abstracciones:

Nota: Estamos usando el suspender palabra clave porque la llamada a la función se realizará de forma asincrónica.

Para este ejercicio, usaremos un objeto singleton para implementaciones de Cloud Functions, que tienen este aspecto:

Nota: Necesitamos mapear el tipo Meal para pasarlo como un argumento a la función “receiveMealOrder”.

Nota: Convertimos el resultado (datos) de la invocación a un Mapa para poder acceder a las funciones devolver el valor mapeado como pares clave-valor. Requerirá que el valor de cada entrada sea emitido al asignar o leer su valor.

los esperar los métodos mantendrán la ejecución hasta que finalice la invocación antes de reanudar su alcance.

Nota al margen: Sería útil para Kotlin agregar algún tipo de C # nameOf (propiedad) para obtener el nombre de la propiedad. En este caso, no sería necesario agregar todas las constantes KEY_XXX.

Administrador de backend

Backend Manager es la capa intermedia entre el controlador y los componentes de acceso a la API. Es … nuestro buen camarero.

Debería, al menos, tener el siguiente comportamiento:

Luego, durante la implementación, debe proporcionar acceso a esas API:

Controlador

Para simplificar, consideramos los clics en los botones como acciones desde el punto de vista del cliente. Podría verse así:

Nota: Estamos usando Kotlin’s corrutinas para invocar Cloud Functions en el alcance de E / S y manejar la ejecución posterior en el alcance principal.

Deja una respuesta

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