Introducción a Windows Presentation Foundation

Septiembre de 2006

Publicado: 23 de Octubre de 2006

David Chappell
Chappell & Associates

Este artículo se aplica a:
Windows Vista
Windows Presentation Foundation
Microsoft .NET Framework 3.0

Resumen: el objetivo principal de Windows Presentation Foundation (WPF) es ayudar a los desarrolladores a crear interfaces de usuario eficaces y atractivas. Conozca el modo en que la plataforma unificada de WPF convierte a los desarrolladores en participantes activos en la creación de interfaces de usuario y proporciona un modelo de programación común para aplicaciones independientes y de explorador.

En esta página

Descripción de Windows Presentation Foundation Descripción de Windows Presentation Foundation
Presentación del problema Presentación del problema
Solución del problema: ventajas de Windows Presentation Foundation Solución del problema: ventajas de Windows Presentation Foundation
Uso de Windows Presentation Foundation Uso de Windows Presentation Foundation
Tecnología Windows Presentation Foundation Tecnología Windows Presentation Foundation
Aplicación de Windows Presentation Foundation Aplicación de Windows Presentation Foundation
Herramientas para Windows Presentation Foundation Herramientas para Windows Presentation Foundation
Windows Presentation Foundation y otras tecnologías de Microsoft Windows Presentation Foundation y otras tecnologías de Microsoft
Conclusión Conclusión
Acerca del autor Acerca del autor

Descripción de Windows Presentation Foundation

Por definición, es el personal técnico quien se preocupa más por la tecnología. El interés de muchos profesionales de software se centra, principalmente, en el modo de funcionamiento de las aplicaciones y no tanto en la forma de interacción que pueda darse entre éstas y los usuarios. Sin embargo, los usuarios (que, al fin y al cabo, son los que pagan) dan gran importancia a las interfaces. La interfaz de una aplicación constituye una parte fundamental de la experiencia global del usuario con el software particular. En lo que respecta a los usuarios, la aplicación es la experiencia. La experiencia mejorada de los usuarios mediante una interfaz optimizada puede contribuir al incremento de la productividad, a la generación de clientes leales y a una ampliación de las ventas en línea, entre muchas otras ventajas.

Los usuarios, que un día se conformaban con interfaces basadas en caracteres, ahora se han acostumbrado a las interfaces gráficas. No obstante, los requisitos que deben cumplir estas interfaces siguen aumentando. El uso de gráficos y componentes multimedia se ha hecho más generalizado. Además, la Web ha condicionado a una generación de usuarios que esperan obtener una interacción con software sencilla. La relevancia de las interfaces de las aplicaciones crece con el aumento del tiempo que los usuarios dedican a interacturar con las mismas. Para satisfacer las crecientes expectativas, la tecnología de creación de interfaces de usuario debe avanzar a la par.

El objetivo de Windows Presentation Foundation (WPF) es proporcionar estos avances en el entorno de Windows. WPF se incluye en la versión 3.0 de Microsoft .NET Framework y permite crear interfaces que incorporan documentos, componentes multimedia, gráficos bidimensionales y tridimensionales, animaciones, características tipo web, etc. Al igual que el resto de los componentes de .NET Framework 3.0, WPF estará disponible para Windows Vista, Windows XP y Windows Server 2003, y su lanzamiento está programado para que se produzca al mismo tiempo que Windows Vista. Este artículo sirve de introducción a WPF y ofrece una descripción de sus distintos componentes. El objetivo es aclarar los problemas que trata esta tecnología y analizar las soluciones que proporciona WPF.

Presentación del problema

A modo de ejemplo, tomemos un hospital que desea crear una aplicación nueva para facilitar el examen y la supervisión de los pacientes. Los requisitos de la interfaz de usuario que debe presentar esta nueva aplicación pueden incluir los siguientes:

  • Presentación de imágenes y texto sobre los pacientes.

  • Presentación y actualización de gráficos bidimensionales sobre las señales vitales de los pacientes (ritmo cardíaco, presión arterial, etc.).

  • Presentación de vistas y superposiciones tridimensionales de la información de los pacientes.

  • Presentación de vídeo para ecografías y otros diagnósticos que admita anotaciones por parte de médicos y enfermeras.

  • Posibilidad para el personal del hospital de leer y realizar anotaciones en los documentos de descripción de los pacientes y sus condiciones médicas.

  • Ejecución como aplicación de Windows para ofrecer una funcionalidad total a los empleados del hospital y en una aplicación del explorador web con restricciones de seguridad, con el fin de ofrecer un acceso más limitado a través de Internet al personal remoto.

Estos requisitos resultan ambiciosos, pero también son perfectamente razonables. Una interfaz de usuario capaz de presentar la información correcta de la forma adecuada y en el momento oportuno puede encerrar un valor comercial significativo. En una situación como la que ilustra el ejemplo anterior del sector sanitario, incluso puede salvar vidas. En escenarios no tan críticos, como pueden ser los relacionados con el comercio en línea y otras aplicaciones orientadas al consumidor, la capacidad de ofrecer al usuario una experiencia eficaz puede ayudar a las ofertas de una compañía a distinguirse de la competencia, así como a conseguir la mejora del nivel de ventas y del valor de la marca de la misma. Muchas aplicaciones actuales pueden beneficiarse de la inclusión de interfaces con gráficos, documentos, componentes multimedia y demás elementos característicos de una experiencia de usuario moderna.

Las tecnologías de 2006 hacen posible la creación de este tipo de interfaz en Windows; sin embargo, el proceso plantea un gran reto. Las dificultades principales incluyen las siguientes:

  • En la actualidad, se usan muchas tecnologías diferentes para el trabajo con gráficos, imágenes y vídeo. Puede resultar difícil y caro encontrar desarrolladores con experiencia en estas distintas tecnologías, al igual que lo es mantener las aplicaciones que crean.

  • El diseño de una interfaz capaz de ofrecer con eficacia toda esta funcionalidad a los usuarios resulta todo un reto. Hacen falta diseñadores profesionales (los desarrolladores de software no tienen los conocimientos necesarios), pero el trabajo conjunto de diseñadores y desarrolladores presenta retos importantes, sobre todo cuando se trata de interfaces tan completas como la descrita en nuestro ejemplo.

  • La posibilidad de ofrecer este tipo de interfaz como aplicación de escritorio de Windows independiente y como versión alojada en el explorador, requiere la creación de dos implementaciones distintas mediante el uso de dos tecnologías diferentes. Probablemente, la aplicación de escritorio de Windows se basará en Windows Forms y otras tecnologías nativas de Windows, mientras que la aplicación alojada en el explorador hará uso de HTML y JavaScript. Se necesitan dos grupos diferentes de desarrolladores con dos tipos de conocimientos bastante distintos.

La creación de interfaces de usuario eficaces y modernas no tiene por qué ser tan compleja. La introducción de una base común podría eliminar todos estos retos al ofrecer un enfoque unificado a los desarrolladores y permitir que los diseñadores jueguen un papel importante. Tal y como se describe a continuación, éste es precisamente el objetivo de WPF.

Solución del problema: ventajas de Windows Presentation Foundation

Tres aspectos de WPF destacan por su importancia. Son los siguientes: una plataforma unificada para interfaces de usuario modernas, la posibilidad para desarrolladores y diseñadores de trabajar conjuntamente, y una tecnología común para interfaces de usuario de Windows y explorador web. En esta sección se describen estos tres aspectos.

Plataforma unificada para interfaces de usuario modernas

Hasta la introducción de WPF, la creación de una interfaz de usuario de Windows como la descrita anteriormente requería el uso de varias tecnologías diferentes. En la siguiente tabla se presenta un resumen de la situación.

Windows Forms

PDF

Windows Forms/ GDI+

Windows Media Player

Direct3D

WPF

Interfaz gráfica, como formularios y controles

X

.

.

.

.

X

Documentos en pantalla

X

.

.

.

.

X

Documentos de formato fijo

.

X

.

.

.

X

Imágenes

.

.

.

X

.

X

Vídeo y audio

.

.

.

X

.

X

Gráficos bidimensionales

.

.

X

.

.

X

Gráficos tridimensionales

.

.

.

.

X

X

Para crear formularios, controles y otros aspectos típicos de una interfaz gráfica de usuario de Windows, probablemente, un desarrollador seleccionará Windows Forms, uno de los componentes de .NET Framework. En caso de que la interfaz deba mostrar documentos, Windows Forms ofrece cierta compatibilidad con documentos en pantalla, mientras que los documentos de formato fijo suelen ser PDF de Adobe. En el tratamiento de imágenes y gráficos bidimensionales, el desarrollador usará GDI+, un modelo de programación definido al que también se puede obtener acceso mediante Windows Forms. Para reproducir vídeo y audio, elegirá Windows Media Player y, en lo que respecta a gráficos tridimensionales, usará Direct3D, un componente estándar de Windows.

Esta situación tan compleja se debe exclusivamente a motivos históricos y no tiene mucho sentido. Lo lógico es contar con una solución única consolidada: WPF. Al crear aplicaciones para equipos que tengan instalada la aplicación WPF, lo más probable es que el desarrollador use esta tecnología para cubrir todos los aspectos mencionados. Después de todo, ¿por qué no usar una base coherente para la creación de interfaces de usuario en lugar de un conjunto variado de tecnologías independientes?

WPF no reemplaza todo lo incluido en esta lista, por supuesto. Las aplicaciones de Windows Forms conservarán su valor e, incluso en un entorno de WPF, algunas aplicaciones nuevas continuarán usando Windows Forms. Es importante recordar que WPF puede interoperar con Windows Forms, como se describe detalladamente más adelante en este artículo. Windows Media Player mantendrá su función independiente y se seguirán usando documentos PDF. Direct3D no perderá su gran valor tecnológico en juegos y otros tipos de aplicaciones. De hecho, WPF hace uso de Direct3D para todas las tareas de representación.

Sin embargo, al proporcionar una amplia gama de funciones en una sola tecnología, WPF simplifica de forma significativa la creación de interfaces de usuario modernas. Como ejemplo de lo que ofrece este enfoque unificado, a continuación se incluye una pantalla que podría formar parte de la aplicación basada en WPF para el sector sanitario descrita anteriormente:

Figura 1. Las interfaces de WPF permiten combinar imágenes, texto, gráficos 2D y 3D, etc.

Esta pantalla contiene texto e imágenes, además de gráficos bidimensionales y tridimensionales. La producción de la pantalla se llevó a cabo con WPF; el desarrollador no necesitó escribir código que requiere el uso de tecnologías de gráficos especializadas (por ejemplo, GDI+ y Direct3D). Del mismo modo, WPF permite la presentación y, en ocasiones, la anotación de vídeo, como se muestra en la secuencia de ecografía siguiente.

