Hoje gostaria de compartilhar com vocês, a versão atualizada do Class Library Poster do Windows Phone OS 7.1. Tenho certeza que será útil para muitas pessoas.

 

Olá a todos, continuando a série de artigos, hoje vou falar sobre um dos novos templates disponíveis no Visual Studio para a versão Mango, o “Rich Graphics Application” (conhecido na versão beta anterior como “3d graphics application”), que permite ao desenvolvedor renderizar XNA e Silverlight na mesma aplicação. Até agora (versão 7.0) era possível escolher entre XNA ou Silverlight, e sim, até era possível algumas misturas, como utilizar a API de microfone ou touch input do XNA em uma aplicação Silverlight, mas na hora dos gráficos, você precisava escolher. Ou desenvolvia algo em XNA e teria complicações para renderização de texto, integração com IE, vídeos, etc.. Ou então partia para uma app Silverlight, mas tinha algumas dificuldades (e impossibilidades) de usar gráficos 3d ou mesmo criar “cenas” e loops bacanas em sua app. Agora o novo template permita que tudo seja feito em uma app só. É possível ter um xaml renderizando Silverlight, navegar para um segundo xaml renderizando apenas XNA e em um terceiro ter uma mistura dos dois. Vamos ver alguns pontos teóricos onde isso se torna possível

 

 

O TEMPLATE

Nos templates, verá que pode escolher o “Rich Graphics Application”. É o template que vou detalhar para vocês.

 

 

Figura 1 – o template

 

 

Ao criar o projeto, você verá algumas coisas interessantes. O projeto é composto por um MainPage.xaml que apenas tem um botão. Esse xaml, assim como essa aplicação, é Silverlight e exatamente o que já conhecemos como desenvolvedores Silverlight.

 

Figura 2 – a página inicial é XAML Silverlight que todos conhecemos

 

É importante que o desenvolvedor entenda que usar esse template significa criar uma aplicação Silverlight e adicionar uma renderização XNA onde desejar. Então todos os conceitos e estrutura continuam funcionando da mesma maneira. Teremos nosso app.xaml, MainPage.xaml, vamos seguir as lógicas e tudo que já existe no Silverlight.

A Mudança inicial vem quando você clica no botão. A aplicação navega para uma segunda página, GamePage.xaml, que será um xaml renderizando APENAS XNA. Ou seja, nesse momento o Silverlight ira sair de cena, o WP7 O.S. irá liberar o máximo possível de memória e trará o XNA para a tela. Legal, mas onde está meu conteúdo XNA? Olhando o solution explorer você entenderá

Figura 3 – Solution explorer com projeto XNA referenciado

 

Conforme você pode notar no Solution explorer, o XNA é adicionado como um projeto a parte e depois referenciado no projeto Silverlight. Então fica claro que estamos criando nossas texturas e o que precisarmos no XNA, depois o consumindo no Silverlight. Entenda como diversas camadas sendo “desenhadas” na tela. A figura abaixo mostra como isso acontece em uma tela renderizando Silverlight e XNA.

 

Figura 4 – as camadas em uma renderização XNA + SL

 

 

 

Legal, mas e como a página “GamePage” consegue renderizar XNA? E como é o código xmal dessa página?

Em uma página 100% renderizada em XNA não há código! O código completo do GamePage.xaml (no início e mesmo após você adicionar qualquer conteúdo XNA) é esse:

  1: <phone:PhoneApplicationPage 

  2:     x:Class="GraphicsApp1.GamePage"

  3:     xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

  4:     xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

  5:     xmlns:phone="clr-namespace:Microsoft.Phone.Controls;assembly=Microsoft.Phone"

  6:     xmlns:shell="clr-namespace:Microsoft.Phone.Shell;assembly=Microsoft.Phone"

  7:     xmlns:d="http://schemas.microsoft.com/expression/blend/2008"

  8:     xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"

  9:     FontFamily="{StaticResource PhoneFontFamilyNormal}"

 10:     FontSize="{StaticResource PhoneFontSizeNormal}"

 11:     Foreground="{StaticResource PhoneForegroundBrush}"

 12:     SupportedOrientations="Portrait" Orientation="Portrait"

 13:     mc:Ignorable="d" d:DesignHeight="800" d:DesignWidth="480"

 14:     shell:SystemTray.IsVisible="False">

 15:     

 16:     <!--No XAML content is required as the page is rendered entirely with the XNA Framework-->

 17: 

 18: </phone:PhoneApplicationPage>

 19: 

 

