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.

Pessoal, tenho recebido muitas dúvidas de como analizar o retorno AMF do java/php, causando principalmente aquele erro “Server Fault”.

Algo OBRIGATÓRIO que todo desenvolvedor deve conhecer é uma forma de estar sempre atento ao retorno AMF e isso pode ser realizado de diversas formas. A mais simples delas é a integração Firefox + Firebug + AMF Explorer e iremos mostrar a seguir como fazer isso.

Primeiro, instale o firefox: http://br.mozdev.org/

Segundo, instale o firebug: https://addons.mozilla.org/pt-br/firefox/addon/firebug/

Terceiro, instale o AMF Explorer: https://addons.mozilla.org/pt-br/firefox/addon/amf-explorer/

Reinicie o firefox (tanto para o firebug quanto para o amf explorer) e então carregue a sua aplicação Flex. Clique no botão do firebug, que na versão 4 está no canto superior direito da tela. Navegue até a aba “Rede” e habilite-a:

Quando for realizar a conexão, limpe as entradas que já tenham acontecido, e faça a conexão AMF. Procure pelo seu gateway, que é o arquivo PHP ou Java que faz a conexão com o servidor. Expanda-o e veja se existe algo semelhante a figura a seguir:

Veja que, quanto expandimos o POST zendamf.php (no seu caso pode ser POST gateway.php), surge o AMF Request e o AMF Response. O AMF Response contém os dados que retornaram do servidor, conforme o exemplo a seguir:

Se houver algum erro de PHP, este erro estará na mensagem também, então ao invés de ver um erro genérico “Server Fault”, você verá o fatal error do php/java que foi gerado.

Esta é uma tradução do seguinte artigo: 10 Things A Good Flex Developer Should Know

Para ser um bom programador Flex é preciso mais que simplesmente saber como usar alguns componentes nativos do Flex. É preciso muito mais.

Aqui está minha contribuição sobre o assunto… juntamente com alguns recursos ou algumas palavras-chave que você poderá pesquisar facilmente através do Google.

Por favor, comente no blog se você achar que esqueci algo (o que é inevitável) ou se quiser sugerir alguns recursos interessantes que devo acrescentar.

1- Programação orientada a Objetos (OO)

