Windows 8

Criando aplicativos para o Windows 8 e o Windows Phone 8

Joel Reyes

Windows Phone 8 e Windows 8: a um passo da convergência. Enquanto isso, os desenvolvedores interessados em criar para ambas as plataformas devem compreender as diferenças e semelhanças encontradas nelas. Saber onde as APIs do Tempo de Execução do Windows 8 e do Windows Phone se cruzam atualmente proporciona a você a melhor oportunidade de fornecer aplicativos a ambas as plataformas, aproveitando muito do mesmo conhecimento, ferramentas, código e ativos. Neste artigo, pretendo explorar essas diferenças e semelhanças para ajudá-lo a compreender o que é e o que não é possível fazer antes de iniciar o desenvolvimento de uma solução direcionada a ambas as plataformas

A consistência na experiência do usuário (isto é, o uso de blocos, a sofisticada interface de toque, a navegação e a barra de aplicativos) simplifica o design e a implementação de aplicativos nas duas plataformas. E a adoção de uma área de superfície de API comum facilita o compartilhamento de código em inúmeros cenários. Você pode escolher as tecnologias certas para os seus aplicativos: C#, Visual Basic ou C++, ou uma solução híbrida para ambas as plataformas. Os recursos disponíveis em aka.ms/sharecode contêm excelentes informações sobre criação de aplicativos executados no Windows Phone 8 e no Windows 8, bem como apresentam técnicas de compartilhamento de código destinadas a maximizar a reutilização do código ao desenvolver para ambas as plataformas.

Áreas específicas de comparação

A compilação eficaz em ambas as plataformas requer conhecimento das principais diferenças entre os recursos, bem como dos recursos que apresentam semelhanças em um nível elevado, mas com diferentes APIs e implementações. Para esses recursos, não tente reutilizar o código. Examinarei três áreas de preocupação:

  • UX
  • Modelo de dados e código de suporte
  • Recursos específicos à plataforma

UX

Fatores forma representam uma importante preocupação ao criar interfaces do usuário para aplicativos multiplataforma. É preciso avaliar atributos como resoluções e tamanhos de tela, além da orientação padrão do dispositivo. É preciso tomar decisões cuidadosas sobre a interface do usuário a fim de garantir uma experiência aprimorada ao usuário considerando as restrições do dispositivo em particular.

Você logo perceberá o quão sem sentido é incluir todos os recursos de um aplicativo da Windows Store em um aplicativo Windows Phone 8 e constatará a necessidade de criar uma experiência do usuário própria para cada plataforma. A Figura 1 apresenta exemplos do tipo de diferenças na interface do usuário a serem consideradas para criar a melhor experiência possível.

Figura 1 Uma comparação entre os recursos do Windows Phone 8 e do Windows 8 na experiência do usuário

Windows Phone 8 Windows 8
Toque com apenas uma mão mais comum Toque com uma ou duas mãos, mouse
Hardware garantido, como câmera e acelerômetro Nenhuma garantia de qualquer hardware específico, requer verificação no tempo de execução
Evite colunas múltiplas de conteúdo Linhas e colunas de conteúdo podem funcionar bem
Role verticalmente para obter mais conteúdo; espaço limitado na barra de aplicativos Role horizontalmente para obter mais conteúdo; espaço significativo na barra de aplicativo
Botão Back no hardware Botão Back na tela
Sem zoom semântico Zoom semântico

XAML Namespaces Embora tanto o Windows 8 quanto o Windows Phone 8 utilizem XAML no design da interface do usuário, não espere reutilizar o XAML em seus aplicativos. Há grandes diferenças nas plataformas, como layout e orientação de página, namespaces XAML e controles XAML, o que torna o processo desafiador. 

