Experiência do usuário/interface do usuário

  • Artigo

As janelas redimensionáveis dão aos usuários mais controle sobre como eles usam o seu aplicativo. Novos recursos permitem que você faça mais com o bloco de seu aplicativo. E atualizações na pesquisa, no compartilhamento e nos botões criam uma experiência geral mais consistente para os usuários.

Novidades e atualizações do Windows 8.1

  • Janelas redimensionáveis
  • Atualizações nos blocos
  • Atualizações na pesquisa
  • Atualizações no compartilhamento
  • Os botões funcionam em todas as telas
  • Integre-se com pessoas e eventos
  • Síntese de fala
  • Atualizações no gerenciamento de tarefas em segundo plano
  • Suporte para aplicativo de alarme na tela de bloqueio
  • Atualizações no agendamento de itens de trabalho

Janelas redimensionáveis

[Obtenha exemplos dos modos de exibição do Aplicativo, Várias exibições e Gerenciador de projeção agora.]

O Windows 8.1 inclui várias alterações no tamanho e na posição das janelas. Ao desenvolver aplicativos para o Windows 8.1, tenha em mente estes pontos principais:

  • O Windows 8.1 não tem estados de exibição de largura fixa. Agora, os usuários podem redimensionar continuamente para baixo, até uma largura mínima. (A largura mínima padrão de um aplicativo é de 500 pixels.) Assim, os aplicativos não têm mais os estados de exibição ajustado e de preenchimento de exibição. Em vez disso, você desenvolve seu aplicativo para ser funcional e bonito em qualquer tamanho, até o mínimo.

    Observação  A exibição ajustada no Windows 8 tinha uma largura de 320 pixels. A largura mínima padrão de 500 pixels é maior do que a exibição ajustada do Windows 8.

  • Se o seu aplicativo funcionar bem em tamanhos menores e você quiser incentivar os usuários a manter o aplicativo na tela, mude a largura mínima para 320 pixels.

  • Os usuários podem ter mais de dois aplicativos na tela ao mesmo tempo. Portanto, seu aplicativo pode aparecer entre dois outros aplicativos e não estar adjacente à borda esquerda ou à direita da tela.

  • Um único aplicativo pode abrir mais de uma janela ao mesmo tempo.

  • Um aplicativo pode iniciar outro aplicativo. Quando isso acontece, os dois aplicativos geralmente dividem a tela uniformemente, caso haja espaço suficiente. Mas você pode alterar isso para que o aplicativo iniciado fique mais largo ou mais estreito que o aplicativo original ou para que ele substitua o aplicativo original na tela. Para substituir o comportamento padrão, use a propriedade DesiredRemainingView.

Os aplicativos devem preencher a altura da tela, assim como no Windows 8. A altura mínima de um aplicativo é de 768 pixels.

Requisitos de pixel para o tamanho mínimo estreito e o tamanho mínimo padrão de um aplicativo

Diretrizes de design para janelas redimensionáveis

Ao criar um aplicativo para o Windows 8.1, você precisa:

Amostras adicionais de layout estão disponíveis para janelas com capacidade de dimensionamento de 320 pixels de largura e para janelas que sejam mais altas do que largas. Para saber mais sobre o uso dos botões em um aplicativo, qualquer que seja o tamanho do aplicativo, veja Os botões funcionam em todas as telas.

Definindo a largura mínima

Para alterar a largura mínima de um aplicativo do padrão de 500 pixels, especifique o atributo MinWidth do elemento ApplicationView no manifesto do aplicativo.

<Application>
   <VisualElements>
      <ApplicationView MinWidth=”width320” />
   </VisualElements>
</Application>

Para saber mais sobre o manifesto do aplicativo, veja Manifesto do pacote do aplicativo.

Atualizações para a classe ApplicationView

No Windows 8.1, o namespace Windows.UI.ViewManagement tem estas novas enumerações:

E a classe ApplicationView tem estas novas propriedades:

ApplicationView também tem estes novos métodos:

No Windows 8.1, estes membros foram substituídos:

  • Propriedade ApplicationView.Value—Não é válida porque os aplicativos não têm mais estados de exibição de largura fixa. Em vez disso, você pode usar a propriedade Orientation para obter a orientação da janela do aplicativo e as propriedades AdjacentToLeftDisplayEdge, AdjacentToRightDisplayEdge e IsFullScreen para obter a posição do aplicativo.

  • Método ApplicationView.TryUnsnap—Não é válido porque os aplicativos não têm mais um estado ajustado específico e porque a largura mínima padrão é de 500 pixels.

  • Enumeração ApplicationViewState—Não é válida porque os aplicativos podem ser redimensionados continuamente e não têm mais estados de exibição de largura fixa.

Atualizações nos blocos

[Obtenha os exemplos de Selos e blocos de aplicativos e Blocos secundários agora.]

O Windows 8.1 introduz estas alterações nos blocos e na maneira como você trabalha com eles.

