Aplicativos Modernos

O Ciclo de Vida dos Aplicativos da Windows Store

Rachel Appel

 

O Windows 8 está mudando como e quando executar aplicativos, e você vai querer entender as nuances do novo ciclo de vida do aplicativo para poder criar aplicativos que respondam como devem em cada ponto. Aplicativos que estão em conformidade com as diretrizes de gerenciamento de ciclo de vida da Microsoft oferecem uma experiência melhor para o usuário, especialmente em dispositivos pequenos, onde a conservação de memória e bateria é garantida.

Design do aplicativo

Dois conceitos de projeto chave são subjacentes aos aplicativos da Windows Store: os aplicativos podem executar em tela cheia, no modo fixo ou preenchido; e os aplicativos devem ser altamente sensíveis para que o usuário possa se concentrar no conteúdo em mãos com menos distrações. Esses dois princípios garantem que o aplicativo atualmente em execução obtenha todos os recursos disponíveis do sistema operacional e do usuário, diferente de aplicativos de desktop do Windows 8 ou aplicativos em versões anteriores do Windows, que precisavam compartilhar esses recursos. 

Todos os aplicativos da Windows Store têm quatro estados: não em execução, em execução, suspenso e encerrado. Quando você inicia um aplicativo, ele é executado. Mais tarde, dependendo da atividade do usuário ou do sistema, o aplicativo pode fazer a transição entre os estados de em execução e suspenso. Por exemplo, se o usuário mudar do aplicativo A para o aplicativo B, o Windows suspenderá o aplicativo A após um breve atraso, movendo-o para o segundo plano. O aplicativo A permanecerá suspenso (até que o usuário retorne a ele ou o Windows o encerre), enquanto o aplicativo B é ativado e muda para o estado de execução (possivelmente a partir de um estado suspenso, se já estiver na memória). Se o usuário retornar ao aplicativo A, o Windows simplesmente o reativará e, até onde o sistema operacional e o aplicativo saibam, ele esteve sempre em execução. Então, naturalmente, é a vez do aplicativo B ser suspenso.

Quando um aplicativo está em estado suspenso, seu código não é executado e o aplicativo permanece na memória, como está. Essencialmente, o aplicativo é armazenado em cache e imediatamente pronto para uso quando o usuário retornar. No entanto, essa não é toda a história — você pode executar tarefas em segundo plano se seguir os procedimentos adequados, e o Windows pode encerrar os aplicativos se a pressão da memória garantir. A Figura 1 ilustra como os aplicativos mudam de estado de execução (consulte bit.ly/TuXN9F para obter mais informações).

Figura 1 Como os aplicativos da Windows Store mudam de estado de execução

Conforme a Figura 1, um aplicativo pode alternar entre os estados de em execução e suspenso frequentemente. As transições de estado do ciclo de vida do aplicativo destacam a diferença entre os aplicativos da Windows Store e os aplicativos de desktop tradicionais.

O Visual Studio 2012 inclui um rico conjunto de ferramentas de depuração, bem como um simulador do Windows (bit.ly/QzBy5I), que você pode usar para gerenciar operações de ciclo de vida do aplicativo. Isso é importante, porque você precisa reagir de forma adequada aos eventos de ciclo de vida do aplicativo e lidar com as transições de estado corretamente a fim de criar uma experiência altamente sensível para o usuário final — um princípio básico do design de aplicativo no Windows 8. Responder apropriadamente aos eventos de ciclo de vida do aplicativo garante que os usuários tenham uma experiência consistente ao longo do ciclo de vida do aplicativo. Especificamente, isso significa salvar e restaurar o estado do seu aplicativo sempre que necessário. Isso pode implicar o retorno do usuário para onde ela estava no aplicativo (como em um assistente) ou preencher novamente os valores de um formulário em que ele estava trabalhando, ou retornar para o último artigo que ele estava lendo. Como o ciclo de vida do aplicativo é controlado pelo movimento do usuário no aplicativo, o aplicativo precisa estar preparado para verificação de seu estado em qualquer momento — sempre que o aplicativo receber o evento de suspensão.

Ativação do aplicativo