Ao verificar o code behind GamePage.xaml.cs você tem algumas coisas interessantes e diferentes do que está acostumado, como ContentManager, GameTimer , SpriteBatch ou SharedGraphicsDeviceManager. Mas antes de qualquer coisa, vamos explicar como o XNA renderiza.

Abrindo o arquivo app.xaml há um novo tag:

  1: <xna:SharedGraphicsDeviceManager />

É esse o responsável por fazer a mágica e trazer o XNA do nível mais baixo para a sua aplicação. Como o SharedGraphicsDeviceManager implementa a interface IApplicationLifetimeAware , você o verá como parte dos seus Application.ApplicationLifetimeObjects . Isso é o que possibilita renderizarmos XNA na nossa GamePage. É o SharedGraphicsDeviceManager que vai fazer o motor do XNA acontecer.

Bacana Rodo, mas e aí? Sei que “é possível” renderizar na página, mas aquele XAML não tem nada! Como é que estamos realmente “ligando” o XNA e colocando nosso conteúdo (seja ele qual for) para rodar na página?

Voltando ao code behind do “GamePage”, é importante sempre lembrar do nosso OnNavigatedTo , que é o evento que irá ser disparado quando a navegação chegar na página. Ou seja, toda vez que formos acessar a nossa GamePage, esse evento ocorre. Então, lá nesse evento, o seguinte código é adicionado:

 

  1:         protected override void OnNavigatedTo(NavigationEventArgs e)

  2:         {

  3: SharedGraphicsDeviceManager.Current.GraphicsDevice.SetSharingMode(true);

  4:             spriteBatch = new SpriteBatch(SharedGraphicsDeviceManager.Current.GraphicsDevice);

  5:             // aqui colocamos o código para carregar o conteúdo XNA que quisermos.

  6:             timer.Start();

  7:             base.OnNavigatedTo(e);

  8:         }

 

O código contém a grande mágica, que é a linha onde usamos o SharedGraphicsDeviceManager . É ali que estamos dizendo à aplicação que queremos usar o XNA. O método SetSharingMode nos permite isso. Após isso iremos usar o XNA para desenhar e carregar o que quisermos na tela, como por exemplo:

 

  1: ContentManager appContent = new ContentManager(app, "Content");

  2: fundo = appContent.Load<Texture2D>("background");

 

A segunda parte da mágica ocorre no evento OnDraw, que irá realmente montar os layers na tela. Lá é onde se tornará possível, por exemplo, ter código XAML sendo renderizado junto com o XNA.

 

  1: SharedGraphicsDeviceManager.Current.GraphicsDevice.Clear(Color.CornflowerBlue);

  2: spriteBatch.Begin();

  3: spriteBatch.Draw(background, Vector2.Zero, Color.White);

  4: spriteBatch.End();

 

Aqui limpamos o buffer e depois iremos colocar os layers na tela. Se fôssemos utilizar uma tela com XNA + Silverlight, precisamos explicitamente dizer que queremos renderizar o nosso Silverlight (imaginem que tenhamos adicionado código XAML para termos botões, grids, etc..). Como vocês viram, quando renderizamos XNA, não precisamos (nem iremos) ter nenhum código XAML. Quando adicionarmos código XAML para renderizar Silverlight em uma página, ele simplesmente não aparecerá se o seu SetSharingMode estiver como true. Para renderizar Silverlight + XNA é necessário usar o UIElementRenderer , que vai renderizar um UIElement qualquer do Silverlight junto com o XNA.

É O UIElementeRenderer que possibilita , então, a integração entre ambas as tecnologias. Os conceitos ficam mais ou menos divididos como SharedGraphicsDeviceManager permite que possamos acessar e ligar os motores do XNA em uma aplicação Silverlight, SetSharingMode é o cara que irá nos informar que desejamos renderizar XNA naquela página (e que queremos tirar o Silverlight de cena, por isso mesmo que tenhamos botões e controles Silverlight eles não irão aparecer) e o UIElementeRenderer é o que possibilitará a renderização de ambas as tecnologias. É com esse cara que iremos unir nossos layers, criar as camadas e as desenhar na tela como algo único para o usuário final.

