Como utilizar o método “getDefinitionByName(“MyClassLibrary”)”

A vantagem em utilizar o método “getDefinitionByName()” é que você consegue instanciar objetos da sua biblioteca de forma dinâmica. Mas, como assim de forma dinâmica? Quer dizer que existe outra forma de instanciar um objeto além dessa: new MC()? Exatamente. Primeiro abra seu Flash e crie um “MovieClip” retangular de 117 x 154 ou das dimensões que você preferir. Depois seta o AS Linkage d0 mc para “MC”, como na figura 1 abaixo.

Figura 1

Vamos adicionar esse mc criado ao palco na forma convencional.

var mcCriado:MovieClip = new MC();
mcCriado.x = 30;
mcCriado.y = 30;

addChild( mcCriado );

Agora, utilizado o “getDefinitionByName(“”)“. A primeira etapa é criar uma variável do tipo “Class” que vai receber a classe capturada pelo método “getDefinitionByName(“”)“. Isso pareceu estranho, então vamos ver como funciona na prática.

import flash.utils.getDefinitionByName;
import flash.display.MovieClip;

/*var mc:MovieClip = new MC();
mc.x = 30;
mc.y = 30;

addChild( mcCriado );*/

var MyClass:Class = getDefinitionByName( "MC" ) as Class;
var mc:MovieClip = new MyClass();
mc.x = 30;
mc.y = 30;

addChild( mc );

Éeee funcionou, mas e aí? Eu poderia fazer sempre da forma convencional, que funcionaria da mesma forma que essa utilizando o “getDefinitionByName(“”)”
Isso é verdade e eu concordo com você. Mas a vantagem de utilizar o “getDefinitionByName(“”)” é a forma dinâmica como eu disse acima.
Vamos supor que você precisa instanciar 5 mcs que estão na biblioteca. Ao invés de você fazer dessa forma:

var mc1:MovieClip = new MC1();
mc1.x = 30;
addChild( mc1 );

var mc2:MovieClip = new MC2();
mc2.x = 130;
addChild( mc2 );

var mc3:MovieClip = new MC3();
mc3.x = 230;
addChild( mc3 );

var mc4:MovieClip = new MC4();
mc4.x = 330;
addChild( mc4 );

var mc5:MovieClip = new MC5();
mc5.x = 430;
addChild( mc5 );

var mc6:MovieClip = new MC6();
mc6.x = 530;
addChild( mc6 );

você pode fazer assim:

for ( var i:uint = 0; i < 5; i++ )
{
var MyClass:Class = getDefinitionByName( "MC" + (i+1) ) as Class;
var mc:MovieClip = new MyClass();
mc.x = 30 + (i * 100);
addChild( mc );
}

E você obterá um resultado parecido como na figura 2,  independente da forma utilizada. Mas note que, com um simples laço de repetição, você simplifica bem seu código. Sem falar nas vantagens de setar valores das propriedades do seu objeto pela interação de cada repetição no laço.

Ok, já aprendi a utilizar o “getDefinitionByName(“”)“, mas eu consigo instanciar apenas “MovieClip”?

Não, você pode utilizar também para instanciar “BitmapData” e “Sprite“.

Para utilizar com imagem é bem simples e funciona da mesma forma. Importe uma imagem para sua biblioteca e depois nomeie seu “AS Linkage” para “IMG“, como na figura 3.

A única diferença é que agora vamos instanciar um “Bitmap” ao invés de um “MovieClip“.

import flash.display.Bitmap;
import flash.utils.getDefinitionByName;

var MyClass = getDefinitionByName( "IMG" ) as Class;
var bmp:Bitmap = new Bitmap( new MyClass() );
bmp.x = 20;
bmp.y = 20;
bmp.smoothing = true;
addChild( bmp );

Pronto, adicionamos uma imagem e poderíamos também adicionar imagens, como no laço de repetição mostrado acima com MovieClips.
Você também pode utilizar essa técnica para dispositivos móveis com Adobe AIR sem problemas.

