DClick

Sistema Offline com flex e java


Twitter!

Algum tempo atrás caímos num grande desafio. Desenvolver uma parte do sistema para o usuário trabalhar desconectado. Sem poder usar o Apollo, pois não estava na versão final e não era homologado pela empresa, e também sem poder instalar um servidor de aplicação na máquina do usuário. Estávamos desesperados, pois a única opção era desenvolver toda a parte do front novamente só que em AWT ou Swing. Agora imagina ter que desenvolver algo parecido com que o flex e capaz de fazer. Eu nem sabia por onde começar, pois nenhum usuário acostumado a usar o flex gostaria de usar uma tela feita nessas tecnologias, pois seria voltar ao passado.

Então num dia inspirado, veio a idéia: se o flex acessa JavaScript e o JavaScript acessa Applet e o Applet não precisa de servidor (executa só com o browser e o plugin do java). Porque não tentamos utilizar isso. Parecia loucura, mas foi isso que foi feito...

Como ficou dividido o sistema:

Arquitetura do Offline

  • Flex – Camada de apresentação que possui apenas os módulos disponibilizados no Offline.
  • Javascript – Responsável pela comunicação entre o Flex (swf) e o Applet (jar). Ele é apenas um redirecionador das requisições Flex para o Applet.
  • Applet – Classe Java que o browser consegue executar. Responsável por receber as chamadas do Javascript e direcionar para a regra de negócio no Back-End Local.
  • Back-End Local – Possui a regra de negócio no qual os módulos disponibilizados no Offline irão utilizar.

Exemplo para somar dois números:

Parte flex:

Actionscript:
  1. <?xml version="1.0" encoding="utf-8"?>
  2. <mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute">
  3.     <mx:Script>
  4.         <![CDATA[
  5.             import mx.controls.Alert;
  6.             public function call():void
  7.             {
  8.                 var result:Object = ExternalInterface.call("calljs", valor1.text,valor2.text);
  9.                 Alert.show(result.toString());
  10.             }
  11.         ]]>
  12.     </mx:Script>
  13.     <mx:Button click="call()" label="Chamar Back End" x="126" y="52"/>    
  14.     <mx:TextInput id="valor1" x="92" y="10" width="57"/>
  15.     <mx:TextInput id="valor2" x="217.5" y="10" width="63"/>
  16.    
  17. </mx:Application>

Acrescentar no index.template.html :

CODE:
  1. <script language="JavaScript">
  2.     function calljs(valor1,valor2)
  3.     {
  4.         ret = document.javaOffline.calcular(valor1,valor2);
  5.         return ret;
  6.     }
  7. </script>
  8.  
  9. <APPLET CODE="br.com.dclick.JavaOffline" WIDTH=1 HEIGHT=1 name="javaOffline">
  10. </APPLET>

Parte java:

JAVA:
  1. package br.com.dclick;
  2.  
  3. import java.applet.Applet;
  4.  
  5. public class JavaOffline extends Applet{
  6.    
  7.     public String calcular(String valor1,String valor2){
  8.         int v1 = 0;
  9.         try{
  10.             v1 = Integer.parseInt(valor1);
  11.         }catch (Exception e) {
  12.             return "Valor " + valor1 + "inválido ";
  13.         }
  14.  
  15.         int v2 = 0;
  16.         try{
  17.             v2 = Integer.parseInt(valor2);
  18.         }catch (Exception e) {
  19.             return "Valor " + valor2 + "inválido ";
  20.         }
  21.        
  22.         return "" + Util.somar(v1, v2);
  23.        
  24.     }
  25.  
  26. }

JAVA:
  1. package br.com.dclick;
  2.  
  3. public class Util {
  4.     public static int somar(int valor1, int valor2){
  5.         return valor1 + valor2;
  6.     }
  7. }

Compartilhe:

  • RSS
  • Twitter
  • del.icio.us
  • Facebook
  • MySpace
  • LinkedIn
  • Google Bookmarks
Por Leonardo Cabral em 20/February/2008 | Comentar | Trackback


No Translations

27 comentários para “Sistema Offline com flex e java”


nossa q gambi!


Pra quem achar que é gambi, pesquisando achei outro blog explicando como resolver uma demanda da mesma maneira que o Leonardo postou.
http://tobiaspatton.wordpress.com/2007/08/29/using-a-signed-java-applet-as-a-flex-helper-part-1/


Quando a “Gambi” é a unica saída dado um determinado contexto não acho justo utilizarmos esta palavra cuja conotação negativa passa a idéia de uma má solução. ”. Se lermos com atenção o post do Leonardo veremos que ele tinha uma serie de variáveis a levar em consideração enquanto tentava encontrar uma solução para o seu problema. E ele encontrou. Portanto, usar a palavra “Gambi” para designar a solução do Leonardo é no mínimo um julgamento precipitado.


só citando o Tobias:
“Keep in mind that I’m not a Java programmer. Nor am I a JavaScript programmer. I’m probably making all sorts of mistakes that will induce a lot of eye rolling.”


Olá,

Isso é um tanto interessante não chamaria de gambiarra, mais artifício computacional.

