Silverlight y WPF

Creación de aplicaciones Silverlight y WPF para XAML para Windows en tiempo de ejecución

Pete Brown

XAML para Windows en tiempo de ejecución (WinRT) para las nuevas aplicaciones de la Tienda Windows es el último miembro de la familia de XAML y C# en Visual Basic que muchos de nosotros hemos llegado a querer. Todo comenzó oficialmente el año 2006 con Microsoft .NET Framework 3.0 y “Avalon” (que más adelante se llegó a conocer como Windows Presentation Foundation o WPF). Luego llegaron varias revisiones más de WPF (inclusive la última, WPF 4.5) y mientras tanto conocimos varias versiones de Silverlight (entre ellas, 1.1 y 5.1), varias versiones de Windows Phone y mucho más. Parte de la pila de XAML incluso está disponible en los dispositivos con .NET Micro Framework.

Tal vez se pregunte por qué existen tantas variantes de XAML y .NET Framework. Aunque muchas de las implementaciones convergieron en los usos similares (por ejemplo Silverlight para escribir aplicaciones de escritorio), cada plataforma se desarrolló y se optimizó para contextos y plataformas diferentes. Silverlight, por ejemplo, se diseñó para funcionar en diferentes plataformas y hospedarse en la Web. XAML en Windows Phone se diseñó para el contexto y el hardware específico de los teléfonos, y XAML para WinRT en Windows 8 se diseñó para aplicaciones de alto rendimiento, sin .NET (x86/x64 y ARM) y optimizadas para toque (pero no solo para toque) de la Tienda Windows.

Sin embargo, estas implementaciones de XAML tienen muchas más similitudes que diferencias. Es debido a estas semejanzas que las discrepancias saltan tanto a la vista. Desde luego, las diferencias más diminutas pueden causar bastantes dificultades durante el desarrollo; algo que conozco tanto por experiencia como por conversaciones con otros desarrolladores. Sin embargo, el hecho que podamos hablar siquiera sobre la compatibilidad en un nivel tan detallado pone de manifiesto la semejanza entre los lenguajes, las bibliotecas y el marcado.

En este artículo me propongo abordar dos situaciones importantes: el uso compartido del código con una aplicación complementaria y la preparación del desarrollo actual para el futuro.

Aplicación complementaria Esto es una situación de uso compartido simultáneo de código o de compilación cruzada para los desarrolladores de aplicaciones WPF y Silverlight que al mismo tiempo quieren desarrollar aplicaciones complementarias de la Tienda Windows para Windows 8.

Preparación para el futuro En esta situación, los desarrolladores crean nuevas aplicaciones WPF y Silverlight ahora, pero no las destinan a Windows 8. Quieren estar preparados para cuando la organización adopte Windows 8; quieren garantizar que las partes pertinentes de las aplicaciones se puedan portar más fácilmente a la nueva interfaz de usuario de Windows.

Décadas de experiencia en programación nos han enseñado que la reutilización y la portabilidad siempre tienen un costo. No obstante, con las técnicas que presentaré, verá que gran parte del esfuerzo es un incremento mínimo sobre el trabajo que tiene que realizar normalmente para crear una aplicación con una arquitectura bien diseñada.

Una arquitectura bien pensada es imprescindible

Dividir las aplicaciones grandes en aplicaciones más pequeñas solo se puede hacer cuando se parte de una buena arquitectura. De hecho, si la aplicación tiene muchas interdependencias entre los módulos del código, muchas jerarquías de clases pesadas o por algún otro motivo tiene la apariencia de una bola de barro o de código desechable, cualquier intento de reutilización o conversión resultará extremadamente difícil. ¡Pero no desespere! El código existente se puede refactorizar y el nuevo se puede escribir con miras a la arquitectura nueva.

Al diseñar aplicaciones nuevas, recomiendo a los desarrolladores de XAML que sigan algunos métodos claves: el enlace, el patrón Model-View-ViewModel (MVVM) y las clases de servicio.

Enlace Mientras más adopte el enlace de datos al desarrollar en XAML, más fácil le resultará mantener separada la lógica de la interfaz de usuario. Idealmente, debería establecer el DataContext para la interfaz de usuario y todo lo demás se debería lograr mediante enlace de datos o comandos. En la práctica, son pocas las aplicaciones donde se logra ese nivel de separación, pero mientras más se aproxime al ideal, más fácil será su vida.

