Adobe AIR e Java: Comunicação via Socket

Há um tempo atrás, comecei uma busca por uma forma de desenvolver uma aplicação desktop que me permitisse reaproveitar meus conhecimentos no desenvolvimento de aplicações web. Foi aí que me deparei com o Adobe AIR, alvo do exemplo deste post, onde vou deixar para fazer um post mais introdutório depois.

Neste post, estarei abordando o desenvolvimento de uma simples aplicação front-end em Adobe Air Java Script/HTML que integrará com um código Java, através de Socket.

A utilização de Socket com Adobe AIR é bem recomendado quando você precisar integrar suas aplicações Adobe AIR com linguagens, até o momento, não suportada diretamente pelo Adobe AIR.

Por se tratar de uma aplicação para demonstrar os conceitos básicos do desenvolvimento Adobe AIR JS/HTML, iremos partir de algo bem simples.

A aplicação front-end terá apenas um campo texto de entrada e um botão de ação (Veja o código abaixo).

Repare que todo o código é escrito em HTML e Java Script, apenas.

Nota: Como podemos ver, importei uma biblioteca Java Script: AIRAliases.js. Esta biblioteca visa simplificar o desenvolvimento AIR atribuindo "aliases" mais simples para referenciarmos os objetos da AIR API. Por exemplo, ao invés de digitar:

var desktop = window.runtime.flash.filesystem.File.desktopDirectory;

Você digitará apenas:

var desktop = air.File.desktopDirectory;

Para trabalhar com Socket no Adobe AIR, utilizaremos a classe Socket na própria AIR API.

Para o envio e recebimento de mensagens com o Socket AIR, precisamos registrar dois eventos: air.Event.CONNECT e air.ProgressEvent.SOCKET_DATA, respectivamente.

O evento air.Event.CONNECT nos informa quando a conexão com o servidor Socket é iniciada e possível. E quando isto acontecer, a engine AIR irá acionar a função onSocketConnectionOpen, definida no Java Script.

O evento air.ProgressEvent.SOCKET_DATA, nos informa quando um dado é retornado pelo servidor Socket.

Neste exemplo, a engine AIR irá acionar a função onSocketDataReceiver.

No código abaixo, temos um exemplo da classe Java que desempenhará o papel de um servidor Socket, que escutará as solicitações na porta 9999.


Por fim, segue abaixo o descritor da nossa aplicação de exemplo.


Dica: Para simplicar a execução das aplicações Adobe AIR via prompt-console, acrescente o diretório ...\AdobeAIRSDK\bin na variável de ambiente PATH do seus sistema operacional.

Para executar a aplicação, entre com o seguinte comando:

> adl AirSocketClient-app.xml

Agora, execute a classe que representa o servidor Socket. Neste exemplo, eu estou usando o Eclipse.

Na interface da aplicação Adobe AIR, entre com qualquer texto e logo após clique no botão Enviar.
Após isso, no console Java, você irá ver seu texto impresso pela classe Java (servidor Socket).

Espero ter consigo passar um pouco a idéia. Em breve voltarei com mais novidades sobre o Adobe AIR.

SOA e o Mundo da Moda

Olá meus amigos. Até que enfim tive tempo para voltar a escrever para o blog.

Bem, durante esse tempo ausênte, tive a oportunidade de participar de eventos e provas de conceitos com algumas plataformas (que no momento não vou citar nomes) ditas "milagrosas", que não convém comentar neste momento, que estão na boca de todos desde o ano passado. E é aí, que vem o título deste novo post.

Este título refere a uma analogia entre o que se vende e o que se implementa da arquitetura SOA com o os grandes desfiles e eventos do mundo da moda (o que se vende) e as roupas que compramos no dia-a-dia (o que se implementa).

Percebo que, assim como no mundo da moda, as grandes fornecedoras de softwares recriam um cenário facilitador, glamuroso, cheio de estilo, com idéias inovadoras, ditando novos comportamentos e maneiras de pensar. Porém, na prática não é isso que vem acontecendo com elas próprias, muito menos é o que chega em nossas mãos em curto e médio prazo.

Tudo isso fica evidente quanto vemos que desde do ano passado estas novas plataformas sendo idealizadas, onde seus alicerces estão centrados nas milhares de siglas que compõe o universo SOA. Porém, releases são anunciadas mas nunca cumpridas. E isso serve de alerta para todos nós, na aquisição e utilização imediata do que estão vendendo. Pois nem eles (os deuses que referencio) estão conseguindo ter sucesso fácil com essas tecnologias.

