El Blog de Fox » Silverlight

Silverlight 4 final

admin — Fri, 16 Apr 2010 12:58:18 +0000

Bueno, despues de muchos meses de desarrollo y versiones betas, ya está aquí Silverlight 4 final.

Como requisito previo es necesario tener instalado el Visual Studio 2010 o el Visual Web Developer 2010 express.

Una vez cumplas dicho requisitos solo necesitas:

Herramientas Silverlight 4

Ahi ya viene incluido Silverlight en si, las herramientas para vs 2010, el sdk y los servicios RIA.

Un alivio, que siempre había que instalar tropecientos paquetes para echar esto a andar jeje.

MVVM Light: Localización

admin — Thu, 25 Mar 2010 14:26:17 +0000

Hola,

Aquí está el último artículo de esta serie sobre MVVM Light

Realmente la localización no forma parte de MVVM Light en sí, es algo que ya existía de antes y que sirve para todo tipo de aplicaciones.

Pero vamos a aprovechar esta serie para meter aquí el artículo y así podamos hacer aplicaciones con buena arquitectura y localizados.

Pero antes que nada….

¿Qué es la localización?

Básicamente es el proceso de adaptar un software a un idioma concreto, por ejemplo, traduciendo sus textos y esto es precisamente lo que vamos a aprender aquí.

¿Cómo se hace eso? Pues el texto está escrito en el xaml y en los .cs…

Es muy fácil como veremos a continuación:

Para empezar, abrimos el proyecto del artículo de comandos, que como recordaréis lo dejamos en inglés a conciencia.

Ejecutamos el proyecto, rellenamos los campos y el resultado es como este:

Todo perfectamente en inglés.

¿Cual es el primer paso a la hora de localizar una aplicación?

Colocar todas las cadenas en un recurso aparte y nunca escribirlas directamente en el código.

Para ello creamos un nueva carpeta en nuestro proyecto llamada Resources, dentro creamos un nuevo item del tipo Resources File (O ficheros de recursos como me imagino que será en castellano).

A este fichero le vamos a poner de nombre Strings.resx. Si lo abrimos, vemos que tenemos 3 columnas en las que rellenar datos. En la primera va el identificador de la cadena, en la segunda irá la cadena en sí y en la tercera podemos poner un comentario que ayude a aquella persona que le toque traducir a saber en qué contexto estaba esa palabra (opcional).

Por ejemplo, imaginad que tenemos la siguiente cadena: “Choose Color” y la tenemos que meter en el fichero Strings.resx, pues básicamente sería algo del tipo:

ChooseColor – Choose Color – Color Picker window

O sea: identificador – cadena – comentario

Bueno, ya que sabemos como rellenar el fichero, voy a colocar la lista de todas las cadenas que estamos usando en la aplicación:

InsertName – Insert your name:
InsertAge – Insert your age:
Accept – Accept
Count – Count
Reset – Reset
Greeting – Hello, my name is {0} and Im {1} years old.
CountMessage – Greeting has {0} characters.

Como véis, hemos colocado aquí todas las cadenas tanto de los .xaml como de los .cs

NOTA: Solo se han de colocar aquellas cadenas que van a ser mostradas por pantalla (pues son las que nos interesan), aquellas cadenas como las de los RaisePropertyChanged pues no hay que meterlas ahí.

MUY IMPORTANTE: En la ventana de Strings.resx donde metéis todos los datos, arriba hay un combobox que pone: Modificador de acceso, tenéis que cambiarlo de internal a public. Además vais a tener que ir al fichero Strings.Designer.cs y ahi modificar el constructor cambiandole el modificador de acceso de internal a public. Además, tendrás que hacer estas 2 cosas cada vez que se guarde el fichero (por ejemplo al meter una nueva entrada). Esto es MUY importante y nada más que por esto merece la pena leer el tutorial.

Bien, este fichero contiene el idioma por defecto de la aplicación, esto quiere decir que si abrimos el programa en un windows ruso y no lo tenemos localizado al ruso, usará el lenguaje por defecto, en este caso, inglés.

Ahora bien, necesitamos quitar todas las cadenas de nuestro programa y sustituirlas por las que están en este fichero. ¿Cómo?

Para empezar necesitamos poder acceder a dicho recurso de forma global en todos los .xaml, y ya sabemos que para eso todo lo que definamos en App.xaml será global para todo fichero .xaml

Así que vamos a App.xaml y colocamos:

Un nuevo namespace:

xmlns:res="clr-namespace:EjemploMVVML.Resources"

Y ahora creamos una instancia del recurso:

Ésta linea la colocamos junto a la instancia del ViewModelLocator

Bien, ya que tenemos acceso a Strings en cualquier .xaml, vamos a empezar a sustituir las viejas cadenas de esta forma:

{Binding Source={StaticResource LocStrings}, Path=Identificador}

Por ejemplo, el primer label, el de insertar la edad:

Simplemente hemos sustituido la cadena escrita a mano por la que tenemos en Strings.resx