Patrón MVVM El patrón MVVM va mano en mano con el enlace de datos. El ViewModel es donde se enlazará la interfaz de usuario. Existe muchísima información excelente (y kits de herramientas, como veremos más adelante) disponible en forma gratuita en Internet y en libros, así que no la repetiré aquí.

Clases de servicio Este enfoque no se debe confundir con los servicios web. Por el contrario, estas clases proporcionan funcionalidades reutilizables en el cliente. En algunos casos, pueden llamar servicios compatibles con REST u otros tipos de servicios. En otros casos, se pueden interconectar con la lógica de negocios. En todos los casos, encapsulan el código que podría ser volátil y facilitan el intercambio entre las diferentes implementaciones. Por ejemplo, en la Ilustración 1, el ViewModel habla con las clases de servicio para usar los servicios de la plataforma y resolver las dependencias externas.

Ilustración 1 Relación entre el ViewModel y las clases de servicio

Ya sé. Está pensando, “¡Puf, otro diagrama de capas!” Pero usted sabe lo importante que son estos conceptos. La intención es desacoplarnos al máximo de la plataforma en la que nos encontramos, dentro de los límites de presupuesto y de tiempo. Al excluir el código que, por ejemplo, realiza llamadas COM o p-invoke a los elementos de escritorio, tales como Windows Imaging o DirectShow, podemos reemplazar esa implementación más fácilmente con la API para las cámaras de WinRT en la aplicación para la Tienda Windows. Las clases de servicio también son un lugar excelente para encapsular otras diferencias entre las plataformas como, por ejemplo, la implementación de los contratos: para enviar un mensaje de correo electrónico desde la aplicación para la Tienda Windows, se necesita un contrato pero, en el escritorio, esto probablemente se haría mediante la automatización de Outlook o con un enlace a un servidor SMTP.

Desde luego, resulta fácil exagerar con la arquitectura y no terminar jamás. Una arquitectura buena debería facilitar el desarrollo, no dificultarlo. Si cree que su equipo tiene que batallar contra las minucias de un patrón arquitectónico determinado, probablemente está perdiendo el tiempo. En su lugar, entienda los patrones y lo que entregan; luego tome decisiones inteligentes e informadas sobre los pros y los contras. En la mayoría de los casos, es preferible implementar el 85 por ciento de una arquitectura excelente que el 0 por ciento de esta. Asimismo, el costo necesario para obtener ese 15 por ciento restante muchas veces no se justifica.

Una vez que separó el código que depende de la plataforma, suele tener una buena cantidad de código no-trivial que podrá reutilizar.

Adopte la nueva estética del diseño de la interfaz de usuario de Windows

Cuando los desarrolladores consideran por primera vez la posibilidad de crear una versión para la Tienda Windows de las aplicaciones Windows Presentation Foundation (WPF) y Silverlight, inmediatamente se topan con el obstáculo de tener que replantear la interfaz de usuario y el diseño visual. Para la mayoría de los desarrolladores, la perspectiva de tener que cambiar el estilo de toda una aplicación no resulta atractivo en lo más mínimo. Si cree que en el futuro se las verá con aplicaciones para la Tienda Windows, el pequeño esfuerzo que tendrá que invertir ahora en adoptar la estética de diseño de la nueva interfaz de usuario de Windows y las instrucciones, definitivamente se recompensará después.

El nuevo diseño de la interfaz de usuario de Windows entrega un marco que nos sirve para guiar las decisiones en el diseño de la interfaz de usuario. Varios vídeos del congreso BUILD 2011 tocan el tema del diseño de aplicaciones para la Tienda Windows. Puede encontrarlos en MSDN Channel 9 en bit.ly/oB56Vf. Además, estas son algunas de las cosas que le conviene hacer para adoptar la nueva estética de diseño de la interfaz de usuario de Windows en sus aplicaciones de escritorio:

• Cree un diseño auténticamente digital. Por regla general, trate de evitar la práctica de diseñar la interfaz de usuario como una falsa analogía de objetos físicos (esqueuomorfismo). Debe evitar no solo la recreación de objetos físicos sino que también las técnicas derivadas como botones brillantes, sombreados en 3D, sombras realistas y fondos vidriosos.
• Emplee una jerarquía tipográfica clara. No use una cantidad desorbitada de fuentes diferentes; y para las fuentes que use, aténgase a un conjunto limitado de tamaños claramente discernibles. Los encabezados se deben diferenciar claramente de las etiquetas de los campos y de los textos de ayuda.
• Identifique la marca de la aplicación. Use sus colores, logotipos, tipografías, etc. según corresponda. Conviene involucrar a los desarrolladores web y diseñadores, ya que frecuentemente tienen más experiencia con las técnicas de marca.
• Use una metáfora de navegación basada en páginas. A los desarrolladores de Silverlight esto les parecerá natural (el marco de navegación es casi idéntico), pero puede que los desarrolladores de WPF deban realizar un esfuerzo un poco mayor para alejarse del enfoque tradicional centrado en muchas ventanas y cuadros de diálogo.
• Céntrese en las tareas. Mantenga la interfaz de usuario enfocada en las tareas e intente no verter hasta el último detalle en un mismo formulario. Desafortunadamente, los usuarios muchas veces creen que quieren todas las funciones en una misma página, pero con el tiempo esto se vuelve difícil de usar, difícil de mantener y difícil de aprender. En algunos casos, considere la posibilidad de dividir las aplicaciones grandes en aplicaciones más pequeñas enfocadas en tareas.
• Evite las decoraciones innecesarias. Cree una interfaz de usuario sencilla. Queremos que la vista del usuario se enfoque en el trabajo que tiene que realizar y no en los menús, elementos de navegación, bordes de las ventanas ni en otro cromo.

Puede ver estos conceptos como las instrucciones de diseño para la interfaz de usuario antigua de Windows. Son instrucciones que debería seguir si quiere que su aplicación le resulte familiar al usuario y que encaje dentro de la nueva interfaz de usuario de Windows. Pero, por supuesto, hay mucho más; así que lo invito a que vea los vídeos de BUILD y estudie las aplicaciones que escribieron otros desarrolladores y diseñadores.

Una forma de partir con un poco de ventaja en los estilos de la interfaz de usuario es copiar los recursos de estilo de otras aplicaciones para la Tienda Windows a sus propias aplicaciones de escritorio. Muchos de estos recursos de estilo se encuentran en la carpeta Windows Kits. En mi equipo, esta carpeta se encuentra en C:\Program Files (x86)\Windows Kits\8.0\Include\winrt\xaml\design.

Algunos de los estilos y recursos se pueden usar tal cual. Algunos no servirán debido a los controles nuevos (ListView y GridView, por ejemplo) y otros pueden requerir de una buena cantidad de ajustes. Sin embargo, esta es una forma excelente para lograr una apariencia y comportamiento modernos en las aplicaciones y para promover una transición fácil entre los estilos de escritorio y de la Tienda Windows. Incluso si no puede usar un estilo o plantilla directamente, puede aprender de ella para obtener una ventaja al desarrollar sus propios estilos.

Su interfaz de usuario de todos modos requerirá de ajustes cuando la traslade a Windows en tiempo de ejecución, pero si adopta estos conceptos en sus aplicaciones ahora, tendrá buenos resultados en sus transiciones entre las aplicaciones para la nueva interfaz de usuario de Windows y las de escritorio que no irriten a sus usuarios ni a los desarrolladores.

Estoy a favor de evitar todo esfuerzo innecesario. Cree el estilo de la aplicación una vez, simplifique la transición y de paso obtenga una imagen moderna.

Reutilización de código y componentes

En las nuevas aplicaciones para la Tienda Windows, todas las miradas están volcadas sobre Windows en tiempo de ejecución. Es nuevo, rápido, y tiene un montón de características increíbles. Sin embargo, a veces olvidamos que Windows en tiempo de ejecución no es lo único con lo que tendremos que trabajar; las aplicaciones para la Tienda Windows creadas con XAML además usan mucho .NET Framework 4.5. De hecho, .NET Framework 4.5 tiene actualizaciones importantes, muchas de las cuales le permiten funcionar lado a lado con Windows en tiempo de ejecución. Sin embargo, sigue siendo .NET, así que tiene bastante sentido compartir el código fuente e incluso los archivos binarios compilados con otras implementaciones de .NET.

