WPF

Una vez instalado el entorno de desarrollo vamos a tratar de hacer alguna pequeña, muy pequeña, aplicación, aunque antes de nada vamos a ver que tipos de aplicaciones podemos desarrollar. Para ello abriremos Visual Studio 2005 y ejecutaremos la opción “Nuevo proyecto”. Seleccionamos el nodo de nuestro lenguaje de programación, debiendo tener en cuenta que hasta la fecha WPF únicamente soporta Visual Basic y C#, para más tarde seleccionar el nodo “.NET Framework 3.0”.

Para Visual Basic:

Para C#:

Las opciones disponibles son tres:

1) Windows Application (WPF).
Aplicación Windows convencional.

2) XAML Browser Application (WPF).
Aplicación Web que por defecto visualizará sus propios botones de navegación.

3) Custom Control Library (WPF).
Control gráfico de usuario.

La importancia de Cider
Vamos a ver algo más. Seleccionaremos la plantilla correspondiente a “Windows Application (WPF)”, indicaremos un nombre de proyecto, como por ejemplo “Ejercicio001” y pulsamos “Aceptar”. Nos hayamos frente al lienzo de WPF, aunque llegado éste momento, nos podemos encontrar con que la versión de Visual Studio 2005, a la que hasta el momento nos hemos referido de forma genérica, adopte un grado de importancia relevante, dado que no es lo mismo trabajar sobre un lienzo en modo gráfico que en modo texto XML. A la fecha Visual Studio 2005 Express no dispone de Cider, el editor gráfico de XAML, algo que para iniciarse en WPF no es fundamental, pese a que nos puede servir de ayuda en determinados momentos. Por nuestra parte vamos a darle un enfoque orientado a conocer los entresijos de XAML, con lo que Cider tendrá una importancia relativa que se puede resumir en que, mientras los usuarios de versiones de pago de Visual Studio 2005 no necesitarán ejecutar la aplicación para poder ver el aspecto de la misma, ya que podrán alternar mediante pestañas entre las vistas de diseño y de código, los usuarios de la línea Express deberán lanzar la aplicación para visualizar los resultados, al menos de momento. Aspecto del editor Cider:

La primera aplicación
Si no usamos una versión Expressnos hayamos ante un formulario Windows convencional, y deberemos pulsar sobre la pestaña “XAML” ubicada bajo éste. En caso de usar una versión Express ya nos encontraremos ante el siguiente código:

<Window
x:Class=“Ejercicio001.Window1″

xmlns=“http://schemas.microsoft.com/winfx/2006/xaml/presentation”

xmlns:x=“http://schemas.microsoft.com/winfx/2006/xaml”

Title=“Ejercicio001″
Height=”205″ Width=”281″>

<Grid>

</Grid>

</Window>

Obviamente el código será exactamente el mismo independientemente del lenguaje de programación seleccionado, ya que XAML describe interfaces de usuario independientemente de la plataforma y del lenguaje de programación.
No debemos olvidar que XAML no es un lenguaje de programación, y que el comportamiento del programa vendrá condicionado por código escrito en VB o C#.

Si ejecutamos la aplicación el resultado no es otro que un formulario Windows convencional, sin ninguna diferencia con
el Windows Form de toda la vida.

Revisando el código inicial
Con el código XAML generado automáticamente podemos distinguir los dos primeros TAGS, <Window> y <Grid>. Mientras que <Window> define un formulario Windows al que como veremos se le asignan una serie de propiedades que iremos conociendo en un futuro, <Grid> define una tabla, en este caso de una columna y una fila, en la que ubicar más controles. La definición de la tabla no es indispensable para ejecutar el formulario, de hecho podemos eliminar el tag <Grid> y ejecutar de nuevo la aplicación obteniendo idénticos resultados, aunque como veremos pronto, la tabla nos será de gran utilidad.

Nota importante: Los tags XAML son case-sensitive, es decir, distinguen entre mayúsculas y minúsculas.

Paralelamente al código XAML, contenido en el archivo “Window1.xaml”, se ha generado un archivo con código Visual Basic o C#, “Window1.xaml.vb” o “Window1.xaml.cs”.

Window1.xaml.vb:

‘
Interaction logic for Window1.xaml

Partial
Public Class Window1

Inherits
Window

Public
Sub New()

InitializeComponent()

End
Sub

End
Class

