C A P Í T U L O  1 

Apresentando as Aplicações de Internet Rica (RIAs) O

kit de ferramentas para Web do Google (Google Web Toolkit - GWT) é um framework de código aberto, que facilita a criação de RIAs para desenvolvedores Java. Você pode usar seus conhecimentos para criar “fat clients” que podem ser implantados, como aplicações web. Estas aplicações, com formato desktop, são, normalmente, escritas em JavaScript, visando o melhor aproveitamento da enorme base instalada de browsers da web. Mas o JavaScript é uma linguagem bem diferente do Java (seu nome foi escolhido por razões de marketing) e, portanto, precisa de diferentes práticas de desenvolvimento. Entretanto, o GWT permite que você desenvolva aplicações JavaScript em Java! Isto é obtido através da parte mais importante do GWT, o compilador de Java para JavaScript. Este compilador traduz o seu código Java em JavaScript, executado no browser do usuário. Como bônus, o GWT consegue lidar com a maioria dos quirks dos navegadores, permitindo que você se concentre em escrever um código que faça algo. Este livro objetiva mostrar como usar o GWT na construção de RIAs. Porém, antes de apresentar o GWT, detalhadamente, precisamos, primeiro, fornecer um pouco de perspectiva histórica. Se você já está familiarizado com o funcionamento interno da web ou se já está ciente das vantagens que o Ajax tem, comparado com as outras abordagens para a criação de RIAs, (como o Flex), sinta-se à vontade para pular este capítulo e começar a partir do capítulo 2, que faz a introdução do GWT. Este capítulo fornece um breve histórico dos sistemas de software, como normalmente interagimos com eles, e como tornamos eles disponíveis aos usuários. Apresentamos diferentes tipos de aplicativos, incluindo RIAs, e descrevemos o Ajax como um dos meios para a criação de RIAs. Finalmente, comparamos diferentes abordagens para o desenvolvimento de RIAS, antes de nos concentrar em uma em particular, no próximo capítulo: o GWT

Uma Breve História Sistemas de Software já estão entre nós por vária décadas, mas só recentemente podemos dizer que começaram a ser usados por milhões de pessoas no mundo todo. Não faz nem vinte anos, quando a maioria das aplicações de software eram somente usadas por profissionais treinados, hoje, a maioria das pessoas no mundo interagem diretamente com uma ou mais aplicações diariamente. Este enorme e rápido crescimento no número de usuários de computadores não poderia ter acontecido sem o grande avanço na facilidade de uso e nas técnicas de interface que se seguiram.

Aplicações Cliente/Servidor

Aplicações Web Ricas

Experiência do Usuário

Aplicações Mainframe

Aplicações Web

Eficiência no Custo Figura 1-1.  Uma vista geral da história de aplicações de software. 1

2

C apítulo 1    A pr e s e n ta n d o a s A plica ç õ e s d E I n t e r n e t R I C A ( R I A s )

Recordando o passado, é difícil acreditar que havia gente que realmente achava divertido interagir com os primeiros computadores (ainda que eu tenha que brigar com alguns que ainda usam Vim). A maioria que se lembra dos terminais de “tela verde” vai admitir que trabalhar com um comando prompt não era geralmente a experiência mais agradável. Entrando com um comando no teclado, dando Enter, e esperando pela saída aparecer na tela nunca vai constituir um rich client (ainda que, para tarefas de certos usuários, seja essa, ainda, a forma apropriada e até mais produtiva). Para evitar confusão, vamos descrever o que caracteriza um rich client. A “riqueza” do cliente está determinada pelo modelo de interação que o cliente oferece ao usuário. Um modelo rico de interação com o usuário é o que oferece suporte para uma variedade de métodos de entrada e que responde intuitivamente e dentro de um prazo razoável. Tal qual uma regra prática, para ser considerado rica, a interação do usuário deverá ser tão boa quanto a mais atualizada geração de aplicativos desktop, como editores de texto e planilhas. Isto inclui características como providenciar meios diferentes de interação (como exemplo, usando o teclado e o mouse para navegação, edição inline e arrastar e soltar) e retorno visual (por exemplo, a mudança do formato do cursor, anúncios em cores diferentes e mostrando botões e janelas em destaque). A passagem daqueles velhos tipos de aplicação para aplicações ricas da web, que este livro trata, foi longa e gradual. A figura 1-1 mostra uma visão geral do estágio principal desta mudança e vai servir de base para a nossa breve história. Podemos distinguir, a grosso modo, quatro estágios na evolução dos softwares de aplicação. A seta mostra o caminho destes estágios, através do tempo.

