Introdução
Quando realizamos o desenvolvimento de aplicações para o Windows Phone é extremamente comum a necessidade em realizar o consumo de dados externos, normalmente disponibilizados por meio de serviços.

Atualmente um padrão de mensagens que vem sendo adotado bastante a utilização do formato JSON (JavaScript Object Notation) para a troca de informações. O JSON basicamente é um formato leve e limpo para representação de dados.

É neste ponto que surgem muitas dúvidas dos desenvolvedores. Como trabalhar com JSON no .NET?

É muito mais simples do que parece, pois o .NET Framework oferece classes nativas para trabalhar com serialização e deserialização de JSON.

Criando seu aplicativo
Para demonstrarmos como é simples trabalharmos com JSON no .NET, iremos criar um exemplo que irá consumir a API do Twitter, que permite retornar JSON nativamente.

• Abra o Visual Studio 2010;
• Crie um projeto do tipo Windows Phone Application;
• Abra o arquivo MainPage.xaml, caso ele ainda não esteja aberto;
• Adicione os seguinte controles ao seu ContentPanel;
  

  <!--ContentPanel - place additional content here-->
  <Grid x:Name="ContentPanel" Grid.Row="1" Margin="12,0,12,0">
      <TextBox Height="72" HorizontalAlignment="Left" 
                  Margin="10,10,0,0" Name="txtUsername"
                  VerticalAlignment="Top" Width="287" />
              
      <Button Content="Pesquisar" Height="72" 
              HorizontalAlignment="Left" Margin="290,10,0,0" 
              Name="btnPesquisar" VerticalAlignment="Top" 
              Width="160" Click="btnPesquisar_Click" />
              
      <ListBox HorizontalAlignment="Left" 
                  Margin="24,88,0,0" Name="listBox1" 
                  VerticalAlignment="Top" Width="415">
                  
          <ListBox.ItemTemplate>
              <DataTemplate>
                  <StackPanel Orientation="Horizontal" Height="132">
                      <Image Source="{Binding user.profile_image_url}"
                              Height="73" Width="73"
                              VerticalAlignment="Top"
                              Margin="0,10,8,0" />
                              
                      <StackPanel Width="340">
                          <TextBlock Text="{Binding user.name}"
                                      Foreground="{StaticResource PhoneAccentBrush}"
                                      FontSize="18"
                                      FontWeight="Bold"/>
  
                          <TextBlock Text="{Binding text}"
                                      HorizontalAlignment="Left"
                                      Width="340"
                                      FontSize="20" 
                                      TextWrapping="Wrap" />
  
                      </StackPanel>
                  </StackPanel>
              </DataTemplate>
          </ListBox.ItemTemplate>
                  
      </ListBox>
  </Grid>

• Abra o Solution Explorer;
• Clique com o botão direito do mouse em seu projeto e selecione Add > Class;
• Defina o nome do arquivo para user.cs e clique em Add;
• No arquivo user.cs, altere a classe para que fique da seguinte maneira;
  

  public class user
  {
      public long id { get; set; }
      public string name { get; set; }
      public string profile_image_url { get; set; }
  }

• Adicione uma nova classe em seu projeto, chamada user_timeline e altere sua definição para;
  

  public class user_timeline
  {
      public long id { get; set; }
      public string text { get; set; }
      public user user { get; set; }
  }

• No Solution Explorer, clique com o botão direito do mouse em References > Add Reference;
• Na janela Add Reference, selecione o assembly System.ServiceModel.Web e clique em OK;
• Abra o arquivo MainPage.xaml.cs;
• No início do arquivo adicione a seguinte linha de código;
  using System.Runtime.Serialization.Json;
• Altere o método btnPesquisar_Click, incluindo o seguinte código;
  

  private void btnPesquisar_Click(object sender, RoutedEventArgs e)
  {
      WebClient twitter = new WebClient();
  
      twitter.DownloadStringCompleted += new DownloadStringCompletedEventHandler(twitter_DownloadStringCompleted);
  
      Uri uri = new Uri("http://api.twitter.com/1/statuses/user_timeline.json?screen_name=" + txtUsername.Text);
      twitter.DownloadStringAsync(uri);
  }