Al compartir el código con las aplicaciones WPF, lo mejor que puede hacer en este momento es escribir su propio código WPF para trabajar con .NET Framework 4.5. Las aplicaciones para la Tienda Windows emplean un subconjunto seguro de .NET 4.5 junto con Windows en tiempo de ejecución. Cuando .NET Framework otorga las mismas prestaciones que Windows en tiempo de ejecución (XAML es un muy buen ejemplo de esto), el perfil de .NET para las aplicaciones para la Tienda Windows usa la versión de WinRT. Si se limita a este subconjunto en la medida de lo posible, su código será extremadamente portable. Esto le resultará especialmente útil cuando trabaje con servicios y código asincrónico.

Al compartir con Silverlight, estamos un poco más restringidos, ya que Silverlight no usa .NET Framework 4.5 ni, en gran parte, la biblioteca TPL. Sin embargo, con el paquete de async para Silverlight 5, los usuarios de Visual Studio 2012 que escriben aplicaciones Silverlight pueden obtener acceso a algunas de las funciones de Task<T>, junto con async y await. Sin embargo, el código de Agregar referencia de servicio no generará código asincrónico del lado cliente. Si esto es importante para usted, puede portar el código proxy a Silverlight. Un método mejor, que emplea la arquitectura que propongo aquí, consiste en encapsular las interacciones con el servicio web dentro de clases de servicio locales.

¿Qué hacer con el código que es idéntico? Las clases de Model —y, en muchos casos las clases de ViewModel— caen en esta categoría. Aquí, tiene dos alternativas: proyectos de la Biblioteca de clases portable (PCL) y proyectos vinculados.

Proyectos PCL La PCL brinda una forma excelente de compartir DLL compilados entre diferentes destinos .NET. La PCL nos permite compartir ensamblados entre .NET, .NET para aplicaciones para la Tienda Windows, Silverlight, Windows Phone, entre otros. Para usar la PCL, debemos restringir las referencias del ensamblado a los que se encuentran en el listado de compatibilidad. Obtenga más información sobre la PCL en bit.ly/z2r3eM.

Proyectos vinculados con código fuente compartido y compilación condicional Esta característica de Visual Studio nos permite tener diferentes proyectos, cada uno destinado a una plataforma diferente, pero con una sola copia compartida del código fuente. En el pasado, usé este sistema principalmente para compartir código entre ASP.NET en el servidor y Silverlight en el cliente. Puede encontrar un ejemplo en mi blog en bit.ly/RtLhe7. 

Aunque en la mayoría de los casos de reutilización tradicionalmente usé proyectos vinculados, la PCL realmente ha crecido mucho en las últimas versiones. Si usted está apuntando a WPF y XAML para WinRT, la PCL le permitirá usar casi todo el perfil de .NET 4.5 en las aplicaciones para la Tienda Windows. En caso de dudas, comience con la PCL.

Una cosa que me gusta del método de los proyectos vinculados es que puedo entregar funcionalidades adicionales propias de la plataforma por medio de clases parciales y compilación condicional. Los símbolos para la compilación condicional se establecen en la pestaña Compilación de la página de propiedades del proyecto, como se puede apreciar en la Ilustración 2.

Ilustración 2 Página de propiedades del proyecto con los símbolos de compilación

Varios símbolos de compilación condicional están definidos en forma predeterminada, como se aprecia en la Ilustración 3.

Ilustración 3 Símbolos de compilación condicional

Observe que .NET Framework completo no define ningún símbolo de compilación, ya que cuenta como la plataforma predeterminada. Si esto no le da confianza, puede agregar sus propios símbolos de compilación; pero no olvide que debe hacerlo en todos los proyectos .NET Framework de la solución.

La compilación condicional también es la forma que tenemos para incorporar diferentes espacios de nombres en el código, según la plataforma de destino:

#if NETFX_CORE
using Windows.UI.Xaml;
#else
using System.Windows.Xaml;
#endif