Apesar de inúmeros, os controles de ambas as plataformas residem em diferentes namespaces. Por exemplo, os controles equivalentes do Windows 8 no Windows Phone encontram-se em Windows.UIXaml.Controls, bem como no Microsoft.Phone.Controls e no Microsoft.Phone.Shell, enquanto o System.Windows.Controls contém controles do Windows 8 e alguns controles compartilhados. Felizmente, o editor XAML o alertará quando houver uma tentativa de adicionar controles incompatíveis. Contudo, o XAML não oferece suporte à compilação condicional; portanto, não há uma maneira fácil de incluir namespaces para uma ou outra plataforma no tempo de execução.

Controles XAML Cada biblioteca de controles foi otimizada em relação à sua plataforma correspondente. Por consequência, recomendamos fortemente que crie seus próprios controles do usuário individualmente para cada plataforma. Isso ajudará a manter uma experiência do usuário consistente nas plataformas, reduzindo ao mesmo tempo a possibilidade de bugs ao portar o XAML. A Figura 2 mostra alguns controles básicos.

Figura 2 Controles básicos do Windows Phone e do Windows 8

Windows Phone 8 Windows 8
O controle PhoneApplicationPage é o elemento raiz da página A página de controle é o elemento raiz da página
Use o controle LongListSelector para mostrar verticalmente o conteúdo de rolagem Use o controle GridView para mostrar verticalmente o conteúdo de rolagem
Use o controle Pivot para paginar o conteúdo horizontalmente Use o controle SemanticZoom para agrupar vários itens em segmentos agrupados (é possível também usar o controle Página de itens agrupados)
Use o controle ApplicationBar Use o controle AppBar

Os modelos do Visual Studio para Windows 8 criam um LayoutAwarePage, que é uma subclasse da página na API básica oferecendo os seguintes recursos adicionais e garantindo a consistência do design e da experiência do usuário:

  • Estado de exibição do aplicativo para mapeamento do estado visual
  • Manipuladores de eventos GoBack, GoForward e GoHome
  • Atalhos do mouse e do teclado para navegação
  • Gerenciamento de estado para navegação e gerenciamento do tempo de vida do processo
  • Um modelo de exibição padrão

Modelo de dados e código de suporte

Todos os aplicativos têm a função de gerenciar dados, e os modelos de dados oferecem a melhor maneira de realizar essa tarefa. Eles ajudam a garantir uma maior capacidade de manutenção, modularidade, organização de projetos e portabilidade, e os APIs que os suportam são excelentes candidatos à reutilização do código. Ainda assim, não sacrifique a arquitetura do aplicativo ou a capacidade de manutenção em nome da reutilização de código. Bibliotecas compartilhadas, técnicas de compartilhamento de código e padrões, como o MVVM (Model-View-ViewModel), certamente proporcionarão melhores resultados. Para obter mais informações sobre esses pontos, consulte o artigo de Doug Holland, “Estratégias de compartilhamento de código para Windows Store e aplicativos do Windows Phone” (msdn.microsoft.com/magazine/dn201744).

Recursos específicos à plataforma

Há inúmeros recursos cujo comportamento se assemelha ao do Windows 8 e do Windows Phone 8, mas implementados de maneiras distintas. Por essa razão, evite reutilizar códigos entre plataformas com certos processos e recursos, incluindo:

  • Ciclo de vida do aplicativo
  • Tarefas e contratos do sistema
  • Blocos
  • Notificações do sistema
  • Armazenamento local
  • Sistemas de rede
  • Processamento em segundo plano
  • Câmera
  • Barra de aplicativo

Ciclo de vida de aplicativos Embora haja fortes paralelos entre o ciclo de vida de aplicativos no Windows Phone 8 e no Windows 8, as duas plataformas apresentam diferentes APIs. Como podemos ver na Figura 3, os estados de alto nível do programa e o fluxo entre estados são semelhantes nas duas plataformas, porém os recursos no Windows Phone 8 são bem mais limitados e essa é a razão da maioria das diferenças no ciclo de vida. Em ambas as plataformas, apenas o aplicativo em primeiro plano consume recursos da CPU (exceto nas tarefas em segundo plano, que são gerenciadas pelo sistema operacional).