Novos tamanhos de blocos

No Windows 8, havia dois tamanhos de bloco:

  • Blocos quadrados (150×150 pixels no nível de colocação em escala de 1x).
  • Blocos largos (310×150 no nível de colocação em escala de 1x).

No Windows 8.1, há dois tamanhos de blocos adicionais:

  • Blocos pequenos (70×70 no nível de colocação em escala de 1x).
  • Blocos grandes (310×310 no nível de colocação em escala de 1x).

Como três dos quatro tipos de modelo agora são quadrados, os blocos que eram chamados de blocos "quadrados" no Windows 8 (150×150 no nível de colocação em escala de 1x) agora são chamados de blocos "médios". Todo o conjunto consiste então em pequeno, médio, largo e grande. Aqui estão alguns exemplos de todos os quatro tamanhos.

Um exemplo de todos os quatro tamanhos de blocos na tela iniciar

Um usuário pode ajustar quatro blocos pequenos no lugar de um bloco médio. Blocos pequenos não dão suporte a notificações de blocos dinâmicos, mas eles dão suporte a selos. Um bloco grande ocupa a mesma quantidade de espaço que dois blocos largos e dá suporte a notificações de blocos dinâmicos, assim como aos tamanhos de blocos do Windows 8.

Novas convenções de nomenclatura para modelos de blocos

Com a adição dos novos tamanhos de blocos, atualizamos a convenção de nomenclatura do Windows 8 para os modelos de blocos. A nova convenção usa tamanhos de pixel absolutos no nível de colocação em escala de 1×. Os quatro tamanhos de bloco são mapeados para os novos nomes conforme indicado a seguir, com muitos modelos em cada categoria:

  • Pequeno = Square70x70
  • Médio = Square150x150
  • Largo = Wide310x150
  • Grande = Square310x310

Da mesma forma, o atributo SmallLogo é agora chamado de Square30x30Logo no manifesto do aplicativo.

De acordo com as novas convenções de nomenclatura, todos os modelos de blocos existentes foram renomeados.

Nome antigo Nome novo Exemplo
TileSquare* TileSquare150x150* TileSquareImage (nome antigo)/TileSquare150x150Image (novo nome)
TileWidexxx TileWide310x150xxx TileWideImageAndText01 (nome antigo)/TileWide310x150ImageAndText01 (novo nome)

 

Para compatibilidade, os nomes antigos ainda são reconhecidos. Porém, use os novos nomes em qualquer desenvolvimento novo que você realizar.

Alterações relacionadas a blocos no manifesto do aplicativo

Você declara as propriedades padrão de seu bloco de aplicativo primário—os tamanhos aos quais ele dá suporte, o nome de exibição e a cor do bloco—no manifesto do aplicativo.

Optando pelos novos tamanhos de blocos

No Windows 8, você optava por dar suporte a um bloco largo para seu aplicativo especificando um ativo de bloco largo no manifesto do aplicativo. No Windows 8.1, você opta por dar suporte a um bloco grande (Square310x310) especificando um ativo de bloco grande no manifesto.

Observação  Seu aplicativo só poderá dar suporte a um bloco grande se ele também der suporte a um bloco largo.

Todos os aplicativos dão suporte a blocos médios (Square150x150) e pequenos (Square70x70). Novamente, você pode fornecer ativos de blocos pequenos no manifesto. Se o aplicativo não fornecer uma imagem de bloco pequeno – seja fazendo seu próprio trabalho de dimensionamento, seja fornecendo um ativo separado – o Windows 8.1 dimensionará automaticamente até a imagem de bloco médio.

Assim como no Windows 8, recomendamos que, para cada tamanho da bloco ao qual der suporte, você forneça ativos separados para cada um dos quatro níveis de colocação em escala (0,8x, 1x, 1,4x e 1,8x). Isso garante que seus blocos sejam sempre nítidos e não tenham artefatos de colocação em escala. Além disso, para melhor suporte de acessibilidade, você pode fornecer ativos de imagem para o tema de alto contraste.

Exibindo o nome do aplicativo para diferentes tamanhos de blocos

No Windows 8, você usava o manifesto do aplicativo para especificar quais tamanhos de blocos exibiam o nome do aplicativo. Você ainda faz isso no Windows 8.1, mas há um novo formato para isso. Observe que você não pode mostrar o nome do aplicativo no tamanho de bloco pequeno (Square70x70).

Declarando um tamanho padrão de fixação

No Windows 8, se um aplicativo dava suporte a um bloco grande, ele era fixado como um bloco grande ao ser iniciado; caso contrário, ele era fixado como um bloco médio. No Windows 8.1, você pode, opcionalmente, substituir isso e declarar o bloco médio ou grande (mas não o bloco pequeno ou grande) como o tamanho padrão de fixação. Mas não se esqueça de que, no Windows 8.1, seu aplicativo não é fixado automaticamente para ser iniciado na instalação. Ele aparece na exibição Todos os Aplicativos e, nela, o usuário deve escolher explicitamente a fixação do aplicativo para ser iniciado.