O Flex se baseia na linguagem ActionScript3, que é totalmente orientada a objetos. Embora não seja um conceito fácil de aprender, programação orientada a objeto é um pré-requisito para aprender Flex. Se já possui experiência com OO (Java, C#, Ruby, etc), então você está pronto. Se não, você precisará pegar um livro sobre OO e começar a aprender o mais rápido possível.

· Head First Java (Java? Sim, Eu sei. Mas confie em mim.)

· Object-oriented programming with ActionScript 3.0

Nota: Alguns de vocês poderão perguntar – “O que são padrões de projetos?”. Vamos dar um passo de cada vez? Preocupe-se em entender classes e objetos, interfaces, herança, composição, polimorfismo, encapsulamento, etc. Só então considere estudar padrões de projetos. De fato, se eu escrever um post intitulado “10 coisas que um GRANDE programador Flex deve saber”, padrões de projeto estará nessa lista.

2- ActionScript/MXML

ActionScript é a linguagem de programação usada juntamente com MXML para criar aplicações Flex. MXML é uma linguagem de marcação baseada em XML. Cada tag MXML é mapeada diretamente para uma classe ActionScript correspondente. MXML é usado pelos desenvolvedores Flex principalmente para apresentar a interface do usuário, enquanto que, o ActionScript é usado para a lógica de negócio. Com exceções, é claro.

O Framework Flex inclui centenas de classes ActionScript e interfaces usadas para desenvolver aplicações Flex. Seu nível de habilidade como um desenvolvedor Flex está diretamente ligado ao seu conhecimento em relação ao ActionScript e MXML.

· Flex in a Week

· Tour De Flex

· Essential ActionScript 3.0

Nota: Fique ? vontade com a API do Flex. Como um desenvolvedor Flex, você vai usá-la diariamente.

3- Debugging

Boa parte do tempo de qualquer programador é gasto no debugging. Obviamente, é necessário debugar para rastrear a causa de bugs. No entanto, também é uma ótima maneira de conhecer o código fonte.

Felizmente, existem muitas ferramentas disponíveis para ajudá-lo com o trabalho de debugging. Invista algum tempo para aprender essas ferramentas. Seu investimento irá proporcionar retorno imediato.

· Flash Builder 4.5 Debugger

· De MonsterDebugger

· Kap Inspect

4- Programação orientada a eventos

Aplicações Flex são orientadas a eventos. Toda ação é o resultado de um evento assíncrono.

Como um desenvolvedor Flex, você deve saber como responder a eventos e como criar e disparar eventos. Para isso, é necessária uma sólida compreensão da arquitetura de eventos do Flex, incluindo familiaridade com os seguintes conceitos:

· Eventos nativos (Flash Player ou Framework de eventos Flex)

· Eventos customizados (Eventos criados pelo desenvolvedor, que estende a classe Event ou uma de suas subclasses)

· Disparar eventos, propagação de eventos (ver classe EventDispatcher e seu método dispatchEvent)

· Event listeners, event handlers (ver classe EventDispatcher e seus métodos addEventListener e removeEventListener)

· Fases do evento (capture, target & bubbling phases; target vs. currentTarget)

· Objetos do evento, tipos de eventos (ver classe Event e subclasses)

· Comportamento do evento default (ver classe Event e subclasses e seu método preventDefault)

5- Data binding

Aparentemente, data binding é um “no brainer”[1]. É só vincular o valor de uma propriedade ao valor de outra propriedade usando chaves. Quando o valor da propriedade de origem for alterado, o valor da propriedade de destino também é alterado.

No entanto, existe uma sobrecarga associada ao uso indiscriminado de data binding, podendo haver implicações no desempenho. Uma sólida compreensão de data binding ajudará a determinar quando é apropriado o seu uso e quando não é.

· Flex Tips – Using Bindable Metadata Events

· Michael Labriola’s presentation entitled Diving in the Data Binding Waters

6- Item renderers

Uma característica de uma aplicação Flex bem projetada é a apresentação dos dados de uma forma visualmente atraente. O Flex oferece uma série de controles baseados em listas (DataGrid, List, TileList, HorizontalList, etc) responsável pela apresentação dos dados. Portanto, pode-se personalizar a exibição dos dados com a ajuda de item renderers.

Você irá consumir muito tempo trabalhando com item renderers. Então é melhor saber bem como ele funciona.

· Flex Examples – Item Renderers in Practice

· A Deep Dive into Flex 4 Lists and Layouts

7- Acesso remoto a dados

Você conhece muitas aplicações que não interagem com os dados? Eu também não. Saiba como recuperar dados através de HTTPServive, WebService e RemoteObject. A arquitetura do framework Flex também poderá ajudá-lo com isso (ver #9).

· Retrieving and handling data with HTTPService

· Retrieving and handling data with WebService

· Retrieving and handling data with RemoteObject

8- Styling / Skinning

Não vamos nos esquecer que o Flex é uma tecnologia de interface e, como tal, certamente há expectativas em relação ao design. Como um desenvolvedor Flex, você deve ser capaz de personalizar a aparência de seus aplicativos usando estilos CSS, gráficos e/ou skins.

Com o Flex 4, não há mais desculpas. Use um pouco do seu tempo para conhecer de uma vez o lado direito do seu cérebro. É uma excelente mudança de paradigma, e vai ajudá-lo a diferenciar-se dos outros desenvolvedores Flex.

· Flex Style Explorer

· ScaleNine

· Introduction to Flex: Part 3 – Styles & Skins

9- Pelo menos um framework de arquitetura Flex

A maioria dos frameworks de arquitetura Flex impõe uma separação de camadas através da implementação do MVC (model-view-controller). Além disso, esses mesmos frameworks especificam como seu código deve ser organizado dentro do projeto Flex.

Embora muitos argumentariam que os frameworks são desnecessários, acredito que os desenvolvedores Flex se beneficiam em muitos aspectos da experiência de usá-los. Basta assistir ? s técnicas (boas ou más) empregadas por um framework para resolver problemas complexos de arquitetura. Isso contribuirá para seu crescimento como um desenvolvedor Flex.

Além disso, é difícil negar o fato de que a experiência com framework aumentará substancialmente o seu valor comercial como um desenvolvedor Flex. Jesse Warden me disse recentemente “Existem poucas empresas que não usam frameworks, mas isso é raro. Queiramos ou não, está na ‘moda’”. Eu concordo com Jesse.

· Cairngorm

· Parsley

· PureMVC

· Mate

· Swiz

· Robotlegs

10- Ciclo de vida de componentes e display list

Eu não estava convencido da necessidade de aprender o ciclo de vida de componentes Flex ou da display list até que escrevi o meu primeiro componente customizado (na verdade foi um componente semi-customizado que se estendia do componente Canvas). Até essa época eu usava componentes nativos do Flex, usando apenas o MXML enquanto que a display list era renderizada para mim. Em nenhuma vez tive que usar os métodos addChild, createChildren ou commitProperties, e usava o evento creatiomComplete para tudo.

Meu primeiro componente customizado usava uma quantidade enorme de eventos assíncronos, e eu não poderia prever a ordem em que cada evento seria disparado. Só depois que eu aprendi os métodos e variáveis do ciclo de vida dos componentes do Flex que eu pude ter um certo controle.

Estes métodos do ciclo de vida estão lá para serem usados. Saiba como funcionam e use-os para o seu benefício. Sua vida será mais fácil e você perderá menos cabelos.

· Colin Moock’s Lost ActionScript Weekend – The Display List

· Creating New Components in Flex 3

· Diving Deep with the Flex Component Lifecycle

· Understanding the Flex 3 Component and Framework Lifecycle

[1] Expressão americana usada para algo que requer pouco esforço mental ou inteligência para realizar ou compreender

Olá pessoal!

Todo mundo já deve estar careca de saber que a Adobe já anunciou o Flash Builder 4.5 e este será lançado em Maio de 2011.

Como você pode ter visto no anuncio, nós Flex developers poderemos criar aplicativos móveis para as plataformas Android, Blackberry Tablet OS e Apple iOS.

Aí vem o porém sobre as duas últimas plataformas e que podem gerar muita confusão no lançamento do Flash Builder em Maio. A Adobe planeja lançar um update em Junho de 2011 com suporte total ao Blackberry Tablet OS e Apple iOS, sem precisar abrir seu prompt de comando favorito. O que acontece na primeira versão lançada em Maio é o suporte total ao Google Android.

Na tabela abaixo retirada do Blog oficial da Adobe, explica melhor esta situação:

*Project will actually target AIR 2.5. You will need to make a manual change to your project to enable this configuration. This will be clearly documented on the Adobe Developer Center and RIM’s developer site upon launch in May, 2011.

Há outra coisa que a Adobe lembra é que com o novo Flash Builder 4.5, você pode criar projetos usando Flex Mobile ou apenas ActionScript puro. Existem algumas diferenças entre estes projetos.
Quando você cria um novo projeto Flex Mobile, você tem direito a usar todas as funcionalidades adicionados no core do Flex SDK, onde possuem componentes específicos para Mobile, como o ViewNavigatorApplication e ViewNavigator para manipular a navegação da aplicação e persistir os dados entre as views.

Já na criação de um projeto ActionScript Mobile, você poderá apenas escrever sua aplicação usando ActionScript puro, que é muito comum no desenvolvimento de jogos, porém não poderá utilizar as classes Flex dentro deste projeto.

É importante lembrar que ambos projetos, fornecem o fluxo completo no Flash Builder para desenvolver projetos mobile através do código e no design view, podendo pré-visualizar e debuggar a aplicação no desktop ou em seu aparelho (smartphone ou tablet).

Posso dizer que está cada vez mais gratificante poder trabalhar com a Flash Platform e ter entrado de cara neste mundo em 2008. Já se passaram 3 anos e vi muita evolução por parte da Adobe, mesmo por meio dos assuntos que rolaram sobre HTML5.

Por hoje é isso e até a próxima.

Mais informações em http://adobe.ly/hH0wtn

Neste post vou explicar como usar a API de Log para mostrar os logs de execução da aplicação e também como usar o componente TraceTarget, que é muito útil para poder recuperar as informações das chamadas para o servidor, facilitando a resolução de problemas.

No Flex temos duas opções para recuperar informações ou logs de execução de uma aplicação. Uma primeira maneira e a mais utilizada, é usar a função global trace(”) para mostrar informações no console do FlashBuilder. Essa abordagem sempre requer que a aplicação esteja sendo executada em modo de debug, o que exige a instalação de um FlashPlayer versão de debug. Lógico que para o ambiente de desenvolvimento isso não é um problema, já que a instalação do FlashBuilder já inclui a versão correta do FlashPlayer versão debug. Mais e quando a aplicação está em produção, ou seja, quando não contamos com a versão de debug do FlashPlayer? Ai que entra a segunda opção.Na segunda opção vamos usar a API de Logging do Flex, que vai nos permitir delegar para uma classe a função de logar informações, seja usando o trace(”), primeira abordagem, ou até mesmo customizando a forma de apresentação. Esta abordagem também nos permite controlar o que é exibido, utilizado categorias e nível de log.

A API de Logging do Flex é muito simples de ser usada. Toda vez que queremos usa-la, estaremos envolvendo duas partes:

1. O Logger, que possui os meios para enviar informações em diversos níveis (all, debug, info, warn, error e fatal) em uma determinada categoria para o Log Target. O Logger sempre irá implementar a interface ILogger, iremos utilizar a classe mx.logging.LogLogger, que já vem no SDK;
2. O Log Traget, que será responsável por registrar a informação usando o trace(”) ou outra implementação. Iremos utilizar a classe mx.logging.targets.TraceTarget.

Para ficar mais fácil de entender como usar a API, vamos imaginar que queremos logar quando a aplicação é pré-inicializado, inicializado e criado.Inicialmente iremos usar a função global trace(”) e depois usar as classes de Log.

Ler o resto…

Durante o ando de 2010 diversos leitores me escreveram solicitando alguma forma de “receita de bolo” para a criação de projetos em Flex. Estavam buscando uma maneira de criar uma aplicação de forma que fosse mais correta e mais fácil, baseada em padrões de projeto e definida através de uma estrutura que facilitasse o desenvolvimento.

No início de 2011 comecei a pensar mais no assunto, pois irei implementar estas regras nos próximos livros, chegando a uma série de “regras” das quais estarei apresentando neste artigo. Inicialmente, queria dizer que eu não sou o dono da verdade, e estou longe de criar alguma regra que se não usada irá causar o seu insucesso. Estou disposto a receber críticas que sejam construtivas, com o intuito de melhorar o sistema cada vez mais, possibilitando assim que a comunidade tenha em mãos um bom documento para consulta.

PHP ou Java?

Uma das perguntas que mais recebi ao longo de 2010, por isso estarei discutindo um pouco sobre qual linguagem de servidor usar. Inicialmente você deve saber que não é a linguagem que vai fazer você ter sucesso ou não em um sistema, e sim o quanto você conhece a mesma. Por exemplo, se você conhece muito bem PHP, porque aventurar-se em Java se dá conta do recado? O mesmo vale para o Java, mas não recebi emails de nenhum programador Java querendo mudar para php… (sic.. hehe).

O que? é fato nesta “briguinha” é que, não existe melhor ou pior. Java é mais complexo que php, exige mais atenção mas traz muitos benefícios, até financeiros (sim você ganha mais). PHP é mais fácil, você cria tudo mais rápido e com isso fica mais feliz Qual você vai escolher? Escolha a que te faz mais feliz.

Zend_AMF ou AMFPHP ?

Outra dúvida muito comum entre os programadores PHP. Eu costumo selecionar um ou outro dependendo do projeto em sí. Se o seu projeto vai usar alguns recursos do Zend Framework, e são muitos, utilize o Zend_AMF. Caso contrário, use AMFPHP.? Aqui chegamos a um impasse do qual julgo ser mais importante do que a briga entre Zend e AMFPHP: você ainda pensa em criar um projeto sem o Zend Framework? Você irá criar tudo que precisa “na mão” ou vai usar componentes de terceiros? Falo isso porque se um projeto em PHP é iniciado, o uso do Zend Framework irá acelerar muito o processo do mesmo. Rotinas como enviar email, acessar a sessão do php, gerenciar usuários com ACL, persistência de dados, acesso ao twitter… são todos muito bem implementados com o Zend e o Zend Framework é mantido pela mesma empresa que mantém o PHP, então não existe biblioteca mais segura em termos de continuidade do que esta.

E quais tecnologias vamos usar nas “melhores práticas” ?

Agora que discutimos as duas perguntas mais perguntadas em 2010 vamos a esta solução que julgo, pessoalmente, ser muito boa:

No cliente:

• Adobe Flash Burrito e Flex SDK 4.5 (Basta baixar e instalar o Flash Burrito: http://labs.adobe.com/technologies/flashbuilder_burrito/).
• SWIZ Framework (http://swizframework.org/)

No servidor:

• PHP
• Zend Framework (http://www.zend.com/community/downloads)
• WAMP Server (para rodar o PHP na própria máquina – http://www.wampserver.com/en/download.php)
• Netbeans ou Eclipse PDT – Eu estou gostando mais do Netbeans, então vou usá-lo.? (http://netbeans.org/downloads/index.html? – Versão PHP)

?

Certifique-se de ter tudo instalado, para que possamos dar prosseguimento no artigo.

Estrutura de pastas e projetos

Outra dúvida comum dos usuários, é definir a estrutura de pastas do projeto. Como instalamos o WAMP Server, ele nos fornece uma pasta onde é possível ter acesso pelo nacegador, através do endereço “localhost”. Isto é, ao acessarmos http://localhost/ o WAMP Server cuida de apontar para o diretório c:wampwww (que é o que chamamos de “document root”). Para que possamos entender a estrutura do projeto, é necessário compreender uma particularidade do Flex. Diferentemente do PHP, os arquivos que estão dentro do projeto Flex não precisam ser enviados ao servidor (os arquivos mxml, as, etc). veja que o Flex compila todos os mxml/as do projeto e gera um único arquivo swf. Este arquivo sim DEVE estar no diretório web do projeto!

Vamos então criar o projeto “melhoresPraticas” da seguinte forma:

1. Crie a pasta c:wampwwwmelhoresPraticas Este é o diretório público do projeto, acessado através de http://localhost/melhoresPraticas?????????
2. Crie a pasta c:wampwwwmelhoresPraticasclasses Este é o diretório onde iremos criar as nossas classes PHP
3. Crie a pasta c:wampwwwmelhoresPraticasvos Este é o diretório onde as classes VOs serão criadas
4. Crie a pasta c:wampwwwmelhoresPraticasZend Aqui você copia/cola o Zend framework, de forma que o arquivo melhoresPraticasZendLoader.php esteja acessível
5. No Flash Builder, crie o projeto “melhoresPraticas”. Você pode deixar o DefaultLocation como está. Não clique em Finish, clique em Next, até chegar na configuração do “Compiled Flex application location”. Ou seja, aqui você irá informar para onde os aquivos compilados do flex irão ficar. Coloque o seguinte caminho: c:wampwwwmelhoresPraticasbin-debug. Não clique em Finish, clique em Next, e em Library Path, adicione a biblioteca swiz (o arquivo swc). Em “Output folder URL”, coloque: http://localhost/melhoresPraticas/bin-debug
6. Com o projeto pronto, clique no botão RUN. Deve então surgir uma página em branco no endereço: http://localhost/melhoresPraticas/bin-debug/melhoresPraticas.html
7. No Netbenas ou no eclipse, crie o projeto php apontando para c:wampwwwmelhoresPraticas

Testando a conexão

Com os projetos prontos, iremos inicialmente realizar uma simples conexão entre o Flex e o PHP. Isso é útil para que possamos começar com trabalho “pesado”. Para conectarmos o Flex no PHP, preciamos criar uma classe de conexão no Flex, que iremos chamar de ServiceBase, e um arquivo que recebe esta conexão no PHP, que chamaremos de gateway.php.

Para criar a classe ServiceBase, use o Flash Builder e acione o menu File > New > ActionScript Class e crie a classe de acordo com a imagem a seguir:

Classe ServiceBase:

package services
{
??? import mx.controls.Alert;
??? import mx.rpc.events.FaultEvent;
??? import mx.rpc.remoting.RemoteObject;
???
??? public dynamic class ServiceBase extends RemoteObject
??? {
??????? public function ServiceBase(classe:String)
??????? {
??????????? super(“zend”);
???????????
??????????? /*
???????????? * Como o arquivo swf está na pasta bin-debug,?
???????????? * precisamos subir um nível para chegarmos ao
???????????? * arquivo gateway.php
???????????? */
??????????? this.endpoint = “../gateway.php”;
???????????
??????????? this.source = classe;
??????????? this.addEventListener(FaultEvent.FAULT,OnFault);
??????? }
???????
??????? protected function OnFault(e:FaultEvent):void
??????? {
??????????? Alert.show(e.fault.faultString,”Erro” );
??????? }
??? }
}

Esta classe tem como principal objetivo estabelecer o endpoint, que é o gateway.php que ainda vamos criar. O atributo source define qual a classe que iremos acessar na pasta classes. Também adicionamos um listener genérico caso haja alguma falha na conexão. Veja que a classe é dinâmica (dynamic), ou seja, podemos chamar métodos da classe sem que eles estejam implementados na classe. Isso é útil pois os métodos chamados nesta classe serão os métodos remotos do PHP.

No servidor, temos que criar o arquivo gateway.php, com o seguinte código:

//Adiciona o autoloader do Zend Framework
// Assim todas as classes do framework
//? serão carregadas quando precisarem
require_once “Zend/Loader/Autoloader.php”;
Zend_Loader_Autoloader::getInstance()->setFallbackAutoloader(true);

//Instancia o servidor Zend_AMF
$server = new Zend_Amf_Server();

//Habilita o modo de desenvolvimento, retornando
// mensagens de erro. Comente esta linha quando
//?? estiver em modo de produção
$server->setProduction(false);

//Adiciona este diretorio como um diretorio de
// classes que podem ser usadas pelo Flex
$server->addDirectory(dirname(__FILE__).”/classes”);
set_include_path(dirname(__FILE__).”/vos”);

//TODO: Adicionar VOs

//Dependendo da requisição do Flex, irá
// chamar a classe correspondente, respondendo
//?? em formato AMF o que a classe responder.
echo $server->handle();

//Não fechar a tag PHP, nunca !!

?

O arquivo gateway.php é o ponto de entrada para as classes em PHP. Veja que inicialmente fazemos um include do Autoloader.php para que todas as classes do Zend Framework sejam instanciadas sem a necessidade de realizar requeires. Criamos então a instância do Zend_AMF_Server, que irá cuidar para que o flex consiga conversar com o PHP via AMF. Adicionamos o diretório classes como um diretório do AMF, onde as classes serão expostas ao flex e usamos o set_include_path para adicionar as classes que estão na pasta “vos” no path global do php, para que não precisamos fazer include das mesmas. Depois adicionaremos mais código sobre as classes VOs.

Na pasta “classes”, criamos a classe Teste, e o método sayHelloWorld. O nome do arquivo tem que ser o mesmo nome da classe, ou seja, Teste.php.

class Teste {
??? public function sayHelloWorld($name)
??? {
??????? return “Hello World $name”;
??? }
}

//Não feche a tag PHP!

?

Agora voltaremos ao Flex para que ele possa acessar a classe teste. No arquivo melhoresPraticas.mxml, adicionamos o seguinte código:

?

http://ns.adobe.com/mxml/2009″
?????????????? xmlns:s=”library://ns.adobe.com/flex/spark”
?????????????? xmlns:mx=”library://ns.adobe.com/flex/mx” minWidth=”955″ minHeight=”600″>
???
??????? ??????????? import mx.controls.Alert;
??????????? import mx.rpc.events.ResultEvent;
???????????
??????????? import org.swizframework.utils.services.ServiceHelper;
???????????
??????????? import services.ServiceBase;
??????? ]]>
???
???
???
??????? ???????????
??????????? var testeService:ServiceBase = new ServiceBase(“Teste”);
??????????? var serviceHelper:ServiceHelper = new ServiceHelper();
???????
??????? serviceHelper.executeServiceCall(
??????????? testeService.sayHelloWorld(“Daniel”),
??????????? function(e:ResultEvent):void{
??????????????? Alert.show(e.result.toString());
??????????? });
???????
??????? ]]>
???
???

?

Como estamos realizando um teste, fazemos o acesso ao PHP no evento creationComplete da aplicação. Criamos a variável testeService que é do tipo ServiceBase, repassando o parâmetro que é o nome da classe no PHP, ou seja, “Teste”. Também criamos a variável serviceHelper que pertence ao Swiz e é um facilitador de acessos ao PHP. Usamos no serviceHelper? o método executeServiceCall, que irá chamar remotamente o método sayHelloWorld repassando o parâmetro “Daniel” e quando concluído, executará a função que está no segundo parâmetro, realizando um Alert.

Ao executar esta aplicação, quando é carregada surgirá a mensagem de retorno do PHP:

?

Criando as classes em Service

Com o teste de conexão realizado, podemos avançar mais no código! A primeira refatoração que faremos é em relação as classes que estão na pasta service. Até agora criamos o seguinte código:

??? var testeService:ServiceBase = new ServiceBase(“Teste”);

Ao invés de criar a instância de ServiceBase repassando uma string que é o nome da classe, iremos criar a classe TesteService, da seguinte forma:

package services
{
??? public dynamic class TesteService extends ServiceBase
??? {
??????? public function TesteService()
??????? {
??????????? super(“Teste”);
??????? }
??? }
}

Veja que, ao criarmos a classe TesteService, podemos alterar o código da aplicação principal da seguinte forma:

var testeService:TesteService = new TesteService();

Implementando o SWIZ

Um dos melhores benefícios que o SWIZ traz é a possibilidade de separar todo o código Flex em camadas, assim como é feito no padrão MVC. Se você ainda não conhece SWIZ, é melhor conhecer, pois se está lendo este artigo está procurando criar aplicações com uma qualidade melhor e não há como chegar a esse nível sem um framework. O Swiz é o o melhor em termos de custo/benefício, porque nao é o mais fácil de aprender nem o mais complicado, e nao é o mais simples e nem o mais completo. É o meio termo em tudo.

Para usarmos o SWIZ, preciamos estabelecer algumas pastas dentro do projeto Flex, que serão nossas camadas. São elas:

• config: contém os arquivos que chamamos de “bean”, que são os arquivos que fornecem informações para serem injetadas em outras classes
• controllers: contém os arquivos que “ditam” a dinamica da camada de visualização
• services: contém os arquivos que fazem o acesso ao PHP
• events: contém eventos que podem ser disparados e mediados pelo flex
• valueObjects: são os VOs que iremos usar na aplicação
• views: contém os formúlários, é a camada de visão

Na pasta config, iremos criar o arquivo Bean.mxml, com o seguinte código:

??? xmlns:fx=”http://ns.adobe.com/mxml/2009″
??? xmlns:s=”library://ns.adobe.com/flex/spark”
??? xmlns:swiz=”http://swiz.swizframework.org”
??? xmlns:services=”services.*”
??? >
???
???
???

?

Neste bean, criamos a variável “testeService”, que é o tipo TesteService. Atenção quando ao uso de letras maiúsculas e minúsculas.? Sempre voltaremos no Bean.mxml para adicionar mais variáveis e com isso, injetá-las nos formulários e controllers da aplicação. Precisamos ainda configurar o Swiz no projeto principal da aplicação (melhoresPraticas.mxml):

http://ns.adobe.com/mxml/2009″
?????????????? xmlns:s=”library://ns.adobe.com/flex/spark”
?????????????? xmlns:mx=”library://ns.adobe.com/flex/mx”
?????????????? xmlns:swiz=”http://swiz.swizframework.org”
?????????????? minWidth=”955″ minHeight=”600″ xmlns:config=”config.*”>
???
???
???????
???????????
???????????????
???????????
???????????
???????????
??????????????? ??????????????????? eventPackages=”events.*”
??????????????????? viewPackages=”views.*”
??????????????????? />
???????????
???????????
???????????
???????????????
???????????
???????????
???????
???

???

?

Esta configuração, adicionada dentro do fx:Declarations, realiza uma configuração padrão no SWIZ. Basicamente adicionamos o Bean que criamos e definimos onde as classes relacionadas a eventos e formulários ficarão. Também definimos um LOG que será apresentado na aba Console do Flex se estiver rodando em modo de Debug.

Após a configuração

Podemos por exemplo criar a tela de login, e outras telas do sistema. Deixarei o código fonte da aplicação para que você possa olhar com calma.

Pegue o código fonte aqui

Conclusão

A lista a seguir é um resumo de melhores práticas que julgo importantes

• Use módulos/sub applications somente se precisar mesmo. Não comece um projeto de 10 telas querendo usar módulos para cada tela.
• Separe sua aplicação em camadas. Você escreve mais e cria mais artigos, mas o projeto fica mais consistente.
• Você não precisa criar o arquivo services-config.xml para conectar sua app no servidor. Pode-se criar uma classe cujo o endpoint é um caminho RELATIVO ao gateway.
• Use o caminho RELATIVO sempre, para faclitar o deploy da sua app. Isto é, use “../gateway.php” ao invés de “http://localhost/gateway.php”.
• Injete o controller na view, para passar dados à ela. Se deseja enviar mensagens para a view, então use eventos
• Não injete a view no controller.
• Use o dispatcher do SWIZ.
• Use o serviceHelper do SWIZ.
• Quando criar um formulário na view, faça o databind com uma variável do controller.
• Use eventos com moderação. Particularmente eu uso os eventos para notificar a view de alguma mudança, nunca para passar dados, que é função do controller.
• Se você quer chamar um método da view pelo controller, use eventos.
• Mais?

Ontem a Adobe lançou a última versão do Adobe Flash Player, a 10.2, essa versão recebeu atenção especial com relação a exibição de conteudo de video (com a nova classe StageVideo), visando melhorar a performance e diminuir o consumo de CPU. Foram lançadas as versões para Mac, Windows e Linux.
Entre outras novidades temos a opção de usar fullscreen em multiplas tela e também a possibilidade de usar cursores personalizados.
Atualize seu Flash Player e acompanhe o resto das novidades diretamente do blog dos produtores do Flash Player.
E para quem é desenvolvedor, segue o link das versões debugger do Flash Player 10.2 http://www.adobe.com/support/flashplayer/downloads.html

A dica Flex de hoje é a respeito de um objeto muito utilizado quando trafegamos dados entre o Flex e o back-end da nossa aplicação. Estamos falando dos Value Objects, também chamados de Data Transfer Objects (DTOs) ou apenas Transfer Objects, que têm como principal função o armazenamento de dados e que, ao contrário de outros componentes, estão livres de qualquer lógica de negócio. Os Value Objects são implementados como classes ActionScript.

Vamos supor que estamos desenvolvendo em nossa aplicação uma tela onde deveremos listar todos os usuários do sistema. Ao chamar um serviço no back-end recebemos a lista de usuários, sendo que cada um dos elementos dessa lista é representada por um Value Object como mostramos abaixo:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
package vo

{

    [Bindable]

    public class UsuarioVO

    {

        public var nome:String;

        public var email:String;

        public var senha:String;



        public function UsuarioVO()

        {

        }



    }

}

Repare que no trecho de código acima criamos um package chamado “vo” e dentro deles criamos uma classe ActionScript chamada “UsuarioVO.as”. Repare que a tag “Bindable” é utilizada antes da definição da classe, justamente porque queremos garantir que todos os atributos do nosso Value Object possam utilizar o data binding, ou seja, que suas alterações possam ser monitoradas por componentes do Flex. Lembrando que também poderíamos definir o data binding individualmente para cada atributo dessa classe ao invés de definir para a classe toda.

Uma outra dica interessante é definir o método toString() nas nossas classes, dessa forma toda vez que você utilizar seus Value Objects em lugares que o Flex precisa mostrar uma String, esse método será invocado automaticamente pelo Flash Player. Essa dica pode auxiliar nos traces e debugs da sua aplicação.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
package vo

{

    [Bindable]

    public class UsuarioVO

    {

        public var nome:String;

        public var email:String;

        public var senha:String;



        public function UsuarioVO()

        {

        }



        public function toString():String

        {

            return "Usuário: " + this.nome;

        }



    }

}

Espero que tenham gostado e até a próxima!

Twitter!

Umas das coisas que eu acho mais interessante quando estou desenvolvendo para Adobe AIR é a facilidade de realizar as atualizações da aplicação, é muito simples e fácil de implementar uma maneira automatica para as atualizações. Na verdade a implementação já existe, só é preciso saber como utilizar.

Neste post vou falar um pouco sobre o framework de update das aplicações air e como tirar proveito disso com um processo deployment também automatico utilizando ANT para compilar o projeto e Hudson para separar os ambientes e etc.

Air Update Framework – Atualização da aplicação

O framework de update do air trabalha basicamente com 3 coisas:

A classe ApplicationUpdaterUI e os arquivos de configurações update.xml e updateConfig.xml . Independente de como será feito o deployment da sua aplicação, o modo de atualização será sempre baseado nesta classe e nestes arquivos.

Você também pode utilizar esta classe atribuindo manualmente as propriedades que são lidas pelos arquivos de configuração, entretanto, com arquivo é possível alterar os valores depois que o AIR ja tiver sido compilado.

ApplicationUpdaterUI

Esta classe utiliza o arquivo de configuração updateConfig.xml para saber aonde procurar por uma atualização e informar em caso exista uma versão mais recente.

Esta classe precisa basicamente de 3 coisas.

1. Setar a propriedade configurationFile com o arquivo updateConfig.xml
2. Inicializar
3. E verificar se há uma nova versao.

Segue abaixo um trecho de código com a utilização:

No projeto que irei disponibilizar no final do post eu estou utilizando a classe VersionManager criada aqui na DClick para facilitar um pouco essa parte de configurar e inicializar o updater

updateConfig.xml

Dentro do arquivo updateConfig.xml está todas as configurações de como a verificação de novas atualizações serão feitas. A classe ApplicationUpdaterUI lê estas informações durante a inicialização.

update.xml

Este arquivo contem a informação de qual é a versão atual do sistema e onde baixa-la. O update framework compara a versão do software que está sendo executada ( token <version> dentro do xml que descreve a aplicação air ) e caso for diferente da que esta no update.xml ele irá tentar fazer atualização para a nova versão.

ANT Task – Compilação através de linha de comando

Agora que agente ja viu como funciona o sistema para atualização de versão dos aplicativos AIR, podemos podemos deixar o processo de distribuição ainda mais rapido. Vamos ver como gerar a nova versão pelo plugin do flex e depois como gerar utilizando um script ANT

O plugin do flex possibilida fazer o export do projeto para o arquivo .air, basta clicar em project/export release build (imagem abaixo).

Entretanto deste modo cabe a você antes de executar o export configurar qual será a nova versão do aplicativo, e para qual ambiente ( producao/teste/cliente/etc ) você esta compilando esta nova versão.

Em um projeto desenvolvido com integração continua com o cliente, onde varias versões são compiladas durante o desenvolvimento, fazer o build da aplicação não é a melhor escolha.

Uma alternativa é criar um script ANT para buildar o projeto, com ele é possível buildar o projeto e a cada build alterar a versão do aplicativo, deste modo sem muito esforço você tem uma maneira mais prática para gerar as versões da aplicação. O esforço fica em criar o script a primeira vez porque dependendo do tamanho do projeto ( dependencia entre outros projetos, etc ) o script pode ficar grande e complexo.

No final do post vou deixar um link para um projeto no github, a ideia é que este projeto funcione como um template básico para quando for desenvolver um app em air, pois ele ja define a estrutura de pastas build/ambiente e também um script ANT padrao para buildar o projeto de acordo com cada ambiente que for necessário. O script esta todo comentado, de modo que é possível enter cada passo que esta sendo feito.

Como funciona o ANT para o Flex/Air?

O script é dividido em targets ( passos ) que são executados numa ordem definida pelo criador.

Por ex: Os passos básicos para gerar o .air são

1. Compilar o projeto e gerar o swf.
2. Gerar o instalador .air a partir do swf.

Compilação do SWF:

Para compilar o projeto e gerar o swf o script ANT utiliza um jar chamado flexTasks.jar. Primeiro é necessário incluir este jar dentro do script atráves da tag <taskdef /> do ant ( veja abaixo ):

Depois de incluir o jar como recurso é possível compilar o projeto utilizando a tag  ( veja abaixo ):

Este exemplo foi extraido do script ANT que está no projeto template. Para ver mais detalhes sobre como utilizar a tag veja o link da adobe

Gerando o .AIR

Uma vez que você ja compilou o projeto e ja gerou o .swf, para gerar o .air você irá utilizar o jar .adt ( Adobe Developer Tool ). Diferente do flexTask.jar, o adt nós não vamos incluir como recurso no script, vamos executa-lo através da tag

Veja abaixo um exemplo extraido do script que esta no projeto de template:

Com o ADT é possível gerar o .air já autenticado com um certificado ou simplesmente gerar um arquivo .airi sem autenticação e depois em um outro passo autenticar este arquivo intermediario. Para ver mais detalhes dos argumentos que o ADT recebe como passa-los segue o link da adobe

Como alterar a versão da aplicação a cada build?

Apesar de nós já termos visto como é feita a compilação do swf e como é gerado o .air, ainda não vimos como alterar a versão da aplicação a cada build. Muito bem, no script que está no projeto template, isto é feito através da tag Esta tag recebe como parametro um arquivo, e sempre que é executada ela incrementa em um o valor numerico que está dentro do arquivo. Portanto já temos um contador para cada versão. Um dos parametros que o ADT recebe é o ${app.description.final} que na verdade é uma variável que está apontando para xml que descreve esta versão, tudo que temos que fazer é antes de rodar o ADT, alterar o token  deste xml.

Veja abaixo a sequencia de como isto é feito no script que esta no projeto template.

Nestes 3 passos nós atualizamos o numero da versão do ambiente que esta sendo compilado, montamos o codigo final da versão ( neste caso V1, V2, V3 ) e em seguida alteramos o node <version /> do xml que descreve a aplicação  de <version>[version]</version> para <version>v1</version>.

Na próxima vez que rodar o script o token será alterado novamente de <version>[version]</version> para <version>v2</version>. E assim sussesivamente.

Utilizar o Hudson para buildar o projeto com o script ANT

Apesar de ja estar utilizando o ANT para buildar o projeto e o update framework para verificar atualizações, não é muito interessante que o desenvolvedor tenha que ficar rodando manualmente o script ant, e sendo responsável por compilar o ambiente correto e etc. Para fazer este trabalho nós vamos utilizar o hudson.

Com o hudson você pode configurar um job que irá rodar o script ANT de maneira automatica. Além disso, o hudson pode ser integrado com o repositório de código ( git, subversion, cvs, etc ). Portanto após todos os commits da versão serem feitos, basta executar o job do hudson que ele ira baixar todas as alterações no código e em seguida executar o ANT para gerar a nova versão.

No script ANT o parâmetro que indica para qual ambiente estamos rodando é fornecido pelo Hudson, deste modo, para cada ambiente vamos criar um job no hudson.

Abaixo segue um screencast passo a passo de como criar um novo job no hudson ja integrado com o projeto template que esta no github e disponível para download.

Para aqueles que quiserem ver mais detalhes sobre o Hudson, segue o link oficial.

Segue o url para o pessoal que quiser dar uma olhada nos fontes ou até mesmo baixar o projeto/template com essas configuracões de ANT e etc.

http://github.com/thiagofelix/Air-Atualiza–o-Automatica