Fundamentos de Silverlight–Parte 1

¿Qué es Silverlight?

Silverlight es una tecnología que nos permite crear Aplicaciones Enriquecidas para Internet o RIA por sus siglas en inglés (Rich Internet Applications). Con Silverlight podemos construir aplicaciones que van desde pequeños componentes dentro de una página Web hasta sofisticadas Aplicaciones de Negocio que estén consumiendo y presentando datos de alguna base de datos, pasando por juegos casuales, reproductores de multimedios, Gadgets para Windows Vista o 7, y un largo etcétera.

Incluso después de más de 3 años de haber sido liberada al público en general su primera versión, aún existen muchas confusiones y malinterpretaciones acerca de esta tecnología. Primeramente, tenemos que decir que Silverlight es una tecnología multi-navegador, esto es, es capaz de ejecutar adentro de los navegadores más comunes disponibles hoy en día: Internet Explorer, FireFox, Chrome y Safari.

Por otro lado, Silverlight es una tecnología Multi-Plataforma, esto es, es capaz de ejecutar en los principales Sistemas Operativos disponibles hoy en día: Windows, Mac OSX y Linux (a través de Moonlight, proyecto que es llevado a cabo por la empresa Novell y que es la implementación de Silverlight para ese Sistema Operativo). Al momento de estar escribiendo este documento, Moonlight no tiene paridad 1 a 1 con las características de Silverlight 4. Para mayor información puedes consultar el roadmap de Moonlight en http://www.mono-project.com/MoonlightRoadmap

Silverlight, a diferencia de otras tecnologías Web del lado del Servidor (por ejemplo: ASP.NET, PHP, etc.), es una tecnología del lado del Cliente, es decir, todo el cómputo y ejecución de las aplicaciones sucede en el equipo del usuario, tal y como si se tratase de cualquier tipo de aplicación instalada. Esto es una gran ventaja ya que Silverlight puede sacar provecho de las características de procesamiento del hardware en donde está instalado.

Silverlight es un plugin que ofrece una experiencia de instalación muy similar a cualquier otro plugin para los navegadores. En el caso de la versión 5 (que es la versión más nueva disponible al momento de estar escribiendo esto) tiene un tamaño aproximado de 7 MB para el caso del Sistema Operativo Windows.

Durante el lanzamiento de Silverlight 4 en Abril 2010, se anunció que próximamente las aplicaciones de Silverlight podrán ejecutar en electrónicos de uso común en nuestros hogares, como televisores, reproductores de DVD, reproductores de Blu-Ray y cajas decodificadoras de cable para la TV. Asimismo, Silverlight es una de las plataformas de desarrollo para la nueva versión del Sistema Operativo móvil de Microsoft: Windows Phone 7. En conjunto con XNA como plataforma para la construcción de juegos 2D / 3D, Silverlight ofrece a los desarrolladores de Aplicaciones móviles una plataforma robusta, fácil de aprender y con una oferta de herramientas con alta funcionalidad.

Con lo anterior podemos deducir que Silverlight es una gran apuesta para ser una tecnología que sea capaz de ejecutar de la misma manera, en diferentes lugares: en los tres tipos de pantalla más comunes en la vida de las personas hoy en día (equipos de cómputo tradicionales como PC’s o Laptops, Televisores y teléfonos móviles). Un mismo código ejecutando en diferentes dispositivos, con diferentes resoluciones, con características de hardware diferente. Es de gran importancia esto ya que los desarrolladores podrán reutilizar sus conocimientos existentes en tecnología .NET para poder construir soluciones que lleguen a más personas y en lugares donde antes esto no era posible.

(Actualización del 20 de diciembre 2011)

Se presume que el nuevo dashboard de Xbox liberado en noviembre 2011 incluye Silverlight como la plataforma de desarrollo para sus aplicaciones. Sin embargo, aún no hay documentación técnica oficial al día de hoy que hable acerca de ello.

http://www.istartedsomething.com/20111206/the-future-of-xbox-is-apps-on-your-tv/ http://www.engadget.com/2011/10/10/microsoft-reportedly-preparing-silverlight-like-app-framework-ah/

Silverlight y HTML

El propósito de Silverlight nunca ha sido reemplazar HTML como tecnología de presentación de Interfaces de Usuario, sino complementarla con características y funcionalidades que no están disponibles en dicha tecnología. Si bien HTML es un estándar que pretende ser implementado de manera única y consistente en todos los navegadores disponibles hoy en día, esto en la práctica ha sido, es y será un proceso lento ya que podemos destacar una falta de quórum entre las principales empresas que respaldan sus navegadores, quienes (paradójicamente) implementan las especificaciones de estándares de manera diferente. Además si hablamos en términos de funcionalidad, Silverlight ofrece más y mejores características.

Otras consideraciones importantes son:

Rendimiento

El rendimiento de las Aplicaciones de Silverlight es superior gracias a que el código ejecuta bajo el Common Language Runtime (CLR), además de que cuenta con múltiples hilos de ejecución.

Consistencia

Silverlight se asegura de renderizar las Aplicaciones de manera consistente en cualquier lugar donde esté ejecutando

Tiempo

El tiempo de innovación es un punto muy importante ya que la evolución de la funcionalidad y características en las versiones futuras de Silverlight sucederán en un lapso de tiempo muy corto, a comparación de las especificaciones de estándares como HTML.

Para mayor información puedes consultar el siguiente artículo de Brad Becker, Director de Administración de Productos, Plataformas de Desarrollo: http://team.silverlight.net/announcement/the-future-of-silverlight/

Silverlight y el .NET Framework

Una característica muy importante acerca de Silverlight es que no requiere del .NET Framework tanto del lado del Cliente como del lado del Servidor. Del lado del Cliente es obvio ya que es precisamente a esto que podemos ejecutar aplicativos de Silverlight en Sistemas Operativos que no sean Microsoft Windows. Y más aún, también es independiente del .NET Framework del lado del Servidor: no es necesario tener instalado Internet Information Services (IIS) en nuestro Servidor Web, también puede ser Apache, Tomcat, etc.

(Actualización del 16 de septiembre 2011)

Silverlight y Windows 8

Durante el primer keynote del evento //Build/ que se llevó a cabo del 13 al 16 de Septiembre en Anaheim, CA., se mostró al mundo entero la plataforma de desarrollo de aplicaciones en el próximo Sistema Operativo de Microsoft: Windows 8. En Windows 8 habrá dos categorías de aplicaciones: Aplicaciones Metro, las cuales están enfocadas a dispositivos táctiles como tablets y Aplicaciones de Escritorio, las cuales son las aplicaciones de ventanas que todos conocemos con mecanismos de entrada tradicional de teclado y mouse, por ejemplo, Aplicaciones de Negocio (LOB por sus siglas en inglés), Aplicaciones de tipo OLTP, Herramientas, etc.