Window1.xaml.cs:

using System;

using System.Collections.Generic;

using System.Text;

using System.Windows;

using System.Windows.Controls;

using System.Windows.Data;

using System.Windows.Documents;

using System.Windows.Input;

using System.Windows.Media;

using System.Windows.Media.Imaging;

using System.Windows.Shapes;

namespace Ejercicio001

{

/// <summary>

/// Interaction logic for Window1.xaml

/// </summary>

public partial class Window1 : Window

{

public Window1() { InitializeComponent(); }

}

}

NOTA: Para ver los archivos anteriores en las versiones Express de Visual Studio 2005 emplearemos el
Explorador de soluciones (Importante activar la opción de ver todos los archivos).
Este archivo contiene la lógica de la interfaz, es decir, lo que vas más allá de la definición de los
elementos que la componen. Esta lógica se asocia mediante las mismas técnicas empleadas en ASP.NET 2.0, el codebehind
y las clases parciales. Mientras que en el archivo XAML definía el tipo y el nombre de la clase:

<Window x:Class=“Window1″

En el archivo VB o C# definiré la respuesta a los eventos que se produzcan en las instancias de la clase, separando físicamente, gracias a las clases parciales, la definición por un lado y el comportamiento por otro.

El toque personal

Dado que hasta el momento nos hemos conformado con la funcionalidad básica de un formulario, vamos a ponerle nuestro pequeño grano de arena, añadiendo un control y asociando un evento al mismo. En el formulario dibujaremos
un botón que contenga el texto “Adiós mundo cruel” que al ser pulsado cierre la aplicación.

Primero nos encargaremos del aspecto, consistiendo únicamente en añadir el botón. Para ello editaremos el archivo XAML del siguiente modo:

<Window x:Class=“Window1″

xmlns=“http://schemas.microsoft.com/winfx/2006/xaml/presentation”

xmlns:x=“http://schemas.microsoft.com/winfx/2006/xaml”

Title=“Ejercicio001″
Height=”300″ Width=”300″>

<Grid>

<Button>Adiós mundo cruel</Button>

</Grid>

</Window>

Con el tag <Button> definimos un botón dentro de la tabla, que si no le decimos lo contrario
ocupará todo el espacio de la misma. Si ejecutamos la aplicación evidentemente tendremos resuelto el tema visual
pero el botón no ejecutará ninguna acción. Para que el botón ejecute código escrito por nuestra parte, necesitaremos asociar un fragmento de código a un determinado evento del botón, en este caso, el evento Clic.

Volvemos a editar el código XAML del siguiente modo:

<Window
x:Class=“Window1″

xmlns=“http://schemas.microsoft.com/winfx/2006/xaml/presentation”

xmlns:x=“http://schemas.microsoft.com/winfx/2006/xaml”

Title=“Ejercicio001″
Height=”300″ Width=”300″>

<Grid>

<Button
Click=“Adios”>Adiós
mundo cruel</Button>

</Grid>

</Window>

Ahora sí tenemos la interfaz acabada, aunque si ejecutamos el código en éste momento obtendremos un sonoro error, dado que el compilador no encontraría la definición del método “Adios”. Vamos a crearlo usando VB o C#:

Visual Basic:

‘
Interaction logic for Window1.xaml

Partial
Public Class Window1

Inherits
Window

Private
Sub Adios()

Me.Close()

End
Sub

Public
Sub New()

InitializeComponent()

End
Sub

End
Class

C#:

using
System;

using
System.Collections.Generic;

using
System.Text;

using
System.Windows;

using
System.Windows.Controls;

using
System.Windows.Data;

using
System.Windows.Documents;

using
System.Windows.Input;

using
System.Windows.Media;

using
System.Windows.Media.Imaging;

using
System.Windows.Shapes;

namespace
Ejercicio001

{

///
<summary>

///
Interaction logic for Window1.xaml

///
</summary>

public
partial class Window1 : Window

{

private
void Adios()

{

this.Close();

}

public
Window1()

{InitializeComponent();}

}

}

Tratamos ahora de ejecutar la aplicación. Seguimos estancados con otro error, debido a que cuando desde XAML definimos el método que gestiona el evento “Clic”, implícitamente se asignan al método indicado los parámetros necesarios para gestionar el evento. Para solventar el error, añadimos los parámetros pertinentes al método “Adios”.

Visual Basic:

