Como definir opções de conectividade em tela de fundo (HTML)

Artigo
12/12/2015

[ Este artigo destina-se aos desenvolvedores do Windows 8.x e do Windows Phone 8.x que escrevem aplicativos do Windows Runtime. Se você estiver desenvolvendo para o Windows 10, consulte documentação mais recente]

Este tópico explica os recursos de conectividade de rede em segundo plano disponíveis para um aplicativo do Tempo de Execução do Windows escrito em JavaScript e HTML e mostra como configurar opções de conectividade em segundo plano.

O que você precisa saber

Tecnologias

IXMLHTTPRequest2

Habilita o acesso aos recursos Web usando uma extensão para o objeto XMLHttpRequest.
System.Net.Http

Ativa a conexão a serviços da Web com um cliente Web moderno.

Pré-requisitos

As informações a seguir se aplicam a qualquer aplicativo do Tempo de Execução do Windows com suporte a rede ou conectado dependente de conexões de rede para estar sempre ativas. Este tópico se aplica a aplicativos escritos em JavaScript e HTML para Windows 8.1, Windows Phone 8.1 e Windows Server 2012 R2. Para obter saber mais sobre tarefas em segundo plano para aplicativos em JavaScript, veja Dando suporte ao seu aplicativo com tarefas em segundo plano.

Para saber mais sobre aplicativos da Windows Store conectados ou com reconhecimento de rede escritos em C++/XAML e sobre aplicativos que usam o .NET Framework 4.5 em C#, VB.NET ou C++ gerenciados no Windows 8.1 e no Windows Server 2012, consulte Como permanecer conectado em segundo plano.

Modelo de ciclo de vida para aplicativos da Windows Store

O Windows 8 e posterior introduz um novo modelo de ciclo de vida para aplicativos do Tempo de Execução do Windows, diferente do modelo usado para aplicativos de área de trabalho no Windows 8 e aplicativos de versões anteriores do Windows. Por padrão, a operação de um aplicativo do Tempo de Execução do Windows é totalmente suspensa quando ele vai para segundo plano. Há algumas exceções para a suspensão de aplicativos (impressão ativa, acesso a um fluxo de áudio e transferência de arquivos em segundo plano usando Windows.Networking.BackgroundTransfer, por exemplo). Para algumas dessas exceções (Windows.Networking.BackgroundTransfer, por exemplo), o aplicativo ainda pode ser suspenso, mas o Windows continua a transferência de rede em um processo separado.

Esse novo modelo para aplicativos do Tempo de Execução do Windows melhora a resposta do aplicativo em execução em segundo plano e reduz o uso de recursos do sistema. Essa redução aumenta o tempo de operação de um sistema a bateria antes de ser recarregado. Além disso, esse novo modelo fornece um mecanismo para que os aplicativos que devem trabalhar em segundo plano (como protocolo VoIP, mensagens instantâneas e e-mail) proporcionem uma experiência de conexão sem interrupções ao usuário final. Ou seja, um aplicativo que depende de uma conexão de rede de longa duração com servidor remoto pode continuar funcionando quando o aplicativo é suspenso. Manter o dispositivo sempre conectado para aplicativos em tempo real e tentar reduzir o consumo de recursos, aumentando a resposta do aplicativo, são demandas que competem entre si.

Para possibilitar cenários de rede em tempo real para um aplicativo do Tempo de Execução do Windows em JavaScript que precisa estar sempre conectado, é possível usar vários recursos inéditos no Windows 8:

Tarefas em segundo plano
Gatilho do sistema para SessionConnected
Gatilhos de tempo
Serviços de Notificação por Push do Windows (WNS)
Notificações por push não processadas

Esses recursos dão suporte para aplicativos sempre conectados que precisam receber notificações por push não processadas quando um aplicativo do Tempo de Execução do Windows é suspenso. Esses aplicativos também são descritos como acessíveis o tempo todo. O foco deste tópico é como um desenvolvedor pode usar o WNS e notificações por push não processadas para criar um aplicativo sempre conectado em tempo real. Esses recursos exigem que o aplicativo também seja um aplicativo de tela de bloqueio.

Outros recursos de tarefas em tela de fundo também podem ser usados por um aplicativo de rede. Há alguns outros gatilhos disponíveis que podem ser usados por um aplicativo do Tempo de Execução do Windows, entre eles:

Gatilhos de manutenção (eventos periódicos de manutenção)
Gatilhos do sistema para usuários e sessões (sessão do usuário conectada/desconectada, usuário presente/ausente e alteração de ID online)
Gatilhos do sistema para status de rede (alteração no estado da rede, Internet disponível/indisponível)
Gatilhos do sistema para tela de bloqueio (adicionar/remover aplicativo)