Windows Phone 8 and Windows 8 Lifecycles
Figura 3 Ciclos de vida do Windows Phone 8 e do Windows 8

A Figura 4 mostra as diferenças de comportamento do ciclo de vida entre as duas plataformas.

Figura 4 Diferenças entre os ciclos de vida do Windows Phone 8 e do Windows 8

Windows Phone 8 Windows 8
Os aplicativos do Windows Phone 8 são sempre inicializados e reinicializados. Os aplicativos da Windows Store são reiniciados sem navegação pela página.
O Windows Phone 8 pode excluir aplicativos. O Windows 8 suspende ou encerra totalmente os aplicativos. Os aplicativos da Windows Store suportam ativação por exibição hospedada, em que o aplicativo executa uma tarefa única no contexto da interface do usuário disponibilizada pelo sistema.
O Windows Phone 8 é compatível com reiniciação rápida de aplicativos O Windows 8 não necessita do recurso de Reiniciação rápida de aplicativos, pois os aplicativos são mantidos em um estado suspenso pelo tempo que for possível; de outra forma, seriam encerrados.

A Figura 5 mostra os namespaces em que residem os eventos do ciclo de vida do aplicativo.

Figura 5 Namespaces do ciclo de vida do aplicativo

Windows Phone 8 Windows 8
Deriva de: System.Windows.Application Deriva de: Windows.UI.Xaml.Application
Application_Launching  
Application_Activated OnLaunched
Application_Deactivated OnSuspending
Application_Closing  

Há diversos pontos de entrada de aplicativo em cada plataforma, conforme a Figura 6 mostra.

Figura 6 Pontos de entrada de aplicativos

Windows Phone 8 Windows 8 Ambos
Inicialização rápida Pesquise Bloco do aplicativo
Conexão com o aplicativo Compartilhar Blocos secundários
    Notificações
    Associações de arquivo e protocolo

Tarefas e contratos do sistema O Windows 8 e o Windows Phone 8 incluem suporte integrado para operações comuns envolvendo a coordenação com o sistema operacional. O Windows 8 trata dessas questões utilizando contratos, enquanto o Windows Phone 8 utiliza tarefas (como iniciadores e seletores). Contratos e tarefas oferecem recursos semelhantes ao usuário, porém o desenvolvimento é diferente. A funcionalidade exposta pelas plataformas não executa necessariamente um mapeamento individual; portanto, é necessário avaliar cuidadosamente as tarefas e contratos ao portar um aplicativo.

Os APIs de tarefa do Windows Phone 8 encontram-se no namespace Microsoft.Phone.Task: PhotoChooserTask, EmailAddressChooseTask, SaveContractTask e assim por diante. Por outro lado, os contratos do Windows 8 contêm APIs individuais relacionados aos painéis abertos por botões (painel de pesquisa, painel de compartilhamento e semelhantes); a declaração de suporte a contratos é feita no manifesto do aplicativo. Contratos são basicamente acordos e sua implementação envolve a substituição de métodos na classe de Aplicativo ou manipulando eventos nas classes na API do Windows.

Blocos Blocos são pontos de entrada da Windows Store e dos aplicativos do Windows Phone 8. Blocos primários simplesmente abrem aplicativos, enquanto os secundários são fixados na tela Iniciar; tratam-se efetivamente de um “link profundo” que pode levar o usuário a uma página específica do aplicativo. Ambas as plataformas são compatíveis com blocos dinâmicos nos quais o conteúdo é atualizado periodicamente, porém as APIs são totalmente diferentes. A Figura 7 descreve os blocos do Windows Phone 8 e do Windows 8.

Figura 7 Comparação entre blocos do Windows Phone 8 e do Windows 8