Private
Sub Adios(ByVal
sender As Object, _

ByVal
e As System.Windows.RoutedEventArgs)

Me.Close()

End
Sub

C#:

private
void Adios(object
sender, EventArgs e)

{

this.Close();

}

Ahora sí, ejecutamos la aplicación, y al pulsar sobre el botón, la ejecución finaliza.

La importancia de llamar las cosas por su nombre
Una vez finalizado nuestro primer ejemplo, uno se queda con el regusto amargo de ver que hasta para algo tan simple como un clic de ratón tenemos que conocer y escribir todos los parámetros asociados al evento, algo que naturalmente resulta poco práctico.

Gracias a Jusep caí en la cuenta de lo torpe que había sido. Vamos a darle un nombre al botón y a quitarle la asociación que
habíamos realizado mediante la propiedad “Click”:

<Button Name=“btnCerrar”>Adiós mundo cruel</Button>

Gracias a éste pequeño cambio, ahora ya puedo ir al código y seleccionar el control y el evento a asociar usando únicamente el ratón:

Mucho mejor, ¿no? Aunque tiene una pega, después de asignar al control el nombre “btnCerrar”, no podremos seleccionarlo mediante el desplegable de controles hasta que no hayamos realizado alguno de los siguientes rupestres métodos:

• Recompilar la aplicación y cerrar para posteriormente abrir los archivos de definición de la ventana.
• Ejecutar la aplicación y cerrarla.

NOTA IMPORTANTE: Pese a que ya se ha liberado la versión definitiva de WPF, a la fecha Cider todavía se encuentra en versión CTP.

También cabe destacar un aspecto importantísimo del código anterior. Mientras que en el código visto hasta el momento, la definición del método “Adios” no contenía ninguna referencia al botón, ya que de hecho no podía al carecer el mismo de un nombre, ahora la relación entre código y control ya no se define en el código XAML mediante propiedades sino en el mismo
código de negocio, permitiendo así mayor independencia entre los perfiles de diseño y programación.

Visual Basic:

Private Sub btnCerrar_Click(ByVal sender As Object, _

ByVal e As System.Windows.RoutedEventArgs) _

Handles btnCerrar.Click

Me.Close()

End Sub

Es evidente que le queda mucho camino por recorrer a Cider aunque de momento nos conformaremos pensando en que todas estas penurias nos servirán para conocer mejor las tripas de WPF, algo que espero que en un futuro nos pueda servir para salir airosos de algún que otro desaguisado.

En otros posts he tratado el tema de Windows Presentation Foundation (en adelanet WPF) como un ente conceptual, sin detenerme en ningún aspecto práctico, ya que para ello quiero presentar primero a la estrella de WPF, XAML.

XAML es el lenguaje declarativo, basado en XML, mediante el cual definiremos las interfaces de usuario dentro de WPF. El nombre XAML, pronunciado al modo anglosajón como zamel, proviene de las siglas inglesas de eXtensible Application Markup Language, algo así como Lenguaje Extensible de Formato de Aplicaciones.

A día de hoy las especificaciones de XAML están ya finalizadas, dado que WPF ha sido ya lanzado dentro del nuevo .NET Framework 3.0.

¡Bienvenidos a XAML!

Desde los inicios de Windows Presentation Foundation, de cuando se le conocía con el nombre de Avalon, se encontró envuelto en un amasijo de opiniones que trataban de ubicarlo dentro del panorama actual que Microsoft ofrece, en otros posts anteriores he comentado el “qué” y el “por qué”, ahora le llega el turno al “dónde”, ya que las visiones de cómo encaja WPF han sido complejas al menos hasta hace muy poco. Pero vamos al tema.

Descubriendo las intimidades de Longhorn
Avalon (WPF) fue presentado como una de las principales novedades del nuevo sistema operativo de Microsoft, el Windows Vista (anteriormente conocido como Longhorn). Se trataba de un subsistema de Longhorn dedicado a la gestión de gráficos 2D/3D. En esas fechas, la visión de una tecnología que fusionara las herramientas de creación de interfaces de usuario era difusa.