Alterações no esquema de manifesto do aplicativo

Agora você especifica um namespace adicional, "https://schemas.microsoft.com/appx/2013/manifest", em seu manifesto, para incluir os elementos do esquema que declaram a nova funcionalidade da qual estamos falando. O exemplo a seguir mostra alguns dos atributos novos e renomeados que você verá no manifesto. Observe o ativo de bloco grande incluído no elemento DefaultTile, que também declara explicitamente um tamanho padrão preferido. O aplicativo também opta por mostrar seu nome de aplicativo somente nos blocos médio e largos, não no bloco grande.

<Package 
    xmlns="https://schemas.microsoft.com/appx/2010/manifest" 
    xmlns:wb="https://schemas.microsoft.com/appx/2013/manifest">
    
...

<wb:VisualElements 
    DisplayName="Your app name" 
    Description="App description" 
    BackgroundColor="#464646" 
    ForegroundText="light" 
    ToastCapable="true" 
    Square150x150Logo="Assets\Medium150x150Tile.png" 
    Square30x30Logo="Assets\APVLogo.png">
    
    <wb:DefaultTile 
        Square70x70Logo="Assets\Small70x70Tile.png" 
        Wide310x150Logo="Assets\Wide310x150Tile.png" 
        Square310x310Logo="Assets\Large310x310Tile.png" 
        ShortName="App" 
        DefaultSize="square150x150Logo">
        
        <wb:ShowNameOnTiles>
            <wb:ShowOn Tile="square150x150Logo"/>
            <wb:ShowOn Tile="wide310x150Logo"/> 
        </wb:ShowNameOnTiles>
    </wb:DefaultTile>
    
    <wb:LockScreen 
        Notification="badgeAndTileText" 
        BadgeLogo="Assets\badge.png"/>
    
    <wb:SplashScreen Image="Assets\SplashScreen.png"/>
</wb:VisualElements>

Alterações nas notificações de blocos

Ao enviar uma notificação de bloco, lembre-se de que seu aplicativo pode receber a notificação quando estiver em execução no Windows 8.1 ou no Windows 8. Como os novos nomes para os modelos existentes são reconhecidos apenas pelo Windows 8.1, o esquema adicionou um atributo fallback. Com a inclusão do atributo fallback, sua carga de notificação pode especificar um modelo do Windows 8.1 juntamente com um modelo do Windows 8, caso a notificação seja recebida em um sistema Windows 8. Para usar os novos nomes de modelo e o atributo fallback, inclua o novo atributo version, definido com o valor de 2, no elemento visual, como mostrado aqui.

<tile>
  <visual version="2">
    <binding template="TileSquare150x150Image" fallback="TileSquareImage" branding="None">
      <image id="1" src="Assets/Images/w6.png"/>
    </binding>
    <binding template="TileWide310x150Image" fallback="TileWideImage" branding="None">
      <image id="1" src="Assets/Images/sq5.png"/>
    </binding>
    <binding template="TileSquare310x310Image" branding="None">
      <image id="1" src="Assets/Images/sq6.png"/>
    </binding>
  </visual>
</tile>

Observe que você não pode usar o atributo fallback com blocos grandes, porque eles não existiam no Windows 8. As notificações do Windows 8 funcionam muito bem no Windows 8.1 sem alterações, mas elas não podem usar o tamanho de bloco grande.

Observação  Qualquer modelo de bloco grande (Square310x310) incluído em sua carga deve ser a última associação listada. Um sistema Windows 8 deixará de analisar uma notificação se encontrar uma associação que ele não reconheça através do modelo ou do nome de fallback. Assim, ele sempre vai parar quando encontrar uma associação 310×310.

Especificando tamanhos de blocos para a fila de notificação

No Windows 8, quando você habilitava a fila de notificação, ela era habilitada para blocos médios e grandes. O Windows 8.1 adiciona métodos para a classe TileUpdater, que permitem habilitar a fila de notificação para tamanhos de blocos específicos.

Novos tamanhos de blocos e logotipos alternativos em blocos secundários

No Windows 8.1, o submenu que os usuários veem ao fixar conteúdo como um bloco secundário permite percorrer e escolher dentre todos os tamanhos e aparências de bloco secundário disponíveis. O bloco secundário pode dar suporte a qualquer tamanho de bloco que tenha suporte em seu bloco de aplicativo. Se você não determinar uma imagem de bloco pequena específica para o bloco secundário, o Windows 8.1 reduzirá a imagem de bloco quadrado e a usará.

Além da imagem de bloco secundário padrão, você pode fornecer até três versões alternativas para cada tamanho de bloco, até o máximo possível de 12 versões. Você também pode especificar, usando o método AlternateVisualElements, um pequeno logotipo alternativo para cada um dos três tamanhos de bloco (quadrado, largo, grande) que dão suporte a logotipos.