Blocos do Windows Phone 8 Blocos do Windows 8
Três tamanhos: pequeno, médio, grande Dois tamanhos: menor, maior
Blocos padrão, blocos móveis, blocos cíclicos e blocos icônicos (Microsoft.Phone.Shell) SecondaryTile pode ser personalizado usando modelos XML (Windows.UI.StartScreen)
Forneça imagens lado a lado no manifesto Forneça imagens lado a lado no manifesto
Crie blocos secundários usando o método estático ShellTile.Create Crie blocos secundários usando o método SecondaryTile.Re­­­questCreateAsync
Atualize blocos do aplicativo usando ShellTile.Update (Microsoft.Phone.Shell); envie notificações por push usando ShellTileSchedule (ShellTileToast também atualiza blocos) Atualize blocos do aplicativo usando TileUpdateManager e TileNotification (Windows.UI.Notifications)
O usuário pode desafixar o bloco do aplicativo O usuário pode desativar o bloco dinâmico

A Figura 8A e a Figura 8B mostram uma comparação entre códigos da criação de blocos secundários. No Windows Phone 8, a classe ShellTile disponibiliza uma interface estática para criação (e remoção) de blocos secundários. Isso pode ser obtido usando uma das diversas classes que encapsulam dados de um bloco: StandardTile, CycleTileData, FlipTileData ou IconicTileData. O Windows 8 contém apenas uma estrutura de dados para definir blocos secundários (SecondaryTile). A criação de blocos é feita por meio de uma solicitação assíncrona; nela, o usuário é questionado se deseja fixar o bloco na tela Iniciar.

Figura 8A Criação de blocos no Windows Phone 8

CycleTileData tileData = new CycleTileData()
{
  Title = item.Title,
  SmallBackgroundImage = new Uri(item.GetImageUri(),
    UriKind.RelativeOrAbsolute),
  CycleImages = list
};
ShellTile.Create(new Uri(navDataSource,  
  UriKind.Relative), tileData, true);

Figura 8B Criação de blocos no Windows 8

var tile = new SecondaryTile(
  item.UniqueId,      // Tile ID
  item.ShortTitle,    // Tile short name
  item.Title,         // Tile display name
  item.UniqueId,      // Activation argument
  TileOptions.ShowNameOnLogo, // Tile options
  uri                 // Tile logo URI
  );
await tile.RequestCreateAsync();

Notificações do sistema As notificações do sistema no Windows 8 são semelhantes os lembretes e alarmes do Windows Phone 8. Elas permitem que o aplicativo notifique o usuário sobre um evento em determinado horário. Clicar em uma notifica do sistema abre o aplicativo se estiver fechado e o reinicia se estiver suspenso.

O Windows Phone 8 é compatível com dois tipos de notificação: alarme e lembrete. O aplicativo pode exibir também notificações (mesmo no segundo plano) utilizando ShellToast. Os alarmes e lembretes encontram-se em Micro­soft.Phone.Scheduler, enquanto o ShellToast está disponível em Microsoft.Phone.Shell.

O Windows 8 utiliza notificações do sistema via ToastNotification­Manager e ScheduledToastNotification, disponíveis no namespace Windows.UI.Notifications, habilitadas por meio do manifesto do aplicativo.

Armazenamento local O namespace Windows.Storage disponibiliza um novo conjunto de APIs compartilhadas que cuidam do gerenciamento local de arquivos. No Windows Phone 8, System.IO.IsolatedStorage.IsolatedStorageFile oferece compatibilidade com versões anteriores do Windows Phone, porém seria aconselhável adotar as novas APIs. É possível usar serialização e Windows.Storage.ApplicationData.Current.LocalFolder para persistir dados do aplicativo no armazenamento local de aplicativos.

Ambas as plataformas são compatíveis com armazenamento de pares de chave/valor (configurações) e arquivos e pastas. Contudo, as APIs do Windows Phone 8 são um subconjunto das APIs completas e não oferecem suporte ao armazenamento de dados de roaming, ao armazenamento temporário de dados, às configurações locais ou às configurações de roaming. A Figura 9 é um resumo das opções de armazenamento de cada plataforma.