Ahora tienes que hacerlo con las demás cadenas que están en el .xaml (por simplificar el tamaño del tutorial no voy a pegar aqui el código, pero vamos, es algo mecánico.

Y bueno suponiendo que tenemos el .xaml listo con todo modificado, vamos a explicar como hacer esto mismo pero en C# para las cadenas de nuestras clases:

string cadena = Resources.Strings.Identificador;

¿Nada complicado verdad?

Así que nuestras dos propiedades del MainViewModel quedarían así:

Greeting = string.Format(Resources.Strings.Greeting,
	APerson.Name, APerson.Age);

CountMessage = string.Format(Resources.Strings.CountMessage, characters);

Ala, ya tenemos todo listo.

Normalmente cuando creamos una aplicación que soportará localización, metemos directamente todas las cadenas al Strings.resx para ahorrarnos trabajo

Bueno, ya tenemos todo listo. Así que lo que queda es añadir un nuevo fichero de recursos por cada lenguaje que vayamos a meter, cada fichero tendrá un nombre del tipo:

Strings.xx-yy.resx

Por ejemplo:

Strings.es-es.resx
Strings.en-us.resx
Strings.de-de.resx

Para nuestro ejemplo, creamos un fichero de recursos llamado Strings.es-es.resx junto a Strings.resx.

Este fichero es igual al anterior y se usa igual que el anterior. En este caso, la primera columna llevará los identificadores (los mismos que antes) y en la segunda la cadena pero ya en el idioma que estamos localizando:

InsertName – Introduce tu nombre:
InsertAge – Introduce tu edad:
Accept – Aceptar
Count – Contar
Reset – Reiniciar
Greeting – Hola, mi nombre es {0} y tengo {1} años.
CountMessage – El saludo tiene {0} caracteres.

Nada más, ahora si abrimos nuestro programa…

Nos sale totalmente en castellano, puesto que tenemos nuestro sistema operativo en castellano.

Así que sólo quedaría añadir un fichero por cada idioma que queramos soportar y nada más.

Os adjunto el proyecto (.NET 4):

EjemploMVVML.zip

Con esto doy por concluida la serie de artículos sobre Iniciación a MVVM Light.

Como ejercicio final os recomendaría echarle un ojo por encima a mi aplicación Apunta Notas ya que está escrita usando todo lo que aquí hemos aprendido y quizá os pueda solucionar muchas de las dudas que tengáis, aunque podéis preguntar en cualquier artículo las dudas que os hayan quedado.

Apunta Notas

Hasta la próxima.

MVVM Light: Messenger

admin — Wed, 24 Mar 2010 22:32:28 +0000

Y aquí estamos con la tercera parte de este artículo sobre MVVM Light.

En esta ocasión hablaremos sobre Messenger y no, no es el que usas para chatear con tus colegas, aunque la idea es parecida.

Antes de explicar en qué consiste lo de Messenger vamos a presentar ~~al concursante~~ el ejemplo.

El ejemplo es parecido al del anterior artículo, pero le hemos añadido una vuelta de tuerca más para mostraros otros conceptos nuevos.

El ejemplo se mantiene simple para no liaros con cosas que no tienen que ver con lo que vamos a explicar hoy.

Creamos una nueva aplicación MVVM Light para WPF, y añadimos la siguiente clase al modelo:

using System.ComponentModel;

namespace EjemploMessenger.Model
{
    public class Persona : INotifyPropertyChanged
    {
        private string _nombre;
        private int _edad;

        public Persona()
        {

        }

        public string Nombre
        {
            get { return _nombre; }
            set
            {
                _nombre = value;
                RaisePropertyChanged("Nombre");
            }
        }

        public int Edad
        {
            get { return _edad; }
            set
            {
                _edad = value;
                RaisePropertyChanged("Edad");
            }
        }

        #region INotifyPropertyChanged Members

        public event PropertyChangedEventHandler PropertyChanged;

        private void RaisePropertyChanged(string propertyName)
        {
            if (PropertyChanged != null)
            {
                PropertyChanged(
                    this,
                    new PropertyChangedEventArgs(propertyName)
                    );
            }
        }

        #endregion
    }
}

Hemos cogido prestada la misma clase que hemos usado en el anterior ejemplo, aunque ya están puesto las variables en castellano pues aunque sea buena practica hacerlo en inglés, este blog está en castellano y muchos no saben inglés.

La ventana quedaría así:

Ahora necesitamos crear otra ventana con su ViewModel. Creamos un ViewModel llamado EdadViewModel (Para ello al darle a añadir, nos saldrá la opcion de crear un nuevo MvvmViewModel directamente, así que seleccionamos esta opción). Luego creamos una ventana dándole a la opción MvvmView. A esta ventana le damos el nombre de EdadWindow.xaml y le añadimos el siguiente código:

Cada vez que añadamos un nuevo ViewModel a nuestro proyecto, deberemos añadir la referencia al ViewModelLocator, para ello abrimos la clase ViewModelLocator.cs y le damos a añadir nuevo snippet de código (o lo escribes a mano si quieres) y añades un ViewModelLocator property, luego lo modificamos para que quede así:

private static EdadViewModel _edad;

/// 
/// Gets the ViewModelPropertyName property.
/// 
public static EdadViewModel EdadStatic
{
	get
	{
		if (_edad == null)
		{
			CreateEdad();
		}

		return _edad;
	}
}

/// 
/// Gets the ViewModelPropertyName property.
/// 
[System.Diagnostics.CodeAnalysis.SuppressMessage("Microsoft.Performance",
	"CA1822:MarkMembersAsStatic",
	Justification = "This non-static member is needed for data binding purposes.")]
public EdadViewModel Edad
{
	get
	{
		return EdadStatic;
	}
}

/// 
/// Provides a deterministic way to delete the ViewModelPropertyName property.
/// 
public static void ClearEdad()
{
	_edad.Cleanup();
	_edad = null;
}

/// 
/// Provides a deterministic way to create the ViewModelPropertyName property.
/// 
public static void CreateEdad()
{
	if (_edad == null)
	{
		_edad = new EdadViewModel();
	}
}

Básicamente por cada ViewModel en el proyecto, necesitamos una referencia de éste en el ViewModelLocator, cada referencia consta de una instancia estática del ViewModel, una propiedad estática y otra normal de ésta, y un método para hacer una limpieza (como recordaréis, al crear un ViewModel, éste nos dá la posibilidad de hacer una limpieza una vez que deje de ser útil.).

Bueno, ya tenemos creado la primera parte del esqueleto de la aplicación, ahora sólo nos queda añadir código a cada ViewModel.

Antes de eso, quiero explicar el proposito de este ejemplo.

El ejemplo en sí es el mismo que el anterior, con tu nombre y edad forma un saludo. En este caso, no puedes introducir la edad directamente en la casilla, sino que tienes que introducirla en otra ventana aparte.

Antes de nada vamos a instanciar la clase Persona y vamos a crear la propiedad Saludo:

private Persona _unaPersona;
private string _saludo;

public Persona UnaPersona
{
	get { return _unaPersona; }
	set
	{
		_unaPersona = value;
		RaisePropertyChanged("UnaPersona");
	}
}

public string Saludo
{
	get { return _saludo; }
	set
	{
		_saludo = value;
		RaisePropertyChanged("Saludo");
	}
}

public MainViewModel()
{
	_unaPersona = new Persona();
}

Ahora, empezamos con el botón que nos permitirá usar la otra ventana. Para ello creemos un ~~evento~~ comando que haga precisamente eso:

public RelayCommand RecogerEdadCommand { get; private set;}

RecogerEdadCommand = new RelayCommand(RecogerEdad);

private void RecogerEdad()
{
	var edad = new EdadWindow();
	edad.ShowDialog();
}

Y bindeamos el botón al comando:

Con esto ya se abre la ventana, ¿Nada nuevo verdad? Simplemente instanciamos la ventana y la mostramos como un dialogo modal.

Vamos a escribir el código necesario en el EdadViewModel para recoger lo que escribamos y calcular nuestra edad, además crearemos el comando del botón y lo bindearemos, escribiré todo el código para simplificar, total, no es nada nuevo:

EdadViewModel

using System;
using GalaSoft.MvvmLight;
using GalaSoft.MvvmLight.Command;

namespace EjemploMessenger.ViewModel
{
    public class EdadViewModel : ViewModelBase
    {
        public int Dia { get; set; }
        public int Mes { get; set; }
        public int Año { get; set; }

        public RelayCommand CalcularEdadCommand { get; private set; }

        public EdadViewModel()
        {
            CalcularEdadCommand = new RelayCommand(CalcularEdad);
        }

        private void CalcularEdad()
        {
            var añoActual = DateTime.Now.Year;
            var mesActual = DateTime.Now.Month;

            var edad = añoActual - Año;

            if (Mes > mesActual)
                edad += 1;
        }
    }
}

Nada que deba sorprendernos.

EdadWindow.xaml

Aqui el código de la ventana, no he puesto ninguna validación (¿Material para otro artículo? , asi que vamos a suponer que introducimos los datos correctos). Además de eso, tenemos los bindings puestos y … ¿El botón tiene un comando y un evento a la vez? Sí. Puedes tener ambas cosas a la vez.

En este caso, necesito crear un evento en el botón para que haga algo relacionado con la ventana en sí y no con datos (O sea, trabajo para el code-behind en este caso). Lo lógico es que cerremos la ventana a la hora de hacer click, pero claro, no podemos hacer eso desde el ViewModel, así que necesitamos hacerlo en el code-behind. Así que el comando calcula la edad y el evento cierra la ventana.

private void OnAceptar(object sender, RoutedEventArgs e)
{
	Close();
}

Guay del paraguay, pero la edad está en EdadViewModel y la necesitamos en la instancia de Persona que está en MainViewModel. ¿Cómo la pasamos alli? ¿Cómo podemos hacer que MainViewModel obtenga la edad?

La solución más típica era la de crear un método en el code-behind de la ventana el cual nos devuelve lo que esa ventana a generado o directamente acceder a las propiedades.

Esta solución se ha usado mucho siempre, pero tiene un gran problema y es precisamente el que MVVM intenta resolver; el acople entre clases.

Si el método que abre la ventana necesita también saber como acceder a los datos que ésta genera, ya esas dos clases dependerían mucho la una de la otra.

Como solución a esto (y a otros muchos casos de este estilo) nació la clase Messenger. Ésta clase sirve para enviar mensajes de un lado a otro en una aplicación, de forma totalmente desacoplada.

La idea es que un objeto se registra para recibir mensajes de cierto tipo pero no sabe quien lo envia, simplemente espera dichos mensajes y nada más. Con esto conseguimos el buscado desacople.

Como se suele decir: Más vale un ejemplo que mil palabras ( ¿O eran imágenes? ):

¿Qué necesita recibir el MainViewModel para funcionar?, ¿La edad, no? ¿Qué tipo de variable es la edad? Un int.

Así que vamos a registrar mensajes que vengan con un int como parámetro. ¿Cómo se registra una clase para recibir mensajes?

Se usa el método estático Register de la clase Messenger:

void Register(object recipiente, Action action);

El primer parámetro es el objeto el cual se está registrando al mensaje, y el segundo es el método que se ejecutará cuando se reciba un mensaje

Vamos a registrar nuestro mensaje en el MainViewModel para que éste quede a la escucha de dichos mensajes, para ello escribimos en el constructor:

Messenger.Default.Register(this, edad => UnaPersona.Edad = edad);

Decimos que queremos escuchar todos los mensajes que traigan un int y que cuando recibamos uno, asignará el int que traiga consigo a la propiedad Edad de UnaPersona.

¿Fácil verdad?

Ahora falta que alguien los envié, y en este caso sería EdadViewModel. Para enviar mensajes se usa el siguiente método estático de la clase Messenger:

void Send(T message);

Simplemente el tipo de mensaje a enviar y el mensaje en sí.

Así que dentro del método CalcularEdad después del if ponemos:

Messenger.Default.Send(edad);

No debe sorprenderos, es bastante sencillo, enviamos edad a través de un mensaje.

Eso sí, este mensaje le llegara a TODOS los que estén escuchando mensajes que vengan con un int. En este caso da igual, pero si tenemos otras clases esperando mensajes también, pues puede liar. Así que tenemos acceso a otro tipo de método:

void Send(TMessage message);

Con ese método podemos especificar a quien queremos enviarle este mensaje, así que vamos a modificar nuestro ejemplo:

Messenger.Default.Send(edad);

Mejor

La clase Messenger es mucho más que eso, es capaz de intercambiar varios tipos de mensajes, normalmente para cosas más especificas. Vamos a mostrar otro tipo más de mensaje.

Antes de hacerlo, conviene pensar que quizá el ejemplo que ya he dado quizá no sea la mejor solución al 100%. La ventana de la Edad puede ser una ventana genérica usada por muchas partes de tu software, y si el mensaje que envía ya va dirigido a alguien en concreto, nos jodería el invento. Sin embargo, la clase que usa esa supuesta ventana genérica suele usar esa y no intercambiar con 20 más, quiero decir, debería quizá la clase que está usando dicha ventana ser la que especifique claramente a quien va a usar y dicha ventana ser genérica para que cualquiera pueda usarla y cualquiera pueda recibir sus mensajes.

¿Cómo hacemos eso?

A bote pronto podemos usar otro tipo de mensaje, NotificationMessageAction

Éste tipo de mensaje envía una notificacion y además espera que la clase que lo reciba le conteste.

Probemos:

En EdadViewModel registramos el mensaje, en este caso es un poco más complejo:

private NotificationMessageAction _message;

en el constructor:

Messenger.Default.Register>(
		this,
		m => _message = m);

y dentro de CalcularEdad:

_message.Execute(edad);

El mensaje del tipo NotificationMessageAction nos ofrece una forma de contestar a dicho mensaje, o sea, ejecutar el callback. Para ello necesitamos usar el método Execute de dicho mensaje, necesitamos hacer una copia del mensaje para poder acceder a dicho mensaje desde cualquier sitio de la clase.

Una vez tengamos el mensaje registrado y copiado, simplemente tenemos que ejecutar el método Execute para devolver el mensaje, en este caso, la edad.

Ahora bien, en la clase MainViewModel necesitamos enviar dicho mensaje y manejar el callback:

var edad = new EdadWindow();
Messenger.Default.Send(new NotificationMessageAction("Dame la edad", laEdad => UnaPersona.Edad = laEdad));
edad.ShowDialog();

Como veis, enviamos un nuevo mensaje del tipo NotificationMessageAction. Entre otras sobrecargas del método, tenemos una que recibe como primer parámetro el mensaje que queramos enviar (en este caso, la clase que recibe el mensaje no va a usar dicho mensaje, asi que le pasamos cualquier cosa) y como segundo parámetro recibe un delegado del tipo Action, usamos una lambda para que nos almacene la respuesta UnaPersona.Edad.

Así que la idea es: Enviamos mensaje > el recipiente lo recibe y almacena > cuando tiene la respuesta la envia > el que envió el mensaje recibe respuesta y hace algo con ella.

Bueno, con este tipo de mensaje conseguimos que EdadWindow pueda ser usada por otras muchas clases ya que ésta no sabe en ningun momento quien la usa, simplemente envia la edad como respuesta y bueno le da igual quien lo reciba o que haga con ello jeje.

Y bueno, se nos olvidaba que el programa tiene que enviar un saludo… Ya tenemos el nombre y podemos conseguir la edad, así que vamos a registrar el comando para el saludo, el cual es exactamente igual que el comando del articulo anterior:

public RelayCommand AceptarCommand { get; private set; }
[/csharp

[csharp]
AceptarCommand = new RelayCommand(Aceptar);

private void Aceptar()
{
	Saludo = string.Format("Hola, mi nombre es {0} y tengo {1} años.",
		UnaPersona.Nombre, UnaPersona.Edad);
}

Para terminar, os dejo la lista de mensajes que teneis y una descripción de ellos:

MessageBase: Es el mensaje simple, puede llevar informacion opcional del que envía el mensaje.
GenericMessage: Un mensaje simple que lleva una propiedad del tipo T.
NotificationMessage: Usado para enviar una notificación (un string) hacia un recipiente. Por ejemplo podemos guardar una lista de notificaciones en una clase y enviarlas a un recipiente.
NotificationMessage: El mismo mensaje que el anterior pero enviado además una propiedad del tipo T.
NotificationMessageAction: Permite enviar un mensaje a un recipiente y le permite a dicho recipiente contestar al mensaje.
NotificationMessageAction: Lo mismo que el anterior pero enviando además una propiedad del tipo T.
DialogMessage: Usado para pedirle a un recipiente (normalmente a una vista) que muestre un dialogo y notificar el resultado al que envió dicho mensaje. El recipiente puede mostrar cómo mostrar dicho dialogo, por ejemplo usando un MessageBox o un popup personalizado.

PropertyChangedMessage: Usado notificar a todo el mundo que una propiedad a cambiado (en la clase que envia dicho mensaje). Es lo mismo que usar el evento PropertyChanged solo que esto lo hace de una más simple.

Bueno, y dicho esto dejo por finalizado este artículo, adjunto el proyecto también:

EjemploMessenger.zip

Hasta la próxima

MVVM Light: Comandos

admin — Sun, 21 Mar 2010 18:44:16 +0000

Aquí vamos con la segunda parte del tutorial.

Para este tutorial vamos a crear un ejemplito muy muy simple pero que nos ayudará a entender los conceptos básicos que es lo que realmente buscamos.

Para empezar vamos a ir a la página de MVVM Light y bajarnos la última versión (la versión 3 a dia de hoy)

Página de MVVM Light

Que no os asuste la instalación, simplemente teneis que bajar los binarios y los templates para la versión de visual studio que estéis usando. Como extra también podéis bajar los snippets lo cual recomiendo.

Cuando bajeis los 3 ficheros, lo descomprimís y solo es copiarlo donde corresponde, nada dificil (Si teneis problemas dejadme un comentario).

Una vez tienes MVVM Light instalado vamos a crear una nueva aplicación MVVM Light para WPF (Para Silverlight o Windows Phone 7 sería lo mismo realmente).

El template de MVVM Light es bastante bastante completito, nos vienen los directorios que tenemos que usar (con la excepción de Views aunque no sé por qué) y además nos crea ya una ventana con su ViewModel asociado. Además de un diccionario de estilos (MainSkin.xaml) en el cual podemos meter nuestros estilos de la ventana.

Por último, nos crea un ViewModelLocator el cual instancia en el App.xaml. ¿Para qué sirve esto?

ViewModelLocator es el encargado de instanciar y mantener una referencia de cada ViewModel que existe en nuestra aplicación. Lo cual nos da ciertas ventajas, entre ellas poder asignar el DataContext de cada View en el xaml y no mediante código, lo cual nos permitirá diseñar nuestra aplicación en tiempo de diseño sin hacer ninguna floritura extra.

Ya en la próxima parte os explicaré como añadir más ViewModels al ViewModelLocator así que por ahora vamos a ignorarlo y seguir adelante.

Empezamos borrando el MainSkin.xaml puesto que no lo vamos a usar en este simple ejemplo.

Creamos en el modelo una clase llamada “Person” y le pones este código:

using System.ComponentModel;

namespace EjemploMVVML.Model
{
    public class Person : INotifyPropertyChanged
    {
        private string _name;
        private int _age;

        public Person()
        {

        }

        public string Name
        {
            get { return _name; }
            set
            {
                _name = value;
                RaisePropertyChanged("Name");
            }
        }

        public int Age
        {
            get { return _age; }
            set
            {
                _age = value;
                RaisePropertyChanged("Age");
            }
        }

        #region INotifyPropertyChanged Members

        public event PropertyChangedEventHandler PropertyChanged;

        private void RaisePropertyChanged(string propertyName)
        {
            if (PropertyChanged != null)
            {
                PropertyChanged(
                    this,
                    new PropertyChangedEventArgs(propertyName)
                    );
            }
        }

        #endregion
    }
}

Como veis está en inglés puesto que luego vamos a usar este ejemplo en el artículo de localización, además es una MUY buena practica escribir todo el código en inglés (variables, comentarios, clases, todo).

Esta clase implementa INotifyPropertyChanged puesto que el modelo necesita notificar sus cambios de cara al DataBinding.

Normalmente yo suelo crear una clase llamada Notifier la cual implementa esta interfaz y luego heredo el modelo hereda de esta clase (siempre que no necesitemos heredar del modelo de otra clase y tengamos que implementar esta interfaz a mano como en el ejemplo).

Vamonos con la interfaz, os dejo el código, algo en plan rápido y guarrete ya que este artículo no tiene nada que ver con interfaces

Lo importante de aquí, es ver como se ha definido el DataContext en la ventana. Hemos cogido la referencia del ViewModel que nos interesa (el MainViewModel) desde el ViewModelLocator. ¿Chulo verdad?

Ahora vamonos al MainViewModel, uhm, ya tiene código por defecto… (Le he quitado algun comentario para simplificar el ejemplo):

using GalaSoft.MvvmLight;

namespace EjemploMVVML.ViewModel
{
    public class MainViewModel : ViewModelBase
    {
        public string Welcome
        {
            get
            {
                return "Welcome to MVVM Light";
            }
        }

        public MainViewModel()
        {
            if (IsInDesignMode)
            {
                // Code runs in Blend --> create design time data.
            }
            else
            {
                // Code runs "for real"
            }
        }

        ////public override void Cleanup()
        ////{
        ////    // Clean up if needed

        ////    base.Cleanup();
        ////}
    }
}

Cada ViewModel heredará de ViewModelBase el cual nos provee de ciertos helpers que nos facilitarán la vida. Por ejemplo dicho ViewModelBase implementa ya el INotifyPropertyChanged y además nos provee de un método en el cual podemos hacer limpieza en caso de que sea necesaria (Una especie de destructor).

Además tenemos una propiedad bastante util, IsInDesignMode y ya el constructor viene listo para usarlo. Simplemente podemos colocar código dentro de IsInDesignMode para hacer uso del “Design-time DataContext” (Revisar el artículo si quereis saber qué es esto) y luego el código real dentro del else.

Como ya sabemos usar el Design-time DataContext y no tiene nada que ver con MVVM Light, vamos a borrar eso y escribir directamente el código real.

Vamos a borrar el método Cleanup y borrar la propiedad “Welcome” y dejar solo el costructor vacío.

Para empezar vamos a crear una instancia de la clase Person.

Normalmente el instanciar una clase que va a ser expuesta a la vista necesita 3 pasos:

Crear la instancia:

private Person _aPerson;

Instanciarla en el constructor:

_aPerson = new Person();

y crearle su propiedad con notificación de cambios:

public Person APerson
{
    get { return _aPerson; }
    set
    {
        _aPerson = value;
        RaisePropertyChanged("APerson");
    }
}

Ya tenemos lista la instancia de Person para ser bindeada por la vista.

Vamos a bindear las 2 cajas (las de nombre y edad) a sus respectivas propiedades de la instancia de Person:

Nada nuevo aquí, solo hacemos los binding como estamos acostumbrados a hacer.

También vamos a necesitar bindear el tercer TextBox el cual contendrá un pequeño saludo.

Para ello creamos una propiedad en el ViewModel:

private string _greeting = string.Empty;

public string Greeting
{
    get { return _greeting; }
    set
    {
        _greeting = value;
        RaisePropertyChanged("Greeting");
    }
}

y bindeamos la tercera caja:

Ahora, si ejecutamos la aplicación…

Vemos que no hace nada, los botones no responden (¡Sorpresa!)

¿Cómo podemos solucionar esto?

Ah claro, creamos un evento por cada botón y asunto solucionado.

Pero… Habíamos dicho que todo el trabajo referente a datos se hacía en el ViewModel y no en el Code-Behind de la vista… Bueno, delegamos la acción al ViewModel desde el Code-Behind y ya está.

Vale, funciona, pero… ¿No es un poco guarrete esto que proponemos? Sí, sin duda.

WPF y Silverlight ofrecen algo más especializado para estas cosas que los propios eventos, ese algo se llama “Commands” o “Comandos” en castellano.

¿Qué ofrecen estos _Commands_ como ventaja frente a los eventos? Muchas. Las iremos viendo a lo largo del resto del artículo.

Para empezar, los comandos no se definen en el Code-Behind, sino directamente en el DataContext, que en nuestro caso es en el MainViewModel. Con esto, nuestro código será mucho más limpio puesto que no tenemos que delegar el trabajo desde el Code-Behind y asi dejamos a éste para lo que realmente está, para hacer todo lo referente a la vista y no a los datos.

Así que vamos al lío.

¿Cómo se crea un comando?

Originalmente quizá crear un comando no era tan facil como crear un evento, pero gracias a la comunidad tenemos unas clases que harán que crear comandos sea incluso más facil que crear eventos.

MVVM Light incluye una de esas clases, RelayCommand

Usar un RelayCommand es lo más facil del mundo, empezamos por crear el comando en sí como una propiedad autocompletada del MainViewModel:

public RelayCommand AcceptCommand { get; private set; }

Los comandos por convención incluyen la palabra Command al final.

Ahora creamos el comando en el Constructor:

AcceptCommand = new RelayCommand(Accept);

El constructor del RelayCommand recibe un delegado (Comunmente llamado el parametro Execute pues será el que ejecute código) del tipo Action el cual espera un método que no acepte parámetros y tampoco devuelva nada, así que le hemos pasado el método “Accept” al RelayCommand, así que vamos a crear dicho método (sin parametro y devolviendo void):

private void Accept()
{
	Greeting = string.Format("Hello, my name is {0} and Im {1} years old.",
		APerson.Name, APerson.Age);
}

Ya solo nos queda bindear el botón Accept al comando:

Tan fácil como esperabas

Ejecutamos la aplicación y… Funciona!

Vamos a crear ahora el comando para el botón reset, seguro que ya sabréis hacerlo por vosotros mismos…

public RelayCommand ResetCommand { get; private set; }

ResetCommand = new RelayCommand(Reset);

private void Reset()
{
	APerson = new Person();
	Greeting = string.Empty;
}

Creo que no harán falta las explicaciones aquí, ¿Verdad?

Ahora probemos una cosa… Abrimos la aplicación y le damos a Accept…

Uh, esto ya no mola tanto… ¡Ah! Ya lo tengo, pongo el botón como disabled y cuando rellene los dos textbox lo pongo enabled… Uhm, la idea es buena, pero… ¿Cómo lo implemento? Podría crear unos eventos que comprobaran que los textbox tienen información y luego desbloquear el botón o algo. Nah, muy dificil, mejor compruebo a la hora de hacer click de que haya info, en caso de no haberla que suelte un MessageBox diciendo que has de rellenar las cajas o mejor, no hago nada, se supone que si no escribes algo no va a valer.

Bueeeno, vamos a hacerlo bien, que lo importante en una aplicación con interfaces es la experiencia de usuario (UX).

Los comandos tienen la capacidad de saber cuando pueden ser ejecutados y cuando no. La forma que tienen de avisar de que no pueden ser ejecutados es simplemente bloqueando el control (¡Justo lo que queremos!).

Para ello, RelayCommand acepta otro delegado (éste comunmente llamado CanExecute), en este caso del tipo Func el cual no acepta ningun valor y a la vez devuelve un bool, el cual si es true el comando se puede ejecutar y si es false, pues lo contrario.

Antes que nada, necesitamos una forma de comprobar si los atributos de la clase están “rellenos” o no, para ello vamos a implementar una pequeña propiedad en la clase Person:

public bool IsValid
{
	get
	{
		return _name != string.Empty && _age > 0;
	}
}

Vamos a modificar nuestro AcceptCommand

En el constructor lo cambiamos por:

AcceptCommand = new RelayCommand(Accept, CanAccept);

La convención también suele decir que los métodos para comprobar si un comando se puede ejecutar o no van prefijados por Can.

Ahora escribámos el método:

private bool CanAccept()
{
	return APerson.IsValid;
}

Si ejecutamos el código, vemos que el botón Accept está bloqueado:

Para desbloquearlo deberemos rellenar los 2 textboxes primero.

NOTA: Por defecto el binding se hace cuando el campo pierde el foco, así que hasta que no le quitemos el foco a la ultima caja que rellenemos, no se activará el control. Esto puede ser modificado cambiando el modo del binding a PropertyChanged.

Una de las cosas buenas de los RelayCommands es que aceptan un delegado, y en este caso el CanAccept es simplemente una linea…

Así que vamos a borrar el método CanAccept entero y vamos a modificar la inicialización del RelayCommand para que reciba una lambda:

AcceptCommand = new RelayCommand(Accept, () => APerson.IsValid);

Te quitas 4 líneas de encima.

Vamos a meterle una nueva feature a la aplicación, una que nos diga el número de caracteres que tiene el saludo.

Vamos a la vista y debajo del bóton reset insertamos:

Nada extraño, bueno, código feo de Blend, pero no nos preocupa eso para el tutorial (pero si para nuestras aplicaciones reales ehh )

¿Cómo vamos a contar los carácteres del mensaje? En el mundo real simplemente bindeariamos la nueva caja a “Greeting.Length” y asunto solucionado, pero como esto no es el mundo real y sí un artículo de aprendizaje, vamos a usar otro método el cual nos será util para otras muchas cosas en dicho mundo real

Los comandos nos permiten la posibilidad de enviar un parámetro con ellos, así que vamos a aprovechar eso para enviar el numero de caracteres directamente sacado del textbox del Greeting.

Para ello empezamos dandole un nombre a dicho TextBox:

Ahora nos vamos con la creación del comando:

public RelayCommand CountCommand { get; private set; }

Como veis, ahora usamos una versión genérica del RelayCommand que acepta un parámetro pero…. ¿Por qué int? y no un int normal?

Atención a esto, ya que probablemente esto solo sea suficiente para leer el artículo.

El RelayCommand va a intentar comparar el parámetro con null, un tipo primitivo no puede almacenar null, así que comparar un int contra null dará una preciosa excepción la mar de maja.

Entonces existen versiones nullables de los tipos primitivos, para usar esos tipos hay que colocar la interrogación detrás del tipo, int?, double?, bool?, etc.

Con decir que yo pasé horas investigando esto e incluso terminé reescribiendo parte de la clase para que no reventara… Oye, ya no hacía falta pasarle ningún nullable, pero vamos, ya que se como va, os lo explico bien

Pasemos a lo siguiente, inicializar el comando:

CountCommand = new RelayCommand(Count, noused => Greeting != string.Empty);

¿Qué es eso de noused? El parámetro que pasamos con el comando lo recibirá tanto el “Execute” como el “CanExecute” y en este caso, el “CanExecute” no necesita para nada ese parámetro, aun asi, tiene que recibirlo, asi que le pongo de nombre “noused” para dar a entender que no lo necesitamos. Aparte de eso, comprobamos que ya se haya creado el mensaje del greeting para activar el botón.

Antes de implementar el método Count necesitamos una propiedad donde alojar el mensaje con el numero de caracteres, tal y como hicimos con la propiedad Greeting:

private string _countMessage = string.Empty;

public string CountMessage
{
	get { return _countMessage; }
	set
	{
		_countMessage = value;
		RaisePropertyChanged("CountMessage");
	}
}

y ahora la bindeamos a la caja:

Ahora vamos a crear el método “Count”:

private void Count(int? characters)
{
	CountMessage = string.Format("Greeting has {0} characters.", characters);
}

Lo unico que queda es bindear el comando al botón:

¿No es difícil verdad? Hacemos uso de CommandParameter para enviar un parámetro, en este caso el numero de carácteres del textbox “Greet”.

Todavía queda algo más. No todos los controles implementan comandos y normalmente estos comandos son ejecutados cuando haces click en el control. No siempre va a ser eso lo que necesitas y muchas veces directamente no vas a tener opción a ningun tipo de comando. Así que en vez de tirar de eventos, podemos usar una librería que trae MVVM Light, EventToCommand, con esta librería podemos “transformar” cualquier evento a un comando.

Para evitar hacer más complejo el ejemplo, vamos a suponer que los botones no tienen comandos y queremos transformar su evento “Click” en un comando.

Para ello tenemos que importar estos namespaces en nuestra ventana:

xmlns:i="clr-namespace:System.Windows.Interactivity;assembly=System.Windows.Interactivity"
xmlns:cmd="clr-namespace:GalaSoft.MvvmLight.Command;assembly=GalaSoft.MvvmLight.Extras.WPF4"

NOTA: Si estais usando Visual Studio 2008 con WPF3.5 has de cambiar uno de los namespaces:

xmlns:cmd="clr-namespace:GalaSoft.MvvmLight.Command;assembly=GalaSoft.MvvmLight.Extras"

Bueno, ahora nos vamos a un botón cualquiera (por ejemplo reset) y lo dejamos así:

No es tan complejo, ¿no? Hemos seleccionado el tipo de evento que estará bindeado al comando y luego hemos dicho cual es el comando No hemos tenido que modificar el ViewModel siquiera.

Esto suele venir bien por ejemplo para ejecutar un comando cada vez que seleccionas un elemento en un ListBox, ya que SelectionChanged no puede ser bindeado a un comando por defecto.

Y bueno, hasta aquí la explicación de comandos, más largo de lo que esperaba, y espero que no se olvide nada.

Os dejo un zip con el código fuente (Visual Studio 2010) para los que no queráis hacerlo mientras lo leeis (¡Mal! )

Código fuente

Espero vuestros comentarios (que va a ser que no habrán) y nos vemos en la próxima parte.

MVVM Light: ¿Qué es?

admin — Sat, 20 Mar 2010 18:30:59 +0000

Empezamos con la primera parte de la serie de artículos de MVVM Light, en concreto con la gran pregunta:

¿Qué es exactamente MVVM o MVVM Light?

Vamos a empezar explicando qué es MVVM:

MVVM es un patrón de diseño que entra dentro de los llamados patrones mv* como podrían ser:

Ambos son patrones muy usados a la hora de crear la arquitectura de la aplicación. De MVP ya hemos hablado en otro artículo y bueno, MVVM es una alternativa mejor a la hora de desarrollar aplicaciones tanto WPF, Silverlight y Windows Phone 7.

Antes de entrar en explicaciones concretas, os dejo un diagrama que os ayudará a entender las cosas:

Como podéis ver aquí, existen tres componentes en este patrón: Model-View-ViewModel, osea, MVVM.

En el Modelo irá toda la lógica de negocio de nuestra aplicación, como podría ser la clase Libro, Persona, Factura… Este tipo de clases tambien son llamadas POCO’s (Plain Old C# Objects), o sea, clases básicas sin ninguna funcionalidad de WPF ni Silverlight.

El ViewModel como su nombre indica, es el modelo de la vista, o dicho de otra forma, es donde irá todo el trabajo que la vista necesita hacer. Si tomamos como ejemplo mi ApuntaNotas, el ViewModel se encargaría de añadir nuevas notas cuando el usuario hace click en el botón, borrar notas, renombrarlas, cambiarles la categoría… En resumen, el ViewModel hace todo el trabajo de la vista que tiene que ver con datos.

La Vista como cabe de esperar será la que contendrá el XAML de nuestra aplicación WPF, Silverlight o Windows Phone 7. Nada raro aquí.

Eso si, todo el mundo se pregunta… ¿Y el Code-Behind de la vista? ¿Vale para algo?

Por supuesto que sí, es un tema controvertido quizá, el code-behind en aplicaciones WinForms por ejemplo ha sido siempre usado para hacer todo el trabajo de la vista. Luego dijeron que eso estaba mal y decidieron delegar todo ese trabajo a un controlador y dejaron el code-behind inutil sin ningún uso.

En MVVM el code-behind es bastante usado, ¿Para qué exactamente? El code-behind lo usaremos para hacer todo el trabajo que tiene que ver con la vista en sí. ¿Recuerdas que dije que el ViewModel haría todo el trabajo de la vista relacionado con datos? Pues ahora el code-behind hace el trabajo restante, o sea, lo que tiene que ver exclusivamente con la vista.

Por ejemplo… Imaginad que si seleccionamos un elemento de un ListBox queremos que cierto TextBox coja el foco; esto es cosa de la vista en sí, no tiene que ver con datos ni nada así que el mejor lugar para hacerlo es el code-behind.

Explicandolo de otra forma que quizá os quede más clara:

Tenemos una aplicación para mostrar una serie de resultados que extraemos de una base de datos.

Para ello tenemos un ViewModel que extrae esos datos del modelo, y prepara esos datos para que una vista pueda usarlos. El ViewModel en sí no sabe nada acerca de las vistas, éste simplemente tiene un conjunto de propiedades para que una vista pueda hacer DataBinding a ellas (como podeis ver en el diagrama de antes). A este ViewModel podemos asignarle cualquier numero de vistas que queramos y dichas vistas representará esos datos como quiera.

Entonces imaginemos que una de esas vistas representará esos datos usando graficas y esas graficas contendrán cosas como animaciones, por ejemplo dandole a un botón la grafica hace una animación chula para mostrar los datos. ¿Quien ha de hacer ese trabajo? Está claro que el ViewModel no, puesto que el ViewModel no sabe nada acerca de las Vistas que lo están usando y si tuviera que implementar cosas por cada vista que lo use, perdería ya el desacople, ¿no? Así que es el code-behind el que hace estas cosas puesto que son cosas que solo atañen a la vista y nadie más.

Hasta aquí es básicamente MVVM, queda algo importante que contar, los comandos, pero eso lo dejaré para la próxima parte donde ya pondré un ejemplillo para que todo esto quede bien claro

Introducción a MVVM Light: Índice

admin — Sat, 20 Mar 2010 18:25:36 +0000

Voy a escribir un artículo de introducción al patrón MVVM y en concreto usando MVVM Light.

Voy a dividir este artículo en varias partes para no agobiar al lector con un artículo muy largo.

Nos vemos en la primera parte

Expression Blend 4 Beta y Silverlight 4 RC

admin — Tue, 16 Mar 2010 11:57:09 +0000

Los que usamos Visual Studio 2010 RC estamos de enhorabuena.

La release de Visual Studio 2010 RC tenia 2 grandes puntos negros:

Silverlight 4 Beta no funcionaba en VS 2010 RC sabes dios por qué, la cosa es que nos dijeron que esperasemos a una nueva release de Silverlight, y claro, ahora que estos días es el MIX 2010 pues han aprovechado para anunciar Silverlight 4 RC el cual es compatible con el último VS.

Os dejo aquí el enlace de la descarga:

Herramientas de Silverlight 4 para Visual Studio 2010

SDK de Silverlight 4

Silverlight toolkit (Opcional)

Por otro lado había una Preview de Blend 3 con soporte para WPF 4 y Silverlight 4, pero esta preview dejó de funcionar con Visual Studio 2010 RC así que sólo tocaba esperar para una versión con soporte que según los desalladores, saldría pronto y claro han aprovechado el MIX 2010 también. Así que ahora tenemos Blend 4 Beta disponible para todos

Blend 4 Beta

Y por favor, no seais tan tontos como yo que me volví loco con la key que pide… Solo has de hacer click en el enlace que os da el instalador cuando os pide la key, ahí podeis crear una.

Por último, han sacado un add-in para Windows Phone 7 para Blend 4 y aunque el telefono no está en la calle, trae un emulador por si quiereis ir probando:

Paquetes necesarios

Un saludo.

Silverlight & HTML & Apache

admin — Fri, 24 Jul 2009 13:56:26 +0000

Buenas!

Mucha gente piensa, de hecho, yo también lo pensaba en su día, que para poder usar Silverlight necesitaríamos un servidor Windows corriendo IIS y una aplicación web usando ASP.NET.

Investigando descubrí que podía embeber una aplicación Silverlight dentro de un simple HTML. Gracias a esto, podemos embeber dicha aplicación en cualquier tipo de página, ya sea PHP u otra cosa.

No solo eso, si no que podemos correr dicha página web bajo un servidor Apache ya sea en Windows o Linux. Ahora te surgirán las dos típicas preguntas: ¿Cómo?, ¿Por qué funciona?. Paso a contestarlas:

¿Por qué funciona en algo que no sea Windows e IIS?

Silverlight no se ejecuta en el servidor, Silverlight se ejecuta en el cliente, es un plugin del navegador, así que somos nosotros quienes necesitamos tener Silverlight instalado.

Así que al ser nosotros quienes ejecutemos la aplicación, el servidor simplemente necesita conocer los ficheros de Silverlight y nada más.

¿Cómo lo hago?

Tendremos que modificar el fichero .htaccess e insertar estos MimeTypes:

AddType application/x-silverlight-app xap
AddType application/x-silverlight-2 xap

Realmente con uno nada más funciona, pero mejor insertamos ambos y nos quitamos de tener que editar luego el html para cambiar el MimeType.

Y bueno, ya que estamos, podriamos insertar todos estos:

AddType application/x-ms-application application
AddType application/x-ms-manifest manifest
AddType application/octet-stream deploy
AddType application/vnd.ms-xpsdocument xps
AddType application/xaml+xml xaml
AddType application/x-ms-xbap xbap
AddType application/x-silverlight-app xap
AddType application/x-silverlight-2 xap

Con todos estos, podremos hacer uso del ClickOnce que nos ofrece el Visual Studio para distribuir nuestras aplicaciones de forma más comoda, en este caso, desde nuestra web.

Y nada más, con esto ya podemos usar alojar nuestra aplicación Silverlight en un servidor Linux con Apache.

Vale, y… ¿Ahora como incrusto la aplicación en el HTML?

Más facil todavía.

Si creamos una aplicación Silverlight en el Visual Studio, nos dará la opción de crear un proyecto ASP.NET, pero si le decimos que no, nos creará un .html básico con el objeto ya embebido.

Básicamente, al compilar una aplicación Silverlight, se creará un fichero .xap que no es más que un .zip que contiene los ficheros .xaml, los dll necesarios… Vamos, algo parecido a los .jar de Java.

Ahora con este .xap, solo necesitaremos embeberlo en el .html usando un código como este:

Con esto, dentro de ese div tendremos nuestra aplicación Silverlight embebida.

Esto sería un ejemplo completo de página HTML que contiene simplemente el Silverlight.




    SilverlightApplication1

Con el CSS ajusto el tamaño de la aplicación Silverlight. Imagino que no será la mejor forma para hacerlo, pero todavía estoy verde con la programación web

Ejemplo de aplicación Silverlight embebida aquí en el artículo

Eso es todo amigos.