No código acima, por exemplo, iríamos simplesmente adicionar mais uma linha de “Draw” para o Silverlight, montando nossos layers da forma como preferirmos. Se você “desenhar” o XNA primeiro, ele aparece por baixo do Silverlight, e vice versa.

Espero que essa explicação de conceitos do novo template tenha os ajudado um pouco a entender esse que é um dos novos conceitos do mango e que causam um pouco de confusão. Acredito que nesse assunto o mais complicado, muito mais do que entender códigos e demos, é entender como XNA + SL funcionam juntos e, mais do que isso, qual a necessidade do template.

Devo admitir que o código envolvido para fazer as tecnologias se conversarem é simples e a parte complexa fica para o XNA, o qual demanda uma veia artística que esse que vos fala inclusive não possui. O grande porém é que, apesar de simples, são conceitos um pouco diferentes e que demandam entender algumas coisas diferentes do que estamos acostumados a ver no Silverlight. Mas nada que uma demo simples caseira com quadrados e circunferências não resolva! Faça o teste e me conte!

Abraços!

Introdução
Desde o anúncio oficial, realizado pela Microsoft, sobre a próxima grande atualização para o Windows Phone, codinome Mango, muitos desenvolvedores estão procurando se atualizar tecnicamente e também atualizar seus aplicativos.

O objetivo de nosso artigo é apresentar de maneira simples, quais são os pontos de compatilidade de aplicação existentes entre as versões do Windows Phone.

Versões existentes
Até o presente momento temos as seguintes versões:

Release	Versão do SO
Windows Phone 7	Windows Phone OS 7.0
Windows Phone 7 – Codinome “Mango”	Windows Phone OS 7.1

SDK do Windows Phone
Com a liberação do Windows Phone SDK 7.1 Beta 2, disponível para download no site http://create.msdn.com, é possível realizar o desenvolvimento de aplicação para o Windows Phone OS 7.0 e para o Windows Phone OS 7.1. Um ponto muito importante de ressaltarmos é que aplicativos desenvolvidos com base no Windows Phone OS 7.0, executará em ambas as versões do OS, porém aplicativos desenvolvidos para o Windows Phone OS 7.1, executarão apenas nesta versão do OS.

Outro ponto importante está relacionado a compatibilidade nas ferramentas de desenvolvimento, conforme a seguinte tabela:

Versão do SDK	Versão da aplicação – OS	Criar ou abrir projetos	Distribuir ou depurar projetos	Funcionalidades do Windows Phone OS 7.1
7.0	7.0	Sim	Sim	Não
7.0	7.1	Não	Não	Não
7.1	7.0	Sim	Sim	Não
7.1	7.1	Sim	Sim	Sim

Conclusão
Estes são alguns dos pontos iniciais relacionados a compatibilidade de aplicações entre as versões do Windows Phone. Existem outras questões que estão relacionadas diretamente à bibliotecas, e formas de desenvolvimento de aplicações que iremos abordar posteriormente. Até a próxima…

 

Bem pessoal, continuando a série de artigos, hoje vamos falar sobre execução de áudio no background. Um assunto importante para os desenvolvedores que trabalham com o Windows Phone, pois, apesar de já ser possível hoje integrarmos aplicações de terceiros com o hub Music + Videos e fazer uso de algumas ferramentas interessantes, não é possível rodar áudio no background, ou seja, se sua aplicação utiliza áudio internamente, não através do hub de música, assim que o usuário deixa a aplicação, o áudio não está mais disponível.

Para o Mango update, temos alguns novos templates, que você conheceu na parte 1. Um deles é o Windows Phone Audio Playback Agent, que irá nos possibilitar executar músicas que estão no Isolated Storage ou remotas, e que iremos conhecer hoje.

Mãos a obra!

O TEMPLATE

