Silverlight e WPF

  • Artigo

Escrevendo aplicativos Silverlight e WPF com o XAML do Tempo de Execução do Windows em mente

Pete Brown

 

O Tempo de Execução do Windows (WinRT) XAML para novos aplicativos da Windows Store é o membro mais recente da família XAML e C#/Visual Basic que muitos de nós iremos adorar. Tudo começou oficialmente em 2006 com o Microsoft .NET Framework 3.0 e o "Avalon" (mais tarde chamado de Windows Presentation Foundation ou WPF). Depois vieram mais várias revisões do WPF, incluindo a mais recente, WPF 4.5, e concomitantemente, tivemos sete versões do Silverlight (incluindo 1.1 e 5.1) indicadas, várias versões do Windows Phone e muito mais. Você encontrará até mesmo parte da pilha XAML disponível em dispositivos com .NET Micro Framework.

Você pode se perguntar por que há tantas variações em XAML e o .NET Framework. Embora muitas das implementações tenham convergido em usos similares (Silverlight para escrever aplicativos de desktop, por exemplo), cada plataforma foi desenvolvida e otimizada para cenários e plataformas de destino diferentes. Por exemplo, o Silverlight foi projetado para ser multiplataforma e hospedado na Web. O XAML no Windows Phone foi projetado para cenários específicos de telefone e hardware, e o WinRT XAML no Windows 8 foi projetado para alto desempenho, nos aplicativos "metal" (x86/x64 e ARM), primeiro toque (mas não apenas toque) da Windows Store.

No entanto, essas implementações de XAML têm muito mais semelhanças do que diferenças. É por essas semelhanças que as diferenças parecem tão pronunciadas. Naturalmente, pequenas diferenças podem causar uma série de desafios de desenvolvimento, algo que sei por experiência própria e por conversar com outros desenvolvedores. No entanto, o fato de podermos até mesmo falar sobre compatibilidade detalhadamente ilustra a semelhança entre as linguagens, bibliotecas e marcação.

Neste artigo, meu foco está voltado para dois cenários importantes: compartilhar código com um aplicativo complementar e preparar seu desenvolvimento atual para o futuro.

Aplicativo complementar É um cenário de compartilhamento de código simultâneo, ou de compilação cruzada, para os desenvolvedores de aplicativos WPF e Silverlight que querem desenvolver aplicativos da Windows Store complementares para o Windows 8 ao mesmo tempo.

Preparação para o futuro Nesse cenário, os desenvolvedores criam novos aplicativos WPF e Silverlight hoje, mas não estão visando atualmente o Windows 8. Quando a organização adotar o Windows 8, os desenvolvedores querem estar prontos; eles querem ajudar a garantir que partes apropriadas de seus aplicativos serão portadas mais facilmente para a nova interface de usuário do Windows.

Décadas de experiência em programação nos ensinou que a reutilização e a portabilidade nunca são gratuitas. No entanto, com as técnicas apresentadas aqui, você verá que muito do esforço é um incremento mínimo sobre o que você faria normalmente para criar aplicativos bem arquitetados.

A arquitetura elaborada é essencial

Dividir aplicativos grandes em aplicativos menores é possível somente se você tiver uma boa arquitetura para começar. Na verdade, se seu aplicativo tiver muitas interdependências entre os módulos de códigos, muitas hierarquias de classe pesada, ou parecer uma bola de lama ou código descartável, a reutilização ou a portabilidade será extremamente difícil. Mas não se desespere! O código pode ser refatorado e o novo código pode ser escrito com a nova arquitetura em mente.

Para criar novos aplicativos, aconselho os desenvolvedores de XAML a seguirem algumas abordagens importantes: associação, padrão MVVM (Model-View-ViewModel) e classes de serviço.

Associação Quanto mais você abraça a associação de dados ao desenvolver em XAML, mais fácil será manter sua lógica separada da interface do usuário. O ideal é que você defina o DataContext para a interface do usuário, e todo o resto seja manipulado por associação de dados ou comandos. Na prática, alguns aplicativos são capazes de atingir esse nível de separação, mas quanto mais próximo você chegar, mais fácil será sua vida.