Um gatilho de tempo pode ser usado quando um aplicativo não necessita de conectividade em tempo real, mas precisa ser executado por um breve tempo dentro de um intervalo. Um gatilho do sistema pode ser usado quando o aplicativo precisa reconhecer eventos (por exemplo, a disponibilidade da conectividade com a Internet ou presença de usuário). Vários gatilhos podem ser combinados em um aplicativo para possibilitar diversos cenários. Para saber mais, veja Dando suporte ao seu aplicativo com tarefas em segundo plano.

A maioria dos aplicativos do Tempo de Execução do Windows não precisará usar as notificações por push não processadas detalhadas neste tópico. Um aplicativo pode dar ao usuário a impressão de que está sempre em execução em segundo plano usando um bloco dinâmico ou um bloco dinâmico com notificações por push não processadas (diferentes das notificações por push não processadas) do WNS. Seu aplicativo não precisa ser um aplicativo da tela de bloqueio (descrito mais adiante neste tópico) ou ser executado em segundo plano para usar um bloco. No entanto, ele deve estar na tela de bloqueio para usar um bloco dinâmico com notificações por push não processadas.

Requisitos para estar sempre conectado

Normalmente, dois elementos são exigidos para que um aplicativo esteja sempre conectado e acessível:

Um processo de longa duração para garantir que todas as notificações de rede de entrada sejam recebidas e possam ser processadas rapidamente pelo aplicativo.
Uma conexão de rede de longa duração com um ponto de extremidade remoto que possa receber e enviar dados conforme necessário.

Nas versões anteriores do Windows, os aplicativos continuam em execução quando perdem o foco (em tela de fundo). Quando estão em segundo plano, esses aplicativos podem manter conexões de longa duração que enviam e recebem dados e mensagens keep alive. Permitir que os aplicativos sejam executados em tela de fundo consome recursos que podem afetar a capacidade de resposta de outros aplicativo e a duração da bateria.

Aplicativos do Tempo de Execução do Windows e a tela de bloqueio

O Windows 8 apresenta um novo modelo de Software que suspende os aplicativos do Tempo de Execução do Windows quando vão para segundo plano. Quando um aplicativo é suspenso, todos os pacotes recebidos pelo sistema podem não ser entregues imediatamente ao aplicativo e os pacotes de rede de entrada podem ser descartados. Nenhum pacote novo é enviado quando o aplicativo está suspenso. Como resultado dessas condições, as conexões de rede existentes podem ser fechadas.

Para estar sempre conectado, um aplicativo deve ser um aplicativo da tela de bloqueio. Um aplicativo da tela de bloqueio é um tipo especial de aplicativo que pode exibir notificações na tela de bloqueio e executar códigos em segundo plano quando ele não está em primeiro plano. Somente aplicativos que usam uma ou mais tarefas em segundo plano podem ser aplicativos da tela de bloqueio.

Os aplicativos da tela de bloqueio têm algumas habilidades especiais:

Podem receber uma notificação por push bruta do WNS capaz de executar códigos quando a notificação é recebida.
Podem executar códigos quando um gatilho de tempo é disparado.
Podem executar códigos quando uma sessão de usuário é iniciada.

Os aplicativos fixos na tela de bloqueio podem apresentar informações ao usuário quando estão em segundo plano meio da atualização e exibição de um ícone de notificação na tela de bloqueio quando há novas informações. Esses aplicativos também podem exibir uma notificação na tela quando chega uma mensagem. Se a notificação é tocada ou clicada, o sistema solicita que o usuário desbloqueie o dispositivo. Quando o dispositivo é desbloqueado, o aplicativo que corresponde à notificação é iniciado com informações contextuais.

Os aplicativos da tela de bloqueio têm algumas limitações significativas. Um usuário pode ter no máximo sete aplicativos da tela de bloqueio a qualquer momento. Um usuário pode adicionar ou remover um aplicativo da tela de bloqueio a qualquer momento.

Os aplicativos da tela de bloqueio são ótimos para fornecer informações aos usuários relacionadas a coisas que podem ter perdido quando não estavam usando o dispositivo. Eles também são perfeitos para fornecer notificações na tela relativas a eventos que necessitam de ação imediata do usuário, como uma chamada telefônica recebida, novas mensagens instantâneas ou e-mails urgentes.

A maioria dos aplicativos não precisa ser da tela de bloqueio. Quando um aplicativo é suspenso em segundo plano, ele pode usar notificações por push (além das não processadas) do WNS para atualizar um bloco e dar aos usuários a impressão de que o aplicativo está em execução, em tempo real e com conteúdo atualizado. Os aplicativos também podem usar o WNS para emitir uma notificação do sistema ao usuário a qualquer momento ou atualizar a contagem de notificações no bloco do aplicativo.

