Windows Dev Center

Trabalhando com blocos em um aplicativo de negócios da Windows Store usando C#, XAML e Prism

De: Desenvolvendo um aplicativo de negócios da Windows Store com C#, XAML e Prism para o Tempo de Execução do Windows

Logotipo de padrões e práticas

Página anterior | Próxima página

Saiba como criar um bloco de aplicativo que é atualizado por notificações periódicas e como criar blocos secundários e links profundos para promover conteúdo específico de um aplicativo na tela Inicial. A implementação de referência do AdventureWorks Shopper demonstra isso, e como iniciar o aplicativo a partir de um bloco secundário usando o Prism para o Tempo de Execução do Windows.

Download

Baixe a amostra do AdventureWorks Shopper
Baixe a biblioteca StoreApps do Prism
Baixar o manual (PDF)

Depois de baixar o código, veja Introdução ao Prism para o Tempo de Execução do Windows para obter instruções sobre como compilar e executar a implementação de referência e também para compreender a estrutura da solução do Microsoft Visual Studio.

Você aprenderá

Aplica-se a

  • Tempo de Execução do Windows para Windows 8.1
  • C#
  • Linguagem XAML

Tomando decisões importantes

Um bloco é a representação de um aplicativo na tela Inicial e permite apresentar ao usuário conteúdo rico e envolvente quando o aplicativo não está sendo executado. Blocos devem ser atraentes para os usuários para lhes dar uma ótima impressão inicial do seu aplicativo da Windows Store. A lista a seguir resume as decisões a serem tomadas ao criar blocos para o seu aplicativo:

  • Por que devo investir em um bloco dinâmico?
  • Como tornar um bloco dinâmico atraente para os usuários?
  • Que forma deve ter o meu bloco?
  • Que tamanho deve ter a imagem do meu bloco?
  • Que modelos de bloco devo usar?
  • Qual mecanismo devo usar para distribuir notificações de bloco?
  • Quantas vezes o conteúdo do meu bloco dinâmico deve mudar?
  • Meu aplicativo deve incluir a capacidade de fixar blocos secundários na tela Inicial?

Blocos podem ser dinâmicos, o que significa que eles são atualizados através de notificações, ou estáticos. Para saber mais sobre blocos, incluindo por que você deve investir em um bloco dinâmico, como tornar um bloco dinâmico atraente para os usuários, que forma e tamanho um bloco deve ter, que modelos de bloco você deve usar, quantas vezes o conteúdo do bloco dinâmico deve mudar e blocos secundários, veja Diretrizes para blocos e selos, Tamanhos de imagens de blocos e notificações do sistema, O catálogo de modelos de blocos, Enviando notificações, e Visão geral de blocos secundários.

A escolha do mecanismo a ser usado para distribuir uma notificação de bloco depende do conteúdo que você quer mostrar e da frequência de atualização desse conteúdo. Notificações locais são uma boa maneira de manter o bloco do aplicativo atual, mesmo que você também utilize outros mecanismos de notificação. Muitos aplicativos vão usar notificações locais para atualizar o bloco quando o aplicativo for ativado ou quando o estado mudar dentro do aplicativo. Isso garante que o bloco seja atualizado quando o aplicativo for iniciado e encerrado. Notificações agendadas são ideais para as situações onde o conteúdo a ser atualizado já é conhecido, como o convite de uma reunião. Notificações periódicas fornecem atualizações de blocos com um mínimo de investimento em clientes e na Web ou na nuvem e são um excelente método de distribuir o mesmo conteúdo a um público amplo. Notificações por push são ideais para situações em que o seu aplicativo tem dados em tempo real ou dados personalizados para o seu usuário. Notificações por push também são úteis em situações em que os dados são sensíveis ao tempo e em que o conteúdo é gerado em momentos imprevisíveis. Notificações periódicas oferecem a solução de notificação mais adequada para aplicativos com side-loading, mas não fornecem notificações sob demanda. Além disso, com notificações periódicas, após a sondagem inicial no serviço Web ou da nuvem, o Windows continuará a sondar em busca de atualizações de blocos, mesmo que o seu aplicativo nunca seja ativado novamente. Para saber mais, veja Escolhendo um método de distribuição de notificações.

Observação  Notificações por push usam os Serviços de Notificação por Push do Windows (WNS) para distribuir atualizações para os usuários. Antes de enviar notificações usando o WNS, seu aplicativo deve ser registrado no Painel da Windows Store. Para saber mais, veja Visão geral de notificações por push.

