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.

image

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…

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.

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

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

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


 

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

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

6o - 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.

7o - 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:

8o - 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:

9o - 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:


10o - 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).

11o - 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.

 

12o - 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

Bom pessoal, hoje um artigo para mostrar algo que é bem simples, mas que tem gerado muitas dúvidas no pessoal.

Tenho recebido muitas dúvidas e questões relacionadas a nuvem e ao SkyDrive. Talvez por envolver diferentes APIs e o nome assuste, não sei, mas fato é que parece ser muito mais complexo do que é.

Vamos mostrar hoje como salvar alguma informação da sua aplicação em um arquivo no SkyDrive. Da mesma forma podemos obter a lista de folders na aplicação ou mesmo trabalhar com outros aplicativos Live. Mas hoje o foco é backup na nuvem.

 

Para trabalhar com SkyDrive (e outrs soluções Live) em seu aplicativo Windows Phone, você precisa do SDK da Live para começar. Vá para http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=28195 e faça o download.


 

 

Após isso, adicione as referências ao seu aplicativo:

 

 

 

 

Pronto, agora é só implementar o código!

Para começar, precisamos colocar em algum local do aplicativo um botão para que o usuário possa se logar ao SkyDrive (no caso, o Live ID).

Você pode arrastar/usar o controle SignInButton , que irá encapsular todas as chamadas REST e o processo OAuth necessárias para que o usuário consiga fazer o login.

 

 

 

O código xaml do controle ficará assim:

  1: <my:SignInButton x:Name="skyDriveLogin" ClientId="xxxxxxxxx" 
  2: Scopes="wl.signin wl.basic wl.skydrive wl.skydrive_update" 
  3: Branding="Windows"  TextType="Login" SessionChanged="skyDriveLogin_SessionChanged" 
  4: RedirectUri="" />

 

O ClientID na linha 1 é uma identidade que pecisa ser obtida para seu aplicativo: Vá para dev.live.com e você terá a lista de aplicativos. É só criar um novo aplicativo e irá receber o seu ID.

 

Além disso estamos definindo os escopos com os que queremos trabalhar (note o “update” no sky drive), o Branding é apenas o visual que o botão de login assume (você pode ter o logo do windows, do sky drive, etc..), e o session changed é o evento que iremos utilizar para Logar nosso usuário. O redirectURI também precisa ser uma URI válida!



Vamos ver como a nossa tela fica com o Botão:

 

 

Agora é hora de conectar o nosso usuário. O processo de login ocorrerá chamando a página de login do Live ID e o evento SessionChanged será disparado.

 

Veja a tela de login, de resultado, e o código do evento que mostra a autorização na tela:

 

 

  1: LiveConnectClient client;
  2: 
  3:         private void skyDriveLogin_SessionChanged(object sender, Microsoft.Live.Controls.LiveConnectSessionChangedEventArgs e)
  4:         {
  5:             if (e.Status == LiveConnectSessionStatus.Connected)    
  6:             {    
  7:                 client = new LiveConnectClient(e.Session);    
  8:                 ((App)App.Current).LiveSession = e.Session;    
  9:                 this.txtMensagem.Text = "Autorizado";      
 10:                 
 11:                 client.GetCompleted += new EventHandler<LiveOperationCompletedEventArgs>(OnGetCompleted);  
 12:                 client.GetAsync("me", null);   
 13:             }   
 14:             else   
 15:             {   
 16:                 this.txtMensagem.Text = "Falha no login"; 
 17:                 client = null;  
 18:             }              
 19:         }
 20: 
 21:         void OnGetCompleted(object sender, LiveOperationCompletedEventArgs e)
 22:         {
 23:             if (e.Error == null)
 24:             {
 25:                 if (e.Result.ContainsKey("first_name") &&
 26:                     e.Result.ContainsKey("last_name"))
 27:                 {
 28:                     if (e.Result["first_name"] != null &&
 29:                         e.Result["last_name"] != null)
 30:                     {
 31:                         this.txtUsuario.Text =
 32:                             "Bem vindo " + e.Result["first_name"].ToString() + "" + e.Result["last_name"].ToString() + "!";
 33:                     }
 34:                 }
 35:             }
 36:             else
 37:             {
 38:                 this.txtUsuario.Text = "Erro: " + e.Error.ToString();
 39:             }
 40:         }



Vamos lá, temos 40 linhas, mas a maioria está aí apenas para validações e para mostrar quem está logado.

 

Antes de qualquer coisa, estamos instanciando uma propriedade do tipo LiveConnectClient, que é justamente quem buscará a sessão e fará a chamada ao método que nos possibilitará acesso ao SkyDrive.

Na linha 5 fazemos uso do LiveConnectSessionStatus, que validará se já estamos conectados.