Aplicações Mainframe Começando por volta de 1960, as aplicações mainframe, cujos usuários tenham acesso por meio de cartões perfurados e terminais lsater (ou emulações de terminais), estabeleceram o primeiro estágio de aplicações de software. Os terminais “tela verde” (os monitores monocromáticos da maioria dos terminais e dos antigos PCs) disponibilizavam uma interface de usuário baseada em texto, para interação com a parte servidor da aplicação. Uma interface baseada em texto, obviamente, não permite interatividade rica, como arrastar e soltar ou feedback instantâneo ao mesmo tempo que o usuário está digitando. De mais a mais, as aplicações dos terminais não conseguem fornecer a melhor resposta, pois a entrada do usuário deve sempre ser processado pelo servidor antes que o retorno esteja disponível ao usuário. De uma perspectiva custo-benefício, aplicações mainframe sempre foram criticadas por ter custos de manutenção crescentes que são o resultado de um círculo vicioso de falta de documentação e a dificuldade de fazer upgrade. A aplicação tinha de ser desenvolvida para o sistema operacional específico onde seria implantada, e, possívelmente, dependendo no número de sistemas operacionais suportados, resultando em uma maior base de código.

Aplicações Cliente/Servidor À medida que os computadores pessoais se tornaram mais populares, as pessoas começaram a ter mais poderes em suas mesas. Com esta revolução, veio a mudança da UI, baseada na linha de comando para uma UI mais próxima ao desktop, resultando no modelo WIMP (janelas, ícones, menus e dispositivos como o mouse) inventado na Xerox PARC nos meados de 1970. Ainda que as primeiras adoções pela Apple e Microsoft fossem pobres, elas permitiram aos desenvolvedores criar aplicações com características de interação com o usuário mais ricas. O poder gráfico das máquinas desktop permitiu que as aplicações se tornassem mais amigáveis, com um retorno visual melhorado. No entanto, estas aplicações ainda necessitavam de um processamento e armazenamento de dados centralizado, portanto, precisando interagir com um servidor central, sendo que, daí, veio o termo cliente/servidor. Em termos de custo, não houve uma melhora substancial, pois, além do desenvolvimento do software do lado servidor, agora também o lado cliente teria de ser desenvolvida. E sendo que os requisitos para o lado cliente normalmente ditavam suporte para vários sistemas operacionais, houve um aumento maior nos custos de desenvolvimento e manutenção. Outro fator de aumento de custos foi que o software, não era executado em um lugar central, mas sim em numerosas máquinas individuais, toda versão nova de software necessitava de atualização em todas as máquinas onde estava instalado.