Mas cuidado, se você estiver utilizando o Flash Builder com SWC você vai precisar utilizar o new MC() ou new IMG(), independe do nome que estiver seu mc ou imagem na biblioteca. Você precisa fazer isso para anexar seu objeto na VM do FlashPlayer ou Adobe AIR. Depois de instanciar seu objeto, você pode utilizar o “getDefinitionByName(“”)” sem problemas.

OBSERVAÇÃO.

Caso você queira obter qual é a classe de origem do seu objeto, você pode utilizar o método “getQualifiedClassName” veja:

import flash.display.Bitmap;
import flash.utils.getDefinitionByName;

var MyClass = getDefinitionByName( "IMG" ) as Class;
var bmp:Bitmap = new Bitmap( new MyClass() );
bmp.x = 20;
bmp.y = 20;
bmp.smoothing = true;
addChild( bmp );

trace( getQualifiedClassName( bmp ) );

Observe que o retorno foi “flash.display::Bitmap” é não IMG como definido. Mas se você estiver utilizando para Sprite e MovieClip o retorno vai ser a classe definida e não “flash.display::Sprite” ou “flash.display::MovieClip“.
Espero que esse material te ajude de alguma forma.

Documentar ou não…

E ae galera,

Esse assunto é complicado, muitos acham que documentar o código é uma perda de tempo e outros acham isso extremamente necessário.

Documentar é quase uma arte! Em especial para geração dos Docs, no caso do actionscript gerados com o asdoc (onde você pode navegar entre os pacotes e classes através de páginas HMTL), e, para algumas IDEs ele também ajuda com o code hint (aquele “box” que aparece a descrição de algum método ou classes).

É de grande ajuda, principalmente para quem gosta de escrever APIs, componentes e vários outros tipos de aplicações e isso realmente consome um tempo considerável (descrevendo de maneira clara o que determinada classe ou método faz, determinar qual versão minima do flash player (para AS), autor, versão da API, licença e mais um monte de informação…).

Escrever uma API extremamente documentada é até legal (no final quando você vê todos o métodos e classes com aquelas linhas cinzas de comentários). Isso eu estou vendo enquanto escrevo o Kindergarden – https://github.com/diasbruno/kindergarten/.

Depois de ver a paletra do Phil Japikse, link,  quase morri de rir com o modo que ele fala sobre documentação, e pior, é tudo verdade. Basicamente, essa palestra me motivou a escrever esse post, mas claro…também coloco algumas ideias minhas.

Grandes blocos de comentários, várias especificações, comentários incompletos (sempre tem), TODOS, NOTES…é muito bom, parece bem organizado, e como falei, existe um tempo gasto para escrever tudo isso. Esse tempo gasto que gera a preguiça de escrever. E depois você ainda reclama de vai ficar ouvindo as pessoas da equipe perguntando: “Ei…isso aqui faz o que?”.

Mas,…existe alguns detalhes na escrita da documentação que são até engraçados de ver. Quem não tem um código como esse em algum projeto?:

// Pega todos os posts do repositório como Array.
var postList:Array = this.postRepository.getAll();

É engraçado porque na maior parte do tempo nós documentamos coisas onde, com uma boa escrita dos nomes das classes, métodos e variáveis, é puramente repetição do que a linha de código diz.

Então esse é o caso onde boas práticas de programação evitam linhas e linhas de comentário, práticas como:

 

• Classes, métodos e variáveis devem fazer uma única coisa. Se uma função faz mais do que ela deveria, fica mais difícil de nomea-la corretamente e provavelmente será difícil reutiliza-la, já que ela faz essa operação amais. Isso também ajuda a remover duplicações no código.

• Separar código pela sua especialidade. Se um determinado código é responsável por pegar informação de algum servidor/api como Facebook, Twitter ou sistema, faça dele um objeto ou classe específico para trabalhar com isso. Isso ajudará na reutilização e na manutenção/aprimoramento desse código. Ex.: Não usar o mesmo objeto para montar a view e fazer requisições. Não usar objetos que trabalham com requisição de informações de domínios diferentes.

Não é errado escrever comentários dentro da função. Ainda há casos onde é interessante documentar, principalmente quando você utiliza uma API de outro desenvolvedor e ela não é 100% clara. Então para esclarecer onde é preciso, comente explicando o que a linha faz.

Outra coisa que aparece…

