Migrando o XAML/código do Silverlight ou do WPF para um aplicativo da Windows Store

Applies to Windows and Windows Phone

Se estiver familiarizado com outras plataformas baseadas em XAML, como WPF (Windows Presentation Foundation), Microsoft Silverlight ou Silverlight for Windows Phone, então você pode reutilizar essas habilidades para criar aplicativos da Windows Store. Este tópico lista as diferenças gerais que você deve conhecer ao migrar o código e o XAML do seu aplicativo original do WPF ou do Silverlight.

Observação  Se você estiver migrando um aplicativo do Windows Phone que usa XAML, veja Recursos para desenvolvedores do Windows Phone.

Mapa: como este tópico está relacionado aos outros? Consulte: Mapa de aplicativos da Windows Store em C# ou Visual Basic.

Técnicas gerais para importam XAML e código

Quando você está migrando código e XAML que foi escrito anteriormente para outra estrutura de interface do usuário, tal como WPF ou Silverlight, as etapas de migração envolvidas são mais substanciais do que a atualização entre versões da mesma estrutura, por exemplo. Mesmo assim, usando este tópico para identificar áreas em que diferenças de API e modelo de programação, você pode reutilizar partes de seu código e do XAML. A melhor forma de fazer isso é integrar essas partes na estrutura do código e do XAML, que você obtém de um novo modelo de projeto do Microsoft Visual Studio para um aplicativo da Windows Store, usando C++, C# ou Visual Basic. Dessa forma, você obterá uma estrutura de navegação apropriada para suas páginas XAML e os namespaces do Tempo de Execução do Windows incluídos para seu code-behind. Se você precisar de mais páginas XAML ou mais código, use as opções Adicionar novo para começar com uma página do aplicativo da Windows Store ou arquivo de código, copie seu XAML ou código original como segmentos para a nova página/arquivo e, em seguida, faça as conversões de nível de linha, se necessário.

As seções restantes deste tópico abordam várias áreas de recurso que são comuns às estruturas iniciais da interface do usuário e aos aplicativos da Windows Store. Leia cada uma dessas seções de forma a ter uma visão geral das diferenças envolvidas e o que você deve fazer para ter seu XAML e código migrados funcionando em um aplicativo da Windows Store.

Novo projeto e comportamento

Os aplicativos da Windows Store possuem uma aparência e um comportamento (personalidade) exclusivos que os diferenciam de outros aplicativos, incluindo os aplicativos criados usando outras plataformas baseadas em XAML. Dedique um tempo para aprender as práticas recomendadas para criação de um excelente aplicativo da Windows Store. Lidar com os aspectos de design da criação de um aplicativo da Windows Store frequentemente significa que você deve recompor partes substanciais de sua interface do usuário. Em especial, a forma em que você manipula caixas de diálogo, menus, comandos de entrada, listas talvez tenha que ser recomposta para que você possa seguir as diretrizes de design. Veja Criando excelentes aplicativos da Windows Store e Diretrizes de experiência do usuário para aplicativos da Windows Store.