Padrão MVVM O padrão MVVM anda de mãos dadas com a associação de dados. O ViewModel é associado à interface do usuário. Há uma tonelada de informações excelentes (e kits de ferramentas, que abordarei mais tarde) disponíveis gratuitamente na Internet e em livros. Então, não vou me prolongar aqui.

Classes de serviço Essa abordagem não deve ser confundida com serviços Web. Elas são classes que fornecem funcionalidade reutilizável no cliente. Em alguns casos, elas podem chamar o RESTful ou outros serviços. Em outros casos, elas podem fazer interface com a lógica dos seus negócios. Em todos os casos, elas encapsulam o código potencialmente volátil e facilitam a troca de implementações. Por exemplo, na Figura 1, o ViewModel conversa com classes de serviço para usar os serviços de plataforma e resolver dependências externas.


Figura 1 Relação entre o ViewModel e as classes de serviço

Eu sei. Você está pensando: "Ah! Outro diagrama de camada". Mas você sabe como estes conceitos são importantes. A intenção é dissociar-se da plataforma que você está o mais razoável possível dentro de suas restrições de orçamento e tempo. Fatorando um código que, por exemplo, faz chamadas COM ou p-invoke em elementos de desktop como Windows Imaging ou DirectShow, você pode substituir mais facilmente essa implementação pela API de câmera do WinRT no seu aplicativo da Windows Store. Classes de serviço também são um ótimo lugar para encapsular outras diferenças de plataforma, tais como implementações de contrato: o envio de um e-mail de seu aplicativo da Windows Store usaria um contrato, mas no desktop, isso provavelmente significaria automatizar o Outlook ou conectar a um servidor SMTP.

Claro, é fácil exagerar na arquitetura e nunca terminar o trabalho de fato. A boa arquitetura deve facilitar o desenvolvimento, e não dificultar. Se você perceber que sua equipe está se atrapalhando com as minúcias de determinado padrão de arquitetura, provavelmente está perdendo tempo. Em vez disso, entenda os padrões e o que eles trazem. Depois, tomem decisões informadas e inteligentes sobre as compensações. Na maioria dos casos, implementar 85% de uma arquitetura ótima é melhor que 0% da mesma. Da mesma forma, os custos envolvidos em conseguir implementar esses últimos 15% geralmente não valem a pena.

Uma vez que você separa o código dependente de plataforma, pouquíssimo de outro código não trivial pode ser reutilizado.

Abrace a nova estética do design de interface do usuário do Windows

Quando os desenvolvedores consideram primeiro criar versões da Windows Store de aplicativos Windows Presentation Foundation (WPF) e Silverlight existentes, imediatamente se deparam com o obstáculo de ter de reinventar design UX e visual. Para a maioria dos desenvolvedores, a possibilidade de reformular um aplicativo inteiro não é atraente. Se você acha que os aplicativos da Windows Store estão em seu futuro, um pouco de trabalho agora para abraçar a nova estética e diretrizes do design de interface do usuário do Windows realmente valerá a pena mais tarde.

O novo design da interface do usuário do Windows fornece uma estrutura que você pode usar para como guia para suas escolhas de design da interface do usuário. Vários vídeos BUILD 2011 abrangem o design de aplicativos da Windows Store. Você pode encontrá-los no MSDN Channel 9, em bit.ly/oB56Vf. Além disso, confira aqui algumas coisas que você vai querer fazer para abraçar a nova estética de design da interface do usuário Windows em seus aplicativos de desktop:

  • Seja autenticamente digital. Geralmente, isso coíbe a prática de criar a interface do usuário para ser um falso analógico de objetos físicos (esqueumorfismo). Você deve evitar não só recriar objetos físicos, mas também técnicas derivadas, como botões brilhantes, sombreamento 3D, sombras realistas e planos de fundo transparentes.
  • Tem uma hierarquia clara de tipos. Não use uma tonelada de fontes diferentes, e para as fontes que você usar, use poucos tamanhos essenciais e facilmente distintos. Os títulos devem ser facilmente distinguidos dos nomes de campos e do texto de ajuda.
  • Dê sua marca ao aplicativo. Use suas cores, logotipos, fontes etc. conforme apropriado. Ajuda a ter seus designers e desenvolvedores da Web envolvidos aqui, pois muitas vezes eles têm mais experiência prática com a marca.
  • Use uma metáfora de navegação baseada em página. Os desenvolvedores do Silverlight acharão isso natural (a estrutura de navegação é quase idêntica), mas os desenvolvedores do WPF podem ter um pouco mais trabalho para migrar da tradicional abordagem de desktop de várias janelas e caixas de diálogo.
  • Foque na tarefa. Mantenha a interface do usuário centrada na tarefa e não tentar acumular tudo em um único formulário. Infelizmente, os usuários muitas vezes pensam que querem todas as funções em uma única página, mas com o tempo isso dificulta o uso, a manutenção e o aprendizado. Em alguns casos, considere dividir aplicativos grandes em aplicativos menores, voltados para a tarefa.
  • Evite decoração desnecessária. Mantenha a interface do usuário simples. Você quer chamar a atenção do usuário para o trabalho em que ele precisa se concentrar, não para menus, elementos de navegação, bordas das janelas e outros detalhes.