Figura 2. Las interfaces de WPF pueden incluir vídeo y permiten al usuario realizar anotaciones de texto.

Además, WPF permite mostrar documentos de forma legible. En la aplicación hospitalaria, por ejemplo, un médico puede consultar las notas sobre el tratamiento de un paciente específico o tener acceso a material de investigación médica actual sobre algún tema relevante. Asimismo, el médico puede realizar anotaciones, como muestra la pantalla a continuación.

Figura 3. Las interfaces de WPF pueden mostrar documentos con varias columnas, incluidas las anotaciones.

El documento se presenta en columnas legibles y el usuario puede consultarlo página a página, en lugar de hacer uso de la función de desplazamiento. Merece la pena mejorar la legibilidad en pantalla; éste es un objetivo importante de WPF. Aunque los documentos de formato fijo son tan útiles como los documentos en pantalla, con frecuencia puede resultar más adecuado usarlos. La apariencia en pantalla de este tipo de documento se conserva idéntica tras la impresión, por lo que los documentos de formato fijo ofrecen un aspecto estándar en cualquier situación. Microsoft ofrece XML Paper Specificatión (XPS) para definir este tipo de documento. WPF también proporciona a los desarrolladores un grupo de interfaces de programación de aplicaciones (API) para crear documentos XPS y trabajar con ellos.

No obstante, la creación de interfaces de usuario modernas va más allá de la unificación de tecnologías diversas. También consiste en aprovechar las ventajas que ofrecen las tarjetas gráficas modernas. De este modo, WPF puede transferir la mayor carga de trabajo posible a cualquier unidad de procesamiento de gráficos (GPU) disponible en el sistema. Una interfaz moderna tampoco debe verse limitada por las deficiencias de los gráficos de mapa de bits. Por esta razón, WPF usa únicamente gráficos vectoriales, lo que permite que las imágenes se ajusten automáticamente al tamaño y a la resolución de la pantalla en la que se muestran. En lugar de crear gráficos diferentes para la presentación en monitores pequeños y en pantallas grandes, el desarrollador puede dejar que WPF se ocupe de adaptarlos.

Gracias a la unificación en una misma base de todas las tecnologías necesarias para crear interfaces de usuario, WPF puede simplificar enormemente la labor de quienes crean las interfaces. Sólo tendrán que familiarizarse con un único entorno, por lo que WPF puede reducir el costo asociado a la creación y el mantenimiento de aplicaciones. Además, al facilitar la generación de interfaces que incorporan gráficos y vídeo, entre otros elementos, WPF puede mejorar la calidad (y el valor comercial) de la interacción de los usuarios con las aplicaciones de Windows.

Posibilidad para desarrolladores y diseñadores de trabajar conjuntamente

Es estupendo disponer de una base tecnológica unificada para crear interfaces de usuario completas. Pero quizás sea pedir demasiado que los desarrolladores sepan sacar el máximo partido de este entorno para crear interfaces completas y fáciles de usar. La creación de interfaces de usuario eficaces, en especial cuando se trata de interfaces globales como la descrita en nuestro ejemplo hospitalario, requiere a menudo conocimientos que muchos profesionales de software no tienen. Aunque resulta posible crear aplicaciones sin recurrir a esta experiencia, lo cierto es que para crear una gran interfaz de usuario, es necesario trabajar con diseñadores de interfaces profesionales.

Pero, ¿cómo conseguir que diseñadores y desarrolladores trabajen en equipo? La forma actual de interacción de estas dos disciplinas es problemática. Por lo general, el diseñador usa una herramienta gráfica para crear imágenes estáticas de los diseños de pantalla que debe mostrar una aplicación específica. A continuación, las imágenes pasan al desarrollador, quien se encarga de crear el código necesario para convertirlas en realidad. Sin embargo, para un desarrollador, puede ser muy complicado o incluso imposible implementar las imágenes que el diseñador dibuja tan fácilmente. Las limitaciones tecnológicas, las programaciones apretadas, la falta de conocimientos, los malentendidos o simples desacuerdos pueden hacer que el desarrollador no refleje completamente la visión del diseñador. Se necesita un método de trabajo mejorado que permita la colaboración estrecha del personal de estas disciplinas interdependientes, sin que esto influya de forma negativa en la calidad de la interfaz.

Con este fin, WPF incluye el lenguaje de marcado de aplicaciones extensible (XAML). El lenguaje XAML define elementos XML, como Button, TextBox, Label, entre muchos otros, para especificar exactamente la apariencia de las interfaces de usuario. Asimismo, los elementos XAML suelen disponer de atributos, lo que permite definir varias opciones. Por ejemplo, este sencillo fragmento de XAML sirve para crear un botón rojo que contiene la palabra "No":

<Button Background="Red">
 No
</Button>

Cada elemento XAML corresponde a una clase de WPF. A su vez, cada atributo de dicho elemento cuenta con una propiedad o evento correspondiente en la clase. Por ejemplo, es posible crear el mismo botón rojo con el código C# siguiente:

Button btn = new Button();
btn.Background = Brushes.Red;
btn.Content = "No";

Pero, si todo lo que puede expresarse en XAML, puede expresarse también en código, ¿para qué sirve XAML? Lo cierto es que resulta mucho más fácil crear herramientas que generan y usan descripciones basadas en XML, que usar código con la misma finalidad. XAML ofrece un método basado en herramientas muy sencillo para describir interfaces de usuario y, de este modo, permite una mejor colaboración entre desarrolladores y diseñadores. En la siguiente ilustración se muestra el proceso.

Figura 4. XAML permite a desarrolladores y diseñadores trabajar juntos.

Mediante el uso de una herramienta como Microsoft Expression Interactive Designer, el diseñador puede definir la apariencia y el modo de interacción de una interfaz de usuario. La herramienta, diseñada específicamente para la definición de la apariencia de interfaces de WPF, genera una descripción de la interfaz expresada en XAML. Aunque podría incluir un botón tan sencillo como el que se muestra en el ejemplo, en realidad, la descripción es mucho más compleja de lo que sugiere el fragmento de código anterior. Seguidamente, el desarrollador importa la descripción XAML en una herramienta como Microsoft Visual Studio. En lugar de volver a crear por completo la interfaz a partir de las imágenes estáticas generadas por el diseñador, la definición de la interfaz se adopta de forma sistemática. A continuación, el desarrollador escribe el código de la interfaz, como los controladores de eventos, junto con el resto de las funciones que requiera la aplicación. También es posible crear estilos aplicables globalmente a la interfaz de aplicación, lo que facilita su personalización para situaciones diferentes.

El trabajo conjunto de diseñadores y desarrolladores reduce los errores de traducción que suelen darse cuando los desarrolladores implementan interfaces a partir de las imágenes creadas por los diseñadores. Además, permite el trabajo en paralelo del personal de estas dos disciplinas. Como resultado, se obtienen iteraciones más rápidas y comentarios más eficaces. Otra ventaja es que ambos entornos usan el mismo sistema de creación, por lo que las aplicaciones de WPF pueden pasar de un entorno de desarrollo a otro sin complicaciones. Existen herramientas más especializadas para el diseño de interfaces definidas mediante XAML como, por ejemplo, ZAM 3D de Electric Rain, que permite crear elementos de interfaz tridimensionales.

Las interfaces de usuario mejoradas pueden incrementar la productividad; ofrecen un valor comercial apreciable. No obstante, la creación de interfaces verdaderamente efectivas, sobre todo en un entorno tan polifacético como el que presenta WPF, requiere la participación total y en primera instancia de los diseñadores. Uno de los objetivos principales de XAML y de las herramientas compatibles es convertir esta posibilidad en realidad.

Tecnología común para interfaces de usuario de Windows y explorador web

Es importante crear interfaces de usuario eficaces para las aplicaciones de Windows. Y la creación de interfaces eficaces para aplicaciones basadas en Web es, por lo menos, igual de relevante. Por definición, estas interfaces vienen proporcionadas por el explorador web y lo más sencillo es dejar que el explorador muestre de forma pasiva el código HTML que recibe. Las interfaces de explorador de mayor respuesta ofrecen ejecución lógica en JavaScript, para lo que pueden hacer uso de JavaScript y XML (AJAX) de forma asincrónica. Estas interfaces pueden incluso admitir animaciones, vídeo y muchos otros componentes mediante Flash Player de Adobe y otras tecnologías. Este tipo de software web, conocido a veces como aplicaciones de Internet enriquecidas, puede mejorar considerablemente la experiencia del usuario, ya que pone a su alcance interfaces de funcionalidad total. Además, puede incrementar el valor comercial al dotar de un mayor atractivo a las aplicaciones web.

Hasta ahora, la generación de este tipo de interfaz requería el uso de un conjunto de tecnologías totalmente distintas a las usadas en la creación de interfaces nativas de Windows. Por ello, los desarrolladores suelen centrarse en uno de los siguientes enfoques: si se trata de un desarrollador de interfaces de Windows o de un desarrollador de interfaces web. Sin embargo, ¿por qué debe existir esta dicotomía para las aplicaciones de Internet enriquecidas con acceso a través de Windows? No hay motivo inherente que impida el uso de las mismas tecnologías tanto para interfaces nativas de Windows como para interfaces de explorador web.

WPF ofrece esta posibilidad. Así, un desarrollador puede crear una aplicación XAML del explorador (XBAP) con WPF, que se ejecuta en Internet Explorer. De hecho, es posible usar el mismo código para crear una aplicación de WPF independiente y una XBAP. Como ejemplo, la pantalla a continuación muestra una aplicación de servicios financieros que se ejecuta como aplicación de Windows independiente. Al igual que la aplicación hospitalaria anterior, esta combina texto, imágenes y varios tipos de gráficos. Además, la pantalla muestra el escritorio de Windows Vista, con elementos como el reloj y el tema Aero, que proporciona los bordes semitransparentes de la ventana de la aplicación.

Figura 5. Una aplicación de servicios financieros se puede ejecutar como aplicación de WPF independiente.

Esta es la apariencia de la interfaz al ejecutarse en Internet Explorer como XBAP:

Figura 6. Es posible ejecutar la misma aplicación como XBAP

Ahora, en lugar de ejecutarse en su propia ventana, la interfaz se presenta enmarcada por el explorador; sin embargo, su funcionalidad es exactamente la misma. También se puede usar el mismo código en ambos casos, lo que reduce el esfuerzo que requiere el tratamiento de los dos tipos de interfaces. Y, por supuesto, el uso del mismo código implica el uso de unos mismos conocimientos de desarrollo. Los desarrolladores ya no se verán obligados a elegir entre la creación de interfaces de Windows y la generación de interfaces web. WPF elimina por completo esta distinción y permite que los mismos conocimientos se usen en ambos casos.