public class PostRepository {
public function PostRepository( dataContext: IDataContext ) { ... }
...
/**
 * Esse método retorna todos os posts do IDataContext, que podem ser
 * do banco de dados, de arquivo(s) ou outro tipo.
 * Caso não haja informação, o retorno será uma Array vazia.
 *
 * @return Array
 */
public function getAll() :Array {
return this._dataContext.getAll();
}
}

Fica muito bonito escrever um bloco de comentário como o do getAll(). Mas, porque você quer saber se ele vai utilizar informações do banco ou de um ou vários arquivos? Ou se o retorno pode ser vazio? Essas informações não são de responsabilidade dessa classe e sim do IDataContext que será utilizado. Então gastamos mais tempo para descrever essas informações onde poderia ser simplificado. Se o método retorna uma Array, ele deve retornar uma Array, mesmo que vazia…nunca “null” – mas isso é outra história .

/**
* Retorna todos os posts do contexto.
*
* @return Array
*/
public function getAll() :Array {
return (this._dataContext != null ? this._dataContext.getAll() : []);
}

Depois dessa, acaba parecendo mesmo muito desnecessário documentar, mas apesar disso tudo…não. A questão é eliminar o tempo gasto com esse tipo de coisa.

Então, para concluir. Documentar ainda continua sendo importante, mas deve ser de maneira objetiva e clara. O código não fica muito poluído e longo, e afinal, quem vai manter esse código depois é você.

 

Espero que ajude! :)

 

Jogando a toalha

Pessoas,

Comunico que a partir de hoje não estou mais à frente do ASDEVs e deixo a bola apenas com o Jay Moretti.

Foi muito legal a experiência como moderador do grupo e continuarei no chat do msn (grupo1337489@groupsim.com) junto com os vários bons desenvolvedores tirando dúvidas e ajudando quando puder.

Grande abraço,

Filipe Cunha

Mesa Redonda sobre Flash Plataform

Muitos desenvovledores da Plataforma Flash já criaram posts sobre a questão do Flash Player e Flex SDK.
Amanhã às 21h, reuniremos todas essas opiniões no endereço https://experts.adobeconnect.com/_a204547676/mesa_redonda/ e todo mundo está mais do que convidado.

Confira quem vai participar.

Stefan Horochovec
Vicente Maciel Jr
Jay Moretti
Fabio Vedovelli
Bruno Ribeiro
Joao Felipe (Justin Bieber)
Lauro Santos
Tofinha
Igor Costa
Odair Seixas
Alex Affonso
Fabio Flatschart
Ystallonne Alves
Neto Leal
Filipe Cunha

A Adobe não matou o Flash, apenas quer definir um lugar para ele.

Então você se assustou com as declarações da Adobe semana passada, mas você sabe dizer porque exatamente?

Não vou discutir aqui se a Adobe fez “a coisa certa” ao descontinuar o Flash Player para mobile por dois simples motivos:

1) A decisão já foi tomada

2) Isso é papo para o dia 19/11 no #FlashCampSP.

Para quem não terá saco de ler o post até o final, já coloco aqui minha conclusão:

Sim, você terá que aprender HTML5 (e agregados) tão bem quanto você sabe Flash/Actionscript se você quiser continuar desenvolvendo front-end para internet e se você está puto com isso, terá dois trabalhos: Um de ficar puto e outro de deixar de ficar.

Vamos ao título do post: A Adobe não matou o Flash apenas quer definir um lugar para ele.

Sejamos muito francos. Quem aqui já pensou em como seu site/aplicação, desenvolvido para o browser do desktop, ficaria no celular? Nós já ficamos putos em ter que pensar nas diferentes resoluções de monitores, layouts fluidos, resoluções mínimas, bla, bla, bla, quanto mais na tela do celular, que pede um projeto totalmente diferente.

Mesmo trabalhando com a plataforma Flash (entre desenvolvimento e design) há +-8 anos, nunca usei o fato do meu Android rodar Flash Player no browser para outra coisa que não fosse sacanear quem tem iPhone, pelo simples fato de que entrar em sites feitos em Flash no browser do celular nunca lembrou, nem de longe, a experiência que tenho no desktop por 2 motivos:

- A performance do Flash Player no dispositivo móvel é muito menor do que no desktop e segundo o post do Mike Chambers, não estava nem próximo de se igualar.

- Tamanho da tela do celular é tão menor que o monitor que apenas dar zoom na tela ou colocar uma série de if/else if na programação não resolve. Tem que ter outro desenvolvimento, com uma leitura do projeto totalmente diferente, o que lembra a época das trevas de criar sites na versão HTML e na versão Flash.

Por muito tempo houveram coisas na internet que somente o Flash pôde oferecer ou oferecia de uma forma muito mais fácil, tanto para usuários como para desenvolvedores, como áudio, vídeo e animações vetoriais, etc.

Surge o HTML5 prometendo fazer algumas coisas que até então só o Flash fazia (e faz, quardada algumas proporções) sem depender de plugins, contudo que você tenha os browsers mais modernos para poder renderizar tudo corretamente.

Essa semana ouvi bastante de pessoas que fizeram sua carreira em cima da Plataforma Flash, coisas do tipo:

- Eu já sou bom o suficiente com o Flash, vou ter que recomeçar do zero com HTML5?

- Eu estava em um ambiente tão confortável (Flash Player) vou ter que voltar para guerra dos browsers?

- Voltar a programar em javascript depois de trabalhar com AS3 por tanto tempo é um puta retrocesso (Essa é minha).

- Porque eu não ouvi minha mãe e estudei Direito ou Medicina??

Esse tipo de sentimento de alguns na comunidade Flash somado aos comentários de pessoas que se dizem jornalistas e adoram anunciar que “O Flash morreu” sem nem saber de onde veio o tiro e ao total despreparo da Adobe em fazer os anuncios da semana passada, causaram uma boa bagunça na cabeça de algumas pessoas, principalmente de quem está começando na área e de lá até aqui não teve um dia que não viesse algum aluno/ex-aluno perguntar se vale apenas continuar aprendendo AS3.

 

Vamos aos fatos:

1) Adobe parou de investir esforços no FlashPlayer para dispositivos móveis

Motivos:

Segundo a Adobe, é muito caro manter uma equipe com foco no desenvolvimento do Flash Player para dispositivos móveis e o retorno em cima desse investimento era quase zero.

A Adobe viu que as pessoas não consomem aplicativos, de qualquer natureza, nos browsers e sim como apps, baixadas na App Store do seu dispositivo (Apple App Store, Android Market, Blackberry App World, etc).

E agora?

Segundo a Adobe, eles continuarão a investir no desenvolvimento do Adobe AIR, o que significa que você poderá continuar a desenvolver em Flash/Actioncript para dispositivos móveis, mas ao invés de colocar a aplicação no seu servidor, terá que empacota-lá e envia-lá às App Stores da vida e ao invés do usuário entrar no seu endereço no browser, ele vai baixar aquela aplicação para o celular/tablet.

 

2) A Adobe continuará a investir no Flash Player para browsers desktop e no Adobe AIR para mobile.

Motivos:

Como já disse, tem coisas que o Flash faz que o HTML5 já faz diretamente no navegador, sem necessidade de plugin (Flash Player), mas tem coisas que mesmo quando a especificação do HTML5 estiver finalizada, ele não fará nem de longe.

A versão 11 do Flash Player já oferece possibilidades de fazer coisas na internet que antes nem sonhavamos (basta ver os vários exemplos de Stage3D, suporte à joystick, entre outros).
A Adobe já anunciou que está trabalhando na versão 12 do Player para desktops e acaba de lançar a nova versão do Adobe AIR

E agora?

Porém a Adobe “sugeriu” uma mudança no escopo do uso do Flash que é para entrega de vídeo de uma forma que o HTML5 não pode, criação de games e desenvolvimento de Apps para mobile.

Eu disse que a Adobe “sugeriu” porque uma vez que o player continuará em desenvolvimento, tecnicamente, nada te impede de continuar a usar o Flash para desenvolver um site inteiro (por exemplo), como já é feito hoje em dia.

Mas não comemore ainda!