O processo WWAHost.exe é um host de aplicativo que executa aplicativos JavaScript da Windows Store. Aplicativos XAML escritos em qualquer linguagem — como C#, Visual Basic ou C++ — acionam o executável correspondente do aplicativo. De qualquer forma, todos os aplicativos passam pela ativação, que tem uma série de catalisadores:

  • O usuário inicia um aplicativo a partir de um bloco.
  • O usuário alterna para uma aplicativo suspenso.
  • O Windows inicia o aplicativo através de um contrato do Windows Search ou de Compartilhamento de Destino.
  • O Windows chama uma associação de protocolo (esquema URI) (bit.ly/QyzX04) ou inicia um aplicativo devido a uma associação de arquivo.
  • O Windows chama uma extensão, como um contrato do Seletor de Abertura de Arquivos ou Seleção de Contatos.

Como ocorre a ativação determina o código que precisa ser executado. Inicializações de um bloco, contrato ou protocolo fazem com que um aplicativo do Windows Library for JavaScript (WinJS) lance um evento ativado e que um aplicativo XAML gere um evento OnLaunched. Durante esses eventos, você verifica o estado anterior do aplicativo para executar as ações apropriadas. 

Se o aplicativo mudar de um estado de não-execução para um estado de execução, você precisará carregar dados atualizados, pois essa transição indica que o aplicativo foi iniciado a partir de um bloco, botão, protocolo ou extensão. Se o aplicativo estiver retornando de um estado suspenso, você geralmente não precisa fazer nada; o usuário pode escolher apenas onde parou. Se o aplicativo passar do estado de encerrado para o estado de execução, você deverá recarregar os dados e navegar no aplicativo até o último lugar em que o usuário esteve (a menos que tenham se passado meses desde a última utilização). Código para manipular a ativação mostrado em JavaScript na Figura 2 e em C# na Figura 3. Como mostra o código, você pode testar o estado de execução anterior, e como o Windows iniciou o aplicativo, pois a API do Windows tem um conjunto útil de enumerações para ambos os casos. Quando você tiver essa informação, poderá repreencher os dados conforme necessário.

Os eventos ativados por JavaScript e OnLaunched XAML contêm um argumento args, que você pode consultar para determinar o estado em que o aplicativo estava antes da ativação. A Figura 2 e a Figura 3 mostram exemplos do evento ativado.

Figura 2 Código de ativação de aplicativo em JavaScript

var app = WinJS.Application;
var activation = Windows.ApplicationModel.Activation;
var nav = WinJS.Navigation;
app.addEventListener("activated", function (args) {
  if (args.detail.kind === activation.ActivationKind.launch) {
    if (args.detail.previousExecutionState !==
      activation.ApplicationExecutionState.terminated) {
      // TODO: This application has been newly launched.
      // Initialize your application here.
    } else {
      // TODO: This application has been reactivated from suspension.
      // Restore application state here.
    }
    if (app.sessionState.history) {
        nav.history = app.sessionState.history;
    }
    args.setPromise(WinJS.UI.processAll().then(function () {
      if (nav.location) {
          nav.history.current.initialPlaceholder = true;
          return nav.navigate(nav.location, nav.state);
      } else {
        return nav.navigate(Application.navigator.home);
      }
    }));
  }
});

Figura 3 Código de ativação de aplicativo em C#

async protected override void OnLaunched(LaunchActivatedEventArgs args)
  {
// Check whether the session data should be restored.
    if (args.PreviousExecutionState == 
      ApplicationExecutionState.Terminated)
    {
      // Here we've created a SuspensionManager class that
      // handles restoring session data from a file and
      // then gives access to that data through a Dictionary.
      await SuspensionManager.RestoreAsync();
// Retrieve the data for restore.                 
data = SuspensionManager.SessionState["savedData"];
    }
    // If not, use the app's default values
    else
            {
data = "Welcome";
    }
    Window.Current.Activate();
}