En cualquier aplicación que no sea trivial, probablemente deberá usar tanto PCL como proyectos vinculados para compartir el código. Compartir XAML, sin embargo, es más difícil.

Uso compartido de las interfaces de usuario y recursos en XAML

Por varios motivos, compartir XAML resulta más difícil que compartir código. El paso más importante para esto es adaptar la interfaz de usuario al formato y la plataforma de destino. (Consulte “Adopte la nueva estética del diseño de la interfaz de usuario de Windows”, donde encontrará algunas pistas.) En la mayoría de los casos, el tiempo de desarrollo se invierte mejor en garantizar que el código se pueda reutilizar, ya que obtendrá más beneficios con menos esfuerzo. No obstante, existirá el deseo y la tendencia de compartir también XAML entre los proyectos.

XAML no conoce el concepto de compilación condicional. Por esto, las diferencias en los espacios de nombres generan más problemas que en el código. Aparte de los espacios de nombres mismos, entre XAML para WinRT y las otras versiones también cambió la forma de importarlos en XAML.

Por ejemplo, tome en cuenta este XAML de .NET Framework:

xmlns:localControls="clr-namespace:WpfApp.Controls"

Y este XAML para WinRT:

xmlns:localControls="using:WindowsApp.Controls"

En vez de la instrucción “clr-namespace”, XAML para WinRT usa la instrucción “using” en XAML para importar los espacios de nombres. ¿Por qué hizo esto el equipo del producto? Los espacios de nombres importados en XAML podrían venir de código que no corresponde al CLR, como por ejemplo C++. Ahora no solo tenemos compatibilidad con XAML en C++, sino que también podemos escribir ensamblados de extensión en C++ y usarlos en el código .NET. Esto significa que el término “clr-namespace” dejó de ser exacto.

Una forma de lidiar con las diferencias es cargar el XAML en forma dinámica. En los tiempos de Silverlight 1.1, los controles de usuario se generaban del siguiente modo: XAML se cargaba en forma dinámica y se procesaba en tiempo de ejecución. Desde entonces, los desarrolladores han empleado este método, debido a su flexibilidad, en todas las plataformas.

Al cargar XAML en forma dinámica, trabajamos con cadenas. Esto significa que podemos reemplazar un texto o extraer un subconjunto antes de cargarlo al árbol visual. Digamos, por ejemplo, que tenemos una definición de un control de usuario vacío en nuestro proyecto WPF o Silverlight. El control de usuario no es más que una cáscara que define los espacios de nombres y la clase. Luego tenemos una cáscara equivalente en el proyecto de XAML para WinRT.

Este es el XAML para .NET:

<UserControl x:Class="WpfApp.Controls.AddressControl"
  xmlns="https://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml">
  <Grid x:Name="LayoutRoot">
  </Grid>
</UserControl>

Y este es el XAML para WinRT:

<UserControl x:Class="WindowsApp.AddressControl"
  xmlns="https://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml">
  <Grid x:Name="LayoutRoot">
  </Grid>
</UserControl>

Ambos controles de usuario en XAML son el resultado completamente corriente de las plantillas. El único cambio que realicé fue darle un nombre al elemento Grid raíz y eliminar algunos espacios de nombres que no se usaban para simplificar el código. El código subyacente de los controles se puede compartir mediante las técnicas para compartir código, aunque recomiendo particionar el código en una clase compartida independiente, siempre que se pueda.

Luego, para cargar el XAML en tiempo de ejecución, podemos usar código similar al que aparece en la Ilustración 4.

Ilustración 4 Código para cargar XAML en forma dinámica

public partial class AddressControl : UserControl
{
  public AddressControl()
  {
    InitializeComponent();
    LoadXaml();
  }
  private void LoadXaml()
  {
    string xaml =
    "<Grid xmlns=\"https://schemas.microsoft.com/winfx/2006/xaml/presentation\" " +
      "xmlns:x=\"https://schemas.microsoft.com/winfx/2006/xaml\">" +
      "<Grid.RowDefinitions>" +
        "<RowDefinition Height=\"Auto\" />" +
        "<RowDefinition Height=\"30\" />" +
      "</Grid.RowDefinitions>" +
      "<TextBlock Text=\"Address\" Grid.Row=\"0\" FontSize=\"10\" />" +
      "<TextBox x:Name=\"t1\" Grid.Row=\"1\" FontSize=\"15\" />" +
    "</Grid>";
    var reader = new StringReader(xaml);
    var xmlReader = XmlReader.Create(reader);           
    LayoutRoot.Children.Add((UIElement)XamlReader.Load(xmlReader));
  }
}

