Archive for category ActionScript 3
System.useCodePage, por que não usar?
Posted by Renato Pacheco in ActionScript 3, Flash, Flex on 10 de setembro de 2009
Em muitos projetos com o Flash passamos por uma inseparável questão dos caracteres especias que são um tormento para muitos desenvolvedores que em um momento de desespero recorrem ao System.useCodePage, fazendo assim:
System.useCodePage = true;
Que bom, de repente seu problemas acabaram, todos aqueles caracteres começaram a funciona, mas que comando maravilhoso é esse? Vamos ver o que a Adobe nos diz.
Um valor Booleano que determina qual a página de código a ser usada para interpretar arquivos de texto externos. Quando a propriedade for definida como false, os arquivos de texto externos serão interpretados como Unicode. (Esses arquivos devem ser codificados como Unicode quando você os salva). Quando a propriedade está definida como true, os arquivos de texto externos são interpretados usando a página de código tradicional do sistema operacional que executa o aplicativo. O valor padrão de useCodePage é false.
O texto carregado como arquivo externo (usando a classe Loader.load(), URLLoader ou URLStream) deve ter sido salvo como Unicode para que o aplicativo o reconheça como Unicode. Para codificar arquivos externos como Unicode, salve-os em um aplicativo que ofereça suporte a Unicode, como Bloco de notas do Windows.
Resumindo a história, desde que você mantenha o valor de System.useCodePage como false, o Flash irá interpretar os dados recebido como Unicode, mas também significa que eles serão enviados as páginas dos servidores também como Unicode.
Unicode: é um padrão universal que permite aos computadores representar e manipular de forma consistente praticamente qualquer sistema de escrita que exista.
Então, uma vez que você carrega um arquivo externo que não esteja em Unicode e aparecem aqueles caracteres malucos você corre para mudar o System.useCodePage para true. Vamos ver agora o que a adobe diz sobre isso.
Quando esse código está presente, o aplicativo interpreta o texto externo usando a página de código tradicional do sistema operacional que executa o sistema operacional. Geralmente, é CP1252 em um sistema operacional Windows em inglês e Shift-JIS em um sistema operacional japonês. Se você definir useCodePage como true, o Flash Player 6 e superior tratarão o texto como o Flash Player 5 o trata. (O Flash Player 5 tratava todos os textos como se estivessem na página de código tradicional do sistema operacional que executava o player).
Quer dizer, seu problema se resolve por que apartir deste momento os textos serão interpretados de acordo dom o sistema operacional que estiver executando o SWF e não mais usando a codificação universal.
Acontece que seu cliente comprou um notebook direto dos Estados Unidos, ou pior ele é Chinês e você vai apresentar seu site pra ele, ai eu te pergunto:
O sistema operacional dele tem os nossos caracteres? Você acha mesmo que ele vai poder ver todos aqueles acentos maravilhosos? Os dados que você vai carregar estão no formato que você precisa?
Então eu recomendo, se você realmente quer que o máximo possíveis de pessoas possam usar perfeitamente o seu site, procure usar o System.useCodePage com valor padrão false.
Por isso, se necessário, procure tratar os dados enviados ou recebidos pelo Flash antes de mudar o tipo de codificação que ele irá trabalhar.
Documentação ActionScript 3
Posted by Renato Pacheco in ActionScript 3 on 9 de setembro de 2009
Como não podia ser diferente, link obrigatório para todo desenvolverdor é a documentação da liguagem e que moleza maior tendo ela toda em português.
http://help.adobe.com/pt_BR/AS3LCR/Flash_10.0/index.html
Tem também uma orientação para quem quer migrar do AS2 para o AS3 também em português.
http://help.adobe.com/pt_BR/AS3LCR/Flash_10.0/migration.html
Particularmente para aqueles que ainda não aderiram ao AS3 acho que já é um bom momente. Eu mesmo não havia aderia completamente ao AS2 por que o mesmo apresentava varios bugs que mesmo usando AS2 eu programava como se fosse AS1.
Felizmente o AS3 parece estar funcionado como prometido, já trabalho com ele desde o Flash CS3 e está exelente, é mais rápido e organizado de se trabalhar.
ExternalInterface ou navigateToURL?
Posted by Renato Pacheco in ActionScript 3, JavaScript on 8 de setembro de 2009
Alguns desenvolvedores costumam se questionar sobre o uso do ExternalInterface no lugar navigateToURL para executar um JavaScript afinal de contas a classe existe para executar esta tarefa mas, será que não existem exceções?
Pode ser que você se lembre do getURL que até o Flash 7 era o nosso meio de comunicação com o navegador antes da chegada do ExternalInterface ainda no AS2 e que felizmente logo na seqüência, o getURL saiu de cena para dar lugar ao navigateToURL no AS3.
Passada por esta fase tornou-se obrigatório o uso do ExternalInterface e o navigateToURL foi deixado de lado para o uso exclusivo de acesso a links. Eu até concordaria, desde que todos os pontos fossem cobertos.
Vamos a um exemplo criando dois botões, um usando o ExternalInterface e outro usando navigateToURL para executar um JavaScript. Vou utilizar neste exemplo um script para adicionar a favoritos que encontrei no site codigofonte que funciona em vários navegadores.
JavaScript:
function addFav(title,url)
{
if (window.sidebar)
{
window.sidebar.addPanel(title, url,"");
}
else if(window.opera && window.print)
{
var mbm = document.createElement('a');
mbm.setAttribute('rel','sidebar');
mbm.setAttribute('href',url);
mbm.setAttribute('title',title);
mbm.click();
}
else if(document.all)
{
window.external.AddFavorite(url, title);
}
}
Agora no Flash, fiz dois botões:
![]()
Cada um executando o mesmo JavaScript de maneiras diferentes:
ActionScript:
// Importando as classes que vamos utilizar.
import flash.external.ExternalInterface;
import flash.net.navigateToURL;
// Vamos definir o título do favorito.
var titulo:String = "Renato Pacheco";
// Aqui, definimos a url do favorito.
var url:String = "http://www.renatopacheco.com.br";
// Juntando os dois dados acima, montamos um JavaScript covencional.
// Poderiamos usar até em um link de página HTML.
// É muito importante usar a função void(0) para anular o retorno da função qe vamos executar.
var javaScript:String = "javascript:addFav('" + titulo + "','" + url+ "');void(0);";
// Aplicando a um dos botões a função ExternalInterface.
ExtIntBtn.addEventListener(MouseEvent.CLICK,function($e:MouseEvent):void{
ExternalInterface.call("addFav",titulo,url);
});
// Aplicando ao outro botão o navigateToURL.
NavToUrlBtn.addEventListener(MouseEvent.CLICK,function($e:MouseEvent):void{
navigateToURL(new URLRequest(javaScript),"_self");
});
Ao colocar o SWF na mesma página que o código JavaScript e clicar em qualquer um dos botões aparentemente temos quase o mesmo resultado:

A primeira vista temos o mesmo resultado, mas não podemos esquecer que esta ação depende do usuário para ser concluída.
No caso do navigateToURL não faz diferença pois o flash continuará sua execução normalmente mas, para o ExternalInterface a história não é bem assim. Quando é executado o ExternalInterface.call() espera um retorno do javascript seja ele nulo ou não, então espere que o usuários demore uns quinze segundos para terminar a ação e veja o que acontece:

Você pode até achar que isso não acontece e que ninguém vai levar mais de quinze segundos para adicionar um link aos favoritos, pois eu lhe digo que já aconteceu e não interessa sua justificativa, o cliente vai entrar em pânico quando vir uma mensagem dessa.
Por isso eu pensaria duas vezes antes de tornar o uso de o ExternalInterface uma regra indiscutível e a prova de falhas.