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

Devido à alguns reposicionamentos profissionais, não vou poder dedicar todo tempo que dedicava ao grupo e para fazer menos do que já fizemos até aqui, não me interessa

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

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

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.

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.

A agenda do evento conta com Lee Brimelow e Paul Trani, evangelistas da Adobe US para a plataforma Flash e vários nomes nacionais de peso, como Arthur Debert, Lucas Dupin, Janderson Cardoso, Leon Kulikowski, Gabriel Peart e Stefan Horochovec, além de Claus Wahlers, um cara que já programava antes de você saber o que é um computador.

Os temas vão desde games em Flash, AIR para mobile e devices até arte generativa com HTML5, divididos em 6 palestras e 4 workshops em um dia inteiro dedicado a fazer você melhorar o desempenho e qualidade das suas aplicações!

Porque você deve sair de casa em um sábado e participar do evento?
1) O Brasil já tem tão poucos eventos dedicados ao desenvolvimento de aplicações RIA que se você tem algum contato com projetos desse tipo, não deveria nem precisar de motivos para se convencer!

2) A agenda do evento foi montada para que todos tirem proveitos das palestras/workshops, independente do nível de conhecimento.

3) O custo do evento é menor do que aquele jantar com a namorada no Japonês. Certamente é melhor o jantar ao invés ver um monte de nerd o dia todo, mas, a não ser que sua namorada seja sua chefe ou você seja Chef de outro restaurante , o japonês não te ajudará profisisonalmente

4) O evento encerra em uma mesa redonda com todos os palestrantes. Não é todo dia que se tem a chance de fazer perguntas diretamente para essas personalidades. Quer saber o que esses caras fizeram para chegar onde estão? É só perguntar.

5) Quer trocar de emprego ou está precisando de freela?? Lá estarão vários outros profissionais da mesma área que certamente conhecem uma empresa procurando alguém para contratação ou freela.

6) Quer mais motivos? Aparece lá na Impacta dia 19/11 que nós te mostramos.

Mais informações em asdevs.com.br/flashcampsp

Vimos no último post sobre SEO e FLASH como funciona a indexação de sites pelo Google, e conforme vimos no link onde o prórpio Google anúncia melhorias na indexação do Flash, é muito importante disposnibilizarmos um Sitemap em XML que deve ser hospedado na raiz (root) do website para facilitar o acesso do Google aos conteúdos de nosso site.

Segue abaixo um exemplo de Sitemap XML para ser usado em um site em Flash que usa SWFADdress e SWFObject.

</?xml version="1.0" encoding="UTF-8"?>
	<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
		<url>
			<loc>http://www.seusite.com.br/#/home/</loc>
            		<lastmod>201-01-01</lastmod>
			<changefreq>monthly</changefreq>
			<priority>1.0</priority>
		</url>
		<url>
			<loc>http://www.seusite.com.br/#/contato/</loc>
            		<lastmod>201-01-01</lastmod>
			<changefreq>monthly</changefreq>
			<priority>0.8</priority>
		</url>
	</urlset>

Vejamos as partes e nós mais importantes deste XML:

</?xml version="1.0" encoding="UTF-8"?>

é o cabeçalho do documento XML.

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">

encapsula o XML e mostra a referência do protocolo

<url>

Nó inicial para entrada das outras tags.

<loc>http://www.seusite.com.br/#/contato/</loc>

Aqui você coloca a URL da sua página, note que o endereço com “#” é justamento o endereço que nos dá o retorno do SWFADdress para dentro do conteúdo de determinada página, neste caso contato.
Neste nó do XML, podemos ter até 2,048 caracteres.

<lastmod>201-01-01</lastmod>

Aqui inserimos a data de última modificação da página. Atentar para o formato ANO/MÊS/DIA, já que é o “W3C Datatime format”.

<changefreq>monthly</changefreq>

Neste nó colocamos com que frequência a página é alterada, é aconselhado colocar o valor correto neste parâmetro, para evitar que ela não seja ignorada pelo crawler do motor de busca.
Os valores podem ser os um dos seguintes: always,hourly,daily,weekly,monthly,yearly,never.

<priority>1.0</priority>

Na tag acima temos onde darmos a prioridae para a URL. Esta prioridade vai de 0.0 até 1.0. O valor padrão, quando este parâmetro falta, é de 0.5.

Obviamente, que se tivermos mais páginas no site, tanto maior será a quantidade de nós que terá este XML. É adequado fazer um nó para cada página no site.
Para mais informações sobre este protocolo, você pode acessar o link abaixo:
http://www.sitemaps.org/protocol.php

O próximo passo é acessar e utilizar a ferramenta de webmaster do Google.

Já é de algum tempo que que o Google vem indexando conteúdo de SWF e sua busca.
Porém ao longo dos últimos anos tivemos mais algumas novidade e melhorias nesta indexação.

