Android View State Machine Part 2: State Data Creation and Pipeline | por Egbai Smile Mmumene | Noviembre de 2021
Cabe destacar que aquí el término «estado» se usa libremente, donde asociamos el término estado como un conjunto de datos que serán representados en la vista, es decir, el estado de error se convertirá al usuario viendo la pantalla de error , que contiene el texto obtenido del objeto de estado de error
Tengo este término y lo llamo Bandera de estado, Lo describo como un indicador en el objeto de datos, utilizado para calcular el estado o representar el estado en sí. Echemos un vistazo más de cerca a esto.
Mirando En este ejemplo de datos JSON, el primer ejemplo representa usuarios sin transacciones y el segundo ejemplo tiene una lista de transacciones. Si tiene una pantalla que debería mostrar una lista de transacciones de usuario, tendrá una máquina de estado de IU que puede mostrar un estado vacío o mostrar una lista de transacciones de usuario cuando no hay transacciones.Ahora no hay mapeo, lo sabemos comercio La clave JSON es nuestra «Bandera de estado» por Este ejemplo JSON. Esta es solo una representación simple, ya que podemos saber que hay muchas formas diferentes de crear indicadores de estado, algunos procesos de representación utilizan cosas como enumeración o sellado, o incluso indicadores booleanos con claves específicas. Ahora, este es el uso de etiquetas de estado desde la perspectiva de devolver los datos del servidor y las etiquetas de identificación, sin posprocesamiento.
En un escenario más realista, tenemos etiquetas de estado, generalmente una mezcla de diferentes atributos, y necesitamos realizar verificaciones de varios niveles para verificar las claves disponibles en la respuesta del servidor o los objetos de la base de datos en el dispositivo.
En estos escenarios, definimos nuestro estado como una combinación de diferentes atributos de datos o la ausencia de ciertos valores, y el procesamiento de estos datos y la asignación o creación de datos de estado incrustados se pueden considerar como una tubería de estado.
Estado de éxito y error
Cuando solicita datos de un servicio, generalmente espera éxito en uno de los dos estados cuando recibe un tipo de datos de ruta feliz o un error (ruta no tan feliz), independientemente de si esta respuesta es el comienzo del proceso de canalización de datos y Se incluirán en el flujo de la ruta Algunos signos de estado.
La ruta de datos devuelta (feliz o triste) determinará la conversión de tipo aplicada a los datos hasta que obtenga el objeto de datos de estado final.
Hablemos del estado de error, la mayoría de las veces los errores siempre parecen tener la marca más obvia, y su representación de la vista en la máquina de estados es casi siempre muy simple. Suponga que realiza una solicitud desde un dispositivo móvil y recibe una excepción, y luego, basándose en la excepción, sabrá a qué estado de error debe realizar la transición.
Arriba tenemos 2 sub-estados de errores, podemos mapear a cualquiera de ellos en función de la respuesta, es decir, podemos mapear a cualquier error general de la falla del servidor, o mapeamos la conexión al problema relacionado con Internet.
Un método directo para asignar errores al error ViewState, aquí usamos el tipo Throwable / Exception como StateMarker, por lo que IOException Nos llevará a un ConnectivityErrorEstado y cualquier otro Exception Será considerado GeneralErrorEstas asignaciones son siempre específicas de la aplicación, y esto solo se muestra como un ejemplo de cómo se convierte el marcador de error al StateMachine de la vista.A diferencia de lo que solemos buscar, buscamos rutas felices marcadas en objetos de datos, por ejemplo enum, boolean, int O alguna combinación string Para determinar en qué estado se encuentra el usuario. Por ejemplo, ¿los detalles incompletos significan que los datos pertenecen a un nuevo usuario?
Si seguimos el camino feliz de recibir una respuesta de datos exitosa del servicio, generalmente nuestro siguiente paso es limpiar estos datos y reasignar el objeto a algo más fácilmente asociado con su vista. Como preferencia, me gusta usar clases selladas para representar los datos de mi estado y adjuntar los datos asociados como parámetros. Esto hace que sea más fácil cambiar la lógica de qué estado devolver y extraer datos cuando solo accedo a campos específicos que sé que están disponibles En escenarios complejos, prefiero seguir procesando widgets con estado en la canalización. Si mis hijos sellados representan vistas, y después de mapear estos widgets, el objeto final emitido simplemente se adjunta a la vista.
Arriba tenemos un estado de vista simple, que representa una vista vacía y una vista de datos, nuestro ejemplo esperado es recibir datos, dejar que un mapeador intermedio los convierta a uno de los estados listados y luego consumir el objeto final en la vista.
Crear un mapeador nos permite aprovechar nuestra hipotética «Bandera de estado» En este caso, esta es la disponibilidad de la lista de transacciones.Cuando la lista está vacía, devolvemos un estado EmptyView. En aplicaciones más complejas, puede hacer que un asignador alimente datos a otro asignador hasta que obtenga los datos requeridos / estado hipotético. Esto generalmente se debe a que los marcadores de estado en estos sistemas provienen del cálculo de varios atributos o por separado.
Nota: La creación de mapeadores como objetos hace que sea más fácil probar estos mapeadores y verificar la salida sin tener que depender de agregar muchas configuraciones iniciales.
En términos generales, en términos de mapeo de datos, la mayoría de las personas mapearán a través de capas del sistema, por lo que desde Datos -> Dominio -> Representación o Datos -> DemoY solo se asignan a dominios cuando se necesita almacenamiento en caché. Esto es subjetivo para la arquitectura de la aplicación, porque no es raro encontrar objetos de dominio para su representación en la vista. Independientemente del proceso de pasos, intente siempre:
- Determine el estado en el que puede caer la vista o el sistema y cree las representaciones necesarias para procesar estos datos.
- Lógica de estado individual en presentación / vista. Esto ayuda a seguir fácilmente la lógica del estado al codificar y pensar en el flujo de datos.
- No devuelva datos en objetos que nunca se utilizarán. Al igual que en el ejemplo de estado anterior, nuestro EmptyState es esencialmente una pantalla con algún tipo de imagen / ilustración, por lo que nuestro objeto EmptyView no necesita devolver datos del usuario.
Nuestra canalización aquí agrega un conjunto de mapeadores o subprocesos que identifican, distribuyen y luego emiten o crean objetos con estado que pueden contener datos asociados.
en breve…
- Las transiciones entre estados de datos se basan en una serie de transiciones definidas por varias etiquetas de objetos de datos o colecciones.
- Identificar o conceptualizar algunos estados finitos (La clase secundaria es la clase principal del estado.) Incluir el camino feliz-triste (error y respuestas exitosas) facilita el manejo de varias transiciones entre estados, y agregar un nuevo estado es simplemente agregar un conjunto de transiciones para mapear este nuevo estado en su vista respectiva.
- Tener una única fuente de datos de estado en la vista ayuda a mantener una representación lógica clara para las transiciones de vista.