[Início]

Blocos no AdventureWorks Shopper

A implementação de referência do AdventureWorks Shopper inclui blocos padrão médios e largos, que foram criados de acordo com os requisitos de pixel para cada um. É importante escolher um logotipo pequeno que represente seu aplicativo para que os usuários possam identificá-lo quando o bloco exibir o conteúdo personalizado. Para saber mais, veja Criando blocos de aplicativos.

Os blocos padrão se tornam dinâmicos quando são atualizados com notificações periódicas, em intervalos de 30 minutos, para fazer propaganda de produtos específicos para os usuários na tela Inicial. As notificações periódicas usam modelos de espiada para que o bloco dinâmico seja animado entre dois quadros. O primeiro quadro mostra uma imagem do produto anunciado, enquanto o segundo quadro mostra os detalhes do produto. Ambos os modelos de blocos de espiada largos e médios são usados. Embora o AdventureWorks Shopper assuma o bloco largo como padrão, ele pode ser modificado para médio pelo usuário. Para saber mais, veja Usando notificações periódicas para atualizar o conteúdo do bloco

O AdventureWorks Shopper inclui a capacidade de criar blocos secundários fixando produtos específicos na tela Inicial a partir de ItemDetailPage. O diagrama a seguir mostra os dois quadros de um bloco secundário criado a partir de um dos produtos vendidos no AdventureWorks Shopper.

Bloco secundário do AdventureWorks Shopper na tela Inicial

Selecionar um bloco secundário ativa o aplicativo e exibe o produto previamente fixado em ItemDetailPage. Para saber mais, veja Criando blocos secundários.

[Início]

Criando blocos de aplicativos

Os blocos começam como blocos padrão, definidos no manifesto do aplicativo. Um bloco estático sempre exibirá o conteúdo padrão, que geralmente é uma imagem de logotipo de bloco inteiro. Um bloco dinâmico pode atualizar o bloco padrão para mostrar conteúdo novo, mas pode voltar ao padrão se a notificação expirar ou for removida. Os diagramas a seguir mostram as imagens de logotipo padrão pequenas, médias e largas que podem ser encontradas na pasta Assets na solução AdventureWorks Shopper do Visual Studio. Cada logotipo tem um plano de fundo transparente. Isso é particularmente importante para o logotipo pequeno, que irá se misturar com o conteúdo da notificação do bloco.

Logotipo de bloco pequeno do AdventureWorks Shopper

30 x 30 pixels

Logotipo de bloco quadrado do AdventureWorks Shopper

150 x 150 pixels

Logotipo de bloco largo do AdventureWorks Shopper

310 x 150 pixels

Observação  Ativos de imagem, incluindo os logotipos, são espaços reservados e destinados apenas para treinamento. Eles não podem ser usados como uma marca comercial ou para outros fins comerciais.

O editor de manifesto do Visual Studio torna o processo de adicionar os blocos padrão fácil. Para saber mais, veja Guia de início rápido: criando um bloco padrão usando o editor de manifestos do Visual Studio. Para saber mais sobre como trabalhar com recursos de imagem, veja Guia de início rápido: usando recursos de arquivo ou imagem e Como nomear recursos usando qualificadores.

Se apenas um logotipo médio for fornecido no arquivo de manifesto do aplicativo, o bloco do aplicativo será sempre quadrado. Se um logotipo médio e um logotipo largo forem fornecidos no manifesto, o bloco do aplicativo terá um padrão de bloco largo quando for instalado. Você deve decidir se quer permitir um bloco largo também. Essa escolha é feita fornecendo uma imagem de logotipo larga ao definir seu bloco padrão no manifesto do aplicativo.

Usando notificações periódicas para atualizar o conteúdo do bloco

Notificações periódicas, que são chamadas algumas vezes de notificações de sondagem, atualizam blocos em um intervalo fixo, baixando o conteúdo diretamente da Web ou da nuvem. Para usar notificações periódicas, seu aplicativo deve especificar o URI de uma localização da Web que é sondada pelo Windows em busca de atualizações de blocos e deve definir quantas vezes esse URI deve ser sondado.

