Empezando con Windows 7.1 (y XVII) – Comunicación entre diferentes VistaModelo


El problema

A medida de que voy avanzando en la aplicación, veo que poco a poco se van cubriendo escenarios comunes. En este post me voy a centrar en la comunicación entre diferentes VistaModelo.

En vez de dibujar aburridos diagramas de clases, vamos a tratar de ilustrarlo con un par de pantallas.

El programa

Disponemos de una primera pantalla de configuración. Esta pantalla permite activar notificaciones y, además, muestra información sobre la configuración del usuario en FourSquare (extraída de una entidad que consume información de la base de datos)

configuracion_1

Así mismo, el “tile” sobre los campos informativos “ID de Usuario” y “Nombre Completo” se puede pulsar para acceder a la página que nos permite registrar la información del usuario.

configuracion_2

Esta página (bueno, la página no, la vistamodelo que hay detrás), una vez el usuario autoriza el acceso de la aplicación, guarda la información en base de datos y vuelve atrás (a la página anterior).

configuracion_1

Que, no se ha enterado de que ha habido cambios en la entidad de configuración que consume para mostrar la información de FourSquare (lógico, al fin y al cabo, estos cambios han tenido lugar fuera de su ámbito).

La solución

La solución al problema es sencilla (aproximación prácticamente idéntica a las que hay en otro patrones de diseño como MVC o MVP).

En pocas palabras:

  1. La página de configuración se registra a posibles cambios de la entidad (o entidades) en que se encuentra interesada.
  2. La página de registro, que actúa sobre dicha entidad, lanza un mensaje “al mundo” cuando realiza algún cambio sobre la misma.
  3. La página de configuración se puede dar por enterada del cambio e inicia sus tareas de avisar, a su vez, a la página de que ha habido cambios y que tiene que refrescar la información que está mostrando en pantalla.

El ejemplo

MVVM Light nos proporciona un conjunto de clases que nos ayuda en estas tareas. Se encuentran bajo el espacio de nombres Messaging.

image

Aunque veremos algunos de los tipos definidos en este espacio de nombres en algún futuro post, me voy a centrar ahora en un par de clases.

La clase Messenger se encarga de gestionar el envío y recepción de mensajes. Los mensajes se envían “a quien quiera oírlos”. Los receptores de los mensajes tienen que haberse suscrito para poder recibir mensajes de un tipo.

Como explicaba antes, la VistaModelo de Registro se encarga de actualizar las preferencias de usuario tras el proceso de registro en FourSquare

   1: /// <summary>

   2: /// Registra las preferencias de usuario a partir de la información obtenida del mismo de FourSquare

   3: /// </summary>

   4: private void RegistrarPreferenciasDeUsuario()

   5: {

   6:     try

   7:     {

   8:         Entities.Preferencias pref = _dataService.ObtenerPreferenciasConfiguracion();

   9:         Entities.Preferencias prevPref = pref.Clone();

  10:  

  11:         pref.FourSquareFullName = String.Format("{0} {1}", _user.firstName, _user.lastName);

  12:         pref.FourSquareUserId = _user.id.ToString();

  13:         pref.FourSquareToken = _fsContexto.Token;

  14:  

  15:         _dataService.ActualizarPreferencias(pref);

  16:  

  17:         RaisePropertyChanged<Entities.Preferencias>("Preferencias", prevPref, pref, false);

  18:     }

  19:     catch (Exception ex)

  20:     {

  21:         // Hacer algo con la excepción

  22:         throw;

  23:     }

  24: }

Como podéis ver en el código, nada fuera del otro mundo. Se invoca el método RaisePropertyChanged. En este caso, no estamos interesados en ver qué propiedad de la entidad ha cambiado (ya que cambian varias y, a todos los efectos, no estoy interesado en obtener este grado de detalle) y he decidido pasar como primer parámetro el nombre de la clase. Se pasa también el valor original, el valor actualizado (para poder realizar esto, he tenido que montar un método para clonar la entidad) y se indica si el mensaje será lanzado “a quien quiera oírlo” (broadcast). Si este último parámetro no se pone a true, otra VistaModelo no recibirá esta mensaje.

En cuanto a la VistaModelo correspondiente a la configuración está interesada en recibir mensajes que le informen de cambios en las preferencias, para ello en el constructor realizaremos la operación de sucripción al tipo de mensaje.

   1: /// <summary>

   2: /// Este método subscribe a la VistaModelo a cualquier cambio realizado las propiedades de las <see cref="Preferencias"/>

   3: /// más concretamente sobre las preferencias que afectan a FourSquare

   4: /// </summary>

   5: private void SubscribirseCambiosEnPreferenciasConfiguracion()

   6: {

   7:     MessengerInstance.Register<PropertyChangedMessage<Preferencias>>(this, (p) =>

   8:     {

   9:         _preferencias = p.NewValue;

  10:  

  11:         DispatcherHelper.CheckBeginInvokeOnUI(() =>

  12:         {

  13:             RaisePropertyChanged(FourSquareUserIdNombreProp);

  14:             RaisePropertyChanged(FourSquareFullNameNombreProp);

  15:         });

  16:     });

  17: }

Este código tiene un poco más de enjundia. Vamos a analizarlo.

Primero, hacemos uso de la propiedad MessengerInstance que estamos heredando de la clase base (ViewModelBase) definida en el framework. A través de esta clase nos registramos a los mensajes del tipo PropertyChangedMessage<Preferencias> (que, si os fijáis, es el mismo tipo que estábamos lanzando en la VistaModelo anterior).

A continuación utilizamos un delegado anónimo que actualiza la referencia que teníamos con el nuevo valor y hace uso de una clase llamada DispatcherHelper (también definida en el framework MVVM Light) que nos permite acceder fácilmente al Dispatcher.

Mediante este Dispatcher, estamos pidiendo que se ejecute en el hilo de UI la actualización de las propiedades para que la página pueda refrescarlas.

¿Por qué esto es importante? En Silverlight (en realidad no exclusivamente en Silverlight) se define un hilo de UI donde se ejecutan todas las acciones que afectan a la interfaz de usuario (UI). Cualquier intento de actualizar algún elemento de la UI fuera de dicho hilo se va estrellar irremediablemente con la excepción: Invalid cross-thread access.

image

Por último, es necesario inicializar el DispatcherHelper antes de que seamos capaces de hacer funcionar todo esto. ¿Cómo lo hacemos? En la documentación encontrada por la red se insiste en inicializar dicha clase en App_Startup porque este método siempre se invoca en el contexto del hilo de UI.

Desgraciadamente, en WP7, tal método no existe. ¿Dónde inicializamos el dispatcher entonces? La respuesta es: en el constructor de App, que siempre se ejecuta en el hilo de UI.

image

A partir de aquí, todo funciona como debería.

configuracion_1

Ya que al actualizar Preferencias desde la vista de Registro

configuracion_2

El mensaje de cambio llega a la vista de configuración que se encarga de avisar a su vista de que ha de refrescarse.

configuracion_3

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s