Objeto de aplicativo e modelo de aplicativo

  • O modelo de aplicativo para ativação e a vida útil do aplicativo são diferentes porque os aplicativos podem ser suspensos e reiniciados. Para saber mais, veja Iniciando, retomando e executando multitarefas.
  • A marca Application em app.xaml não pode ser usada para anexar eventos de ciclo de vida do aplicativo; a conexão de eventos para eventos como Suspending deve ser parte da lógica de inicialização no arquivo code-behind app.xaml.
  • O objeto Window é diretamente menos equivalente a um aplicativo em execução HWND de uma perspectiva de programação do Microsoft Win32. Alguns recursos avançados de janelas são exibidos em um objeto separado, que você obtém usando o valor da propriedade Window.CoreWindow.
  • Por outro lado, se estiver vindo de uma perspectiva do aplicativo Silverlight, você não terá mais o host do navegador como um limite de programação intermediário: seu aplicativo da Windows Store é executado diretamente no Tempo de Execução do Windows. Isso simplifica as coisas, evitando problemas de hospedagem do navegador em que o Silverlight teve de trabalhar, como tratamento de entrada passando por uma camada de acesso do programa, acesso a armazenamento limitado e um modelo de cache e segurança voltado à Internet.
  • Os aplicativos Silverlight podem empacotar partes do aplicativo no pacote de implantação, como partes externas, ou baixar componentes sob demanda. Um aplicativo da Windows Store também tem essas opções, mas as APIs usadas para acessar as partes do pacote são diferentes. Onde o Silverlight usa Application.GetResourceStream, um aplicativo da Windows Store usa um modelo mais generalizado, em que o pacote instalado é apenas uma pasta de armazenamento. Por exemplo, você pode obter o valor da propriedade Package.InstalledLocation e depois chamar uma variedade de APIs StorageFolder (a maioria delas é assíncrona) para obter qualquer outro componente no pacote. Para saber mais, veja Criando e recuperando recursos em aplicativos da Windows Store.
  • O modelo de aplicativo de Tempo de Execução do Windows usa um conceito de funcionalidade. Você deve declarar uma funcionalidade como parte de seu processo de desenvolvimento e implantação, e um usuário poderá ver na interface do usuário da Windows Store que seu aplicativo solicitou uma funcionalidade específica. Talvez seja necessário solicitar funcionalidades para acessar o armazenamento de biblioteca para um usuário, para usar APIs de webcam e assim por diante. Para determinado código que antes funcionava no Silverlight e no WPF, mesmo se o código for convertido corretamente no nível da sintaxe, talvez você ainda precise solicitar uma funcionalidade do Tempo de Execução do Windows para acessar esse código. Para saber mais, veja Declarações de funcionalidades do aplicativo.
  • Iniciar um aplicativo diretamente de um bloco não é a única forma de ativar um aplicativo da Windows Store. Por exemplo, seu aplicativo talvez dê suporte à inicialização por associações de arquivos, por um contrato "Executar em" etc. Você deve planejar isso preservando o estado do aplicativo como dados de aplicativo e garantindo que seu aplicativo tenha todos os dados necessários para inicialização em todos os cenários de ativação possíveis. Para saber mais, veja Como ativar um aplicativo e outros tópicos em Iniciando, retomando e usando multitarefas.

Programação .NET e projeção de tipo

A arquitetura do Tempo de Execução do Windows é baseada no princípio de que os desenvolvedores podem utilizar diferentes linguagens para acessar a mesma funcionalidade e os mesmos conceitos subjacentes do Tempo de Execução do Windows. Um aspecto de como cada programa pode ter diferentes linguagens no Tempo de Execução do Windows e ainda preservar características ou padrões da linguagem é a projeção de tipo. No caso de linguagens Microsoft .NET, os desenvolvedores dessas linguagens estão familiarizados com o sistema de tipos do .NET e com os tipos e conceitos primitivos implementados pelo assembly .NET mscorlib.

