Esta é a primeira parte de uma série de três tutoriais que vou colocar sobre a integração de Flex com AIR e SQLite. A primeira (esta) vai centrar-se em uma breve introdução ao AIR com SQLite e vamos criar uma aplicação onde vamos adicionar uma base de dados local, inserir vários tipos de dados e depois coloca-los directamente em uma datagrid em Flex.

A parte dois que será colocada mais tarde (estou a trabalhar nela) será centrada em criar uma form para adicionar dinamicamente informação à base de dados e em colocar várias tabelas a interagirem entre si em que a primeira tem dados e a segunda possui várias informações relativas aos items anteriores.

A terceira será depois a integração das chamadas da base de dados com itemClasses e também ValueObjects.

Espero que gostem! Mauro.

Ontem realizei uma apresentação na monthly-meeting do nosso UserGroup...aqui estão os slides (o video deverá de estar disponivel em breve)

Deixo aqui o link para os slides da minha apresentação “Rich Internet Applications – Uma visão geral” no CTIC 2009 em Viseu a 13 de Maio. Esta apresentação é útil para quem está a entrar nesta coisa das RIAs e quer perceber exactamente o que são, e quais as diferenças e vantagens face às aplicações Desktop e Web. Espero que vos seja útil.

Tal como prometido, aqui estão os slides da apresentação “Enterprise RIAs - This is how we do it“. Espero que tenham gostado e que a apresentação vos tenha sido útil.

Durante as minhas aulas de Actionscript em ambiente de FLASH, por norma verifico que os formandos têm alguma dificuldade em utilizar algumas das "best practices" mais comuns nomeadamente em relação á criação de Eventos personalizados, no entanto, e assim que conseguem ultrapassar essa barreira, a primeira questão que me colocam é sempre a mesma:

“então e se eu quiser enviar dados pelo meu Event Object, por forma a ……”

Eis que surge então a necessidade de passar o conceito de VO (Value Object) e criação de Classes de Eventos personalizadas.

Como tive hoje que criar alguns ficheiros para exemplificação do Conceito de Classe de Evento Personalizada para envio de dados de uma instância para outra, resolvi partilhar convosco neste Blog os mesmos Ficheiros na esperança que venha ainda a ser útil para alguns dos meus leitores, ou ainda servir de ponto de consulta e esclarecimento de dúvidas para aqueles que durante as aulas não perceberam o conceito.

Sendo Assim vamos começar por analisar o pequeno problema que se coloca, e que servirá de “Case Study” para a criação de uma Class de Evento personalizada e do conceito de VO.

PROBLEMA:

• Temos um form onde a pessoa regista o seu nome, idade e situação laboral, e ao clicar num botão registar, pretende-se acrescentar a uma lista (Texto) os dados da pessoa.

RESOLUÇÃO:

1. Criar uma Class PessoaVO, que irá servir para armazenar os dados da pessoa que forem inseridos no Form
2. Criar uma Class PessoaEvent, que será uma subclass da Class Event, e que servirá para enviar um “Event Object” que incluirá uma instância da Class PessoaVO, com os dados anteriormente adquiridos no Form.
3. A Aplicação principal estará á “escuta” da ocorrência do Evento PessoaEvent, e quando este for detectado, receberá pelo “Event Object” uma instância de PessoaVO com os dados da pessoa.
4. A Aplicação após receber os dados da pessoa insere e actualiza a TextArea com os registos das pessoas.

Mãos á obra, vamos começar por criar um ficheiro em FLASH, com um form com duas instâncias de TextInputs, para o nome e idade, uma instância de CheckBox para o estado laboral e um botão de registo, ao lado criar uma Textarea para ir acrescentando os Registos, ou seja, qualquer coisa deste género(desculpem mas a designer estava de folga, lol):

Passo seguinte vamos criar a Class PessoaVO, que será uma classe Value Object, e por esse motivo terá somente propriedades, propriedades estas que servirão para guardar os dados do form de registo:

package {

  public class PessoaVO {

   public var nome:String;

   public var idade:int;

   public var empregado:Boolean;

  }

}

Depois de criar a Class responsável pelo armazenamento e transporte dos dados do formulário vamos criar a Class PessoaEvent, que irá ser uma SubClass da Class Event:

package {

import flash.events.Event;

import PessoaVO;

public class PessoaEvent extends Event {

public static const PESSOA:String = "pessoa";

public var dadosPessoa:PessoaVO;

public function PessoaEvent(type:String, voPessoa:PessoaVO) {

super(type);

this.dadosPessoa = voPessoa;

}

public override function clone():Event {

return new PessoaEvent(type, dadosPessoa);

}

}

}

Esta Class começa por fazer o "extends" da Class Event, na linha 9, criamos uma constante do tipo de String que irá identificar o "type" do nosso evento para usar depois como por exemplo usamos o CLICK num MouseEvent, na linha 10 criamos uma instância de PessoaVO, para guardar os dados do form e posteriormente enviar os mesmos pela instância de evento criada. O constructor da Class é bastante simples e terá como parâmetros o "tipo " de evento criado, e a instância, neste caso, de PessoaVO. na linha seguinte (13), chamamos o constructor da Class "Pai" para passar o tipo de evento criado, aqui não se passa qualquer parâmetro extra pois a Class "Event" não contêm parâmetros adicionais. Na linha 14 atribuímos á instância da class "dadosPessoa" os valores recebidos no parâmetro voPessoaConstructor da Class. Por fim é necessário efectuar o overrride do método clone da class Event, de forma a que esta instância de evento tenha um comportamentos normal de um evento como o "Bubbling" por exemplo, nesta definição retornamos o event criando a instância do novo evento e passando os dados armazenados na instância da PessoaVO. do Por fim criamos a Document Class do nosso ficheiro:

package {

import flash.display.MovieClip;

import flash.events.MouseEvent;

public class MainEventPessoa extends MovieClip {

public var pessoa:PessoaVO;

public function MainEventPessoa() {

pessoa = new PessoaVO;

registarBtn.addEventListener(MouseEvent.CLICK, registar);

this.addEventListener(PessoaEvent.PESSOA, receberPessoa);

}

private function receberPessoa(e:PessoaEvent):void {

registosTa.appendText("\n------------------\n"

+ "Nome: " + String(e.dadosPessoa.nome) +

"\n" + "Idade: " + String(e.dadosPessoa.idade) + "\n" +

"Nome: " + String(e.dadosPessoa.empregado) + "\n");

}

private function registar(e:MouseEvent):void {

pessoa.nome = nomeTi.text;

pessoa.idade = int(idadeTi.text);

pessoa.empregado = empregadoCb.selected;

dispatchEvent(new PessoaEvent("pessoa", pessoa));

}

}

}

Nesta Document Class, começamos por criar uma instância de PessoaVO, onde iremos atribuir os valores dos dados que irão ser preenchidos no FORM, na linha 13, definimos o evento click no botão registar que irá inicializar toda a sequência do script. o Listener do clicar em Registar vai associar os dados dos campos do form ás propriedades da instância de PEssoaVO (pessoa) linhas 26 a 28, na linha 30 "criamos" um evento do tipo PessoaEvent, onde iremos incluir nos parâmetros do constructor, o nosso PessoaVO com o nome "pessoa". Na linha 14 a nossa Aplicação recebe o evento "PessoaEvent.PESSOA", e chama o listener das linhas 18 a 22 que irá acrescentar(para os mais esquecidos deverão sempre usar o método appendText da Class TextField, e não o operador " += " para concatenar strings) á TextArea os dados que recebeu no "Evento Object" e que acedemos na propriedade "dadosPessoa" deste.

espero que este Post seja esclarecedor para muitos de vós, não hesitem em colocar questões ou sugestões para explicações futuras, deixo aqui tb um ficheiro zip com os ficheiros exemplificando o mini-tutorial.

Quando se constroem aplicações web, é normalmente uma boa prática configurar-se o ambiente de desenvolvimento de forma a que seja o mais semelhante possível ao ambiente de produção.
Uma das configurações que se faz antes de se iniciar o desenvolvimento do projecto, é a criação de um virtual host cuja configuração seja o mais idêntica possível à configuração do servidor onde o projecto estiver alojado.

Entre outras configurações, a mais importante é a estrutura de directorias, que em desenvolvimento é diferente da estrutura em produção.

Regra geral, quando se trata de uma aplicação com backend e um backoffice nós costumamos organizar o nosso ambiente de desenvolvimento desta forma:

\webfuel\projecto

\webfuel\projecto\frontend
\webfuel\projecto\frontend\bin-debug (binários da aplicação)
\webfuel\projecto\frontend\src
\webfuel\projecto\frontend\[...]