Mas… Uma dúvida,
Claro que vocês não usaram o Applet somente para fazer contas. O que realmente era executado no cliente? vocês colocaram um banco e etc?

Abraços!
\o/


Rodrigo,

Eu não vi o que o pessoal fez, mas definitivamente não foi só para fazer contas. O Leonardo deve ter dado este exemplo por questões de simplicidade – o que eu acho que ajuda bastante.

[]’s


Deixo aqui registrado que a solução colocada acima não é a melhor solução para trabalhar flex com java, pois se fosse, a adobe já teria implementado ela em uma das suas soluções, mas dentro da realidade de já ter toda a parte front e toda parte back implementada, seria muito trabalhoso ter que desenvolver toda a parte de front novamente. Portanto resolvemos fazer essa “gambi” para aproveitar tudo que foi desenvolvido, necessitando desenvolver apenas um conector que fica no flex e outro no back-end que é responsável por serializar e deserializar os objetos que trafegam entre o front e o back. Resumindo: Essa solução foi pensada e implementada em menos de um mês usando apenas um programador. Se existir um programador que sozinho desenvolva TODA a parte do front em Swing ou AWT em menos tempo, eu gostaria de conhecer… (E olha que não precisa ficar cheio de efeito que nem é no flex)


Rodrigo,
Na verdade o que foi postado foi apenas um exemplo para mostrar que funciona…
No sistema real o applet é apenas um connector, onde ele recebe a requisição do flex e deserializa os objetos que foi serializado pelo flex (os valores não chegam assim, um por um, vem tudo serializado e lá existe uma rotina genérica que os deserializam) e depois de deserializar ele usa toda a parte que já estava feita do back-end, incluído o acesso ao banco de dados, e tb tivemos que implementar uma nova funcionalidade que era de sincronizar os dados do sistema offline com o sistema online (ou seja ele também chega a fazer conexão http com um outro sistema), mas para postar o sistema todo aqui acho que eu ficaria um pouco extenso, então tentei exemplificar para passar a idéia…


Olá Senhores,
Eu entendi o que foi imposto aqui, eu apenas peguntei por curiosidade mesmo.

Quero dar os parabéns ao pessoal da DClick pois a solução atende muito bem! em um ambiente onde minhas possibilidades técnicas são restringidas, a solução é atraente.

Abraços.
\o/


Parabéns Leonardo,

Você conseguiu fazer a mesma aplicação Flex/Java online trabalhar offline (local), fazendo o trabalho do Apollo sem acessar a API do Apollo e sem usar um servidor de aplicação web.

Num é à toa que vc é conhecido como Mestre Java.
valeu.


[...] Eu não gosto de escrever assuntos relacionados a isso. Isso já aconteceu comigo e acaba de acontecer com Leonardo Cabral bem aqui. [...]


[...] Fonte: Igor Costa. [...]


Todo mundo sabe que isso não é a forma mais correta de se resolver esse tipo de situação, mais como o Leonardo disse, o tempo não permitia fazer uma implementação em Swing, que seria a forma correta.

Em um EAD tive que fazer exatamente a mesma coisa, mais no meu caso não tinha como fazer interface em Swing. Mais enfim, não é a solução mais elegante.

Só um pequeno comentário sobre RIA. As vezes só pensamos em encher os olhos do cliente com um monte de “frescurinhas” que aplicações em Flash Player são capazes de fazer e esquecemos de resolver os verdadeiros problemas do cliente.

Falo isso porque o Leonardo disse isso lá no primeiro paragráfo: “a única opção era desenvolver toda a parte do front novamente só que em AWT ou Swing”. E este não foi implementado pela questão da parte visual do Flex que com certeza era mais rica.

Mais tá ótimo, o problema foi resolvido, só não acostume a fazer isso =)


Jan,
Você só esqueceu que essas “frescurinhas” (aspas propositais) aliados de uma boa usabilidade são responsáveis pelas resoluções de problemas do cliente.


Leonardo, não seria possivel fazer a ligacao direto do front em flex com o back end?


calma gente .. o “nossa q gambi” não foi tão depreciativo assim…
desculpe se atingi o ego de alguém, foi mal … Igor ;)

quem nunca fez uma gambi ou “artifício técnico” (chamem como queiram),
que atire a primeira pedra. quem não tem cão caça com gato, é isso aí!

parabéns pela gambi !! ;) se atende tua necessidade ótimo!


Acho que algumas pessoas não entenderam muito bem o motivo deste post…

Este post não foi publicado aqui para se discutir se esta solução é a mais elegante.

Não podemos afirmar qual a melhor solução para um problema que não sabemos sua amplitude e nem temos ciência de todos os fatores relevantes do mesmo, como prazo, custo, equipe, tecnologias envolvidas…
Não podemos pensar que todos os projetos de sistemas são como aqueles q fazemos em casa, pra controlar nossa listinha de mp3, onde usamos tudo que queremos usar.

O que esta sendo mostrado aqui é a possíbilidade de se trabalhar FLEX e JAVA offline, sem servidor e sem AIR (apollo).
Se alguem tiver outra solução para se usar o FLEX com o Java offline, ai sim, será legal discutirmos como ela foi feita, qual a melhor maneira de se usar as 2 soluções e etc…