Otra ventaja derivada del uso de la misma tecnología para interfaces de Windows y web es que el creador de una aplicación no necesitará decidir de antemano el tipo de interfaz que debe presentar la aplicación. Siempre y cuando los clientes de destino sean compatibles con la ejecución de XBAP, la aplicación podrá ofrecer una interfaz de Windows o web (o ambas) con el mismo código en gran medida.

La descarga de XBAP se lleva a cabo a petición desde un servidor web, por lo que los requisitos de seguridad asociados son más estrictos que en el caso de aplicaciones de Windows independientes. Por consiguiente, las XBAP se ejecutan en un recinto de seguridad proporcionado por la seguridad de acceso a código de .NET Framework. Adicionalmente, las XBAP sólo se ejecutan en Windows con la tecnología WPF instalada en el sistema, y únicamente en las versiones de Internet Explorer 6 y 7. No obstante, en lo que respecta a las aplicaciones que cumplen estos requisitos, las aplicaciones de Internet enriquecidas pueden usar ahora la misma base que usan las aplicaciones de Windows independientes.

Uso de Windows Presentation Foundation

Resulta de utilidad conocer los problemas a los que se enfrenta WPF, aunque es igualmente útil conocer el modo en que lo hace. Esta sección se ocupa del análisis intrínseco de la tecnología WPF y descubre los diferentes modos en que se implementa en aplicaciones de escritorio de Windows, aplicaciones XBAP y documentos XPS.

Tecnología Windows Presentation Foundation

WPF ofrece una base unificada para la creación de interfaces de usuario. Sin embargo, podemos examinar las tecnologías que contiene como partes diferenciadas e independientes. Entre otros elementos, estas partes incluyen documentos, imágenes, gráficos y animaciones. A la vez, todas las partes dependen del modelo de aplicación básico de WPF, que se describe a continuación.

Modelo de aplicación

Al igual que ocurre con otras partes de .NET Framework, WPF organiza su funcionalidad en un grupo de espacios de nombres, contenidos todos a su vez en el espacio de nombres System.Windows. Independientemente de las partes de la funcionalidad de que se haga uso, la estructura básica de cada aplicación de WPF es prácticamente la misma. Tanto si se trata de una aplicación de Windows independiente como de una XBAP, suele estar compuesta de un conjunto de páginas XAML y de código asociado a dichas páginas.

En lo concerniente a su raíz, cada aplicación hereda de la clase Application estándar de WPF. Esta clase proporciona servicios comunes útiles para cualquier aplicación. Entre ellos, se incluye el estado de bloqueo, cuya disponibilidad es necesaria para toda la aplicación, y los métodos estándar, como Run, que permite iniciar la aplicación, y Shutdown, para finalizarla.

Los objetos Application se pueden crear con XAML, por medio del elemento Application, o con código, mediante la clase Application. Esto se aplica a casi todo en WPF pero, por conservar la simplicidad, en este artículo se usa siempre la opción XAML. A continuación incluimos un ejemplo de XAML muy sencillo:

<Application xmlns=   
    "http://schemas.microsoft.com/winfx/2006/xaml/presentation"
              xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
     StartupUri="Page1.xaml"
     x:Class="Example.SimpleApp">
. . . 
</Application>

En primer lugar, la definición especifica el espacio de nombres de WPF como predeterminado para el elemento y, después, define un prefijo para el espacio de nombres de XAML. Estos dos espacios de nombres no son sinónimos, ya que el uso de XAML va más allá de WPF. Seguidamente, recurre al atributo StartupUri para indicar el nombre de la página XAML que se debe cargar y mostrar al inicio de la aplicación. El atributo final, Class, se usa para identificar la clase que contiene el código asociado a este elemento Application. Como ya mencionamos con anterioridad, las aplicaciones de WPF suelen contener XAML y código escrito en C# o Visual Basic, por lo que se usa un archivo de código subyacente para guardar el código de la clase. Tras la etiqueta de apertura del elemento Application, encontramos el resto de XAML que define la aplicación (omitido en el ejemplo) y, por último, aparece la etiqueta de cierre de Application.

Aunque todas las aplicaciones de WPF derivan de la misma clase raíz, el desarrollador necesitará tomar muchas otras decisiones. Una de las más importantes consiste en elegir entre una interfaz tradicional basada en cuadros de diálogo y una interfaz de navegación para una aplicación. Las interfaces basadas en cuadros de diálogo incluyen botones y otros elementos que los usuarios de Windows ya conocen. Por el contrario, las interfaces de navegación presentan el funcionamiento típico de un explorador. Por ejemplo, en lugar de abrir un cuadro de diálogo en una ventana nueva, se carga otra página. Una interfaz de este tipo se implementa como grupo de páginas, cada una de ellas compuesta de una interfaz de usuario definida en XAML junto con la lógica expresada en un lenguaje de programación. Al igual que ocurre con las páginas de explorador definidas en HTML, XAML proporciona un elemento Hyperlink que permite vincular las páginas entre sí. El usuario navega por estas páginas del mismo modo que lo haría en una aplicación basada en Web, por medio del historial. Sin embargo, no debemos olvidar que seguimos tratando con una aplicación de Windows. Aunque las XBAP harán uso de este tipo de interfaz, también puede darse el caso de aplicaciones de Windows independientes que presentan interfaces de navegación para la interacción con el usuario. La elección queda al cargo de los creadores de la aplicación.

Independientemente del estilo de interfaz que use, por lo general, la aplicación muestra una o varias ventanas. WPF ofrece varias posibilidades en este sentido. La clase sencilla Window proporciona funciones basadas en ventanas básicas (por ejemplo, permite mostrar, ocultar y cerrar ventanas) y se suele usar en aplicaciones de WPF que no usan una interfaz de navegación. En aplicaciones que usan interfaces de navegación, NavigationWindow amplía la clase básica Window para ofrecer compatibilidad con tareas de navegación. Esta compatibilidad incluye el método Navigate, que permite a la aplicación pasar a una nueva página, un diario que contiene el historial de navegación del usuario y varios eventos referentes a la navegación.

Diseño y controles

Con el fin de ordenar las diferentes partes de que se compone una interfaz, las aplicaciones de WPF presentan paneles de diseño. Cada panel puede contener elementos secundarios, como controles (por ejemplo, botones y cuadros de texto) y otros paneles. Cada tipo de panel ofrece opciones de diseño distintas. Así, DockPanel permite colocar los elementos secundarios en los bordes del panel, mientras que Grid supone la colocación precisa de estos elementos en una cuadrícula. El desarrollador define el número de filas y columnas en la cuadrícula y, a continuación, especifica exactamente la ubicación de los elementos secundarios. Canvas ofrece al desarrollador la posibilidad de colocar estos elementos en cualquier lugar dentro de los límites del panel.

Como cualquier otra tecnología de interfaces de usuario, WPF incluye un amplio conjunto de controles, así como la opción para los desarrolladores de crear controles personalizados. Entre los controles estándar se incluyen Button, Label, TextBox, ListBox, Menu, Slider y otros componentes tradicionales del diseño de interfaces de usuario. También hay disponibles controles más complejos, como SpellCheck, PasswordBox y controles para el trabajo con tinta (para Tablet PC, por ejemplo).

Como es usual en interfaces gráficas, los controles incluidos en las aplicaciones de WPF pueden detectar y controlar eventos generados por el usuario (por ejemplo, los movimientos del mouse y el uso de teclas). Mientras que los controles y otros elementos de interfaz de usuario pueden especificarse por completo mediante XAML, los eventos requieren el uso de código. Por ejemplo, a continuación se muestra una definición en XAML de un componente Button sencillo en un panel Canvas:

<Canvas xmlns=
   "http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    x:Class="Example.CodeForCanvas">
  <Button Click="Button_Click">
   Click Here
  </Button>
</Canvas>

La etiqueta de apertura de Canvas empieza con la definición de los espacios de nombres de WPF y de XAML usuales. Seguidamente, especifica que el código asociado a XAML se encuentra en la clase CodeForCanvas, incluida en el espacio de nombres Example de .NET Framework. A continuación aparece la definición del componente Button, que mostrará el texto en pantalla "Click Here". El atributo Click de la etiqueta de apertura de Button indica que el botón usa el método Button_Click para controlar el evento de clic. El código correspondiente a dicho método se parecerá al siguiente:

namespace Example {
  public partial class CodeForCanvas : Canvas  {
    void Button_Click(object sender, RoutedEventArgs e)    {
      Button btn = e.Source as Button;
      btn.Background = Brushes.Purple; 
    }
  }
}

El espacio de nombres y la clase coinciden con los valores especificados en la etiqueta Canvas anterior. La clase CodeForCanvas hereda de la clase Canvas básica proporcionada por WPF, y se define como clase parcial. Las clases parciales se incluyeron por primera vez en la versión 2.0 de .NET Framework para permitir la combinación de código definido de forma independiente en una sola clase. En este caso, la clase Canvas definida en XAML genera una clase parcial que se combina con la clase parcial mostrada aquí. Como resultado, obtenemos una clase completa capaz de mostrar un botón sobre el panel y controlar el evento asociado.

El método Button_Click para controlar dicho evento se encuentra en la clase CodeForCanvas. Se ciñe a las convenciones usuales de .NET Framework para eventos, aunque los argumentos del evento se expresan mediante la clase RoutedEventArgs, definida por WPF. La propiedad Source de esta clase incluye una referencia al componente Button que generó el evento, y que el método usa para cambiar el color del botón a púrpura.

Como sugiere este sencillo ejemplo, los elementos que componen una interfaz de usuario de WPF están ordenados en un árbol visual. Aquí, el árbol incluye únicamente el elemento Canvas con un solo componente secundario Button pero, en una aplicación de WPF real, el árbol suele ser mucho más complejo. Es necesario representar el árbol visual para crear la interfaz en pantalla. En la medida de lo posible, WPF usa la representación de hardware, es decir, la tarea queda al cargo de la tarjeta gráfica instalada en el equipo. No obstante, si la tarjeta no puede realizar el trabajo, WPF recurrirá a su propio software para representar la interfaz. Esta decisión la toma WPF en tiempo de ejecución; los desarrolladores no necesitan hacer nada especial.