Pense nesses conceitos como sendo bem semelhantes às antigas diretrizes de design de interface do usuário do Windows. São diretrizes que você deve seguir se quiser que seu aplicativo pareça familiar para o usuário e se encaixe na nova interface do usuário do Windows. Há mais do que isso, é claro. Por isso, aconselho que você confira os vídeos de compilação e estude os exemplos de aplicativos que outros desenvolvedores e designers escreveram.

Uma maneira de obter uma vantagem inicial com o uso de estilos de interface do usuário é copiar os recursos de estilo de aplicativos da Windows Store em seus próprios aplicativos de desktop. Você pode encontrar muitos recursos de estilo na pasta Windows Kits. Na minha máquina, essa pasta está localizada em C:\Arquivos de Programas (x86)\Windows Kits\8.0\Include\winrt\xaml\design.

Alguns recursos e estilos podem ser usados como estão. Alguns não poderão ser utilizados devido a novos controles (ListView e GridView, por exemplo), e alguns poderão exigir um pouco de ajuste. No entanto, essa é uma ótima maneira de obter uma aparência moderna para seu aplicativo e promover uma transição fácil entre desktop e estilos da Windows Store. Mesmo quando você não puder usar um estilo ou modelo diretamente, poderá aprender com ele para obter uma vantagem em seu próprio trabalho de estilização.

A interface do usuário ainda exigirá certo trabalho quando você migrá-la para o Tempo de Execução do Windows, mas se você abraçar esses conceitos em seus aplicativos agora, terá avançado um longo caminho para assegurar que suas transições entre a nova interface da Windows Store e os aplicativos de desktop não sejam chocantes para os usuários ou seus desenvolvedores.

Sou totalmente a favor do menor esforço. Estilize o aplicativo uma vez, facilite a transição e obtenha um visual moderno como bônus.

Reutilização de código e componentes

O Tempo de Execução do Windows chama muita atenção no novos aplicativos da Windows Store. Ele é novo, é rápido e tem uma série de recursos legais. No entanto, às vezes esquecemos que o Tempo de Execução do Windows não é a soma total do que você tem que trabalhar; os aplicativos da Windows Store criados com XAML usam muito o .NET Framework 4.5 juntamente com o Tempo de Execução do Windows. Na verdade, o .NET Framework 4.5 tem atualizações significativas, incluindo muitas que o permitirão ser usado paralelamente com o Tempo de Execução do Windows. No entanto, ainda é .NET, — compartilhar o código-fonte e até mesmo binários compilados com outras implementações do .NET é bastante razoável de se fazer.

Ao compartilhar código com aplicativos WPF, a melhor coisa que você pode fazer agora é escrever seu código WPF para funcionar com o .NET Framework 4.5. Os aplicativos da Windows Store usam um subconjunto seguro do .NET 4.5 juntamente com o Tempo de Execução do Windows. Quando o .NET Framework fornece a mesma funcionalidade que o Tempo de Execução do Windows (XAML é um ótimo exemplo), o perfil do .NET para aplicativos da Windows Store usa a versão WinRT. Se você continuar com esse subconjunto o máximo possível, seu código será extremamente portátil. Você achará isso especialmente útil quando estiver trabalhando com serviços e código assíncrono.