Figura 9 Opções de armazenamento no Windows Phone 8 e no Windows 8

Recurso e namespace Finalidade Windows Phone 8 Windows 8
Windows.Storage Armazenamento local de arquivos do aplicativo Sim Sim
System.IO.IsolatedStorage.Isolated­StorageFile Armazenamento local de arquivos do aplicativo Sim Não
Configurações de ApplicationData (LocalFolder) Armazenamento de chaves/valores Não Sim
System.IO.IsolatedStorage.IsolatedStorageSettings Armazenamento de chaves/valores Sim Não
SQL CE Banco de Dados Sim Não

Sistemas de rede A maioria dos aplicativos d pende grandemente dos recursos de Internet dos dispositivos nos quais residem para funcionar corretamente. No Windows 8 e no Windows Phone 8, esse recurso é declarado no manifesto. A Figura 10 mostra as APIs relevantes de rede.

Figura 10 Diferenças nas APIs de rede entre o Windows Phone 8 e o Windows 8

Windows Phone 8 Windows 8 Ambos

ConnectionManager

  • System.Net

NetworkInterface

  • System.Net.Net­work­Information

HttpWebRequest, HttpWebResponse

  • System.Net

DatagramSocket, StreamSocket

  • Windows.Networking.Sockets

Soquete (TCP ou UDP), StreamSocket

  • System.Net.Sockets
 

HttpClient

  • System.Net.Http

WebClient

  • System.Net
 

O Windows 8 apresenta o HttpClient, que atua como uma sessão enviando solicitações ao servidor (HTTP, GET, POST e PUT). Cada instância do HttpClient possui seu próprio pool de conexões a fim de evitar interferência externa. Os dados são retornados na forma de uma sequência de caracteres, HttpRequestMessage, fluxo ou matriz de bytes. 

Por outro lado, o WebClient não está disponível no Windows 8 (exceto em aplicativos de desktop). Ele é usado nos aplicativos do Windows Phone 8 e sua implementação é ligeiramente diferente do WebClient em versões anteriores do Windows. No Windows Phone 8, é possível também usar HttpWebRequest/HttpWebResponse com um invólucro assíncrono. No momento, há uma versão de lançamento de um HttpClient portátil disponível para ambas as plataformas. Você pode obter essa versão na galeria do NuGet.

Processamento em segundo plano Em algumas situações, será necessário executar códigos no segundo plano: Transmitir música, executar ping em um servidor para verificar se há atualizações, baixar arquivos, e assim por diante. Ambas as plataformas podem designar uma tarefa ao sistema operacional a ser executada na ativação de alguns disparos. Essas tarefas são independentes do aplicativo, sendo que o sistema operacional tem total controle sobre elas.

Pode haver apenas um agente no segundo plano por aplicativo, porém o agente em questão está apto a executar uma das ou ambas as tarefas:

  • Tarefas periódicos: tarefas curtas que o sistema operacional poderá executar a cada 30 minutos
  • Tarefas que demandam muitos recursos: tarefas mais longas executadas quando o telefone for conectado ou dispor de uma bateria totalmente carregada

A Figura 11 mostra o que é preciso para implementar tarefas executadas em segundo plano em ambas as plataformas. Observe que os aplicativos da Windows Store que utilizam tarefas executadas em segundo plano devem declarar esse fato no manifesto do aplicativo.

Figura 11 Usando tarefas executadas em segundo plano no Windows Phone 8 vs. Windows 8

Windows Phone 8 Windows 8

Derivar do BackgroundAgent ou de uma de suas subclasses:

  • Namespaces Microsoft.Phone e Microsoft.Phone.Scheduler
Windows.ApplicationModel.Background
Substitua o método OnInvoke e chame NotifyComplete ao concluir Implemente a interface IBackgroundTask e seu método de Execução
Verifique se a tarefa já não foi registrada Declare as tarefas executadas em segundo plano no manifesto: verifique se a tarefa já não foi registrada
Use ScheduledActionService para adicionar e remover agentes de segundo plano Use BackgroundTaskBuilder para criar e registrar uma instância da tarefa
  Manipule o evento BackgroundTask­Completed para obter dados da tarefa

