GR?TIS! ? especial

Perigo do GR?TIS

GR?TIS! Estrat?gias

• Frete Gr?tis: ? dif?cil superestimar o apelo desta oferta. Muitas empresas de com?rcio eletr?nico tornaram padr?o, enquanto alguns usam como uma estrat?gia tempor?ria promocional;
• Troca Gr?tis: Possui um apelo adicional para outro elemento da psique humana: a avers?o ao risco;
• Produtos gr?tis ou upgrades: Existe um acess?rio barato que a maioria dos consumidores iria achar ?til? Uma atualiza??o, talvez? A extens?o de garantia? Pode ser mais eficaz vender um produto se ele estiver associado a um benef?cio GR?TIS! do que simplismente baixar o seu pre?o. As melhores ofertas gratuitas, s?o aqueles com um alto valor percebido. Se voc? j? tentou comprar um cabo HDMI em uma grande loja de eletr?nicos, voc? sabe que eles custam de R$ 30,00 a R$ 50,00, ou mais, apesar do custo de produ??o ser inferior a um d?lar ou dois. Um site de com?rcio eletr?nico inteligente poderia fazer um grande neg?cio em oferecer um produto como este gratuitamente na venda de um outro produto mais caro, acrescentando um grande valor aparente a compra.

Poucos sabem mas o Flash Media Server(versão Interactive) possui uma linguagem de servidor chamada Server-Side ActionScript ou ActionScript Communications(extensão .asc). O que permite recurso poderosos em seus aplicativos multimídia muito além de um simples streaming.
Server-Side ActionScript é o nome que Adobe deu para o JavaScript 1.5, o Flash Media Server possui uma engine de JavaScript para compilar e executar os scripts.
O Server-Side ActionScript é parecido mas não idêntico ao ActionScript 1.0, mas ambos são baseado no ECMAScript(ECMA-262) edition 3 language specification. O Server-Side ActionScript roda sob a engine SpiderMonkey da Mozilla que consta no Flash Media Server enquanto que o ActionScript 1.0 roda sob o AVM1(ActionScript Virtual Machine 1) no Adobe Flash Player. O SpiderMonkey implementa o totalmente o ECMAScript enquanto que a AVM1 do Flash Player não. A grande diferença entre os dois é que o Server-Side ActionScript é case-sensitive.
Portanto para quem já tem conhecimento de JavaScript, pode reaproveita-lo para usar no Flash Media Server, é possível utilizar a maioria dos recursos e ainda contar com os recursos exclusivos do Flash Media Server.

Vamos os primeiros passos para utilizar o Server-Side ActionScript no Flash Media Server. Uma maneira de testar seus scripts é usando o fms_console localizado no caminho:

INSTALATION FOLDERAdobeFlash Media Server 4.5webrootswfsfms_adminConsole.swf

Se você tiver o Adobe Flash Professional, pode abrir esse arquivo diretamente apenas dando dois cliques, caso contrario, abra pelo navegador. Ao ser aberto, devemos ter uma tela como essa:

Tela inicial do fms_adminConsole.swf

Basta entrar com o login e senha que você determinou no momento em que estava instalando o Flash Media Server que deveremos entrar para a seguinte tela:

Tela pos-login

Esse será seu melhor amigo ao desenvolver aplicativos com Flash/Flex e Flash Media Server. Por padrão, o Flash Media Server lê o seguinte diretorio:

INSTALATION FOLDERAdobeFlash Media Server 4.5applications

Esse caminho pode ser configurado modificando a linha “VHOST.APPSDIR” no seguinte arquivo:

INSTALATION FOLDERAdobeFlash Media Server 4.5conffms.ini

Criaremos um diretorio chamado “teste”, e dentro dele um arquivo chamando “main.asc” com o seguinte conteúdo:

Agora no console, carregaremos nossa aplicação criando uma nova instância dela selecionando no combobox:

Na tela seguinte, basta dar um “enter”.

Deveremos ter o resultado do nosso trace na caixa de texto como na imagem:

Resultado do trace

Uma recomendação que faço é que você limpe a tela antes de executar novamente o script main.asc, basta clicar no botão Clear Log(1) e depois em Reload Application(2):

Alguns exemplos do que pode ser usado com o Server-Side ActionScript

Constantes

Expressões Regulares

Funções

Objetos

Array