Agora o Google indexa muito mais conteúdo do SWF: tais como textos, links e além disso, pode indexar os links dentro do conteúdo em SWF.
No entanto estas mudanças são melhores suportadas a partir do Flash Player 10.1, ou seja, sites muito antigos com versão de Flash Player inferiores, muito possivelmente não terão estas mudanças verificadas na busca e indexação.

Mas comforme segue, é ideal que cada página tenha uma URL única e que a mesma seja cadastrada em um SiteMap feito em XML e que os links de cada página em SWF e que este mesmo SiteMap seja colocado corretamente dentro do Google Webmasters Tools.
Estas URLs únicas são facilmente conseguidas através do SWFAddress, conforme vimos no post anterior sobre SEO e Flash.
Este procedimento é o mesmo usado para sites feitos totalmente em HTML.

O que o Google indexa do Flash?

- Texto Estático;
- Texto Dinâmico;
- URLs Internas;
- URLs externas;
- XML carregado dentro do SWF;
- HTML carregado dentro do SWF;
- SWFs carregados dentro do SWF pai.

Use o SWFObjetc para incorporar o SWF no HTML!
Não é todo Javascript que o Google consegue ler.

Muito contra vontade, muitos profissionais de SEO e HTML terão que aceitar que coom esta nova indexação é mais fácil uma animação em Flash no site ter seus links e textos indexados do que uma imagem em JPG, PNG ou GIF.

Referências:
http://googlewebmastercentral.blogspot.com/2008/06/improved-flash-indexing.html
http://googlewebmastercentral.blogspot.com/2009/06/flash-indexing-with-external-resource.html
http://googlewebmastercentral.blogspot.com/2010/11/what-feeling-even-better-indexing-of.html

Sandro Silva
@sandrilho
sandrosilva.tumblr.com

Estou de volta para continuar na sequência de nossos posts sobre SEO e Flash.

Hoje veremos a parte de META TAGS e a sua importância para sites feitos em Flash e o que não poderemos colocar no flash em certas tags.

Meta tags são muito importantes no desenvolvimento do site, pois são destas tags em HTML que os sites de buscas tiram algumas informações vitais do website, onde chamarão a atenção de quem as visualiza, como já vimos no post anterior, bem como um melhor posicionamento no termo de procura digitado.

Neste caso os sites em Flash tem uma desvantagem, pois geralmente só é feito em uma página a os links são feitos através de loadMovie ou por frames dentro do SWF.

Assim os sites em Flash tem pouca abrangência em títulos e descrição de um site, pois só apresentam uma página HTML para contê-los, enquanto sites de HTML podem variar de página a página.

Convenhamos, fazer um site em Flash e colocar uma parte em cada HTML diferente fica feio demais, quem faz isso deveria fazer o site em HTML.

Todas as tags baixo ficarão entra a TAG <head> e o fechamento dela </head>:

1 – <tittle>PALAVRAS-CHAVE – empresa</tittle>

Muito cuidado ao trabalhar com o título, aqui está a parte mais importante do teu site para o Google e outros sites de busca em geral.

Aqui conforme o exemplo acima deveremos colocar palavras-chave primeiro e depois o nome da empresa ou do relativo dono do site, por ordem de relevância.

Aqui o ideal é que o texto não ultrapasse 70 caracteres.

Por exemplo: <tittle>Restaurante de Frutos do Mar em São Paulo – Tramontini</tittle>

No exemplo acima as palavras-chave são: restaurante, frutos do mar e São Paulo.

Claro que o interessante é você caprichar muito mais no título e pensar como usuário do Google na hora da pesquisa e jogar com algumas palavras chaves que mais combinem com o conteúdo do site.

Como título deixe uma frase que faça sentido, pois digitando algo sem sentido não será em nada atraente para um click de mouse no Google, Yahoo, Bing.

Nunca deixe como título algo que não tenha nada haver com o website em questão, contará pontos negativos para você.

2 – <meta http-equiv=”expires” content=”0” />

Não tão importante quanto a primeira, esta tag avisa quando a página irá expirar.
Caso você queira marcar ela para expirar algum dia nos sites de busca, você poderá marcar conforme exemplo abaixo:

<meta http-equiv=”expires” content=”Tue, 17 Oct 2011 00:00:00 GMT” />

3 – <meta name=”robots” content=”follow,index”>

Esta
meta tag é na verdade era mais importantes para sites em HTML, mas com as mudanças recentes do Google já é importante para nós.

Ela indexa esta página, e os outros links que estão na página, no caso dentro do SWF.

Exemplos abaixo:

<meta name=”robots” content=”index,follow”>

Indexa a página inicial e todos os links nela contida.

<meta name=”robots” content=”noindex,follow”>

Não indexa a página inicial, mas indexa todos os links nela contida.