Suporte mais preciso a cadeia de caracteres fonética para ordenar blocos secundários

Em certos idiomas baseados em caracteres, como japonês, a ordem de classificação na interface do usuário é baseada em uma ortografia fonética dos caracteres que compõem o nome de exibição do aplicativo. A ortografia fonética é uma cadeia de caracteres separada do nome de exibição. Ao fixar um bloco secundário, os usuários podem especificar um nome de exibição para o bloco no submenu flutuante, mas não podem especificar uma ortografia fonética. O Windows faz uma suposição quanto à cadeia de caracteres fonética, mas ela nem sempre está correta.

Às vezes, porém, os aplicativos conhecem a cadeia de caracteres fonética correta porque o usuário a definiu por meio de um controle personalizado que o aplicativo oferece. No Windows 8.1, um aplicativo pode então passar essa cadeia de caracteres para o Windows por meio da nova propriedade SecondaryTile.PhoneticName. Observe que essa cadeia de caracteres de nome fonético está vinculada ao nome de exibição padrão associado ao bloco secundário. Portanto, se o usuário alterar o nome de exibição por meio do submenu de fixação, a suposição do sistema para a ortografia fonética será usada.

Atualizações na pesquisa

[Obtenha o exemplo de controle SearchBox agora.]

O Windows 8.1 introduz um novo controle de caixa de pesquisa para ajudar você a fornecer resultados de pesquisa: Windows.UI.Xaml.Controls.SearchBox para aplicativos que usam XAML e WinJS.UI.SearchBox para aplicativos que usam JavaScript.

Agora, seus aplicativos podem incluir a caixa de pesquisa como um elemento na marcação. O novo controle dá suporte a estilos e modelagem completos.

No Windows 8.1, a experiência de pesquisa de aplicativo é controlada completamente por seus aplicativos. A caixa de pesquisa integra-se com o contrato de Pesquisa para habilitar a experiência e permitir uma personalização profunda, de modo que seus aplicativos ofereçam experiências de acordo com as necessidades do usuário.

A caixa de pesquisa dá suporte a sugestões e resultados de pesquisa fornecidos pelo aplicativo e histórico de pesquisa específico do aplicativo, bem como suporte completo para interações com toque, teclado e mouse.

O layout da caixa de pesquisa tem aparência semelhante ao exemplo a seguir.

O controle de caixa de pesquisa no aplicativo para aplicativos da Windows Store

Aqui estão exemplos de resultados de pesquisa exibidos no controle da caixa de pesquisa.

Exemplo de resultados da caixa de pesquisa para MSFT.

O controle da caixa de pesquisa dá suporte à integração com IME.

Controle de pesquisa no aplicativo com IME.

As sugestões são atualizadas à medida que o usuário digita cada letra com um IME. As sugestões incluem caracteres chineses ideográficos com base na entrada fonética parcial. A interface do usuário do Candidato IME UI não obstrui o submenu de sugestões de pesquisa. A caixa de pesquisa dá suporte ao uso de entrada do teclado para navegar na caixa de texto, na lista de candidatos IME e nas sugestões de pesquisa.

Atualizações no compartilhamento

[Obtenha os exemplos de Origem de conteúdo de compartilhamento e Destino de conteúdo de compartilhamento agora.]

O Windows 8.1 disponibiliza essa alterações para o compartilhamento de experiências e a maneira como você usa o contrato de Compartilhamento em seus aplicativos.

Adicionando novos formatos de dados para DataPackage

No Windows 8.1, aplicativos de origem para o contrato de Compartilhamento podem fornecer várias maneiras de voltar para o conteúdo que está sendo compartilhado. O Windows 8.1 divide o formato Uri em dois novos formatos de dados no DataPackage e introduz quatro novas propriedades fortemente tipadas no DataPackagePropertySet. Para DataPackage, o formato Uri é substituído pelos formatos WebLink e ApplicationLink.

WebLink é compartilhado quando o usuário não seleciona nada, assim, o aplicativo de origem compartilha uma seleção implícita do conteúdo exibido. Ao popular esse formato, o aplicativo de origem compartilha o conteúdo da página atual como um URI (Uniform Resource Identifier). O link compartilhado faz referência à página da Web que o usuário está exibindo, assim, esse formato sempre começa com http ou https.

ApplicationLink também é compartilhado quando o usuário não seleciona nada; assim, novamente, o aplicativo de origem compartilha uma seleção implícita do conteúdo exibido. Ao popular esse formato, o aplicativo de origem compartilha o conteúdo da página atual como um URI. O URI compartilhado tem um esquema que é manipulado pelo aplicativo de origem. Quando o aplicativo de origem é ativado com esse protocolo de URI, ele exibe o mesmo conteúdo que está sendo exibido no momento. Esse formato representa o conteúdo compartilhado fornecendo uma maneira de retornar ao conteúdo com o uso de um protocolo de aplicativo.