Há uma lista de tipos que são especificamente projetados para .NET ao programar para o Tempo de Execução do Windows. Esses tipos existem no assembly mscorlib e no namespace System ou são adicionados especificamente a um dos assemblies WindowsRuntime que são incluídos como assemblies de referência .NET para programação do Tempo de Execução do Windows.

  • Interfaces de coleção comum projetam as interfaces de coleção que são familiares aos programadores .NET. O IVector<T> é projetado como IList<T>. O IMap<K,V> é projetado como IDictionary<TKey,TValue>. Tipos enumeráveis dão suporte à sintaxe e aos métodos de extensão relacionados foreach através de System.Linq. Classes de exibição relacionadas e variantes somente leitura possuem projeções semelhantes. Por meio dessas projeções, qualquer classe de Tempo de Execução do Windows que implementa uma interface de coleção pode dar suporte à API da interface da coleção .NET projetada.

  • O Uri é projetado como System.Uri. (Entretanto, existem algumas diferenças notáveis. Veja a seção "URIs".)

  • "Primitivas" comuns são projetadas como o tipo mscorlib/System, com o qual os desenvolvedores estão familiarizados em função da programação .NET. Por exemplo, qualquer código de aplicativo que envolva um valor double pode usar a API fornecida para System.Double ao programar com uma linguagem .NET.

  • As APIs .NET que interagem com o sistema de tipos podem referenciar o System.Type .NET e você pode usar o operador typeof no código do Tempo de Execução do Windows. (Observação: se você for fazer interoperabilidade ou usar C++ em parte de seu código de outras maneiras, o C++ possui um operador typeid, mas ele é limitado se comparado a typeof.)

  • IReference<T> é projetado como Nullable<T> para .NET e habilita uma sintaxe de linguagem como bool? para representar um booliano anulável.

  • EventHandler<T> é projetado como System.EventHandler<TEventArgs> para .NET.

  • HResult é projetado como System.Exception para .NET. Há também suporte à extração de informações de mensagem de um erro do Tempo de Execução do Windows por API e ao fornecimento de uma exceção de tipo apropriada baseada em System.Exception a um desenvolvedor do .NET. Você pode usar try-catch e técnicas semelhantes para o seu tratamento de exceção, e pode lidar com muitas exceções .NET padrão com as quais já esteja familiarizado. Para saber mais, veja Tratamento de exceções para aplicativos do Tempo de Execução do Windows em C# ou Visual Basic.

  • Os padrões ICommand usam a definição .NET (System.Windows.Input.ICommand).
  • As interfaces que você usava para objetos comerciais com reconhecimento de associação desenvolvidos em .NET são convertidas quando você usa o objeto como uma fonte de dados do Tempo de Execução do Windows. Por exemplo, uma associação pode responder a PropertyChanged ou a CollectionChanged conforme implementada em uma classe de objeto comercial originalmente criada para WPF ou Silverlight.

  • Muitas das estruturas que geralmente são usadas como tipos de valores para programação da interface do usuário da linguagem XAML são projetadas como estruturas que possuem métodos de utilitário disponíveis. Essas estruturas têm o mesmo nome e local do namespace, mas referenciam um assembly WindowsRuntime para que os métodos de utilitário sejam compatíveis com .NET. Por exemplo, os programadores .NET podem usar a API de utilitário de Matrix3D, como HasInverse, ou os operadores internos. (C++/CX também possui suporte a utilitários para suas estruturas, em que a implementação também é feita como uma projeção, mas esse suporte é mais limitado.)

  • Um conceito relacionado é que, quando um tipo é projetado como um tipo .NET, ele pode dar suporte para métodos de extensão .NET. Isso habilita métodos de extensão .NET que são especificamente projetados para a programação de aplicativos da Windows Store. Por exemplo, um tipo .NET existente, como StreamReader, pode dar suporte a métodos que usam padrões async similares àqueles das APIs Windows.Storage.

  • O tipo base de todos os objetos de tempo de execução aparece como System.Object, e tem a API System.Object esperada, como ToString. Entretanto, aqui estão algumas das poucas diferenças nas implementações desse métodos quando executados no Tempo de Execução do Windows. Essas diferenças são frequentemente citadas na documentação de referência do .NET, em uma seção Observações para o Tempo de Execução do Windows.

Observação  As projeções de tipo têm a finalidade de ajudar em cenários de migração de XAML e de código, especialmente quando você migra o code-behind de objetos de negócios, classes lógicas autocontidas ou páginas XAML. Na maioria das vezes, você não precisará investigar se um tipo do seu código original realmente é um tipo projetado no Tempo de Execução do Windows. Os compiladores e modelos de projeto farão a coisa certa para você.

Quando você usa tipos projetados, talvez ainda precise de referências de namespace para os casos em que as projeções estão lá para suporte ao tempo de execução, mas não fazem parte das bibliotecas da estrutura principal .NET e não estão definidas em namespaces .NET existentes como System.Collections.Generic. Por exemplo, se você tiver o código C# que usa a estrutura Point, ainda será necessária uma instrução using que faça referência ao namespaceWindows.Foundation, porque é assim que o Point projetado também é definido.

Para saber mais sobre aplicativos .NET e da Windows Store que usam programação em C++, C# ou Visual Basic, veja Visão geral do .NET para aplicativos da Windows Store.

Modelo de programação geral

  • Se você não estiver programando com uma linguagem .NET, mas com extensões de componentes Visual C++ (C++/CX), muitas estruturas têm uma definição de estilo C básico que não dá suporte a membros que não sejam dados.
  • O modelo de programação integrou a sintaxe para operações assíncronas. As operações assíncronas são mais predominantes no modelo de programação do que eram no WPF ou no Silverlight. A finalidade das APIs assíncronas é reforçar padrões que dificultam o bloqueio inadvertido do thread da interface do usuário em um manipulador de eventos ou retorno de chamada. Para saber mais, veja Guia de início rápido: chamando APIs assíncronas em C# ou Visual Basic.
  • Devido a padrões assíncronos ou outras tarefas em segundo plano que não estão no thread da interface do usuário, talvez você tenha a necessidade de fazer chamadas de outros threads que acabam atualizando o thread da interface do usuário, assincronamente. A API que você usa para atravessar os threads (geralmente de um thread em segundo plano para o thread da interface do usuário) é a mesma que no Silverlight, DependencyObject.Dispatcher.
  • O acesso ao arquivo e ao armazenamento que pode ter sido feito com as APIs de assembly mscorlib e system agora são feitos com API dedicada do sistema, como StorageFile.
  • Se você estiver programando usando a linguagem .NET, poderá também usar a lógica baseada em System.IO.Stream existente. Você pode acessar métodos de extensão que retornam um fluxo de tipos similares do Tempo de Execução do Windows, chamando, por exemplo, o método de extensão AsStream em uma instância IRandomAccessStream. Em um editor de código, a API System.IO.Stream aparecerá como opção nos menus suspensos do Microsoft IntelliSense sempre que você tiver instâncias Stream obtidas de tipos de fluxo/buffer relacionados.