<meta name=”robots” content=”index,nofollow”>

Indexa a página inicial, mas nenhum link existente nela.

<meta name=”robots” content=”noindex,nofollow”>

Não indexa nem a página inicial e nem seus links.

Indexar os links que você tem no site é opção sua, mas tenha em mente que links externos podem detonar o PageRank do teu site.
4 – <meta name=”description” content=”texto sobre o que é a página ou site.”>

Outra Meta tag importantíssima para nós, aqui você terá que descrever o conteúdo do site, também pensando naquilo que o usuário irá procurar nos sites de buscas.

Você tem que colocar na descrição algumas palavras chaves que já tenham no Título do website e também tenham no conteúdo do website, para reforçar a importância.

Este texto de descrição será o que aparecerá logo abaixo do Título do site no Google, assim, escreva algo atraente e que faça algum sentido.

Exemplo:

<meta name=”Description” content=”Restaurante especializado em Frutos do Mar em São Paulo com larga carta de vinhos e várias pções de pagamento.” / >

No exemplo acima as palavras-chave são: restaurante, frutos do mar e São Paulo, novamente, reforçando o título.

Aqui o ideal é que o texto não ultrapasse 155 caracteres.

5 – <meta name=”keywords” content=”palavras-chave”>

Esta aqui já foi declarada em desuso para o Google, porém não para outros sites de busca, pelo menos não declararam nada que não usam maiis como referência para as buscas.

Mas aqui você pode colocar algumas palavras-chave que serão os termos onde você se guiará para desenvolvimento de um bom título e uma boa descrição para o site.

Exemplo:

<meta name=”Keywords” content=”Restaurante, frutos do mar, São Paulo, SP, jantar, almoço” />

Aqui o ideal é que o texto não ultrapasse 200 caracteres.

6 – <meta name=”generator” content=”programa – Flash”>

Meta name generator é onde declaramos o programa usado para desenvolvimeno do site, no caso aqui, coloco Flash.

7 – <meta name=”author “content=”Sandro Silva”>

A meta tag author é explícita em seu significado, no caso aqui colocaremos o nome do autor do website, no caso, você ou a agência onde você trabalha.

Por hoje é isto galera do Flash, FDT, FlashDeveloper.

No meu próximo post entrarei em assuntos um pouco mais avançados com a maravilhosa ferramenta
SWFAddress, e a possibilidade de indexação de vários links para um site só em Flash.

Até mais!

E vou começar explorando uma necessidade bem comum atualmente, a compressão de dados.

Vou sempre ser o mais curto possível, mas não irei deixar os newbies na mão.

E vou começar explorando uma necessidade bem comum atualmente: a compressão de dados.Vou usar como exemplo um projeto meu que precisou fazer leitura num arquivo comprimido em ZIP gerado pelo XMind.Tem pressa e sabe porque quer comprimir dados pule o texto abaixo.

Comprimir dados tem mesmo vantagem hoje em dia?

Você pode fazer aquela analise clássica dizendo que a Internet hoje permite maior transferência de dados e ficar reduzindo o tamanho de arquivos é bobagem, muitas agências de publicidade alegam isso.

Mas na realidade temos o fato real de que nem todos possuem aquela banda larga linda, existe a sobrecarga de transmissão no servidor e tem a necessidade de termos um trabalho mais protegido das mãos de gente maliciosa.

Onde eu uso isso?

Um cenário típico é quando precisamos enviar um XML extenso, como uma lista com 10.000 registros ou um arquivo Collada para usar com 3D por exemplo. Comprimi-la nos dá um arquivo em média 10% menor que o original.

Quem realmente usa isso?

Alguns exemplos de arquivos que são na verdade arquivos ZIP com uma terminação diferente são:

• Java (.jar, .war)
• Google Earth (.kmz)
• Open Raster (.ora)
• XMind (.xmind)

Só vou usar isso para comprimir os dados ou tem mais  alguma outra…

vantagem além do tamanho?

1) Todo arquivo costuma ser um grupo de estruturas com pastas e informações organizadas.

Como já vem organizados nós passamos ele para a memória muito mais rápido e podemos fazer alterações no esquema de dados muito praticamente.

2) Segurança, pois os dados passam pela rede em forma incompreensível para humanos. Além de você poder usar uma biblioteca de criptografia também.

Já falei o suficiente para convencer, então vamos a…

Implementação em um caso de uso

Isso surgiu quando eu procurei uma ferramenta gráfica para trabalhar com diálogos dos personagens de um jogo.
Precisava de um jeito fácil de montar os balões e desvios condicionais. Escolhi o XMind, um famoso editor de Mapas Mentais.

Todos os editores de mapas mentais usam um arquivo XML, bastaria exportar do XMind. No entanto isso acarreta um trabalho adicional, um terceiro arquivo de lixo que pode ocasionar problemas com versionamento e limpeza. (E meu jogo anda com uns 6.000 arquivos de produção).