Como comentado no artigo anterior, o template Windows Phone Audio Playback Agent é um dos quatro novos templates disponíveis no Update Mango. Eles se juntam aos templates antigos para oferecer novas possibilidades ao desenvolvedor. O template que trabalharemos é responsável por todo o trabalho pesado de execução do áudio no background, usando o novo conceito de “agentes” (Background Agents). Desse template iremos gerar uma dll , que será referenciada e consumida em um projeto de aplicação Windows phone 7.

CRIANDO O PROJETO

Para começar, crie um novo projeto do tipo Windows Phone Audio Playback Agent no seu Visual Studio 2010.

 

 

 

O projeto, ao ser criado, já conta com uma classe AudioPlayer, que faz parte do novo namespace Microsoft.Phone.BackgroundAudio e herda da classe AudioPlayerAgent (que por sua vez herda de BackgroundAgent, mas está fora do nosso escopo), e essa é a classe que fará o trabalho sujo. Alguns eventos já estarão prontos e faremos um player muito simples, que apenas tocará a música, ou seja, Play e Stop. A idéia do artigo é apenas didática, mas um exemplo com mudança de faixas não adiciona complexidade nenhuma, pois envolve apenas algumas regras básicas de contadores e um pouco mais de código. Outro ponto importante é que não estamos utilizando uma classe “music” ou algo do gênero, com melhores práticas, mas que ocuparia muito espaço por aqui. Quem desejar saber mais ou ter um exemplo mais completo, entrem em contato ou acessem meu blog pessoal, pois escrevi esse exemplo em alguns webcasts e posso repassar a vocês O vídeo ou mesmo outros exemplos.

Primeiro passo, vamos escrever um método que tocará nossa música.

  1:         private void PlayMusic(BackgroundAudioPlayer player)

  2:         {

  3:             player.Track = new AudioTrack(new Uri("Stellar.wma",UriKind.Relative)

  4: , "Stellar", "Debutantes99", "Tempestade", null);

  5: 

  6:             player.Play();

  7:         }

  8: 

No exemplo, estamos usandoa instância de player que iremos receber por parâmetro e a propriedade Track (do tipo AudioTrack e que contém as informações da música executada) está sendo populada. Instanciamos uma nova AudioTrack, na ordem dos parâmetros, com a localização, nome, artista, álbum e imagem de capa.

Para que possamos saber como e qual música tocar quando o usuário desejar, e como fazer o Play/Stop, precisamos de código no evento “OnUserAction“, que já estará no arquivo AudioPlayer.cs. O bacana é que você verá inclusive um comentário sobre a necessidade de adicionar código para o handle da ação do usuário. É aqui que iremos chamar no método PlayMusic criado no código anterior. Faça o override, adicionado:

  1: switch (action)

  2: {

  3: case UserAction.Play:

  4: PlayMusic(player);

  5: break;

  6: case UserAction.Stop:

  7: player.Stop();

  8: break;

  9: }

Pontos importantes: a ação Play irá nos levar ao nosso método, já com o Stop estamos utilizando o evento padrão. O caminho é o seguinte: Usuário clica em Play na tela, a classe Audio Player será executada, o evento acima chamado e, por último, nosso PlayMusic é executado.

Pronto. Para uma aplicação simples com Play e Stop é tudo que criaremos nesse projeto. Agora precisamos o referenciar e escrever nosso código na tela.

ADICIONANDO O PROJETO WINDOWS PHONE APPLICATION

Crie um novo projeto Windows Phone Application. Tela mais simples possível, apenas para verificar o processo de execução de áudio.

Adicione a referência ao projeto. Botão direito, add reference, projects e selecione nosso projeto de background criado anteriormente.

 

 

Seu arquivo de música deve ser adicionado ao projeto. Após adicionar um arquivo existente de música, botão direito, properties, mude o build action para “content”, conforme figura abaixo.

 

 

Não esqueça que, caso esteja usando Isolated Storage, o arquivo precisa ser adicionado, caso contrário, o processo não funciona. O passo não está mostrado aqui, mas adicione a música como sendo um arquivo qualquer de Isolated Storage. Mais um ponto importante, estamos utilizando apenas uma página, sem o conceito de MVVM aplicado. É importante que estude o pattern e possa aplicar em soluções reais.