Tanto si la representación se lleva a cabo mediante hardware como a través de software, WPF se basa siempre en el enfoque de modo retenido para los gráficos. Los creadores de la aplicación se encargan de definir la apariencia del árbol visual, generalmente, mediante la combinación de XAML y código. A partir de ahí, WPF conserva la información incluida en el árbol. Por ejemplo, en lugar de exigir a la aplicación que vuelva a dibujar la totalidad de una ventana o parte de ella cuando el usuario se dispone a descubrirla, WPF se ocupa de hacerlo sin necesidad de recurrir a otros procesos. Los elementos que componen el árbol se almacenan como objetos, y no como píxeles en la pantalla, de modo que WPF cuenta con la información suficiente para controlar este tipo de representación. Incluso en casos de modificación del tamaño de ventanas y de los controles que contienen, WPF puede volver a realizar la representación completa por su cuenta. WPF dispone de la información necesaria para volver a crear la interfaz según el nuevo tamaño, ya que es capaz de interpretar la forma de los gráficos (líneas, elipses, etc.) y se basa en gráficos vectoriales, no en mapas de píxeles.

Estilos y plantillas

A menudo, resulta útil poder definir la apariencia de algunos elementos individuales de interfaz de usuario, para después aplicar esta misma apariencia a otros elementos. Las hojas de estilos en cascada (CSS) permiten hacer uso de esta opción en páginas HTML, por ejemplo. WPF se sirve de estilos para ofrecer una función similar. Tal y como sugiere la popularidad de las hojas de estilos CSS, la capacidad de definir estilos puede ser de gran utilidad. Entre otras cosas, permiten una mejor separación de las tareas de los diseñadores y los desarrolladores. Así, permiten al diseñador crear una apariencia uniforme para la interfaz, mientras el desarrollador puede olvidarse de estos detalles.

Mediante el elemento Style de XAML, el creador de una aplicación de WPF puede definir uno o varios aspectos de la apariencia de un elemento particular y, posteriormente, aplicar el mismo estilo una y otra vez. Por ejemplo, la definición del estilo ButtonStyle puede ser la siguiente:

<Style x:Key="ButtonStyle"> <Setter Property="Control.Background" Value="Red"/> <Setter Property="Control.FontSize" Value="16"/></Style>

Cualquier elemento Button definido con este estilo mostrará un fondo rojo y el tamaño de fuente 16. Por ejemplo:

<Button Style="{StaticResource ButtonStyle}">
   Click Here
  </Button>

Como muestra la apariencia de "StaticResource" en el ejemplo, los estilos de WPF se definen generalmente como recurso, es decir, datos definidos independientemente del código de la aplicación.

Los estilos permiten muchas más opciones que las de este sencillo ejemplo. Un estilo se puede derivar de otro, por ejemplo, al heredar su configuración y, quizás, reemplazarla. En ocasiones, los estilos definen desencadenadores que especifican aspectos comunes de comportamiento interactivo. De este modo, un estilo determinado puede especificar que el fondo de los botones debe cambiar a amarillo al desplazar el mouse sobre elementos Button.

WPF también admite el uso de plantillas. Las plantillas son similares a los estilos. Hay dos tipos de plantillas disponibles:

  • Plantillas de datos: permiten el uso del elemento DataTemplate de XAML para especificar conjuntos de características relacionadas con la apariencia de datos. Es posible definir colores y aspectos de alineación, entre otros rasgos una vez que se incluyan a una plantilla de datos, para después usarlos en cualquier otra parte de la interfaz de usuario de la aplicación.

  • Plantillas de control: permiten el uso del elemento ControlTemplate de XAML para definir la apariencia de controles.

Tiene sentido contar con un método sencillo que los creadores de aplicaciones puedan usar para definir la apariencia de la interfaz. En WPF, los estilos y las plantillas son los mecanismos principales de esta funcionalidad.

Texto

La mayoría de interfaces de usuario incluyen algún texto; algunas se componen de poco más. Sin embargo, para la mayoría de los usuarios, no se puede comparar leer texto en pantalla con leer un documento impreso. Estamos acostumbrados a la gran calidad de la representación de las letras y de las relaciones entre estas que suelen ofrecer libros y revistas. La lectura en pantalla es diferente; por algún motivo, el texto no parece tan fácil de leer.

El objetivo de WPF es dotar al texto en pantalla de la legibilidad característica del texto impreso para poner fin a esta distinción. Para conseguirlo, WPF ofrece compatibilidad con las fuentes OpenType estándar de la industria, lo que permite el uso de las bibliotecas de fuentes existentes. También es compatible con la tecnología ClearType, definida más recientemente. ClearType suaviza la apariencia del texto mediante la colocación de subpíxeles, una técnica usada en la iluminación de los subelementos individuales que forman parte de cada píxel en pantallas modernas. Además, WPF proporciona compatibilidad de bajo nivel para la representación de texto mediante la clase Glyphs. Más adelante veremos cómo esta clase se usa para representar caracteres en documentos XPS.

Para mejorar aún más la legibilidad, WPF se sirve también de elementos adicionales como las ligaduras, que hacen posible la sustitución de grupos de caracteres por imágenes conectadas únicas. Por ejemplo, el grupo "ffi" quedará reemplazado en las páginas impresas por una sola ligadura conectada que incluya estos tres caracteres. El uso de este tipo de elementos hace la lectura en pantalla más placentera, aunque el lector no perciba de forma consciente los detalles que contribuyen a que así sea.

Documentos

Una cuestión importante es que el texto sea más legible, ya que forma parte de los botones, de las listas y de muchos otros elementos que componen una interfaz de usuario. Y esto es aún más relevante durante la lectura de amplias secciones de texto, por ejemplo, en documentos. Por consiguiente, la mejora de la legibilidad del texto en pantalla requiere, a su vez, el perfeccionamiento de la presentación de documentos. En este sentido, WPF es compatible con dos tipos de documentos: documentos fijos y documentos de flujo.

Los documentos fijos presentan la misma apariencia tanto en pantalla como en formato impreso. La seguridad de conservar una apariencia idéntica es importante cuando se manejan ciertos tipos de formularios y documentos legales, entre otras publicaciones, y dichos documentos fijos gozan de popularidad en varias áreas de trabajo. Los documentos de formato fijo compatibles con WPF vienen definidos por XPS, que se trata más adelante en este artículo. El contenido de los documentos fijos se puede especificar mediante el elemento FixedDocument de XAML. Este sencillo elemento contiene una lista de elementos PageContent, cada uno de los cuales incluye el nombre de una página del documento fijo. Para mostrar un documento fijo, WPF cuenta con el control DocumentViewer, que ofrece una visualización de sólo lectura de documentos XPS para permitir al lector desplazarse por el documento, realizar búsquedas de fragmentos de texto determinados, etc.

Los documentos fijos están diseñados para su uso en pantalla y en papel, mientras que la presentación de los documentos de flujo está ideada únicamente para la pantalla. Con el fin de que su contenido resulte lo más claro posible, la apariencia del texto y de los gráficos se puede ajustar automáticamente al tamaño de la ventana, entre otros factores. Los documentos de flujo vienen definidos por el elemento FlowDocument de XAML. A continuación se muestra un sencillo ejemplo:

  <FlowDocument 
    ColumnWidth="300" 
    IsColumnWidthFlexible="True" 
    IsHyphenationEnabled="True">
      <Paragraph FontSize="12">
       <Bold>Describing WPF</Bold>
      </Paragraph>
      <Paragraph FontSize="10">
       WPF is the user interface technology for the .NET 
       Framework 3.0. It provides a unified foundation for modern 
       user interfaces, including support for documents, two- and 
       three-dimensional graphics, media, and more. It also 
       allows using the same approach (and the same code) for 
       creating standalone Windows applications and applications 
       that run inside a browser.
      </Paragraph>
  </FlowDocument>

Este documento requiere la presentación en una columna con ancho mínimo de 300. El ancho se mide en píxeles independientes del dispositivo, cada uno de los cuales tiene un ancho definido de 0,26 mm. Sin embargo, en la línea siguiente, el creador del documento especifica que el ancho es flexible. Para ello, establece el valor de la propiedad IsColumnWidthFlexible en true. Esto sirve de autorización a WPF para cambiar el ancho y el número de columnas que se usarán para mostrar el documento. Por ejemplo, si el usuario cambia el ancho de la ventana en que se muestra el documento, WPF puede incrementar o disminuir el número de columnas que contiene el texto, así como el ancho que deben presentar.

A continuación, se solicita el uso de guiones al establecer el valor de la propiedad IsHyphenationEnabled en True. Después, aparecen dos párrafos del documento. El texto de cada uno de ellos se presenta incluido en un elemento Paragraph con un tamaño de fuente diferente. Además, el texto del primer párrafo indica el uso de la fuente en negrita.

WPF define varias opciones FlowDocument adicionales para mejorar la legibilidad del texto. Por ejemplo, si el valor de la propiedad IsOptimalParagraphEnabled se establece en true, WPF se encargará de distribuir el espacio en blanco de los párrafos del modo más uniforme posible. Esto impide que el espacio en blanco influya de forma negativa en la legibilidad del texto, como suele ocurrir en los documentos impresos. Los documentos de flujo también admiten anotaciones, por ejemplo, es posible agregar notas en texto normal o, en el caso de Tablet PC, en tinta. Cada anotación está compuesta de un delimitador, que identifica el contenido del documento con el que está asociada, y de una carga, que incluye el contenido propio de la anotación.

Para facilitar la presentación de documentos FlowDocument, WPF proporciona varios controles. Son los siguientes:

  • FlowDocumentPageViewer: permite el desplazamiento por el documento página a página. Este control incluye botones de desplazamiento hacia delante y hacia atrás, además de un control de zoom para cambiar el tamaño del documento.

  • FlowDocumentScrollViewer: ofrece una vista de desplazamiento más tradicional para los documentos de tipo FlowDocument e incluye una barra de desplazamiento en el lateral derecho de la página.

  • FlowDocumentReader: combina la funcionalidad de FlowDocumentPageViewer y de FlowDocumentScrollViewer. Este control permite al usuario pasar de la vista basada en páginas de un documento de flujo (incluida la vista que muestra dos páginas a la vez) a una vista de desplazamiento.

El incremento gradual de la cantidad de información que se proporciona digitalmente subraya la importancia de la calidad que debe ofrecer la experiencia de la lectura en pantalla. Con la capacidad de adaptación de la apariencia de la información que ofrecen los documentos de flujo, WPF se propone mejorar esta experiencia para los usuarios de Windows.

Imágenes

Las imágenes constituyen una parte fundamental de muchas interfaces de usuario, ya se trate del logotipo de la compañía, imágenes de una puesta de sol o de cualquier otra cosa. En WPF, la presentación de las imágenes se suele llevar a cabo mediante el control Image. Por ejemplo, para mostrar un archivo JPEG, se podría usar el código XAML siguiente:

<Image 
 Width="200" 
 Source="C:\Documents and Settings\All Users\Documents\
  My Pictures\Ava.jpg" />

El ancho de la imagen está establecido en 200 y, una vez más en este caso, las unidades son píxeles independientes del dispositivo. El archivo que contiene la imagen viene identificado por el atributo Source.

Los archivos de imágenes pueden incluir información sobre las imágenes (metadatos), como palabras clave y clasificaciones que aplican los usuarios. Las aplicaciones de WPF pueden leer y escribir esta información. Además, es posible usar las imágenes de formas mucho más interesantes. Por ejemplo, podemos colocar una imagen en una de las caras de un objeto tridimensional giratorio. Aunque nuestro sencillo ejemplo ilustra un caso común, WPF permite un uso de las imágenes bastante más amplio.

El control Image de WPF admite imágenes almacenadas en varios formatos, entre ellos, JPEG, BMP, TIFF, GIF y PNG. También puede mostrar imágenes almacenadas con el formato Windows Media Photo (WMPhoto) de Microsoft (nuevo con Windows Vista). Independientemente del formato, WPF usará Windows Imaging Component (WIC) para producir la imagen. Además de proporcionar codificadores y descodificadores (códecs) para todos los formatos de imagen mencionados, WIC ofrece un marco de trabajo para agregar códecs de terceros.

Vídeo y audio

Con el incremento de la velocidad de redes y procesadores, el vídeo juega un papel cada vez más importante en la interacción de los usuarios con el software. Además, dedicamos mucho tiempo a escuchar música y otros tipos de audio en nuestros equipos. Consecuentemente, WPF ofrece compatibilidad integrada con ambos.

Esta compatibilidad depende del control MediaElement. A continuación incluimos un ejemplo sencillo de XAML que ilustra el modo de uso de este control:

<MediaElement 
 Source="C:\Documents and Settings\All Users\Documents\
  My Videos\Ruby.wmv" />

El control permite reproducir vídeo en formato WMV, MPEG y AVI, junto con varios formatos de audio.

Gráficos bidimensionales

Los creadores de gráficos bidimensionales en Windows llevan veinte años usando la interfaz de dispositivo gráfico (GDI) y su sucesora GDI+. No obstante, incluso las aplicaciones de Windows Forms requieren el acceso a esta funcionalidad a través de un espacio de nombres totalmente diferente, ya que los gráficos bidimensionales no están integrados en la tecnología de la interfaz de usuario. En cuanto a los gráficos tridimensionales, la situación era aún peor; se requería una tecnología independiente por completo: Direct3D. WPF elimina esta complejidad en una amplia gama de aplicaciones. Los gráficos 2D y 3D se pueden crear directamente en XAML o en código de procedimiento con las bibliotecas de WPF. Como sucede con el resto en WPF, los elementos usados son simplemente una parte más del árbol visual de las aplicaciones.

En lo que respecta a gráficos bidimensionales, WPF define un grupo de formas que las aplicaciones pueden usar para crear imágenes. Son los siguientes:

  • Line: dibuja una línea recta entre dos puntos.

  • Ellipse: dibuja una elipse.

  • Rectangle: dibuja un rectángulo.

  • Polygon: dibuja una forma cerrada definida por un grupo de líneas rectas conectadas entre sí.

  • Polyline: dibuja una forma abierta definida por un grupo de líneas rectas conectadas entre sí.

  • Path: dibuja formas descritas por una ruta arbitraria. Las formas pueden ser abiertas o cerradas, y las líneas de la ruta pueden ser rectas o curvas. En realidad, las demás formas existen únicamente por comodidad, ya que Path se puede usar para dibujar líneas, elipses, rectángulos, polígonos, polilíneas, etc.

El uso de estas clases para crear gráficos sencillos es muy simple. Por ejemplo, el código XAML siguiente sirve para dibujar una elipse roja:

<Ellipse Width="30" Height="10" Fill="Red" />

Para rellenar formas, se usa un pincel. En el ejemplo anterior, se usa el pincel predeterminado, un pincel de color sólido, pero WPF ofrece otras opciones. Por ejemplo, se puede definir un rectángulo con un degradado de color que cambie de rojo a amarillo en horizontal de la siguiente forma:

<Rectangle Width="30" Height="10" 
 Fill="HorizontalGradient Red Yellow" />

Hay disponibles otros pinceles, incluidos un degradado vertical, un degradado radial y pinceles que usan imágenes, mapas de bits, etc. Además, las formas también admiten el uso de lápices para especificar el color, el ancho y el estilo del contorno.

En WPF, todo está creado sobre una base común, por lo que la combinación de aspectos totalmente diferentes es sencilla. Las aplicaciones pueden mostrar elementos Image dentro de elementos Rectangle, colocar elementos Ellipse dentro de elementos Button, etc. Por ello, la combinación de gráficos 2D con gráficos 3D y otras partes de la interfaz es un proceso muy simple.

Al igual que con las formas, WPF proporciona otro grupo de clases para trabajar con gráficos bidimensionales. Se trata de geometrías que, en muchos sentidos, son muy similares a las formas. De modo similar a las formas, que incluyen opciones como Line, Rectangle, Ellipse y Path, las geometrías permiten seleccionar entre LineGeometry, RectangleGeometry, EllipseGeometry y PathGeometry. La diferencia más importante entre los dos tipos de clases es que las formas se usan comúnmente para dibujar imágenes visibles, mientras que las geometrías se suelen usar para definir regiones. Por ejemplo, si resulta necesario recortar una imagen cuadrada para colocarla dentro de un círculo, la clase EllipseGeometry permite especificar los límites del círculo. Del mismo modo, si se desea definir una región para pruebas de acceso de una aplicación como, por ejemplo, un área en la que se deben detectar los clics del mouse, es posible especificar una geometría para dicha región.

Finalmente, cabe mencionar que todo lo descrito en esta sección se implementa sobre una interfaz de nivel inferior denominada capa visual. Esta capa se puede usar directamente para crear gráficos, imágenes y texto. Esto puede resultar muy útil en determinadas circunstancias, por ejemplo, a la hora de crear gráficos sencillos de alto rendimiento. Sin embargo, la mayoría de las aplicaciones usarán las formas y demás abstracciones de nivel superior que ofrece WPF.

Gráficos tridimensionales

Los gráficos bidimensionales son muy comunes en las interfaces de Windows, por lo que WPF ofrece bastante tecnología en esta área. Por el contrario, hoy día, los gráficos tridimensionales no se usan ya tanto, aunque pueden ofrecer resultados muy buenos cuando se trata de mejorar la visualización de los datos y manejar gráficos 3D, representaciones de productos, etc. Tradicionalmente, el trabajo con gráficos 3D requiere un conjunto de habilidades único, que no suele encontrarse fuera del círculo de los desarrolladores de juegos y otros grupos especializados. La intención de WPF es cambiar este panorama al incluir la compatibilidad con gráficos 3D en el entorno estándar.

Sin WPF, el desarrollo 3D en Windows suele quedar al cargo de la API de Direct3D. Como ocurre con todo lo demás en WPF, la compatibilidad con gráficos 3D se sirve de Direct3D de forma no visible, pero el entorno que se presenta a los desarrolladores es mucho más sencillo. Como veremos más adelante en este artículo, aunque todavía se dan casos en que recurrir a Direct3D se prefiere al uso de WPF, la intención de Microsoft es conseguir que el desarrollo 3D convencional para interfaces de Windows se base en WPF.

Para mostrar gráficos 3D en WPF, la aplicación usa el control Viewport3D que, básicamente, ofrece una ventana al mundo tridimensional que describe esta aplicación. El control Viewport3D se puede usar en cualquier parte de las interfaces de WPF, lo que permite la representación de gráficos 3D allí donde se necesiten.

Para crear una escena tridimensional, el desarrollador describe uno o más modelos y, a continuación, especifica el modo de iluminación y visualización de éstos. Como de costumbre, estos aspectos se pueden especificar por medio de XAML, de código o de una combinación de ambos. Para describir modelos, WPF incluye la clase GeometryModel3D, que permite definir la forma de los mismos. Una vez definido el modelo, su apariencia se controla mediante la aplicación de diferentes tipos de material. Por ejemplo, la clase SpecularMaterial dota de brillo a las superficies, al contrario que la clase DiffuseMaterial.

Independientemente de los materiales que se usen, los modelos se pueden iluminar de varios modos. DirectionalLight proporciona luz que se origina desde una dirección específica, mientras que AmbientLight permite la iluminación uniforme de todo lo que contiene una escena. Por último, para definir el modo de visualización de los modelos, el desarrollador especifica una cámara. Por ejemplo, PerspectiveCamera sirve para especificar la distancia y la perspectiva de visualización de los modelos. OrthographicCamera tiene la misma finalidad, excepto en lo que concierne a la perspectiva: los objetos que están más alejados de la cámara no parecen más pequeños.

La creación de escenas 3D complejas directamente en XAML o con código no sigue un proceso sencillo. Es de esperar que, para la mayoría de las aplicaciones de WPF que incluyen 3D, los desarrolladores harán uso de herramientas gráficas para generar las definiciones necesarias. De cualquier modo, la capacidad de usar gráficos 3D en interfaces de usuario estándar tiene el potencial de mejorar la calidad del contenido de la pantalla considerablemente.

Transformación y efectos

Además de permitir la definición de formas y otros elementos, WPF ofrece también a los desarrolladores la posibilidad de transformar estos elementos mediante giros y cambios de tamaño, por ejemplo. En XAML, esto se consigue mediante los elementos RotateTransform y ScaleTransform, respectivamente. Este tipo de transformación se puede aplicar a cualquier elemento de interfaz de usuario. A continuación se muestra un sencillo ejemplo:

</Button>
  <Button Content="Click Here">
   <Button.RenderTransform>
    <RotateTransform Angle="45" />
   </Button.RenderTransform>
  </Button>

El elemento RotateTransform aplica un giro de 45° al botón. Quizás esta acción no sea particularmente útil, pero el hecho de que es posible realizarla pone en evidencia el carácter general del diseño de WPF. Los diferentes aspectos de la interfaz de usuario no dependen de tecnologías subyacentes distintas, por lo que se pueden combinar de formas muy diversas.

Asimismo, WPF incluye algunos efectos predefinidos. Al igual que las transformaciones, estos efectos son aplicables a varios componentes de interfaz de usuario: Buttons, ComboBoxes, etc. Incluyen un efecto de desenfoque que da una apariencia difusa a los elementos de interfaz, un resplandor externo que los hace brillar y un efecto de sombra paralela para ensombrecer el fondo sobre el que se encuentran.

Animaciones