Aviso importante, use esses recursos SOMENTE em ambiente de desenvolvimento. Em ambiente de produção, você derrubará todo mundo que estiver conectado ? sua aplicação.

Referência:
Documentação do Adobe Flash Media Server

O blog flex.etc.br será apenas? mantido? para acesso, não haverá mais novos post ou informações. Os comentários serão aprovados e respondidos normalmente.

Estou abrindo o meu novo blog, d.ps.net.br, onde estarei realizando o mesmo trabalho feito até agora, mas com uma diversificação maior das áreas, saindo do “mundo flex” no qual estava trabalhando.

Se o mundo não acabar no final do ano, o blog fica no ar por mais alguns anos, para acessos póstumos

Lembrando que o fim do blog foi uma ação programada.

Olá pessoal! Que tal vir morar no Rio de Janeiro, atuar com desenvolvimento Apache Flex + Java, trabalhando para uma grande multinacional na Barra da Tijuca? A Match Latam é uma multinacional e ela atua aqui no Brasil também com desenvolvimento, e um de seus grandes cases é o portal ParPerfeito, dentre outros. Se você [...]

Hoje existem diversas plataformas no mundo mobile e cada uma com uma linguagem específica, dessa forma, existe um custo elevado para portar uma mesma aplicação para todas as plataformas, esse custo elevado no desenvolvimento de projetos acaba criando uma barreira muito grande para que pequenas empresas possam usufruir desse ambiente que cresce exponencialmente a cada [...]

Twitter!

JodaTime

Não existe segredo quando se fala da implementação de datas no Java: é ruim de usar. Alguns chegam a dizer que é errado usar inclusive, mas não serei tão extremo.
A API de datas do Java é ruim por vários motivos, como por exemplo, é mal documentada, não é Thread Safe, é difícil de manipular datas, e o comportamento nem sempre é o esperado.
Vamos ver como susbtituir a API de datas que vem Out of the Box no Java, por uma mais efetiva, amigável e confiável: JodaTime.

Lembrando do Calendar

Todo programador Java conhece o Calendar, e sabe que para usá-lo, basta seguir o Design Pattern singleton, ou seja, basta chamar o método de classe em Calendar que devolve a instância única do sistema para o Calendar.


Problema: não funciona.


Não funciona porque se a instância é singleton, e não utiliza threadlocking no código, então não é uma instância ThreadSafe. Logo toda vez que chamamos o getInstance() do Calendar, obtemos uma nova instância. Para ilustrar, crie um teste em JUnit 4 com o seguinte código:

Rode o teste e veja a barra do JUnit ficar vermelha. O comparador ‘==’ usado em objetos, compara pelo endereço de memória, o que deveria ser o mesmo se fosse seguido o padrão singleton de verdade.
Pra piorar, todos os métodos que alteram as intâncias do Date estão expostos (por mais que estejam depreciados) para mantêr compatibilidade com versões anteriores da VM. Portanto o Date também não é ThreadSafe, pois não existe controle de concorrência em sua implementação.
Agora vamos deixar o Date e o Calendar de lado, e vamos ao JodaTime.

DateTime

O JodaTime diferencia muito bem os conceitos de data, instante de tempo, período, etc. A classe mais básica (interface no caso) é a ReadableInstant. Não precisa dizer que todas as modelagens de data implementam essa interface, permitindo comparar todos os tipos de modelagem de tempo pontuais. Um período não descreve um único instante ou ponto no tempo, por exemplo.
DateTime é talvez o ReadableInstant mais conhecido, e funciona muito parecido com o Date do Java.
Fatores que tornam o DateTime mais amigável são: é ThreadSafe pois é imutável, é muito bem documentado, e é muto fácil realizar operações com data. Vamos escrever um pouco de código para entender o que se passa.
Comece criando um DateTime. Como no Java, este DateTime criado possui o instante atual do sistema. Em seguida para efeito de teste (o teste pode falhar dependendo de quando for executado), adicione um dia na data criada, e verifique que o novo date aponta para amanhã:

Repare que tive que reassociar o date para que ele pudesse ser alterado, afinal DateTime é imutável, o mesmo comportamento que o BinInteger possui. Repare também que pra adicionar um dia, basta chamar plusDays. Este método já se encarrega de fazer toda a lógica de adicionar um dia na data, como por exemplo mudar o mês ou ano se for preciso, por isso se esse teste for rodado no dia 31 de dezembro, ele irá falhar pois o DateTime irá adicionar mais um dia a data, e perceberá que se trata do ano seguinte, e portanto getDayOfYear irá devolver ’1′, e não ’366′ ou ’365′ como esperado.
O JodaTime também trata anos bissestos e horário de verão se for selecionado o fuzo correto.
Existe uma API bem completa em DateTime para manipular todos os campos possíveis da data, sendo assim fica muito mais fácil iterar ao longo dos dias, sem precisar delegar pro Calendar a tarefa, e depois recuperar o resultado.
Não vou abordar muito da API do JodaTime, pois está muito bem documentada e existem muitos exemplos nas internet. O objetivo desse post é tratar do assunto do próximo tópico.

JodaTime e Hibernate

Pior que manipular datas, é persistir datas. Cada banco persiste data do seu próprio jeito, e cada implementação de ORM trata o Date do seu próprio jeito. Mas se você está utilizando o Hibernate, o JodaTime tem uma solução de padronização pra você: JodaTime Hibernate.
Com o JodaTime Hibernate é possível mapear diversos tipos de representação de data em suas classes Java, com ou sem TimeZone, como String ou bigint, como período ou duração, etc.
Para se ter uma idéia do que é possível, basta verificar a documentação online.
E para utiliza é muito fácil. Imagine que você tenha uma entidade com um campo DateTime, que se chama entryDate, portanto temos o getter:

Para tornar este DateTime uma data que é padrão do banco que será utilizado, por exemplo, basta adicionar a seguinte anotação:

Estamos falando para o hibernate utilzar o tipo de coluna descrito pelo PersistentDateTime, e utilizar o mesmo para converter a data novamente para DateTime quando for recuperado.
Caso você esteja fazendo engenharia reversa de algum banco, recomendo ler a descrição de todos os tipo disponíveis pra fazer a melhor escolha.
Com isso conseguimos obter todos os benefícios do JodaTime em nossas entidades, facilitando controlar as datas no domínio de nossas aplicações.


Espero ter despertado sua curiosidade com o JodaTime. Na minha opinião é uma das melhores bibliotecas Java disponíveis, mas não quero falar muito sobre suas funcionalidades, pois um dos pontos mais fortes da biblioteca é a facilidade de se acostumar com ela, e principalmente utilizar todos seus recursos. Quero que vocês tenham um pouco desse gostinho .

Por @Gust4v0_H4xx0r

Twitter!

Spring @Configuration

O que há de novo

Para habilitar certas funcionalidades do Spring que envolvem AOP, era preciso escrever tags XML como por exemplo context:component-scan para especificar os pacotes em que o Spring pode buscar por beans anotados com @Component, @Repository ou @Service.
Na versão 3.1 foram disponibilizadas as mesmas funcionalidades via anotação. São elas:

Vamos abordar o caso básico, pois o resto é bem similar.

@ComponentScan

Caso você ainda não esteja familiarizado com as configurações por anotaçãoo, vamos ao básico.
Comece criando uma classe que representará seu container de beans, e a anote com @configuration:

Nesta classe estarão os beans que o container irá instanciar e deixar a nossa disposição.
Para iniciar o container vamos criar um test (JUnit 4) que instancia o contexto:

Aqui criamos um container do tipo AnnotationConfigApplicationContext e registramos nossa classe de configuração nele. Repare que é possível registrar mais classes, e portanto disponibilizar mais beans no container.
Agora vamos criar nosso bean de teste:

Vamos criar os métodos em nossa classe de configuração que instanciam nosso bean de duas maneiras diferentes:

Repare que a única diferença entre os dois é a String que passamos como parâmetro.
Agora que temos 2 beans diferentes em nosso container, vamos criar os testes para verificar o comportamento do Spring. Abaixo da inicialização do contexto, vamos adicionar as seguintes linhas:

Aqui estamos garantindo que nossos dois beans diferentes estarão no contexto como esperado.
Antes de rodar o teste, será necessário adicionar a dependência do CGLib ao seu projeto. Caso você esteja usando o maven, basta adicionar a seguinte dependência>

Pronto, com isso temos o suficiente pra deixar a barra do JUnit verde. Vamos agora adicionar o @ComponentScan.
Em nossa classe de configuração (poderia ser qualquer outra registrada no contexto) adiciona a seguinte anotação:

No meu caso meu bean está dentro do pacote br.com.dclick.tentativas.configuration.beans e portanto basta eu alterá-lo adicionando o seguinte código:

Dessa forma posso criar mais um teste e verificar que o bean está vindo corretamente:

Rode o teste e deixa o JUnit feliz.
A única coisa a se ter cuidado aqui, é que com @ComponentScan, você não pode mapear o diretório da própria classe de configuração.

Demais Configurações

Daqui em diante basta anotar suas classes de configuração com as configurações que você deseja ativar, como por exemplo @EnableAsync que permite que os beans rodem de maneira assíncrona com a anotação @Async.

Brinque um pouco com as outras anotações. Acredito que vale o esforço, pois esse tipo de configuração permite abandonar um pouco os arquivos XML e tornam mais fácil o refactor dos beans, afinal teremos erros de compilação com as mudanças de código.

Por enquanto é isso, qualquer dúvida mande nos comentários que responderei assim que possível.

Por @Gust4v0_H4xx0r

Twitter!

Profiles e Environments no novo Spring 3.1

A SrpingSource adotou a estratégia de soltar mais versões do Spring com mais velocidade e escopos de funcionalidades menores.
Seguindo tal estratégia acabou de sair do forno o primeiro release candidate da versão 3.1 do framework.
Para uma estratégia de escopos menores, até que tiveram bastante trabalho e adicionaram várias novidades. Vamos cobrir as novidades aos poucos, começando com uma muito interessante: Profiles e Environments.

Especificando Profiles nos Beans

A idéia de um profile é simples. Um profile define um escopo, envirnmente como é chamado no framework, em que certos beans estarão disponíveis e outros não.
Imagine que você precisa de uma conexão com o banco de dados de testes, que é diferente do banco de dados de desenvolvimento. Com profiles podemos definir um data source do profile de desenvolvimento, e outro do profile de testes, instanciando o correto de acordo com o ambiente que a aplicação irá rodar.

Anotações

Para especificar um profile no seu bean, basta adicionar a anotação @Profile com o nome do profile correspondente. Lembrando que este é o caso em que seus Beans estão sendo criados pelo component-scan usando package scan. Vamos criar um exemplo pra ficar mais claro o que acontece.
Vamos criar uma interface comum para nossos beans:

Agora vamos criar dois profiles e dois beans diferentes para a mesma interface. Um é o bean de desenvolvimento (dev) e o outro de testes (qa).

Repare que já anotei os beans com @Profile respeitando os profiles específicos de cada bean.
Agora criamos o arquivo de beans do spring, dei o nome de spring31-test-beans.xml:

Feito isso, vamos criar um teste para verificar a lógica de criação dos beans. estou usando JUnit 4.8.1.

Algumas coisas diferentes estão acontecendo nesse teste.
Estou instanciando um GenericXmlApplicationContext para carregar meus arquivos de beans, isso porque esse application context me disponibiliza um método que é importante para nosso teste: getEnvironment(). Com isso conseguimos acessar o environment do application context, e mais do que isso, conseguimos setar os profiles que estão ativos usando setActiveProfiles. Repare que é possível de setar mais de um profile como ativo, e que os beans podem precisar de mais de um profile para serem instanciados.
Outro fato importante, é que este environment que está disponível, é uma instância de ConfigurableEnvironment. Se você tentar acessar o profile diretamtente em ApplicationContext, você estará acessando um Environment o qual não permite ativar e desativar profiles. Fica a dica.


Após ativar o profile que queremos, basta chamar o load no contexto seguido do refresh para que os beans sejam criados.
Uma vez que o bean foi criado, basta recuperá-lo e executar o teste para se certificaro que se trata do bean que estamos esperando. Note que o nome dos dois beans é o mesmo, e que apenas um deles existe no application context, pois o outro profile não está ativo.

Nested Beans

Outra maneira de definir profiles nos beans é diretamente no XML do spring. Para que isso seja possível foi necessário permitir nested beans nos arquivos de beans, ou seja, definições de beans dentro de outra definição.
Além de possibilitar a definição de diferentes profiles, essa nova funcionalidade permite que sejam definidos alguns padrões de comportamento para os beans que só se apliquem no conjunto de beans que está nested. Mas isto veremos em um próximo post.
Para testar a definição de profiles direto no XML, vamos criar um outro XML chamado spring31-test-nested-beans.xml:

Feito isso, vamos criar um novo teste que é idêntico ao primeiro, com exceção do arquivo de beans especificado, afinal o comportamento deve ser o mesmo em ambos os casos:

Sua barra do JUnit vai ficar verde e você vai ficar feliz com essa brincadeira rápida com profiles.

Ativando Profiles de outras maneiras

Ativa os profiles no código funciona muito bem no caso dos testes, mas o que realmente se aplica a vida real é poder ativar tais profiles de maneira independente da aplicação e do código propriamente dito. Por isso podemos ativar os profiles setando uma variável global chamada spring.profiles.active.
Podemos ativar tal variável de diversas maneiras, dentre elas no próprio web.xml como um parâmetro da sua Servlet do Spring:

Podemos usar também JNDI, ou até mesmo uma variável de ambiente da VM Java. Se você preferir também pode ativar profiles diretamente no maven:

Fazendo Download

Se você usa o maven, basta adicionar o seguinte no seu pom:

Caso você queira baixar diretamente do site, acesse o site do spring.

Espero ter sido útil, qualquer pergunta basta enviar nos comentários.

Por @Gust4v0_H4xx0r

Twitter!

Impressões sobre o Evento do Google para Desenvolvedores

São Paulo foi escolhida como a primeira cidade para cediar o Google Developer Day, e não foi por acaso. O Google deixou bem claro em seu KeyNote que está acreditando muito no mercado brasileiro no que diz respeito a desenvolvimento de software, e não é uma mera crença, mas sim um argumento baseado em dados que o CTO do Google faz questão de mostrar pra todo mundo em sua palestra. Dentre tais números está a marca impressionante de 500.000 (quinhentas mil) ativações de dispositivos Android no mundo por dia e crescendo, sendo que um dos maiores mercados é o Brasil.






Para participar do GDD era preciso se inscrever no site, e resolver uma provinha com um problema simples de programação. Acertando as questões da provinha, suas chances de ser convidado aumentavam consideravelmente. E foi assim que eu fui convidado.
Trata-se de um evento voltado principalmente para desenvolvedores, com brindes, comida e Wi-Fi de graça, ou seja, o paraíso para muito Nerd entusiasta Google. Com direito a tendinhas e logos do Google espalhados por todo Hall de eventos do Hotel Sheraton.
Fiquei espantado com a quantidade de pessoas, e principalmente com a quantidade de pessoas usando algum smartphone top de linha (com Android claro) no mesmo ambiente. Ambiente esse que tocava música 8 bits dos video games antigos (bons tempos… =) ). E para começar o evento e dar início a maratona de palestras, o CTO do Google pessoalmente ministrou o KeyNote.
O KeyNote deixou todo mundo bem curioso sobre o que estava por vir ao longo do dia nas palestras separadas por tracks como Android, Google AppEngine, Google Chrome e talvez o mais esperado Html 5.

Android

Nada de muito novo com as palestras sobre Android. O pessoal do Google fez questão de manter o suspense sobre qual seria a versão do novo Android (Ice Cream Sandwich), mas que agora já foi revelado que será a 4.0.
Foram feitas algumas palestrar sobre usabilidade de Apps para Android, e passado bem por cima as features novas da plataforma, dentre elas o que acredito fosse o mais esperado é a integração total entre celulares e tablets, ou seja, o mesmo apk para ambos os dispositivos.
Para tornar fácil tal integração, foi adicionado o conceito de Fragment, que nada mais é do que uma porção específica da interface do dispositivo, que varia de acordo com o tamanho da tela. Por exemplo um tablet, pode possuir 3 Fragments padrão, sendo um uma barra de tarefas, outro uma listagem e um uma área de trabalho todos mostrados ao mesmo tempo, mas a mesma aplicação em um celular iria do Fragment de listagem para o Fragment com a área de trabalho por meio de uma transição, pois não cabem os 3 fragments na tela ao mesmo tempo.
Falou-se muito de In App Billing, ou seja, compra de artefatos dentro das próprias aplicações e não diretamente no market. Foram mostrados números bem convincentes, como por exemplo: do top 10 de aplicações mais rentáveis na AppMarket, 9 usam In App Billing. Números no mínimo tentadores para arriscar com a tecnologia.
Acredito que o Google tem muito mais novidade guardada para o Android, mas não falaram nada no GDD, porque o foco do evento foi outro, como veremos.

Google AppEngine