\webfuel\projecto\backoffice
\webfuel\projecto\backoffice\bin-debug (binários do backoffice)
\webfuel\projecto\backoffice\src

\webfuel\projecto\backend (backend, por exemplo em php)
\webfuel\projecto\mm (imagens, e outros recursos multimédia)

Quando corremos a aplicação localmente, sem os virtual hosts, vamos obter algo como http://localhost/projecto/bin-debug/index.swf .

Para que a aplicação possa comunicar com o backend, o path para o gateway será por exemplo algo como ../../backend/gateway.php .

Para que a aplicação possa aceder aos recursos multimédia (imagens, etc) o caminho será algo como ../../mm/imagem1.jpg .

Estes caminhos não batem certo com os caminhos na versão de produção:

www.projecto.pt (binários da aplicação)
www.projecto.pt/backoffice (binários do backoffice)
www.projecto.pt/backend (backend, por exemplo em php)
www.projecto.pt/mm (imagens e recursos multimédia)

Vemos que na versão de produção a aplicação para aceder ao backend vai fazer o caminho backend/gateway.php - enquanto que na versão de desenvolvimento, fazia o caminho ../../backend/gateway.php . O mesmo se aplica para as restantes directorias.

Há muita gente que trabalha com a estrutura de directorias e caminhos do ambiente de desenvolvimento, e quando chega a altura de alojar o projecto, mudam os caminhos no source code (ou num ficheiro de configuração) e recompilam - má prática.

Solução: criar um virtual host

O Apache permite que se associe um ambiente com configurações específicas a um determinado domínio. Ou seja, se o Apache receber um pedido de acesso ao dominio www.projecto.dev , e houver um virtual host para esse dominio, podemos configurá-lo para devolver a nossa própria estrutura de directorias (e não só).

O que gostariamos era de escrever no browser www.projecto.dev , e ser-nos exposto o nosso projecto com a estrutura de directorias igual à estrutura que vamos obter no servidor.

Vamos começar por configurar o apache editando o ficheiro httpd.conf na directoria conf do apache. No final do ficheiro, basta adicionar as seguintes linhas:

NameVirtualHost 127.0.0.1
Include conf/vhosts/*.conf

A primeira linha permite que o apache possa associar os nomes dos domínios pedidos aos virtual hosts que vamos configurar (mais info aqui).

A segunda linha indica ao Apache para carregar e executar todos os ficheiros de configuração com a extensão .conf na directoria vhosts. Isto fará com que criar um novo virtual host seja algo como criar um novo ficheiro .conf na directoria vhosts.

Vamos agora à directoria vhosts, e vamos criar um ficheiro chamado projecto.conf .

Nesse ficheiro, vamos colocar o seguinte:

<VirtualHost 127.0.0.1:80>
DocumentRoot "D:\OsMeusProjectos\projecto\frontend\bin-debug"
ServerName www.projecto.dev
<Directory "D:\OsMeusProjectos\projecto\frontend\bin-debug">
Options Indexes FollowSymLinks Includes ExecCGI
AllowOverride All
Order allow,deny
Allow from all
</Directory>

Alias /backend "D:\OsMeusProjectos\projecto\backend"
Alias /backoffice "D:\OsMeusProjectos\projecto\backoffice\bin-debug"
Alias /mm "D:\OsMeusProjectos\projecto\mm"
</VirtualHost>

Isto vai indicar ao Apache que os pedidos recebidos na porta 80, máquina 127.0.0.1 relativos ao domínio www.projecto.dev irão ter a directoria bin-debug do frontend como a directoria de raíz do projecto. Os Aliases permitem que o Apache exponha o backend, backoffice e mm em directorias específicas, resultando assim num ambiente igual ao de produção.
Depois de feita a alteração acima, é preciso reiniciar o Apache.

Falta conseguirmos fazer com que pedidos para www.projecto.dev vão parar ao Apache. Para isso, vamos mexer no ficheiro "hosts" do Windows para forçarmos o redireccionamento de pedidos para www.projecto.dev para a nossa máquina local.
Basta para isso editar o ficheiro hosts (mais info no wikipedia), na directoria c:\windows\system32\drivers\etc . Recordo que no Windows Vista, será preciso abrir um editor de texto com permissões de administrador, e depois fazer o File > Open e procurar o ficheiro no disco - caso contrário não será possível editá-lo.

Neste ficheiro, bastará colocar o seguinte:

127.0.0.1 www.projecto.dev

A linha acima vai indicar o sistema operativo que todos os pedidos feitos para o domínio www.projecto.dev vão ser reencaminhados para 127.0.0.1 - a nossa máquina local. Como estamos a fazer os pedidos dentro de um web-browser, a porta por defeito será a 80. O resto é fácil de adivinhar: pedidos para a nossa máquina local na porta 80 vão ser entregues a quem? Ao nosso amigo Apache! Que ao receber um pedido destinado ao domínio www.projecto.dev, vai procurar o Virtual Host respectivo e expô-lo com a estrutura que definimos.

Obviamente, isto abre-nos as portas para fazer configurações mais radicais (i.e. configurar o Apache para que o Virtual Host seja igualzinho ao do servidor final).

Fizemos na Webfuel um projecto há uns meses para um dos principais criadores de joias nacionais. Um dos requisitos do cliente era que na secção de showroom, cada joia pudesse ser apresentada dentro de uma ferramenta de zoom que permitisse ver a joia em detalhe - implicando que as fotos das joias tivessem resoluções superiores a 700x700 pixeis. Outro dos requisitos, era que as imagens das joias não tivessem fundo para que pudessem encaixar correctamente no layout do site - implicando que teria que ser escolhido um formato que suportasse transparência, neste caso PNG. Para terminar, era imperativo que o cliente, sem quaiquer conhecimentos de informática, pudesse adicionar e actualizar as fotos das joias através do backoffice - implicando que cada foto fosse um PNG colocado no servidor pelo cliente através das funcionalidades do backoffice.

Estas pré-condições implicaram o recurso ao formato PNG - o único que permitiria resolver o problema, visto a norma JPEG2000 não ser suportada pelo Flash Player. Porém, adoptar o formato PNG para as fotos das joias com as dimensões acima referidas resultou em ficheiros de cerca de 500KB. Isto, num site com cerca de 200 a 300 jóias, com várias fotos cada.

Depois do deployment do site constatou-se o esperado: em ligações rápidas, os 500KB de cada foto não representavam grandes problems, mas em ligações lentas podia ser desesperante esperar de 10 a 20 segundos para a foto carregar. E com o disseminar recente das ligações 3,5G (kangurus, vodafone e tmn connect box, etc), tornou-se problemático pelo que tivemos que procurar por uma solução.

Encontrámos uma extensão chamada PNG2SWF pertencente ao pacote SWFTools que permitia converter um PNG para um SWF. Como é sabido, um PNG embebido em SWF pode levar compressão sendo mantida a transparência, pelo que decidimos fazer algumas experiências. Após alguns testes, tivemos resultados impressionantes: imagens de 500 Kb passaram para 60 Kb sem serem perdidos os canais alpha. Exactamente o que precisávamos!

O problema que surgiu de seguida consistia em saber como integrar o PNG2SWF com o site / backoffice sem afectar a experiência do utilizador. Era importante que o cliente continuasse a utilizar o backoffice como sempre, sem trabalho adicional.

Fizemos então um script simples, que vos ofereço adiante, e que consiste num género de proxy para carregar PNGs, só que devolve o PNG convertido para SWF, e escalado para dimensões arbitrárias escolhidas pelo programador.

O download do script pode ser feito aqui: pngoptimize . O source code pode ser visto abaixo:

<?php

    // 31-10-2008
    // pngOptimize.php by João Saleiro - Webfuel ( joao.saleiro@webfuel.pt)
    // Todo:
    // - receive quality from $_GET vars
    // - set default values for quality, w and h

    $image = $_GET['url'];
    $w = $_GET['w'];
    $h = $_GET['h'];

    $date = filemtime($image);

    // Generate SWF filename
    $swf = $image . $w . $h .'_'. $date .'.swf';

    // Generate SWF if it doesn't exist
    if (!file_exists($swf))
    {
        // Calculate dimensions
        list($width, $height) = getimagesize($image);

        $proportion = 1;
        if ($width > $height)
            $proportion = $w/$width;
        else
            $proportion = $h/$height;

        // Load image and preserver transparency
        $im = @imageCreateFromPNG ($image);
        imagealphablending($im, false);
        imageinterlace ( $im, 0);
        imagesavealpha($im, true);

        // Create new Image
        $im_dest = imagecreatetruecolor ($width*$proportion,  $height*$proportion);

        // Set transparency
        $background = imagecolortransparent($im);
        imagecolortransparent($im_dest, $background);
        imagealphablending($im_dest, false);
        imagesavealpha($im_dest, true);

        // Resize old image to new image
        imagecopyresampled($im_dest, $im, 0, 0, 0, 0, $width*$proportion, $height*$proportion, $width, $height);

        // Save new image
        $tempName=$image.'temp.png';
        imagepng($im_dest, $tempName);

        // Clean memory
        imagedestroy($im);
        imagedestroy($im_dest);   

        // Convert new image to SWF
        shell_exec("./png2swf -j 85 -o $swf $tempName");

        // Remove temp file
        unlink($tempName);
    }

    // If we get here, and there's no file, we don't return nothing
    if (!file_exists($swf))
        exit(0);

    // Return generated SWF
    header("Content-type: application/x-shockwave-flash");
    $fp = fopen($swf,"rb");
    fpassthru($fp);
    fclose($fp);
?>

O algoritmo é relativamente simples:

1. O script recebe por GET os parâmetros: url, w e h, que correspondem ao endereço relativo do PNG, e as dimensões que queremos para o nosso SWF resultante;
2. O script vai então gerar um nome de ficheiro único para aquele url, com aquelas dimensões, e para a data do PNG (i.e. se o PNG for actualizado pelo cliente o script detecta que há um PNG novo, o que implica gerar um novo SWF com novo nome);
3. É verificado se já existe algum SWF com aquele nome único (i.e. uma versão em cache daquele PNG já convertido para SWF com aquelas dimensões). Se existir, o SWF é aberto e lido, e feito um fpassthru do ficheiro (i.e. é devolvido o conteúdo do ficheiro SWF), depois de definido o header application/x-shockwave-flash para que o Flash possa interpretar o resultado do ficheiro PHP como sendo um SWF;
4. Se não existir nenhum SWF, o script vai abrir o PNG referido no URL, e criar um novo PNG temporário com as dimensões referidas, mantendo a transparência;
5. É então feita a conversão desse PNG temporário para SWF através de um shell_exec que executa o png2swf com os parâmetros necessários para a conversão, sendo gerado um SWF com o nome de ficheiro referido acima, e devolvido com o fpassthru.

Para utilizar este script é necessário:

• Colocar no servidor, na mesma directoria do pngConvert.php, o png2swf (linux) ou png2swf.exe (windows);
• Permissões de execução do png2swf nessa directoria;
• Permissões do php para a chamada de comandos externos (shell_exec);
• Permissões de escrita nas directorias onde estão os ficheiros PNG para serem lá colocados os ficheiros SWF;

Do lado do cliente, o código necessário para carregar um PNG convertido para SWF através do pngConvert é:

   MXML:

<mx:Image source="pngConvert.php?url=imagem.png&w=100&h=100"/>

    Actionscript 3 (i.e. Flash)

var l:Loader=new Loader();

l.load(new URLRequest('pngConvert.php?url=imagem.png&w=100&h=100'));

addChild(l);

O script ainda pode levar algumas melhorias, nomeadamente:

• a qualidade da imagem também ser passada por GET;
• se os parâmetros w e h não estiverem definidos, o SWF gerado é da mesma dimensão que o PNG original.

Não implementei essas melhorias porque não precisei na altura, mas se alguém quiser melhorar, é bem vindo - publicarei depois aqui a versão melhorada, com devidos créditos.

Espero que esta informação e script vos sejam úteis. O script pode ser utilizado livremente e só pedimos que seja colocado um comentário neste post com o endereço do site onde o estão a usar, para alegrarem o nosso dia.

Ainda de "ressaca" da MAX, pareceu-me interessante apresentar um conceito que foi avançado pelo Kevin Lynch na keynote de abertura da MAX e que me parece vai determinar em larga medida a forma como se vai desenvolver software nos próximos tempos.

O conceito em si não é nada de novo e, como acontece na maioria dos casos, inúmeras aplicações no mercado já o utilizam. No entanto, a formalização com um nome específico dá-lhe um ar oficial que o coloca ao nível de conceitos como "cliente-servidor" e "web application".

Este conceito diz respeito à forma como as aplicações cada vez mais tendem a comunicar com origens de dados. De um paradigma em que a grande maioria das aplicações possuem uma origem de dados bem definida (normalmente associada apenas com essa aplicação), passa-se para a conexão com diversas origens de dados diferentes que podem ser disponibilizadas por terceiros em qualquer parte do mundo dando corpo ao conceito de "cloud computing".

O que tornou isto possível foi a disponibilização de dados e até mesmo lógica através da publicação de web services que estão disponíveis para conexão utilizando protocolos standard bem definidos e que podem ser consumidos por uma infinidade de tecnologias tanto de cliente como de servidor.

Um exemplo clássico deste tipo de aplicações são os famosos mashups (quem ainda não fez um mashup?). O que esta apresentação do Kevin traz de especial é que ela foi inserida no seio de uma keynote que pretendia ser "séria" e que avançava a visão da Adobe para a evolução da programação. Não foi uma qualquer sessão de show-off em que pretendia apresentar as potencialidades de uma qualquer tecnologia ou plataforma. E eu acredito que realmente as coisas vão começar a ser feitas desse modo. A regra de ouro "se alguém na empresa já escreveu código para fazer isso, porque deverei eu escrevê-lo de novo?" passará a ser "se alguém na internet já escreveu e publicou um serviço para fazer isso....".

Será que, mais uma vez, a Adobe cunhou um conceito que vai "pegar" (tal como a Macromedia fez com o conceito RIA)? Será que este tipo de aplicações vão sair do âmbito das aplicações sociais e de entertenimento e vão invadir o mercado empresarial? Acho que só o futuro poderá responder a estas perguntas. O que é que vocês acham?

Olá,

Este ano tive a felicidade de ir à MAX em S. Francisco. Não foi a minha primeira participação numa MAX mas foi a primeira vez que fui à sua versão norte americana.

De um modo geral, o evento foi tudo aquilo que se esperava dele e a possibilidade de estabelecer contactos efectivos com pessoas que, de outro modo, poderíamos nem sequer ter a oportunidade de conhecer é uma enorme mais valia resultante da participação nestes eventos.

Em termos de sessões, verificou-se que, este ano, a Adobe centrou-se ainda mais nas suas tecnologias de desenvolvimento de RIAs que, de facto, dominaram a grande maioria das sessões técnicas e foram um aspecto muito importante nas comunicações gerais. Coldfusion, LiveCycle e BlazeDS encontraram, também, um espaço bastante significativo o que permitiu a quem esteve presentente perceber de que forma se podem construir experiências web considerando todos os aspectos envolvidos (à excepção de uma solução de base de dados).

Um outro vector abordado que tem vindo a ganhar uma crescente notoriedade por parte da Adobe é o dos serviços como é o caso do Cocomo, uma plataforma construida sobre o Acrobat Connect que permite o desenvolvimento de aplicações em Flex com recurso a partilha em tempo real de dados, audio e vídeo.

Relativamente às sessões gerais, entre as participações do costume (O Shantanu e o Kevin Lynch fizeram as comunicações mais formais sobre a empresa e as tecnologias em desenvolvimento), houve uma que despertou bastante interesse quer pela forma como foi apresentada, quer pelo conteúdo apresentado. De facto, ver o Ben Forta e o Tim Buntel vestidos de "agentes especiais" à procura de uma solução para a criatividade foi um momento gratificante que deu origem a conversas entre os dois que pouco ficaram a dever a um qualquer filme de comédia do tipo "Get Smart". Os temas abordados nesta apresentação correram as tecnologias e ferramentas essenciais da Adobe para a criação de experiências de utilização ricas na internet tendo partido do design, passado pelo desenvolvimento e, finalmente, acabando na disponibilização das mesmas.

Os sneaks deste ano, apesar de bastante bons, deixaram um pouco a desejar relativamente ao de anos anteriores (também não é fácil rivalizar com o anúncio de um novo Flash player). Algumas tecnologias na área da imagem e vídeo foram apresentadas ao lado de plugins e plataformas que permitem o desenvolvimento mais fácil de aplicações web e desktop com recurso a diversos mecanismos automáticos e a conceitos largamente distribuídos por outras empresas e tecnologias como é o caso, por exemplo, dos widgets.

Resta-me apenas dizer que a cidade de S. Francisco é fantástica e que me senti perfeitamente em casa já que dizem que é das cidades americanas a que mais se assemelha a uma cidade europeia.

Quero finalizar esta entrada no blog agradecendo à Sumi Lim que é a Developer relations manager para EMEA e que, portanto, serve de interlocutora entre o nosso grupo e a Adobe. O carinho com que nos recebeu e o esforço que realizou no sentido de nos levar a conhecer e a manter contactos com o maior número de pessoas possível foi um dos aspectos mais importantes desta participação.

Cocomo é uma plataforma que permite adicionar capacidades real-time nas nossas RIAs e é composto de um conjunto de componentes client-side assim que de uma infraestrutura server-side suportada pela Adobe. Da parte do utilizador, este só terá que se preocupar em desenvolver a aplicação visto toda a gestão  de manutenção e escalabilidade serão da preocupação da Adobe.

Esta versão beta permite adicionar as seguintes funcionalidades:

• VoIP 
• Video via webcam
• Chat
• Whiteboards multi-utilizadores
• FileSharing em real-time
• Gestão de utilizadores
• Permissões e Perfis
  
• Data Messaging robusto

Para começar a usar, terão de se inscrever no Portal para obter a shared key. Para mais informações consulte a página do Labs

 

A Adobe publicou ontem uma imagem muito interessante e elucidativa para representar o ecosistema da Flash Platform. Na imagem é possível ver o universo das ferramentas Adobe, e a forma como se interligam.

 

À esquerda, a azul claro, temos as ferramentas de design: After Effects, Adobe Illustrator, Fireworks e Photoshop. Com estas ferramentas os designers podem criar o aspecto gráfico das aplicações / sites / experiências / etc, sendo este exportado num novo formato, o FXG. O FXG é um novo formato da Adobe baseado em XML para representar elementos gráficos, e que é compatível com o universo que circunda a plataforma Flash.

A azul escuro temos as aplicações de desenvolvimento: o Flash IDE, Flash Catalyst (anteriormente conhecido por Thermo), e o Flex Builder. O Flash IDE e o Flex Builder são os nossos já velhos conhecidos, sendo o primeiro mais virado para Interaction Designers que procuram um IDE visual, e o segundo para developers que procuram um IDE virado para código. O Flash Catalyst é uma ferramenta que ficará no meio, entre o Flash e o Flex Builder que permitirá a Interaction Designers utilizar um ambiente gráfico e intuitivo para importar layouts feitos nas ferramentas de design, e convertê-los através de alguns cliques para aplicações, podendo ser adicionada interactividade. O resultado o Flash Catalyst é MXML (bem formado, segundo dizem) que depois é entregue aos developers para implementarem toda a parte dura do código. Segundo se diz, o Flash Catalyst pode também carregar MXML já alterado pelos developers (corrijam-me se estiver enganado), pelo que permitirá que ambas as equipas - developers e designers - possam trabalhar ao mesmo tempo, recorrendo a um source control. O Flash Catalyst está ainda a um ano de ser lançado em versão final, pelo que durante este período serão certamente disponibilizadas versões beta e de preview.

A cinzento, em cima, temos o Flex SDK, a framework de eleição para desenvolvimento de RIAs. É composta por um conjunto de componentes, e ferramentas que assentam em Actionscript 3, para desenvolvimento rápido de aplicações. O Flex SDK está actualmente na versão 3, mas a versão que se segue (nome de código: Gumbo) vai trazer novidades absolutamente estontantes. Sendo open-source, é possível acompanhar o desenvolvimento do Gumbo, e inclusivé, fazer já aplicações com a actual versão. As milestones do Gumbo são:

• lançamento do MAX preview agora durante o MAX;
• versões Beta 1 e Beta 2 na primeira metade de 2009 (aposto em Fevereiro e Maio);
• versão final na segunda metade de 2009.

As ferramentas acima "não fazem mais" que gerar ficheiros SWF que são depois interpretados e executados nos devidos runtimes: o Flash Player, que corre dentro do browser, e com limitações de acesso à máquina do utilizador (obviamente por motivos de segurança), e o Adobe Air, que permite que os SWFs possam ser instalados nos computadores dos utilizadores e correr como aplicações desktop, com acesso à maquina do utilizador como qualquer outra aplicação (i.e. leitura do disco, clipboard, etc). O Flash Player está neste momento na versão 10 que introduz uma panóplia de funcionalidades fantásticas: suporte nativo a 3D, FileReference local, suporte a filtros avançados (Pixel Bender), suporte avançado a texto, melhor performance com suporte a aceleração pela placa gráfica, etc.

De referir que os runtimes acima são compatíveis com os principais sistemas operativos, nomeadamente Mac, Windows e Linux - e a grande novidades do Max: graças ao Open Screen project temos também o Flash Player 10 em Symbian, Windows Mobile, Wii, Playstation, etc.

As aplicações (SWFs) que assentam sobre os runtimes acima serão fat clients descarregados para as máquinas dos utilizadores (pelo browser, ou instalados com Adobe Air), e que poderão posteriormente comunicar com um servidor para trocar dados. Essa comunicação pode assentar em diversos protocolos e formatos, tais como simples texto, XML, SOAP (web-services), JSON, e AMF - o formato de dados em que assenta o Flash Remoting. Estes formatos podem ser trocados sobre HTTP ou HTTPs, Sockets, RTMP, entre outros.

Esta panóplia de formatos de comunicação permitem comunicar com quase todas as tecnologias server-side existentes no mercado, pelo que aplicações feitas em Flash são facilmente integráveis com plataformas existentes, sejam elas Adobe ou de terceiros. Da Adobe, temos os servidores especificamente criados para Flash: BlazeDS e Flash Media Server que introduzem funcionalidades de Data e Multimedia Streaming, entre outras. Depois temos os servidores ColdFusion e LiveCycle ES, de onde a minha funcionalidade favorita deste último é de longe o facto dos servidores poderem tomar a iniciativa de contactar os clientes e empurrar dados (i.e. dados dos clientes sincronizados automaticamente com o servidor). Apesar da Adobe fornecer as suas próprias soluções server-side, como dito acima aplicações Flash podem ser facilmente integradas com outras soluções de backend de entidades terceiras, como, PHP, JAVA, .NET, etc, desde que implementem algum dos protolocos de comunicação acima referidos. Como exemplos de plataformas, temos BEA, SAP, salesforce.com, WebSphere, Zend, etc.

Vendo esta imagem, é inevitável sentir orgulho de ter acreditado e escolhido um dia o caminho da plataforma Flash. Aquilo que começou um dia como uma ferramenta para adicionar animações a páginas Web, é hoje em dia a mais poderosa plataforma para criar aplicações distribuídas e interactivas. As nossas amigas RIAs.

Ainda o evento MAX SF começou, já circulam algumas das novidades dos goodies que vamos poder usufruir.

AIR 1.5

Para começar, fomos contemplados com a nova versão do AIR 1.5. Esta é contemplada com suporte para base de dados locais encriptados assim como a integração do Flash Player 10 e uma versão actualizada do engine WebKit. A inclusão do Flash Player 10 irá permitir tirar partido das novas funcionalidades tais como custom filters, blend modes, fills através do Pixel Bender e suporte para 3D. A versão do Webkit vem com o suporte para Squirrelfish, um novo interpretador de JavaScript que permite ganho de performance.

Como parte dos meus estudos para a Certificação Flex 3, estou a rever alguns pontos em que me sinto menos à vontade dentro do maravilhoso mundo do Flex. Vou começar por um ponto que ainda hoje reserva bastantes dificuldades de compreensão. Falo do MVC - Model, View, Controller. O MVC é um padrão quer de desenho quer de arquitectura usando na construção de software. O uso deste padrão é muito vasto, e entende-se como o tratamento separado da lógica de programação e a interface grafica do proprio software que resulta numa enorme versatilidade da aplicação que torna muito mais facil modificar o aspecto visual da aplicação ou o código sem criar dependencias/afectação entre eles lidando facilmente com a comunicação entre utilizador, interface gráfica e o código da nossa aplicação.

Open Web Application Security Project (OWASP) vai organizar, pela primeira vez em Portugal, durante os dias 4 a 7 de Novembro, o OWASP Summit EU Portugal 2008, naquela que é uma das suas maiores reuniões mundiais.

Este encontro vai juntar especialistas de todo o Mundo na área da Segurança de Informação, em particular no domínio da Segurança em Aplicações baseadas na Web, os quais irão apresentar e discutir as mais recentes ferramentas e documentos desenvolvidos pela OWASP.

Para além disso, vão realizar-se mais de 40 apresentações de líderes de projectos patrocinados pela OWASP, divididas por seminários técnicos e de negócio, acções de formação e múltiplas sessões de trabalho, tudo na área de pesquisa de segurança para aplicações Web.

É ainda objectivo do Summit dinamizar a colaboração, atingir e traçar novos objectivos para projectos OWASP, representações locais e para toda a comunidade OWASP.