Quando o resultadofor “true”, então começamos o processo de realmente ir buscar informações.

Dois pontos importantes das linhas 7 a 12.

Primeiro, na linha 8, notem que ao invés de recebermos a sessão emuma variável local ao método ou à página, estamos o fazendo com uma propriedade da classe App (arquivoApp.xaml, presente em todo aplicativo WP7
E responsável pelo “container” que são os application pages).

E qual o motivo disso? O fazemos para que seja possível reutilizar essa informação através do aplicativo inteiro.
Quando formos subir nosso arquivo para o SkyDrive, não queremos o fazer através da página de configuração, certo? então estamos mantendo essa informação disponível.

Logo mais a utilizaremos novamente.

 

Já na linha 11 / 12 nos inscrevemos no evento Get e passamos o folder root do SkyDrive (no nosso exemplo
estaremos sempre salvando nessa pasta).

Você pode trabalhar da forma como preferir, inclusive dando a opçãode escolha ao usuário.

 

O evento OnGetCompleted nada mais é do que apenas mostrarmos informações sobre o usuário logado,
como podem ver nas imagens acima.

 

Com isso, o usuário está conectado ao SkyDrive!!

 

Simples, não?

 

Vamos agora entender como subir um arquivo.

 

Para isso, usei um exemplo e uma ideia de um formulário onde o usuário irá colocar alguma informação e a
salvará tanto no IsolatedStorage local, quanto poderá clicar em um CheckBox para também salvar a mesma
infona nuvem, no seu SkyDrive. Isso foi a base criada para o aplicativo que criei para o Devbrasil Summit 2012.

 

Não mostro aqui o código completo da tela, apenas o evento de click no botão “salvar”, com a parte do
Isolated Storage também suprimida.

 

Assim que o usuário clicar no botão “Salvar” na tela abaixo, o código a seguir é disparado:

 

 



  1:         private void btnNotas_Click(object sender, RoutedEventArgs e)
  2:         {
  3:             //SEÇÃO DE CÓDIGO DO ISOLATED STORAGE REMOVIDO
  4: 
  5:             if (chkSkyDrive.IsChecked == true)
  6:             {
  7:                 if ((App.Current as App).LiveSession != null)
  8:                 {
  9:                     string nomeArquivo = codigo + ".txt";
 10:                     byte[] arrayBytes = Encoding.UTF8.GetBytes(this.textNotas.Text);
 11:                     MemoryStream stream = new MemoryStream(arrayBytes);
 12: 
 13:                     LiveConnectClient cliente = new LiveConnectClient((App.Current as App).LiveSession);
 14: 
 15:                     cliente.UploadCompleted += new EventHandler<LiveOperationCompletedEventArgs>(cliente_UploadCompleted);
 16:                     cliente.UploadAsync("me/skydrive", nomeArquivo, stream);
 17:                 }
 18:                 else
 19:                 {
 20:                     MessageBox.Show("É necessário logar no Sky Drive");
 21:                 }
 22:             }
 23:         }

 

 

O código é bastante simples:


Após salvar para o Isolated Storage (o código é 100% separado, ou seja, você pode salvar para o isolated e tratar com um try/catch de forma independente o acesso ao SkyDrive) validamos se o checkbox “Fazer Upload para o SkyDrive” está checado, seguido por validação da sessão (lembram que a usaríamos em nossa segunda tela? é aqui que a utilização da classe “App” faz sentido).

 

Se tudo estiver ok, vamos, na linha 9, criar um nome para o arquivo. aqui utilizei um código qualquer e adicionei o “.txt”. Fiquem livres para criar métodos verdadeiros, códigos ou padrões que façam sentido, assim como folders (e claro, uso de stringbuilders também são bacanas : ) )

 


Na linha 10 vamos buscar o valor do nosso conteúdo (no meu caso, o valor que inseri na imagem acima - “texto para artigo…”) para criação do nosso array de bytes e geramos um stream do tipo MemoryStream a partir desse array.

 

Novamente amos instanciar um LiveConnectClient, na linha 13, assim como fizemos anteriormente para obter os dados do usuário, e é com esse cliente que iremos chamar nosso serviço para fazer o upload.

Note que na linha 16 passamos o parâmetro de root folder para subir o arquivo (obviamente pode ser alterado e o hardcoded retirado), além do próprio nome do arquivo e o nosso stream.

 

Caso o usuário ainda não esteja logado, salvamos no isolated e mostramos a informação a ele. É só ir até a página de configuração, logar, e voltar para salvar na nuvem.

 

 

 

Só isso , Rodo?

 

 

 

Sim, isso e somente isso. abra seu SkyDrive e valide… seu arquivo estará lá!!

E pronto. agora seu aplicativo Windows Phone consegue fazer uploads e backup para a nuvem!