• Agora no método twitter_DownloadStringCompleted realize a leitura do retorno das informações;
  

  void twitter_DownloadStringCompleted(object sender, DownloadStringCompletedEventArgs e)
  {
      if (e.Error != null)
      {
          MessageBox.Show("Ocorreu um erro.");
          return;
      }
  
      string json = e.Result;
      Stream stream = new MemoryStream(System.Text.Encoding.UTF8.GetBytes(json));
  
      DataContractJsonSerializer serializer = new DataContractJsonSerializer(typeof(List<user_timeline>));
  
      List<user_timeline> resultado = (List<user_timeline>)serializer.ReadObject(stream);
      stream.Close();
  
      listBox1.ItemsSource = resultado;
  }

• Execute a aplicação;
• No campo texto, digite thiagojmonaco e clique no botão Pesquisar;
   

Conclusão
Como pudemos ver basciamente o processo para trabalhar com JSON é criar as classes de mapeamento das entidades, e utilizar a classe DataContractJsonSerializer de maneir simples, rápida e indolor . Até a próxima…

Uma super otimização de performance para o Windows Phone que pouca gente conhece é fazer com que as imagens utilizadas em seu aplicativo sejam decodificadas fora da thread de interface.

Por padrão, o windows phone faz o download da imagem em thread separada, mas assim que a imagem é retornada sua decodificação é feita na thread de interface, causando o bloqueio da mesma por alguns milissegundos.

Para realizar a decodificação também em outra thread, basta especificar o parâmetro CreateOptions de seu controle de imagem conforme o código abaixo:

   1:  <Image>

   2:      <Image.Source>

   3:          <BitmapImage UriSource="{Binding SuaUrl}" 

   4:                       CreateOptions="BackgroundCreation"/>

   5:      </Image.Source>

   6:  </Image>

Você vai sentir ainda mais a diferença quando estiver usando um ListBox com imagens, fazendo com que o scrolling fique muito melhor.

Por:

André Carlucci
@andrecarlucci
www.andrecarlucci.com

Bom pessoal, hoje escrevo o artigo em resposta a algumas dúvidas que vem surgindo.

Seria o início de uma fragmentação enorme do Windows Phone?

O que preciso fazer?

Devo pensar nesses celulares mais simples?

Em caso de dúvidas mais teóricas e muitas vezes mais filosóficas, sugiro conversarmos no www.rodolphomarques.com . Dê uma olhada nas colunas mensais que escrevo sobre Windows Phone lá, minha opinião, as informações que posso passar, e aí batemos um papo sobre isso. Aqui, nossa ideia será saber como fazer e o que muda.

Apenas uma rápida afirmação: SIM, você DEVE considerar esses telefones. Seja por termos um Nokia barato na jogada, o que deve massificar muito o uso, ou pelo fato de que esses telefones entrarão com tudo em mercados como China e Brasil, fato é, não desconsidere o fato de que aparelhos com 256MB existem. Você vai agradecer por pensar nisso!

O desenvolvimento para esses aparelhos foi adicionado no SDK 7.1.1 , o qual foi lançado em fevereiro. O Thiago escreveu um post sobre o que esse update contém. Clique aqui e leia o post.

Para nós, o que importa é: você quer que sua aplicação continue executando em qualquer Windows Phone que exista. Quanto mais gente tiver acesso ao seu app, melhor não?
Então as dúvidas são:

-Tendo um app já publicado, como ter certeza que ele funcionará nos novos aparelhos?

Vamos responder cada uma delas. Sempre lembrando, aqui estamos tratando de aplicativos XAML. Não entraremos em jogos. O link para saber mais sobre XNA é esse aqui

Se você já tem uma aplicação no Marketplace, você precisa

- Testar se sua aplicação não passa do limite de 90MB.
Sua app não pode usar mais do que esse valor, do contrário, ela não estará disponível para uso nesses aparelhos.
Para isso, você pode verificar usando o "Performance Analysis" no Visual Studio e testar seu aplicativo. Veja as duas imagens abaixo que mostram como acessar essa opção e executar seu aplicativo testando a memória utilizada pela mesma.

Dessa forma você pode entender o uso de memória, CPU, durante todo o ciclo da sua aplicação. Isso é bacana e bastante recomendado, para entender onde estão os pontos críticos, fazer um ajuste fino ou qualquer coisa que possa ajudar a experiência do usuário.

Uma forma fácil e direta para fazer esse teste dos 90MB é usar o MarketPlace Test Kit (botão direito em cima do projeto, Open Marketplace Test Kit). Essa tool fará os testes automatizados e irá informar se sua aplicação está ok quanto ao pico de memória.

-Validar cada chamada dos Background Agents e os bloquear em dispositivos com 256 MB