Os formatos WebLink e ApplicationLink não são exclusivos. WebLink vincula a conteúdo na Web e ApplicationLink vincula ao conteúdo de um aplicativo. Por exemplo, um aplicativo leitor de notícias pode ter conteúdo em ambos os formatos, com um URI para levar o usuário de volta ao artigo no aplicativo ou para levar o usuário ao mesmo artigo em um site. O aplicativo de destino escolhe como manipular o URI. Por exemplo, o aplicativo Email pode usar o formato WebLink, porque o link pode ser enviado à Internet e consumido em um sistema que não seja o Windows. Porém, o aplicativo leitor pode usar o formato ApplicationLink, assim, ele reativa o aplicativo de origem e leva o usuário de volta ao conteúdo original.

ContentSourceWebLink é uma propriedade complementar que você usa para atribuir o conteúdo compartilhado. Ela é compartilhada quando o aplicativo fornece um link da Web para o conteúdo que está sendo compartilhado. Quando o usuário faz uma seleção explícita, o formato WebLink não é populado, porque o valor para o formato WebLink não é igual à seleção do usuário. Popular essas informações não significa que a página da Web é a seleção do usuário, mas apenas que o conteúdo provém dela.

ContentSourceApplicationLink é a segunda propriedade complementar que você usa para atribuir o conteúdo compartilhado. Ela é compartilhada quando o aplicativo determina que é significativo que o usuário retorne ao conteúdo exibido atualmente no aplicativo. Quando o usuário faz uma seleção, o formato ApplicationLink não é populado, porque o valor para o formato ApplicationLink, nesse caso, não é igual à seleção do usuário. Popular essas informações não significa que o link profundo no aplicativo representa a seleção do usuário, mas apenas que o conteúdo provém dela.

Por exemplo, um usuário está em um aplicativo leitor examinando um artigo. O usuário seleciona uma citação e a compartilha no OneNote. Para atribuir a citação ao artigo, o aplicativo leitor não usa o formato WebLink ou ApplicationLink, porque o artigo não é equivalente à citação que está sendo compartilhada. Então, em vez disso, o aplicativo usa as propriedades ContentSourceWebLink e ContentSourceApplicationLink. O OneNote adiciona o texto selecionado, juntamente com a atribuição de fonte. Mais tarde no OneNote, o usuário pode ler a citação e retornar ao aplicativo leitor ou à página da Web para ler o contexto da citação.

Melhorando a capacidade de resposta de compartilhamento

No Windows 8.1, os aplicativos que usam o contrato de Compartilhamento podem melhorar a capacidade de resposta ignorando o painel de compartilhamento de forma programática.

Chame o novo método DismissUI para fechar o painel de Compartilhamento. Chamar DismissUI é semelhante a quando o usuário ignora o painel Compartilhar tocando fora dele. Se a operação de compartilhamento levar muito tempo, o aplicativo continuará a ser executado. Se a operação não tiver execução longa, ela terá 10 segundos para ser executada antes de ser encerrada.

Atualmente, o aplicativo de destino não pode se mover para fora da tela. Assim, quando uma operação de compartilhamento é iniciada, o aplicativo normalmente mostra um indicador de progresso e o usuário deve aguardar até que a operação seja concluída (embora a interação do usuário não seja mais necessária para concluir a operação). Embora, na realidade, seja seguro para o usuário fechar o submenu com um toque leve, os usuários tendem a pensar que descartar antes que a operação de compartilhamento seja concluída pode causar perda de dados; por isso, eles não estão dispostos a fazê-lo. DismissUI permite que seu aplicativo descarte o submenu automaticamente.

Nome da família de pacote

No Windows 8.1, aplicativos de origem para o contrato de Compartilhamento podem fornecer um Nome da Família de Pacote para os aplicativos de destino, de modo que eles possam fornecer uma experiência de fallback ao iniciar o aplicativo especificado por ApplicationLink.

O Nome da Família de Pacote é o identificador exclusivo de um pacote do aplicativo. Quando um aplicativo de origem fornece esse identificador ao aplicativo de destino, o aplicativo de destino pode oferecer uma experiência de fallback chamando o método LaunchUriAsync com o ApplicationLink fornecido. Se o esquema de URI não for manipulado, por exemplo, porque o usuário desinstalou o aplicativo, ou se o URI for movido para outro dispositivo que não tenha o aplicativo instalado, uma caixa de diálogo instruirá o usuário a procurar um aplicativo na Windows Store. O usuário é levado para a Loja por padrão, mas não para o aplicativo desejado. Se você incluir o Nome da Família de Pacote no objeto LauncherOptions que é passado para o LaunchUriAsync, o usuário será avisado sobre o aplicativo específico a ser instalado e será levado para a página de listagem desse aplicativo na Loja