La plataforma de desarrollo para las Aplicaciones de Escritorio está basada en .NET y Silverlight, tal y como sucede hoy en día, por lo que no hay ningún tipo de cambio con respecto a las aplicaciones actuales.

Por otro lado, la plataforma de desarrollo para las Aplicaciones Metro está basada en Windows Runtime (WinRT, un API orientada a objetos alterna a Win32) y XAML o HTML. El motor de interpretación de XAML ha sido incorporado al core del Sistema Operativo ¡por lo que ahora más que nunca es muy importante conocer y dominar este importante lenguaje!

Como podrás observar en la ilustración anterior, en Windows 8 el .NET Framework y Silverlight siguen siendo las plataformas principales para la creación de Aplicaciones de Escritorio, ya que si bien es importante un soporte nativo a los dispositivos con pantallas táctiles, hay muchos escenarios en donde no hace sentido tener una aplicación de este estilo, por lo que las Aplicaciones de Escritorio seguirán siendo la principal categoría durante muchos años por venir.

Fundamentos de Silverlight–Parte 2

Versiones de Silverlight

La historia de Silverlight se remonta al año 2007, cuando aún se denominaba WPF/e (acrónimo de Windows Presentation Foundation / everywhere, debido a su íntima relación con esa tecnología y por tener como objetivo ser precisamente multi-plataforma). En aquel tiempo fue liberada al público la versión 1.0, que su objetivo principalmente estaba enfocado en la reproducción de multimedios. El modelo de programación de esta primera versión estaba reducido a utilizar JavaScript como lenguaje para la construcción de aplicaciones e incluía únicamente figuras básicas y texto para crear las Interfaces de Usuario. Fue hasta la versión 1.1 que Microsoft habría anunciado estaría disponible la plataforma de desarrollo de .NET para poder construir aplicaciones ya que Silverlight incluiría una implementación del CLR. Esta

versión fue posteriormente renombrada a Silverlight 2, por tratarse de una liberación con una gran cantidad de cambios y mejoras y que merecía una asignación de versión mayor. Fue a partir de este momento en donde muchos desarrolladores y empresas voltearon a ver esta tecnología, ya que en pocas palabras, significaba poder programar con la comodidad y robustez de Visual Studio .NET y con alguno de los lenguajes de dicha plataforma, pero no únicamente para Windows sino para Mac también.

Posteriormente fue anunciada la versión 3 que incluiría más y mejores características pero ahora enfocadas principalmente a la construcción de aplicaciones de negocio. Características como ejecución Afuera del Navegador, más controles para datos, el Framework de Navegación, Pixel Shaders, soporte para ClearType, Conexiones Locales y una gran cantidad de componentes fueron liberadas en esta versión.

En Silverlight 4 se agregaron más características para Aplicaciones de Negocio, como la Confianza Elevada, con la cual prácticamente no hay ningún límite en lo que pueden hacer las aplicaciones de Silverlight.

[Acualización del 14/Ene/2012] Silverlight para Windows Phone 7.1 (nombre clave "Mango") – la nueva versión del Sistema Operativo móvil de Microsoft está basado en Silverlight 4. Esto quiere decir que la gran mayoría de las características incorporadas en Silverlight 4 están disponibles en las aplicaciones para Windows Phone 7.1; solo algunas cosas contadas no estarán disponibles. Para mayor información consulta esta página.

[Acualización del 14/Ene/2012]

La última versión disponible de Silverlight al momento de estar escribiendo este texto es Silverlight 5, liberado durante el día 09 de Diciembre 2011 la cual incluye aún más características y componentes específicamente enfocados (sin estar sujetos únicamente a) a la creación de Aplicaciones de Negocio: Confianza Elevada en aplicaciones dentro del navegador, p/Invoke, soporte a Múltiples Ventanas, Plantillas de Datos Implícitas, Enlace Ancestor Relative, Extensiones del Marcado Personalizadas, Soporte a 64 bits, entre muchos otros. Para mayor información consulta esta página.

Gracias a lo anterior, Silverlight se está convirtiendo cada vez más en la plataforma elegida y preferida para el desarrollo de aplicativos de negocio, modernos, multi-plataforma, con alta funcionalidad y respaldadas por robustas herramientas bien conocidas en el ámbito del desarrollo en .NET.

Fundamentos de Silverlight–Parte 3

Plataformas y Navegadores Soportados

Silverlight 4 soporta las siguientes versiones de Sistemas Operativos:

Sistema Operativo VersionesWindows Windows 2000 SP4, Windows XP, Windows Vista, Windows 7,

Windows 8Mac OS 10.4.11 en adelanteLinux A través de Moonlight*

*Al día de hoy, Moonlight no tiene una paridad 1:1 en funcionalidad con Silverlight 4, por lo que probablemente no todas las aplicaciones ejecuten de la misma manera en ese sistema operativo. Para mayor información acerca de Moonlight puedes consultar su sitio oficial.

Silverlight 4 soporta los siguientes navegadores:

Firefox 2+ Internet Explorer 6+ Chrome 4+ Safari 4+

Fundamentos de Silverlight–Parte 4

Herramientas relacionadas

Si bien es técnicamente posible poder crear una aplicación de Silverlight haciendo uso simplemente del Bloc de Notas, al hacer esto lo único que estaríamos haciendo es demostrar lo geek que somos y que tal vez tenemos mucho tiempo libre. Es por esto que siempre debemos utilizar herramientas que nos permitan ser lo más eficientes que podamos, y que nuestro tiempo se enfoque únicamente a resolver los problemas que estamos tratando de resolver inicialmente al crear una aplicación.

La herramienta por excelencia para la creación de aplicaciones –no solo de Silverlight, sino en general de .NET- es Visual Studio .NET. La última versión de esta herramienta (por lo menos al estar escribiendo este texto) es Visual Studio .NET 2010. Existen una gran cantidad de ediciones de Visual Studio .NET 2010 y cualquier edición nos servirá para construir aplicativos de Silverlight 4, desde la versión Ultimate que es la más completa hasta la versión Visual Web Developer Express 2010 que es totalmente gratuita y es extraordinaria opción para iniciarse en el mundo de desarrollo de aplicaciones Web con .NET. Nos referiremos como “Visual Studio .NET” en todo este libro a cualquier edición que hayas instalado de la versión 2010.

Tener instalado Visual Studio .NET es insuficiente, ya que únicamente trae soporte para la versión de Silverlight 3. Para poder tener soporte a la versión 4 debemos descargar e instalar las herramientas de Visual Studio .NET 2010 para Silverlight 4. Esta es una descarga de aproximadamente 25 MB y que una vez que las hayas instalado se habrán incluido los siguientes componentes:

El motor de ejecución de Silverlight 4 para desarrollo y depuración SDK de Silverlight 4 Una actualización para Visual Studio .NET para soportar Silverlight 4 WCF RIA Services

Herramientas Opcionales

Prácticamente con lo anterior tenemos todo lo necesario para comenzar a construir aplicativos de Silverlight 4. No obstante, hay una gran cantidad de herramientas y programas que podemos utilizar para poder hacer nuestro trabajo más sencillo. A continuación, se enlistan algunas de las más destacables.

Expression Blend 4

Herramienta enfocada para el diseño de Interfaces de Usuario con Silverlight y WPF. Si bien esta herramienta la estoy considerando como opcional -porque técnicamente no es requisito- es de suma importancia y altamente recomendable que también la tengamos a la mano para poder editar el código XAML de una manera más fácil. Expression Blend está enfocada al rol de diseñador e incluye diferentes características que en Visual Studio .NET no es posible encontrar, como por ejemplo: la creación y edición de Storyboards de animaciones, manejo y administración de los Diccionarios de Recursos, creación de Estilos, modificación de Plantillas de Controles, etc. Para mayor información consulta http://www.microsoft.com/Expression.

Windows Phone 7 Developer Tools

Estas son las herramientas necesarias para construir aplicaciones para Windows Phone 7. Incluye las plantillas necesarias para Visual Studio .NET y el Emulador de Windows Phone 7 para poder depurar nuestro código. Para mayor información consulta http://www.windowsphone7.com.

Silverlight Toolkit

Por cuestiones de tamaño, el plugin de Silverlight incluye un número limitado de controles que podemos utilizar sin necesidad de referenciar alguna biblioteca externa. El Silverlight Toolkit es un proyecto de código fuente abierto soportado y respaldado por Microsoft en donde podemos encontrar una gran cantidad de controles extra para Silverlight. Para mayor información consulta http://www.codeplex.com/Silverlight.

Deep Zoom Composer

Herramienta que nos ayuda a procesar imágenes para su despliegue en el control MultiScaleImage (imágenes que tienen una secuencia de tamaños y resoluciones para poder construir aplicaciones de tipo Deep Zoom). Para mayor información consulta http://www.microsoft.com/downloads.

Fiddler

Fiddler nos permite inspeccionar todo el tráfico que sucede en HTTP o HTTPS. Nos ayuda a conocer a detalle las peticiones y respuestas que están sucediendo cuando nos estamos comunicando desde nuestro aplicativo de Silverlight a algún lado. Para mayor información consulta http://www.fiddler2.com.

Reflector

Nos permite inspeccionar los ensamblados de .NET y conocer su código original. Para mayor información consulta http://www.red-gate.com/products/reflector.

Silverlight Spy

Silverlight Spy es una herramienta que nos permite inspeccionar una aplicación de Silverlight cuando se está ejecutando, su árbol de elementos visuales, su código XAML e incluso su código fuente. Para mayor información consulta http://firstfloorsoftware.com.

Control Bing Maps

El control de Bing Maps para Silverlight es un control que nos ayuda a poner un mapa en nuestras aplicaciones para incluir características de geo localización. Para mayor información consulta http://www.microsoft.com/downloads.

Fundamentos de Silverlight–Parte 5

Estructura de los Proyectos

Comencemos creando un nuevo proyecto de Silverlight 4. Al igual que cualquier otro tipo de proyecto al utilizar Visual Studio .NET podemos seleccionar de toda la lista de plantillas que tengamos instaladas la adecuada para nuestros propósitos.

La siguiente figura muestra la caja de diálogo de creación de un nuevo proyecto en Visual Studio .NET. Notemos que la en la sección de plantillas instaladas en la parte izquierda tiene seleccionada la opción de “Silverlight”. Al hacer esto nos mostrará la lista de todas las plantillas instaladas para esta plataforma.

Figura 2: Nuevo Proyecto de Silverlight

Al hacer clic en el botón “OK” Visual Studio nos mostrará otra caja de diálogo la cual contiene información relacionada al proyecto que estamos creando. Por ejemplo, nos preguntará si deseamos un crear un proyecto Web relacionado. La necesidad de crear un proyecto Web relacionado o no lo detallaremos más adelante. Asimismo nos ofrece la opción de seleccionar la versión de Silverlight a la que queremos apuntar; esta es una opción bastante útil si estamos creando por ejemplo un Ensamblado para un proyecto de Silverlight para Windows Phone 7 que necesitemos compartir su funcionalidad para un proyecto de Silverlight 4. Por último, la caja de diálogo nos preguntará si deseamos habilitar los WCF RIA Services para este proyecto en cuestión (de manera predeterminada esto no estará habilitado).

La Figura 3 muestra la caja de diálogo con todas las opciones que estamos detallando:

Figura 3: Opciones iniciales

En lo que a nuestra aplicación respecta, aceptaremos todos los valores predeterminados y haremos clic en el botón OK de esta caja de diálogo. Al hacer esto Visual Studio cerrará la ventana y creará una Solución con el mismo nombre que indicamos en el paso anterior y dos proyectos, un proyecto para nuestra aplicación de Silverlight 4 y otro proyecto será el proyecto Web (que elegimos sí crear en el paso que acabamos de describir).

Figura 4: Estructura de la Solución

Proyecto de Silverlight

El proyecto de Silverlight incluye diversos elementos que automáticamente incluye Visual Studio por nosotros. A continuación los enlistamos y describimos:

Fólder “Properties”

AppManifest.xml

Manifiesto de la Aplicación de Silverlight.

AssemblyInfo.cs

Archivo que incluye atributos globales para el Ensamblado de la Aplicación de Silverlight.

Fólder “References”

Muestra la referencias a Ensamblados de .NET que tiene actualmente el proyecto.

App.xamlEn la práctica, es posible borrar ambos archivos App.xaml y su code-behind y compilar así el proyecto: no causará ningún tipo de error en la compilación. No obstante, al hacer esto únicamente veremos la animación inicial de Silverlight sin ningún tipo de funcionalidad adicional. Moraleja: déjalos como están

El archivo App.xaml representa el XAML global para la Aplicación. En él podemos declarar recursos globales y/o referencias a Diccionarios de Recursos externos. Debemos tener un archivo de esta naturaleza en cada Aplicación de Silverlight. Su nombre es totalmente arbitrario.

App.xaml.cs

Archivo de code-behind para la Aplicación. En él encontraremos los manejadores de eventos globales para la Aplicación.

MainPage.xaml

Representa la “pantalla” principal para la Aplicación. Este archivo comúnmente se abre automáticamente en el diseñador interactivo de Visual Studio. Su nombre es totalmente arbitrario.

MainPage.xaml.cs

Archivo de code-behind para la pantalla principal de la Aplicación. En él escribiremos los manejadores de eventos y código en general para darle funcionalidad a nuestro aplicativo.

Proyecto Web