Como há um número limitado de espaços para aplicativos da tela de bloqueio, você deve pensar em criar seu aplicativo de modo que funcione mesmo sem permissões de aplicativo de tela de bloqueio. O usuário deve permitir explicitamente a adição de um aplicativo à tela de bloqueio. Seu aplicativo deve sempre funcionar quando está visível em primeiro plano. O fato de ser um aplicativo da tela de bloqueio simplesmente faz com que ele possibilite alguns dos mesmos cenários quando está em tela de fundo.

Há um recurso que permite a um aplicativo escrito em JavaScript e HTML receber pacotes de rede de entrada quando ele está em segundo plano

Notificações por push não processadas que são recebidas pelo sistema e resultam na execução de uma tarefa em segundo plano no aplicativo. Usando esse recurso, o aplicativo recebe os dados não processados no WNS (Serviço de Notificação por Push do Windows). O conteúdo desses dados devem ser compreendidos pelo aplicativo. O aplicativo deve se registrar no WNS para receber a notificação por push não processada.

Vários dos mecanismos abordados a seguir podem ser usados para possibilitar cenários em tempo real para aplicativos colocados na tela de bloqueio. Cada um tem vantagens e desvantagens. Os mecanismos não são mutuamente exclusivos e podem ser combinados em alguns aplicativos.

Usando WNS em aplicativos da Windows Store

O WNS é um serviço em nuvem hospedado pela Microsoft para Windows 8. Ele pode ser usado por aplicativos do Tempo de Execução do Windows para receber notificações que podem executar códigos, atualizar um bloco ou emitir uma notificação na tela. Para usar WNS, o computador local deve estar conectado à Internet, de modo que o serviço WNS possa se comunicar com ele. Para saber mais, veja a visão geral de notificações por push.

Um aplicativo do Tempo de Execução do Windows em primeiro plano pode usar WNS para atualizar blocos, emitir notificações ao usuário ou atualizar notificações. Os aplicativos não precisam estar na tela de bloqueio para usar o WNS. Leve o uso do WNS em consideração em seu aplicativo se ele precisar executar códigos em resposta a uma notificação por push.

Para aplicativos que não precisam estar na tela de bloqueio (a maioria), o WNS pode ser usado para fornecer uma atualização de blocos.

Se você fixar seu aplicativo do Tempo de Execução do Windows à tela de bloqueio e usar o WNS em segundo plano, o aplicativo poderá receber notificações por push não processadas do WNS em tempo real e mostrá-las na tela de bloqueio como uma notificação ou atualização de notificação. Quando uma notificação por push bruta é enviada a um aplicativo da tela de bloqueio, o aplicativo pode executar códigos em resposta à notificação. O uso do WNS pode ser bem mais eficiente do que o uso de gatilhos de rede disponíveis para aplicativos da Windows Store escritos em C++/XAML e para aplicativos que usam o .NET Framework 4.5 em C#, VB.NET ou C++ gerenciado no Windows 8.1 e no Windows Server 2012 R2.

O WNS oferece vários benefícios:

O WNS oferece o mecanismo com maior economia de recursos para enviar notificações em tempo real a aplicativos da tela de bloqueio.
O WNS simplifica o modelo de desenvolvedor de seu aplicativo. Na maioria dos cenários, os desenvolvedores não precisam criar tarefas em segundo plano, pois o sistema operacional renderiza os blocos ou notificações do sistema. Em um pequeno subconjunto de cenários, se o seu aplicativo precisar executar uma tarefa em segundo plano, ele deverá somente registrar o gatilho não processado e a própria tarefa em segundo plano.
Nenhum conexão de soquete persistente precisa ser mantida entre o aplicativo cliente e um servidor remoto, pois o Windows mantém a conexão com o WNS. Como resultado, a sobrecarga de enviar mensagens keep-alive não é necessária.
Uma única conexão do WNS entre o cliente e o serviço em nuvem pode oferecer suporte a todos os aplicativos no computador local, o que resulta em eficiência relacionada ao potencial de duração da bateria para o cliente.
O custo operacional pode ser reduzido para o serviço no servidor porque não há necessidade de manter muitas conexões de soquete TCP estacionadas entre o cliente e o serviço remoto.
Seu aplicativo não precisa ficar armazenado na memória em todos os momentos, pois, mesmo que ele seja encerrado, o WNS poderá continuar atualizando o bloco, emitindo notificações do sistema ou disparando a execução de uma tarefa em segundo plano ao receber uma notificação não processada.
Tarefas em plano de fundo que usam notificações por push não processadas podem ser escritas em C++/XAML e usando o .NET Framework 4.5 em C#, VB.NET ou C++ gerenciado no Windows 8.1 e no Windows Server 2012 R2.