El código para cargar XAML para WinRT es incluso más fácil, debido a la funcionalidad disponible para cargar cadenas:

string xaml = "..."
LayoutRoot.Children.Add((UIElement)XamlReader.Load(xaml));

Para simplificar, aquí cargué el XAML desde una cadena codificada en forma rígida y usé XAML que ya es portable y no requiere de ninguna manipulación de cadenas. En el primero, si quiere compatibilidad para el diseñador, haga que el código cargue el texto desde un archivo de recursos en XAML. Luego, incluya todas las clases y definiciones de xlmns para brindar compatibilidad con el diseñador, pero descártelas en la etapa de carga de XAML.

Independientemente de cómo se inserta el XAML en el árbol visual, si queremos conectar eventos en el XAML cargado en forma dinámica, también lo podemos hacer en código:

LayoutRoot.Children.Add((UIElement)XamlReader.Load(xaml));
var t1 = FindName("t1") as TextBox;
if (t1 != null)
{
  t1.TextChanged += t1_TextChanged;
}

Del mismo modo como podemos cargar la interfaz de usuario en XAML, también podemos cargar los recursos en tiempo de ejecución. Podemos crearlos a partir de cero o, con los mismos métodos que acabamos de ver, cargarlos desde el origen de XAML:

private void LoadResources()
{
  string xaml =
    "<Style xmlns=\"https://schemas.microsoft.com/winfx/2006/xaml/presentation\" " +
      "TargetType=\"TextBox\">" +
      "<Setter Property=\"Margin\" Value=\"5\" />" +
    "</Style>";
  // Implicit styles use type for key
  var key = typeof(TextBox);
  App.Current.Resources.Add(key, XamlReader.Load(xaml));
}

Al cargar los recursos en forma dinámica, asegúrese de que se hayan cargado antes de hacer referencia a ellos. En el caso de los estilos implícitos, estos simplemente no se aplicarán a nada que ya se encuentre en el árbol visual en el momento de crear el recurso.

Para ser más claros, todo este método es un poco chapucero y no funcionará perfectamente en todas las situaciones. (Llegado un punto, la manipulación de cadenas puede significar más esfuerzo de lo que vale.) Pero para lograr una reutilización máxima entre plataformas, esta es una solución posible. Personalmente, solo emplearía este método para los componentes críticos de la interfaz que van a cambiar mucho o que son demasiado complejos o abundantes para copiar y pegarlos en forma periódica.

Por supuesto, también podríamos escribir una acción de compilación personalizada u otra extensión de Visual Studio para controlar el procesamiento en forma automática cuando los archivos se guardan, desprotegen, compilan o para otro paso.

La última forma consiste en abandonar XAML por completo y crear, en su lugar, toda la interfaz de usuario con código. En la mayoría de las aplicaciones, por lo general advierto contra esta solución; requiere de mucho trabajo adicional y tiene cero compatibilidad con el diseñador. Las interfaces de usuario orientadas en datos, sin embargo, funcionan extremadamente bien con este método. Si se puede crear en XAML, también se puede crear con código; como en el caso del XAML para WinRT que aparece en la Ilustración 5.

Ilustración 5 Creación de una interfaz de usuario con XAML para WinRT

private void CreateControls()
{
  Grid g = new Grid();
  RowDefinition r1 = new RowDefinition();
  RowDefinition r2 = new RowDefinition();
  r1.Height = new GridLength(1, GridUnitType.Auto);
  r2.Height = new GridLength(30.0);
  g.RowDefinitions.Add(r1);
  g.RowDefinitions.Add(r2);
  TextBlock t = new TextBlock();
  t.Text = "Address";
  Grid.SetRow(t, 0);
  TextBox tb1 = new TextBox();
  Grid.SetRow(tb1, 1);
  g.Children.Add(t);
  g.Children.Add(tb1);
  LayoutRoot.Children.Add(g);
}