Este proyecto es creado únicamente si así lo indicamos en la caja de diálogo de opciones iniciales como se muestra en la Figura 3. Este proyecto está estructurado de manera predeterminada como a continuación se indica:

Fólder “Properties”

Incluye el archivo AssemblyInfo.cs específico para el proyecto Web

Fólder “References”

Indica los Ensamblados referenciados en el proyecto

Fólder ClientBin

El fólder ClientBin es el fólder destino en donde se copiará la Aplicación de Silverlight automáticamente cuando compila. Su nombre es totalmente arbitrario.

Páginas XXXTestPage.aspx y XXXTestPage.html

Los archivos .aspx y .html que incluye el proyecto Web nos servirán para probar la Aplicación de Silverlight adentro de un navegador ya que incluyen por dentro el elemento <object> que representa la instancia del aplicativo como tal. Sus nombres son totalmente arbitrarios.

Silverlight.js

Este archivo incluye diversas funciones para el hospedaje de la Aplicación de Silverlight en páginas html.

Web.config

Archivo de configuración propio del proyecto de ASP.NET

Agregando un poco de funcionalidad…

A través del diseñador interactivo en Visual Studio y la caja de herramientas agreguemos un botón (control Button) y un bloque de texto (elemento TextBlock) a MainPage.xaml tal y como lo muestra la siguiente figura:

Al agregar cada uno de los elementos podemos observar que el código XAML de MainPage.xaml es modificado automáticamente por Visual Studio, esa es precisamente la finalidad del diseñador interactivo: el permitirnos crear y modificar nuestra Interface de Usuario sin necesidad de escribir el código XAML de manera manual.

Ahora bien, hagamos doble-clic en el botón para que Visual Studio cree automáticamente el manejador del evento predeterminado de dicho control, en este caso el evento Click. En el evento Click cambiaremos el texto del bloque de texto por la fecha y hora actual. La siguiente caja de texto muestra el código completo del manejador del evento:

1: private void button1_Click(object sender, RoutedEventArgs e) 2: { 3: textBlock1.Text = DateTime.Now.ToString(); 4: }

Esta será toda la funcionalidad que implementemos por el momento. Ahora vayamos a analizar con más detalle el modelo de compilación de las Aplicaciones de Silverlight.

Fundamentos de Silverlight–Parte 6

Modelo de Compilación

El proyecto de Silverlight no es más que un proyecto de tipo Class Library (Biblioteca de Clases). Esto quiere decir que cuando compilamos el proyecto de la Aplicación de Silverlight el resultado de la compilación será un Ensamblado llamado NombreDelProyecto.dll, donde NombreDelProyecto es el nombre que indicamos al crear un nuevo proyecto de este tipo.

Además de lo anterior, el proyecto de Silverlight está preparado para que posteriormente de haber compilado el archivo DLL, se empaquete en un archivo con extensión .xap. El archivo XAP (pronunciado “ZAP”) es copiado automáticamente al fólder ClientBin en el proyecto Web relacionado. Todo esto lo hará Visual Studio sin nuestra intervención.

Ahora bien, ¿qué es el archivo XAP?

El Archivo XAP

El archivo XAP representa el aplicativo de Silverlight como tal, es decir, el archivo XAP es la unidad de despliegue de las aplicaciones de Silverlight. Si bien su extensión es totalmente arbitraria, el archivo XAP es un empaquetado de tipo ZIP que por dentro incluye todos los elementos necesarios para la correcta ejecución de la Aplicación de Silverlight. Esto lo podemos demostrar si cambiamos la extensión del archivo por .zip como a continuación muestra la siguiente figura:

Figura 5: Contenido del Archivo XAP

La figura muestra WinRAR –una utilería para la apertura o creación de archivos ZIP, RAR entre otros- y el contenido de dicho archivo.

Podemos apreciar entonces que el archivo XAP incluye: el Ensamblado principal de la Aplicación y el Manifiesto de la Aplicación (archivo AppManifest.xaml).

Ensamblado Principal

El Ensamblado Principal es el resultado de la compilación del proyecto de Silverlight y no es diferente a cualquier otro DLL de .NET que hayamos utilizado con anterioridad. Por lo tanto, el Ensamblado será código MSIL (Código Intermedio de Microsoft, por su acrónimo en inglés Microsoft Intermediate Language) el cual todo compilador de .NET está preparado para generar.

Esto es de vital importancia conocerlo ya que el DLL principal puede ser extraído como cualquier otro archivo incluido en un empaquetado ZIP y abierto con alguna herramienta para interpretación de código MSIL como Reflector. Debido a esto, es importante ofuscar el código a través de alguna herramienta de Ofuscación preparada para ello. La siguiente figura muestra el Ensamblado principal de la Aplicación siendo abierto por Reflector y mostrando el código intermedio que dejó el compilador de C#, e interpretado de regreso a ese lenguaje:

El Manifiesto de la Aplicación

Si abrimos el archivo AppManifest.xaml que incluye por dentro el archivo XAP, podemos darnos cuenta que su contenido es diferente a como lo tenemos en tiempo de diseño dentro de Visual Studio en el panel del Explorador de Soluciones. Esto es debido a que sus datos se establecen únicamente al compilar el proyecto de Silverlight.

El Manifiesto es un elemento de tipo <Deployment> que tiene los siguientes atributos:

EntryPointAssembly

Indica cuál es el Ensamblado que debe iniciar al ejecutar la Aplicación. De manera predeterminada apuntará al Ensamblado principal de la Aplicación.

EntryPointType

Indica cuál es la clase que debe iniciar cuando la Aplicación ejecute. Esto es análogo por ejemplo a un aplicativo de tipo Consola creada con el lenguaje C# en donde contamos con un método static void Main() que representa el punto de entrada del aplicativo. De manera predeterminada este atributo apuntará a la clase App que incluyó automáticamente Visual Studio al crear un proyecto de tipo Silverlight.

RuntimeVersion

Indica la versión de Silverlight con la que fue compilada la Aplicación. Este atributo también es de particular importancia ya que será este valor el que valide si el usuario tiene la versión mínima correcta para ejecutar la Aplicación de Silverlight o no.

Además, el elemento <Deployment> en el manifiesto incluirá una sección llamada <Deployment.Parts> la cual indica cuáles son todos los Ensamblados que constituyen la Aplicación de Silverlight. Podemos deducir entonces que esta sección estará directamente relacionada con las referencias a Ensamblados externos que incluyamos.

La siguiente caja de texto muestra el contenido completo del archivo AppManifest.xaml relacionado al proyecto que creamos con anterioridad:

<Deployment xmlns="http://schemas.microsoft.com/client/2007/deployment" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" EntryPointAssembly="Fundamentos.Inicial" EntryPointType="Fundamentos.Inicial.App" RuntimeVersion="4.0.50826.0"><Deployment.Parts>