O recurso de gatilho de rede usando ControlChannelTrigger não está disponível em JavaScript.

Observação ControlChannelTrigger não é compatível com o Windows Phone

Conexões de rede em segundo plano que usam gatilhos de rede só podem ser escritas em C++/XAML e usando o .NET Framework 4.5 em C#, VB.NET ou C++ gerenciado no Windows 8 e no Windows Server 2012. Para saber mais, veja Como permanecer conectado em segundo plano.

O WNS também tem algumas limitações que podem afetar alguns aplicativos. O WNS não está disponível para um computador local conectado a uma rede corporativa ou doméstica privada que bloqueie acesso público à Internet. O WNS também pode ser bloqueado por alguns firewalls de rede, mesmo quando o acesso à Internet está disponível. Há outras desvantagens do uso do WNS que devem ser levadas em consideração. Especificamente, as notificações são enviadas com base no melhor esforço, não havendo garantia do recebimento. O tamanho máximo da carga em uma notificação por push não processada é de 5 kilobytes.

Pelas vantagens, recomendamos que os desenvolvedores que criam aplicativos de VoIP, mensagens instantâneas ou e-mail considerem o uso de notificações WNS para aplicativos da tela de bloqueio, mas pensem em alternativas se elas não atenderem aos requisitos.

Não será necessário criar um aplicativo da tela de bloqueio se você quiser simplesmente realizar uma atualização de blocos ou emitir uma notificação do sistema usando WNS. Um aplicativo da tela de bloqueio é necessário com o uso do WNS somente quando o aplicativo exige uma notificação por push bruta para disparar a execução de uma tarefa em tela de fundo.

Usando gatilhos de tempo ou de evento do sistema em aplicativos do Tempo de Execução do Windows

Os aplicativos da tela de bloqueio podem ser configurados para executar códigos periodicamente usando um gatilho de tempo com um intervalo mínimo de 15 minutos. Um exemplo é a necessidade de sondar novas mensagens de e-mail, possivelmente quando o aplicativo está conectado a um servidor de e-mail POP3 ou IMAP.

Aplicativos de tela de bloqueio também podem usar um gatilho de evento do sistema para executar códigos quando o usuário faz logon no computador local (gatilho de sistema para início de sessão). Um exemplo é fazer logon do usuário em um serviço de mensagens instantâneas quando ele inicia uma sessão de usuário, de modo que as mensagens possam ser recebidas.

Neste tópico, nos concentramos na criação de aplicativos da tela de bloqueio usando notificações por push não processadas com WNS ou o recurso de gatilho de rede. Para saber mais sobre como usar um temporizador, veja Como executar uma tarefa em segundo plano em um temporizador. Para saber mais sobre tarefas em segundo plano, veja Dando suporte ao seu aplicativo com tarefas em segundo plano.

Tarefa em segundo plano e área restrita

A duração da tarefa em segundo plano é determinada pela função que a implementa. Para garantir que as tarefas em segundo plano não afetem negativamente a vida útil da bateria, o Windows aplica um limite em termos de recursos de CPU e de E/S da rede, que um aplicativo pode usar durante as tarefas em segundo plano. Cada aplicativo obtém uma cota desses recursos periodicamente, e esgotar essa cota suspende a tarefa em segundo plano do aplicativo. Um aplicativo deve ser flexível à suspensão devido à área restrita.

Para saber mais, veja Dando suporte ao seu aplicativo com tarefas em segundo plano.

Etapas adicionais

Para saber mais sobre como criar um aplicativo de tela de bloqueio de forma a receber notificações de rede em segundo plano que usam notificações brutas por push, veja Como criar um aplicativo de tela de bloqueio que usa notificações brutas por push em segundo plano.

Para saber mais sobre o processo de registrar um canal de notificações por push e enviá-lo ao servidor, registrar uma tarefa em segundo plano para ativar uma notificação por push não processada e enviar uma notificação por push não processada ao canal e ativar essa tarefa em segundo plano, veja Como usar o WNS para entregar notificações por push não processadas a um aplicativo de tela de bloqueio.

Para saber mais sobre como escrever uma tarefa em segundo plano de forma a receber notificações de rede em segundo plano que usam notificações por push não processadas, veja Como escrever uma tarefa em segundo plano para notificações por push não processadas.

Para saber mais sobre as orientações e listas de verificação para o uso de notificações por push não processadas, veja Diretrizes e lista de verificação para notificações não processadas.