Migrando seus aplicativos do Developer Preview para o Consumer Preview

Blog do desenvolvedor de aplicativos do Windows 8

Ideias sobre a criação de aplicativos com o estilo Metro para o Windows 8, da equipe de engenharia do Windows 8

Migrando seus aplicativos do Developer Preview para o Consumer Preview

  • Comments 0

Olá, sou John Sheehan, arquiteto parceiro da Equipe de Desenvolvimento do Windows.

Estamos muito felizes por vocês estarem desenvolvendo aplicativos para as versões de pré-lançamento. Seus comentários nos ajudam a aprimorar o Windows 8. Claro que o desenvolvimento de um pré-lançamento significa que é necessário fazer as atualizações dos aplicativos para cada versão de pré-lançamento – esta postagem é sobre isso, a migração dos seus projetos do Developer Preview para o Consumer Preview. Destacarei algumas das alterações aqui, mas para obter um guia detalhado, vocês podem baixar o white paper sobre a migração de aplicativos da //Compilação do Windows 8 Consumer Preview do Centro de Desenvolvimento.

Ao começar a pensar sobre a migração de aplicativos para o Consumer Preview, tenho certeza de que alguns de vocês estão se perguntando por que escolhemos fazer essa alterações. Posso garanti-los que levamos cada alteração muito a sério. Alguns aprimoramentos são feitos com base diretamente nos comentários que ouvimos: se falta algum recurso necessário ou se o mesmo é confuso, nós o facilitamos. Às vezes, após concluirmos um recurso e começarmos a usá-lo, percebemos que não atingimos os objetivos desejados e, assim, usamos o que aprendemos e o aperfeiçoamos. Levamos em conta vários fatores. Tenham certeza de que pensamos cuidadosamente sobre cada decisão, com o objetivo de criar uma ótima plataforma para seus aplicativos estilo Metro.

Tive que passar pelo processo de migração com o aplicativo Connect 4 que desenvolvi no Developer Preview. Sei que é um pouco trabalhoso fazer a migração, mas se vocês seguirem as etapas descritas na postagem e no documento, estarão prontos para começar muito rapidamente.

Então, aproveitem!

Começando do zero

Embora seja tentador manter seu projeto já existente e tentar migrá-lo para o Consumer Preview, tantas coisas mudaram desde o Developer Preview que é melhor começar um novo projeto. Por exemplo, no Visual Studio, houve inúmeras alterações nos arquivos de definição de projeto: a extensão de projeto do JavaScript foi renomeada para .jsproj e a instrução de importação foi alterada nos arquivos .csproj/.vbproj. Seu projeto existente nem mesmo abrirá por causa dessas alterações. Após começar um novo projeto, você poderá mover partes do seu antigo projeto para o novo.

Essas etapas são uma boa diretriz para a migração de seu código. Você também pode encontrar essas etapas e muitos outros detalhes da migração na //Compilação do Windows 8 Consumer Preview. (Mencionarei isto diversas vezes até o final desta postagem!)

  1. Crie um novo projeto no Visual Studio e escolha o modelo mais parecido com a interface do usuário do seu aplicativo existente.
  2. Se os novos Modelos de Item oferecem suporte aos contratos e recursos necessários, como o contrato do Seletor de Arquivos ou o contrato do Windows Search, use-os em vez de tentar reutilizar seu código existente.
  3. Após reconstruir os elementos básicos de sua interface usando os novos modelos, faça a migração dos ativos visuais e de áudio do antigo projeto para o novo. Limite o código adicional que levar para o projeto apenas à lógica de negócios personalizada existente no centro do seu aplicativo.
  4. Por fim, comece a delinear sua nova interface (estruturada com os novos modelos) com os ativos visuais e de áudio e a lógica de back-end.

Seguindo essas etapas, você naturalmente incorporará muitas das alterações ao código do aplicativo. Agora, vamos discutir algumas alterações específicas que podem afetar seu código ao migrá-lo para os novos modelos.

Alterações gerais que afetam todas as linguagens

Em primeiro lugar, gostaria de descrever algumas alterações no modelo de programação básico que afetam desenvolvedores em qualquer linguagem de programação.

Alterações de manifesto

O manifesto é o DNA do seu aplicativo. Ao fazermos alterações na plataforma, muitas vezes elas têm um impacto sobre a estrutura do manifesto. Dado o número de alterações no manifesto, provavelmente será mais fácil começar com o novo manifesto gerado ao criar seu novo projeto e usar o editor de manifestos para modificar este novo manifesto, em vez de tentar usar o já existente.