Aplicações Web Ao mesmo tempo que as aplicações de software eram desenvolvidas no servidor central, ou em torno dele, a Internet e a Web estavam se tornando populares e se espalhando. A Web, originalmente, era para ser uma plataforma para permitir que pessoas pudessem compartilhar informações, publicando documentos e, através de hiperlinks, fazer referência cruzada deles. À medida que o uso da Web se tornou mais abrangente, mais e mais pessoas começaram a ter softwares em suas máquinas que podiam interagir com esta estrutura de documentos. O navegador web permitia funcionalidades comuns, como ir e vir através do histórico da navegação e marcar determinadas páginas para uma futura recuperação. Mas a principal vantagem era que, ao invés de ter vendedores de software tendo de criar versões específicas de suas aplicações para sistemas operacionais diferentes, eles tinham esta enorme base instalada ao seu dispor. Se ao menos eles pudessem entrar nisso! Para que se possa entender os próximos passos da evolução dos aplicativos de software, precisamos olhar mais detalhadamente a estrutura e os procedimentos internos da Web. Os navegadores Web entregam documentos formatados, usando a Hypertext Markup Language (HTML) (www.w3.org/HTML). Eles encontram o documento que o usuário quer, usando um uniform resource locator (URL) (http://www.w3.org/Adressing) e usa um Hypertext Transfer Protocol (HTTP) (http://www.w3.org/Protocols) para recuperar o documento de um servidor web remoto. Este é um importante conceito da Web: na verdade, todos os documentos residem em um ou mais servidores Web, e o navegador web (o cliente) recupera o documento do servidor. Ele então lê o documento HTML, aplicando as regras de formatação definidas no arquivo (discutido mais tarde) e o transfere para a tela, para a leitura do usuário.

C apítulo 1    A pr e s e n ta n d o a s A plica ç õ e s d E I n t e r n e t R I C A ( R I A s )

3

A enorme popularidade da Web é, em grande parte, devida a ela ser única: só há uma Web, para onde quer que vá e seja qual for a plataforma que você use. E, além disso, a Web está definida por um punhado de padrões industriais sem fins lucrativos que são definidas e gerenciadas por entidades, como a World Wide Web Consortium (W3C) que estão à disposição em http://www. w3.org) e a Internet Engineering Task Force (IETF) (http://www.ietf.org), que impediu vendedores individuais, como a Microsoft, de se apoderar da Web através de extensões proprietárias. A Web funciona somente por que pessoas aceitam os padrões que os navegadores podem implementar, aos quais provedores de conteúdo e desenvolvedores de aplicativos podem aderir. Não somente o HTML, mas outros padrões, como o Cascading Style Sheets (CSS) (http://www.w3.org/Style/CSS ), Document Object Model (DOM) (http://www.w3.org/DOM), Scalable Vector Graphics (SVG), e Portable Network Graphics (PNG) (http://www.w3.org/ Graphics/PNG) têm contribuido para o sucesso da Web. A maioria destes padrões serão discutidos ao longo deste livro. Ao invés de usar somente a Web para entregar documentos HMTL estáticos aos usuários, alguém veio com a ideia de permitir que os usuários solicitassem documentos gerados dinamicamente. Desse modo, por exemplo, o usuário aproveitaria os navegadores web (já instalados) para pesquisar estatísticas em tempo real ou conteúdos pessoais. É aqui, neste ponto, que nasce a aplicação Web. Uma aplicação web é a que reside em um servidor central e pode ser acessada por usuários que já possuam navegadores web. Em uma perspectiva eficaz de custo, esta era uma ótima forma de desenvolvimento de software. Você desenvolve e fornece a aplicação uma só vez, ao invés de ter de instalar aplicações clente em cada máquina de usuário, o cliente já tem todo o software necessário pré-instalado. E quando você desenvolve uma versão nova de sua aplicação, só tem de trocar a versão central, e porque todos os clientes interagem com a versão central, eles estarão automaticamente recebendo a nova versão. No entanto, de um ponto de vista da riqueza, as coisas voltaram aos tempos do mainframe. Ao invés de ter a experiência rica do desktop do usuário, permitindo múltiplos meios de interação, resposta e feedback visual, as coisas foram de novo para o modelo de interação “entre-com-comando-e-espere”. Toda ação em um aplicativo web resulta em uma chamada ao servidor, para gerar a próxima página ou documento. Portanto, como um cliente, você emite um comando, clicando em um link ou submetendo um formulário, e então você talvez tenha de esperar centenas de milisegundos, ou até segundos, para receber a página/ documento de volta do servidor. Enquanto isso se passa, você não tem meios de interagir com a aplicação. Ainda que exista um retrocesso óbvio, em termos de uso, o custo-beneficio, grandemente melhorado, tornou as aplicações na web a mais popular aplicação de software, hoje em dia.

Aplicações Ricas da Web Ainda que aplicações web tenham se tornado, de fato, o padrão para o desenvolvimento de software, elas são, na maioria dos casos, usadas para desenvolver aplicações de propósito geral que estão publicamente disponíveis. Apesar disso, temos numerosas aplicações que dependem, pesadamente, da interação rica com o usuário para completar tarefas do dia-a-dia, elas são desenvolvidadas como aplicações cliente/servidor. A razão disso é óbvia, à medida que a Web e sua abordagem de documentos centralizados não permitem ao usuário uma interação rica. Imagine uma aplicação do tipo planilha na Web, onde toda vez que você entra ou modifica dados em uma célula, você tenha de esperar que a página seja toda recarregada com os valores recalculados. Isso se torna pior quando a comunicação entre cliente e servidor passa por uma rede pública, tipicamente gerando um tempo de espera maior entre pedidos e respostas. Um tempo de espera grande para um retorno pode conduzir a um bloqueio da aplicação e, portanto, não-aplicável para realizar um trabalho diário de uma pessoa. Portanto, esse tipo de aplicação, até recentemente, permaneceu no domínio do cliente/servidor, alavancando a capacidade de uma aplicação verdadeiramente rica, mas ainda carregando o fardo de ser um alvo em diferentes ambientes. É aqui que o Ajax entra para resolver esta questão, ao permitir a desenvolvedores criar aplicações user-friendly e ainda colher o beneficio de poder disponibilizar a aplicação na Web.

Apresentando o Ajax Conforme foi esboçado nas seções anteriores, desenvolvedores precisavam de uma forma de desenvolver aplicações interativas e ao mesmo tempo poder disponibilizar essas aplicações na web. O Ajax preenche exatamente essa necessidade. Por exemplo, desenvolvedores podem usar o Ajax para prover uma funcionalidade que busca e mostra sugestões apropriadas à medida que os usuários entram com dados em um campo de entrada. Eles também podem codificar poderosas aplicações de chat baseadas na Web, que não necessitam de um refresh em toda a página, enquanto o usuário está teclando uma nova mensagem. O Ajax faz isso tudo usando o JavaScript, no navegador, para modificar diretamente a UI, usando o objeto XMLHttpRequest, que será discutido mais tarde, para se comunicar com o servidor sem dar refresh na página inteira. Então, usa a informação retornada do servidor, normalmente em XML ou outro tipo de formato de texto, para atualizar a UI. Antes mesmo que o termo Ajax fosse cunhado, desenvolvedores já estavam desenvolvendo aplicações como as descritas, usando características específicas dos navegadores (como o LiveConnect Netscape http://developer.mozilla.org/en/docs/LiveConnect). Mas só foi depois que Jesse James Garret cunhou o termo em seu artigo “Ajax: A New Approach to Web Applications” (http:// www.adaptivepath.com/publications/essays/archives/000385.php) que esse modelo para desenvolver aplicações realmente decolou. Apesar que hoje Ajax seja uma palavra que não significa nada, Garret sugeriu que ela fosse um acrônimo para Asynchronous JavaScript and XML. Vamos nos deter em cada um dos componentes deste acrônimo para poder entender o que é o Ajax.

Assíncrono Para se entender, a principal diferença que há entre as aplicações Ajax e as que foram desenvolvidas antes do apareceimento do Ajax, temos de olhar, atentamente, como os usuários interagem com as aplicações web. Figura 1-2 ilustra isto para uma apli-

4

C apítulo 1    A pr e s e n ta n d o a s A plica ç õ e s d E I n t e r n e t R I C A ( R I A s )

cação web típica. O usuário inicia fazendo um pedido em uma página web. O servidor processa o pedido e devolve o resultado para o navegador, onde ele é, subsequentemente, disponibilizado para o usuário. Uma aplicação web típica só permitirá ao usuário fazer um limitado número de coisas. O usuário pode fornecer dados de entrada através do uso de widgets de formulário (clicando num link ou botão para submeter a informação) ou solicitando uma nova página. O resultado de ambas as ações é que o usuário terá que esperar o servidor retornar a resposta. Nesse meio tempo, o usuário não tem acesso à aplicação. Este é o chamado modelo síncrono de interação. Toda interação com o usuário é interrompida até que o servidor retorne a resposta, só então o usuário pode continuar a usar a aplicação.

Cliente

Pedido

Pedido

Rede

Usuário Interação

Resposta

Usuário Interação

Resposta

Usuário Interação

Servidor Processamento do Lado Servidor

Processamento do Lado Servidor

Tempo Figura 1-2.  O modelo de interação da uma aplicação web típica. Ainda que seja aceitável este modelo para navegação através de páginas web (digamos, em um site de notícias), é inviável para aplicações do dia-a-dia, como nossa planilha no exemplo anterior. É inaceitável no caso de uma aplicação tipo planilha, modificando um dado e então tendo que esperar o servidor retornar os valores recalculados de uma fórmula. Primeiro, você quer continuar interagindo com a planilha, enquanto o resultado da ação é recalculado. Ainda mais importante: você também quer evitar o recebimento e nova renderização da página inteira. Isso causa um overhead extra porque o servidor tem que regerar a página inteira, e ela será enviada através da rede e o navegador tem que gerar a página inteira, novamente. Seria muito melhor se pudéssemos só atualizar as células relevantes na planilha. É aí que o modelo assíncrono entra no jogo, preenchendo os espaços vazios (buracos) na interação e permitindo que o usuário continue interagindo com a aplicação, enquanto ações anteriores são manipuladas pelo servidor. Este modelo é mostrado na Figura 1-3. O problema com a interação mostrada na Figura 1-3 é a quebra do modelo clássico Web do pedido de página por HTTP pelo HTML, cuja simplicidade é uma de suas maiores forças. O modo de fazer isso sem perder mais do que ganhamos é com o Ajax engine, uma camada entre a interação do usuário e a comunicação com o servidor. Este engine roda dentro do navegador e delega ações ao servidor enquanto manipula os resultados. Pelo fato que o engine despacha chamadas para o servidor e disponibiliza resultados para o usuário, o usuário pode, nesse período, continuar interagindo com a aplicação. Em razão que o engine adere aos mesmos padrões, o modelo Web permanence intacto. Para implementar esse modelo assíncrono, precisamos de uma forma de enviar pedidos para o servidor de modo assíncrono, sem fazer uma atualização de página. Como já foi anteriormente mencionado, a Web, originalmente, foi criada para estabelecer conexões entre documentos e navegação entre eles. Portanto, nem a Web nem seus padrões suportam, diretamente, operações do tipo Ajax. Entretanto, desenvolvedores são pessoas criativas e se houver um meio, ele será usado para conseguir fazer o trabalho. Sucede que havia um meio de se fazer estes chamados assíncronos dos navegadores, só que não em uma forma de navegaçao independente. O Microsoft Internet Explorer vem com um controle Active embutido (XmlHttpRequest), que poderia ser usado para fazer uma chamada assíncrona. Mozilla/Firefox contém mecanismos próprios similares, também chamados, convenientemente, de XmlHttpRequest, somente implementados como um objeto nativo. Ambos os mecanismos são similares na forma que você os usa. Isto possibilitou que os desenvolvedores usassem o modelo assíncrono em aplicações que rodam na maioria dos navegadores. Isso tornou, rapidamente, o Ajax bem popular. Nota  Ainda que o uso de XmlHttpRequest, ora como um componente Active ou como um objeto nativo, é de longe, a forma mais popular para

enviar chamadas assíncronas ao servidor, há outras formas. Dois exemplos de outros mecanismos remotos: estão usando um iframe escondido e adicionando dinamicamente uma tag script no cabeçalho do documento.

C apítulo 1    A pr e s e n ta n d o a s A plica ç õ e s d E I n t e r n e t R I C A ( R I A s )

5

Navegador

Atualização

Atualização

Atualização

Resposta

Rede

Processamento no Cliente

Pedido

Pedido

Resposta

Processamento no Cliente

Ação

Ação

Ajax Engine

Atualização

Usuário Interação

Servidor Processamento

Processamento

no Lado Servidor

no Lado Servidor

no Lado Servidor

Evento Externo

Processamento

Tempo Figura 1-3.  O modelo de uma aplicação Ajax de interação.

JavaScript O JavaScript é uma linguagem de script criada por Brendan Ech quando ele estava trabalhando na Netscape. Originalmente, se chamava Mocha e mais tarde LiveScript, mas foi renomeada Javascript por volta de 1995. Ainda que o nome sugira o contrário, a linguagem é bem diferente da linguagem de programação Java, ainda que elas compartilhem, como ancestral comum, a sintaxe do C. O JavaScript foi, provavelmente, nomeado a partir do Java por razões mercadológicas como parte da aliança estratégica entre a Sun Microsystems e a Netscape. Alguns dizem que usaram Java no nome para dar ao JavaScript uma aura de ser a nova linguagem “quente” de programação na web. É por causa do suporte no Netscape que o JavaScript se tornou a linguagem de script com maior suporte entre os navegadores. A Microsoft começou a desenvolver seu próprio dialeto denominado JScript, porém, mais tarde, passou a dar suporte ao JavaScript. Em 1966, JavaScript se submeteu a padronização, resultando nas especificações ECMAScript com o JavaScript como uma das implementações, os outros sendo o ActionScript (muito usado pelo Adobe) e JScript, que ainda é usado para o Active Scripting da Microsoft. O JavaScript é uma linguagem dinâmica, francamente tipada, baseada em protótipos com funções de primeira classe. Suporta a sintaxe da programação C estruturada, inclusive comandos de laço (loops), comandos de switch e assim por diante. Uma exceção é que ele não suporta escopo em nível de bloco. Para ter uma ideia melhor do JavaScript, vamos dar uma olhada na Listagem 1-1, que mostra uma página HTML simples que usa o JavaScript para mostrar ao usuário um alerta com um valor que o usuário forneceu em um campo de entrada. Listagem 1-1.  Exemplo de um JavaScript Embutido em uma Página HMTL JavaScript sample function handleButtonClick() { var input = document.getElementById(‘query’); alert(‘Query: ‘ + input.value); } Query: Show