Mas uma rápida pesquisa e descobri que formato do XMind nada mais é que um XML dentro de um ZIP… Tcha-ram, Meus problemas se acabaram. Basta ler o arquivo e interpretar o XML como o do formato mais simples.Assim eu ganho velocidade e limpeza.

Criando nosso código

Você vai precisar:

Flex 4.0

Flash Develop (ultimo release, baixe neste forum)

nochump-ziplib-105-dist.zip

Criei um mxml para ser a cara da aplicação.

Coisa pouca, um campo para mostrar o thumbnail, uma aba para selecionar o arquivo origem e o destino, uma aba para mostrar a saida do depurador, e uma para erros.

Coloquei o código no Pastebin.com

http://pastebin.com/akaExS3x

Feita a interface, vamos ao que interessa

Instalei a biblioteca simplesmente copiando o .swc na pasta /lib e clicando com o direito no arqu

ivo escolhi a opção “add to library”.

A classe de trabalho é simples ela herda a classe EventDispatcher isso quer dizer que recebe e manda eventos.
Como sera lido um XML criei a lista de namespaces usado no documento.

//mamespaces

private var xmind:Namespace = new Namespace("urn:xmind:xmap:xmlns:content:2.0");		

private var fo:Namespace = new Namespace("http://www.w3.org/1999/XSL/Format");		

private var svg:Namespace = new Namespace("http://www.w3.org/2000/svg");

private var xhtml:Namespace = new Namespace("http://www.w3.org/1999/xhtml");

private var xlink:Namespace = new Namespace("http://www.w3.org/1999/xlink");

A classe funciona instanciando-se um objeto e usando o método load como é de costume.

Você pode adicionar eventos à ela, com eu fiz no mxml.

parser.load( new URLRequest( "mind1.xmind" ) );	

parser.addEventListener( Event.COMPLETE, added );

No carregamento crio um objeto ZipFile, e descarto o URL Loader usando o System.gc().

A biblioteca em ação:

Cada entrada no Zip é chamada de ZipEntry.

Basta correr as entradas do arquivo. No caso do padrão XMind existem arquivos especificos.

Este é o “coração” do leitor de arquivos:

private function loaderDone( e:Event ):void

{

  var data:IDataInput = internalLoader.data;

  // as ByteArray;

  zipFile = new ZipFile( data );	

  internalLoader = null;	

  System.gc();	

  LogManager.message = "Carga efetuada.";	

  for (var i:int = 0; i < zipFile.entries.length; i++)	

  {

    var entry:ZipEntry = zipFile.entries[i];	

    var dt:ByteArray; 

    switch( entry.name )

    {	

      case "Thumbnails/thumbnail.jpg":

        LogManager.message = "Thumbnail carregado.";

        dt = zipFile.getInput(entry);

        thumbnail = new Loader();

        thumbnail.loadBytes(dt);

        break;
      case "content.xml":

        LogManager.message = "Lendo XML";

        dt = zipFile.getInput(entry);	

        _xml = new XML( dt.readMultiByte(dt.bytesAvailable, "UTF-8") );

        break;	

    }

  }

  System.gc();

  this.parse( _xml );

  dispatchEvent( new Event(Event.COMPLETE) );

}

Como todo conteúdo é binário eu tenho que recuperar o XML assim:

dt = zipFile.getInput(entry);

_xml = new XML( dt.readMultiByte(dt.bytesAvailable, "UTF-8") );

O thumbnail é usado num Loader a parte e será exibido no aplicativo.
O content.xml é o arquivo que nos interessa.

public function parse( x:* ):void

{

  if (x is XML)

  {

    if (_xml==null)

      _xml = x as XML;

  }

  else

    _xml = new XML( x as String );

  var i:int;

  LogManager.message = "Lendo XML:";

  default xml namespace = xmind;

  for each(var x:XML in _xml.sheet)

  {

    LogManager.message = "Folha: " + x.title;
    // Aqui voce implementa alguma coisa 

  }

}

Terminado envio um Event.COMPLETE para o sistema, ai o mxmlc desenha o thumbnail.

A classe você pode ver neste link http://pastebin.com/g8MrT1bD

Também criei uma classe extra para gerenciar os logs, mas isso foi capricho meu mesmo.

http://pastebin.com/fiE9jn1s

E o último XML?

Este tutorial esta apenas mostrando o caminho das pedras.

Falarei da implementação final quando estiver pronta. Mas já é o suficiente para vocês modificarem o mecanismo de leitura em seus projetos.

Enjoy

Um exemplo de game para iOS feito com AIR 2.7, cada release a adobe nos surpreende em otimização, cada vez mais fica claro que vale a pena experimentar, principalmente com games casuais.

via The Flash Blog