Se você ainda está em dúvida se deve ou não abrir sua Loja Virtual, abaixo seguem dez ótimos motivos para convencê-lo(a) de que está no caminho certo.

Conheça CogStores: E-commerce / Lojas Virtuais aqui.


1. Funcionamento 24 horas – Com um endereço na web, a sua empresa pode montar uma loja virtual e vender a qualquer hora. O horário comercial da sua empresa passa ser 24×7 (7 dias por semana e 24 horas por dia). A loja na rede abre canal de comercialização com 50 milhões de internautas somente no Brasil. Os números do e-commerce no Brasil são impressionantes.

Conheça CogStores: E-commerce / Lojas Virtuais aqui.
Link: http://www.blogdoecommerce.com.br/porque_criar_loja_virtual/

Sockets

Através do namespace System.Net.Sockets, o Windows Phone provê suporte a uma implementação gerenciada de sockets, permitindo que desenvolvedores possam ter um controle rigoroso ao acesso a redes, com esse recurso temos disponível um conjunto de API’s de alto nível, permitindo que o desenvolvedor crie aplicativos que interagem com um cliente utilizando de serviços existentes de TCP.

Existem muitas funcionalidades onde esse recurso pode ser utilizado, como pode exemplo, para criar aplicativos de FTP, e-mail e Chat, com sockets é possível criar aplicativos mais sofisticados e ricos, podendo utilizar de TCP (Transmission Control Protocol) ou UDP (User Datagram Protocol).

Câmera e fotos

Existem duas formas de acessar a câmera no Windows Phone, através das API´s do próprio sistema operacional ou através dos recursos já existentes do Silverlight 4, com as APIs do Windows Phone você tem imagens de alta resolução, além de controle do auto foco, acesso ao modo do flash, entre outros recursos, já com os recursos do Silverlight 4 webcam API, você tem facilidade de gravar vídeos e áudios em arquivos, se você já possui códigos em alguma aplicação Silverlight, você poderá aproveita-los com poucas ou nenhuma modificação quanto ao acesso a webcam.

É possível ter um controle bem flexível da câmera fotográfica do smartphone, através do Windows Phone podemos ter um controle do auto foco da câmera, gerenciar o flash utilizado, acionar a captura da imagem, além de uma série de eventos que podemos utilizar através do Microsoft.Devices.PhotoCamera, no código XAML a representação da câmera pode ser feito através do recurso VideoBrush do Silverlight.

Push Notitications e Live Tiles

Notifications é um poderoso recurso que o Windows Phone implementou de maneira bem interessante, com ele podemos enviar e receber informações para o Windows Phone 7, essas mensagens são enviadas para um serviço da Microsoft, e o serviço online envia para o smartphone, podendo receber a mensagem em seu projeto. Você poderá obter a mensagem recebida e manipular as informações, existem três tipos de Notifications, o tipo RAW, Toast e Tile, resumidamente o primeiro permite receber informações diretamente em sua aplicação, o segundo permite receber um aviso no topo da tela do Windows Phone, a aplicação receberá a notificação mesmo que a sua aplicação não esteja em execução no momento. Já o tipo Tile, é uma notificação nos Tiles que ficam na tela principal do Windows Phone e pode ser acionado quando apertamos o botão Start do aparelho. Na versão Mango, temos mais recursos disponíveis para essas notificações, a notificação do tipo Toast agora pode receber um determinado link que vai para determinado local em sua aplicação e ainda pode passar parâmetros que você pode utilizar para ler e realizar alguma tarefa, dando mais poder para as notificações no Windows Phone, as notificações do tipo Tile também foram incrementadas, agora é possível utilizar um Tile com dois lados e que mude periodicamente ou ainda ter tiles secundários para a mesma aplicação.

Figura 1. Fundo do Tile

Profiler