O formato de Uri foi substituído

Como mencionado anteriormente, o Windows 8.1 divide o formato de Uri em dois novos formatos de dados em DataPackage e introduz quatro novas propriedades fortemente tipadas em DataPackagePropertySet. Para DataPackage, o formato Uri é substituído pelos formatos WebLink e ApplicationLink. O formato Uri permanece como um alias para o formato WebLink.

Os botões funcionam em todas as telas

No Windows 8, quando havia vários aplicativos na tela e o usuário invocava botões, o sistema exibia botões para qualquer aplicativo que ocupasse o maior espaço na tela. No Windows 8.1, o sistema exibe botões para o último aplicativo com o qual o usuário interagiu, independentemente de quantos aplicativos estejam na tela ou se há várias telas. Por exemplo, se o usuário selecionar o botão Configurações, o sistema exibirá as configurações do submenu para o último aplicativo que foi usado.

Projete seu aplicativo para que ele funcione com os botões, independentemente do tamanho do aplicativo. Em particular, a largura do submenu Configurações deve ser menor ou igual à largura atual de seu aplicativo.

Criar aplicativos que se integram com as pessoas e os eventos

[Veja, agora, os exemplos API do Gerenciador de Contatos, API de Compromissos e Lidando com ações do contato.]

O Windows 8.1 permite que você acrescente ao seu aplicativo o poder de pessoas e eventos. Você pode permitir que os usuários do seu aplicativo procurem informações sobre pessoas que eles conhecem diretamente no aplicativo e interajam com as pessoas integrando experiências de comunicação, como mensagens, email, chamadas, chamadas de vídeo e assim por diante. Você também pode manter os usuários no seu aplicativo permitindo que eles vejam rapidamente suas disponibilidades no calendário e adicionem eventos ao calendário que preferirem.

Use estas novas APIs para habilitar o aplicativo a exibir cartões de visita das pessoas e gerenciar eventos diretamente em seu aplicativo:

  • ShowContactCard método

    Habilita os aplicativos a consultar o sistema operacional para obter o contato de um usuário e mostrar os dados de contato do usuário em um cartão de visita.

  • AppointmentsProvider namespace

    Dá suporte a solicitações para adicionar, substituir e remover compromissos por meio de ativações com as quais um provedor de compromissos interage.

  • AppointmentManager classe

    Habilita os aplicativos a interagir com o provedor de compromissos do usuário para adicionar, substituir e remover eventos. Além disso, mostra a interface do usuário primária para o provedor de compromissos.

  • Activation namespace

    Habilita um aplicativo a lidar com os parâmetros de ativação para o novo provedor de compromissos e contratos de contato, com suporte no Windows.

Síntese de fala

[Obtenha o exemplo de Síntese de fala agora.]

O Windows 8.1 introduz a API de Windows.Media.SpeechSynthesis, que dá suporte à síntese de fala—conhecida como TTS (conversão de texto em fala)— em aplicativos da Windows Store.

Use a síntese de voz para solicitar entrada ao usuário, realçar notificações de aplicativos e caixas de diálogo de mensagens, dar instruções (como navegação passo a passo) e ler conteúdo como mensagens de texto ou email, RSS feeds, livros e resultados de pesquisa.

O Windows 8.1 inclui diversos mecanismos de síntese de fala, conhecido como vozes. Cada voz tem um nome amigável, como Microsoft David (en-US, masculino), Microsoft Zira (en-US, feminino) e Microsoft Hazel (en-UK, feminino), que pode ser especificado no seu aplicativo e também selecionado por um usuário em Idioma no painel de controle.

Os recursos de síntese de fala com suporte no Windows 8.1 habilitam o seguinte:

  • Configuração do sintetizador de fala para um gênero, uma voz e um idioma específicos.

  • Geração de saída de fala de uma cadeia de caracteres de texto simples usando as características e propriedades padrão da voz atual.

  • Geração de saída de fala de uma cadeia de caracteres contendo SSML (Speech Synthesis Markup Language) para personalizar as características da voz, a pronúncia, o volume, o tom, a taxa ou velocidade, a ênfase e assim por diante.

  • Leitura e gravação de dados de áudio gerados pelo mecanismo de síntese de fala de e para um fluxo de acesso aleatório.

Geração de fala por meio de um texto simples

Este exemplo mostra como um aplicativo da Windows Store usa um objeto SpeechSynthesizer para criar um fluxo de áudio e gerar a fala com base em uma cadeia de caracteres de texto simples.

// The object for controlling and playing audio.
var audio = new Audio();

// The object for controlling the speech-synthesis engine (voice).
var synth = new Windows.Media.SpeechSynthesis.SpeechSynthesizer();