As notificações periódicas requerem que seu aplicativo hospede um serviço Web ou da nuvem. Qualquer endereço HTTP ou HTTPS válido pode ser usado como o URI a ser sondado pelo Windows. O exemplo de código a seguir mostra o método GetTileNotification na classe TileNotificationController do projeto AdventureWorks.WebServices, que é usado para enviar conteúdo de bloco para a implementação de referência do AdventureWorks Shopper.

AdventureWorks.WebServices\Controllers\TileNotificationController.cs


public HttpResponseMessage GetTileNotification()
{
    var tileXml = GetDefaultTileXml("http://localhost:2112/Images/hotrodbike_red_large.jpg",
                                    "Mountain-400-W Red, 42");
    tileXml = string.Format(CultureInfo.InvariantCulture, tileXml, DateTime.Now.ToShortDateString(), DateTime.Now.ToShortTimeString());

    // create HTTP response
   var response = new HttpResponseMessage();

    // format response
    response.StatusCode = System.Net.HttpStatusCode.OK;
    response.Content = new StringContent(tileXml);

    //Need to return xml format to TileUpdater.StartPeriodicUpdate
    response.Content.Headers.ContentType = 
        new System.Net.Http.Headers.MediaTypeHeaderValue("text/xml");
    return response;
} 


Esse método gera o conteúdo do bloco XML, formata esse coteúdo e o retorna como uma resposta HTTP. O conteúdo do bloco deve obedecer ao Esquema de blocos e ser codificado em UTF-8. O conteúdo do bloco é especificado usando os modelos TileWidePeekImage01 e TileSquarePeekImageAndText02. Isso é necessário porque, embora o aplicativo use o bloco largo por padrão, ele pode ser alterado para o bloco quadrado pelo usuário. Para saber mais, veja O catálogo de modelos de bloco.

Em um intervalo de sondagem de 30 minutos, o Windows envia uma solicitação HTTP GET para o URI, baixa o conteúdo do bloco solicitado como XML e exibe o conteúdo no bloco do aplicativo. Isso é feito pelo método OnInitialize na classe App, como mostra o seguinte exemplo de código.

AdventureWorks.Shopper\App.xaml.cs


_tileUpdater = TileUpdateManager.CreateTileUpdaterForApplication();
_tileUpdater.StartPeriodicUpdate(new Uri(Constants.ServerAddress + "/api/TileNotification"), PeriodicUpdateRecurrence.HalfHour);


A nova instância de TileUpdater é criada pelo método CreateTileUpdaterForApplication na classe TileUpdateManager a fim de atualizar o bloco do aplicativo. Por padrão, um bloco na tela inicial mostra o conteúdo de uma única notificação até que ela seja substituída por uma nova. No entanto, você pode habilitar o ciclo de notificações para que até cinco notificações sejam mantidas em uma fila e para que o bloco as percorra. Isso é feito chamando o método EnableNotificationQueue com um parâmetro true na instância TileUpdater. Por fim, é feita uma chamada a StartPeriodicUpdate para sondar o URI especificado a fim de atualizar o bloco com o conteúdo recebido. Após essa pesquisa inicial, o Windows continuará a fornecer atualizações a cada 30 minutos, conforme especificado. A sondagem continuará até você interrompê-la explicitamente ou seu aplicativo ser desinstalado. Caso contrário, o Windows continuará a sondar atualizações no seu bloco mesmo que o aplicativo não seja mais ativado.

Observação  Embora o Windows se esforce para sondar conforme solicitado, o intervalo não é preciso. O intervalo de sondagem solicitado pode ser atrasado em até 15 minutos.

Por padrão, as notificações periódicas de bloco expiram três dias depois que são baixadas. Portanto, é recomendável que você definir uma expiração em todas as notificações de bloco periódicas, usando um tempo que faz sentido para o seu aplicativo, para garantir que o conteúdo do bloco não persista por mais do que o período relevante. Isso também garante a remoção de conteúdo obsoleto se seu serviço Web ou de nuvem se tornar inacessível ou se o usuário se desconectar da rede por um período de tempo prolongado. Isso é feito por meio do retorno do cabeçalho HTTP X-WNS-Expires para especificar a data e a hora de expiração.

Para saber mais, veja Visão geral de notificações periódicas, Usando a fila de notificações e Diretrizes para notificações periódicas.

[Início]

Criando blocos secundários

Um bloco secundário permite que um usuário ative em um local específico de um aplicativo diretamente a partir da tela Inicial. Aplicativos não podem fixar blocos secundários programaticamente sem a aprovação do usuário. Os usuários também têm controle explícito sobre a remoção de blocos secundários. Isso permite que os usuários personalizem sua tela Inicial com as experiências que eles mais utilizam.