Agora irei demonstrar como implementar uma tarefa executada em segundo plano, primeiramente no Windows 8 e depois no Windows Phone 8.

Veja a seguir as etapas de alto nível do Windows 8:

  • Implemente a interface IBackgroundTask e o método de Execução
  • Declare no manifesto o uso da tarefa executada em segundo plano
  • Verifique se a tarefa já não foi registrada
  • Use BackgroundTaskBuilder para criar e registrar uma instância da tarefa
  • Manipule o evento BackgroundTaskCompleted para obter dados da tarefa:
using Windows.ApplicationModel.Background;
namespace MyTaskExample
{
  public class SimpleBackgroundTask : IBackgroundTask
  {
    public void Run(IBackGroundTaskInstance task)
    {
      // Do stuff ...
    }
  }
}
  • Declare que o aplicativo utiliza uma tarefa executada em segundo plano:
<Extensions>
  <Extension Category="windows.backgroundTasks"
    EntryPoint="Tasks.MyTask">
    <BackgroundTasks>
      <Task Type="systemEvent" />
    </BackgroundTasks>
  </Extension>
</Extensions>
  • E verifique o registro:
foreach (var task in Background.BackgroundTaskRegistration.AllTasks)
{
  // Use if (task.Value.Name == taskName) to see if
  // the task has already been registered
}
// If not ...
var taskBuilder = new BackgroundTaskBuilder();
taskBuilder.Name = taskName;
taskBuilder.TaskEntryPoint = "Tasks.MyTask";
taskBuilder.SetTrigger(
  new SystemTrigger(SystemTriggerType.TimeZoneChange, false));
BackgroundTaskRegistration myTaskRegistration =
   taskBuilder.Register();

Veja a seguir as etapas de alto nível do Windows Phone 8:

  • Crie ScheduledTaskAgent (modelo de agente de tarefa programada do Windows Phone):
public class ScheduledAgent : ScheduledTaskAgent
{
  protected override void OnInvoke(ScheduledTask task)
  {
    // Write code here to perform task ...
    NotifyComplete();
  }
}
  • Verifique se a tarefa já foi programada para execução e, em caso negativo, crie uma nova tarefa: de outra forma, remova a tarefa existente (a tarefa programada per execução periódica por dez dias):
PeriodicTask task =
     ScheduledActionService.Find(taskName) as PeriodicTask;
   bool found = (task != null);
   if (!found)            
     task = new PeriodicTask(taskName);
   else
     ScheduledActionService.Remove(taskName);
   task.Description = description;
   task.ExpirationTime = DateTime.Now.AddDays(10);
   ScheduledActionService.Add(task);

Diferentemente do Windows 8, não há necessidade de declarar no manifesto o suporte dado às tarefas executadas em segundo plano.

Câmera O Windows Phone 8 e o Windows 8 oferecem suporte à captura de imagens e vídeo, porém, à semelhança dos demais recursos, as APIs são diferentes.

A captura de fotos no Windows Phone 8 é uma tarefa conduzida pelo sistema operacional. Você pode registrar um retorno de chamada para tratar do resultado quando o usuário sair da interface do usuário da câmera. O resultado pode ser ou não uma foto, por isso verifique antes de usar o produto final. A gravação em vídeo não é integrada à tarefa de captura da câmera, por isso requer-se mais trabalho.

