Aprovechar el enlace de datos y BaseObservables para implementar actualizaciones de interfaz de usuario sobre la marcha para un elemento de vista de reciclador para una experiencia de usuario dinámica | de Keshav Kant Gupta | diciembre 2022

Foto de Rubaitul Azad en Unsplash Imagine un escenario en el que necesitamos implementar una operación en un elemento de vista de reciclador en función del estado actual de ese elemento, es decir. Nuestra perturbación lógica debe limitarse al estado de uno solo sin afectar el estado de otros elementos del reciclador, y estos cambios de estado deben sobrevivir a la reconstrucción de la vista del reciclador y la eliminación de la vista en las operaciones de desplazamiento.

aplicación de muestra

Consideremos una aplicación de gestión de inventario utilizada para registrar información sobre las mercancías que ingresan al almacén. Nos gustaría proporcionar una página donde los usuarios puedan especificar «N» productos diferentes con su cantidad, peso y dimensiones para definir la cantidad de espacio de almacenamiento que requerirá. Lo que también queremos son validaciones para cada artículo para que no terminemos con un producto de aspecto extraño que no tiene peso ni cantidad, etc. También queremos lograr estas validaciones en tiempo real, que no queremos notificar al usuario al final del formulario que se perdió algo en el medio. El producto final sería algo como esto.Una característica de esta aplicación es que podemos hacer clic en cualquier entrada de texto en cualquier elemento y nuestras validaciones funcionan en tiempo real.

Podríamos tomar otros enfoques

1. VerModelos – Tal vez podríamos usar ViewModelProviders para vincular diferentes instancias del mismo modelo de vista a un elemento de vista de reciclador en su soporte de vista y luego observarlas o vincular estas instancias a nuestro archivo XML. pero con este enfoque tendríamos que lidiar con el estado de estos modelos de vista, iniciándolos y destruyéndolos cuando el usuario se desplaza. Si bien esto se puede implementar, conlleva un alto riesgo de bloquear la interfaz de usuario en tiempo de ejecución. Es posible que se inicie una vista, pero hay un ligero retraso en la inicialización del modelo de vista, lo que provoca un «Excepción de puntero nulo‘ o terminar con un escenario donde la misma instancia de modelo de vista está vinculada a dos elementos de vista diferentes
2. Devoluciones de llamada de TextWatcher — También podemos usar observadores de texto para aplicar el mismo comportamiento. pero a veces pueden hacer que nuestro código sea muy complejo, lógico, especialmente cuando hay 4 o 5 observadores involucrados y necesitan interactuar entre ellos. Funcionan, pero a veces se siente como aplicar bucles a un problema de programación dinámica.
3. BaseObservables — También podemos aplicar observables base y mover parte de nuestra lógica al modelo de elementos en sí, luego este modelo se puede conectar a la vista en sí como cualquier otro modelo. Discutiremos este enfoque en este blog para lograr «actualizaciones rápidas de la interfaz de usuario para nuestros elementos de vista del reciclador».

¿Por qué no una clase de modelo de datos simple o algo así?

Consideremos una clase de datos simple de Kotlin para un producto que se parece a esto: esta clase de datos es perfecta, pero no para nuestro caso porque si creamos una dependencia del peso en la cantidad, un cambio en la cantidad no actualizará automáticamente nuestro peso, como este es el caso sin datos en vivo. Por lo tanto, no podemos vincular este producto para que cambiar la cantidad no cambie el peso, o muestre un error en nuestro TextInputLayout si nuestro peso está tan vacío. Para esto necesitamos un modelo base observable

BaseObservableModelsBaseObservableModels

Lo bueno de los modelos base observables es que podemos configurarlos para notificar a otras variables del modelo cuando cambia una variable. Entonces, cuando están vinculados a una vista, funcionan de manera similar a un módulo Livedata en un ViewModel. Lo que hicimos en el código anterior es que pasamos una fracción de nuestra lógica comercial a nuestro modelo. Este modelo se puede utilizar para hacer cualquier trabajo que hace un modelo. Sin embargo, dado que vinculamos este modelo a nuestro elemento de vista de reciclador, funcionará como un objeto LiveData y notificará a nuestra interfaz de usuario los cambios de datos en tiempo real. Este modelo logra esto mediante el uso de la clase databinding.BaseObservable proporcionada por Android.androidx.databinding.BaseObservable es una clase en la biblioteca de enlace de datos de Android que proporciona una clase base para objetos observados por expresiones de enlace de datos. Incluye métodos para notificar al sistema de vinculación de datos cuando los datos cambian para que las expresiones se puedan actualizar para reflejar los nuevos datos. En las clases anteriores actualizamos error de peso Si el valor de peso actual es nulo o nulo, daría nuestro «Diseño de entrada de texto” sobre el valor de product.weight en tiempo real. Entonces, si ingresamos un valor de peso vacío o un valor igual a cero, indicaría un error requerido. Otra cosa buena es que, dado que los observables están integrados en el propio modelo, es independiente de cualquier cambio de estado Nuestros artículos de vista de reciclador No tenemos que preocuparnos por iniciar o eliminar artículos de vista de reciclador. Aún así, debemos notificar a nuestra vista de reciclador de manera que nuestros observables antiguos no se atasquen en nuestras vistas recién creadas.

Adaptador RecyclerView y ViewHolder

nuestro viewHolder se vería así

Modelo de vista de actividad y devoluciones de llamada

Al agregar devoluciones de llamada al objeto, podemos actualizar nuestra IU de actividad según el estado de los datos dentro del adaptador de la siguiente manera. Esta devolución de llamada se adjunta al modelo a través del constructor y pasa el estado de los datos al modelo de vista de actividad