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

Para armazenar e recuperar dados em um banco de dados local as aplicações Windows Phone utilizam LINQ to SQL. O LINQ to SQL é um recurso nativo do Framework 3.0 e foi um dos recursos que mais chamaram atenção no lançamento do Microsoft Visual Studio 2008. O LINQ to SQL, como já dito em outros posts, fornece mapeamento objeto-relacional entre a aplicação e bancos de dados relacionais, além disso é um recurso extremamente poderoso, que permite a construção de consultas utilizando sintaxe C# e VB.Net.

O Windows Phone 7.5 utiliza como base de dados o Local Database, versão compacta do famoso banco de dados Microsoft SQL, e própria para dispositivos móveis.

Aqui vamos apresentar o exemplo de uma aplicação que armazena e remove dados do Local Database, utilizando como plataforma o Windows Phone 7.5.

1^o - Crie a aplicação utilizando o template Windows Phone Application.

2^o - Ao ser perguntado sobre a versão da plataforma Windows Phone, selecione a opção Windows Phone OS 7.1.

3^o - Dentro do projeto crie três pastas, sendo elas: DAO, Controller e Model.

4^o - Faça referência a DLL System.Data.Linq.

5^o - Dentro da pasta Model, criada anteriormente, crie a classe DataItem conforme a imagem a seguir.

6^o - Adicione os atributos de mapeamento objeto-relacional LINQ para criar o mapeamento entre a classe e a tabela do banco de dados do Local Database. Faça referência ao namespace System.Data.Linq.Mapping.

7^o - Dentro da pasta DAO crie uma classe chamada DataBaseContext, e a faça herda DataContext, classe presente no namespace System.Data.Linq. Esta classe será nosso data context e será responsável por fazer a ponte entre a aplicação e o banco de dados. Dentro da classe crie um atributo público chamado DataItems e que seja do tipo Table<DataItem>, este atributo representará nossa tabela no banco de dados. A classe DataBaseContext deverá se parecer com a seguinte implementação:

8^o - Agora que temos nossa entidade e nosso data context, devemos criar uma classe que encapsule os comando com o banco de dados, por isso criaremos dentro da pasta DAO a classe DAOProvider. Esta classe representará nossa camada de acesso a dados e encapsulará os comandos feitos para o banco de dados. Nesta classe implementaremos quatro métodos, sendo eles: CreateDataBase, método que criará a base de dados; GetDataItems, método que retornará todos os dados que estiverem no banco de dados; Save, salva novos registros na base de dados; Remove, remove os dados do banco de dados. A implementação funcionará da seguinte forma:

9^o - Para intermediar as chamadas entre a camada de visão e o repositório criaremos uma classe de controle que faça chamadas ao repositório. A vantagem de utilizar este tipo de classe é a possibilidade de encapsultar o repositório e poder adicionar filtros que intermediem o acesso aos dados do banco de dados. Esta classe deverá ser implementada como demonstrado a seguir:

10^o - Finalmente vamos construir a interface do nosso aplicativo. Esta será uma interface bastante simples, deverão ser adicionados os seguintes itens: um textbox, um listbox e um botão (mais detalhes do layout poderão ser vistos no link para o download do exemplo, pois o layout do projeto não é o objetivo deste post).

11^o - O único detalhe importante do layout é o modo como será feito o bind do listbox, pois na verdade ele será populado "na mão", isto é, os itens serão adicionados um-a-um (em um próximo post veremos como fazer isso de modo automático). Segue detalhe do XAML descrevendo o bind do listbox.

12^o - A lógica da camada de visão deverá funcionar como o código apresentado a seguir. Como pode ser observado no código, ao clicar no botão Salvar um novo registro será incluso na base de dados, e ao clicar sobre qualquer item do listbox, o mesmo será removido do banco de dados.

Esta é uma introdução ao acesso a dados utilizando o Windows Phone 7.5 e o recurso de Local Database. Espero que este post sirva como introdução para todos, e também espero que motive a construção de novos aplicativos para esta nova plataforma.

Para o download do exemplo acesse esse link: http://code.msdn.microsoft.com/Windows-Phone-Mango-e-SQL-81f15d55

[]s!

Por
Fernando Henrique Inocêncio Borba Ferreira
Microsoft Most Valuable Professional - Data Platform Development