Navegação

O modelo de navegação do Silverlight usava páginas XAML, avulsas ou no pacote, como base para direcionar o conteúdo no qual navegar. Os aplicativos da Windows Store usam tipos e, particularmente, o tipo que é indicado como x:Class para uma página XAML. Um bom plano seria usar a funcionalidade Adicionar Novo do Gerenciador de Soluções para criar novas páginas XAML no modelo de projeto de aplicativo da Windows Store de sua escolha. Importe os elementos abaixo do nível raiz da página original do Silverlight e solucione os problemas de conversão que possam existir. Em seguida, construa uma estrutura de navegação usando um Frame na página principal. De forma alternativa, crie um novo projeto usando os modelos Aplicativo de Grade ou Aplicativo de Divisão. Eles incluem páginas que já têm uma estrutura de navegação, além de modelos de estado da exibição e lógica suspender/retomar. Você também pode usar a estratégia de navegação e o modelo aplicativo de hub. Para saber mais, veja Parte 3: Navegação, layout e modos de exibição ou Adicionando um controle Page.

O Tempo de Execução do Windows tem as classes Page e Frame no conjunto de controles padrão, enquanto no Silverlight elas eram provenientes das bibliotecas do SDK e tinham que ser distribuídas. Se você estiver migrando XAML que contém um Page ou um Frame, poderá remover o prefixo "sdk:" dos elementos e o mapeamento de xmlns do prefixo "sdk:". As páginas podem substituir OnNavigatedTo ou OnNavigatedFrom quando precisarem executar alguma limpeza durante uma ação de navegação. Porém, há também eventos e substituições disponíveis na classe Frame, por exemplo, Navigated, então convém colocar sua lógica de navegação no Frame, e não nas páginas individuais. Além disso, enquanto o Frame do Silverlight tinha botões simples de navegação em seu modelo de controle, os recursos de navegação do Tempo de Execução do Windows são integrados aos modelos de página e usam estilos e modelos dedicados para os botões propriamente ditos. Para saber mais, veja Guia de início rápido: navegando entre as páginas.

Blocos e notificações

Os recursos de blocos dinâmicos e notificações tinham níveis variáveis de suporte nas estruturas anteriores de XAML, então não havia um procedimento geral para convertê-los. Para saber mais sobre como esses recursos funcionam em um aplicativo da Windows Store, veja Trabalhando com blocos, selos e notificações do sistema . Se o seu aplicativo usa notificações por push do Windows Phone, veja Recursos para desenvolvedores do Windows Phone.

Usando o .NET Framework