Ao compartilhar com o Silverlight, você fica um pouco mais restrito, pois o Silverlight não usa o .NET Framework 4.5 ou, na sua maior parte, a biblioteca de tarefas paralelas. No entanto, com o pacote de direcionamento assíncrono para o Silverlight 5, os usuários do Visual Studio 2012 que escrevem aplicativos Silverlight obtêm acesso a parte da funcionalidade Task<T> e async/await. No entanto, o código Adicionar Referência de Serviço não irá gerar o código de cliente assíncrono. Se isso for importante para você, poderá portar o código proxy gerado para o Silverlight. Uma abordagem melhor, usando a arquitetura que propus aqui, é encapsular as interações de serviço Web dentro de classes de serviço locais.

E o código que é idêntico? Classes de modelo — e, em muitos casos, classes ViewModel — entram nesta categoria. Aqui, você tem duas escolhas: projetos PCL (Portable Class Library) e projetos vinculados.

Projetos PCL PCL é uma ótima maneira de compartilhar DLLs compiladas entre diferentes destinos do .NET. O PCL permite compartilhar assemblies entre .NET, .NET para aplicativos da Windows Store, Silverlight, Windows Phone e muito mais. Para usar o PCL, você precisa restringir as referências do assembly àquelas da lista de compatibilidade. Saiba mais sobre o PCL em bit.ly/z2r3eM.

Projetos vinculados com código-fonte compartilhado e compilação condicional É um recurso do Visual Studio que permite ter vários projetos, cada um direcionado para plataformas diferentes, mas com uma única cópia compartilhada do código-fonte. No passado, usei essa abordagem, principalmente para compartilhar código entre o ASP.NET no servidor e o Silverlight no cliente. Você pode encontrar um exemplo no meu blog em bit.ly/RtLhe7. 

Embora tradicionalmente eu tenha usado projetos vinculados para a maioria dos meus cenários de reutilização, o PCL realmente evoluiu nas versões mais recentes. Se seu foco for WPF e XAML WinRT, o PCL permitirá que você use quase tudo do perfil .NET 4.5 para aplicativos da Windows Store. Quando estiver em dúvida, comece com o PCL.

Uma coisa que gosto sobre a abordagem de projeto vinculado é o que posso fornecer funcionalidade adicional específica de plataforma através de classes parciais e compilação condicional. Os símbolos de compilação condicional são definidos na guia de compilação da página de propriedades do projeto, como mostrado na Figura 2.


Figura 2 Página de propriedades do projeto mostrando os símbolos de compilação

Por padrão, vários símbolos de compilação condicional são definidos por você, como mostrado na Figura 3.

Figura 3 Símbolos de compilação condicional

Plataforma Símbolo de compilação
Windows Runtime + .NET Framework NETFX_CORE
WPF/.NET Framework 4.5 Desktop (nenhum)
Silverlight SILVERLIGHT

Observe que o .NET Framework completo não define símbolos de compilação — ele é considerado a plataforma padrão. Se isso não lhe deixar confortável, você poderá adicionar seus próprios símbolos de compilação; apenas certifique-se de fazer isso em todos os projetos do .NET Framework da sua solução.

Você também pode usar a compilação condicional no código para poder extrair namespaces diferentes, dependendo da plataforma de destino:

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

Em qualquer aplicação não trivial, você provavelmente vai se ver usando PCL e projetos vinculados para compartilhar código. No entanto, compartilhar XAML é mais complexo.

Compartilhamento interfaces do usuário e recursos XAML

Por várias razões, compartilhar XAML é mais difícil do que compartilhar código. O passo mais importante para fazer isso é personalizar a interface do usuário para o formato e a plataforma de destino. (Consulte "Abrace a nova estética do design de interface do usuário do Windows" para obter algumas dicas aqui). Na maioria dos casos, seu tempo de desenvolvimento é gasto melhor garantindo que o código seja reutilizável, porque você terá mais recompensa por menos esforço. No entanto, haverá um desejo e uma tendência de compartilhar XAML entre projetos.