Puede ser muy útil dotar de movimiento a los elementos de la interfaz, es decir, convertirlos en elementos animados. Por ejemplo, es posible conseguir que un botón parezca que está presionado y luego se suelta al hacer clic en él. Este tipo de efecto mejora la experiencia del usuario. Las animaciones más complejas permiten crear interfaces atractivas, ya que captan la atención de los usuarios y ofrecen información interesante. Con este fin, WPF incluye compatibilidad con animaciones.

Al igual que las transformaciones, las animaciones se pueden aplicar a muchos aspectos de interfaz de usuario: botones, formas, imágenes, etc. Para crear una animación, basta con cambiar el valor de una o más propiedades de un objeto a lo largo de cierto período de tiempo. Por ejemplo, para aplastar lentamente un elemento Ellipse, es necesario disminuir progresivamente la propiedad Height asociada durante dos segundos.

La definición de un grupo de animaciones relacionadas suele ser de utilidad. Para ello, WPF incluye la clase Storyboard. Cada elemento Storyboard puede incluir varias escalas de tiempo que, a su vez, pueden contener varias animaciones. Hay disponibles escalas de tiempo diferentes, lo que permite la ejecución de las animaciones como secuencia o en paralelo. A continuación se incluye un ejemplo sencillo (aunque algo incompleto) de XAML que ilustra el proceso de aplastamiento de un elemento Ellipse:

    <Ellipse Width="100" Height="50" Fill="Blue"
     Name="EllipseForSquashing">
     . . . 
     <Storyboard>
      <DoubleAnimation
       Storyboard.TargetName="EllipseForSquashing" 
       Storyboard.TargetProperty="Height"
        From="50" To="25" Duration="0:0:2" />
       </Storyboard>
       . . . 
    </Ellipse>   

El ejemplo empieza con la definición de un elemento Ellipse que vimos anteriormente en este artículo. En este caso, se usa también la propiedad Name para asignar un identificador que permita realizar referencias posteriores a este elemento Ellipse. Se omiten algunos detalles pero, para definir la animación en XAML, es necesario incluir un elemento Storyboard. La propiedad Height del elemento Ellipse es de tipo doble; por ello, Storyboard contiene un elemento DoubleAnimation. Este elemento especifica el nombre del elemento Ellipse que va a animarse, la propiedad que se va a modificar y los cambios precisos que se deben aplicar. En el ejemplo, el valor de Height cambia de 50 a 25 durante un período de dos segundos.

Se pueden crear animaciones mucho más complejas. Es posible activarlas con determinados eventos (como clics del mouse), interrumpirlas y reanudarlas, repetirlas varias veces o de forma indefinida, etc. El objetivo es permitir a los desarrolladores que creen interfaces de usuario que mejoren la experiencia del usuario y ofrezcan una mayor facilidad de uso y más funcionalidad.

Enlace de datos

La mayoría de las interfaces de usuario presentan algún tipo de datos. Con el fin de simplificar la tarea de los desarrolladores que las crean, el enlace de datos facilita la presentación de los datos en pantalla. Esta función permite la conexión directa de la apariencia de los controles de WPF con datos externos. Por ejemplo, el valor de la propiedad Text en un control TextBox de WPF se puede enlazar a la propiedad Name de un objeto Employee que forma parte de la lógica empresarial de esta aplicación. Los cambios que se produzcan en una propiedad se podrán reflejar posteriormente en la otra. Por ejemplo, si un usuario actualiza el valor de TextBox, la propiedad Name del objeto Employee también cambiará y viceversa.

La creación de este tipo de conexión entre las propiedades de dos objetos requiere el uso de la clase Binding de WPF. Ésta es una ilustración de XAML simplificada de la apariencia que puede ofrecer este tipo de enlace:

<TextBox . . . >
 <TextBox.Text>
  <Binding Path="Name" />
 </TextBox.Text>
</TextBox>

En el ejemplo, el atributo Path del elemento Binding sirve para identificar la propiedad que se desea enlazar con la propiedad Text de TextBox. Path se usa cuando el objeto de que forma parte esta propiedad (especificada en tiempo de ejecución) es un objeto Common Language Runtime (CLR), que se define en un lenguaje como C# o Visual Basic. Además de objetos CLR, el enlace de datos en WPF también permite realizar conexiones directas a datos XML por medio de la propiedad XPath de Binding. Esta opción crea una consulta XPath que selecciona uno o varios nodos en documentos XML mediante referencias a los datos especificados.

También existen opciones de enlace de datos más complejas. Por ejemplo, el enlace de listas permite rellenar el contenido de controles ListBox a partir de cualquier objeto CLR que implemente la interfaz IEnumerable estándar. De ser necesario, también se pueden filtrar u ordenar los datos antes de presentarlos. Aunque el enlace a un Dataset de ADO.NET es perfectamente posible, WPF no ofrece compatibilidad directa con el enlace de datos en sistemas de administración de bases de datos relacionales. Independientemente de la opción de enlace de datos que se use, la intención es conseguir que la presentación de datos en interfaces de usuario siga un proceso lo más directo posible.

Automatización de interfaces de usuario

Los usuarios más comunes de las interfaces de WPF son, lógicamente, personas. No obstante, hay ocasiones en que la interfaz requiere el control proveniente, no de un ser humano, sino de otra aplicación de software. Este es el fin de la funcionalidad de automatización de interfaces de usuario (UI) de WPF.

Por ejemplo, supongamos que un desarrollador desea crear scripts de prueba automatizadas para la interfaz. El acceso mediante programación que ofrece la automatización de interfaz de usuario permite crear scripts capaces de controlar la interfaz como lo haría un usuario humano. Esta función resulta igualmente útil a la hora de crear asistentes de accesibilidad (por ejemplo, una herramienta para la lectura con voz de los elementos de la interfaz). Al permitir el desplazamiento mediante programación por el árbol que contiene estos elementos, la automatización de interfaz de usuario hace posible la creación de estos tipos de herramientas.

Para ello, WPF crea un árbol de automatización de IU. El árbol se compone de objetos AutomationElement, cada uno de los cuales representa algo específico en la interfaz. Desktop es la raíz del árbol y las aplicaciones abiertas son elementos secundarios de esta raíz. El árbol continúa en estas aplicaciones, donde cada control de WPF queda representado por uno o varios objetos AutomationElement. Para permitir un acceso mediante programación completo a la interfaz, todos los elementos susceptibles de interacción con el usuario están representados por objetos AutomationElement únicos. Por ejemplo, un control con varios botones tendrá un objeto AutomationElement único como representación para el control mismo y para cada botón. La presencia de este nivel de granularidad en el árbol de automatización de interfaz de usuario ofrece a las aplicaciones cliente (ya sean scripts de prueba, asistentes de accesibilidad, etc.) el acceso a cada componente de la interfaz como si se tratara de un usuario humano.

La automatización de interfaz de usuario no es el aspecto más destacado de WPF. Seguramente, muchos usuarios no usarán nunca esta función. Sin embargo, aquéllos que la necesitan (comprobadores de software y usuarios con discapacidad, entre otros), la necesitan de verdad. La frecuencia de uso no refleja la importancia de este tipo de función.

Aplicación de Windows Presentation Foundation

El contenido tecnológico de WPF es extraordinario. Aunque se centra exclusivamente en la interacción con el usuario, actualmente, esta tecnología se aplica de tres formas relacionadas: aplicaciones de WPF independientes, aplicaciones XBAP y documentos XPS. En esta sección se analiza cada una de ellas.

Aplicaciones de WPF independientes

Generalmente, WPF se usa como aplicación independiente. Las aplicaciones de WPF independientes se ejecutan como cualquier otra aplicación de Windows y no es necesario disponer de un explorador web. Por consiguiente, las aplicaciones independientes cuentan con plena confianza y se pueden usar todas las funciones de WPF. Esta plena confianza implica, además, que las aplicaciones de WPF independientes pueden usar libremente otros servicios disponibles en el equipo, como Windows Communication Foundation (WCF).

Al igual que otras aplicaciones de Windows, la instalación de una aplicación de WPF independiente se puede realizar desde un disco local o desde un servidor de red. La función ClickOnce de .NET Framework también sirve para llevar a cabo la instalación. ClickOnce ofrece a los usuarios de Internet Explorer un método sencillo para la descarga y la instalación de aplicaciones de Windows, incluidas aplicaciones de WPF, así como para la actualización automática de estas aplicaciones cuando cambien

Aplicaciones XAML de explorador: XBAP

Aunque las aplicaciones de WPF independientes ofrecen la máxima funcionalidad, es posible que, en ocasiones, no sean la mejor elección. En muchas circunstancias, la ejecución de un cliente en un explorador web resulta más útil que ejecutarlo como aplicación de Windows. WPF incluye aplicaciones XBAP para que estos clientes puedan ofrecer interfaces de usuario modernas.

Como muestra la ilustración siguiente, las XBAP se ejecutan en Internet Explorer. Las XBAP pueden actuar como cliente en aplicaciones web creadas con ASP.NET, JavaServer Pages (JSP) u otras tecnologías web. Estas aplicaciones pueden usar HTTP o SOAP para devolver la comunicación a la aplicación web. Independientemente de la plataforma de servidor que se use, la carga de las XBAP se realiza siempre mediante ClickOnce. Sin embargo, durante este proceso, no se presentarán cuadros de diálogo ni mensajes al usuario; las XBAP se cargan de forma idéntica a las páginas web. Por este motivo, las XBAP no aparecen en el menú Inicio ni en Agregar o quitar programas.

Figura 7. Ejecución de una XBAP en Internet Explorer

Aunque no se trata de un requisito estricto, las XBAP suelen ofrecer una interfaz de navegación al usuario. Esto permite que la aplicación se comporte como un cliente web que, probablemente, es lo que espera el usuario. En Internet Explorer 7, las XBAP hacen uso de los botones de desplazamiento hacia delante y hacia atrás del explorador. Además, las páginas XAML a las que tiene acceso el usuario aparecen en el historial del explorador. En Internet Explorer 6, los botones de desplazamiento hacia delante y hacia atrás forman parte de la propia XBAP que, además, se encarga de mantener su propio historial. Estas aplicaciones tienen la capacidad de identificar el entorno de ejecución y realizar las acciones adecuadas en consecuencia. Por lo tanto, el desarrollador no necesita crear versiones diferentes según el explorador.