O Windows Phone 8 inclui um recurso exclusivo de criação de aplicativos para câmeras chamado Lens (Lente). É possível também criar lentes de mídia avançada, o que proporciona uma experiência única na visualização ou edição de fotos. Além disso, a câmera pode ser usada como gateway para outras experiências. Por exemplo, aplicativos de leitura de códigos de barra utilizam a câmera para ler códigos de barra e exibir seus dados associados. Todas essas aplicações que utilizam lentes são possíveis utilizando extensibilidade de lente; isso permite partir diretamente do coletor de lentes para uma experiência de visor. É possível também usar APIs especiais para acessar o sensor da câmera de forma programática. Para obter mais informações, consulte “Extensibilidade das lentes no Windows Phone 8” (aka.ms/Vdgk8e) e “Capturando fotos para o Windows Phone” (aka.ms/Owcwpl) no Windows Phone Dev Center.

O Windows 8 utiliza CameraCaptureUI (Windows.Media.Capture) para fotos e vídeos. Isso requerer a ativação de uma Webcam e microfone no manifesto:

private async void OnCapturePhoto(object sender,
   TappedRoutedEventArgs e)
{
  var camera = new CameraCaptureUI();
  var file = 
    await camera.CaptureFileAsync(CameraCaptureUIMode.Photo);
  if (file != null)
  {
      // Do something with the result ...
  }
}

O Windows Phone 8 utiliza CameraCaptureTask (Microsoft.Phone.Tasks) para tirar fotos. Isso requer a habilitação de ID_CAP_ISV_CAMERA e ID_CAP_MICROPHONE no manifesto, conforme mostrado na Figura 12.

Figura 12 Habilitando ID_CAP_ISV_CAMERA e ID_CAP_MICROPHONE no manifesto do Windows Phone 8

private readonly CameraCaptureTask cameraTask;
public Init() {
  cameraTask = new CameraCaptureTask();
  cameraTask.Completed += PhotoCaptured;
}
public void TakePhoto() {
  cameraTask.Show();
}
private async void PhotoCaptured (object sender,
   PhotoResult result) {
  await Task.Run(() => {
    // Do something with the result...
  });
}

Barra de aplicativo As barras de aplicativo do Windows 8 são bem mais eficazes que as do Windows Phone 8. Ações comumente usadas, como adicionar, editar e excluir itens, podem ser inseridas na barra de aplicativo. O aplicativo poderá ser notificado quando o usuário abrir ou fechar uma barra de aplicativo manipulando os eventos Aberto e Fechado.

Há diferenças significativas na forma como a barra de aplicativo funciona em cada plataforma, conforme mostrado na Figura 13.

Figura 13 Diferenças na forma como a barra de aplicativo funciona no Windows Phone 8 e no Windows 8

Windows Phone 8 Windows 8
Uma barra de aplicativo na parte inferior da página Duas barras de aplicativo: uma na parte inferior e outra na superior

Apenas quatro itens permitidos

  • Insira itens adicionais no menu
  • Sem agrupamento

Comporta-se como qualquer contêiner

  • Nenhum menu
  • Pode agrupar itens em contêineres aninhados
Controle ApplicationBar em PhoneApplicationPage.ApplicationBar Controle AppBar em Page.BottomAppBar ou Page.TopAppBar
Defina o modo como Padrão para exibir a barra de aplicativo no carregamento da página Defina IsOpen como verdadeiro para mostrar a barra de aplicativo no carregamento da página
Defina IsMenuEnabled para habilitar o menu Defina IsSticky como verdadeiro para forçar una barra de aplicativo a sempre permanecer aberta

A declaração da barra de aplicativo no Windows 8 é mostrada na Figura 14. Observe que são usados dois painéis de pilha para agrupar os botões, sendo um grupo à esquerda e o outro à direita.

Figura 14 Declaração da barra de aplicativo no Windows 8

<Page.BottomAppBar IsOpen="True">
  <AppBar x:Name="bottomAppBar" Opened="AppBar_Opened" 
        Padding="10,0,10,0">
    <Grid>
      <StackPanel Orientation="Horizontal" 
        HorizontalAlignment="Left">
        <Button Style="{StaticResource TakePictureAppBarButtonStyle}"
          Click="TakePicture_Click"/>
        <Button Style="{StaticResource ShareTaskAppBarButtonStyle}"
          Click="ShareImage_Click"/>
      </StackPanel>
      <StackPanel Orientation="Horizontal" 
        HorizontalAlignment="Right">
        <Button Style="{StaticResource StartCoookingAppBarButtonStyle}"
          Click="StartCooking_Click"/>
        <Button Style="{StaticResource PinToStartAppBarButtonStyle}"
          Click="PinToStart_Click"/>
      </StackPanel>
    </Grid>
  </AppBar>
