Web RunTime é uma das possibilidades que a Nokiaoferece para criação de aplicativos para seus dispositivos movéis. Se você já é um desenvolvedor web, você não precisa de quase mais nada para começar a desenvolver para os dispositivos Nokia usando o WRT. Ele permite a criação de widgets para plataforma S60 sendo uma extensão do navegador Webkit permintindo que as instâncias do browser sejam executadas como se fossem aplicativos separados. E você ainda pode criar aplicativos mais ricos com o uso do Flash.

Ferramentas de desenvolvimento.
A Nokia oferece algumas ferramentas para facilitar o desenvolvimento para WRT:

• Nokia Web Developer Environment Standalone.
• Plugin para o Aptana Studio.
• Extensão para o Adobe Dreamweaver.
• Plugin para o Microsoft Visual Studio.

Também oferece UI Framework e Library como:

• Guarana WRT UI library – Uma library baseada em JQuery para o Nokia WRT feita pelo pessoal do INdT(Instituto Nokia de Tecnologia) com sede em Manaus.
• Nokia Mobile Web Templates – Um conjunto de templates otimizados para mobile e para você customizar como quiser.

E tem algumas API’s para se trabalhar com os recursos dos dispositivos movéis.

• Platform Service 2.0 – Uma API em JavaScript e ActionScript 2.0 para acessar recursos dos dispositivos movéis como acelerometro, geolocalização etc.
• API Bridge – é um componente para aparelhos Nokia com Symbian, que permite widgets WRT, conteúdo Adobe Flash Lite e aplicações Java possam acessar recursos do dispositivo através de uma arquitetura plug-in. Os desenvolvedores podem estender o componente APIBridge com os seus próprios plug-ins.

Como funciona os widgets feitos com Web RunTime? esse widgets são arquivos com extensão .wgz que nada mais é que um arquivo compactado com os arquivos de seu site. Os arquivos que não podem faltar são:

• Info.plist – arquivo responsavel pelas informações de seu widget como versão, pagina inicial, nome etc
• index.html – na verdade, pode ser qualquer nome desde que esteja setado no Info.plist como MainHTML.

Criar widgets com WRT e Flash Lite
Como você usa html para criar seus widgets com WRT, nada impede de usar o Adobe Flash na mesma maneira de como você usa normalmente atraves do html. Vamos ver um exemplo usando JavaScript para fazer a comunicação com o Flash atraves da classe ExternalInterface. Nesse exemplo utilizarei o Nokia Web Developer Environment Standalone.

• Crie um novo projeto do tipo Symbian web apps->Basic web app project. Dê um nome para seu projeto e clique em next. São gerados os arquivos basicos para seu projeto.

Daremos a opção do usuario escolher dois videos para tocar. Começaremos com o html contendo as opções de video.

E o html que carregará o swf responsavél por tocar o video:

Editaremos o arquivo basic.js para adicionar o método que mandará para o swf o video que deverá ser tocado.

No Flash, criamos um arquivo do tipo Flash Lite 3.0 ou 3.1. No painel da library, clique em na opção “new Video”. Dê o nome de instancia de “vd”. Em type deixe selecionando “Video (ActionScript-controlled) e adicione no stage. Adicionaremos o seguinte codigo para que o Flash execute o video via stream a partir do Flash Media Server:

Usamos a classe estatica ExternalInterface para que nosso método dentro do Flash possa ser chamado a partir do JavaScript. Executando o emulador do Nokia Web Developer, devemos ter algo parecido com isso:

Emulador Nokia Web Developer

Para gerar o arquivo .wgz, bastar clicar com o botão direito no projeto e pedir “Package Web app” e seu aplicativo está pronto para rodar no celular. Testei no Nokia 5230

Para saber mais:
http://www.forum.nokia.com/Develop/Web/Tools/
http://wiki.forum.nokia.com/index.php/Category:Web_Runtime_%28WRT%29
JQuery Mobile
Adobe Flash Lite

Os envolvidos com Rails já sabem que no domingo passado terminou o Rails Rumble. Uma competição onde equipes de até 4 pessoas criam aplicações
dentro de um período de de 48h.

As aplicações são julgadas nos critérios de Inovação, Aparência, Utilidade e Acabamento. E neste ano 300 equipes estão competindo nestes pontos e concorrendo a vários prêmios legais.

Neste ano eu tive o imenso prazer de participar da competição e vou contar um pouquinho como foi essa experiência.

Preparação

Montamos nossa equipe bem antes do evento, formada por: eu, João Vitor, Jeffry Degrande, Bruno Alves.

Logo que todos toparam encarar essa maratona a tarefa foi decidir o que ser feito.

Como todo a equipe está em Belo Horizonte decidimos que a melhor forma de colocar as coisas na mesa seria através de reuniões presenciais. A primeira delas foi para a decisão do tema.

Antes da reunião cada pessoa levantou uma série de idéias e no dia fomos descartando o que era complexo de mais ou que não tinha interesse. Ficamos com 3 idéias principais mas no final o que escolhemos foi a idéia do Superfolio

A idéia

Basicamente a ferramenta é uma forma de resolver a criação de site profissionais. Como assim? Toda pessoa precisa de um curriculum, no entanto eles são trabalhosos de serem feitos, ficam desatualizados e para várias profissões não significam muito (ex.: para um desenvolvedor Ruby seu github pode fazer mais diferença que seu CV).

Por outro lado todo profissional precisa de um site na internet com informações bem parecidas com a de um CV, no entanto um site abre um mar de possibilidades. Possibilidades como facilidade de atualizações, anexar imagens e principalmente links para redes que possam interessar seus contratantes e clientes (ex.: um desenvolvedor Ruby pode linkar seu Github e seu Blog). Outro ponto que conta muito em qualquer contratação são sua recomendações, este também é um ponto que um site pode resolver e um CV não.

A idéia é bem simples, permitir que qualquer profissional interessado em criar seu site possa acessar um painel administrativo e definir sua biografia, experiências, fotos de projetos, links externos e aceitar recomendações.

Como a ferramenta é para criação de um site de verdade também é necessário que exista a possibilidade da customização completa do layout, ter um domínio próprio e poder monitorar os acessos (via Google Analytics).

Ficou curioso? Acesse o meu superfolio e veja tudo que pode ser feito: http://daniellopes.me/

Planejando a execução

Com a idéia levantada começamos a fazer encontros semanais na Dito Internet.

Diferente de um projeto de software convencional, desta vez nós sabíamos todas as features e não tínhamos a opção de ir criando o sistema e recebendo feeback. Por essa razão a opção de várias reuniões longas foi tomada ao invés do modelo Agile de reuniões.