O XAML não tem o conceito de compilação condicional. Como resultado, as diferenças de namespace são mais difíceis de gerenciar do que no código. Além dos próprios namespaces, a maneira como você os importa para XAML mudou entre o XAML WinRT e as outras versões.

Considere este XAML do .NET Framework:

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

E este XAML do WinRT:

xmlns:localControls="using:WindowsApp.Controls"

Em vez da instrução "clr-namespace", o XAML do WinRT usa a instrução "using" em XAML para importar namespaces. Por que as equipes do produto fizeram isso? Namespaces importados em XAML podem vir de código não-CLR — C++, por exemplo. Não só você agora tem suporte para XAML em C++, como também pode escrever assemblies de extensão em C++ e utilizá-los no seu código .NET. Isso significa que o termo "clr-namespace" já não é mais preciso.

Uma maneira de lidar com as diferenças é carregar o XAML dinamicamente. Nos tempos do Silverlight 1.1 alpha, esta era a maneira de gerar usercontrols: o XAML era carregado e processado dinamicamente no tempo de execução. Desde então, essa abordagem tem sido usada por desenvolvedores de aplicativos para flexibilidade em todas as plataformas.

Quando você carrega dinamicamente o XAML, está trabalhando com cadeias de caracteres. Isso significa que você pode substituir ou subdefinir o texto como quiser antes de carregá-lo na árvore visual. Por exemplo, digamos que você tenha uma definição de usercontrol vazia em seu projeto WPF ou Silverlight. O usercontrol é apenas um shell que define namespaces e a classe. Então, você tem um shell equivalente no projeto XAML do WinRT.

Este é o XAML do .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>

E este é o XAML do 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>

Os dois controles de usuário XAML são os mesmos modelos comuns de sempre. A única alteração que fiz foi dar um nome ao elemento raiz Grid e remover alguns namespaces não utilizados para manter o código curto. O codebehind para os controles pode ser compartilhado usando as técnicas de compartilhamento de código, mas eu recomendo particionar o código em uma classe compartilhada separada sempre que possível.

Em seguida, para carregar o XAML no tempo de execução, você pode usar o código semelhante ao que você vê na Figura 4.

Figura 4 Código para carregar XAML dinamicamente

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));
  }
}

O código para carregar no XAML do WinRT é ainda mais fácil devido ao suporte ao carregamento direto da cadeia de caracteres:

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

Para simplificar, carreguei o XAML de uma cadeia de caracteres codificada aqui e usei um XAML que já é portátil e não exige qualquer manipulação da cadeia de caracteres. No primeiro, se você quiser suporte do designer, faça o código carregar texto de um arquivo de recurso XAML. Em seguida, inclua todas as definições habituais de classe e xlmns para suportar o designer, mas descarte-as durante a etapa de carregamento do XAML.

Independentemente de como o XAML fica na árvore visual, se você quiser conectar eventos no XAML carregado dinamicamente, poderá fazer isso a partir do código também:

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

Da mesma forma que você pode carregar a interface do usuário XAML, você também pode carregar recursos no tempo de execução. Você pode criá-los a partir do zero ou, usando as mesmas abordagens mostradas aqui, carregá-los do código-fonte 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));
}

Ao carregar recursos dinamicamente, certifique-se de tê-los carregados antes que eles sejam referenciados. No caso de estilos implícitos, eles simplesmente não se aplicarão a nada que já estiver na árvore visual quando o recurso for criado.

Para ser claro, toda essa abordagem é um pouco complicada e não funcionará sem problemas em todos os cenários. (Em algum momento, a manipulação da cadeia de caracteres pode dar mais trabalho do que vale a pena). Mas se você quiser máxima reutilização da entre plataformas, esta é uma forma possível de fazer isso. Pessoalmente, eu usaria isso somente para componentes críticos da interface do usuário que mudarão muito ou são demasiado complexos ou numerosos para simplesmente copiar e colar normalmente.

É claro que você também poderia gravar uma ação de compilação personalizada ou outra extensão do Visual Studio para manipular automaticamente o processamento quando os arquivos forem salvos, verificados, criados, ou para algum outro passo.