Blocos secundários são independentes do bloco de aplicativo principal e podem receber notificações de bloco independentemente. Quando um bloco secundário é ativado, um contexto de ativação é apresentado ao aplicativo pai para que ele possa ser iniciado no contexto do bloco secundário.

A opção para criar um bloco secundário é vista na barra de aplicativos inferior de ItemDetailPage como o botão da barra de aplicativos Fixar na Tela Inicial. Isso permite criar um bloco secundário para o produto que está sendo exibido. Selecionar o bloco secundário ativa o aplicativo e exibe o produto previamente fixado em ItemDetailPage. O diagrama a seguir mostra um exemplo de submenu que é exibido quando você seleciona o botão Fixar na Tela Inicial. O submenu mostra uma visualização do bloco secundário e solicita que você confirme sua criação.

Submenu de bloco secundário do AdventureWorks Shopper

A funcionalidade de fixar e desafixar blocos secundários é fornecida pela classe SecondaryTileService, que implementa a interface ISecondaryTileService. No método OnInitialize da classe App, a classe SecondaryTileService é registrada como um mapeamento de tipo com base no tipo ISecondaryTileService com o contêiner de injeção de dependência Unity. Em seguida, quando a classe ItemDetailPageViewModel é instanciada, que aceita um tipo ISecondaryTileService, o contêiner Unity resolverá o tipo e retornará uma instância da classe SecondaryTileService.

O fluxo de trabalho usado pelo AdventureWorks Shopper para fixar um bloco secundário na tela Inicial é o seguinte:

  1. Você invoca PinProductCommand através do botão da barra de aplicativos Fixar na Tela Inicial em ItemDetailPage.

    AdventureWorks.UILogic\ViewModels\ItemDetailPageViewModel.cs

    
    PinProductCommand = DelegateCommand.FromAsyncHandler(PinProduct, () => SelectedProduct != null);
    
    
    
  2. O AdventureWorks Shopper verifica se o bloco ainda não foi fixado, chamando o predicado SecondaryTileExists na instância SecondaryTileService.

    AdventureWorks.UILogic\ViewModels\ItemDetailPageViewModel.cs

    
    bool isPinned = _secondaryTileService.SecondaryTileExists(tileId);
    
    
    
  3. O AdventureWorks Shopper chama o método PinWideSecondaryTile na instância SecondaryTileService para criar um bloco secundário. A propriedade SelectedProduct.ProductNumber é utilizada como uma ID única.

    AdventureWorks.UILogic\ViewModels\ItemDetailPageViewModel.cs

    
    isPinned = await _secondaryTileService.PinWideSecondaryTile(tileId, SelectedProduct.Title, SelectedProduct.ProductNumber);
    
    
    

    O método PinWideSecondaryTile cria uma nova instância da classe SecondaryTile, fornecendo informações como o nome curto, o nome de exibição e o logotipo, entre outras.

    AdventureWorks.UILogic\Services\SecondaryTileService.cs

    
    var secondaryTile = new SecondaryTile(tileId, displayName, arguments, _squareLogoUri, TileSize.Wide310x150);
    secondaryTile.VisualElements.ShowNameOnWide310x150Logo = true;
    secondaryTile.VisualElements.Wide310x150Logo = _wideLogoUri;
    
    
    
  4. O método RequestCreateAsync é chamado na instância SecondaryTile para exibir um submenu que mostra uma visualização do bloco, solicitando que você confirme sua criação.

    AdventureWorks.UILogic\Services\SecondaryTileService.cs

    
    bool isPinned = await secondaryTile.RequestCreateAsync();
    
    
    
  5. Após a confirmação, o bloco secundário é adicionado à tela Inicial.