Eu fiquei responsável pela interface, então antes mesmo do evento eu fiz todos os mockups necessários para termos a visão completa da aplicação. Com os mockups detalhamos algumas dezenas de tickets no Pivotal Tracker.

Dividindo tarefas

Alguns pontos precisavam ser estudados antes do evento já que no dia não poderíamos aprender nada, apenas executar.

Como dito anteriormente, eu fui o designer então além de todos os mockups também fiz uma grande pesquisa de referência para o layout, pois não haveria tempo para “inspiração”. Com base nos mockups também foi possível identificar quais pontos do HTML seriam complexos então achei solução para estes pontos e também bibliotecas de JS que deveriam ser usadas (jQuery, facebox, jquery-tools e etc).

Bruno ficou responsável por configuração dos servers então ele montou uma receita do que precisaria ser seguido no dia do evento. Também contratou uma VPS para os testes e estudou o Base-App, que automatiza o deploy.

Jeffry ficou com a parte de customização do layout e temas, ele optou pelo Liquid e se especializou neste ponto. Também cuidou de estudar a melhor alternativa para integração contínua (escolhido foi o CI Joe).

No site também temos uma busca complexa na home que pesquisa por qualquer termo no site dos usuários. Para isso João Vitor ficou a cargo das pesquisas e por final usamos o Solr.

Logística

Antes do evento também fizemos a organização do que precisaríamos no dia e quais tipos de refeições deveriam ser feitas para evitar o cansaço.

Para o local do evento o Bruno cedeu o escritório da Dito que conta com uma infra-estrutura muito boa e cercado de restaurantes.

Foi decidido que as principais refeições seriam feitas nesses restaurantes e ali faríamos as reuniões de retrospectiva dos mini-sprints.

Tudo foi muito bem planejado e a único complicador foi a falta de um chuveiro na Dito

Execução

Uma coisa já era fato. O prazo é curto mas todos os membros da equipe são profissionais e nós não sacrificaríamos as boas práticas por causa do tempo.

Ficou definido que usaríamos métodos ágeis, pair pogramming quando necessário, deploy contínuo, integração contínua e principalmente Test Driven Development.

Jeffry montou um server de integração contínua com CI Joe que ficava ligado ao televisão de 42 polegadas da Dito. Todos os pushs para o github do projeto e builds ficavam visíveis e com um som diferente tocando para cada fato. Assim sabíamos ao certo quando os testes paravam de funcionar.

Para deploy usamos o famoso Capistrano. Mas antes do evento fizemos um tunning do meu template de app Rails, o Base-APP. Com ele o Capistrano já fica muito bem configurado além de várias outras coisas que melhoramos nele mas que são comuns para qualquer app (o projeto é open-source e MIT). Também foi usado o Hoptoad para monitoração de exceptions em produção.

Pair programming foi essêncial para achar os erros mas não para planejamento pois tudo já havia sido planejado antes. Também usamos pair programming para evitar o sono.

Para TDD decidimos pelo Rspec com Steak. Uma boa cobertura é essencial, principalmente em um ambiente tão apertado como o Rumble e testes de aceitação fizeram toda a diferença.

Tendência ao amadorismo

Nós, seres humanos, gostamos de colocar a culpa do nosso amadorismo em vários fatos mas nunca em nós mesmo. No Rumble a maior desculpa para a “tosqueira” é o tempo.

Já fui questionado várias vezes se deve ser feito TDD quando o tempo é apertado e vou compartilhar um pouco dessa experiência no caso mais extremo: Rails Rumble.

Não seguimos TDD a risca no projeto mas seguimos desenvolvimento com testes o tempo todo.

Na madrugrada de domingo, já extremamente cansados, estávamos fazendo vários push’s para o Github simultaneamente e em um certo momento alguns testes começaram a quebrar.

Não corrigimos isso na hora e ficamos com 9 testes quebrando. E nesse momento eu estava no HTML e o Bruno e Jeffry implementando novas features não relacionadas aos tests quebrados. Até que o Jeffry largou tudo para consertar os tests. Mas o Jeffry era o único da equipe com conhecimento do Liquid então o Bruno resolveu assumir o “pepino”.

Alguns dos testes foram corrigidos com meu HTML mas o mais complicado era um teste que estava falhando por algum motivo estranho que não era simples de achar. No fim, Bruno descobriu uma falha grave no nosso algoritmo de redirecionamentos que permite a usuário ter seu próprio domínio (daniellopes.me ao invés de de superfolio.net/daniel).

O resumo é que se não tivéssemos testes não teríamos conseguido achar esse bug e se a equipe tivesse deixado o caos tomar conta o sistema teria ido para o ar com este bug grave. Atualmente o sistema está rodando bem e sem notificar nenhuma exception.

Lições aprendidas

O Rumble serviu para colocar a prova todos os nossos conhecimentos de Ruby e desenvolvimento de software. Eu, pessoalmente, pude tirar várias lições (e acho que meu amigos de equipe vão concordar).

Amadorismo

Primeiro, o tópico anterior: Falta de tempo não é desculpa para amadorismo.

Equipe

Outro fator marcante foi a importância da equipe. Mais do que em qualquer projeto, no Rumble, pessoas são mais que processos e manter a comunicação, a amizade e pensamentos na mesma linha em 48h, sem descanso, é um mega desafio.

No nosso caso a equipe se deu muito bem, como eu nunca tinha visto antes. Apesar de nunca termos trabalhado todos juntos houve uma coesão muito grande.

Todos os membros trabalharam como loucos e suaram a camisa pelo projeto. Foi a melhor definição de uma equipe auto-gerenciável que já vi (kudos para o Jeffry, Bruno, João e eu mesmo ).

Descanso

Outra lição é que sempre é preciso haver descanso, não importa o quão apertado é o deadline você não pode entrar no modo “Hero” (como dito no Rework). O estado onde resolver o problema se torna questão de honra, não importando mais nada.

Se você fica muito tempo olhando um problema você nunca vai resolve-lo se não descansar um pouco ou pedir ajuda. Toda vez que a coisa agarrava compartilhávamos o problema com a pessoa mais próxima e um olhar externo resolvia rapidamente.

Design

Outro ponto que ajudou muito foi ter uma equipe de Railer’s experts junto com um designer com conhecimento de Git, HTML, JS e testes. Ou seja, alguém focado no frontend mas com visão geral das tarefas. (depois farei outro post sobre o verdadeiro papel do Design em Software)

Em vários momentos quando eu passava do photoshop para o html nossos testes de aceitação quebravam no protótipo já existente. Conseguir resolver essas coisas sem precisar chamar outro desenvolvedor ajudou muito.