<AssemblyPart x:Name="Fundamentos.Inicial" Source="Fundamentos.Inicial.dll" /></Deployment.Parts> </Deployment>

Fundamentos de Silverlight–Parte 7

Comprender el modelo de compilación de las Aplicaciones de Silverlight es únicamente el primer paso. ¿Qué sucede cuando a través de un navegador, entramos a una página que incluye un aplicativo de Silverlight?

Para responder a lo anterior es buena idea ejecutar el proyecto que tenemos en Visual Studio presionando F5. Visual Studio levantará el ASP.NET Development Server (antes conocido como “Cassini”), abrirá automáticamente el navegador que tenemos configurado como predeterminado y solicitará la página .aspx (esa página es la que está configurada como predeterminada, podemos cambiar este comportamiento si hacemos clic derecho sobre el archivo .html y seleccionamos la opción “Set As Start Page…”).

Con la aplicación ejecutando dentro del navegador predeterminado podemos observar que efectivamente el texto del bloque de texto es cambiado por la fecha y hora actual, tal y como lo expresamos a través de código anteriormente. ¡Hemos creado nuestra primera Aplicación de Silverlight 4!

Detengámonos un poco en el URL que está en el navegador. Podemos ver que se trata efectivamente de la página .aspx que tenemos en nuestro proyecto Web relacionado. No obstante, también podemos darnos cuenta que ¡nuestra Aplicación de Silverlight está ejecutando adentro de la página!

Las Aplicaciones Silverlight deben ser hospedadas en una página HTML como mínimo, pudiendo ser ASP, ASP.NET, JSP, PHP, etc.