O fluxo de trabalho usado pelo AdventureWorks Shopper para desfixar um bloco secundário da tela Inicial é o seguinte:

  1. O AdventureWorks Shopper invoca UnpinProductCommand através do botão da barra de aplicativos Desafixar da Tela Inicial em ItemDetailPage.

    AdventureWorks.UILogic\ViewModels\ItemDetailPageViewModel.cs

    
    UnpinProductCommand = DelegateCommand.FromAsyncHandler(UnpinProduct, () => SelectedProduct != null);
    
    
    
  2. O AdventureWorks Shopper verifica se o bloco ainda não foi desafixado, chamando o predicado SecondaryTileExists na instância SecondaryTileService.

    AdventureWorks.UILogic\ViewModels\ItemDetailPageViewModel.cs

    
    bool isPinned = _secondaryTileService.SecondaryTileExists(tileId);
    
    
    
  3. O AdventureWorks Shopper chama o método UnpinTile na instância SecondaryTileService para remover o bloco secundário. O bloco pode ser identificado pela propriedade SelectedProduct.ProductNumber como o ID exclusivo.

    AdventureWorks.UILogic\ViewModels\ItemDetailPageViewModel.cs

    
    isPinned = (await _secondaryTileService.UnpinTile(tileId)) == false;
    
    
    

    O método UnpinTile cria uma nova instância da classe SecondaryTile usando a propriedade SelectedProduct.ProductNumber como a ID exclusiva. Ao fornecer uma ID para um bloco secundário existente, esse bloco secundário existente é substituído.

    AdventureWorks.UILogic\Services\SecondaryTileService.cs

    
    var secondaryTile = new SecondaryTile(tileId);
    
    
    
  4. O método RequestDeleteAsync é chamado na instância SecondaryTile para exibir um submenu que mostra uma visualização do bloco a ser removido e solicitando que você confirme sua remoção.

    AdventureWorks.UILogic\Services\SecondaryTileService.cs

    
    bool isUnpinned = await secondaryTile.RequestDeleteAsync();
    
    
    
  5. Após a confirmação, o bloco secundário é removido da tela Inicial.
Observação  Blocos secundários também podem ser removidos através da barra de aplicativos de tela Inicial. Quando isso ocorre, o aplicativo não é contatado para informações de remoção, a confirmação do usuário não é solicitada, e o aplicativo não é notificado de que o bloco não está mais presente. Qualquer ação de limpeza adicional que o aplicativo executaria ao desafixar o bloco deve ser realizada na sua próxima ativação.

Para saber mais, veja Visão geral de blocos secundários e Diretrizes de blocos secundários.

Ativando o aplicativo a partir de um bloco secundário

Sempre que o aplicativo é ativado, o método OnLaunched na classe MvvmAppBase é chamado (a classe MvvmAppBase é fornecida pela biblioteca Microsoft.Practices.Prism.StoreApps). O parâmetro LaunchActivatedEventArgs no método OnLaunched conterá o estado anterior do aplicativo e os argumentos de ativação. Se o aplicativo for iniciado com seu bloco principal, a propriedade TileId do parâmetro LaunchActivatedEventArgs terá o mesmo valor que a ID do aplicativo no manifesto do pacote. Se o aplicativo for lançado por um bloco secundário, a propriedade TileId terá uma ID que foi especificada quando o bloco secundário foi criado. O método OnLaunched na classe MvvmAppBase irá chamar o método OnLaunchApplication na classe App somente se o aplicativo não estiver retomando após suspensão ou se ele tiver sido ativado por meio de um bloco secundário. O método OnLaunchApplication, mostrado no exemplo de código a seguir, fornece um comportamento de ativação específico do aplicativo.

AdventureWorks.Shopper\App.xaml.cs


protected override Task OnLaunchApplication(LaunchActivatedEventArgs args)
{
    if (args != null && !string.IsNullOrEmpty(args.Arguments))
    {
        // The app was launched from a Secondary Tile
        // Navigate to the item's page
        NavigationService.Navigate("ItemDetail", args.Arguments);
    }
    else
    {
        // Navigate to the initial page
        NavigationService.Navigate("Hub", null);
    }

    Window.Current.Activate();
    return Task.FromResult<object>(null);
}


Nesse método, o parâmetro LaunchActivatedEventArgs contém o estado anterior de seu aplicativo e os argumentos de ativação. Se o aplicativo estiver sendo ativado a partir do bloco de aplicativo, a propriedade Arguments de ativação não irá conter dados e, portanto, a navegação será feita para HubPage. Se o aplicativo estiver sendo ativado a partir de um bloco secundário, a propriedade Arguments de ativação conterá o número do produto a ser exibido. A navegação ocorrerá para ItemDetailPage, com o número do produto sendo transmitido à substituição OnNavigatedTo na instância de ItemDetailPageViewModel, de modo que o produto especificado seja exibido.

[Início]

 

 

Mostrar:
© 2015 Microsoft