Já tem algum tempo que estou para publicar esta informação, que pode ajudar muita gente a resolver uma encrenca quando se precisa efetuar um processamento de uma quantidade “ignorante” de dados e o Flash Player Runtime não ajuda…

Em um projeto me deparei com este “inconveniente”, onde estava lá a aplicação executando o processamento a todo vapor, passado 15 segundo uma mensagem me aparece questionando se eu deixo ou não o processamento continuar… Mas como assim?!

Então fui a pesquisa, verifiquei que devido a regras de segurança e respectivas políticas da Runtime para proteger os navegantes pela Web a fora, de algum engraçadinho fazer um código pesado que trave o web browser do pobre cidadão, ou mesmo vire um vortex de consumo de processamento.

Infelizmente não achei a referência que havia lido na época que me levaram as respectivas informações:

1 – o tempo padrão de processamento contínuo de um algoritmo executado pelo Flash Player Runtime é de 15 segundos.

2 – existe a possibilita de estender esse tempo até 60 segundos, porém no meu caso não iria em alguns cenários ser o suficiente para processar a quantidade sem noção de dados que o usuário quer executar.

Foi ai que os meus estudos e interesse por desenvolvimento de games no Flash me salvaram a pele…

No Flex é possível criar uma classe que herde de Sprite, que nada mais é que um “filme”, onde nesse filme eu sei que existem quadros, e que nesses quadros eu poderia fragmentar meu processamento da quantidade sem noção de dados. E foi exatamente isto que eu fiz.

Para entender a minha linha de raciocíneo observe a imagem a seguir:

Sei que no Flex é possível fazer miséria com registro e tratamento de eventos, para a minha e possivelmente a sua alegria também, existe um evento nessa classe que trata o evento de quando entra em um novo quadro renderizado: Event.ENTER_FRAME, e foi exatamente ali que resolvi o problema, fragmentando meu processamento em blocos dentro de cada quadro que será executado.

Legal já te contei a solução, agora para te ajudar um pouco mais, fiz um exemplo de projeto implementando essa idéia, segue:

Download: LongProcessing.zip

SVN: http://erkobridee.googlecode.com/svn/trunk/adobe_flex/LongProcessing

O código pode ser visualizado nesse [link]

Tela que indica o processamento dos blocos:

Eis a classe que faz a mágica: ExportHTMLHelper nesta classe escrevi comentários importantes que devem ser considerados na hora de implementar o seu respectivo código de processamento.

Tela após o termino do processamento, possibilitando salvar o resultado:

Para essa aplicação fiz um export para um HTML simples apenas para exemplificar.

Bom espero que esse exemplo lhe seja útil.

Um outro projeto da faculdade (2005), posso dizer que este foi o que eu mais gostei de trabalhar, foi 1 ano inteiro trabalhando nesse projeto e os respectivos filtros de processamento para imagem, resultado final ficou legal, neste post estou disponibilizando o fonte do projeto e demais informações…

Na imagem a seguir pode ser visto todos os filtros implementados pela aplicação

Atenção: os filtros e informações técnicas dos algoritmos implementados estão documentados no help da aplicação que está junto ao projeto.

Download: PID

SVN: http://erkobridee.googlecode.com/svn/trunk/java/ProcessamentoImagemDigital/

As classes podem ser visualizadas nesse [link]

Resolvi ressuscitar um projeto de 2005 que fiz durante a faculdade e sempre achei legal, uma calculadora léxica que analisa uma equação matemática informada e executa o cálculo…

O funcionamento dessa calculadora é descrito na imagem a seguir:

A calculadora executa uma verificação/avaliação da expressão informada e com base nessa executa seu respectivo processamento, apresentando o resultado da equação.

Algo interessante desse projeto é a possibilidade de visualizar a avaliação da equação que foi utilizado para então executar o processamento do cálculo, que pode ser visualizado através do ícone da lupa na imagem acima.

Download: Calculadora Lexica

SVN: http://erkobridee.googlecode.com/svn/trunk/java/CalculadoraLexica

As classes podem ser visualizadas a partir desse [link]

Aplicação em Adobe AIR para explorar e visualizar arquivos através de um aplicativo em Adobe AIR que possibilita ver/executar alguns tipos e para os demais não reconhecidos tenta abrir no aplicativo padrão do sistema operacional…

Download: LocalFileExplorer

Códigos:

LocalFileExplorer.mxml

LocalFileExplorerCode.as

custom.SmoothVideoDisplay.as

VideoPlayer customizado para habilitar o smooth na imagem (sinceramente não sei porque o componente VideoPlayer já não vem com essa opção de ativação…)

O modo fullscreen funciona mas não está do jeito que eu quero ainda com background preto… está branco e isto irrita, pelo menos aos meus olhos quando estou vendo um vídeo em fullscreen.