Performance é um dos assuntos mais importantes quando estamos criando aplicativos em geral, principalmente quando a aplicação vai ser executada em dispositivos com recursos limitados, como é o caso de smartphones, com a versão Mango temos agora uma ferramenta que analisa o perfil da sua aplicação, possibilitando analisar e medir através de gráficos , diversos recursos utilizados.

A ferramenta é totalmente integrada com o Visual Studio, para iniciar o uso do recurso , basta carregar a sua aplicação e no menu Debug, localizar e clicar na opção “Start Windows Phone Performance Analysis”, Figura 2, e clicar em Launch Application, em seguida você executa a rotina que deseja monitorar em seu aplicativo e clica em Stop Profiling, um arquivo com extensão SAP será criado, a cada processo de analise, um arquivo é criado, e você poderá manter um histórico para futuras analises de melhorias. Dentre as informações que a ferramenta apresenta, estão os frame rates, que são os números de renderização da tela do telefone, expressada em frames por segundo (fps), a porcentagem de uso da CPU do telefone, o uso da memória do aplicativo medido em megabytes, a utilização de Storyboards e imagens carregadas, por fim temos um indicativo de quando os eventos do garbage collections foram acionados durante o monitoramento. Se você selecionar um determinado período, o Visual Studio apresentará informações detalhadas sobre diversos pontos do aplicativo.

Figura 2. Performance Analysis

Figura 3. Analise detalhada da aplicação

Emulador

O emulador também sofreu algumas melhorias, duas delas são muito interessantes , como a possibilidade de testar no emulador os sensores de acelerômetro, Figura 4, e localização. Agora podemos simular através do emulador a leitura desses sensores, não precisando ter um equipamento físico para poder criar uma aplicação, basta você utilizar o mouse que o emulador vai responder conforme a ação esperada pelo aparelho real. No caso da utilização de recursos de localização, você ainda conta com uma barra de ferramentas com controles de busca, inclusão de indicativos de localização e gravação da localização, o emulador ainda contém alguns outros recursos que talvez sejam disponibilizados na versão final, como a possibilidade de adicionar gravações referente as simulações.

Figura 4. Emulador

Device Status

O namespace Microsoft.Phone.Info fornece informações sobre o equipamento, na versão anterior, era utilizado a classe DeviceExtendedProperties para obter alguns dados sobre o equipamento, na versão Mango essa tarefa passa a ser realizada por DeviceStatus, você pode obter informações como o total de memória, a versão do hardware e o nome do fabricante do equipamento. Através do PowerSource, podemos verificar se o dispositivo está funcionando com bateria ou conectado a uma fonte de alimentação externa. Outro recurso disponível é a possibilidade de verificar se existe ou não um teclado físico no smartphone através da propriedade IsKeyboardPresent.

Local Database

Existem dois tipos de persistências no Windows Phone 7, o Transient Data e o Persistent Data, você pode manipular informações através de Isolated Storage, um recurso que permite registrar e recuperar informações no próprio aparelho, essa forma de persistência de dados é chamada de “Persistent Data”, ou armazenar informações na memória, Transient Data, sua aplicação pode manipular esses dados conforme o seu ciclo de vida, porém na versão mango uma nova forma de Persistent Data foi adicionada, o local Database.

Agora temos a possibilidade de utilizar uma base de dados local em uma aplicação, antes da disponibilização das ferramentas betas da versão mango para desenvolvedores e da documentação oficial, falava-se que uma versão do SQL CE estaria disponível para ser utilizada, porém em sua documentação oficial a base de dados é citada somente como local database, uma versão própria do Windows Phone, um grande diferencial de produtividade está no suporte ao LINQ to SQL para operações em base de dados.

O local database permite armazenar dados relacionais dentro de um ambiente residente no Isolated Storage, por estar dentro do Isolated Storage, ele somente pode ser acessado pela aplicação correspondente, e roda somente no processo do aplicativo, não sendo executada com um serviço continuo, a manipulação de dados locais são acessados apenas através de LINQ to SQL, não tendo suporte ao Transact-SQL.