Após isso, precisamos apenas criar os botões na tela e chamar nosso projeto de áudio. No MainPage.xaml adicione dois botões dentro do grid Content Panel. Também adicione um TextBlock, que irá mostrar ao usuário qual é a música sendo executada. O seu código ficará assim:

  1: <!--ContentPanel - place additional content here-->

  2: <Grid x:Name="ContentPanel" Grid.Row="1" Margin="12,0,12,0">

  3:   <StackPanel>

  4:     <TextBlock x:Name="currentMusic" Foreground="{StaticResource PhoneAccentBrush}" Height="50" FontStyle="Italic"></TextBlock>

  5:     <Button Content="TOCAR" x:Name="btnPlay" Click="btnPlay_Click"></Button>

  6:     <Button Content="STOPAR" x:Name="btnStop" Click="btnStop_Click"></Button>

  7:   </StackPanel>

  8: </Grid>

  9: 

 

Duplo clique nos botões e você irá gerar o evento de ambos. A listagem abaixo mostra o código do arquivo MainPage.xaml.cs:

  1: public partial class MainPage : PhoneApplicationPage

  2:     {

  3:         // Constructor

  4:         public MainPage()

  5:         {

  6:             InitializeComponent();

  7: 

  8:             BackgroundAudioPlayer.Instance.PlayStateChanged += new EventHandler(Instance_PlayStateChanged);

  9:         }

 10: 

 11:         protected override void OnNavigatedTo(System.Windows.Navigation.NavigationEventArgs e)

 12:         {

 13:             if (BackgroundAudioPlayer.Instance.PlayerState == PlayState.Playing)

 14:             {

 15:                 this.currentMusic.Text = BackgroundAudioPlayer.Instance.Track.Artist + " - " + BackgroundAudioPlayer.Instance.Track.Title + " from album " + BackgroundAudioPlayer.Instance.Track.Album;

 16:             }

 17: 

 18:         }

 19: 

 20:         void Instance_PlayStateChanged(object sender, EventArgs e)

 21:         {

 22:             AudioTrack track = BackgroundAudioPlayer.Instance.Track;

 23:             

 24:             if (track != null)

 25:             {

 26:                 this.currentMusic.Text = track.Artist + " - " + track.Title + " from album " + track.Album;

 27:             }

 28:         }

 29: 

 30:         private void btnPlay_Click(object sender, RoutedEventArgs e)

 31:         {

 32:             BackgroundAudioPlayer.Instance.Play();

 33:         }

 34: 

 35:         private void btnStop_Click(object sender, RoutedEventArgs e)

 36:         {

 37:             BackgroundAudioPlayer.Instance.Stop();

 38:         }

 39:     }

Pontos importantes a destacar:

- O event handler no construtor, para que possamos obter a faixa quando o usuário a executar e enviar a mesma ao tetblock.

-O override do OnNavigatedTo. Esse evento é executado quando a navegação vem para a página atual, ou seja, sabemos que o evento rodará quando nosso MainPage for acionado. Dessa forma, vamos tentar obter a música tocando, se o player estiver sendo executado, iremos adicionar os dados ao TextBlock. Isso é importante, pois como nosso áudio funcionará no Background e aplicação pode não estar mais sendo executada (mas o áudio sim), ao voltarmos a ela quero que o texto mostre qual a música atual.

-Os eventos de play e stop nada mais são do que chamadas ao BackgroundAudioPlayer. Mas e quanto aos nossos métodos e eventos criados no projeto anterior? Lembre-se que o que fizemos foi um override no evento que define mudanças de ação do usuário, ou seja, na hora que tivermos um Play por parte do usuário, o OnUserAction será disparado, iremos ver que é um Play e nosso método PlayMusic será executado, fechando o ciclo.

Ao executar a aplicação, temos o resultado:

 

CONCLUSÃO

Nesse artigo podemos ver como é fácil na versão Mango rodar um áudio no background, utilizando o poder do framework e do novo template. Temos disponível, assim como o Play e Stop mostrado, o método de Pause, Skip, etc, sendo extremamente fácil adicionar essas funções. Sigam o que viram aqui, criem suas classes para conter uma lista de músicas que desejam executar, utilizem o padrão MVVM para ter um modelO e também código separado da interface, e criem os players dentro da aplicação de forma fácil. Em caso de dúvida, entrem em contato!