A forma final é evitar completamente o XAML e criar toda interface do usuário a partir do código. Geralmente, não aconselho esta abordagem para a maioria dos aplicativo — exige muito trabalho extra e você tem zero suporte do designer. No entanto, interfaces do usuário orientadas por dados combinam muito bem com esta abordagem. Se você puder criá-lo em XAML, poderá criá-lo em código, como no XAML do WinRT mostrado na Figura 5.

Figura 5 Criando uma interface do usuário com XAML do 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, com exceção das configurações de fonte (para manter a lista curta), é equivalente ao XAML carregado dinamicamente que adiciona um TextBlock e um TextBox à grade LayoutRoot, contidos em uma grade.

Considere conjuntos de ferramentas de código aberto

Muitos dos melhores kits de ferramentas XAML/C# são de código aberto. Em um projeto de código aberto você, é provável ver pessoas interessadas aprender e adicionar os tipos de recursos que possibilitam a movimentação entre Silverlight, WPF e o Tempo de Execução do Windows.

Há uma série de kits de ferramentas MVVM, por exemplo, que são portáteis para vários tipos diferentes de XAML. Usando um deles, você pode ajudar a reduzir o número de alterações que seu código-fonte exige para você compartilhá-lo ou portá-lo. Da mesma forma, você encontrará controles, bancos de dados locais e outros conjuntos de ferramentas disponíveis para uso entre plataformas.

Há sempre o risco de os desenvolvedores de código aberto não trabalharem para as novas versões de destino das plataformas, mas com acesso ao código-fonte, você pode forjar o código e usá-lo se quiser. Apenas devolva o código quando terminar.

Decidir o que deve ser um aplicativo de interface do usuário da Windows Store

Quando chegar a hora de criar seu novo aplicativo da Windows Store, tenha em mente que nem todos os aspectos de todos os aplicativos de desktop se traduzem diretamente em aplicativos da Windows Store. Por exemplo, um aplicativo grande com 300 formulários, que executa um pacote completo de funções diferentes para diferentes usuários, não é necessariamente um bom candidato para a nova interface do usuário do Windows. Em vez disso, os aplicativos da Windows Store devem ser centrados na tarefa e adaptados para um uso específico.

Tome como exemplo um aplicativo de seguro. Você pode ter um aplicativo que é compartilhado por um grande número de usuários na empresa. Ele lida com funções de supervisão para gerenciar a segurança dos usuários. Ele permite registrar reclamações de vidro quebrado por telefone, bem como em um laptop em campo. Ele tem uma funcionalidade integrada para criar novas políticas etc.

Se você dividir o aplicativo em uma série de aplicativos menores centrados na tarefa (ou no usuário), será mais adequado para a nova interface do usuário do Windows. Por exemplo, você pode querer um aplicativo separado para o ajustador de campo focado especificamente para registrar informações no local do acidente. Como ele é focado, inclui suporte para tirar fotografias e gravar vídeo, bem como cache local de dados para áreas desconectadas ou com baixo sinal. Esse aplicativo compartilha provavelmente muitos códigos com os outros aplicativos da empresa, mas seu foco facilita a adaptação aos cenários para os quais foi criado.

Conclusão

O XAML do WinRT, o Silverlight e o WPF foram criado com finalidades diferentes em mente, mas são mais semelhantes do que diferentes. Compartilhar código entre eles é fácil, e é possível compartilhar XAML. Há muitas técnicas adicionais que você pode seguir para focar nas três plataformas e migrar do desktop para a nova interface do usuário da Windows Store. Eu adoraria continuar essa conversa no Twitter e no meu blog em 10rem.net. Se você usou outras técnicas para multiplataforma ou portabilidade de código no Tempo de Execução do Windows, adoraria receber seus comentários.

Pete Brown é o cara do XAML e gadgets do Windows 8 na Microsoft. Ele também é autor de "Silverlight 5 in Action" (Manning Publications, 2012) e "Windows 8 XAML in Action" (Manning Publications, 2012). Seu blog e site são 10rem.net, e você pode segui-lo no Twitter em twitter.com/pete_brown.

Agradecemos ao seguinte especialista técnico pela revisão deste artigo: Tim Heuer