Launchers and Choosers

Os Launchers e Choosers são APIs que acessam alguns recursos do sistema operacional, eles disponibilizam recursos complexos deixando transparentes para que o desenvolvedor através de API´s, os Launchers são tarefas que somente são iniciadas pela sua aplicação, teoricamente, você não tem nenhum tipo de retorno da API, somente você pode inicia-los , passando os parâmetros que ela vai utilizar para realizar a tarefa. Já os Chooser também iniciam uma tarefa, mas a principal diferença é que os Choosers retornam algum dado que você poderá trabalhar em sua aplicação, um exemplo seria o EmailAddressChooserTask, com ele podemos apresentar ao usuário a lista de e-mails cadastrados no aparelho, quando um e-mail é selecionado, podemos obter essa informação e utilizar para enviar um e-mail através de um Launcher chamado EmailComposeTask, que não retorna nenhuma informação,dessa forma algumas tarefas que poderiam ser bem complexas são facilitas com os Launchers e Choosers. Na versão Mango temos novos Launchers and Choosers adicionados as API´s são eles:

Address Chooser Task : Inicia a lista de contatos da aplicação e permite a seleção.

Game Invite Task : API utilizada em jogos aprovados no Xbox Live que permite convidar jogadores para uma partida multi-player em um Game.

Save Ringtone Task : Permite gravar um arquivo MP3 ou WMA na lista de ringtones do sistema operacional.

Bing Maps Task : Inicia o Bing Maps, permitindo setar a propriedade center com uma posição geográfica.

Bing Maps Directions Task : Inicia o Bing Maps permitindo informar e receber informações sobre dois pontos.

Conclusão

O Windows Phone 7 chegou trazendo uma nova plataforma de desenvolvimento para dispositivos móveis, a Microsoft utilizou o que existe de mais moderno para criar o seu sistema operacional, dando suporte as melhores práticas de desenvolvimento e integração com aplicativos, a versão Mango contém mais de 500 novos recursos e confirma o investimento da Microsoft em sua plataforma mobile.

A renderização da interface gráfica do Windows Phone 7 foi projetada para buscar o máximo de performance que o smartphone pode proporcionar, a UI Thread é responsável pelo desenho da interface principal do aplicativo, quando criamos um software para o WP7, devemos evitar bloquear a UI Thread, pois ela está diretamente relacionada a performance do software e também com a experiência do usuário com o aplicativo.

Os smartphones com Windows Phone 7, tem disponível um recurso que utiliza a aceleração da GPU, aumentando consideravelmente o desempenho gráfico para algumas tarefas relacionadas a manipulação de imagens e animações, principalmente as que usam a rotação de eixos, escalas e alguns tipos de? animações que usam de Storyboard. Não é necessário acionar nada para que alguns tipos de Storyboards utilizem esse recurso, eles automaticamente usam o Composition Thread ou também chamado de Render Thread.

O Render Thread pode ser usado para animações simples utilizando DoubleAnimation ou Easing Functions, ou em propriedades? como Opacity, Render Transforms e Rectangular Clip. Habilitando o EnableRedrawRegions podemos ver quais regiões na aplicação estão sendo desenhadas no momento, visualizando? quadro a quadro:

Application.Current.Host.Settings.EnableRedrawRegions = true;

Composition Frame Rate Thread? e UI Frame Rate Thread

Quando executamos um aplicativo através do Visual Studio 2010 com o smartphone plugado no computador,? podemos visualizar alguns números no lado superior direito da tela, esses números servem para você ter como parâmetro alguns pontos sobre a renderização gráfica, memória, etc, os dois primeiros números de 3 dígitos são referente a Render Thread e a UI Thread.

O Composition Frame Rate Thread está associado a velocidade com que a tela é atualizada em uma thread separada da UI Thread, como referência, o Windows Phone 7 utiliza o valor 30 como ponto de equilíbrio, ou seja, quando for abaixo de 30, os números estarão na cor vermelha, acima de 30 ele ficará com a cor default, o valor mais próximo de uma boa performance é 60, sua aplicação deve buscar sempre se aproximar desse número.