A procura pelas palestras sobre AppEngine foi muito grande, tanto que não consegui entrar em uma delas pois a sala lotou logo depois do anúncio do começo do evento.
O Google definitivamente acredita que seu Cloud é o futuro no que diz respeito a hospedagem de serviços para as Apps Mobile. O foco principal no GDD foi mostrar como que é fácil desenvolver para a AppEngine todos os tipos de aplicativos, incluindo jogos (foi reservada uma palestra apenas para falar de jogos usando a AppEngine).
Acredito que a intenção do Google é difundir mais o uso da AppEngine aqui no Brasil. Acredito que apesar do crescimento que foi obtido, eles percebem que o crescimento pode ser muito maior. Não acompanhei muito o track sobre AppEngine, então não consigo entrar muito em detalhes sobre o que mais foi abordado.

Google Chrome

Eu não esperava que fosse ser dada tanta atenção ao Google Chrome como foi dada no GDD.
Em todas as palestras o Google Chrome era referenciado como principal porta de entrada para a Web e as novas tecnologias. Foram apresentadas ferramentas de produtividade e desenvolvimento para criar aplicativos específicos do Google Chrome.
Acredito que o Google está preparando terreno, e já quer ter em mãos muitos aplicativos compatíveis com o Google Chrome quando chegar a hora de lançar o Chrome OS. E o discurso deles é muito convincente para os desenvolvedores. Eu ouvi muita gente impressionada com as possibilidades e facilidades de desenvolver aplicativos Chrome.

Html 5

Html 5 foi a estrela do evento. Não tinha uma pessoa que os olhos não brilhavam ao ver o trailer de Era do Gelo em 3D no Youtube, ou alguns avatares dançando conforme a música que tocava no ambiente de maneira dinâmica. E todo mundo ficou impressionado quando descobriu que todos os slides de todas as palestras estavam sendo passados no Chrome, e foram feitos em Html 5.
Foram mostradas muita features de Html 5 que ainda estão em teste, e que não necessariamente irão dar certo, mas a idéia não era conseguir algum tipo de vantagem, e sim mostrar o potencial do que está por vir.
Foi apresentado um framework muito interessante em Java: PlayN!. Uma biblioteca para construir jogos que podem ser jogados em Html 5, Android ou até mesmo Java nativo.
Muitas melhorias com tratamento de áudio e vídeo foram mostradas, e do jeito com que os palestrantes demonstraram, é difícil não acreditar que Html 5 ditará o ritmo das aplicações Web em um futuro próximo.





Espero que eu tenha despertado a curiosidade de alguns sobre as tecnologias do Google e da Comunidade que estão por vir. E de uma coisa eu estou convencido, preciso conhecer mais Html 5 .

Por @Gust4v0_H4xx0r

Twitter!

Impressões sobre o Evento do Google para Desenvolvedores

São Paulo foi escolhida como a primeira cidade para cediar o Google Developer Day, e não foi por acaso. O Google deixou bem claro em seu KeyNote que está acreditando muito no mercado brasileiro no que diz respeito a desenvolvimento de software, e não é uma mera crença, mas sim um argumento baseado em dados que o CTO do Google faz questão de mostrar pra todo mundo em sua palestra. Dentre tais números está a marca impressionante de 500.000 (quinhentas mil) ativações de dispositivos Android no mundo por dia e crescendo, sendo que um dos maiores mercados é o Brasil.






Para participar do GDD era preciso se inscrever no site, e resolver uma provinha com um problema simples de programação. Acertando as questões da provinha, suas chances de ser convidado aumentavam consideravelmente. E foi assim que eu fui convidado.
Trata-se de um evento voltado principalmente para desenvolvedores, com brindes, comida e Wi-Fi de graça, ou seja, o paraíso para muito Nerd entusiasta Google. Com direito a tendinhas e logos do Google espalhados por todo Hall de eventos do Hotel Sheraton.
Fiquei espantado com a quantidade de pessoas, e principalmente com a quantidade de pessoas usando algum smartphone top de linha (com Android claro) no mesmo ambiente. Ambiente esse que tocava música 8 bits dos video games antigos (bons tempos… =) ). E para começar o evento e dar início a maratona de palestras, o CTO do Google pessoalmente ministrou o KeyNote.
O KeyNote deixou todo mundo bem curioso sobre o que estava por vir ao longo do dia nas palestras separadas por tracks como Android, Google AppEngine, Google Chrome e talvez o mais esperado Html 5.