org.flashcommander.components.Mp3Player.as

Componente para execução de arquivos mp3

SVN:

http://erkobridee.googlecode.com/svn/trunk/file_explorer/standalone/LocalFileExplorer/

Mais informações:

Como foi comentado os arquivos de audio .mp3 possui um componente interno para execução, para os demais arquivos de audio a aplicação utilizará o recurso para abrir na aplicação padrão vinculado ao arquivo no sistema operacional.

Para os respectivos arquivos de vídeo .mov .mp4 .flv foi definido um componente que extende ao VideoPlayer que possibilita setar a suavização do vídeo, em outras palavras, reduzir aqueles “quadrados” na imagem do vídeo durante a execução quando esta está com um tamanho diferente da resolução inicial.

Para os respectivos arquivos .gif .png .jpg .pdf .txt .htm .html irá abrir utilizando o componente HTML do Adobe AIR.

Observação: conforme já comentado, porém apenas para relembrar, para todos os demais arquivos que não estão previstos para estes 3 visualizadores de arquivos da aplicação, a aplicação tentará abrir o respectivo arquivo usando o recurso do Adobe AIR 2.0 de abrir com a aplicação padrão setada no sistema operacional.

ps.: Esta aplicação pode ser utilizada como base para muitas possíveis aplicações que necessitem listagem e visualização/execução de arquivos no computador local ou em algum computador acessível via rede através de um nome (não testei através de IP ainda, se alguém testar poderia me informar se funciona? grato)

Aplicação em Adobe AIR para explorar e visualizar arquivos através de um aplicativo em Adobe AIR que possibilita ver/executar alguns tipos e para os demais não reconhecidos tenta abrir no aplicativo padrão do sistema operacional…

Download: LocalFileExplorer

Códigos:

LocalFileExplorer.mxml

LocalFileExplorerCode.as

custom.SmoothVideoDisplay.as

VideoPlayer customizado para habilitar o smooth na imagem (sinceramente não sei porque o componente VideoPlayer já não vem com essa opção de ativação…)

O modo fullscreen funciona mas não está do jeito que eu quero ainda com background preto… está branco e isto irrita, pelo menos aos meus olhos quando estou vendo um vídeo em fullscreen.

org.flashcommander.components.Mp3Player.as

Componente para execução de arquivos mp3

SVN:

http://erkobridee.googlecode.com/svn/trunk/file_explorer/standalone/LocalFileExplorer/

Mais informações:

Como foi comentado os arquivos de audio .mp3 possui um componente interno para execução, para os demais arquivos de audio a aplicação utilizará o recurso para abrir na aplicação padrão vinculado ao arquivo no sistema operacional.

Para os respectivos arquivos de vídeo .mov .mp4 .flv foi definido um componente que extende ao VideoPlayer que possibilita setar a suavização do vídeo, em outras palavras, reduzir aqueles “quadrados” na imagem do vídeo durante a execução quando esta está com um tamanho diferente da resolução inicial.

Para os respectivos arquivos .gif .png .jpg .pdf .txt .htm .html irá abrir utilizando o componente HTML do Adobe AIR.

Observação: conforme já comentado, porém apenas para relembrar, para todos os demais arquivos que não estão previstos para estes 3 visualizadores de arquivos da aplicação, a aplicação tentará abrir o respectivo arquivo usando o recurso do Adobe AIR 2.0 de abrir com a aplicação padrão setada no sistema operacional.

ps.: Esta aplicação pode ser utilizada como base para muitas possíveis aplicações que necessitem listagem e visualização/execução de arquivos no computador local ou em algum computador acessível via rede através de um nome (não testei através de IP ainda, se alguém testar poderia me informar se funciona? grato)

Segue um exemplo básico de aplicação de como localizar um determinado tipo de arquivo no computador. Este respectivo código pode ser evoluído e reaproveitado em algum aplicativo que precise ler conteúdo de um determinado diretório do computador.

Obs.: Essa aplicação foi baseada e adaptada do disponibilizado nesse link.

Ver código:

- FileSearch.mxml

- FileSearchCode.as

Download: FileSearch

SVN: http://erkobridee.googlecode.com/svn/trunk/adobe_air/FileSearch/

Para facilitar, normalmente se cria a classe AS com mesmo nome e no mesmo pacote da sua correspondente java. Para usar remoteobject as classes AS e Java precisam ter um método construtor sem parâmetros e os atributos precisam ter o mesmo nome e precisam ser públicos ou com métodos get / set públicos.