Também foi importante o designer conseguir “baixar” e trabalhar corretamente com o código usando o Git, então o fluxo e forma de compartilhamento era igual entre toda a equipe e eficiente.

A parte do design também guiou as funcionalidades, fazendo que conseguíssemos identificar problemas graves antes de implementarmos.

Refactoring

Ficou bem claro que o mais importante é colocar funcionando e que depois haverá tempo para ajustes. Pensando dessa forma é muito importante manter um bom suite de testes para que você possa voltar e refatorar depois e manter a confiança do funcionamento.

O sistema possui vários pontos que podem ser melhor arquitetados mas o que importa é que ele está online e com nosso suite de testes podemos fazer essa refatoração nos pontos que importam.

Conclusão final

Apesar do cansaço (e da falta de banho eu saí do evento extremamente motivado e satisfeito com o resultado. A equipe foi extraordinária e a competição uma experiência que não tem preço.

Não importa o resultado (bem… importa um pouco a verdade é que conseguimos entregar em 2 dias um CMS relativamente complexo e mantendo a qualidade do trabalho.

Agora é conseguir os usuários que vão fazer uso do sistema de fato. Passando o efeito que chamo de “Onda Sapo” (usuários curiosos que só entram no sistema para sapear e não para usar mesmo acredito que o sistema poderá evoluir para algo bem funcional. O exemplo é o meu próprio site em daniellopes.me .

Também decidimos manter a equipe e fazer encontros frequentes para melhorar o Superfolio como um time.

Com certeza ano que vem participarei novamente e caso passemos para final vamos precisar da ajuda de vocês

Já achava que o seu Perfil Gravatar era o máximo? Espere só até os ver no seu blog WordPress.com.

Hoje nasceu uma nova e espantosa era do Gravatar: as Janelas Flutuantes Gravatar. Agora fica mais fácil saber de quem são os seus comentários favoritos no seu blog, mexendo apenas o rato..  Esta nova funcionalidade está activa em todo o WordPress.com, por omissão.

O que é?

Estas janelas mostram informações sobre uma pessoa: nome, biografia, imagens e contactos noutros serviços que usam, tais como Twitter, Facebook ou LinkedIn.

Quando comenta, esta funcionalidade oferece-lhe uma maneira excelente de divulgar a sua presença na internet e a ajudar o mundo a encontrar o seu blog. Como autor, permitem-lhe rápidamente identificar quem comenta no seu blog e oferece-lhe mais maneiras de se conectar com o seu público.

Como usar

Pode ver a informação de outras pessoas simplesmente passando o seu rato por cima da imagem Gravatar dessa pessoa em qualquer blog do WordPress.com e esperando muito poucos segundos até que apareça a janela de informação.  A informação visível é lida directamente do perfil Gravatar dessa pessoa, ou seja, quanto mais informação existir nesse perfil, mais informação verá na janela.

Isto pode ajudar bastante na moderação de comentários, já que esta funcionalidade está também disponível no painel de administração, mas se não quiser nada disto no seu blog, pode desligar esta opção em Opções > Discussão > Avatars

Se ainda não criou o seu perfil Gravatar, basta-lhe iniciar a sessão em Gravatar.com com a sua conta do WordPress.com e preencher os seus detalhes, lendo estas instruções primeiro, se necessário. Se ainda não tem conta no WordPress.com, pode pedir uma conta Gravatar aqui.

Em duas semanas a Egenial dará inicio a um novo curso, um treinamento para empreendedores chamado de Mockup.

Você sendo proprietário do seu negócio ou mesmo trabalhando como contratado em uma empresa precisa ser um empreendedor.

Mas o ponto mais atrativo para nós desenvolvedores é que como o próprio nome diz somos profissionais com o objetivo de construir algo. No entanto muitas vezes ficamos presos em tecnologias novas e desafios técnicos que na verdade não interessam muito para o produto final.

Ter a visão de colocar as coisas em prática independente da tecnologia é muito importante tanto para um funcionário de uma empresa de software ou um fundador de uma startup aplicando uma nova idéia.

Mesmo já estando com a faca e queijo na mão e na grande maioria das vezes habituados ao desenvolvimento para clientes, criar um saas ou produto qualquer envolve muito mais coisa.

Vou citar um exemplo: a parte técnica central do Cifras foi desenvolvida em pouco mais de um mês incluindo o design. É o tempo normal para desenvolvimento de um projeto para um cliente também.

Mas o que não é perceptível a primeira vista é o que está por trás do sistema. Por exemplo existe um painel administrativo que foi sendo evoluído com base nos problemas e necessidades (ver quais usuários pararam de acessar, inadimplentes, bloquear contas, etc).

Além disso também temos todo o sistema de automatização de deploy, backups e servidor de homologação.

Também temos o site público que envolve o sistema de suporte através de FAQS criados por um CMS (cada pedido de suporte que chega mais de uma vez acaba sendo convertido em um FAQ por outro painel administrativo).

Claro ainda existem outra decisões como formas de marketing, análise de mercado, melhores formas de suporte, burocracias com formas de pagamento e etc. Além de saber filtrar sugestões alinhadas com as prioridades do produto.

Ao ter uma ideia interessante normalmente você acaba esquecendo todas estas decisões importantes e que tornam a criação de um produto um trabalho colossal.

Acredito que este curso o ajudará bastante a ter uma visão completa para criar uma solução prática e por apenas R$120,00.

Pouco mais de 1 mês atrás eu postei aqui no blog uma dica sobre como dar reset na senha de “sa” no SQL Express, um assunto completamente diferente dos temas que costumo abordar normalmente. Fiz aquele post principalmente para guardar a dica, caso fosse necessária novamente no futuro. O que eu não esperava era que ela seria tão necessária: Desde quando postei até agora eu já utilizei ou indiquei aquele post 7 vezes aqui no serviço.

Esse assunto se tornou importante aqui devido ao fato de que agora os computadores de novos funcionarios não serão mais formatados, a não ser que a instalação anterior esteja com problemas. Como tivemos uma onda de contratações recentemente, vários computadores que estavam guardados foram disponibilizados para os novos desenvolvedores e então o problema de tornou latente.

Isso me fez ver também que meu post anterior poderia ter seu passo a passo melhorado, pois nem todos os casos são iguais e nem todos os detalhes estavam bem claros. Por isso eu decidi escrever um novo post mais claro e detalhado para ficar mais fácil para as próximas pessoas que precisarem dessa dica.

Quando o SQL Server ou SQL Express é instalado em um computador junto ou por algum outro aplicativo (Visual Studio, Web Platform Installer), o grupo de administradores local da máquina não é adicionado automáticamente ao grupo de administradores do banco de dados. Então, quando um computador muda de dono, o novo dono não consegue ter acesso admin no próprio SQL, mesmo sendo administrador local, pois apenas o usuário anterior e o “sa” estão no grupo de administradores do SQL.

O SQL e o SQL Express têm um modo de execução chamada “Single User” que serve justamente para realizar reparos na instalação. Quando o SQL está rodando em modo “Single User”, todos os administradores locais são incluídos temporáriamente como administradores do banco de dados, mesmo que ele não esteja configurado assim. Isso torna possível conectar no banco e fazer as “correções” necessárias usando o usuário logado atualmente no computador.

Abaixo tem um passo a passo para realizar a correção e reassumir controle sobre o banco de dados.

1. Obtenha o nome do serviço da instância do SQL que você deseja reparar. O serviço do SQL Server custuma se chamar MSSQLSERVER e o do SQL Express costuma se chamar MSSQL$SQLEXPRESS. Se você não tiver certeza, pode verificar o nome do serviço indo em “Painel de Controle > Ferramentas Administrativas > Serviços” e dando um duplo clique no serviço desejado você verá o nome dele:
   
2. Abra um prompt de comando em modo administrativo (“Run as Administrator” ou “Executar como Administrador”)
   
3. Pare o serviço do SQL desejado executando o seguinte comando:

   NET STOP NomeDoServicoPasso1

   No meu caso, o nome do serviço seria MSSQL$SQLEXPRESS.

4. Reinicie o serviço do SQL em modo Single User com o seguinte comando:
   

   NET START NomeDoServicoPasso1 /m

   A partir de agora só é possível conectar nesse banco de dados com o usuário atual.

5. Conecte no banco de dados utilizando o SQL Server Management Studio, mas executando como Administrador do mesmo modo que foi feito com o prompt de comando. Isso é necessário pois o SQL está executando em modo Single User, então ele só aceitará conexões do usuário que iniciou o serviço.

   

6. No SQL Server Management Studio, execute as alterações desejadas no servidor (ex.: alteração da senha do usuário “sa”, inclusão do seu usuário no grupo “sysadmin”, inclusão do grupo de administradores local como sysadmin no SQL, etc…). Depois de feitas as alterações, feche o SQL Server Management Studio.
7. Pare o serviço do SQL novamente, usando o mesmo comando executado no passo 3.
   

   NET STOP NomeDoServicoPasso1

8. Reinicie o serviço do SQL em modo normal, executando o mesmo comando do passo 4, mas sem o parâmetro /m no final.
   

   NET START NomeDoServicoPasso1

9. Pronto, pode voltar a usar seu servidor de banco de dados normalmente.

Os passos acima podem ser feitos para qualquer versão e instância de SQL Server ou SQL Express e também funcionam em versões anteriores do SQL.

Vou iniciar neste artigo o desenvolvimento de uma aplicação bem simples com WPF 4, o projeto consiste em um cadastro de contatos, onde o usuário poderá incluir, alterar ou deletar um contato, por questões didáticas, o exemplo terá somente 3 campos e 1 tabela, apesar de simples, estarei trabalhando em um sistema organizado em camadas, o projeto utilizará o Entity Framework 4 e será desenvolvido seguindo o padrão MVVM (Model View View-Model), que terá uma parte do tutorial somente para explicar o assunto conceitualmente e na prática.

Na primeira parte do mini tutorial nós veremos a camada de dados do projeto, nessa camada vamos programar a forma que o nosso sistema vai persistir os dados em uma base de dados, neste caso, o MS SQL Server Express 2008.

Atualmente existem diversas formas de realizar essa tarefa, o que dificulta um pouco saber qual a melhor, porem é comum fazer uso de frameworks para facilitar a persistência de dados, os frameworks O/R ajudam a manter o seu projeto padronizado, auxiliando muito em boas práticas quando temos sistemas orientados a objetos e banco de dados relacionais.

A escolha do melhor framework para um determinado projeto merece um estudo, sendo para a camada de persistência, seja para o padrão MVVM, Inversão de Controles, entre outros, uma das preocupações com o uso de frameworks é a descontinuação do mesmo por parte dos proprietários ou comunidade envolvida, mas por diversas vezes, o uso de frameworks é uma grande vantagem dependendo da situação.

Para a camada de persistência , dois frameworks tem se destacado, o nHibernate, projeto maduro, que teve sua origem no famoso framework Hibernate para Java e o Entity Framework 4, projeto da Microsoft e com vasta documentação disponível.

Recentemente iniciei meus estudos com o Entity Framework 4, e neste tutorial estarei utilizando o framework , o EF4 oferece o mapeamento objeto relacional (O/R), ou seja, permite mapear as tabelas do banco de dados como objetos, podemos criar o modelo de classes do projeto utilizando técnicas de orientação a objetos, como herança por exemplo, e neste momento não vamos nos preocupar em como o modelo de classes será registrado na base de dados.

Para iniciar, vamos criar uma Solution para guardar os projetos que farão parte dessa solução, abra o Visual Studio 2010, e clique em File – New -Project, em Installed Templates, clique em Other Project Types, e selecione Visual Studio Solutions e em seguida Blank Solution, ou seja, uma solução vazia, dê o nome de SolutionContato e clique em OK.

Selecione a opção ADO.NET Entity Data Model e dê o nome de ModelContato.edmx e clique em Add para adicionar no projeto.

No centro da tela temos o ModelContato.edmx, neste local vamos desenhar o modelo de entidades do projeto, como nosso exemplo é muito simples, selecione na janela Toolbox um elemento Entity e arraste e solte para dentro do ModelContato.edmx, note que uma classe já com uma propriedade Id foi visualmente inserida no ModelContato.edmx

Se um projeto tem mais entidades, você pode inserir da mesma forma e utilizar as associações entre as classes (Association) e Herança (Inheritance) disponíveis no painel Toolbox.

Em Generate Database Wizard clique no botão New Connection para criar uma nova conexão com o SQL Server Express.

Pronto, deixe marcado a opção “Save entity connection setting in App.Config as” para que os dados da sua conexão sejam inseridos no arquivo App.Config e clique em Next.

Um tela vai aparecer com todos os script para a criação das tabelas no SQL Server, clique em Finish, localize no Visual Studio 2010 o botão “Execute SQL” e clique para gerar a base de dados, se tudo ocorrer com sucesso, você receberá a mensagem Command(s) completed successfully.

Olá

Neste post irei comentar um pouco sobre a grande evolução que os States sofreram no Adobe Flex 4 em relação as versões 2 e 3 do Flex SDK. Com novos recursos, realmente agora ficou muito fácil sua implementação em nossos projetos.

Na versão 3 do Flex SDK, era muito difícil a utilização de States em nossas aplicações. Sua implementação era muito complexa e ao invés de facilitar a vida do desenvolvedor na verdade ela criava mais uma barreira para o desenvolvimento, ou seja, muito pouco material você irá encontrar na internet caso pesquise, encorajando a sua utilização.

Entretanto, no Flex 4 SDK, os States foram reformulados. Sua implementação ficou muito mais fácil e agora sim, vale a pena utilizar esse recurso em seus projetos.

Para exemplificar a utilização do State, iremos criar um projeto em nosso Adobe Flash Builder, conforme imagem abaixo:

Feito isso, iremos criar um layout que contemple essas duas situações:

O detalhe é que esse layout irá conter um único TitleWindow, e não iremos utilizar nenhum ViewStack para fazer as telas de login e cadastro. Iremos apenas usar os novos conceitos de States para mostrar e ocultar informações.

Primeiro passo será criar a tela de Login, conforme imagem e código abaixo:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

<?xml version="1.0" encoding="utf-8"?>
<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009"
			   xmlns:s="library://ns.adobe.com/flex/spark"
			   xmlns:mx="library://ns.adobe.com/flex/mx">
	<fx:Declarations>
		<!-- Place non-visual elements (e.g., services, value objects) here -->
	</fx:Declarations>
	<s:TitleWindow width="384" height="200" horizontalCenter="0" verticalCenter="0" title="Login">
		<s:layout>
			<s:BasicLayout/>
		</s:layout>
		<s:Label text="Olá, Seja bem vindo(a)!" left="10" top="15"/>
		<s:Label text="Email:&#xd;" top="52" left="25"/>
		<s:TextInput left="65" top="47" right="15"/>
		<s:Label text="Senha:" left="20" top="82"/>
		<s:TextInput x="65" y="77" width="148" displayAsPassword="true"/>
		<s:Button label="Entrar" left="65" top="107"/>
		<s:Button label="Limpar" top="107" left="143"/>
		<s:Button label="Não sou cadastrado" top="107" left="221"/>
	</s:TitleWindow>
</s:Application>

Podemos observar que todos os objetos contidos no TitleWindow foram posicionados através de posicionamento relativo, utilizando valores para “left, right, top” e não valores para “x e y”. Até então tudo normal, sem nenhuma implementação nova.

Agora, iremos adicionar um novo State para nossa aplicação para o formulário de cadastro, conforme imagem abaixo. Caso seu Adobe Flash Builder não esteja com o painel para States habilitado. Utilize a opção “Window -> States“.

No campo Name, informamos o nome de nosso State, Cadastro, e na opção “Create as” iremos deixar marcada a opção para que o State a ser criado seja uma duplicação do State1, que é o nome padrão do State inicial dentro do Adobe Flash Builder.

Agora iremos alterar o nome do nosso primeiro State em nossa aplicação. Para isso, iremos clicar em cima do nome State1, e solicitar sua alteração, conforme imagem abaixo:

Feito isso, podemos verificar quais alterações ocorreram em nosso código-fonte e em nosso ambiente visual. Nosso layout não sofreu nenhuma alteração, surgindo apenas um bloco de códigos com as definições dos States.

1
2
3
4

<s:states>
	<s:State name="Login"/>
	<s:State name="Cadastro"/>
</s:states>

Agora, podemos dar inicio a construção de nossa tela de cadastro. Iremos então selecionar nosso State Cadastro, da seguinte forma:

Feito isso, iremos iniciar as alterações em nossa janela, sem se preocupar com o State anterior. Obteremos então o seguinte resultado:

Para o desenvolvimento desse layout, eu dupliquei o campo e o label do campo email para que eu pudesse armazenar o nome do usuário do sistema que fosse efetuar seu cadastro, e também dupliquei o campo e label senha, conforme a sugestão do layout.

Em seguida, alterei o label dos botões, e alterei o titulo de meu TitleWindow.

Entrando em modo de Design, obtemos o seguinte código:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

<?xml version="1.0" encoding="utf-8"?>
<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009"
			   xmlns:s="library://ns.adobe.com/flex/spark"
			   xmlns:mx="library://ns.adobe.com/flex/mx">
	<s:states>
		<s:State name="Login"/>
		<s:State name="Cadastro"/>
	</s:states>
	<fx:Declarations>
		<!-- Place non-visual elements (e.g., services, value objects) here -->
	</fx:Declarations>
	<s:TitleWindow width="384" height="200" horizontalCenter="0" verticalCenter="0" title="Login" title.Cadastro="Cadastro" height.Cadastro="250" horizontalCenter.Cadastro="0" verticalCenter.Cadastro="0">
		<s:layout>
			<s:BasicLayout/>
		</s:layout>
		<s:Label text="Olá, Seja bem vindo(a)!" left="10" top="15" text.Cadastro="Informe seus dados para o cadastro&#xd;"/>
		<s:Label text="Email:&#xd;" top="52" left="25" top.Cadastro="82" left.Cadastro="26"/>
		<s:Label text="Nome:" top="53" left="23" includeIn="Cadastro"/>
		<s:TextInput top="77" left="66" right="14" includeIn="Cadastro"/>
		<s:TextInput left="65" top="47" right="15" top.Cadastro="47" left.Cadastro="66" right.Cadastro="14"/>
		<s:Label text="Senha:" left="20" top="82" top.Cadastro="112" left.Cadastro="21"/>
		<s:TextInput x="65" y="77" width="148" displayAsPassword="true" x.Cadastro="66" y.Cadastro="107"/>
		<s:Label text="Senha:" left="21" top="142" includeIn="Cadastro"/>
		<s:TextInput x="66" y="137" width="148" displayAsPassword="true" includeIn="Cadastro"/>
		<s:Button label="Entrar" left="65" top="107" top.Cadastro="167" left.Cadastro="66" label.Cadastro="Cadastrar"/>
		<s:Button label="Limpar" top="107" left="143" top.Cadastro="167" left.Cadastro="148"/>
		<s:Button label="Não sou cadastrado" top="107" left="221" top.Cadastro="167" left.Cadastro="222" label.Cadastro="Efetuar Login"/>
	</s:TitleWindow>
</s:Application>

Nesse momento, fica fácil perceber como o Flex 4 SDK trabalha com os States. A cada propriedade comum de um objeto em mais de um State, é adicionado ao fim da propriedade, o nome do State correspondente. Para exemplificar, usaremos a declaração do TitleWindow:

1

<s:TitleWindow width="384" height="200" horizontalCenter="0" verticalCenter="0" title="Login" title.Cadastro="Cadastro" height.Cadastro="250" horizontalCenter.Cadastro="0" verticalCenter.Cadastro="0">

A primeira vez o atributo title aparece sem a declaração de qual State deverá pertencer, ou seja, nesse caso esse é o valor quando o State da aplicação for o State default. Logo em seguida o atributo title aparece seguido de um ponto e do valor Cadastro, que é o nome de nosso segundo State, já com o novo valor do título da janela. E assim, essa regra permanece no próprio componente TitleWindow e também nos demais componentes.

É valido ressaltar, que ao selecionar o modo “Source” em seu Adobe Flash Builder, você também poderá mostrar o código de apenas um ou todos os States disponíveis em seu componente da seguinte forma:

Nesse momento, podemos perceber que o Adobe Flash Builder oculta a codificação em MXML que não será utilizada no State selecionado.

Para efetuarmos a troca de State, faremos a seguinte implementação. Com o State Login selecionado, clique com o botão direito do mouse sob o botão com o label “Não sou cadastrado” e vá na opção “Generate Click Handler“.

Nesse momento, o Adobe Flash Builder entrará em modo “Source”. Faça a seguinte implementação:

1
2
3
4

protected function button1_clickHandler(event:MouseEvent):void
{
	currentState = 'Cadastro';
}

Volte ao modo Design e faça a mesma operação no botão com o label “Efetuar Login” e faça a seguinte implementação:

1
2
3
4

protected function button2_clickHandler(event:MouseEvent):void
{
	currentState = 'Login';
}

Pronto. Basta salvar e executar o projeto, e terá um exemplo simples e rápido para demonstrar o uso de States dentro do Flex 4 SDK. A partir de agora, fica por nossa conta a criatividade para sua melhor exploração.

Para ver o exemplo rodando clique aqui.

Para ver o código fonte do exemplo completo clique aqui.

Para efetuar o download do exemplo clique aqui.

Obrigado pela visita, volte sempre!

Caso você não tenha ouvido, Adobe Acrobat 9 tem uma API de ActionScript para portfólios PDF.

Aprenda e faça-se sobressair de outros desenvolvedores Flex. O “Adobe Acrobat PDF Portfolio Navigator Developer Contest” pode ser sua oportunidade de ter o seu trabalho comentado por algumas das empresas RIA top no mundo. No concurso, você também pode ganhar excelentes prémios.

Um painel de especialistas da Adobe irá selecionar 10 trabalhos. Representantes de diversas empresas RIA irão rever os 10 melhores trabalhos e selecionar três vencedores. Esta é uma ótima maneira de começar o seu trabalho e mostrar a estas empresas o seu trabalho que estão sempre à procura de colaboradores criativos.

Os juízes destas empresas líderes no mundo RIA são:
• Blitz
• Catalyst Resources
• Effective UI
• G2
• Universal Mind

1º lugar:
Escolha entre Dell Adamo Desire ou MacBook Air 2.13GHz

2º lugar:
Apple iPad wifi, 3G 32GB device

3º lugar:
HP Mini 5102 device

10 finalistas:
Destaque em Adobe.com

Ir a Adobe Acrobat PDF Portfolio Navigator Developer Contest para obter mais informações.

Boa sorte a todos!

Olá pessoal

A grande sensação ontem (23/03) foi a publicação pelo guru Christophe Coenraets demonstrando um vídeo aonde através do Flash Builder ele consumiu recursos de um projeto Java sem codificação no ambiente Flex. Nesse artigo vou demonstrar como trabalhar com esse recurso passo-a-passo.

Bom, primeiro passo é você ter em seu computador todas as ferramentas necessárias. Neste caso, você irá utilizar o Eclipse Galileu JEE, Flash Builder (stand-alone ou plugin) e do BlazeDS 4 Beta.

A aplicação que desenvolveremos nesse tutorial é a mesma desenvolvida no post anterior, com a diferença que aonde foi feito codificação manual no ambiente Flex, agora, iremos utilizar o Flash Builder para a geração do código fonte.

Bom, no Eclipse Galileo para iniciar um projeto, eu escolhi a opção File -> New -> Web -> Dynamic Web Project, conforme abaixo:

E depois configurei o projeto da seguinte maneira:

Bom, depois de configurar o projeto, iremos criar um Bean para serializarmos algumas informações que serão enviadas para o Flex. A idéia é bastante simples, irei criar um model para uma simples agenda de contato.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

package br.com.horochovec.model;
 
import java.io.Serializable;
 
/**
 * Modelo para agenda de contato
 * @author Stefan Horochovec
 */
public class Contato implements Serializable {
 
	/**
	 *
	 */
	private static final long serialVersionUID = 1L;
 
	private String nome;
 
	private String email;
 
	public String getNome() {
		return nome;
	}
 
	public void setNome(String nome) {
		this.nome = nome;
	}
 
	public String getEmail() {
		return email;
	}
 
	public void setEmail(String email) {
		this.email = email;
	}
 
}

E em seguida, criarei um serviço que irá adicionar em um ArrayList os contatos que serão enviados do Flex para o Java.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

package br.com.horochovec.service;
 
import java.util.ArrayList;
 
import br.com.horochovec.model.Contato;
 
/**
 * Serviço para manutenção dos contatos
 * @author Stefan Horochovec
 */
public class ContatoService {
 
	private static ArrayList listContato = new ArrayList();
 
	/**
	 * Adiciona um contato a lista
	 * @param contato
	 */
	public void addContato(Contato contato) {
		listContato.add(contato);
	}
 
	/**
	 * Retorna a lista de contatos
	 * @return
	 */
	public ArrayList getListContato() {
		return listContato;
	}
 
}

Após isso, já temos uma simples aplicação pronta para trabalhar com o Flex, basta apenas configurar os arquivos .XML para que o BlazeDS possa funcionar.

A partir de agora é necessário que você já tenha descompactado o arquivo blazeds-bin-4.0.0.14910.zip. Após descompactá-lo, você terá que descompactar o arquivo blazeds.war que surgiu da descompactação anterior. Como resultado, obterá o seguinte:

Bom, podemos copiar para o diretório WebContent/WEB-INF de nosso projeto Java, os diretórios: flex/, lib/, spring/ e os arquivos: flex-servlet.xml e web.xml. Após copiar esse conteúdo, o primeiro arquivo que iremos configurar, é o arquivo web.xml que fica dentro da pasta WebContent/WEB-INF/.

Para essa configuração, iremos alterar o conteúdo do arquivo web.xml que veio dentro do arquivo blazeds.war que foi previamente descompactado.

Perceba que os parametros da aplicação foram alterados e também foi alterado o valor da propriedade useAppserverSecurity para false. O resultado será:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
 
    <display-name>FlexDuck</display-name>
    <description>FlexDuck</description>
 
    <!-- Http Flex Session attribute and binding listener support -->
    <listener>
        <listener-class>flex.messaging.HttpFlexSession</listener-class>
    </listener>
 
    <!-- MessageBroker Servlet -->
    <servlet>
        <servlet-name>MessageBrokerServlet</servlet-name>
        <display-name>MessageBrokerServlet</display-name>
        <servlet-class>flex.messaging.MessageBrokerServlet</servlet-class>
        <init-param>
            <param-name>services.configuration.file</param-name>
            <param-value>/WEB-INF/flex/services-config.xml</param-value>
       </init-param>
        <load-on-startup>1</load-on-startup>
    </servlet>
 
    <servlet>
        <servlet-name>RDSDispatchServlet</servlet-name>
		<display-name>RDSDispatchServlet</display-name>
        <servlet-class>flex.rds.server.servlet.FrontEndServlet</servlet-class>
		<init-param>
			<param-name>useAppserverSecurity</param-name>
			<param-value>false</param-value>
		</init-param>
        <load-on-startup>10</load-on-startup>
    </servlet>
 
    <servlet-mapping id="RDS_DISPATCH_MAPPING">
        <servlet-name>RDSDispatchServlet</servlet-name>
        <url-pattern>/CFIDE/main/ide.cfm</url-pattern>
    </servlet-mapping>
 
    <servlet-mapping>
        <servlet-name>MessageBrokerServlet</servlet-name>
        <url-pattern>/messagebroker/*</url-pattern>
    </servlet-mapping>
 
    <welcome-file-list>
        <welcome-file>index.html</welcome-file>
        <welcome-file>index.htm</welcome-file>
    </welcome-file-list>
 
    <!-- for WebSphere deployment, please uncomment -->
    <!--
    <resource-ref>
        <description>Flex Messaging WorkManager</description>
        <res-ref-name>wm/MessagingWorkManager</res-ref-name>
        <res-type>com.ibm.websphere.asynchbeans.WorkManager</res-type>
        <res-auth>Container</res-auth>
        <res-sharing-scope>Shareable</res-sharing-scope>
    </resource-ref>
    -->
 
<!--
	<context-param>
		<param-name>contextConfigLocation</param-name>
		<param-value>
			/WEB-INF/spring/*-config.xml
		</param-value>
	</context-param>
 
    <filter>
        <filter-name>springSecurityFilterChain</filter-name>
        <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
    </filter>
 
    <filter-mapping>
      <filter-name>springSecurityFilterChain</filter-name>
      <url-pattern>/*</url-pattern>
    </filter-mapping>
 
	<listener>
		<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
	</listener>
 
	<servlet>
		<servlet-name>flex</servlet-name>
		<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
		<load-on-startup>1</load-on-startup>
	</servlet>
 
	<servlet-mapping>
    	<servlet-name>flex</servlet-name>
    	<url-pattern>/messagebroker/*</url-pattern>
 	</servlet-mapping>
 
-->
 
</web-app>

Feito isso, iremos adicionar dentro da pasta WebContent a pasta flex que foi previamente descompactada do arquivo blazeds.war, e também todo o conteúdo da pasta lib para dentro do diretório WebContent/WEB-INF/lib , obtendo o seguinte resultado:

Feito isso, iremos configurar o único arquivo .xml do BlazeDS para que esse exemplo funcione. O arquivo WEB-INF/flex/remoting-config.xml. Iremos adicionar uma configuração para informar ao BlazeDS sobre o serviço ContatoService que foi criado anteriormente, conforme abaixo:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

<?xml version="1.0" encoding="UTF-8"?>
<service id="remoting-service" 
    class="flex.messaging.services.RemotingService">
 
    <adapters>
        <adapter-definition id="java-object" class="flex.messaging.services.remoting.adapters.JavaAdapter" default="true"/>
    </adapters>
 
    <default-channels>
        <channel ref="my-amf"/>
    </default-channels>
 
    <destination id="ContatoService">
    	<properties>
    		<source>br.com.horochovec.service.ContatoService</source>
    	</properties>
    </destination>
 
</service>

Após essa última configuração, podemos exportar o nosso projeto para um servidor web. Nesse caso, utilizaremos o Tomcat 6.x. Neste artigo não entrarei em detalhes de sua instalação e configuração.

Bom, as configurações no projeto Java já foram finalizadas, e considerando que o deploy da aplicação dentro do Tomcat já foi realizado, a partir deste momento iremos trabalhar diretamente com o Flash Builder.

Neste artigo irei demonstrar a comunicação utilizando o Flash Builder e a versão do Flex 4. Você pode fazer o download da versão 4.0 do Flash Builder e do Flex 4 SDK aqui.

Após instalado e iniciado o Flash Builder, iremos criar um projeto no seguinte molde:

As configurações feitas na segunda tela de configuração são bastante importantes. Fazendo elas da forma correta, você estará apto a iniciar o projeto sem fazer novas configurações.

Na primeira linha, em Root Folder, foi apontado o diretório de deploy da minha aplicação dentro do meu servidor de aplicação.

Na segunda linha, em Root URL, foi apontado o caminho da URL para abertura da aplicação em meu navegador de internet.

Na terceira linha, em ContextRoot, apontamos o nome da nossa aplicação.

Na quarta e ultima linha, em Output folder, apontamos o diretório de onde deve ser exportados os arquivos quando compilados. Para esse tutorial, foi apontado diretamente o diretório de minha aplicação dentro do meu servidor Tomcat.

Como resultado, o Flash Builder irá criar e disponibilizar no workspace um projeto da seguinte forma:

É muito importante fazer a conferência de uma configuração gerada automaticamente pelo Flash Builder em cima dos parametros informados na segunda etapa da criação do projeto. No menu ‘Project’ vá na opção ‘Properties’ e confira as propriedades de acordo com a imagem abaixo:

Iremos criar uma tela no Flash Builder que contenha dois campos text input para preencher as informações do nome e email do contato, e também um grid para conter a lista dos contatos que serão adicionados no Java e retornarão ao Flex através do BlazeDS.

Segue sua implementação

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

<?xml version="1.0" encoding="utf-8"?>
<?xml version="1.0" encoding="utf-8"?>
<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009"
			   xmlns:s="library://ns.adobe.com/flex/spark"
			   xmlns:mx="library://ns.adobe.com/flex/mx" height="419">
 
 
	<fx:Declarations>
 
	</fx:Declarations>
 
 
	<s:Panel width="400" height="137" title="Cadastro" left="10" top="10">
 
	</s:Panel>
 
	<s:Panel x="12" y="166" width="400" height="227" title="Pesquisa" left="10">
		<mx:DataGrid x="10" y="10" bottom="30" left="5" right="5" top="5" id="grid">
		</mx:DataGrid>
		<s:Button x="-1" y="163" label="Listar todos" left="5" bottom="5" id="button"/>
	</s:Panel>
</s:Application>

A partir deste momento, usaremos os recursos de Data/Services presentes no Flash Builder 4 para a geração da comunicação com o Java.

Primeiro, iremos conectar o Flash Builder com o BlazeDS. Para isso, na aba “Data/Services” clique na opção “Connect to Data/Service”. Caso ela não esteja disponivel em seu workspace, vá ao menu “Window” e marque a opção “Data/Services”.

Feito isso, na próxima tela, marque a opção “BlazeDS”, clique em Next e marque a opção para não utilizar controle de acesso. Conforme as telas abaixo:

Na última tela, você deve marcar os serviços que deseja adicionar a aplicação, com opção de definição de endereços de pacotes e depois finalizar a criação do Objeto, conforme:

Após finalizar a configuração do serviço remoto, obtemos o seguinte resultado no Flash Builder.

Agora, iremos definir que no momento do click no botão logo abaixo do DataGrid, a aplicação deverá invocar o método getListContato().

O primeiro passo para isso, é clicar com o botão direito sobre o botão com do painel que contem o DataGrid e marcar a opção “Generate Service Call“. Feito isso configure a tela do serviço conforme apresentado abaixo:

Feito isso, selecione o DataGrid e clicando com o botão direito dentro dele, selecione a opção “Bind to Data” e configure a tela conforme informado abaixo:

Nesse momento, o painel responsável por listar as informações da nossa agenda de contato já está finalizado.

Agora, clicando novamente com o botão direito em cima do DataGrid, clique na opção “Generate Details Form” e configure a tela conforme abaixo:

O formulário gerado será adicionado no mesmo container que estiver o DataGrid, portanto, será necessário reposicioná-lo dentro do Panel já criado, conforme imagem abaixo:

Ok, agora basta configurarmos o clique do botão de salvar para que adicione novos contatos.

O primeiro passo é alterar o label do botão para “Cadastrar“.

O segundo passo é clicar com o botão direito sobre o botão de cadastro e selecionar a opção “Generate Service Call” e configure a opção da seguinte forma:

Ao terminar essa configuração, você será direcionado diretamente para a implementação do click do botão com a chamada do serviço remoto. A implementação gerada do método será a seguinte:

1
2
3
4
5
6

protected function button2_clickHandler(event:MouseEvent):void
{
	contato.email = emailTextInput.text;
	contato.nome = nomeTextInput.text;
	addContatoResult.token = contatoService.addContato(/*Enter value(s) for */ arg0);
}

E você deverá fazer a seguinte alteração. Adicionar o parametro a ser enviado no método addContato() e inicializar o objeto contato, da seguinte forma:

1
2
3
4
5
6
7

protected function button2_clickHandler(event:MouseEvent):void
{
	contato = new Contato();
	contato.email = emailTextInput.text;
	contato.nome = nomeTextInput.text;
	addContatoResult.token = contatoService.addContato(contato);
}

Com isso, nosso projeto estará enviado as informações para o Java. Agora, para finalizar, iremos adicionar um evento para disparar um método quando tivermos o resultado do serviço remoto.

No CallResponder com o id “addContatoResult” pressione o CTRL + SPACE para acionar o code complete e acione o event “result“, e em seguida, solicite para que seja adicionado o ResultHandler para o event adicionado, conforme imagens abaixo:

E na função adicionada no código devemos fazer a seguinte implementação:

1
2
3
4
5

protected function addContatoResult_resultHandler(event:ResultEvent):void
{
	contato = new Contato();
	getListContatoResult.token = contatoService.getListContato();
}

Rodando a aplicação, teremos como resultado no navegador o seguinte:

E como resultado final no código fonte:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66

<?xml version="1.0" encoding="utf-8"?>
<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009"
			   xmlns:s="library://ns.adobe.com/flex/spark"
			   xmlns:mx="library://ns.adobe.com/flex/mx" height="419" xmlns:services="services.*" xmlns:valueObjects="valueObjects.*">
	<fx:Script>
		<![CDATA[
			import mx.controls.Alert;
			import mx.rpc.events.ResultEvent;
 
			protected function button_clickHandler(event:MouseEvent):void
			{
				getListContatoResult.token = contatoService.getListContato();
			}
 
 
			protected function button2_clickHandler(event:MouseEvent):void
			{
				var contato : Contato = new Contato();
				contato.email = emailTextInput.text;
				contato.nome = nomeTextInput.text;
				addContatoResult.token = contatoService.addContato(contato);
			}
 
 
			protected function addContatoResult_resultHandler(event:ResultEvent):void
			{
				contato = new Contato();
				getListContatoResult.token = contatoService.getListContato();
			}
 
		]]>
	</fx:Script>
 
 
	<fx:Declarations>
		<s:CallResponder id="getListContatoResult"/>
		<services:ContatoService id="contatoService" fault="Alert.show(event.fault.faultString + 'n' + event.fault.faultDetail)" showBusyCursor="true"/>
		<valueObjects:Contato id="contato"/>
		<s:CallResponder id="addContatoResult" result="addContatoResult_resultHandler(event)"/>
	</fx:Declarations>
 
	<fx:Binding source="grid.selectedItem as Contato" destination="contato"/>
 
	<s:Panel width="400" height="137" title="Cadastro" left="10" top="10">
		<mx:Form defaultButton="{button2}" x="1" y="-4" bottom="0" left="0" right="0" top="0">
			<mx:FormItem label="Email">
				<s:TextInput id="emailTextInput" text="{contato.email}"/>
			</mx:FormItem>
			<mx:FormItem label="Nome">
				<s:TextInput id="nomeTextInput" text="{contato.nome}"/>
			</mx:FormItem>
			<s:Button id="button2" label="Cadastrar" click="button2_clickHandler(event)"/>
		</mx:Form>
 
	</s:Panel>
 
	<s:Panel x="12" y="166" width="400" height="227" title="Pesquisa" left="10">
		<mx:DataGrid x="10" y="10" bottom="30" left="5" right="5" top="5" id="grid" dataProvider="{getListContatoResult.lastResult}">
			<mx:columns>
				<mx:DataGridColumn headerText="email" dataField="email"/>
				<mx:DataGridColumn headerText="nome" dataField="nome"/>
			</mx:columns>
		</mx:DataGrid>
		<s:Button x="-1" y="163" label="Listar todos" left="5" bottom="5" id="button" click="button_clickHandler(event)"/>
	</s:Panel>
</s:Application>

Para fazer o download do projeto clique aqui.

Espero ter ajudado, um abraço