El enfoque que se estaba dando a Vista a nivel de desarrollo, y que en la actualidad perdura (aunque lamentablemente de una forma más difuminada), no era otro que poder gestionar las entrañas del sistema operativo mediante código administrado y una exhaustiva jerarquía de objetos, que incluirían además de WPF a Windows Communication Foundation (anteriormente conocido como Indigo) y Windows Workflow Foundation entre otros (algunos como WinFs quedaron poro el camino). Las especificaciones de éste conjunto de subsistemas Windows requerían del .NET Framework 2.0 para ser utilizadas.

Llegados a éste punto las cosas más o menos cuadraban; Windows Vista admitirá una interfaz de componentes para ser gestionados desde el .NET Framework 2.0 que vendrán a suplantar las “maravillosas” llamadas al antiguo Win32.

WinFX se populariza
Mientras la pelota estaba en el terreno de Windows Vista el tema estaba ubicado en ese oscuro mundo de los Betas Testers, pero Microsoft estaba dispuesto a hacer llegar al máximo conjunto de gente sus “nuevas maravillas”, con lo que decide enmarcarlas todas en un paquete al que llama WinFX, y permite instalarlo en los tan populares Windows XP.
�
Fue aquí dónde nació la sombra de la duda. El programador de a pie empieza a plantearse lo que realmente es WinFX, y empiezan a coexistir dos corrientes de opinión a cual con más adeptos.

WinFX como ampliación del Sistema Operativo
Al instalar WinFX ampliamos las posibilidades que nos brinda el sistema operativo, para más tarde aprovecharlas desde el .NET Framework 2.0.

WinFX no es más que un Framework
WinFX es visto como un Framework que nos permite trabajar con el sistema operativo de forma mucho más cómoda. El nuevo Framework se gestionará mediante otro paralelo diseñado con propósitos más generalistas, el .NET Framework 2.0.

Framework sobre Framework = Nuevo Framework

La solución al conflicto se reveló el pasamos mes de Junio por parte de Microsoft, alineándose con la corriente de opinión que veía a WinFX como un Framework independiente, pero intentando por todos los medios posibles procurar no dejar del todo contento a nadie. Intentaré explicarme:

Dado que WinFX es admitido como Framework, la comunidad de desarrolladores empezaba a hacerse preguntas del tipo:

• ¿WinFX sustituirá al .NET Framework?
• ¿Qué Framework manda sobre el otro?

Y Microsoft responde con: WinFX + .NET Framework 2.0 = .NET Framework 3.0, es decir, las suma de Frameworks dan como resultado un nuevo y único Framework.

¿Qué es lo que no gusta? Pues el cambio de chip no ha sido del todo bien acogido por algunos. Pasamos de un .NET Framework dependiente de Windows, pero no orientado al mismo, a uno nuevo que se fusiona seriamente con el sistema operativo, poniendo en serio compromiso proyectos como Mono. (Ya hablaré de WPF y Mono, en breve…)

¿Marketing o coherencia?
En todo caso: ¡Bienvenidos al .NET Framework 3.0!

- Windows Presentation Foundation es el subsistema de Windows (librerías integradas en el sistema operativo), orientado a unificar los mecanismos de creación y gestión de interfaces de usuario. -

Si bien la respuesta a nuestra pregunta inicial, es al menos en apariencia sencilla, vamos a tratar de profundizar en Windows Presentation Foundation (en adelante WPF) para ver las implicaciones reales que conllevan la aparición de éste nuevo subsistema.

¿El por qué de WPF?

Como ya se ha anticipado en su definición, WPF nace con el propósito de unificar, y es que cuando hablamos de interfaces de usuario nos vienen a la cabeza tres escenarios o entornos muy concretos:

• Aplicaciones de escritorio.
• Aplicaciones Web.
• Aplicaciones para dispositivos móviles.

¿Es lo mismo plantearse una interfaz de usuario para correr en un escritorio Windows que para correr bajo un navegador Web? Es evidente que hace falta muy poca experiencia en la materia para poder contestar a esta pregunta, que por supuesto tiene como respuesta un rotundo NO, al menos hasta hace poco… La nueva filosofía que se nos plantea con herramientas como WPF radica en definir los elementos esenciales que deben componer la interfaz de usuario, delegando a un segundo paso la definición del aspecto de los mismos. Tanto los elementos como el aspecto se adaptará de la mejor forma posible al entorno en que se ejecute la aplicación, pero lo importante es que la definición usada será siempre la misma independientemente del escenario empleado.

Ejemplo 1:

Pongamos que tenemos que desarrollar una aplicación para mostrar las facturas de un determinado mes. Para ello decido que el elemento de una interfaz de usuario que se adapta mejor a mis necesidades es una tabla (grid). Defino la tabla en la aplicación y le asigno una apariencia visual con unos degradados muy resultones.

Ejecuto la aplicación en un entorno de escritorio. La tabla luce de maravilla mostrando sus magníficos degradados. Además por lo que parece he usado una tabla estupenda, por que sin escribir una sola línea de código puedo ordenar su contenido por una determinada columna haciendo un simple clic sobre la cabecera de una de ellas. Pero no sólo eso, si juego con la tecla “shift” puedo hacer ordenaciones compuestas, o puedo variar el orden de las columnas arrastrando las mismas con el ratón. Fantástico ¿no?.

Voy a ver ahora que tal corriendo la aplicación bajo un navegador Web: Pues la verdad es que muy bien también; Es fantástico. El aspecto es muy similar, aunque a simple vista puedo detectar algunos cambios como en la profundidad visual de las celdas, pero no hay duda que me ha conservado esos degradados tan estupendos que he seleccionado. Hago clic sobre una columna y me ordena el contenido de la tabla por dicha columna, ¡esto es perfecto! Aunque… ¡Vaya! No puedo hacer ordenaciones múltiples con la ayuda de la tecla “shift”, y ¿por qué no puedo arrastrar columnas? Vaya, no es oro todo lo que reluce…

Vale, pese a todo la cosa no va mal, vamos a ver que tal se muestra la aplicación bajo un dispositivo móvil: Efectivamente la tabla sigue estando, ¿pero que se ha hecho de esos degradados tan bonitos? ¿Por qué no puedo ordenar la tabla? En definitiva me doy cuenta de que la interfaz se ha empobrecido enormemente.

NOTA: Evidentemente se trata de un ejemplo orientativo que no pretende profundizar en lo que realmente se puede obtener de un determinado entorno (AJAX, etc.)

¿Qué trata de plasmar el ejemplo 1? Pues aparte de algo evidente como que el entorno de escritorio hasta la fecha es sin duda el que nos permitirá crear interfaces más ricas y complejas, es que debemos tratar de realizar interfaces usando las mismas herramientas independientemente del entorno o entornos donde pretendamos ejecutar nuestra aplicación. En el ejemplo anterior, mientras que diseñaría un formulario Windows con una tecnología muy concreta como puede ser Windows Forms para la aplicación de escritorio, para ejecutar bajo el navegador Web, voy a tener que redefinir por completo la interfaz, usando otra tecnología como puede ser ASP.NET. En resumen, doble trabajo, doble necesidad de conocimientos.

Ya puestos; Mejorando lo presente

Llegados a éste punto, si antes os habéis interesado por el tema de WPF, habréis podido comprobar que esta humilde introducción ha pretendido alejarse del enfoque habitual de lo que he podido leer hasta el momento, que muchas veces hace hincapié en la evolución histórica de las tecnologías usadas para crear interfaces de usuario, y en algo menos importante, sí, ¡WPF es lo que anteriormente se conocía como nombre en clave Avalon! (Buf… tenía que decirlo…)

El por qué yo he optado por resaltar otros aspectos es simple, entiendo poco de historia, me gusta ser práctico, y ya han incidido suficientemente otros, aunque si que me gustaría destacar algo que en su día dijo David Salgado en un Code Camp que pude ver a través de Internet, y que se podría resumir como que WPF viene a cubrir todo aquel espacio que hay entre los gráficos del Word y los del Halo.

La cita a David Salgado me servirá para reconducir mis palabras a las corrientes más populares, la que durante tiempo hemos estado observando con desánimo los que por desgracia tenemos que dedicar más tiempo a bases de datos que en maravillas no terrenales como DirectX. Se acabó apilar libros y libros de programación multimedia, WPF quizás no sea DirectX, pero las posibilidades multimedia que nos brinda harán las delicias a más de uno, con lo que sí, está bien, unifiquemos la forma de desarrollar las interfaces, pero ahora que las hemos fusionado, ¿porqué no vamos un paso más allá? ¿De qué nos sirve tener potentes tarjetas gráficas si ya no nos queda (al menos a algunos) tiempo para jugar? Simplifiquemos la forma de usar la tecnología que el hardware actual no brinda y abandonemos la ya antigua Win32API, ¡Bienvenidos a WPF!