Numa aplicação uma classe AS estava num pacote diferente da sua correspondente Java. Quando acesso um método remoto que retorna um objeto desta classe do Java para o Flex vem tipada corretamente, mas quanto tento enviar de Flex para Java dá um fault onde faultCode = Client.Message.Encoding e faultString = Cannot create class of type ‘packageAS.classeAS’.

Este erro me chamou a atenção porque sempre imaginei que era só usar o atributo alias de RemoteClass [RemoteClass(alias="pacoteServer.classeServer")] apontando para a classe sever corretamente que iria funcionar, mas no fim o pacote e nome da classe precisam ser iguais.

Procurando na documentação algo que explicasse este fato não encontrei nada, mas achei algo interessante: “In the ActionScript class, you use the [RemoteClass(alias=" ")] metadata tag to create an ActionScript object that maps directly to the Java object.” Isto é, usar alias com um espaço em branco vincula com sua classe server com mesmo pacote e mesmo nome de classe.

Foi disponibilizado ontem(03/08/2010) a nova versão da Lib Flerry, com um suporte melhorado para o uso do java e respectivos jars da aplicação java

Segue as novidades e mudanças no Flerry 1.2.0:

• O processo de localização do Java foi completamente reescrito. Agora este processo olha no local retornado pelo sistema operacional:
  • Windows – c:windowsSystem32javaw.exe (que  a partir da versão 6 se tornou o local padrão de localização do Java) [ uma observação aqui, se sua versão do Windows for NT, provável que a localização seja: c:windowsntSystem32javaw.exe ]
  • Mac – /usr/bin/java se não estiver aqui, então verifica no local  /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/java
  • Linux – /usr/bin/java se não estiver aqui, então verifica no local /etc/alternatives/java
  • Caso não encontre nos locais predefinidos, o mecanismos de localização do Java então irá procurar: No Windows, utilizará o acesso via NativeProcess ao FindJava.exe para verificar nos registro do Windows a localização do Java. Este mecanismo foi uma contribuição do Serge Jespers, onde ele usa esta funcionalidade na aplicação Package Assistant Pro. No Mac e Linux será acessado o comando nativo /usr/Bin/whereis Java para descobrir onde o Java está instalado.
• O local padrão para se disponibilizar os arquivos jar foi renomeado, agora deve-se crier o diretório /libs dentro do projeto Adobe AIR /src. Atualmente este diretório não conterá apenas jars, também deverá ser disponibilizado neste diretório o FindJava.exe. Porém o diretório das libs pode ser customizado através da propriedade libsDirectory da classe NativeObject.
• Todos os jars dentro da pasta libsDirectory serão adicionadas automaticamente ao classpath de execução da aplicação Java. A especificação manual de cada jar do diretório não é mais necessária.
• O código compilado Java pode ser disponibilizado na pasta classes. Não é mais obrigatório o empacotamento em um jar. Isto irá possibilitar o teste e debug da aplicação de modo muito mais fácil.
• Suporte “fora da caixa” (facilitado) para debug do código Java.
• Melhoramento da comunicação do AIR com o Java, agora suporta a transferência de objetos grandes. Isto através da divisão de blocos de 256 bytes.
• Adicionado um conjunto de testes do FlexUnit.
• Adicionado um script Ant build.
• Atualização dos jars de serialização AMF para o BlazeDS 4.0.
• Removida a referência entre os projetos flerru e flerry-demo. Agora o projeto flerry-demo é um projeto separado que referencia a lib flerry.swc.

Esta versão contou com a contribuição:

A seguir segue os vídeos sobre o Flerry…

Estou disponibilizando um exemplo de como integrar de maneira simples e efetuar uma comunicação textual entre um aplicativo Adobe AIR 2 com uma aplicação Java…

Lembrete: para pode utilizar o recurso NaticeProcess é necessário efetuar uma configuração no xml que define as informações de execução da aplicação, você precisará definir a tag: <supportedProfiles>extendedDesktop</supportedProfiles> conforme pode ser visto [SimpleAirJava-app.xml]

Atualizado: 20100725 2300

Incluído campo para definir o caminho do javaw no computador local

Download: SimpleAirJava.zip

SVN: ( Google Code, acesso para leitura)

http://erkobridee.googlecode.com/svn/trunk/adobe_air/nativeprocess/Java/SimpleAirJava

Para facilitar uma visualização rápida dos código, segue os links:

SimpleAirJava_UI [ aplicação Adobe AIR ] ( UI – User Interface )

SimpleAirJava.mxml

App.as

SimpleAirJava-app.xml

SimpleAirJava_NP [ aplicação Java ] ( NP – NativeProcess )

RunApp.java

Espero que ajude a compreender um pouco como integrar AIR + Java localmente.

Obs.: ainda existe a obrigatoriedade de gerar um instalador nativo para poder distribuir e utilizar o NativeProcess na aplicação instalada.