O UI Frame Rate Thread mostra a taxa de atualização da Thread principal, enquanto a interface do usuário estiver ativa, o valor de 30 também foi definido como ponto de equilíbrio, ficando vermelho se a aplicação estiver abaixo deste valor, porém este valor deve ser acima de 20 para ter um tempo de resposta aceitável e quanto maior o valor , o tempo de resposta será mais rápido.

Exemplo prático de UI Thread VS Render Thread

Vou criar um aplicativo simples com dois elementos Ellipse na tela, um com o nome BolaVermelha e outro com BolaAzul, as duas Ellipses serão animadas na tela, a BolaAzul vai utilizar o Render Thread, pois vamos utilizar uma Storyboard com a propriedade RenderTransform, já a BolaVermelha vamos anima-lá atualizando a mesma propriedade, mas utilizando um timer DispatcherTimer para atualizar a propriedade, ou seja, não utilizaremos uma Storyboard para realizar a animação e ela estará utilizando a UI Thread.

   1:    public partial class MainPage : PhoneApplicationPage

   2:      

   3:  

   4:          DispatcherTimer timer;

   5:          RotateTransform rotateVermelho;

   6:          bool bateVolta;

   7:          int contador = 0;

   8:  ? 

   9:          public MainPage()

  10:          

  11:              InitializeComponent();

  12:              Loaded += new RoutedEventHandler(MainPage_Loaded);

  13:  ? 

  14:              Application.Current.Host.Settings.EnableRedrawRegions = true;

  15:  

  16:              this.BolaVermelha.RenderTransform =

  17:                  new RotateTransform();

  18:              this.BolaAzul.RenderTransform =

  19:               new RotateTransform();

  20:  

  21:              rotateVermelho =

  22:              BolaVermelha.RenderTransform as RotateTransform;

  23:              rotateVermelho.Angle = -50;

  24:  ? 

  25:              timer = new DispatcherTimer();

  26:              timer.Tick += new EventHandler(timer_Tick);

  27:              timer.Interval = new TimeSpan(0, 0, 0, 0, 33);

  28:              timer.Start();

  29:  ? 

  30:              bateVolta = false;

  31:  

  32:          

  33:  ? 

  34:          void MainPage_Loaded(object sender, RoutedEventArgs e)

  35:          

  36:  ? 

  37:              Storyboard storyboard = new Storyboard();

  38:              DoubleAnimation animation = new DoubleAnimation();

  39:              animation.From = 0;

  40:              animation.To = 180;

  41:              animation.Duration = new Duration(new TimeSpan(0, 0, 1));

  42:              animation.AutoReverse = true;

  43:              Storyboard.SetTarget(animation, this.BolaAzul.RenderTransform);

  44:              Storyboard.SetTargetProperty(animation, new PropertyPath("Angle"));

  45:              storyboard.Children.Add(animation);

  46:              storyboard.RepeatBehavior = RepeatBehavior.Forever;

  47:              storyboard.Begin();

  48:  

  49:          

  50:  ? 

  51:          void timer_Tick(object sender, EventArgs e)

  52:          

  53:              if (rotateVermelho .Angle == 120)

  54:              

  55:                  bateVolta = true;

  56:              

  57:              if (rotateVermelho.Angle == -50)

  58:              

  59:                  bateVolta = false;

  60:              

  61:  ? 

  62:              if (bateVolta == true)

  63:              

  64:                  rotateVermelho.Angle -= 1;

  65:              

  66:              else

  67:              

  68:                  rotateVermelho.Angle += 1;

  69:              

  70:  ? 

  71:              contador++;

  72:  ? 

  73:              if (contador == 600)

  74:              

  75:                  MessageBox.Show("Parando a UI Thread");

  76:                  Thread.Sleep(1000);

  77:              

  78:  ? 

  79:              if (contador == 1000)

  80:              

  81:                  MessageBox.Show("Inserindo BitmapCache");

  82:                  BitmapCache cache = new BitmapCache();

  83:                  BolaVermelha.CacheMode = cache;

  84:  ? 

  85:              

  86:  ? 

  87:          }

  88:  ? 

  89:      }