Em aparelhos como o Lumia 610 não é permitido o uso de Background Agents. Aliás, é a ÚNICA feature de desenvolvimento que não está habilitada para aparelhos 256. Então é o único ponto que realmente exige atenção. Caso você não os use, parabéns, só checar consumo de memória e seguir adiante. 
Sobre agentes, estamos falando tanto das tasks "periodic" quanto "resource intensive". Então, caso sua aplicação as use, seja para fazer update de tile, sincronização de dados, ou qualquer outro uso, você precisa remover o registro desses agentes nos aparelhos com 256MB. "Mas Rodo, eu quero poder continuar utilizando o recurso em todos os outros aparelhos MAS TAMBÉM disponibilizar meu app aos de 256MB"
É aqui que entra o ApplicationWorkingSetLimit, uma nova propriedade que, passada como parâmetro ao método DeviceExtendedProperties.GetValue entregará a quantidade de memória disponível e dará ao desenvolvedor opções de tratamento diferenciadas em cada caso.
No exemplo do Background Agents, iremos os registrar apenas caso estejamos trabalhando com aparelhos de 512MB.

  long result =
(long)DeviceExtendedProperties.GetValue("ApplicationWorkingSetLimit");

Caso o resultado acima seja menos do que 90MB (94371840), estamos falando de um aparelho 256MB. É necessário então não registrar agentes e , claro, importante tentar minimizar o uso de memória. Como já sabemos que nosso aplicativo executou o test kit e passou, apenas vamos adicionar código para registrar o agente somente em caso de aparelhos com 512MB:

  1:             Int64 ram = (Int64)DeviceExtendedProperties.GetValue("ApplicationWorkingSetLimit");

  2: 

  3:             if (ram < 94371840L)

  4:             {

  5:                 string textoAoUsuario = "Não é possivel registrar o Agente. Telefone não é compatível";

  6:             }

  7:             else

  8:                 RegistrarAgente();

Lembrando ainda que o telefone pode não ter sido atualizado. nesse caso a chamada acima gerará uma exceção, por conta do uso do ApplicationWorkingSetLimit. Um Try catch cai bem!


Caso você já tenha sua app, só precisa pensar nisso!

E caso esteja escrevendo um novo aplicativo, comece pensando nas duas questões acima.

Nos dois casos, mas principalmente quando for escever um novo aplicativo (onde ainda não tem a chance de fazer a execução do testkit), lembre..

-OTIMIZAR MEMÓRIA!
Para otimizar memória, lembre:
-Cuidados com uso de imagens, áudio, transições (alguns controles são realmente pesados).
-quando usar lista de dados, pense em virtualização e/ou melhores forma de utilização. não tente carregar uma longa lista toda de uma vez, trazendo muitos objetos do server ao telefone.
-teste, teste, teste. Temos acesso ao novo emulador de 256MB, caso não tenha um telefone para testes. Use o performance analysis, test kit.
 E, caso queira ler mais sobre o assunto performance, um link bom é esse aqui


Por fim, você ainda tema  chance de explicitamente optar por não distribuir seu aplicativo a esses novos aparelhos.
Para restringir esse seu aplicativo aos telefones como o Lumia 610 (o usuário será informado da restrição) é simples:

Vá ao seu arquivo WMAppManifest.xml(estará localizado no seu projeto Windows Phone, pasta Properties). Adicione, logo após a tag "Capabilities" o seguinte código:

  1: <Capability Name="ID_CAP_ISV_CAMERA" />

  2:       <Capability Name="ID_CAP_CONTACTS" />

  3:       <Capability Name="ID_CAP_APPOINTMENTS" />

  4:     </Capabilities>

  5:       <Requirements>

  6:           <Requirement Name="ID_REQ_MEMORY_90" />

  7:       </Requirements>

  8:     <Tasks>

  9:       <DefaultTask Name="_default" NavigationPage="MainPage.xaml" />

A TAG requirements, localizada entre as linhas 5 a 7 é o que é necessário para informar que seu aplicativo não estará disponível para aparelhos mais simples.


Bom, é isso. Lembre que, excluindo os Background Agents, o resto é apenas práticas de performance, que farão bem ao seu aplicativo em QUALQUER cenário. seus usuários agradecerão, com certeza.

E, se querem uma dica, não optem por bloquear seu aplicativo em dispositivos 256MB. O trabalho para adaptar, caso necessário, é pouco.. e valerá a pena!

Introdução
No último dia 27/02/2012 foi anunciado pela equipe de Windows Phone uma grande novidade, o suporte a dispositivos de baixo custo, sendo que o primeiro aparealho anunciado foi o Nokia Lumia 610. A ideia principal é conseguir ofecere a plataforma do Windows Phone em grandes mercados em crescimento, como China, Costa Rica, Israel,por exemplo, o que significa uma possibilidade de 60% de mercado para o Windows Phone.

Nokia Lumia 610

Novos Aparelhos
Como citamos, o Nokia Lumia 610 foi apenas o primeiro aparelho apresentado, mas podem esperar que muitos outros vão surgir, inclusive novas marcas. Algumas marcas que irão lançar dispositivos de baixo custo são: Acer, HTC, LG, Nokia, Samsung, Toshiba e ZTE.

Tenho certeza que estão se preocupando o que muda no Windows Phone para suportar esses novos aparelhos, correto?

A equipe de engenharia do Windows Phone tem trabalhado duro, para sempre oferecer uma plataforma ainda mais robusta, com grande experiência para os usuários, e isso não será diferente nesses novos dispositivos pois diversas otimizações foram realizadas no sistema operacional, como por exemplo, um suporte otimizado a paginação de dados em memória par que possa utilizar, automaticamente, a memória física do dispositivo para alguns armazenamento de informações. Com isso temos a garantia de compatibilidade com a grande maioria das aplicações que já estão publicadas no marketplace.

Vale lembrar que as grandes diferenças desses novos aparelhos são o processador de menor custo – Qualcomm 7x27a – e a quantidade de memória reduzida para 256MB.

Update do SDK
Uma novidade que também foi anunciada no mesmo dia, foi uma atualização no Windows Phone SDK, o chamado Windows Phone SDK 7.1.1 Update, que dará acesso ao emulador de aparelhos com 256MB, permitindo que sejam realizados testes das suas aplicações.

Um ponto importante é que até o momento, essa atualização do SDK trata-se de um Technical Preview, ou seja, ainda não é a versão final e pode sofrer atualizações até sua versão final. Além disso ela NÃO inclui uma licença “go live”, isso significa que ainda não é permitido publicar aplicações desenvolvidas com este SDK.

Então, caso queira realizar seus teste, baixe já o Windows Phone SDK 7.1.1 Update – CTP.

O que há de novo no SDK?
Resumidamente, as novidades do Windows Phone SDK 7.1.1 Update – CTP são as seguintes:

• Detectar Memória de Trabalho de Aplicação
  Foi adicionado um novo valor de propriedade de dispositivo, ApplicationWorkingSetLimit, que pode ser utilizado para detectar que a aplicação está sendo executada em um dispositivo de 256MB.
  
• Emulador 256MB
  Como já foi dito anteriormente o emulador de Windows Phone no SDK foi atualizado para permitir que sejam simulados dispositivos de 256MB.
  
• Framework XNA
  Os dispositivos com 256MB oferecem suporte total a XNA, no entanto ajustes de performance podem ser necessárias nas aplicações.
  
• Backgroun Agents
  Background Agents, de maneira geral, não são suportados em dispositivos com 256MB.
  
• Manifesto de Aplicação
  Apesar de os disposivitos 256MB oferecerem uma grande possibilidade de crescimento de mercado, pode ser que por algum motivo você não queira que sua aplicação seja distribuida neste tipo de dispositivo. Sendo assim, é possível definir no manifesto de sua aplicação que ela não pode ser executada em dispositivos com 256MB.
  
• Publicidade
  Utilizando o Microsoft Advertising SDK for Windows Phone, é possível ganhar dinheiro com suas aplicações e jogos por meio de propagandas fornecidas pelo Microsoft Advertising. Foi disponibilizado um novo SDK para que seja utilizado em suas aplicações.

Conclusão
O lançamento dos novos dispositivos é uma grande oportunidade que o Windows Phone possui para ganhar uma boa fatia do mercado existente, pois oferecerá uma quantidade maior de dispositivos e o mais importante, com preços atrativos e competitivos.

É claro que para isso as aplicações precisarão estar preparadas para isso. Por isso nos próximos artigos iremos abordar como preparar nosso código para os dispositivos de 256MB. Até a próxima…

Uma das primeiras dúvidas que surgem quando estamos utilizando MVVM é como mapear eventos da View para o ViewModel sem utilizar o code-behind. Há várias maneiras de se fazer isso e vamos explorar algumas delas neste post.

Para começar, crie uma aplicação em branco (Windows Phone Application).

1. Utilizando MvvmLight EventToCommand

Instale Mvvmlight em sua aplicação via nuget:

PM> install-package mvvmlight

O pacote do mvvmlight, além das suas dlls, já adiciona várias classes que vamos precisar em nosso exemplo. Vamos começar configurando o MainViewModel como DataContext da MainPage, assim temos para onde apontar nossos comandos. Adicione essa linha no cabeçalho da MainPage.xaml:

DataContext="{Binding Source={StaticResource Locator}, Path=Main}"

Dê um play para verificar se não há nenhum erro e vamos adicionar nosso comando. Abra o MainViewModel e modifique-o para que fique desta forma (não precisa modificar os “usings”):

 1: public class MainViewModel : ViewModelBase {

 2:  

 3:     public ICommand MostreMensagemCommand { get; set; }

 4:  

 5:     public MainViewModel() {

 6:         MostreMensagemCommand = new RelayCommand<string>(MostreMensagem);

 7:     }

 8:  

 9:     public void MostreMensagem(string mensagem) {

 10:         MessageBox.Show(mensagem);

 11:     }

 12: }

Na linha 3 estamos expondo o comando que deve ser chamado de nossa interface. Este comando simplesmente recebe um delegate para o método que realmente queremos invocar: MostreMensagem.

Agora abra o arquivo MainPage.xaml e modifique o grid “ContentPanel” para ficar assim:

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

 2:     <Button Content="Click me!">

 3:         <i:Interaction.Triggers>

 4:             <i:EventTrigger EventName="Click">

 5:                 <cmd:EventToCommand 

 6:                         Command="{Binding MostreMensagemCommand}" 

 7:                         CommandParameter="Hello Mvvmlight!"/>

 8:             </i:EventTrigger>                    

 9:         </i:Interaction.Triggers>

 10:     </Button>

 11: </Grid>

Não esqueça de adicionar também os namespaces:

xmlns:i="clr-namespace:System.Windows.Interactivity;assembly=System.Windows.Interactivity" 
xmlns:cmd="clr-namespace:GalaSoft.MvvmLight.Command;assembly=GalaSoft.MvvmLight.Extras.WP71" 

Veja que estamos utilizando um trigger que vai disparar quando o botão for clicado, chamando o comando MostreMensagemCommand presente no DataContext da View (no caso nosso MainViewModel) e por fim executando o nosso método MostreMensagem.

Dê play na aplicação e clique no botão para ver nossa mensagem:

Simples, não? Agora vamos ver como se faz isso usando puramente EventTriggers do Blend.

2. Utilizando o Blend InvokeCommandAction

Como o MvvmLight utiliza a dll do Blend System.Windows.Interactivity, ela já está adicionada em seu projeto se você seguiu os passos anteriores.

Esta mesma dll possui um trigger quase idêntico ao EventToCommand do Mvvmlight, chamado InvokeCommandAction. Para usá-lo, basta alterar o código do seu grid ContentPanel:

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

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

 3:     <Button Content="Click me!">

 4:         <i:Interaction.Triggers>

 5:             <i:EventTrigger EventName="Click">

 6:                 <i:InvokeCommandAction

 7:                         Command="{Binding MostreMensagemCommand}"

 8:                         CommandParameter="Hello Blend!" />

 9:             </i:EventTrigger>

 10:         </i:Interaction.Triggers>

 11:     </Button>

 12: </Grid>

O funcionamento vai ser idêntico ao do mvvmlight, dê play na aplicação e veja a nova mensagem.

3. Utilizando o Wp7Tools EventMapping

Apesar de gostar bastante do padrão, eu pessoalmente só utilizo comandos quando tenho que reaproveitar o mesmo comportamento em vários viewmodels.

Como a maioria das vezes eu criava um comando somente para repassar a execução a um método do viewmodel, sem mesmo utilizar o “CanExecute”, desenvolvi uma DependencyProperty para mapear eventos diretamente para actions.

Primeiramente, instale o Wp7Tools no seu projeto. O Wp7Tools é o framework que utilizo em todas as minhas aplicações e tem principalmente helpers para aumentar a testabilidade das mesmas. Você pode baixá-lo via nuget:

PM> install-package wp7tools

Adicione o namespace na MainPage:

xmlns:wp7="clr-namespace:Wp7Tools.Commands;assembly=Wp7Tools" 

E modifique o grid “ContentPanel” para ficar assim:

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

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

 3:     <Button Content="Click me!">

 4:         <wp7:Events.Mappings>

 5:             <wp7:Map Event="Click" ToMethod="MostreMensagem" WithParam="Hello Wp7Tools!" />

 6:         </wp7:Events.Mappings>

 7:     </Button>

 8: </Grid>

Por:

André Carlucci
@andrecarlucci
www.andrecarlucci.com