O código que é executado durante a ativação deve ser executado dentro de 15 segundos ou o Windows encerrará o aplicativo. Embora isso possa parecer rigoroso, os aplicativos que impedem que o usuário interaja com a interface do usuário por tanto tempo não são responsivos. De acordo com pesquisa do UseIt.com sobre usuários e tempos de resposta (bit.ly/NWSumy), a maioria dos usuários abandonam sites que demoram mais de 10 segundos para carregar. Na verdade, os usuários ficam frustrados quando páginas demoram mais de 1 ou 2 segundos para carregar, e muitos saem muito antes do valor de referência de 10 segundos. Saber isso sobre os usuários é especialmente importante se você pretende vender seu aplicativo na Windows Store, pois os usuários frustrados postam comentários negativos sobre os aplicativos — sem contar que seu aplicativo pode nem mesmo passar na certificação da Store se o desempenho for ruim. (Consulte bit.ly/OxuEfu para obter mais informações sobre como enviar um aplicativo.) É importante considerar cuidadosamente quais dados carregar e quando. Felizmente, as bibliotecas do Tempo de Execução do Windows (WinRT) facilitam carregar dados de forma rápida e progressiva, oferecendo um modelo de programação assíncrono de primeira classe (bit.ly/NCx6gE).

O objeto Windows.ApplicationModel.Activation faz parte da API do Windows acessível por todos os aplicativos da Windows Store, independentemente da linguagem. O objeto Activation contém uma enumeração activationKind com os seguintes valores:

  • Launch: o usuário iniciou o aplicativo ou tocou em um bloco secundário.
  • Search: o usuário quer pesquisar com o aplicativo.
  • ShareTarget: o aplicativo foi ativado como destino para operações de destino.
  • File: um aplicativo abriu um arquivo cujo tipo esse aplicativo está registrado para manipular.
  • Protocol: um aplicativo abriu uma URL cujo protocolo esse aplicativo está registrado para executado.
  • FileOpenPicker: o usuário quer escolher arquivos ou pastas fornecidos pelo aplicativo.
  • FileSavePicker: o usuário quer salvar um arquivo e selecionou o aplicativo como local.
  • CachedFileUpdater: o usuário quer salvar um arquivo para o qual o aplicativo fornece gerenciamento de conteúdo.
  • ContactPicker: o usuário quer selecionar contatos.
  • Device: o aplicativo manipula o AutoPlay.
  • PrintTaskSettings: o aplicativo manipula tarefas de impressão.
  • CameraSettings: o aplicativo captura fotos ou vídeo de uma câmera conectada.

Como seu aplicativo pode suportar vários recursos, como compartilhamento e pesquisa, a enumeração activationKind permite ver qual é a intenção do usuário para iniciar o aplicativo e executar o código correspondente.

Como gerenciar suspensão, encerramento e retomada

Quando o usuário muda para um aplicativo diferente, ou o dispositivo hiberna ou entra em suspensão, o Windows interrompe a execução do código do aplicativo, mas mantém o aplicativo na memória. O motivo dessa suspensão é que minimiza o impacto da bateria e do desempenho dos aplicativos dos quais o usuário não está obtendo valor ativamente. Quando o Windows retorna da suspensão ou de um encerramento breve, o usuário deve ter a sensação de que o aplicativo nunca foi interrompido. O manuseio adequado dos eventos do ciclo de vida garante um design responsivo.

O Windows inicia o processo de suspensão gerando um evento oncheckpoint WinJS ou um evento OnSuspending XAML, onde você pode salvar dados e informações do usuário antes de o aplicativo passar ao modo suspenso. Qualquer código executado nesses eventos deve ser concluído em 10 segundos, ou o Windows interromperá o aplicativo por completo. Assim como no processo de ativação, essa regra mantém a integridade geral do sistema operacional estável e permite a alternância rápida. Gerar o evento oncheckpoint requer uma simples definição de função:

app.oncheckpoint = function (args) {
  // Save app data in case of termination.
};

Em XAML, você usa um evento Application.Suspending:

async void Suspending(Object sender,
  Windows.ApplicationModel.SuspendingEventArgs e) {
  // Save app data in case of termination.
}

Durante a suspensão, você precisa salvar o local do usuário ou a posição de rolagem no aplicativo, liberar identificações e conexões do arquivo e marcar os dados com data e hora. Você pode conseguir isso usando os objetos integrados WinJS.Application.sessionState ou XAML SuspensionManager. Você deve sempre salvar as informações do usuário e os dados do aplicativo no evento de suspensão porque o Windows não notifica os aplicativos antes de encerrá-los. Isso é importante porque o encerramento pode ocorrer sob uma variedade de circunstâncias, como quando o Windows precisa liberar memória ou o dispositivo fica sem energia (bateria).