Este código, con la excepción de la configuración de las fuentes (para no alargar demasiado el listado), es equivalente al XAML, que se carga en forma dinámica, que agrega unos elementos TextBlock y TextBox en la cuadrícula LayoutRoot, que se encuentra dentro de una cuadrícula.

Considere la posibilidad de usar kits de herramientas de código abierto

Muchos de los mejores kits de herramientas para XAML con C# son de código abierto. En un proyecto de código abierto activo, probablemente encontrará personas interesadas en recoger y agregar las características que permiten pasar entre Silverlight, WPF y Windows en tiempo de ejecución.

Existen varios kits de herramientas para MVVM, por ejemplo, que son portables en gran medida entre las diferentes variantes de XAML. Al usar uno de estos, puede reducir la cantidad de cambios en el código fuente cuando tiene que compartirlo o portarlo. Asimismo, encontrará controles, bases de datos locales y otros kits de herramientas disponibles que podrá usar en diferentes plataformas.

Siempre existe el peligro de que los desarrolladores de código abierto dejen de trabajar para las versiones nuevas de las plataformas; pero debido al acceso al código fuente, tiene la posibilidad de bifurcar el código y hacerse cargo usted mismo, si así lo desea. Simplemente deberá contribuir el código cuando haya terminado.

Lo que debería ser una aplicación con interfaz de usuario para la Tienda Windows

Cuando llega la hora de crear la nueva aplicación para la Tienda Windows, tome en cuenta que no todos los aspectos de las aplicaciones de escritorio se traducen directamente a las aplicaciones para la Tienda Windows. Por ejemplo, una aplicación grande con 300 formularios que realizan todo un conjunto de funciones diferentes para diferentes usuarios, generalmente no es un buen candidato para la nueva interfaz de usuario de Windows. Las aplicaciones para la Tienda Windows más bien deberían estar centradas en tareas y adaptadas para usos específicos.

Tomemos como ejemplo una aplicación de seguros. Podríamos tener una aplicación grande compartida por un número importante de usuarios dentro de la empresa. Tiene funciones de supervisión para administrar la seguridad de los usuarios. Permite realizar reclamaciones por daños en cristales por vía telefónica y en terreno mediante un equipo portátil. Tiene funciones integradas para crear directivas nuevas, etc.

Al dividirla en varias aplicaciones más pequeñas orientadas en tareas (o en usuarios), se prestará mucho mejor para la nueva interfaz de usuario de Windows. Se podría separar, por ejemplo, una aplicación para el ajustador en terreno que se concentre puntualmente en recopilar información sobre los accidentes en la escena. Como tiene un fin muy específico, permite tomar fotografías y grabar vídeo, además de almacenar los datos en forma local para las zonas desconectadas o con una señal deficiente. Esta aplicación probablemente comparte mucho código con las otras aplicaciones de la empresa, pero al tener un objetivo claro, resulta mucho más fácil adaptarla al contexto para el cual se creó.

En resumen

XAML para WinRT, Silverlight y WPF se crearon para diferentes propósitos, pero tienen más semejanzas que diferencias. Resulta fácil compartir código entre ellos y también es posible compartir XAML. Existen muchas técnicas adicionales que puede seguir para escribir para las tres plataformas y pasar del escritorio a la nueva interfaz de usuario de la Tienda Windows. Me encantaría continuar esta conversación en Twitter y en mi blog en 10rem.net. Si usted ha usado otras técnicas para programar para varias plataformas o para portar código a Windows en tiempo de ejecución, me encantaría conocerlas.

Pete Brown es el especialista en XAML para Windows 8 y gadgets en Microsoft. También es el autor de “Silverlight 5 in Action” (Manning Publications, 2012) y “Windows 8 XAML in Action” (Manning Publications, 2012). Su blog y sitio web se encuentran en 10rem.net, y puede seguirlo en Twitter en twitter.com/pete_brown.

Gracias al siguiente experto técnico por su ayuda en la revisión de este artículo: Tim Heuer