Mas de todo esses esforço, algumas idéias, maneiras de pensar e comportamentos ficam. Contribuindo muito na nossa evolução.

Porém, devemos ter cuidado ao ver uma tendência e já sair implementando em um projeto real. E, isso na minha visão, é um dos principais motivos do porque muitas iniciativas, não somente em SOA, não obtiveram o sucesso esperado.

Lembrem-se: Se você ver em algum evento ou consultor visitando sua empresa falando de algo muito inovador, praticamente te colocando em situação desconfortante de que se você não usar aquilo, você não estará sendo uma pessoa moderna e estilosa. Isso é uma cilada. Saiba que, o cenário atual da TI e não apenas o seu, ainda não está preparado para aquilo. Nem mesmo os próprios fornecedores estão. Portanto, não coloque sua cabeça a prêmio tão facilmente.

No próximo post, eu estarei falando de um elemento essêncial, e que não está sendo levando em consideração na adoção SOA, e que está fazendo com que muitos projetos fracassem: "A tal da Governança".

RUP e Scrum de mãos dadas

Já escutei e li muitas coisas sobre RUP (Rational Unified Process) e Scrum. Principalmente no sentido em que um é melhor que outro, em algum aspecto.

Esta comparação, ao meu ver, pode ser extremamente pertinente ou completamente incoerênte, dependendo do que irá ser abordado. Vou procurar me explicar.

O RUP, em resumo, representa um framework de melhores práticas para orientar a criação, ou adaptação de processos de engenharia de sofware. Ou seja, como o próprio RUP prega em seu primeiro dos seis princípios, o Adapt the Process, você deve ser capaz de identificar as áreas em que a cobertura na estrutura do processo RUP é considerada insuficiente para o seu projeto e balancear os níveis de cerimônia, precisão e controle, de acordo com uma variedade de fatores, incluindo o tamanho e a distribuição de equipes, a quantidade de restrições externamente impostas e a fase na qual o projeto se encontra.

E é justamente na questão de controle que eu vejo que o Scrum pode apoiar, e muito, já que ele não é um processo de engenharia de software, mas sim, um framework empírico de Gerenciamento de Projetos que busca prover maior visibilidade sobre os sucessos, insucessos, impedimentos, comprometimentos das equipe e satistação do cliente ao longo do projeto.

Portanto, fica claro que apesar de Scrum ter algumas práticas que auxiliariam em diversas disciplinas do RUP, a disciplina que ele poderia, em um primeiro momento ser mais utilizado, é na disciplina de Gerência de Projeto, como forma de se ter maior controle e visibilidade de como o projeto está andando (reuniões, quadro kanban); Priorizar de requisitos e planejar as iterações de forma a produzir entregáveis com maior valor (ROI) para o cliente; Possibilitar a criação de uma equipe auto-gerenciada, facilitando ainda mais o trabalho do Gerente de Projeto; Obter estimativas mais realistas com práticas como o plannig poker.

Podemos perceber inclusive que muitas das práticas que o Scrum prega, já fazem parte dos princípios do RUP, tais como: Balance Competing Stakeholders Priorities, Demonstrate Value Iteratively e Focus Continuously on Quality.

Da mesma forma que já vi muitos projeto que disseram ter usado RUP falharem, principalmente pelo não entendimento de seus princípios e por tentar utilizar tudo, eu estou vendo muitos projetos que dizem usar o Scrum falharem ou indo para o mesmo caminho de fracasso, pois acreditam que Scrum é um processo de engenharia, que terá respostas para tudo, e não é verdade.

Devemos sempre lembrar que o próprio Manisfesto Ágil informa que por exemplo “Indivíduos e interações são mais importantes que processos e ferramentas”, mas não que devemos descartar os processos e ferramentas.

Com isso, o RUP sendo uma estrutura de processo adequada para uma grande variedade de tipos de projetos, podemos com toda certeza, obter nele alguma boas práticas em nossos processos ágeis que utilizam o Scrum como gerenciamento.

Em suma, com as poucas características ditas acima sobre o RUP e Scrum, vejo claramente que ambos possam ser usados em conjunto, como forma de si complementarem. Então, vamos usar os dois o máximo que possível e contruir projetos com qualidade.

Bons processos e projetos. ;D