O fato de você poder fazer tecnicamente não quer dizer que você vá fazer, pois outras razões influenciam nessa decisão, como desde o cliente que ouviu falar que o Flash morreu e não quer que você faça aquele freela em uma tecnologia “morta”, ou seu chef, que muitas vezes não entende absolutamente nada do que você faz, mas ouviu em algum lugar que não é legal usar Flash, até que realmente o Flash não seja a melhor tecnologia para um determinado projeto.

 

3) Adobe vai investir em ferramentas que facilitem a vida ao desenvolver com HTML5

Motivo:

O HTML5 é aplamente suportado pelos dispositivos móveis. Novamente, segundo Mike Chambers, o HTML5 é hoje para os browsers de dispositivos móveis o que o Flash Player é para os browsers de desktops.

O Flash Player para mobile já não era lá essas coisas (vamos combinar né?) então a Adobe parou seus esforços em tentar fazer o plugin no mobile ter o mesmo rendimento dos desktops para focar em fazer melhores ferramentas que facilitarão a sua vida.

Outro anuncio que fez a comunidade da Plataforma Flash temer pelo futuro da tecnologia, foi que a Adobe cada vez mais portará recursos do Flash para o HTML5. Nada menos esperado já que eles anunciaram que vão investir pesado na tecnologia.

Isso não quer dizer que o HTML5 SERÁ o Flash, nem mesmo que o substituirá totalmente, mesmo por conta das suas arquiteturas que são muito diferentes.
Ao que tudo indica, nada impede (e é bem provável) da Adobe fazer com que a IDE do Flash dê saída para muita coisa em HTML5…

E agora?

E agora meu amigo… ou você aprende HTML5 para continuar desenvolvendo os front-ends seja na sua agência seja nos seus freelas ou você continua apenas com seu conhecimento de Flash/Actionscript e se concentra no novo escopo que a Adobe quer dar p/ ele, vídeo, games e Apps para mobile (se é que essa moda vai pegar).

 

E o futuro?

Continuo apostando na Plataforma Flash, não apenas por gostar muito de trabalhar com ela e pelo que ela me permite fazer como desenvolvedor, mas porque em nenhum momento a Adobe disse que a plataforma morrerá e eu também não vi nada que me levasse a crer nisso.

A  Adobe errou absurdamente em não dar a devida importância a esse comunicado. Perderam a chance de fazer um evento para explicar as coisas, por exemplo, dando chance para os jornalistas fazerem as perguntas que aos poucos foram se esclarecendo ao longo da semana. Assim evitariam várias especulações e conclusões infundadas de quem já não simpatiza com Flash.

Não é questão de esperar para ver o HTML5 vai vingar ou não… já vingou! E se você ainda está puto com isso, está na hora de deixar de ficar não acha?!

Acho que a comunidade da Plataforma Flash está fazendo muito #mimimi em cima disso, alguns por falta de informação, por medo de perder o posto de “único desenvolvedor de coisas legais da equipe” ou por preguiça/frustação de ter que voltar a mexer com HTML, CSS, javascript (porque na maioria das vezes, esse cara também já brincou com isso) e voltar p/ esse terreno bizarro que é a guerra dos browsers (com o Flash Player a gente não tem que se preocupar muito com isso).

Ao meu ver, o profissional de Flash continuará a ser muito solicitado por um bom tempo, pois longe de morrer, por muito tempo existirão coisas que somente o Flash/Actionscript poderá fazer ou fará de uma forma muito mais fácil e ou com melhor performance que o HTML5.

Mas o pulo do gato é você conhecer muito bem as duas tecnologias, seus poderes e limitações e saber quando usar o que e principalmente o que os dois podem fazer juntos. Na verdade, o cara que hoje só se limita ao Flash, já deveria rever essa postura há muito tempo!

É uma frase batida, mas totalmente válida: Temos que nos apegar à soluções e não à tecnologias, por mais passional que seja a comunidade do Flash (me incluo nisso).

Se você trabalha com internet e não tem disposição para estudar cosias novas, sempre dá tempo de mudar de profissão.

Para esclarecimentos sobre as mudanças com o Flex, passo a bola para o Mário Júnior, Janderson FC e Igor Costa que já escrevem/gravaram bastante coisa à respeito.

Mover objetos com seno e cosseno

O primeiro fato ao mover objetos com seno e cosseno e saber como funciona os ângulos no flash.

O segundo fato e que sempre precisamos converte o ângulo em radiano.
O terceiro fato e termos que ter um valor para o raio desse ângulo.
Observações:
O cosseno movimento objeto apenas na horizontal, ou seja, no eixo x.
O seno faz a movimentação no eixo y, ou seja, apenas na vertical.

Então, agora vamos abrir o Flash e criar um arquivo do tipo “ActionScript 3.0″ de 500px de largura por 500px de altura a 30 fps. Você pode criar o arquivo do tamanho que preferir.
Com a ferramenta “oval toll” ou pressionando “o” criei um círculo branco, e pressione f8 para converte-lo em Movie Clip com o ponto de registro no centro. Também definir que a classe responsável por esse círculo vai ser “Ball” isso possibilita que eu adicione esse círculo no palco por código.

Observe que na biblioteca está o movieclip que acabamos de criar e seu “linkage” é “Ball”. Se você não estiver visualizando a biblioteca pressione “f11″.
Se o círculo criado estiver no palco click sobre ele e pressione “Delete” para que seja excluído.
Pressione “f9″ para que abra a janela “Actions” é onde vamos inserir nosso código.

var ball:MovieClip = new Ball(); //instanciando o objeto criado
var posX:Number = stage.stageWidth * .5; //capturando metade do palco na horizontal
var posY:Number = stage.stageHeight * .5; //capturando metade do palco na vertical

//posicionado e adicionando no centro do palco
ball.x = posX;
ball.y = posY;
addChild(ball);

Apenas adicionei o objeto no palco, ele ainda não tem nenhum movimento. Para adicionar movimento objeto, vou utilizar o evento “ENTER_FRAME” esse evento é atualizando de acordo com o fps definido. Ou seja se você definiu com 30 fps a função responsável por esse evento vai ser chamada 30 vezes por segundo.

Vamos definir também, o raio e o ângulo de movimento. Como não vamos trabalhar com o ângulo diretamente, utilizaremos uma fórmula que vai converter o ângulo em radiano. Que é o seguinte: ângulo multiplicado por (Math.PI / 180)

import flash.display.MovieClip;
import flash.events.Event;

var radius:Number = 50;
var angle:Number = 0;

var ball:MovieClip = new Ball(); //instanciando o objeto criado
var posX:Number = stage.stageWidth * .5; //capturando metade do palco na horizontal
var posY:Number = stage.stageHeight * .5; //capturando metade do palco na vertical

//posicionado e adicionando no centro do palco
ball.x = posX;
ball.y = posY;
addChild(ball);

//adicionando o evento que vai atualizar a posição de ball
ball.addEventListener(Event.ENTER_FRAME, updateBall);

function updateBall(e:Event):void
{
	var radians:Number = getRadians(angle);//converteno o ângulo em radiano
	ball.x = (Math.cos(radians) * radius) + posX;
	ball.y = (Math.sin(radians) * radius) + posY;	

	angle += 10; //incrementando o ângulo
	angle %= 360; //o resto da divisão do ângulo por 360, assim esse valor não ultrapassa 360
}

function getRadians(angle:Number):Number
{
	return angle * (Math.PI / 180);
}

Nas linhas 23 e 24 é onde acontece os cálculos referente a nova posição. Utilizei os métodos Math.cos e Math.sin para calcular o cosseno e o senno, passei como parâmetro o valor do ângulo convertido em radiano e multipliquei pelo valor do raio. O ângulo determina a direção em que o objeto vai traçar e o raio determina a velocidade com que o objeto vai traçar a direção!

Faça alguns teste alterando o valor do ângulo, raio e o valor com que o ângulo é incrementado.
Observação:
O diâmetro do movimento de “ball” é 2 vezes o valor do raio, sendo assim 2 * radius = 100.
Você pode movimentar “ball” apenas na direção x ou y comentando as linhas 22 e 23.
Você pode usar valores negativos para o valor do ângulo.
Exemplo: -90 que seria exatamente o mesmo que 270.

Na próxima etapa desse tutorial, vou apresentar alguns exemplos práticos que utilizei na criação de uma game.
Valew galera.

« Previous Entries