// Generate the audio stream from plain text.
synth.synthesizeTextToStreamAsync("hello World").then(function (markersStream) {

    // Convert the stream to a URL Blob.
    var blob = MSApp.createBlobFromRandomAccessStream(markersStream.ContentType, markersStream);

    // Send the Blob to the audio object.
    audio.src = URL.createObjectURL(blob, { oneTimeOnly: true });
    audio.play();
});

// The media object for controlling and playing audio.
MediaElement mediaElement = this.media;

// The object for controlling the speech-synthesis engine (voice).
var synth = new Windows.Media.SpeechSynthesis.SpeechSynthesizer();

// Generate the audio stream from plain text.
SpeechSynthesisStream stream = await synth.SynthesizeTextToStreamAsync("Hello World");

// Send the stream to the media object.
mediaElement.SetSource(stream, stream.ContentType);
mediaElement.Play();

Gerando saída de fala por meio de SSML (Speech Synthesis Markup Language )

O próximo exemplo mostra como um aplicativo da Windows Store usa um objeto SpeechSynthesizer para criar um fluxo de áudio e gerar a fala com base em uma cadeia de caracteres de texto SSML.

// The string to speak with SSML customizations.
var Ssml = "<speak version='1.0' " +
    "xmlns='http://www.w3.org/2001/10/synthesis' xml:lang='en-US'>" +
    "Hello <prosody contour='(0%,+80Hz) (10%,+80%) (40%,+80Hz)'>World</prosody> " + 
    "<break time='500ms' />" +
    "Goodbye <prosody rate='slow' contour='(0%,+20Hz) (10%,+30%) (40%,+10Hz)'>World</prosody>" +
    "</speak>";

// The object for controlling and playing audio.
var audio = new Audio();

// The object for controlling the speech-synthesis engine (voice).
var synth = new Windows.Media.SpeechSynthesis.SpeechSynthesizer();

// Generate the audio stream from SSML.
synth.synthesizeSsmlToStreamAsync(Ssml).then(function(synthesisStream){

    // Convert the stream to a URL Blob.
    var blob = MSApp.createBlobFromRandomAccessStream(synthesisStream.ContentType, synthesisStream);

    // Send the Blob to the audio object.
    audio.src = URL.createObjectURL(blob, { oneTimeOnly: true });
    audio.play();
});

// The string to speak with SSML customizations.
string Ssml =
    @"<speak version='1.0' " +
    "xmlns='http://www.w3.org/2001/10/synthesis' xml:lang='en-US'>" +
    "Hello <prosody contour='(0%,+80Hz) (10%,+80%) (40%,+80Hz)'>World</prosody> " + 
    "<break time='500ms' />" +
    "Goodbye <prosody rate='slow' contour='(0%,+20Hz) (10%,+30%) (40%,+10Hz)'>World</prosody>" +
    "</speak>";

// The media object for controlling and playing audio.
MediaElement mediaElement = this.media;

// The object for controlling the speech-synthesis engine (voice).
var synth = new Windows.Media.SpeechSynthesis.SpeechSynthesizer();

// Generate the audio stream from SSML.
SpeechSynthesisStream stream = await synth.synthesizeSsmlToStreamAsync(Ssml);

// Send the stream to the media object.
mediaElement.SetSource(stream, stream.ContentType);
mediaElement.Play();

Atualizações no gerenciamento de tarefas em segundo plano

[Obtenha o exemplo de Tarefa em segundo plano agora.]

O Windows 8.1 adiciona vários novos recursos para tarefas em segundo plano.

Período de silêncio e tarefas em segundo plano

O período de silêncio é um novo recurso do Windows 8.1 que permite ao usuário designar determinados períodos do dia para não receber notificações. Esse recurso também interrompe a maior parte da atividade em segundo plano associada aos aplicativos da Windows Store, impedindo que o usuário seja incomodado e podendo estender a vida útil de carga da bateria do dispositivo.

Quando o sistema entra no período de silêncio, as tarefas em segundo plano são colocadas na fila e suspensas até o final do período. As tarefas em segundo plano que estiverem sendo executadas serão canceladas quando o sistema entrar no período de silêncio.

No final do período de silêncio, as tarefas em segundo plano estarão autorizadas a começar. Cada tarefa em segundo plano é iniciada novamente em um intervalo aleatório antes do sistema sair do período de silêncio. Isso assegura que as tarefas em segundo plano não sejam ativadas ao mesmo tempo, o que colocaria uma carga desnecessária nos recursos do sistema e nos recursos do servidor remoto. O sistema não acionará notificações antes do horário de término do período de silêncio.

Por padrão, há duas exceções permitidas para o período de silêncio: as chamadas telefônicas que chegam de um aplicativo que dá suporte ao novo recurso de chamada de tela de bloqueio e os alarmes definidos pelo usuário no aplicativo de alarme padrão designado. Se o aplicativo for um aplicativo capaz de fazer chamada com tela de bloqueio e a configuração IncomingCall estiver definida como TRUE, a tarefa em segundo plano será executada e a notificação será entregue. As notificações de alarmes definidos pelo usuário no aplicativo de alarme padrão designado serão entregue durante o período de silêncio.

