Este post nasceu de um e-mail que respondi a um amigo e acredito que esta possa ser uma dúvida de muitas pessoas, então vamos lá:
A integração Flex + .NET é muito tranquila e você tem várias maneiras de fazer isso:
1) A mais simples delas é via arquivo de texto, utilizando desde simples .TXT até arquivos XML.
Você pode, por exemplo, construir uma página ASPX que ao ser chamada cria um XML dinâmico e você pode fazer essa chamada do Flex. Trabalhar com XML no Flex é uma coisa muito divertida com E4X. Palavras chave para o Flex: HTTPServicee URLLoader
2) Utilizando WebServices. Criar WebServices no .NET é uma tarefa muita tranquila de ser feita. Por ser um padrão bem difundido para integração de aplicativos, ele está presente também no Flex. Utilizá-los no Flex também é uma tarefa bem tranquila, dê uma olhada aqui para saber como fazer.
3) Uma forma mais especializada de fazer a comunicação é utilizando um protocolo criado pela Adobe pra comunicação do flashplayer com qualquer linguagem, tipo um webservice, só que bem mais elaborado (lembra bem o WCF). Esse protocolo se chama AMF, existem algumas bibliotecas para .NET como o FluorineFx e WebORB. Eu recomendo dar uma olhada no FluorineFx. Ultimamente todos os projetos que tenho atuado que contam com integração Flex + .NET tenho usado o Fluorine e estou muito satisfeito com ele. Palavras chave para o Flex: RemoteObject
4) Se nada disso atender à sua demanda (duvido muito) você pode partir para uma comunicação mais “baixo nível” apelando para Sockets. Para jogos, por exemplo, que se comunicam com servidores já existentes feito em Java ou C++ é comum a utilização de Sockets. Apesar de ser uma tarefa não tão trivial de ser feita, pois o ideal é ter um certo conhecimento de rede que ajuda muito a entender como funciona essa comunicação, é muito interessante a forma como o Flex (AS3) trabalha com Sockets, vale a pena dar uma olhada.
Recomendo muito que você dê uma olhada nas alternativas 1 e 3 primeiro. 1 para uma comunicação mais simplificada e 3para algo mais bem elaborado.
Para se ter uma idéia, utilizando a técnica 3, você consegue passar objetos criados por no .NET diretamente para o Flex (obviamente você deverá ter uma classe no Flex com a mesma estrutura criada no .NET).
Você pode estar se perguntando, poxa, mas e por que não utilizar WebServices? Se você tiver que desenvolver o WebService, dê a preferência para o AMF, pois a comunicação é muito mais rápida e você ainda tem a facilidade de passar objetos mais complexos, diferente do WebService que a princípio só dá pra passar tipos mais primitivos. Mas se já tiver os WebServices e for só integrar, de boa, não vamos reinventar a roda, né?
Primeiramente feliz Ano Novo. Que este ano seja repleto de realizações a todos.
Hoje vou falar um pouco de duas tecnologias interessantes para desenvolvimento para dispositivos móveis. Fiz um resumo sobre o que andei pesquisando sobre elas:
Hoje uma das tecnologias mais difundidas para desenvolvimento no mundo móvel é o Java Micro Edition, ou Java ME. Praticamente todos os celulares da nova geração já vêm com suporte a esta tecnologia por padrão.
Uma outra ferramenta que tem mostrado um futuro promissor é o Flash Lite, a versão ‘mobile’ do já difundido e aceito Flash Player, presente em cerca de 94% dos computadores atualmente. Vem crescendo cada dia mais e alcançando gradativamente uma parcela cada vez maior dos dispositivos móveis.
Abaixo segue uma tabela mostrando a penetração do Flash Lite:
Penetração Flash Lite (Fonte: Strategy Analytics )
Vamos observar as características de cada tecnologia separadamente:
· Java ME
Foi desenvolvido para dispositivos com recursos limitados e de tela pequena que não tem suporte a animações ou interface gráficas sofisticadas.
Muitas funcionalidades foram adicionadas ao J2ME nos últimos anos, bem como existem novas tecnologias disponíveis nos dispositivos, como GPS. Isto permitiu a criação de aplicativos sofisticados como Google Gmail Client ou o browser Opera mini.
Prós:
- Inclui uma parte da linguagem e bibliotecas padrão do Java;
- Recursos fáceis de usar para tarefas comuns, como comunicação http ou enviar e receber SMS;
- Pequena curva de aprendizado para desenvolvedores Java;
- Grande base de instalação para todos os ambientes de celulares.
Contras:
- É necessário um grande esforço para criar interfaces e animações sofisticadas;
- Nem todas as funcionalidades dos dispositivos estão disponíveis e os processos JSR, que introduzem novos padrões de funcionalidades, está atrasado em relação à disponibilidade de funcionalidades nativas;
- Elevado grau de fragmentação devido às variações entre os fabricantes de dispositivos e operadoras.
· Flash Lite
Como mencionado anteriormente é uma espécie de flash player, que roda nos browsers comuns, para celulares e outros dispositivos móveis. Também foi projetado especificamente para dispositivos móveis, não sendo tão poderoso quanto o flash player para os browsers em desktop, devido às limitações dos dispositivos portáteis. Uma lista completa dos dispositivos suportados pode ser encontrada em:http://www.adobe.com/mobile/supported_devices/
Prós:
- Plataforma ideal para a criação de conteúdo animado;
- Fácil para se criar aplicativos portáveis;
- É muito fácil de usar para desenvolvedores que já trabalham com Flash.
Contras:
- Tem restrições de acesso à conexões de rede e a alguns recursos locais do celular
- Um aplicativo flash não pode ser instalado no celular como um aplicativo nativo (standalone).
· Java + Flash Lite (unindo o útil ao agradável)
O Flash Lite pode ser usado para a construção de interfaces animadas como uma grande redução de esforço de desenvolvimento quando comparado ao mesmo feito em Java.
Java e Flash Lite podem comunicar entre si através do sistema de arquivos do celular ou usando um pequeno em C++ (já existe tal servidor, basta apenas fazer uso dele).
Obs.: há algumas restrições dependendo da versão do Flash Lite instalada no celular.
Existem aplicativos como o ‘Jarpa’ que possibilita criar um aplicativo Flash com suporte à Java.
Os arquivos do Flash podem ser adicionados ao pacote de instalação Java e serão instalados juntamente com o aplicativo Java. O aplicativo instalado parecerá um único aplicativo que poderá ser iniciado através do menu do celular.
A combinação das duas tecnologias possibilita a utilização do ‘melhor dos dois mundos’, uma vez que se pode contar com a facilidade do flash para se construir uma interface mais sofisticada aliada ao poder do Java de interagir mais facilmente com os recursos do celular.
Há algum tempo venho me aventurando no ASP.NET e, por consequência, no Visual Studio. Muito bacana, diga-se de passagem. A facilidade de desenvolvimento é um ponto muito interessante do framework, bem como da IDE.
Mas eis que me deparo como uma situação: tenho que substituir um trecho de código por outro em vários arquivos. Para quem conhece expressões regulares, logo vê que isso pode ser feito com um mínimo de esforço, criando-se uma expressão regular simples, aí você abre um "find & replace" e voilà! Mas o danado do Visual Studio cismou de não me obedecer. - Ai, ai, ai menino feio! =P
Deixa eu falar um pouco de expressões regulares para você entender o meu drama:
Quando eu preciso localizar um texto que "casa" com um padrão e substituir parte do texto por outro, eu posso fazer de duas formas: "na unha" ou usar expressões regulares. Eu sou meio preguiçoso nesse sentido, então prefiro ER (provando que sou preguiçoso, vou usar ER daqui para frente).
Por exemplo, eu tenho as seguintes ocorrêcias, por mera ilustração:
enviaEmail("Fulano", instancia1.EmailSistema), enviaEmail("Fulano", instancia2.EmailSistema), enviaEmail("Fulano", instancia3.EmailSistema), etc.
Quero alterar toda a parte "instanciaX.EmailSistema" por outra coisa qualquer.
Então criemos a seguinte ER:
procurar por: enviaEmail\(("Fulano"), (instancia.\.EmailSistema)\)
substituir por: enviaEmail(\1, "fulano@site.com")
O parentese é usado para agrupar coisas, então o que pretendo fazer é substituir o segundo grupo "(instancia.\.EmailSistema)" por "fulano@site.com", mas manter o primeiro grupo, para isso eu uso o retrovisor \1.
Mas isso não funciona no Visual Studio. Afff!
Recorrendo à mãe do Visual Studio, eis que encontro toda uma documentação sobre expressões regulares. Se você observar, pela documentação, o agrupamento é feito usando parenteses mesmo.
Mas repare também que existe uma observação:
 Note |
| There are syntax differences between the regular expressions that can be used in Find what strings and those that are valid in .NET Framework programming. For example, in Find and Replace, the braces notation {} is used for tagged expressions. So the expression zo{1} matches all occurrences of zo followed by the tag 1, as in Alonzo1 and Gonzo1. But within the .NET Framework, the notation {} is used for quantifiers. So the expression zo{1} matches all occurrences of z followed by exactly one o, as in zone but not in zoo. |
Aí eu descobri que para procurar pelo "Find & Replace" do Visual Studio, o agrupamento, que é tratado pela MS como sendo tags, é feito usando chaves "{}" e não parenteses.
Moral da história: a Microsoft sempre tem que inventar de ser diferente. =/