Modelo assíncrono de inicialização a quente

No Developer Preview, todos os métodos assíncronos eram de inicialização a frio. Ao fazer a chamada de um método assíncrono, você obtinha um objeto de operação assíncrono. Você fazia o registro para conclusão e retorno de chamada em andamento (se aplicáveis) neste objeto de operação e solicitava IAsyncInfo.Start. O problema com este modelo era que a chamada para Iniciar era redundante. Como desenvolvedor, seria razoável esperar que a operação assíncrona começasse ao fazer a chamada de método inicial.

Para tornar o modelo assíncrono mais intuitivo, o alteramos para um modelo de inicialização a quente. No Consumer Preview, quando você faz a chamada de um método assíncrono, obtém um objeto de operação assíncrono, mas não precisa fazer a chamada para Iniciar. Em vez disso, a operação é iniciada implicitamente quando o método assíncrono é chamado. Como o comando Iniciar não é mais necessário, o removemos de IAsyncInfo.

Se você já estiver usando .then() (JavaScript) ou await (C#), esta alteração não o afetará.

Além disso, acrescentamos tarefas PPL para facilitar a programação assíncrona em C++. Recomendo a consulta ao tutorial em //Compilação do Windows 8 Consumer Preview e a migração do código assíncrono para o modelo PPL.

Gerenciamento determinístico do tempo de vida dos objetos do Tempo de Execução do Windows (IClosable)

As APIs do Tempo de Execução do Windows podem fornecer ao seu aplicativo o acesso aos recursos do sistema, como manipulações de arquivos e soquetes de rede. Esses recursos são limitados e muitas vezes o usuário ou outros aplicativos não podem usá-los quando seu aplicativo os acessa. Seu aplicativo é responsável pela liberação desses recursos após terminar de usá-los. No entanto, a liberação explícita desses recursos era difícil no Developer Preview e muitos aplicativos os mantinham presos por mais tempo do que o necessário.

No Consumer Preview, as APIs do Tempo de Execução do Windows que acessam esses recursos do sistema podem controlar seu tempo de vida. Por exemplo, em JavaScript, esses objetos do WinRT expõem um método Fechar e em C#, implementam a interface IDisposable. Com o gerenciamento do tempo de vida exposto diretamente nessas APIs do WinRT, agora é muito mais fácil liberar os recursos do sistema quando seu aplicativo tiver acabado de usá-los. Use esses novos recursos de gerenciamento do tempo de vida para reduzir o consumo de recursos do seu aplicativo e garantir que seus clientes sempre tenham acesso aos recursos do sistema, como arquivos, quando seu aplicativo não os estiver usando.

Modelo de threading do WinRT simplificado

Recebemos seus comentários de que o modelo de threading COM subjacente ao WinRT era confuso porque introduzia considerações inexistentes em outros ambientes de programação. Alguns dos problemas eram:

  • O tempo de vida do objeto estava vinculado ao apartment em que foi criado.
  • O comportamento de marshaling automático violava o princípio de menor surpresa.
  • O retorno de chamada de evento muitas vezes era executado em um thread inesperado.
  • Os representantes eram inconsistentes em todo C++ / C#.

Para corrigir esses problemas, alteramos o modelo de threading para objetos do WinRT. Em um nível superior, as alterações são:

  • O tempo de vida de um objeto agora está vinculado a referências abertas. O objeto continua válido até que a última referência desapareça.
  • A maioria dos objetos é ágil. As chamadas para os métodos nesses objetos ocorrem diretamente no thread atual.
  • Os eventos mais comuns são roteados de volta ao thread em que foram registrados. Ainda há casos em que os retornos de chamada de evento podem ocorrer em um thread de trabalho. Porém, são menos comuns.
  • Os representantes C++ agora têm como padrão serem ágeis, como os representantes C# no Developer Preview. Os representantes ainda poderão realizar marshaling para o thread em que foram criados, se você especificar CallbackContext::Same ao criar o representante.

Alterações de (contratos) Windows.ApplicationModel

Introduzimos muitos aprimoramentos nos contratos do Consumer Preview. Esses aprimoramentos vêm na forma de alterações de APIs, funcionalidades, registros de manifesto e interfaces do usuário. Os contratos, como do Windows Search, de Compartilhamento, de Configurações, do Seletor de Arquivos etc., foram todos aprimorados de uma forma ou de outra. Por exemplo, adicionamos um novo contrato do Seletor de Arquivos, o FileSavePickerActivatedEventArgs, que permite ao seu aplicativo agir como um destino Salvar como. Este é um recurso incrivelmente avançado – com o qual é possível desenvolver um seletor que permita a abertura e o salvamento de arquivos pelos usuários na nuvem de maneira tão simples quanto se estivessem no disco local. Para acomodar essa alteração, renomeamos o contrato do Seletor de Arquivos no Consumer Preview como FileOpenPickerActivatedEventArgs.

Para os contratos suportados pelo Visual Studio, a maneira mais fácil de incorporar essas alterações é usar o novo Modelo de item para criar o contrato do zero. É possível adicionar ao novo modelo seu código existente com suporte ao contrato.

Esquemas de protocolo URI

Inúmeras APIs dependem de esquemas de protocolo URI para acessar o conteúdo no pacote do aplicativo ou nos locais de estado ApplicationData do aplicativo. Essas APIs incluem marcas de recursos nos aplicativos estilo Metro escritos em HTML/CSS/JS, Live Tiles, as APIs do ResourceLoader, o controle XAML WebView e as APIs de armazenamento de arquivos.

Atualizamos os nomes dos protocolos para torná-los consistentes em todos os aplicativos estilo Metro e pontos de integração do Windows 8. Também renomeamos esses esquemas de protocolo:

Esquema do Developer Preview

Esquema do Consumer Preview

ms-wwa://

ms-appx://

ms-wwa-web://

ms-appx-web://

localfolder://

ms-appdata://

Além disso, os aplicativos em XAML agora estão restritos ao uso de esquemas de protocolo suportados, como ms-appx://, para acessar recursos.

Alterações importantes nos aplicativos estilo Metro em HTML/CSS/JS

Várias alterações no Consumer Preview são específicas dos aplicativos estilo Metro escritos em HTML/CSS/JS. Veja aqui algumas alterações evidentes.

Alterações de controle

Os controles JavaScript e HTML disponíveis no Developer Preview passaram por muitas alterações em resposta aos seus comentários. Agora, ficou mais fácil adicionar os controles ao seu aplicativo e os métodos para interligá-los ao conteúdo estão mais intuitivos. Alguns dos controles que foram alterados de forma mais evidente e precisarão ser atualizados são o ListView, AppBar e FlipView. Por exemplo, você não pode mais usar um ArrayDataSource para popular um ListView. Em vez disso, você agora usa um WinJS.Binding.List para popular seus ListViews. Binding.List facilita muito o trabalho com os dados da memória do ListView.

Novamente, a //Compilação do Windows 8 Consumer Preview tem o conjunto completo de alterações de controle.

Navegação com documento primário

Anteriormente, era possível navegar no documento primário do seu aplicativo do StartPage empacotado no local para um URL baseado na Web. Isso impedia seu aplicativo de interagir com qualquer notificação importante, como suspender ou continuar, porque esses eventos são do Tempo de Execução do Windows e, por motivos de segurança, os objetos do WinRT são inacessíveis no contexto da Web. No Consumer Preview, não é mais possível navegar pelo conteúdo que não aquele no contexto local. Em outras palavras, é preciso que venha do pacote do seu aplicativo e seja referenciado pelo esquema de protocolo ms-appx://.

Consequentemente, pode ser necessário reorganizar a lógica do aplicativo para contar com um iframe para carregar seu conteúdo Web, mantendo um único documento primário persistente do contexto local sempre na memória.

Modelo de páginas e carregamento de fragmento da WinJS

No Developer Preview, o modelo de navegação nos aplicativos estilo Metro em HTML/CSS/JS contam com APIs de carregamento de fragmento para realizar a navegação por diferentes páginas em um aplicativo. Este modelo era frágil e forçava você a escrever uma grande quantidade de códigos para lidar com coisas como inicialização de controle e estado de página.

No Consumer Preview, introduzimos um controle de página de alto nível na Biblioteca do Windows para JavaScript (WinJS) para carregar conteúdo em uma página. Além disso, atualizamos os modelos do Visual Studio para usar esses controles de página. Na maioria dos casos, os controles de página contornam a necessidade de lidar diretamente com as APIs de carregamento de fragmento. Isso torna a navegação pelos fragmentos em HTML muito mais fácil.

Os controles de página foram desenvolvidos sobre o carregador de fragmento. Eles fornecem um objeto real que reforça os fragmentos renderizados, proporcionam um local para armazenar estados e processam níveis superiores do fragmento para você. Há um controle da WinJS reforçando seu fragmento (anexado ao elemento DOM de nível superior) que o supre com um ciclo de vida bem definido. Você pode adicionar métodos ou estados arbitrários a este objeto de controle.

Finalização de aplicativos em exceções sem tratamento

O JavaScript é muito tolerante com exceções sem tratamento, continuando a executá-las muitas vezes sem ser notado, mas interrompendo a execução de qualquer outro código na função que contenha a exceção, caso contrário. Quando isso ocorre, seu aplicativo não está mais em um estado previsível. Isso significa que os dados dos quais seu aplicativo depende podem não ser válidos ou sua interface terminar em um estado ignorado. Em um navegador da Web, isso é aceitável porque o usuário pode atualizar a página. Mas em um aplicativo estilo Metro, o usuário deve poder executar seu aplicativo por semanas sem mesmo precisar fechar e reabri-lo.

Assim, uma exceção do JavaScript sem tratamento agora registra uma mensagem de erro para o log de eventos e finaliza o aplicativo.

Alterações importantes nos aplicativos estilo Metro em XAML

Se você desenvolveu aplicativos estilo Metro em XAML, perceberá algumas alterações no Consumer Preview específicas das linguagens de programação.

Suporte de vinculação de dados C++

No Consumer Preview, fizemos alterações significativas para os desenvolvedores de C++ simplificarem muito a interface em XAML de vinculação de dados para classes de C++ personalizadas. Ao usar anotações em sua classe através do atributo Windows.UI.Xaml.Data.Bindable, sua classe se torna visível para o mecanismo de vinculação e não é mais necessário implementar a interface nesta classe. Isso reduz significativamente a sobrecarga de códigos.

API de navegação

Se o seu aplicativo estilo metro em XAML usa APIs de navegação, tais como Windows.UI.Xaml.Controls.Frame.Navigate ou Windows.UI.Xaml.Navigation.NavigationEventArgs.Type, você precisará fazer algumas alterações rápidas. Essas APIs agora aceitam um objeto Type como destino, em vez de a representação do nome da cadeia de caracteres da classe. Consulte a //Compilação do Windows 8 Consumer Preview para obter a lista completa das APIs afetadas.

AppBar

Fizemos inúmeras alterações na funcionalidade Windows.UI.Xaml.Controls.ApplicationBar para torná-la mais consistente com a experiência do usuário em aplicativos estilo Metro. Essas alterações também tiram de você a sobrecarga de preocupação com detalhes de implementação para corresponder à experiência estilo Metro.

Uma alteração importante é que você pode inserir um AppBar no seu aplicativo usando as novas propriedades Windows.UI.Xaml.Controls.Page.TopAppBar e BottomAppBar. Recomendamos que você use essas novas propriedades em vez de inserir o AppBars diretamente no layout do aplicativo. Adicionamos, renomeamos ou removemos várias outras propriedades do AppBar.

Zoom semântico

Zoom semântico é o termo usado em toda a plataforma do Windows 8 quando o usuário pode ampliar ou reduzir o conteúdo e alterar seu contexto. Por exemplo, a ampliação de um conjunto de fotos poderá alterar as fotos, de miniaturas para grandes visualizações com nomes, datas etc. O controle JumpViewer permitiu o zoom semântico no Developer Preview. Ele foi renomeado como controle SemanticZoom. O novo nome reflete melhor a experiência do usuário que você fornece ao implementar um desses controles em seu aplicativo.

Para onde ir deste ponto em diante

Além das alterações citadas nesta postagem, muitas APIs no Tempo de Execução do Windows e na Biblioteca do Windows para JavaScript foram alteradas. Por exemplo, no Tempo de Execução do Windows, há alterações nos namespaces de Rede, Mídia, Sistema, Interface do Usuário, Armazenamento, Dispositivos, ApplicationModel, Globalização, Elemento Gráfico e Dados Embora muitas dessas alterações sejam secundárias, você deverá tomar cuidado ao migrar seu código para fazer todas as alterações necessárias no aplicativo. Esta postagem pretende ser um ponto de partida, mas abrange somente uma pequena amostra das alterações feitas para a plataforma de desenvolvimento. Sugeri ao longo da postagem a consulta à //Compilação do Windows 8 Consumer Preview no Centro de Desenvolvimento para obter informações detalhadas sobre como migrar seu aplicativo para o Consumer Preview.

Aguardo seus comentários. Se você tiver perguntas detalhadas do tipo "como faço para...", sugiro que envie uma postagem para os fóruns de desenvolvedor e nós o ajudaremos a encontrar uma solução.

-- John Sheehan, arquiteto parceiro, Equipe de Desenvolvimento do Windows

  • Loading...
Leave a Comment
  • Please add 4 and 7 and type the answer here:
  • Post