Además, tal y como lo describimos al inicio, Silverlight es una tecnología Web del lado del Cliente y por tal motivo todo el cómputo y ejecución sucede en la máquina del usuario, no en el Servidor. Tomemos el botón como ejemplo: al hacer Click en el botón no está enviando la página de regreso al Servidor como sucede con botones de ASP.NET (elemento <asp:Button />). Nuestro código ejecuta de manera local y por tal motivo podemos construir Aplicaciones altamente funcionales y robustas, usando los lenguajes compatibles con la plataforma .NET (como C# en este caso). Lo anterior es de suma importancia tenerlo en cuenta siempre ya que es un paradigma un poco diferente para los desarrolladores de tecnologías Web tradicionales.

Entonces, regresándonos a la pregunta inicial: ¿Qué sucede cuando a través de un navegador, entramos a una página que incluye un aplicativo de Silverlight? A continuación la respuesta:

1. El navegador realiza una petición a la página indicada en el URL

2. El Servidor recibe la petición, la interpreta y prepara la respuesta

3. La respuesta (HTML + Script) es enviada de regreso al navegador

4. El navegador recibe la respuesta y dibuja el HTML + Script

5. Al detectar la instancia de una Aplicación de Silverlight, solicita el archivo XAP en cuestión (expresado en el parámetro “source” del elemento <object>) y lo copia 100% del Servidor al Cliente. Es durante esta fase cuando vemos la ya tradicional pantalla de precarga de Silverlight: unas burbujas azules que dan vueltas e informan un porcentaje de avance. Ese porcentaje de avance es el porcentaje de copiado del archivo XAP del Servidor a la máquina del usuario.

6. Una vez copiado el archivo XAP, es puesto en Cache como cualquier otro elemento de la página Web, para que en una petición subsecuente no lo vuelva a copiar sino que lo tome directamente del Cache del navegador.

Por esta razón, una de las mejores prácticas al construir soluciones con Silverlight es el archivo XAP (la Aplicación per sé) sea lo más pequeña posible, para que el tiempo de descarga sea lo más corto y la experiencia que tenga el usuario al usar nuestro aplicativo sea positiva. Simplemente imaginemos ¿qué pasaría si el archivo XAP midiera 30 MB y el ancho de banda del usuario que está consumiendo la Aplicación es muy reducido? No necesitamos realmente analizar mucho la respuesta para determinar que el tiempo de carga se extendería a niveles inaceptables para la mayoría de las personas.

Hay diferentes mecanismos y prácticas para mejorar el rendimiento que percibe el usuario de nuestra aplicación, siendo el reducir de tamaño el XAP lo más que sea posible. Para lograr esto podemos utilizar la siguiente técnica que detallaremos a continuación.

Fundamentos de Silverlight–Parte 8

Cacheo de Ensamblados

Como lo describimos en una sección anterior, al compilar un proyecto de Silverlight se creará el empaquetado XAP que contiene todos los Ensamblados necesarios para poder ejecutar la Aplicación. Estos Ensamblados son parte del empaquetado para poder estar disponibles de manera inmediata cuando la Aplicación este corriendo, no obstante el tamaño de dichos archivos impacta de manera directa el tamaño final del archivo XAP.

Cuando referenciamos Ensamblados externos, estos Ensamblados son incluidos como parte del archivo XAP. Un ejemplo claro de esto es el uso del control DataGrid. El control DataGrid es un control que nos permite desplegar datos de manera tabular en nuestros aplicativos. No obstante, el control DataGrid no pertenece al núcleo de Silverlight per se, sino que es parte del SDK de Silverlight.

Si arrastramos el control DataGrid de la caja de herramientas y lo soltamos en el diseñador interactivo de Visual Studio podemos percatarnos que por el simple hecho de estarlo declarando, el DataGrid referencia los siguientes Ensamblados:

System.ComponentModel.DataAnnotations.dll System.Windows.Controls.Data.dll System.Windows.Controls.Data.Input.dll System.Windows.Data.dll

La figura anterior muestra el contenido del archivo XAP, al haber declarado el control DataGrid dentro de nuestra Aplicación. Como podemos observar, los archivos que se incluyen ahora son más, si lo comparamos con la lista de archivos cuando inicialmente creamos el proyecto. Esto también se ve reflejado en el Manifiesto de la Aplicación:

<Deployment xmlns="http://schemas.microsoft.com/client/2007/deployment" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" EntryPointAssembly="Fundamentos.Inicial" EntryPointType="Fundamentos.Inicial.App" RuntimeVersion="4.0.50826.0"> <Deployment.Parts> <AssemblyPart x:Name="Fundamentos.Inicial" Source="Fundamentos.Inicial.dll" /> <AssemblyPart x:Name="System.ComponentModel.DataAnnotations" Source="System.ComponentModel.DataAnnotations.dll" /> <AssemblyPart x:Name="System.Windows.Controls.Data" Source="System.Windows.Controls.Data.dll" /> <AssemblyPart x:Name="System.Windows.Controls.Data.Input" Source="System.Windows.Controls.Data.Input.dll" /> <AssemblyPart x:Name="System.Windows.Data" Source="System.Windows.Data.dll" />

</Deployment.Parts> </Deployment>

El elemento <Deployment.Parts> ahora incluye los archivos que requiere el control DataGrid. Esto mismo sucedería al estar referenciando cualquier tipo de Ensamblado externo, ya sea de terceros o propio. En este momento, el archivo XAP mide aproximadamente 220 KB ya empacado.

Si abrimos las propiedades del proyecto de Silverlight, encontraremos -entre otras opciones- la opción para reducir el tamaño del archivo XAP, a través del Cacheo de Ensamblados.

Al compilar nuevamente el proyecto de Silverlight nos podemos percatar de que ahora cada uno de los Ensamblados referenciados (indicados en la lista anteriormente) ha sido empaquetado en un archivo ZIP de manera individual, y cada uno ha sido copiado al fólder ClientBin, al lado del archivo XAP de la Aplicación.

Además, si abrimos nuevamente el archivo XAP veremos que los Ensamblados ya no son incluidos como parte del XAP…

…que el tamaño del archivo se ha reducido dramáticamente…

…y que el Manifiesto de la Aplicación ha sido modificado para indicar que ahora esos Ensamblados son externos. Esto queda expresado a través del elemento <Deployment.ExternalParts> como a continuación se muestra en la siguiente caja de texto:

<Deployment xmlns="http://schemas.microsoft.com/client/2007/deployment" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" EntryPointAssembly="Fundamentos.Inicial" EntryPointType="Fundamentos.Inicial.App" RuntimeVersion="4.0.50826.0"> <Deployment.Parts> <AssemblyPart x:Name="Fundamentos.Inicial" Source="Fundamentos.Inicial.dll" /> </Deployment.Parts> <Deployment.ExternalParts> <ExtensionPart Source="System.ComponentModel.DataAnnotations.zip" /> <ExtensionPart Source="System.Windows.Controls.Data.zip" /> <ExtensionPart Source="System.Windows.Controls.Data.Input.zip" /> <ExtensionPart Source="System.Windows.Data.zip" /> </Deployment.ExternalParts></Deployment>

Ahora la Aplicación ha sido configurada para que los ensamblados externos sean descargados de manera individual y sean colocados en el Cache del navegador pero únicamente la primera vez, para que en ejecuciones subsecuentes de la Aplicación, los Ensamblados –si no han sido modificados- los cargue directamente del Cache y no del Servidor. Esto asegurará que únicamente sea descargado el archivo XAP, que por el hecho de haber reducido su tamaño ahora la Aplicación cargará más rápido.

Esta técnica para reducir el tamaño de los archivos XAP funciona tanto para los Ensamblados que pertenecen al SDK de Silverlight, los del Silverlight Toolkit e incluso en nuestros propios Ensamblados. Para hacer esto lo único que necesitamos es crear un archivo XML de metadatos para cada uno de ellos.

Creación del Archivo de Mapeo

Para que podamos Cachear Ensamblados propios, necesitamos crear un archivo con el mismo nombre que el Ensamblado en cuestión pero con extensión extmap.xml. Por ejemplo, si nuestro Ensamblado se llamase Utilerias.dll, el archivo de Mapeo deberá llamarse Utilerias.extmap.xml y deberá estar al lado del archivo .dll original.

El contenido del archivo de Mapeo será el siguiente:

<?xml version="1.0"?><manifest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <assembly> <name>NOMBRE DEL ENSAMBLADO</name> <version>VERSION DEL ENSAMBLADO</version> <publickeytoken>PUBLIC KEY TOKEN</publickeytoken> <relpath>RUTA DEL DLL</relpath> <extension downloadUri="NOMBRE DEL ARCHIVO ZIP A DESCARGAR" /> </assembly> </manifest>

Los elementos deberán empatar los valores del Ensamblado en cuestión. Asimismo, debemos tomar en cuenta que el Ensamblado deberá estar firmado con una llave de Strong Name usando la utilería sn.exe o directamente usando el panel de propiedades del proyecto del Ensamblado para crear la llave criptográfica.

Comprobación del Cacheo de Ensamblados

Una manera sencilla para comprobar si el Cacheo de Ensamblados está funcionando o no es publicar la Aplicación a un sitio Web público y accesible y utilizar alguna herramienta de inspección como Fiddler.

En este caso publicaré la Aplicación de ejemplo en mi sitio rdiazconcha.com a través del copiado de los archivos vía FTP. Los archivos publicados serán la página .aspx y el fólder ClientBin. El URL final para este ejemplo de comprobación será: http://rdiazconcha.com/Fundamentos/Fundamentos.InicialTestPage.aspx

Si abrimos Fiddler para inspeccionar todo el tráfico de HTTP y abrimos un navegador que haga una petición al URL indicado nos daremos cuenta que efectivamente la primera vez que ejecutamos la Aplicación todos los Ensamblados son descargados posterior a la descarga del archivo XAP principal, ya que no existen en el Cache del navegador aún.

Si abrimos una nueva instancia del navegador y volvemos a hacer una petición a la misma página, nos daremos cuenta que ni la Aplicación ni los Ensamblados ya no serán descargados, sino tomados del Cache del navegador.

Ahora bien, si hacemos algún cambio en los archivos ZIP de los Ensamblados –por ejemplo borrarlos de ClientBin y volver a recompilar toda la Solución para que se regeneren y tengan una nueva estampa de tiempo- y publicamos los archivos nuevamente veremos que efectivamente los archivos ZIP son descargados nuevamente y no son tomados los del Cache. Para este ejemplo volví a publicar únicamente el archivo System.Windows.Data.zip en mi sitio con una nueva estampa de tiempo. Al volver a hacer la petición de la página el resultado que arroja Fiddler será el siguiente:

De esta manera podemos comprobar que únicamente se descargan los archivos que hayan sido actualizados, el resto serán adquiridos a través del Cache del navegador en cuestión.

Fundamentos de Silverlight–Parte 9

Clase UserControl

Enfoquémonos ahora en MainPage.xaml por tratarse de un archivo de suma importancia ya que es ahí donde expresamos la Interface de Usuario para nuestra Aplicación. Si abrimos este archivo en Visual Studio podremos observar que su código comienza con la declaración de un elemento de tipo <UserControl> . Es en este elemento en donde se indica cuál es la clase de código relacionada para este código XAML en específico, además de importar los espacios de nombres requeridos por el intérprete de XAML (el único espacio de nombres requerido por el intérprete de XAML es el indicado con la línea xmlns=”…”):

<UserControl x:Class="Fundamentos.Inicial.MainPage" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" xmlns:d="http://schemas.microsoft.com/expression/blend/2008" xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" mc:Ignorable="d" d:DesignHeight="300" d:DesignWidth="400" xmlns:sdk="http://schemas.microsoft.com/winfx/2006/xaml/presentation/sdk"> …

La clase de código relacionada (Fundamentos.Inicial.MainPage) es en donde escribiremos la funcionalidad que necesite la aplicación, por ejemplo, los manejadores de eventos para los controles, etc. La clase UserControl hereda indirectamente de la clase UIElement que analizaremos a continuación.

Los espacios de nombres (namespaces) mostrados en el código anterior son necesarios cuando requerimos traer a nuestro ámbito las clases y elementos que estos contienen. Esto es también cierto si deseas declarar instancias de tus propios objetos a través de XAML. Esto es análogo a la cláusula using en el lenguaje de programación C# o la cláusula Imports en Visual Basic .NET. Los alias que utilizan los espacios de nombres son totalmente arbitrarios y solamente se utilizan para mejor legibilidad del código.

Fundamentos de Silverlight–Parte 10

Clase UIElement

La clase UIElement es la clase base para todos los elementos visuales en Silverlight. En esta clase es en donde se definen la gran mayoría de los eventos de interacción con el usuario (eventos del mouse, teclado, enfoque, etc.). Algunos de los eventos incluidos en esta clase son:

MouseLeftButtonDown MouseLeftButtonUp MouseRightButtonDown MouseRightButtonUp MouseEnter MouseLeave Drop

Eventos Ruteados

La mayoría de los eventos anteriores que expone la clase UIElement son ruteados, esto es, son eventos que van escalando desde lo más profundo del árbol de objetos de XAML hacia arriba (a este término se le denomina bubbling en inglés). En los argumentos de este tipo de eventos podremos encontrar la propiedad Handled, la cual indica si el evento sigue escalando o no. Debido a la naturaleza que tienen los eventos ruteados podríamos crear manejadores de eventos globales para diversos elementos visuales.

Fundamentos de Silverlight–Parte 11

Manejo de Eventos

En Silverlight tenemos tres maneras diferentes para poder manejar eventos.

Desde XAML A través de código usando la sintaxis estándar A través de código usando Expresiones Lambda

Manejo de eventos usando XAML

Podemos manejar los eventos de los elementos usando XAML. La siguiente caja de texto demuestra el manejo del evento Click del control Button:

…<Button Click="Button_Click" /> …

…y su código relacionado usando el lenguaje C#:

private void Button_Click(object sender, RoutedEventArgs e){ //Manejo del evento}

Manejo de eventos usando la sintaxis del lenguaje

Como cualquier otro evento en C#, podemos usar el operador sobrecargado += para asignar el método que deseamos que se ejecute cuando el evento sea disparado. La siguiente caja de texto demuestra la asignación del método button1_Click al evento Click de un botón:

this.button1.Click += new RoutedEventHandler(button1_Click);private void button1_Click(object sender, RoutedEventArgs e) { //Manejo del evento }

Manejo de eventos usando Expresiones Lambda

Las expresiones lambda son funciones anónimas que podemos utilizar para crear delegados. El siguiente código muestra el uso de una Expresión Lambda como manejador del evento Click de un botón.

//s es object y a es RoutedEventArgs this.button1.Click += (s, a) =>{ //Manejo del evento};

Una de las ventajas claras de utilizar una Expresión Lambda es que nos ahorraremos el cuerpo del método que está manejando el evento. Generalmente en escenarios en donde necesitemos crear contenido dinámico es de gran utilidad contar con esta posibilidad.

Application Class

Silverlight

Encapsulates a Silverlight application.

Inheritance Hierarchy

System.ObjectSystem.Windows.Application

Namespace: System.WindowsAssembly: System.Windows (in System.Windows.dll)

Syntax

C#

VB

Copiar

public class Application

XAML Object Element Usage

Copiar

<Application .../>

The Application type exposes the following members.

Constructors

Name Description

Application Initializes a new instance of the Application class.

Top

Properties

Name Description

ApplicationLifetimeObject

s

Gets the application extension services that have been registered for this application.

Current Gets the Application object for the current application.

HasElevatedPermissions Gets a value that indicates whether the application is running with elevated

permissions.

Host Gets various details about the Silverlight application's host.

InstallState Gets the current out-of-browser installation state of the application.

IsRunningOutOfBrowser Gets a value that indicates whether the application was launched from the out-of-

browser state.

MainWindow Gets the out-of-browser application window.

Resources Gets a collection of application-scoped resources, such as styles, templates, and

brushes.

RootVisual Gets or sets the main application UI.

Windows Gets a collection of the Window instances that have been created.

Top

Methods

Name Description

CheckAndDownloadUpdateAsync Launches an asynchronous process to check for and download an

updated version of the application.

Equals(Object) Determines whether the specified Object is equal to the current

Object. (Inherited from Object.)

Finalize Allows an object to try to free resources and perform other cleanup

operations before the Object is reclaimed by garbage collection.

(Inherited from Object.)

GetHashCode Serves as a hash function for a particular type. (Inherited from Object.)

GetResourceStream(Uri) Returns a resource file from a location in the application package.

GetResourceStream(StreamResourceInfo,

Uri)

Returns a resource file from a location in the specified zip package.

GetType Gets the Type of the current instance. (Inherited from Object.)

Install Attempts to install the application so that it can run outside the

browser.

LoadComponent Loads a XAML file that is located at the specified Uniform Resource

Identifier (URI) and converts it to an instance of the object that is

specified by the root element of the XAML file.

MemberwiseClone Creates a shallow copy of the current Object. (Inherited from Object.)

ToString Returns a string that represents the current object. (Inherited from

Object.)

Top

Events

Name Description

CheckAndDownloadUpdateComplete

d

Occurs when the application has finished checking for updates in response

to a CheckAndDownloadUpdateAsync method call.

Exit Occurs just before an application shuts down and cannot be canceled.

InstallStateChanged Occurs when the InstallState property value changes.

Startup Occurs when an application is started.

UnhandledException Occurs when an exception that is raised by Silverlight is not handled.

Top

Remarks

Application is a class that encapsulates a Silverlight application and provides the following services:

Application Entry Point Application Lifetime Application Management Application-Scoped Resources Unhandled Exception Detection

The entry point in a Silverlight application is the class in your application assembly that derives from Application. This class is known as the application class. When the Silverlight plug-in starts, Silverlight uses metadata in the application package to instantiate the application class. At this point, the application's lifetime starts. The lifetime of an application occurs in the following order:

Construction (Application) Initialization (Startup) Application Running ... Application Shutting Down (initiated by user) Exit (Exit)

By handling the Startup event, you can retrieve and process initialization parameters from the InitParams property of the StartupEventArgs object that is passed to the Startup event handler. Initialization parameters are configured by using the initParams property of the HTML object element that is used to configure and instantiate the Silverlight plug-in.

During startup, you can also specify the main application UI to show by setting the RootVisual property.

Once an application is running, the Application object and its state can be accessed from the static Current property. The singleton pattern ensures that state managed by Application, including shared resources (Resources) and custom properties, is available from a single, application-scoped location.

XAML Usage Notes for the Application class

In practical XAML usage, Application is almost always the root element of the App.xaml file and therefore a practical usage would include the client and XAML xmlns values, as well as an x:Class value for the code-behind that initiates the root visual, as shown in the following XAML fragment.

Copiar

<Application

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

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

x:Class="namespace.class"... >

...

</Application>

Technically the XAML usage for any member of the Application class that supports XAML applies both to the Application class and also to any Application subclass that does not specifically disable XAML usage by shadowing members or changing the access level of its constructors. However, the XAML usage for Application members shows the literal Application rather than the placeholder application because subclassing Application is not necessary for most Silverlight application model scenarios, and the XAML usage shows the most common usage patterns whenever possible.

Examples

The following code example demonstrates how to use this class to merge the XAML and code-behind portions of a Page class. This code is similar to the InitializeComponent method that Visual Studio generates for the same purpose.

Visual Studio generates the InitializeComponent method when a XAML file has a build action of Page. To load a XAML file using the following example code, set its build action to Resource.

C#

VB

Copiar

private System.Windows.Controls.Grid LayoutRoot;

public Page()

{

System.Windows.Application.LoadComponent(this, new System.Uri(

"/SilverlightApplication1;component/Page.xaml",

System.UriKind.Relative));

this.LayoutRoot = ((System.Windows.Controls.Grid)

(this.FindName("LayoutRoot")));

}

Version Information

Silverlight

Supported in: 5, 4, 3

Silverlight for Windows Phone

Supported in: Windows Phone OS 7.1, Windows Phone OS 7.0

Platforms

For a list of the operating systems and browsers that are supported by Silverlight, see Supported Operating Systems and Browsers.

Thread Safety

Any public static (Shared in Visual Basic) members of this type are thread safe. Any instance members are not guaranteed to be thread safe.

See Also

Reference

System.Windows Namespace

Other Resources

Application Model

Adding Silverlight to a Web Page by Using HTML or JavaScript

Silverlight 4 Beta – Soporte para Arrastrar y Soltar en Mac OS X

En el artículo anterior vimos que una de las características nuevas de Silverlight 4 es su capacidad de recibir archivos que se estén arrastrando desde afuera de la aplicación. No obstante, en Mac OS X es diferente el mecanismo para lograr esta funcionalidad ya que en ese sistema operativo, una acción de arrastrar y soltar no le avisa al API de Silverlight de lo ocurrido, a diferencia de lo que sucede en Windows. En este artículo veremos la alternativa para implementar esta característica en Mac OS X. Cabe mencionar que este mecanismo funcionará en Safari, mientras que en FireFox sea probable que no debido a la diferencia de arquitectura de este último en el sistema operativo de Apple.

El proyecto

Usaremos el proyecto anterior.

Modificaciones

Para implementar la funcionalidad de Arrastrar y Soltar en Mac OS X necesitaremos hacerlo a través de funciones de Javascript que le avisen al plugin que una acción de arrastrar-soltar ha sucedido. Las funciones de Javascript deberán manejar alguno de los siguientes eventos del elemento <OBJECT> o <EMBED> (según lo que hayamos usado para instanciar Silverlight, en nuestro caso hemos usado <OBJECT>)

ondragenter ondragleave ondragover ondrop

Según la documentación de Web Kit, de los eventos anteriores debemos como mínimo manejar ondragover, y dentro de él ejecutar preventDefault() en el objeto de evento. Si no hacemos esto no recibiremos ninguno de los cuatro eventos anteriores. Cabe mencionar que esto no está explicado en el SDK de Silverlight 4 Beta pero probablemente esto sea aclarado en sus futuras versiones.

Aclarado lo anterior, realizaremos las siguientes modificaciones al elemento <OBJECT> con el que estamos instanciando Silverlight:

<object id="sl" data="data:application/x-silverlight-2," type="application/x-silverlight-2" width="100%" height="100%" ondragover="ManejaDragOver(event)" ondrop="ManejaDrop(event)">// los parámetros quedan igual</object>

Como podemos observar, las modificaciones son:

- Estamos agregando el atributo id, el cual nos permitirá invocar desde script al elemento.

- Estamos manejando ondragover a través de la función ManejaDragOver. Asimismo a la función le estamos pasando el objeto event el cual tiene información del evento.

- Estamos manejando ondrop a través de la función ManejaDrop. Asimismo a la función le estamos pasando el objeto event el cual tiene información del evento.

Ahora bien, debemos implementar las funciones recién explicadas. Esto lo haremos en el bloque de <script> que ya tenemos presente en la página:

//El manejo de ondragover y la ejecución de preventDefault() //son requeridos según la documentación de WebKit localizada en://http://tuvix.apple.com/mac/library/documentation/AppleApplications/Conceptual/SafariJSProgTopics/Tasks/DragAndDrop.htmlfunction ManejaDragOver(oEvent) {oEvent.preventDefault();}

function ManejaDrop(evento) {

// Previene las acciones por default en el DOMevento.preventDefault();// Obtiene el objeto de Silverlightvar sl = document.getElementById("sl");// Delega el evento a Silverlightvar manejado = sl.dragDrop(evento);

// Si ha sido manejado, evita la propagación del evento en el DOMif (manejado) evento.stopPropagation();

}

ondragover

La función ManejaDragOver únicamente hace una llamada a preventDefault() sobre el objeto de evento. Esto para permitir que el resto de eventos puedan ser recibidos (ver en la parte de arriba la liga a la documentación de Web Kit).

ondrop

La función ManejaDrop también hace una llamada a preventDefault() para evitar las que las acciones por default sucedan en el DOM (ya que nosotros queremos hacer nuestro propio manejo). Posteriormente obtiene el objeto de Silverlight y ejecuta su función dragDrop() pasando como parámetro el objeto de evento. Finalmente validamos que si el evento ha sido manejado, evite la propagación del evento en el DOM.

Resultado

Como podemos apreciar en las siguientes figuras, al arrastrar un archivo desde afuera de la aplicación Silverlight en Mac OS X, y después soltarlo el archivo se agregará al ListBox y comenzará su reproducción automáticamente, justo como en el artículo anterior.

Resumen

Para implementar la funcionalidad de Arrastrar y Soltar en Mac OS X debemos hacerlo a través de script en el DOM debido a las diferencias en la arquitectura de las plataformas; no obstante es pefectamente posible. En este artículo detallamos los pasos necesarios para hacerlo. Esto nos permitirá ofrecer a nuestros usuarios una experiencia estándar en el uso de los aplicativos Silverlight que construímos.

Puedes descargar el código aquí.

Puedes ver el demo en vivo aquí. Requiere el runtime Silverlight 4, Apple Mac OS X y Safari.