Po, se a Gambiarra funcionou, beleza !!!!!!

nao ha mau algum se isso é uma gambi hehehe


Andrey,
O que vc quer dizer com ligação direta???
– Sem passar pelo método calljs no html??? Pode! Mas não deixa de está utilizando a tecnologia JavaScript.
– Sem usar o Applet??? Acho que não, pois para rodar os .class precisa de uma jvm.


Alguém testando ou quem sabe aproveitando a idéia em um outro projeto :) , poderá ter problema com o Sandbox, tanto no java, como no flex. Para tentar resolver esses problemas:
Flex – http://blog.dclick.com.br/2008/02/20/sistema-offline-com-flex-e-java-continuacao/
Java – http://blog.dclick.com.br/2008/02/21/politica-de-seguranca-no-java-arquivo-policy/


Chegue a conclusão que chegarmos o pessoal parece gostar mesmo é de uma polêmica. Eu até brinquei outro dia dizendo que eu iria escrever um post polêmico por mês para agitar um pouco as coisas. Eu não acho que seria exagero dizer que, como na TV, basta ter um “briguinha” em algum lugar para chamar a atenção das pessoas. Acho que se criássemos uma tag “Post Polêmico” esta seria uma das mais visitadas. Freud explica? Darwin talvez? Eu não ouso. But no problem. We are all having fun! :-)


Pense que é muito massa essa “gambi”…

Tinha uma dessas feita pela Microsoft, nos promórdios do AJAX, acho que era Remote Scripting…Era bem assim mesmo…Um applet no meio…Era para outro fim mas tinha…rsrsrs

Brincadeiras a parte, parabéns.

Forte abraços das terras alencarinas !!!


Leonardo,

Sua solução está longe de ter sido gambi. Ela foi genial.


Bem, boa solução.
Porém não vejo como fazer a comunicação inversa (applet > flex) a que está sendo proposta acima (flex > applet).
Caso alguém saiba, ficaria grato na solução. ;)

[]’s


Gostei da solução e gostaria de utiliza-la tambem. Mas talvez voce deve ter passado pelo mesmo problema que eu, na comunicação do javascript com o applet, estou com problemas de segurança, vc saberia como retirar as permissoes de segurança do applet?


Seria desnecessario usar applet e javascript para rodar uma aplicação Flex offline.
Quanto mais tecnologias usamos em nossas aplicações, muito mais recursos de hardware serão exigidos.
Portanto, seria melhor usar o Flex com alguma outra tecnologia, de preferencia C ou C++, devido ao ganho de performance.
Atualmente eu uso Flex localmente e C++ no servidor. Antes eu usava o PHP em conjunto com o Flex. Depois que troquei o script PHP por um programa C++ compilado rodando em CGI, o ganho em desempenho foi assustadoramente superior ao PHP.
Por isso não recomendo ficar aí tentando inventar moda, ou fazendo gambiarras com outras linguagens scripts, porque é lá na frente que o preju aparece.
Em breve vou fazer algumas experiencias com Flex e C++ offline. Talvez eu publique o fonte quando estiver pronto, mais por enquanto não vou fazer isso.
Mais do jeito que a Adobe vem investindo no Flex, logo não iremos mais precisar de uma tecnologia auxiliar, pois o Flex ira dar suporte offline, online, além dos diversos sistemas operacionais que existem por aí…
Aproveitem para pesquisar sobre o projeto da Adobe chamado “Alchemy” que tem como objetivo oferecer suporte ao C/C++ no Flex.
http://labs.adobe.com/technologies/alchemy/
Bom, o conhecimento nunca é demais…
Fiquem com Deus!


_Seria desnecessario usar applet e javascript para rodar uma aplicação Flex offline.
Quanto mais tecnologias usamos em nossas aplicações, muito mais recursos de hardware serão exigidos.
Portanto, seria melhor usar o Flex com alguma outra tecnologia, de preferencia C ou C++, devido ao ganho de performance.
Atualmente eu uso Flex localmente e C++ no servidor. Antes eu usava o PHP em conjunto com o Flex. Depois que troquei o script PHP por um programa C++ compilado rodando em CGI, o ganho em desempenho foi assustadoramente superior ao PHP.
Por isso não recomendo ficar aí tentando inventar moda, ou fazendo gambiarras com outras linguagens scripts, porque é lá na frente que o preju aparece.
Em breve vou fazer algumas experiencias com Flex e C++ offline. Talvez eu publique o fonte quando estiver pronto, mais por enquanto não vou fazer isso.
Mais do jeito que a Adobe vem investindo no Flex, logo não iremos mais precisar de uma tecnologia auxiliar, pois o Flex ira dar suporte offline, online, além dos diversos sistemas operacionais que existem por aí…
Aproveitem para pesquisar sobre o projeto da Adobe chamado “Alchemy” que tem como objetivo oferecer suporte ao C/C++ no Flex.
http://labs.adobe.com/technologies/alchemy/
Bom, o conhecimento nunca é demais…
Fiquem com Deus!

Adicionar comentário

(requerido)
(requerido, não será publicado)