Para aplicativos da Windows Store que usam linguagens .NET (C# ou Microsoft Visual Basic), as APIs do .NET Framework que você chama fazem parte de um perfil específico do .NET Framework. Essa relação é explicada detalhadamente no tópico Visão geral do .NET para aplicativos da Windows Store.

Funcionalidades da linguagem XAML

O XAML para Tempo de Execução do Windows é muito parecido com o XAML para Silverlight em termos das funcionalidades que fazem parte da linguagem XAML em si e também é muito semelhante ao XAML para WPF. Mas há algumas diferenças.

  • Em vez de usar um conjunto de qualificadores clr-namespace:/assembly= para referências de namespace código-para-XAML, use o qualificador using:. Namespaces XAML não referenciam mais assemblies específicos; toda a qualificação e inclusão do assembly é tratada pelo modelo de aplicativo e pela forma como você forma o pacote do aplicativo.
  • Como não é possível mapear assemblies específicos, algumas das referências feitas a mscorlib, para dar suporte aos primitivos de CLR (Common Language Runtime), não funcionarão mais. Em vez disso, você pode usar os tipos intrínsecos da linguagem XAML, como x:String. Para saber mais, veja Tipos de dados intrínsecos XAML. Além disso, considere que muitas das cadeias de caracteres armazenadas anteriormente como x:String em um ResourceDictionary podem ser armazenadas com mais eficiência como uma cadeia de caracteres em um arquivo de recursos do projeto. Para saber mais, veja o tópico sobre como globalizar seu aplicativo.
  • O XAML para Tempo de Execução do Windows não dá suporte a extensões de marcação personalizada.
  • Em casos raros, um XAML em que um atributo Name não prefixado era aceito no Silverlight pode exigir a substituição por um atributo x:Name.
  • Alguns casos em que um Setter.Property excessivamente qualificado funcionava com o XAML do Silverlight não funcionarão com o XAML do Tempo de Execução do Windows. A maioria dos valores Setter.Property deve ser apenas o nome simples da propriedade de dependência e não uma tentativa de qualificar seu proprietário (as propriedades anexadas são uma exceção, você ainda deve qualificar o proprietário para elas.)
  • Se você estiver migrando XAML de WPF, há construtores que o XAML para Tempo de Execução do Windows não permite, além das diferenças do XAML para Silverlight já listadas. Eles incluem: extensão de marcação DynamicResource (e o comportamento de pesquisa de recursos subjacente), x:ClassModifier e x:Subclass, x:Array e suporte a genéricos relacionados do XAML 2009, x:Code, x:Static, x:Type usado explicitamente (há avaliação implícita de x:Type para propriedades que precisam dele), nós VisualTree em modelos e algumas outras diferenças pequenas. Você precisa interceptar qualquer problema de compatibilidade XAML na fase de design, com base nas exceções de análise XAML.

Toque e entrada

  • Não há eventos de entrada específicos ao mouse, como MouseLeftButtonDown. Esses eventos, juntamente com os eventos específicos de entrada por toque, são unificados em eventos Pointer. Na maioria dos casos, é possível converter o evento relevante do mouse em PointerPressed, PointerReleased, PointerEntered ou PointerExited. Para saber mais, veja o tópico sobre como responder à interação com o usuário. Para MouseWheel, use o evento PointerWheelChanged. O delta de roda pode ser obtido no PointerPointProperties no PointerPoint principal dos dados do evento.
  • Se você estava lidando com manipulações brutas para habilitar ações nos controles e criou estados visuais para as suas manipulações, verifique se os controles que está usando já não têm suporte interno a manipulação ou gestos. Por exemplo, o ListBox do Tempo de Execução do Windows possui diversas interações já habilitadas como transições de tema.
  • Para interações em geral, considere manipular os eventos de gesto em vez dos eventos de ponteiro, pois isso geralmente é mais fácil. Por exemplo, Tapped geralmente é um evento melhor no modelo de evento do Tempo de Execução do Windows para interações que seriam manipuladas por um evento específico de mouse no Silverlight.
  • Interações por toque específicas podem ser habilitadas ou desabilitadas por elemento, usando propriedades. Por exemplo, você pode definir IsRightTapEnabled como false, e esse elemento não dará origem a um evento RightTapped. Isso tem como objetivo evitar possíveis problemas com o reconhecimento de gesto e manipulação quando há um excesso de eventos em uma árvore visual de composição de controle.
  • Chaves para eventos chaves não possuem uma separação PlatformKeyCode / Key. A chave reportada dos dados do evento usa uma enumeração diferente, VirtualKey, e outros dados importantes estão disponíveis como KeyStatus.
  • A captura do ponteiro de UIElement pode capturar vários ponteiros, para dar suporte a manipulações de toque que iniciam a captura. Para obter a referência de ponteiro correta, use uma classe de dados de evento relacionada ao ponteiro, como PointerRoutedEventArgs.
  • As chamadas para Control.Focus devem especificar um valor de enumeração que indique que a ação em foco foi programática. O Tempo de Execução do Windows separa as chamadas de foco porque seus estados visuais usam um comportamento diferente para chamadas de foco programáticas. Talvez você precise adicionar a seus modelos novos estados visuais personalizados para um foco que não seja de teclado.
  • Alguns controles do Tempo de Execução do Windows possuem manipulação interna. Por exemplo, um ScrollViewer manipula interações de rolagem, movimento panorâmico e zoom internamente para que o controle dê a resposta correta à ação. A manipulação do controle pode evitar que eventos de ponteiro de nível inferior sejam acionados. Você pode chamar CancelDirectManipulations para substituir esse comportamento. Mas também convém examinar a manipulação de entrada em seus controles gerais. Um comportamento interno talvez já sirva para o seu cenário, sendo desnecessário um manipulador de nível de ponteiro.

Layout/composição de gráficos e elementos

  • Para otimizar o conjunto de elementos das funcionalidades da nova pilha de elementos gráficos, cortamos algumas APIs/conceitos que retardariam a renderização. Exemplos incluem OpacityMask, clipes não retangulares, funções de easing personalizadas e efeitos de bitmap.
  • Não há suporte para VideoBrush, nem para RadialGradientBrush no Tempo de Execução do Windows.
  • A API de geração de imagens do Tempo de Execução do Windows tem um componente de geração de imagens subjacente diferente e de maior capacidade, o WIC (Windows Imaging Component). A boa notícia é que esse componente é compatível com muitos outros formatos de origem de imagem do que o Silverlight ou o WPF. Também há tipos de codificador e decodificador disponíveis fáceis de usar, bem como API adicional no WIC para manipulação de imagem. Para saber mais, consulte o namespace Windows.Graphics.Imaging.
  • O BitmapCache tem uma lógica subjacente diferente do Silverlight, do Silverlight para Windows Phone ou do WPF. Além disso, o cache de bitmap pode ter uma inter-relação com animações e pode fazer com que algumas animações sejam consideradas independentes. Se você usa UIElement.CacheMode em tudo, analise novamente seu aplicativo e reveja se o uso de uma configuração UIElement.CacheMode para algumas de suas interfaces do usuário representa um ganho de desempenho para um aplicativo da Windows Store. Para saber mais, veja UIElement.CacheMode e DebugSettings.IsOverdrawHeatMapEnabled.
  • Para alguns cenários em que você usava um WriteableBitmap, é recomendável usar RenderTargetBitmap como substituto.

Controles

  • Aplicativos da Windows Store e outras estruturas que usam XAML para definição de interface do usuário têm os mesmos controles básicos, como Button e ListBox, e contêineres de layout básicos, como Border, Grid e StackPanel. O Tempo de Execução do Windows também tem controles prontos para coleta, como SemanticZoom e FlipView. Além disso, o GridView é um controle independente, e não um componente usado em um ListView, com a única real diferença entre GridView e ListView sendo a orientação dominante dos itens apresentados que cada um usa. Para saber mais, veja Controles por função.
  • Embora muitas vezes você possa usar o mesmo controle utilizado no seu aplicativo original do Silverlight ou do WPF e talvez até mesmo uma interface do usuário inteira possa ser migrada para os componentes equivalentes, essa nem sempre é a melhor abordagem. É principalmente no momento de definir a interface do usuário do seu aplicativo que convém parar e revisar novamente a orientação de design de aplicativos da Windows Store. Por exemplo, seu aplicativo original e os controles em sua interface do usuário talvez não tenham sido projetados para dar prioridade ao toque, enquanto o aplicativo da Windows Store deve ser projetado para priorizar o toque. A experiência geral da interface do usuário também será diferente, pois a hospedagem não ocorre mais no navegador. Para saber mais sobre design, consulte Desenvolvendo a experiência do usuário para aplicativos. Para saber mais sobre as diretrizes de experiência do usuário para controle, consulte o Índice de diretrizes detalhadas de UX (experiência do usuário).

Animações, transições, estados visuais, estilos

  • O Tempo de Execução do Windows adiciona o conceito de animações de personalidade. Elas podem ser usadas em XAML como animações de transição e animações de tema aplicadas diretamente aos elementos da interface do usuário, sem a necessidade de direcionar várias propriedades desse elemento. As animações de storyboard funcionam quase de forma idêntica. Entretanto, nem todas as animações de storyboard são habilitadas por padrão. A desabilitação de animações dependentes por padrão tem como objetivo tornar os desenvolvedores mais atentos aos custos de desempenho de animações que causariam impacto significativo no thread principal da interface do usuário. Se a sua animação não funcionar como o esperado, tente definir EnableDependentAnimations como true. Entretanto, seja cauteloso, pois a execução de animações dependentes tem um custo de desempenho. Para saber mais, veja Animando sua interface do usuário, Animações com storyboard e Torne as animações mais suaves.
  • Se houver algum prefixo "vsm:" nas definições XAML de estado visual, remova os usos e a definição de prefixos. Não é mais preciso mapear separadamente os prefixos e namespaces de estado visual.
  • Se você está convertendo estados visuais, converta os conceitos "Mouse" em conceitos "Ponteiro", assim como mudou a manipulação de eventos no nível do item. Convém renomear os próprios nomes dos estados visuais, bem como ajustar quais propriedades são alteradas pelo estado. Consulte os dicionários de recursos XAML existentes como generic.xaml na subpasta include/winrt/xaml/design de uma instalação do SDK do Windows. Eles podem sugerir alguns padrões que você pode seguir para estados visuais e eventos relacionados.
  • Se você já tem um tema de alto contraste para um controle personalizado que foi convertido, lembre-se de seguir o modelo ThemeDictionaries sobre como conectar os temas à definição do controle. Em particular, é possível que você pretenda dar suporte aos temas nomeados identificados na enumeração HighContrastScheme. Para saber mais, veja Amostra de estilo em alto contraste XAML.
  • Você deve dar suporte a um modelo de tema claro e a um escuro para seus controles se o seu aplicativo permitir a alternância de tema. Eles estão disponíveis nos modelos padrão, mas você talvez precise adicionar um tema aos modelos personalizados que importar.
  • O WPF e o Silverlight permitiam o uso de uma expressão Binding para fornecer o Value de um Setter no Style. O Tempo de Execução do Windows não permite o uso de Binding para Setter.Value (Binding não é avaliado e Setter não tem nenhum efeito, você não recebe erros, mas também não obtém o resultado desejado). Ao converter estilos XAML do WPF ou do XAML do Silverlight, substitua qualquer uso da expressão Binding por cadeias de caracteres ou objetos que definam valores, ou refatore os valores como valores StaticResource compartilhados, e não como valores obtidos por Binding.

Mídia

  • As APIs de mídia são semelhantes, mas a forma como o Gerenciamento de Direitos Digitais (DRM) integra-se às APIs de mídia é diferente. Ao contrário do que ocorre no Silverlight, o Windows tem um modelo de DRM conectável, e PlayReady é um dos vários que podem ser compatíveis, portanto, as APIs são diferentes para dar conta de um gerenciador de proteção de conteúdo.

  • O MediaElement é basicamente o mesmo, embora provavelmente seja recomendável definir um novo modelo XAML para os modelos de controle de transporte MediaElement anteriores para criar a interface do usuário com reconhecimento de toque. Ou você pode usar AreTransportControlsEnabled para obter alguns controles de transporte padrão. Adições notáveis do Tempo de Execução do Windows à API MediaElement são aquelas em que você pode ter um "cartaz" para carregamento, detectar e usar modos de embalagem de vídeo estéreo e adicionar efeitos de vídeo.
  • A captura da câmera é conceitualmente diferente entre as plataformas e, se tiver esse recurso, você terá que reescrever, e não converter o código. Para saber mais, veja Como visualizar vídeo de uma webcam e Captura de mídia usando amostra do dispositivo de captura. Você usará provavelmente um CaptureElement como a superfície de exibição porque o VideoBrush não está disponível.

URIs

A manipulação do URI (Uniform Resource Identifier) para referências de arquivo funciona um pouco diferente no Tempo de Execução do Windows. URIs relativos não são permitidos, pelo menos não no nível dos tipos de URI puros. O System.Uri do .NET pode aparecer para lhe oferecer uma opção RelativeOrAbsolute em determinadas chamadas à API, mas na prática todos os URIs são absolutos e são avaliados em relação a conceitos e localizações, como o pacote de aplicativos, localizações selecionadas pelo usuário, dados do aplicativo, etc.

Qualquer valor de propriedade que leva a um URI, deve ser examinado. Você não pode usar URIs de esquemas de file:. É possível que você possa usar XAML com referências de URI para alguns valores, como arquivos Image.Source, sem se preocupar com problemas de URI, e fazer com que ele funcione como uma nova IU do Windows. Mas isso depende de como o seu aplicativo original foi estruturado. Quando especificado em XAML, um URI geralmente parece ser um URI relativo, mas essas cadeias de caracteres são processadas e concluídas pelo analisador XAML antes de definir qualquer propriedade no tempo de execução. Para reproduzir esse mesmo comportamento em code-behind, use o retorno FrameworkElement.BaseUri como o valor de parâmetro baseUri no construtor de Uri que combina um URI base com um URI relativo. Para saber mais, consulte Definindo recursos do aplicativo.

APIs de arquivo e armazenamento

As técnicas utilizadas para acessar arquivos e armazenamento no Tempo de Execução do Windows são bem diferentes das utilizadas no .NET, principalmente porque muitas dessas APIs usam um padrão assíncrono e as palavras-chave async/await. Para saber mais, veja o tópico Acessando dados e arquivos.

XML e XMLDOM

A área do .NET disponível para um aplicativo da Windows Store em C++, C# ou Visual Basic não inclui algumas das APIs DOM XML da estrutura, nem encaminha alguns dos tipos de base ao namespace Linq. Procure APIs similares em Windows.Data.Xml.Dom e System.Xml.Linq.

HTML hospedado e lado a lado

Para o Silverlight, o HTML lado a lado é direto porque o controle do Silverlight é hospedado em um elemento DOM e o outro conteúdo HTML está em outro elemento DOM ou um iframe. Ou, para WPF, você poderia ter usado o controle WebBrowser. Para um aplicativo da Windows Store que usa XAML para sua interface do usuário, o controle a ser usado para a exibição de conteúdo HTML é WebView. O modelo WebView define que o HTML é exibido em uma região dentro da interface do usuário XAML geral. O conteúdo HTML mostrado em um aplicativo da Windows Store não precisa ser examinado por motivos de experiência do usuário e segurança. Não simplesmente redirecione o que foi mostrado na iframe de um aplicativo do Silverlight para ser a Source de uma WebView. Você também terá que examinar qual lógica deve permanecer como código JavaScript para o HTML, em vez de executar como code-behind de sua página. Suas decisões feitas aqui serão influenciadas pela forma em que o Tempo de Execução do Windows processa eventos de interação do usuário nos limites do WebView. Para saber mais, veja WebView.

Convertendo projetos

De maneira geral, a conversão de um projeto inteiro é feita melhor quando se começa com um dos modelos de projeto existentes de um aplicativo da Windows Store. Em seguida, use a funcionalidade Adicionar do Gerenciador de Soluções para introduzir páginas XAML e arquivos code-behind novos ou existentes. Por fim, migre blocos de código específicos para os arquivos XAML e de código. Se você fizer isso dessa maneira, pode evitar os detalhes da implementação da estrutura anterior e a infraestrutura de projetos e compilações que podem estar presentes acidentalmente. Você pode usar as instruções using/Imports com os namespaces "Windows" corretos, referenciar os tipos de compilação atuais e acessar o sistema de recursos .resw, pois todos esses elementos estarão disponíveis nos projetos e páginas modelados recentemente.

Se o seu projeto do Silverlight usava o sistema de localização baseado em Binding como documentado no tópico Como tornar o conteúdo XAML localizável, considere alterar a técnica de localização para usar cadeias de caracteres declaradas no sistema PRI (Índice de Recurso do Pacote). O sistema de localização baseado em Binding continuará funcionando, mas ele não tem praticamente nenhum suporte de ferramenta que é possível com o PRI e com os arquivos .resw, tanto no Visual Studio quanto nos processos de localização dedicada ou ferramentas baseadas na metodologia de localização do Visual Studio.

Se você tentar inserir arquivos de código inteiros, pode pesquisar e substituir instruções using/Imports de forma geral ou referências totalmente qualificadas. Por exemplo, "System.Windows" deve ser substituído por "Windows.UI.Xaml". Há algumas exceções a essa regra geral de como os tipos do Silverlight/WPF se relacionam com os tipos e namespaces do Tempo de Execução do Windows, e mencionaremos esses casos na documentação da API (na seção Comentários).

Para saber mais sobre os modelos de projeto, veja Modelos de projeto C#, VB e C++ para aplicativos da Windows Store.

Mais recursos sobre a migração de aplicativos

Tópicos relacionados

Recursos para desenvolvedores do Windows Phone
Mapa para aplicativos da Windows Store em C# ou Visual Basic
Diretrizes de UX para aplicativos da Windows Store
Modelos de projeto C#, VB e C++ para aplicativos da Windows Store
Visão geral de .NET para aplicativos da Windows Store
Suporte do .NET Framework para aplicativos da Windows Store e o Tempo de Execução do Windows

 

 

Mostrar:
© 2014 Microsoft