Então, codifique na defensiva e presuma que o aplicativo será encerrado. Isso significa que você deve salvar os dados do aplicativo em sessionState sempre. Se o Windows encerrar o aplicativo, os dados estarão salvos e prontos para repreenchimento.

A retomada ocorre quando o Windows retira um aplicativo da suspensão. Na maioria das vezes, o Windows simplesmente retomará o aplicativo quando o usuário retornar a ele ou reabri-lo, e em termos de código, você não precisará fazer nada. Durante a suspensão, o aplicativo apenas fica na memória, intocável, para que seu conteúdo permaneça inalterado e não seja preciso fazer nada.

Embora a maioria dos aplicativos não precise fazer nada para sair do estado suspenso, os aplicativos que contêm dados que mudam frequentemente — como RSS feeds, ações e redes sociais — são bons candidatos para usar o evento de retomada. Como o evento de retomada cabe a esses cenários específicos, ele mora no objeto Windows.UI.WebUI.WebUIApplication e não no objeto mais comum WinJS.Application, juntamente com os eventos de ciclo de vida oncheckpoint, onactivated e outros similares:

Windows.UI.WebUI.WebUIApplication.addEventListener("resuming", function () {
  // Repopulate data from sessionState.
});

Você pode adicionar o identificador de retomada ao arquivo default.js ao lado do código de ativação para fins de organização de códigos. Mantenha seu aplicativo responsivo carregando rapidamente apenas a quantidade mínima de dados durante a retomada.

Tarefas em segundo plano e aplicativos de comunicações em tempo real

Embora o código da interface do usuário não seja executado com o aplicativo no modo suspenso, o aplicativo pode executar tarefas em segundo plano (bit.ly/QyRvsU), transferir arquivos grandes ou verificar se há email. Alguns aplicativos de comunicações em tempo real, como clientes de mensagens instantâneas, podem notificar o usuário quando uma mensagem chega, independentemente do estado de execução do aplicativo.

As tarefas de segundo plano são classes leves executadas periodicamente, sob certas restrições, enquanto o aplicativo não está tecnicamente em execução. Elas são executadas em seus próprios áreas de segurança ou contêineres de aplicativos enquanto o aplicativo permanece em estado de não-execução. As tarefas de segundo plano em JavaScript são executadas em um apartamento de thread individual do WWAHost.exe, e as tarefas de segundo plano não-JavaScript são executadas em um .dll em processo carregado em seu próprio apartamento de threading no aplicativo. Essa separação permite que as tarefas de segundo plano sejam executadas independentemente da interface do usuário de um aplicativo, que permanece suspensa até que o usuário retorne ao aplicativo.

Além de poder executar o código no segundo plano, esses aplicativos também exibem informações na tela de bloqueio. A tela de bloqueio contém uma imagem de fundo com informações leves sobrepostas, como hora, data, status da bateria e status da rede. Além disso, os aplicativos — especialmente os em execução em segundo plano — podem exibir informações na tela de bloqueio. Como é importante manter a tela de bloqueio facilmente digerível, as informações que podem ser exibidas são limitadas. Credenciais de até sete aplicativos podem ser exibidas, e o texto do bloco de um único aplicativo pode ser mostrado na tela de bloqueio. Para obter mais informações, consulte a visão geral da tela de bloqueio em bit.ly/RsE7pj.

Siga o modelo

Como desenvolvedor de aplicativos da Windows Store, você precisa se preocupar com problemas como duração da bateria e pressão da memória, execução do seu aplicativo em uma variedade de dispositivos e, o mais importante, a experiência do usuário. Você verá que as metas são mais fáceis de alcançar se seguir as diretrizes de gerenciamento de ciclo de vida descritas. Além disso, além das razões técnicas para o gerenciamento do ciclo de vida do aplicativo, se seu aplicativo for altamente responsivo e tiver um bom desempenho, ele receberá boas críticas na Windows Store.

Rachel Appel é desenvolvedora e divulgadora da Microsoft na cidade de Nova York. Fale com ela através do site rachelappel.com ou pelo e-mail rachel.appel@microsoft.com. Você também pode segui-la no Twitter em twitter.com/rachelappel.

Agradecemos aos seguintes especialistas técnicos pela revisão deste artigo: Adam Barrus, Ben Betz, Arun Kishan, Michael Krause, Hari Pulapaka, John Sheehan e Ben Srour