Android

Nada de muito novo com as palestras sobre Android. O pessoal do Google fez questão de manter o suspense sobre qual seria a versão do novo Android (Ice Cream Sandwich), mas que agora já foi revelado que será a 4.0.
Foram feitas algumas palestrar sobre usabilidade de Apps para Android, e passado bem por cima as features novas da plataforma, dentre elas o que acredito fosse o mais esperado é a integração total entre celulares e tablets, ou seja, o mesmo apk para ambos os dispositivos.
Para tornar fácil tal integração, foi adicionado o conceito de Fragment, que nada mais é do que uma porção específica da interface do dispositivo, que varia de acordo com o tamanho da tela. Por exemplo um tablet, pode possuir 3 Fragments padrão, sendo um uma barra de tarefas, outro uma listagem e um uma área de trabalho todos mostrados ao mesmo tempo, mas a mesma aplicação em um celular iria do Fragment de listagem para o Fragment com a área de trabalho por meio de uma transição, pois não cabem os 3 fragments na tela ao mesmo tempo.
Falou-se muito de In App Billing, ou seja, compra de artefatos dentro das próprias aplicações e não diretamente no market. Foram mostrados números bem convincentes, como por exemplo: do top 10 de aplicações mais rentáveis na AppMarket, 9 usam In App Billing. Números no mínimo tentadores para arriscar com a tecnologia.
Acredito que o Google tem muito mais novidade guardada para o Android, mas não falaram nada no GDD, porque o foco do evento foi outro, como veremos.

Google AppEngine

A procura pelas palestras sobre AppEngine foi muito grande, tanto que não consegui entrar em uma delas pois a sala lotou logo depois do anúncio do começo do evento.
O Google definitivamente acredita que seu Cloud é o futuro no que diz respeito a hospedagem de serviços para as Apps Mobile. O foco principal no GDD foi mostrar como que é fácil desenvolver para a AppEngine todos os tipos de aplicativos, incluindo jogos (foi reservada uma palestra apenas para falar de jogos usando a AppEngine).
Acredito que a intenção do Google é difundir mais o uso da AppEngine aqui no Brasil. Acredito que apesar do crescimento que foi obtido, eles percebem que o crescimento pode ser muito maior. Não acompanhei muito o track sobre AppEngine, então não consigo entrar muito em detalhes sobre o que mais foi abordado.

Google Chrome

Eu não esperava que fosse ser dada tanta atenção ao Google Chrome como foi dada no GDD.
Em todas as palestras o Google Chrome era referenciado como principal porta de entrada para a Web e as novas tecnologias. Foram apresentadas ferramentas de produtividade e desenvolvimento para criar aplicativos específicos do Google Chrome.
Acredito que o Google está preparando terreno, e já quer ter em mãos muitos aplicativos compatíveis com o Google Chrome quando chegar a hora de lançar o Chrome OS. E o discurso deles é muito convincente para os desenvolvedores. Eu ouvi muita gente impressionada com as possibilidades e facilidades de desenvolver aplicativos Chrome.

Html 5

Html 5 foi a estrela do evento. Não tinha uma pessoa que os olhos não brilhavam ao ver o trailer de Era do Gelo em 3D no Youtube, ou alguns avatares dançando conforme a música que tocava no ambiente de maneira dinâmica. E todo mundo ficou impressionado quando descobriu que todos os slides de todas as palestras estavam sendo passados no Chrome, e foram feitos em Html 5.
Foram mostradas muita features de Html 5 que ainda estão em teste, e que não necessariamente irão dar certo, mas a idéia não era conseguir algum tipo de vantagem, e sim mostrar o potencial do que está por vir.
Foi apresentado um framework muito interessante em Java: PlayN!. Uma biblioteca para construir jogos que podem ser jogados em Html 5, Android ou até mesmo Java nativo.
Muitas melhorias com tratamento de áudio e vídeo foram mostradas, e do jeito com que os palestrantes demonstraram, é difícil não acreditar que Html 5 ditará o ritmo das aplicações Web em um futuro próximo.





Espero que eu tenha despertado a curiosidade de alguns sobre as tecnologias do Google e da Comunidade que estão por vir. E de uma coisa eu estou convencido, preciso conhecer mais Html 5 .

Por @Gust4v0_H4xx0r