Debido a que las XBAP se cargan desde la Web y se ejecutan en un explorador, la seguridad de acceso a código de .NET Framework únicamente les otorga confianza limitada. Por esta razón, la capacidad de las XBAP no es tan amplia como la de aplicaciones de WPF independientes. Por ejemplo, una XBAP implementada desde la zona de Internet no puede:

  • Crear ventanas independientes.

  • Mostrar cuadros de diálogo definidos por la aplicación

  • Mostrar el cuadro de diálogo Guardar iniciado desde la misma XBAP

  • Tener acceso al sistema de archivos más allá de un área limitada de almacenamiento aislado.

  • Actuar como cliente de automatización de interfaz de usuario.

  • Usar WCF. Las aplicaciones de WCF deben disponer de plena confianza, por lo que las XBAP implementadas desde Internet no son compatibles con esta tecnología. En su lugar, pueden hacer uso de los servicios web ASP.NET, conocidos comúnmente como ASMX, para comunicarse con la aplicación web a partir de la cual se realizó la carga

  • Usar cualquier código de interfaz de usuario creado con Windows Forms, Microsoft Foundation Classes (MFC) o mediante llamadas directas a Win32. Aunque las aplicaciones de WPF independientes pueden interoperar con todas estas tecnologías anteriores, más adelante veremos cómo ninguna de ellas puede formar parte del entorno de confianza limitada de una XBAP.

  • Usar código no administrado.

Como mencionamos anteriormente, es posible usar la misma base de código para crear una aplicación de WPF independiente y una XBAP. Con este fin, el desarrollador podría hacer uso de la compilación condicional para ajustar en ifdefs las funciones no permitidas en la XBAP. La versión XBAP tiene, prácticamente, la misma capacidad que la aplicación independiente, incluso en lo que respecta a la presentación de documentos, el uso de gráficos bidimensionales y tridimensionales, la reproducción de vídeo y de audio, etc. Además, puede aprovechar el hardware de gráficos que haya disponible en el equipo de ejecución.

En conjunción con las XBAP, es posible mostrar páginas XAML puras directamente en Internet Explorer. Este lenguaje XAML flexible sirve para mostrar páginas estáticas en el explorador. No obstante, el control de eventos requiere código, lo que implica la creación de una XBAP.

Las XBAP permiten a los desarrolladores usar la mayoría de las funciones de WPF en aplicaciones de explorador. También proporcionan un modelo de programación común, mediante el uso mayoritario del mismo código, tanto para aplicaciones independientes como de explorador. En lo que respecta a las aplicaciones web de clientes con plataformas de Windows más recientes, las XBAP constituyen una elección muy atractiva.

Documentos XPS

Los documentos de formato fijo (documentos XPS en el entorno de WPF) desempeñan un función clara en las interfaces de usuario. Como vimos con anterioridad, para la presentación de este tipo de documento, WPF cuenta con el control DocumentViewer. Sin embargo, aunque resulta lógico incluir este control en WPF, el motivo por el que XPS debería considerarse parte de WPF no es tan obvio. Después de todo, la especificación XPS ofrece un método altamente detallado para definir documentos de formato fijo que, a su vez, se pueden usar de formas diversas. Los demás aspectos de WPF se centran únicamente en la creación de interfaces de usuario. Si tomamos en cuenta su ámbito más amplio, ¿por qué habríamos de incluir XPS en el entorno WPF?

Un motivo de gran peso es que los documentos XPS se definen mediante XAML. Aunque sólo se usa un pequeño subconjunto de XAML (el elemento Canvas para el diseño, el elemento Glyphs para la representación de texto y el elemento Path para la creación de gráficos bidimensionales), cada documento XPS es realmente un documento XAML. Esto hace posible considerar XPS como parte de WPF.

De todos modos, una de las aplicaciones más importantes de XPS no guarda relación alguna con las interfaces de usuario en pantalla. A partir de Windows Vista, XPS se convierte en formato de impresión nativo para Windows. XPS actúa como lenguaje de descripción de páginas, por lo que las impresoras compatibles con XPS pueden representar directamente documentos XPS. Esto permite el uso de un único formato de descripción (XAML) durante todo el proceso, desde la pantalla a la impresora. Además, supone una mejora con respecto al mecanismo de impresión existente en Windows basado en GDI, ya que ofrece una compatibilidad de impresión superior para efectos complejos de gráficos, por ejemplo, transparencia y degradados.

De forma conjunta con XAML, los documentos XPS pueden incluir datos binarios, como imágenes en formatos diversos (entre ellos, JPEG, PNG, TIFF y WMPhoto), datos de fuentes, información sobre la estructura de documentos, etc. De ser necesario, es posible firmar los documentos XPS digitalmente con las definiciones de firma W3C XML y certificados X.509. Independientemente de su contenido, cada documento XPS se almacena en un formato definido por las convenciones Open Packaging Conventions (OPC). Las OPC especifican la relación entre las partes de un documento XML (no sólo de un documento XPS o XAML), el modo en que se almacenan en un formato ZIP estándar, etc. Microsoft Office 2007 también usa las OPC para sus formatos XML, de modo que estos dos tipos de documentos presentan cierta similitud en este sentido.

Vimos anteriormente que los usuarios de aplicaciones de WPF pueden visualizar documentos XPS mediante el control DocumentViewer de WPF. Microsoft proporciona además una aplicación para la visualización de XPS, creada sobre el control DocumentViewer, como se muestra aquí. Al igual que el control, esta aplicación permite a los usuarios desplazarse por los documentos página a página, realizar búsquedas de texto, etc. Los documentos XPS no son específicos de Windows, por lo que Microsoft tiene intención de proporcionar visores de XPS también para otras plataformas, como Apple Macintosh.

Figura 8. Los visores de XPS permiten la lectura de documentos XPS por páginas

WPF ofrece un conjunto de API para que los desarrolladores puedan crear, cargar y manipular documentos XPS. Las aplicaciones de WPF también admiten documentos al nivel de las OPC, lo que permite el acceso generalizado a documentos XPS y a documentos de Office 2007, entre otros. Asimismo, las aplicaciones creadas con Windows Workflow Foundation de Microsoft pueden hacer uso de estas API para crear flujos de trabajo que usan documentos XPS.

Al permitir a las aplicaciones mostrar y usar documentos de formato fijo, WPF integra este componente de interfaces de usuario modernas en su enfoque coherente. Con el uso del mismo formato para la impresión de documentos, Windows Vista ofrece una mayor coincidencia entre lo que el usuario ve en pantalla y lo que se muestra en papel. Aunque la posibilidad de usar este tipo de documento no sea lo primero que se espera de una interfaz de usuario, el uso generalizado de XPS ilustra el amplio margen que puede abarcar una tecnología como WPF.

Herramientas para Windows Presentation Foundation

WPF ofrece innumerables funciones a los desarrolladores. Sin embargo, independientemente de su eficacia, la utilidad de cualquier tecnología puede mejorar aún más con el uso de herramientas efectivas. Con WPF, Microsoft proporciona una herramienta diseñada especialmente para los desarrolladores y otra destinada a los diseñadores. En esta sección se las describe brevemente.

Para desarrolladores: Visual Studio

Visual Studio es la herramienta estrella de Microsoft para desarrolladores de software. Junto con el lanzamiento inicial de WPF, Microsoft ofrecerá extensiones de Visual Studio 2005 que los desarrolladores podrán usar para crear aplicaciones de WPF. La próxima versión de Visual Studio, cuyo nombre en código es "Orcas", incluirá aún más ventajas como, por ejemplo, un diseñador visual para WPF (con un nombre en código propio, "Cider"). Esta herramienta visual permite la creación de interfaces de WPF de forma gráfica, con una generación posterior automática del código XAML subyacente. Aunque no se ha anunciado ninguna fecha oficial, el lanzamiento de Orcas está programado para 2007.

Para diseñadores: Expression Interactive Designer

Como se indicó anteriormente, uno de los objetivos principales de WPF es asignar un papel principal a los diseñadores en la creación de interfaces de usuario. XAML tiene la capacidad de convertir este objetivo en realidad pero, para ello, se necesitan herramientas que permitan a los diseñadores trabajar en este entorno nuevo. Microsoft proporciona Expression Interactive Designer con este fin.

Como sugiere la captura de pantalla siguiente, Expression Interactive Designer incluye algunos aspectos propios de herramientas de diseño tradicionales, de modo que los usuarios ya están familiarizados con el método de trabajo. No obstante, esta herramienta se centra exclusivamente en la creación de interfaces para aplicaciones de WPF. De hecho, la interfaz de la herramienta misma se ha creado con WPF. Fijémonos, por ejemplo, en la lista de controles de WPF que hay en la esquina superior derecha de la pantalla siguiente y en la escala de tiempo gráfica situada en la parte inferior. Estos elementos corresponden a funciones de WPF (descritas anteriormente en este artículo) que los diseñadores de interfaces pueden usar. Las animaciones se pueden crear de forma gráfica, al igual que las transformaciones, los efectos, etc. El resultado del trabajo de los diseñadores se expresa en archivos XAML generados por la herramienta y que, posteriormente, se pueden importar en Visual Studio.

Figura 9. Expression Interactive Designer permite a los diseñadores crear interfaces de WPF.

Expression Interactive Designer es uno de los tres componentes de la familia Expression de Microsoft. Los otros dos son Expression Web Designer, para la creación de interfaces web basadas en estándares, y Expression Graphic Designer, para la generación de imágenes vectoriales o de mapa de bits. Entre estos tres componentes, sólo Expression Interactive Designer se centra exclusivamente en la creación de interfaces de usuario para aplicaciones de WPF. Quizás los diseñadores usen otros para crear determinadas partes de la interfaz de usuario (por ejemplo, podrían basar la generación de imágenes GIF en Expression Graphic Designer), pero estas herramientas no son específicas para WPF. Aún no contamos con una fecha exacta, pero todas las herramientas de Expression se publicarán con posterioridad al lanzamiento de WPF.

Windows Presentation Foundation y otras tecnologías de Microsoft

Como la mayoría de las tecnologías nuevas de Microsoft, WPF influye en otras áreas del entorno de Windows. Pero, antes de pasar a analizar el impacto, es importante comprender que la instalación de WPF en un equipo no interrumpirá el funcionamiento de ninguna aplicación de software que use Windows Forms, MFC o cualquier otra tecnología existente. Mientras que las aplicaciones nuevas creadas para sistemas compatibles con .NET Framework 3.0 tomarán WPF como base para las interfaces que incluyen, las aplicaciones que usan tecnologías anteriores no cambiarán en absoluto.

Windows Presentation Foundation y Windows Forms

Desde el lanzamiento inicial de .NET Framework, se ha creado una gran cantidad de aplicaciones mediante Windows Forms. Incluso tras la publicación de WPF, algunas aplicaciones continuarán haciendo uso de Windows Forms. Por ejemplo, cualquier aplicación que se deba ejecutar en sistemas sin WPF, como versiones anteriores de Windows, probablemente elegirá Windows Forms como interfaz de usuario. Por otros motivos, las aplicaciones nuevas también favorecerán el uso de Windows Forms en lugar de WPF, por ejemplo, para disponer de acceso a la amplia gama de controles de Windows Forms.