</Page.BottomAppBar>

A Figura 15 mostra a declaração da barra de aplicativo no Windows Phone 8 (observe que apenas quatro elementos ApplicationBarIconButton são permitidos no ApplicationBar do telefone, e os contêineres são inseridos no elemento ApplicationBar).

Figura 15 Declaração da barra de aplicativo no Windows Phone 8

<phone:PhoneApplicationPage.ApplicationBar x:name="ddd">
  <shell:ApplicationBar x:Name="bottomAppBar" IsVisible="True"
    IsMenuEnabled="True"  Mode="Default" Opacity="1.0">
    <shell:ApplicationBarIconButton x:Name="btnTakePicture"
      IconUri="/Assets/Icons/camera.png" 
      Click="btnTakePicture_Click" 
      Text="Take Picture"/>
    <shell:ApplicationBarIconButton x:Name="btnShareTask"
      IconUri="/Assets/Icons/share.png" 
      Click="btnShareShareTask_Click" 
      Text="Share Image"/>
    <shell:ApplicationBarIconButton x:Name="btnStartCooking"
      IconUri="/Assets/Icons/alarm.png" 
      Click="btnStartCooking_Click" 
      Text="Start Cooking"/>
    <shell:ApplicationBarIconButton x:Name="btnPinToStart"
      IconUri="/Assets/Icons/like.png" 
      Click="btnPinToStart_Click" 
      Text="Pin To Start"/>
  </shell:ApplicationBar>
</phone:PhoneApplicationPage.ApplicationBar>

Conclusão

Cada vez mais os consumidores esperam desfrutar de uma experiência contínua entre seus smartphones e outros dispositivos. A fundamento comum do Windows 8 e do Windows Phone 8 proporciona um nível satisfatório de reutilização ao criar soluções para as duas plataformas. Contudo, como vimos neste artigo, é importante reconhecer as principais diferenças nos dispositivos físicos e na forma em que os usuários interagem com eles, bem como as diferenças de suas APIs. Essas diferenças significam que os designers devem levar em conta a criação de interfaces do usuário e experiências do usuário distintas; por sua vez, isso quer dizer pouca ou nenhuma reutilização de XAML nas plataformas. Embora haja algumas APIs disponíveis para ambas as plataformas, como no caso do Windows.Store.StorageFile, muitos recursos são aparentemente semelhantes, mas implementados de maneira diferente. É o que acontece com os eventos do ciclo de vida, blocos, captura de mídia, tarefas e contratos, configurações, tarefas executadas em segundo plano e a barra de aplicativo.

Uma vez esclarecidas essas diferenças, é possível explorar com confiança as técnicas de reutilização de códigos multiplataforma, como as Bibliotecas de Classe Portáteis, os componentes do tempo de execução, e assim por diante. Para saber mais sobre essas técnicas, consulte o artigo de Doug Holland sobre compartilhamento de código que mencionei anteriormente, bem como o arquivo do Windows Phone Dev Center em aka.ms/sharecode. Faça também o download do código de exemplo demonstrando o compartilhamento em ação em aka.ms/gxcvq3.

Joel Reyes é um divulgador de tecnologia do Setor Público de Divulgação de Plataforma e Desenvolvimento (DPE) relacionado ao Windows Phone 8 e ao Windows 8. Você pode entrar em contato com ele pelo e-mail joel.reyes@microsoft.com.

Agradecemos aos seguintes especialistas técnicos pela revisão deste artigo: Andrew Byrne (Microsoft) e Matthias Shapiro (Microsoft)