LINKS ÚTEIS

MSDN Library
http://msdn.microsoft.com/en-us/library/ff402529(v=VS.92).aspx

 
Podcast Windows Phone
http://www.conexaowindows.com

Blog pessoal
http://www.rodolphomarques.com

Olá a todos, hoje iniciamos uma série de artigos para mostrar as novidades no desenvolvimento para Windows Phone 7. O foco desse conjunto de textos será apresentar o que mudou nas tools, o que o desenvolvedor pode esperar de novo utilizando a versão 7.1 do ferramental de desenvolvimento. De qualquer forma, sei que muitos estão iniciando o desenvolvimento agora, especialmente por conta do lançamento no Brasil, então iremos mostrar todo o processo de download, onde cada ferramenta se enquadra, e aí partiremos para novidades bacanas, como novas formas de utilização da câmera, localização no emulador, novos tiles, SQL CE, entre outros artigos. Para quem está familiarizado com o desenvolvimento, espero poder acrescentar com as novidades. Para quem é novo, não se preocupe, pois o foco é nivelar todos para que possamos ter cada vez mais adeptos do desenvolvimento para a belíssima plataforma que é o WP7!

Mãos a obra!

 

FAZENDO O DOWNLOAD DAS FERRAMENTAS

O desenvolvimento para o Mango continua funcionando da mesma forma. Ou seja, é muito fácil começar a desenvolver, tudo que você precisa é ir ao APP HUB ( http://create.msdn.com ) e fazer um download único. Esse download irá deixar sua máquina 100% pronta mesmo que estejamos falando de uma máquina nova (é importante frisar, para quem já está trabalhando com desenvolvimento para WP7, que a Microsoft recomenda a instalação das tools 7.1 Beta em uma máquina diferente da que possui a instalação atual).

Figura 1 . Fazendo o download no site APP HUB

Figura 2 . A instalação é feita via download único.

 

Após o download, será instalado na sua máquina:

1-Visual Studio 2010 Express For Windows Phone

A IDE de desenvolvimento para Windows é e continua sendo a já famosa IDE da Microsoft. Para o Mango, a versão do Visual Studio continua sendo a mesma e o melhor de tudo, 100% gratuita. Não se enganem com o “Express” do nome, qualquer aplicação que possa fazer em versões mais completas pode ser criada aqui. Aliás, sempre importante lembrar, mas caso você já tenha uma versão do Visual Studio mais completa instalada, os templates para desenvolvimento do WP7 serão adicionados a sua IDE.

2-Expression Blend 4 For Windows Phone

A melhor companhia para o Visual Studio na hora de criar visuais ricos e animações. O Expression Blend permite importação e exportação de projetos do Visual Studio, tornando fácil para criar um design rico e facilitado pelas ferramentas presentes no Expression Blend, e depois migrar o projeto para o Visual Studio e escrever a aplicação propriamente dita. Esse processo pode ser usado inúmeras vezes, de acordo com a necessidade.

3-O emulador

O emulador torna fácil e barato o desenvolvimento de aplicações para Windows Phone 7. Não há a necessidade de que você tenha um aparelho (apesar de ser aconselhável) para desenvolver sua aplicação. O emulador do Mango vem com diversas novas funcionalidades para testar acelerômetro, localização, entre outras novidades.

4-XNA Game Studio e Silverlight for Windows Phone

O framework para criar jogos e o Silverlight for Windows Phone (que agora na versão Mango é baseado no Silverlight 4) também já são instalados. Aqui temos inúmeras situações novas e bacanas, que vamos detalhar mais nos próximos artigos.

Após o download finalizado, você pode clicar no Visual Studio para verificar os projetos de Windows Phone que podem ser criados. Na inicialização da IDE você verá que pode utilizar C# ou VB.NET (os templates para trabalhar com ambas as linguagens estão disponíveis) e para quem já vinha trabalhando com WP7, temos alguns novos templates que detalhamos a seguir.


Figura 3 . O Novo Visual Studio Express For Windows Phone

 

Figura 4 . Ao criar novo projeto, agora escolhemos qual a versão da plataforma

 

Figura 5 . O novo conjunto de templates Silverlight for Windows Phone

 

Os templates para desenvolvimento são:

Windows Phone Application (também disponível anteriormente): Um template que criará uma aplicação em branco, apenas com o xaml inicial e sem nenhum controle embutido. Ideal para começar a aplicação do zero e ter liberdade de escolha.

Windows Phone Databound Application (também disponível anteriormente): Nesse template já temos um Listbox e uma página de detalhes sendo acionada por evento do controle da página principal, ou seja, uma solução que facilita um pouco o desenvolvimento de uma aplicação que conterá uma lista de dados e detalhamento de cada um.

Windows Phone Class Library (também disponível anteriormente): Uma biblioteca de classes, que irá compilar como uma DLL que pode ser redistribuída pelo desenvolvedor.

Windows Phone Panorama Application (também disponível anteriormente): O panorama Application já montará o projeto utilizando o controle Panorama e também montará a base para que seu projeto use o pattern MVVM.

Windows Phone Pivot Application (também disponível anteriormente): O Pivot Application funciona da mesma forma que o Panorama, apenas utilizando o Pivot ao invés do controle Panorama.

Windows Phone 3D Graphics application (NOVIDADE!!!!!!!!): Esse template permitirá a incorporação de conteúdo Silverlight e XNA na mesma aplicação (há um novo template de projeto XNA com a mesma finalidade, mas não é o escopo dos artigos). Esse template criará uma página que suportará renderização de conteúdo XNA. Iremos falar mais sobre o template em breve aqui no blog.

Windows Phone Audio Playback Agent (NOVIDADE!!!!!!!): Novo template que na verdade funciona como uma biblioteca de classes, mas habilitado para poder tocar arquivos de áudio (permitido a partir do Mango para aplicações desenvolvidas por nós!) usando o novo conceito de “agentes” (Background Agents). Falaremos muito ainda sobre Background Agents, já que é uma solução muito interessante, viabiliza o multitask e que ainda assim trabalha de uma forma a economizar bateria. O projeto gerará uma DLL que pode ser posteriormente referenciada.

Windows Phone Audio Streaming Agent (NOVIDADE!!!!!!): Novo template que funciona como o Phone Audio Playback, mas com o intuito de suportar streaming de áudio. Gera uma DLL na compilação e também utiliza o conceito de Background Agent.

Windows Phone Task Scheduler Agent (NOVIDADE!!!!!!!!): Assim como os dois anteriores, também uma biblioteca de classes , porém nesse caso utiliza o conceito de Background Agent para fazer alguma tarefa de background. Imagine que sua app precisa atualizar a cada 30 minutos, é aqui que o trabalho será feito. Sim, é aqui que a magia do multitask vai se tornar real no WP7. Mas não se engane em achar que isso é como um serviço de background do Windows e que a Microsoft está voltando aos tempos de Windows Mobile, as regras são rígidas para uso dos agentes, quantidade de vezes que rodará e quanto tempo sua atualização pode ficar rodando esse agente.

Antes de concluirmos, gostaria apenas de comentar um pouco mais sobre as novidades que o emulador sofreu. Além de termos como usar alguns dos novos recursos do Mango (Bing Voice, por exemplo, está lá), o emulador agora conta com algo chamado “Additional Tools”, que são ferramentas para que possamos utilizar Localização e/ou acelerômetro, por exemplo. Então aquela sua aplicação que mexia algo na tela através do acelerômetro , ou mesmo aquela utilização do Bing Maps pegando sua localização atual e que era complicadíssimo para testar, tendo que adicionar código de teste, agora é simples com o novo emulador!

Figura 6 . Additional Tools, novidade no emulador

 

Bom, espero que com isso possamos ter uma visão do que vem por aí no Mango. A partir daqui vou começar a fazer diversos artigos curtos mostrando as novidades uma a uma, os novos templates, ajudando assim quem está começando agora e também melhorando o conhecimento de quem já está com o WP7 desde o 7.0.

Posso afirmar, mesmo com o pouco tempo de Mango Tools na mão, que temos MUITAS novidades e que o WP7 está vindo com tudo. A atualização é gigantesca e tem muita coisa nova em cima de uma plataforma que já era bem bacana!

Vale a pena estudar e dedicar-se, o Windows Phone 7 veio para ficar!!