?

Na linha 71 criei um contador, quando chegar a 600, ele vai bloquear a UI Thread, na linha 76, a UI Thread é bloqueada propositalmente utilizando Thread.Sleep, neste momento você irá notar que a animação da? BolaVermelha irá parar com base no tempo definido em Sleep, pois a sua Thread está bloqueada, mas a BolaAzul continuará a se movimentar.

Quando o contador chegar a 1000,? vou adicionar um BitmapCache na propriedade CacheMode da BolaVermelha, em alguns casos onde não estamos utilizando a Render Thread, podemos criar um cache, ou seja, colocar os bitmaps na memória, e com isso aproveitar da aceleração da GPU, com performance semelhante a Composition Thread, porém a BolaVermelha continuará na UI Thread,? uma simples mensagem na tela utilizando um MessageBox irá bloquear a UI Thread enquanto a BolaAzul continuará em movimento.

Conclusão

UI Thread e Composition Thread são recursos fundamentais que o Windows Phone 7 utiliza para apresentar a interface gráfica, conhecendo essas Threads você poderá melhorar a perfomance da sua aplicação, os smartphones são equipamentos limitados se comparado a um PC, conhecer quando utilizar determinado recurso pode fazer muita diferença, existem diversos outros pontos a serem considerados quanto ao monitoramento da aplicação com objetivo de melhorar a perfomance, neste artigo somente apresentei uma introdução sobre o assunto.

Alguns recursos podem não funcionar como esperado no emulador, pois depende de diversos fatores como o suporte a DirectX pela placa de video, neste link você encontra mais informações:

WP7/Silverlight Graphics Performance

Mais informações sobre Bitmap Cache : Bitmap Cache

Mais informações sobre performance: Performance Considerations in Applications for Windows Phone

Amanhã (25/05) teremos mais um encontro do nosso grupo de usuários de Ruby, o RailsMG. Convidamos todos para o próximo encontro que será as 19:00h com a palestra as 19:30. Como sempre o local é Take na rua Professor Morais 659, Savassi, Belo Horizonte, MG ( Clique aqui para ver o mapa ).

Amanhã (25/05) teremos mais um encontro do nosso grupo de usuários de Ruby, o RailsMG. Convidamos todos para o próximo encontro que será as 19:00h com a palestra as 19:30. Como sempre o local é Take na rua Professor Morais 659, Savassi, Belo Horizonte, MG ( Clique aqui para ver o mapa ).

Apresentação

Desta vez teremos uma apresentação do Adimir Colen que irá falar sobre monitoramento de processos com God e Bluepill.

Sorteio

Assim como no último encontro, também teremos sorteios de prêmios entre os presentes. O que será sorteado um bônus do PeepCode e um livro da O’reilly. Não podemos esquecer o apoio da 37Signals, Webbynode, eGenial e Github .

Ajude a divulgar a reunião entre os interessados por Ruby e Rails na sua empresa e amigo.

Uma discussão que esta em alta é em relação a velocidade do ZendAmf. O ZendAmf é realmente mais lento por possuir recursos extras e ser baseado no Zend Framework.

Eu já fiz a validação do XML ou AMFPHP, e nesta mostrei que o AMFPHP é muito mais rápido que o XML.

Então aproveitando o exemplo mostro que o AMFPHP ainda continua mais rápido que o ZendAmf e por isso muitos programadores ainda optem por este no desenvolvimento de seus softwares.

Para aqueles como eu, amantes dos produtos Google, e querem utilizar o Google Analytics em todos os sistemas, segue aqui uma forma fácil de integra-lo com o Flex.