Incluso las aplicaciones creadas con WPF pueden beneficiarse del uso de algunos aspectos de Windows Forms. Entre ellos destaca que, actualmente, Windows Forms incluye un conjunto de controles más extenso que WPF. El control DataGridView, introducido con la versión 2.0 de .NET Framework, no cuenta con un control análogo en WPF, y hay disponibles controles de Windows Forms creados por terceros para muchos otros usos. En algunos casos, tiene sentido dejar que las aplicaciones de WPF usen estos controles existentes. A la inversa, WPF ofrece muchas funciones que no se encuentran en Windows Forms, como gráficos 3D y animaciones. Así, también tiene sentido dejar que las aplicaciones de Windows Forms existentes incorporen algunos aspectos de la funcionalidad de WPF.

Ambas circunstancias pueden darse perfectamente. Las aplicaciones de WPF pueden alojar controles de Windows Forms y viceversa. Es posible que los usuarios interactúen con cuadros de diálogo de WPF y de Windows Forms en la misma aplicación sin tan siquiera notar la diferencia.

Para alojar controles de Windows Forms, las aplicaciones de WPF se sirven del control WindowsFormsHost de WPF. Este control permite alojar controles de Windows Forms, lo que permite su uso en aplicaciones de WPF. También admite el alojamiento de controles de ActiveX, de modo que las aplicaciones de WPF disponen de acceso a la gran biblioteca de controles existente basada en esta tecnología anterior. De forma similar, las aplicaciones de Windows Forms usan ElementHost, el control de Windows Forms que admite el alojamiento de controles, paneles y otros elementos de WPF. Las herramientas de cada una de estas tecnologías funcionan igualmente con aplicaciones de software creadas para la otra. El diseñador visual de WPF se puede usar para colocar controles de Windows Forms y viceversa.

No obstante, el uso conjunto de WPF y Windows Forms presenta algunas restricciones. Por ejemplo, no es posible colocar un control de WPF sobre un control de Windows Forms; este último siempre estará por encima. Los efectos de transparencia y transformaciones de WPF tampoco funcionan bien con los controles de Windows Forms. Además, los controles WindowsFormsHost y ElementHost requieren plena confianza, por lo que las aplicaciones de WPF que hagan uso de ellos no podrán ejecutarse como XBAP. Aun así, un gran porcentaje de las aplicaciones de Windows pueden usar tanto WPF como Windows Forms para la creación de su interfaz de usuario.

Windows Presentation Foundation y Win32/MFC

Con anterioridad a la publicación de .NET Framework en 2002, los desarrolladores de Windows solían crear interfaces de usuario mediante llamadas directas a API Win32 o MFC, que proporcionaban contenedores C++ en torno a estas API. En consecuencia, hoy día encontramos gran cantidad de código con interfaces de este estilo. ¿Qué ocurre con este código en un entorno de WPF?

La situación es similar a la que veíamos con Windows Forms. Igualmente en este caso, se pueden alojar controles de WPF en código de Win32/MFC existente y viceversa. De hecho, la base de interoperación entre WPF y Windows Forms está creada sobre los servicios de interoperabilidad de Win32/MFC. WPF incluye la clase HwndHost para permitir el uso de controles de Win32/MFC en WPF, y la clase HwndSource para facilitar el uso de controles de WPF en aplicaciones Win32/MFC. Estas clases se asignan a cada una de las tecnologías según sea necesario. Por ejemplo, HwndHost consigue que hWnd, que hace referencia a un control de Win32/MFC, presente la apariencia de un control de WPF. HwndSource hace lo contrario, es decir, el control de WPF se mostrará como hWnd

Al igual que ocurre con Windows Forms, la combinación de estos dos entornos presenta algunas limitaciones. En realidad, como la interoperabilidad de Windows Forms depende de HwndHost y HwndSource, todas las restricciones descritas anteriormente para los controles de Windows Forms (por ejemplo, con respecto a capas y transparencia) se aplican igualmente aquí. Además, al contrario que en Windows Forms, las aplicaciones que combinan WPF con código de Win32/MFC deben superar la complicación adicional que supone la interoperación entre el entorno de código administrado de WPF y el entorno sin administrar de Win32. Por este motivo entre otros, las aplicaciones de WPF que usan código de Win32/MFC no se pueden ejecutar como aplicaciones XBAP. Sin embargo, igual que antes, lo importante es que las aplicaciones de Windows pueden hacer un uso conjunto de WPF y Win32/MFC. El uso de WPF no implica la eliminación del código de interfaz de usuario existente en las aplicaciones.

Windows Presentation Foundation y Direct3D

Direct3D, parte de la familia de API de DirectX de Microsoft, es una herramienta esencial que los desarrolladores de Windows usan para crear gráficos tridimensionales. El lanzamiento de WPF no supone, de ningún modo, la eliminación de Direct3D. De hecho, como mencionamos anteriormente, WPF depende por completo de Direct3D para todas las tareas de representación. No obstante, WPF también permite crear gráficos 3D, de modo que los desarrolladores tendrán que elegir entre ambas tecnologías.

Pero la decisión no es especialmente complicada. Direct3D sigue siendo la mejor elección para el desarrollo intensivo de 3D, como juegos y aplicaciones técnicas basadas en aspectos tridimensionales (por ejemplo, aplicaciones de visualización científica de alto detalle). Al menos la primera versión de WPF no está diseñada como plataforma para estos tipos de software.

Sin embargo, WPF permite la creación y el uso de gráficos 3D a un público más amplio y menos especializado. Además, admite el uso de gráficos 3D por Web en XBAP y los integra de forma natural en gráficos 2D, documentos y otros aspectos de interfaz de usuario de aplicación. Las aplicaciones de WPF también pueden alojar código de Direct3D mediante la clase HwndHost descrita antes. WPF y Direct3D desempeñan papeles únicos, por lo que ambas tecnologías formarán parte esencial de la plataforma de Windows.

Windows Presentation Foundation y AJAX/"Atlas"

AJAX permite a los desarrolladores crear clientes de explorador más útiles para el usuario. Mediante AJAX, el usuario puede interactuar con un aplicación sin necesidad de actualizar la página (lo que conlleva la intervención del servidor web) con cada solicitud. Para conseguirlo, AJAX se basa en la compatibilidad del explorador con el objeto XMLHttpRequest, una idea que apareció por primera vez en Internet Explorer 5.0 a finales de los años 90. A mediados de la década siguiente, la compatibilidad con XMLHttpRequest era ya común en los exploradores, y así surgió el fenómeno de AJAX.

Pero la creación de clientes de AJAX no sigue un proceso sencillo. Con la intención de simplificarlo, Microsoft proporciona el conjunto de tecnologías que lleva por nombre en código "Atlas". Se trata de una serie de bibliotecas y controles, entre otros elementos, que sirven para crear aplicaciones de AJAX. Se compone de una biblioteca cliente de scripts compatible con varios exploradores (no sólo con Internet Explorer) y extensiones a ASP.NET en el servidor. El objetivo es simplificar la creación de aplicaciones web con clientes AJAX.

La compatibilidad generalizada con AJAX que ofrecen los exploradores es algo que los desarrolladores encuentran muy atractivo. No obstante, aunque AJAX permite crear interfaces mucho más interactivas a los usuarios de la Web, no incluye compatibilidad con una amplia gama de tipos de contenido. Gráficos, vídeo, animaciones y otros estilos de interacción más modernos no dependen únicamente de la compatibilidad con AJAX. En lo que respecta a clientes compatibles con WPF, es probable que las aplicaciones que necesitan estos componentes se creen como XBAP.

Windows Presentation Foundation y "WPF/E"

Mediante el uso de XBAP, las aplicaciones web pueden ofrecer a los usuarios gran parte de la funcionalidad de WPF. Sin embargo, las aplicaciones XBAP implican la instalación de WPF en el equipo cliente, lo que limita su ámbito de aplicación. ¿Qué hay de las aplicaciones web que requieren la presentación de interfaces modernas y que, además, deben permanecer accesibles para Macintosh y otros sistemas no compatibles con WPF?

La tecnología con nombre en código "WPF/E", de lanzamiento próximo, se ocupará de este problema. WPF/E proporcionará un subconjunto de funciones de WPF a diversas plataformas de cliente, entre las que se incluyen Macintosh y dispositivos pequeños, así como a varios exploradores web, como Internet Explorer, Firefox y Netscape. Estas funciones se aplican a gráficos bidimensionales, imágenes, vídeo, animaciones y texto. Sin embargo, parte de la funcionalidad de XBAP queda omitida en WPF/E, incluida la compatibilidad con gráficos tridimensionales, documentos y aceleración de hardware.

Los desarrolladores pueden usar JavaScript para crear aplicaciones de WPF/E. Asimismo, WPF/E incluirá un subconjunto de .NET Framework para varias plataformas, lo que permitirá el desarrollo en C# y Visual Basic. WPF/E no forma parte de .NET Framework 3.0, por lo que su lanzamiento no está programado hasta 2007. Una vez disponible, los creadores de aplicaciones web tendrán a su alcance una amplia gama de funciones aplicables a una serie de plataformas, lo que facilitará la creación de clientes.

Conclusión

Las interfaces de usuario constituyen una parte fundamental de la mayoría de las aplicaciones. La creación de interfaces de máxima eficacia puede ofrecer beneficios apreciables a los usuarios y las organizaciones que se sirven de ellas. El objetivo principal de WPF es ayudar a los desarrolladores a convertir estos beneficios potenciales en realidad. Para aquéllos involucrados en la creación o el uso de aplicaciones de Windows, WPF supone una gran noticia.

WPF ofrece una plataforma unificada para interfaces de usuario modernas, convierte a los diseñadores en participantes activos a la hora de crear estas interfaces y proporciona un modelo de programación común para aplicaciones independientes y de explorador. Con todo ello, WPF contribuirá a mejorar considerablemente la experiencia de los usuarios de Windows. Algunas de las tecnologías que reemplaza fueron base de interfaces de usuario de Windows durante veinte años. La intención de WPF es establecer una base para los próximos veinte años.

Acerca del autor

David Chappell es director de Chappell & Associates (http://www.davidchappell.com/) en San Francisco, California (EE.UU.). Con sus charlas, escritos y asesoramiento, David Chappell ayuda a expertos en tecnología de todo el mundo a comprender y usar software empresarial, así como a tomar decisiones más acertadas en relación con este tipo de aplicaciones.

Mostrar: