Onde isso faz falta?

Suponha que você queira manter 2 imagens iguais aparecendo na tela para simular um efeito de espelho ou que você precise mostrar um thumb e uma imagem grande e esta imagem é carregada dinâmicamente. Você não pode simplesmente dar addChild uma segunda vez, pois o seu objeto vai se mover. Sim, ele vai sumir do lugar antigo e aparecer no novo lugar, mas por quê? Não era para ser uma referência na memória? Sim, continua sendo, mas… Todo DisplayObject possui uma propriedade parent que faz referência ao DisplayObjectContainer onde ele foi adicionado. Sempre que o método addChild é chamado o valor da propriedade parent é alterado e consequentemente o DisplayObject deixa de estar no lugar anterior, porque afinal de contas ele só tem um pai.

Para Bitmap felizmente existe um jeitinho, mas para outros DisplayObject, não. Mas o que um Bitmap tem de tão especial? Um objeto Bitmap tem em sua composição um objeto BitmapData, e este por sua vez tem o método clone implementado. É na propriedade bitmapData que estão armazenadas todas as características da imagem. Segue um exemplo com um Bitmap gerado pelo código, mais especificamente um quadrado vermelho, veja como é simples:

// criando um bitmap (quadrado)
var bitmap:Bitmap = new Bitmap(new BitmapData(100, 100, false, 0xBB0000));
 
// adicionando bitmap no palco
this.addChild(bitmap);
 
// criando um novo bitmap com o clone do bitmap data
var bitmapClone:Bitmap = new Bitmap(bitmap.bitmapData.clone());
 
// modificando o posicionamento p/ enxergarmos os 2 elementos
bitmapClone.x = 100;
bitmapClone.y = 100;
 
// adicionando o clone no palco
this.addChild(bitmapClone);

Se uma imagem é carregada dinamicamente o processo é exatamente o mesmo, já que todo objeto Bitmap possui em sua composição um BitmapData sendo ele carregado externamente ou não. Então aproveitamos o que a imagem já tem. Segue um exemplo:

// declara e instancia um objeto loader
var loader:Loader = new Loader();
 
// adiciona listener para o carregmento da imagem
loader.contentLoaderInfo.addEventListener(Event.COMPLETE, handleLoadComplete);
 
// define uma url para carregamento
var urlRequest:URLRequest = new URLRequest("http://www.nyan.com.br/ico/it.png");
 
// inicia o processo de carregamento
loader.load(urlRequest);
 
// handle para o evento de complete
function handleLoadComplete(event:Event):void 
{
	// cria referencia para a imagem carregada
	var image:Bitmap = loader.content as Bitmap;	
 
	// adiciona a imagem no palco
 	this.addChild(image);
 
	// cria um novo bitmap e adiciona um clone 
	// do BitmapData contido no Bitmap carregado
	var imageCopy:Bitmap = new Bitmap(image.bitmapData.clone());
 
	// adicionando copia no palco
	this.addChild(imageCopy);
	// mudando posicionamento para enxergarmos
	imageCopy.x = 100;
 
}

Tem mais uma coisa interessante nisso: se você declarar um novo Bitmap, atribuindo a ele um BitmapData existente mas sem chamar o método clone, também vai funcionar. A diferença é que se você fizer qualquer alteração no bitmapData através de qualquer um dos Bitmaps, ambos serão alterados, o que não acontece quando invocamos o método clone, pois ele sempre retorna uma nova instância. Este é um bom exemplo pra entender a diferença entre instâncias e referências.

Não é necessário comprimir o arquivo (gerar um zip, um rar ou qualquer outra coisa) ou forçar pelo php, .net, etc. Você pode usar a  classe FileReference. Todo mundo lembra dessa classe na hora de fazer upload, mas a maioria esquece o método download que abre a caixa de diálogo no navegador para salvar o arquivo. 

O código é muito simples:

// definindo url do arquivo
var fileURL:URLRequest = new URLRequest("http://www.nyan.com.br/ico/feed.png");
 
// instancionado objeto file reference
var fileReference:FileReference = new FileReference();
 
fileReference.download(fileURL);

Só não esqueça de uma coisa: O Flash Player 10 sofreu várias atualizações de segurança e uma delas está diretamente relacionada à classe FileReference. Não é possivel chamar os métodos download ou browser se não for através de uma interação do usuário (pressionando uma tecla ou clicando com o mouse, por exemplo).

Se não existe, onde fica toda essa galera que programa para flash? Sinceramente, eu não pensei muito no todo, mas na pequena parcela que pode ser chamada de programador. Ou você é programador ou você não é e isso independe da linguagem que você decidiu se especializar. Um programador conhece e domina lógica – e nos dias de hoje OOP é fundamental – e depois só precisa aplicar isso na linguagem dos seus sonhos (Tá, não é só isso, mas não quero ficar fazendo listas de x ou y).

Mas, segundo o dicionário essa é a definição de programador:

Inform.,
aquele que cria programas de computador.

Aposto que quem escreveu essa definição não é programador e nunca teve que alterar um código que mais parecia uma macarronada ou as paredes de um quarto pintadas por uma criança de 5 anos… E sendo realista, não existe programador flash principalmente porque o Flash não é uma linguagem de programação e sim um aplicativo. Só que isso é um erro de nomeclatura ( que cá pra nós devia ser corrigido ) e não é o foco desse post, então eu vou dividir o universo do “programador flash” em 2 partes principais: os programadores e os não-programadores.

O cara que faz funcionar, entende como funciona o programa, fuçou horrores na vida, mas parou por aí é um não-programador. Ele conhece sintaxe, mas normalmente não sabe exatamente o que está fazendo. Ele só sabe que vai funcionar porque está assim no exemplo que ele achou na internet ou porque ele já fez 500 vezes desse jeito. Infelizmente, é o que mais tem no mercado e digo infelizmente não pelo mercado apenas, mas pelo futuro profissional dessas pessoas. Boa parte de quem programa para Flash tem um início sem embasamento teórico nenhum: são designers, publicitários, curiosos… Mas essas pessoas nunca serão programadores ActionScript? Depende de cada um. Conheço ótimos programadores que começaram assim, na curiosidade. Um programador tem que ser capaz de entender a lógica e também de produzir coisas lógicas ( e que de preferência não tenham lógica só na cabeça dele, que é o que acontece muito nesses casos ). 

O Programador ActionScript sabe o que está fazendo, mas ele pode ter muita ou pouca experiência. Ele possui n níveis de especilização e isso varia conforme sua experiência com a linguagem, mas não considere isso como anos trabalhados. 

Mas onde está o bom ou o mal programador? Bem, pra mim, em termos de código ele nã existe. O que define se alguém é um mau programador ( ou mau profissional ) são suas questões éticas e seus princípios. Cada um deve conhecer os seus limites, fazer o que está de acordo com suas habilidades e ter noção de quanto pode arriscar as coisas em um projeto deixando isso muito claro para todos os envolvidos. 

Alguém que realmente é bom ( e bom em qualquer coisa ) está sempre procurando acompanhar a evolução do nicho no qual está inserido. Sempre dando uma olhadinha aqui e outra ali tentando melhorar sua lógica, seu código e sua experiência. Aliás, um programador mais experiente normalmente agrega velocidade aos projetos, mas não quer dizer que um menos experiente necessáriamente vá produzir um código pior, ele só vai levar mais tempo. 

Em fim…