Recentemente contei com a participação de um desenvolvedor .net em um projeto Flex e a partir disso surgiu alguns questionamentos sobre boas práticas para definir nomenclaturas. Uma vez que viemos de berços diferentes, comecei a me questionar se meu padrão de desenvolvimento estava realmente correto. De maneira resumida este Post apresenta boas práticas de nomenclatura usada em Flex e recomendadas pela Adobe.
-> A escolha de bons nomes é essencial para criar um código de fácil entendimento. Gastar tempo pensando na nomenclatura é um investimento e não perda de tempo. Isto evita encontrar incógnitas no código como variáveis nomeadas de “temp” ou “global”.
-> É importante evitar a qualquer custo o uso de
abreviações, elas podem fazer sentido no momento do desenvolvimento mas no futuro pode gerar desgaste excessivo no seu entendimento. Ser claro é mais importante do que minimizar o tamanho da variável ou função. Salvo alguns casos que as maiorias dos programadores já estão acostumados.
-> Ao incorporar o
tipo ao nome da variável opte por adicioná-lo ao final precedida de underscore. Ex: title_label, title_form, title_button;
->
Pacotes devem ser nomeados com substantivos ou gerúndios. Utiliza-se sempre iniciar o nome de pacote com letra minúscula;
-> Interface sempre inicia com I em letra maiúscula concatenado com o nome a ser dado. Ex: IColorBar, IButton;
-> Classes são nomeadas com a primeira letra de cada palavra em maiúsculo. Ex: ColorBarEvent, ColorBarController, ColorBar;
-> Eventos e Estilos iniciam com letra minúscula seguido de letra maiúscula antes de cada palavra. Ex: creationComplete, preInitializer, color, fontSize;
-> Constantes, são representa sempre com letras maiúscula e "_" (underscore) entre as palavras. Ex: COLOR_OVER, COLOR_OUT;
-> Métodos são iniciados com letra minúscula precedido de letra maiúscula nas outras palavras.Ex: addChild, addElement;
-> Ouvintes de eventos, devem sempre ter a palavra "Handler" no final do nome dado. Ex MouseUpHandler, creationCompleteHandler.
Quando comecei a desenvolver em Flex, tive algumas dificuldades para entender por que alguns atributos em MXML não são atributos em ActionScript. O Post de agora, vem explicar um pouco esta diferenciação que a Adobe fez, e mostra algumas facilidades que o MXML traz, ao permitir que eventos e Estilos sejam definidos como atributos no MXML.
MXML == ActionScript
ActionScript é a principal linguagem para o Flash Player. Logicamente você pode criar toda sua aplicação usando apenas uma ou várias classes em ActionScript. Mas devido aos vários benefícios, podemos usar o MXML para deixar a construção bem mais fácil e intuitiva. O MXML já é uma linguagem que vem facilitar a utilização do ActionScript, mas o resultado final de um MXML é um Action Script.
A tradução de uma linguagem MXML em ActionScript pode ser vista, com uma configuração no Flex. Para isto vá em, Project -> Properties. No canto direito da nova tela. Vá a Flex Compiler.
Em Additional Compiler Arguments, digite o argumento -keep, separado por espaço do argumento anterior.
Quando o projeto for compilado será gerado na pasta raiz do projeto, uma nova pasta com o nome genereted, que conterá todos os ActionScript gerado, pelo MXML, esta pasta é atualizada toda vez que você compila o projeto.
Voltando agora no relacionamento do ActionScript com MXML.
Tags de MXML são Classes em ActionScript
As tags de MXML tornam se classes. Por exemplo criando um Button in MXML, devemos escrever a seguinte linha de código.
depois de compilado este código será equivalente a
// Botão em ActionScript 3.0
import mx.controls.Button;
public function init():void{
var okButton:Button = new Button();
addChild(okButton);
}
Atributos são propriedades
Quando você adiciona atributos a tag, basicamente você esta mudando propriedade daquela instancia do componente. Por exemplo quando mudamos a Label do Botão em MXML teríamos.
<!-- MXML -->
<mx:Button id="okButton" label="Ok" />
que seria equivalente há
// em ActionScript
import mx.controls.Button;
var okButton:Button = new Button();
okButton.label = "Ok";
addChild(okButton);
Atributos são Estilos
Uma grande confusão é feita, quando temos que mudar estilos em Action Script. Estilo são propriedades especiais do Flex, e são usadas para controlar a aparência do componente. Enquanto um estilo é considerado propriedade no MXML em ActionScript as coisas ficam um pouco diferente, neste temos que trabalhar de maneira diferente usando os metodos gstStyle() e Setstyle(). Por exemplo para arredondarmos o canto dos botões devemos usar a propriedade cornerRadius.
Em MXML temos
<!-- MXML -->
<mx:Button id="okButton" cornerRadius="14"/>
Seguindo a Lógica do tópico, acima iríamos fazer "okButton.cornerRadius=14", mas você perceberá um erro do compilador, uma vez que ele não var achar a propriedade cornerRadius. Ao invés disso devemos usar o método SetStyle. Este método tem dois parâmetros o primeiro o estilo da propriedade, e o segundo o valor que queremos definir
// ActionScript
import mx.controls.Button;
var okButton:Button = new Button();
okButton.setStyle("cornerRadius", 14);
addChild(okButton);
Atributos são EventListeners.
EventListeners, é a solução encontrado pelo desenvolvedor para dizer quando acontece alguma interação com ele, como um click de mouse. EM MXML já temos pronto o atributo para ouvir este evento. Isto não acontece com em Action Script onde temos que chamar o método addEventListener para ai sim definir qual evento usar, e conseqüentemente qual método iremos chamar
<!-- MXML -->
<mx:Button id="okButton" click="doSomething"/>
fazendo em ActionScript, teríamos, "okButton.click = doSomething()". Mas novamente teríamos um Erro. Em ActionScript devemos Usar o addEventListener, assim ficaria.
// ActionScript
import mx.controls.Button;
var okButton:Button = new Button();
okButton.addEventListener(MouseEvent.CLICK, doSomething);
addChild(okButton);
Adicionando alguns desafios no desenvolvimento em Flex e consequentemente adotando boas pratícas de programação, fui enconrajado aplicar o padrão de projeto MVC no meu atual desafio. Trata-se de um sistema em Flex onde iremos fazer consultas e alterações no Banco de Dados.
O MVC é um excelente padrão de projeto para se aplicar durante o desenvolvimento de aplicações Flex, ele divide as responsabilidade do projeto, facilitando assim seu reuso de codígo, e manutenção.
Uma boa analógia a se fazer com o padrão MVC é o funcionamento de uma empresa bem administrada. A empresa possuí varias equipes que se interegem entre si, sem que estas, interfira no funcionamento da outra.
Uma contratação de um desenvolvedor por exemplo, é um trabalho conjunto da equipe de RH com a equipe de Desenvolvimento. A equipe de RH jamais deve interferir no trabalho da equipe de desenvolvimento e sim obter informações desta equipe sobre o perfil do futuro desenvolvedor. Por sua vez a equipe de desenvolvimento não deve interferir no processo de seleção do usuário. Somente validar se o profissional definido pela equipe de RH é realmente o profissional desejado.
O padrão MVC trabalha da mesma Forma. Ele separa as classes em três "Equipes" distintas. A parte mais importante para se entender deste projeto é a sua divisão e a comunicação entre estas "equipes". A seguir detalhe da divisão, neste momento irei definir "equipes", como classes.
*
Model -> Armazena dados e toda a logída da aplicação para ser consumida na interface.
*
View -> Toda interface do usuário vai estar aqui.
*
Controler -> Responsável pelas alterações que o usuário var fazer na View e consequentemente alterar os dados da Model
Pegando uma check Box como exemplo teríamos.
* Model -> Esta deverá armazenar o estado da Caixa, se esta marcada ou desmarcada. Informações que normamelte estão gravadas em algum lugar.
* View -> Trata do layout da aplicação, neste caso usando o componente CheckBox do Flex, temos somente a caixinha em branco no estado desmarcado, ou caixinha colorida no estado marcado
* Controler -> Esta define quais são as atitudes que a camada View terá quando o usuário clicar ou cometer qualquer tipo de ação neste botão. O resultado desta interação será armazenada na Model;
Vale salientar que a camada View, não se trata apenas da visualização dos dados, mas sim de qualquer interação com o usuário, como por exemplo audio ou vibração de um controle.
Comunicação entre as Classes
Depois de entender a segregação das classes, devemos entender como funciona a comunicação entre as mesmas.
* A camada MODEL deve enviar notificações de estado para controlar as modificações da camada VIEW.
* A camada VIEW por sua vez, deve registrar na CONTROLLER o recebimento das interações do usuário, solicitando dados da MODEL.
* A camada CONTROLLER deve atualizar a MODEL e consequentemente atualizar a VIEW, com o resultado esperado pelo usuário.
Para facilitar a comunicação, cada objeto em MVC deve armazenar referencias dos outros objetos junto com suas interações. Especialmente a instancia Model precisa referenciar a View, para que a mesma seja rendenrizada.
Responsabilidade de cada Classe
Model
Como ja dito anteriormente sua principal função é armazenar os dados e fornece a aplicação metodos especificos para trabalhar com estes dados e validalar serviços. Citando o exemplo de uma aplicação de um Relogio analogico, a Model irá cuidar de disparar o metódo que irá ter o Tick (segundos) do relógio.
View
Tudo que se relaciona com o usuário deve estar na VIEW, a view é um ouvinte das açoes do usuário e das alterações que ocorre na Model, no exemplo do relógio acima, cada alteração do metodo Tick na Model, teremos uma alteração no ponteiro do relogio que esta na VIEW. É importante salientar, que qualquer mudança feita na view pelo usuário, esta deve ser alterado na Controler para ai sim, alterar algo na Model, a View nunca fará alteração diretamente na Model, o contrário já pode acontecer.
Controller
Esta camada ouve notificações de alterações da dados na Model pela View. A controler pode tambem fazer decisões logicas sobre a entrada destes dados, antes de enviar informações para a Model.
De maneira bem resumida e simplificada este é o padrão MVC, atualmente estou desenvolvendo a aplicação e estou desenvolvido toda a classa View. É interessante pensar que algumas coisas que eu fazia no MXML devem ser feitas agora na classe Controler. Assim que for encarando novos desáfio na utilização deste framework vou relatando. Em um novo Post.
Depois de solidificar os meus conhecimentos no desenvolvimento de aplicações Flex, comecei a ficar atento sobre como reduzir o tamanho e melhorar a performace da aplicação.
Meu primeiro Post, foi justamente sobre este assunto, mas falei especificamente sobre o Framework RLS, que foi implantando no Flex 3, e ganha mais poder no Flex 4 (beta 2), onde esta configuração passa a ser default. Agora opto por mensurar a performace de uma aplicação, ficando assim mais facíl de identificar os pontos onde a aplicação consome mais recurso, ou leva mais tempo para ser executada, consequentemente posso pensar na melhor maneira de melhorar o algoritimo ainda no processo de desenvolvimento.
Calculando o tempo de inicialização de uma aplicação.
Desde os tempos de Flash, temos no pacote flash.utils o método getTimer() que retorna o tempo gasto pela aplicação para ser inicializado no Flash Player. No exemplo a seguir é registrado o tempo exato que uma aplicação demora para ser inicializada, não nos interessa neste momento o tempo de carregamento da aplicação nem muito menos o tempo gasto para identificar o versão do Flash Player. O valor retornado é exatamente o tempo gasto para rodar a aplicação, como se fosse o carregamento do Windows.
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"
layout="absolute"
creationComplete="callLater(getSpendTime)"
width="300" height="100"
>
<mx:Script>
<![CDATA[
import flash.utils.getTimer;
[Bindable]
private var _timer:String;
private function getSpendTime():void{
_timer = "Tempo de carregamento: " + getTimer() + " ms";
}
]]>
</mx:Script>
<mx:Label
verticalCenter="0"
horizontalCenter="0"
text="{_timer}"
/>
</mx:Application>
Este exemplo chama o método callLater() para garantir que a aplicação terminou sua inicialização e so assim chama o metodo getTimer()
[View:/cfs-file.ashx/__key/CommunityServer.Components.UserFiles/00.00.00.21.45.Post.Post02/Initialize.swf]
Sempre que criamos uma aplicação Flex, fazemos grande uso de Classes ActionScript que estão na infra-estrutura do Flex ou de Bibliotecas específicas. Uma maneira de reduzir consideravelmente o tamanho de uma aplicação é disponibilizando estas informações na maquina do usuário, fazendo com o que o mesmo faça o dowload apenas uma vez, e assim todas as aplicações compartilharam dessas bibliotecas. Este recurso compartilhado é conhecido como RSLs (Runtime Shared Libraries).
Atualmente temos dois tipos de Bibliotecas RSLs (Signed e Unsigned), esta diferenciação basicamente define em qual cache(Flash Player ou Browser) estes arquivos serão armazenadas.
O Framework Signed são arquivos *.SWZ feitos pela Adobe e vão diretamente para o cache do Flash Player e do browser, podem ser utilizados por qualquer aplicação independente da origem da aplicação.
Já o framework Unsigned do tipo *.SWF ira somente para o cache do navegador e somente podem ser acessados por aplicações que possuem este domínio configurado.
Framework de verificação do RSL (RSL Digest)
Como podemos ter várias versões do Framework RSLs, o flash player cria uma sumarização (Digest) para verificar se a versão existente no cache da maquina é a solicitada pela aplicação. Se a validação for valída a aplicação carrega a o RSL. Caso não, o flash player dispara um erro e tenta carrega o RSL de outra fonte.
Flash Playe Cache
Como dito acima o Flash Player armazena o Framework RSLs, somente signed RSLs podem ser armazenada no Player Cache.
Por default o tamanho do cache é 20 Mb, mas você pode usar este link para fazer a configuração mais adequada. Nele você poderá configurar o espaço alocado para cache, como também desabilitá-lo.
Utilizando o Framework RSLs no Flex Builder 4 beta 2.
Por default, nesta versão do flash a utilização do Framework RSLs esta habilitada, mas mesmo assim, você pode efetuar configurações e definir quais arquivos usar como RSLs.
Com o projeto aberto, vá em Project -> Properties no canto esquerdo da tela de propriedades, escolha Flex Build Path.
Propriedade de um projeto
Nesta tela podemos configurar o framework Linkage. Trata de como o arquivo final vai ser composto.
Merge into Code (Incorporar ao Codigo) -> Indica que todas as classes e bibliotecas serão adicionadas ao SWF, gerando um arquivo sem nenhuma dependencia e consequentemente grande. Neste caso, a aplicação não precisa tentar carregar as bibliotecas externamentes do cache ou de outros reposítorios. Tudo é carregado em um arquivo uníco todas as vezes que a aplicação é carregada.
RSL -> Nesta opção a aplicação irá carregar o Framework RSL, o que significa um arquivo SWF menor, e as bibliotecas ficarão fora da aplicação carregada somente uma vez na maquina do cliente.
A grande sacada da utilização deste Framework, se faz quando o usuário armazena estas bibliotecasem cache (mesmo que sem saber), o usuário ganha pois não precisará fazer dowloads de arquivos redundates, e o desenvolvedor poderá disponibilizar aplicações bem mais leves.
Uma simples aplicação "Hello World", demonstra claramente a diferença entre usar o framework ou não .
<s:application minheight="768"
minwidth="1024"
xmlns:mx="library://ns.adobe.com/flex/halo"
xmlns:s="library://ns.adobe.com/flex/spark"
xmlns:fx="http://ns.adobe.com/mxml/2009">
<s:label horizontalcenter="0" verticalcenter="0" text="hello World"></s:label>
</s:application>
Abaixo, os arquivos gerados pelo Flex, utilizando a opção "Merge Into Code", onde o arquivo Project.flw ficou com 471kb.
Diferente do resultado obtido quando gero utilizando a opção "Runtime Shared Library", onde o arquivo Project.flw fica com 99Kb.
É perceptível, que são gerados novos arquivos, quando fazemos o uso deste Framework. Estes arquivos são justamente as Bibliotecas que irão para o cache da maquína, e serão carregados somente uma vez.