O período de silêncio é ativado por padrão a partir de meia-noite às 6 da manhã, embora permita o recebimento de chamadas. Os usuários podem alterar essas configurações ou desabilitar o período de silêncio na guia notificações da seção de aplicativos de Mudar configurações do computador. Os períodos de silêncio estão disponíveis em todos os sistemas.

Cancelamento de tarefas ociosas

Além de restrições de recursos de tarefas em segundo plano, a infraestrutura de tarefa em segundo plano do Windows detecta tarefas em segundo plano ociosas ou suspensas. A tarefa em segundo plano é considerada ociosa ou suspensa quando não utiliza a cota mínima de recursos de CPU ou de rede em um período mínimo de tempo (que varia de acordo com o estado do sistema). Se uma tarefa em segundo plano ociosa ou suspensa for detectada, uma notificação de cancelamento será enviada para que ela seja parada e fechada. Se a tarefa em segundo plano não parar de funcionar e fechar em até cinco segundos, o sistema detectará que o aplicativo parou de responder e o encerrará.

No Windows 8.1, evite que o seu aplicativo seja encerrado devido a uma tarefa em segundo plano ociosa ou suspensa: sempre associe um manipulador de cancelamento para que ele seja cancelado da forma correta. Veja detalhes e trechos de código em Como lidar com tarefas em segundo plano ociosas ou suspensas.

Dica de custo de trabalho para tarefa em segundo plano

O Windows 8.1 fornece uma dica para tarefas em segundo plano sobre a disponibilidade de recursos. Quando uma tarefa em segundo plano é ativada, ela pode usar essa dica para decidir quanto trabalho deve ser realizado. Três estados de recursos em segundo plano podem ser relatados: Baixo, Médio e Alto. Para saber mais, veja BackgroundWorkCost e BackgroundWorkCostValue.

Cmdlets do PowerShell para tarefas em segundo plano

Os desenvolvedores podem usar os novos comandos AppBackgroundTask do PowerShell e o novo módulo de designer do cmdlet BackgroundTasksManager para obter informações sobre as tarefas em segundo plano que estão sendo executadas. Isso pode ser muito útil na implementação e depuração de tarefas em segundo plano. Para saber mais, veja os cmdlets do PowerShell para tarefas em segundo plano.

Suporte para aplicativo de alarme na tela de bloqueio

[Obtenha o exemplo de Notificações de alarme agora.]

No Windows 8.1, um dos slots de tela de bloqueio agora é usado para aplicativos de alarme. Os aplicativos de alarme usam a classe AlarmApplicationManager para solicitar permissão do usuário para ser o aplicativo de alarme do sistema. Se o usuário conceder permissão (ou se colocar o aplicativo nesse slot de alarme usando o painel de controle), o aplicativo usará o slot e se tornará o aplicativo de alarme do sistema. As notificações de alarme disparadas pelo aplicativo de alarme do sistema são mostradas ao usuário com uma precisão de um segundo. Apenas o aplicativo no slot de alarme pode disparar notificações de alarme; notificações de alarme disparadas por outros aplicativos são tratadas como notificações normais.

Você agenda notificações de alarme por meio da criação de notificações do sistema com o elemento commands. E você usa o elemento audio para especificar o som do alarme, que é reproduzido quando a notificação é disparada, mesmo que o mudo seja ativado para o sistema.

Atualizações no agendamento de itens de trabalho

A API CoreDispatcher (Windows::UI::Core:CoreDispatcher) agora permite que você tenha mais controle sobre as prioridades no agendamento de item de trabalho.

No Windows 8.1, as prioridades de expedição de trabalho agora estão na seguinte ordem:

  1. SendMessage (Prioridade mais alta)
  2. CoreDispatcherPriority.High
  3. CoreDispatcherPriority.Normal (Inclui mensagens do Windows e chamadas COM (Component Object Model))
  4. Qualquer mensagem de dispositivos de entrada
  5. CoreDispatcherPriority.Low
  6. CoreDispatcherPriority.Idle (Prioridade mais baixa, usada para tarefas em segundo plano)

Para alterar as prioridades das tarefas, use estes novos membros no tipo CoreDispatcher:

  • Método CoreDispatcher::ShouldYield (2 sobrecargas)—Consulta se o chamador deve produzir caso não haja itens na fila de tarefas com a prioridade especificada ou uma prioridade superior.

  • Propriedade CoreDispatcher::CurrentPriority—Obtém ou define a prioridade atual da tarefa que o CoreDispatcher manipulou mais recentemente. Quando um aplicativo estiver processando um trabalho com uma prioridade específica e um trabalho com prioridade mais alta for recebido, defina essa propriedade para aumentar a prioridade da tarefa atual, de modo que ShouldYield forneça resultados mais precisos.