Eduardo Cereto Carvalho. Rich Internet Applications com clientes offline utilizando Gears

Transcrição

1 Eduardo Cereto Carvalho Rich Internet Applications com clientes offline utilizando Gears Itatiba - São Paulo - Brasil Junho de 2009

2 Eduardo Cereto Carvalho Rich Internet Applications com clientes offline utilizando Gears Monografia, apresentada à disciplina Trabalho de Conclusão de Curso II do curso de Engenharia da Computação da Universidade São Francisco, sob a orientação do Prof. Rodrigo Chavez M. do Prado, como exigência parcial para conclusão do curso de graduação. Orientador: Rodrigo Chavez M. do Prado GRADUAÇÃO EM ENGENHARIA DA COMPUTAÇÃO UNIVERSIDADE SÃO FRANCISCO Itatiba - São Paulo - Brasil Junho de 2009

3 i Sumário Lista de Figuras p. iii Resumo p. iv Abstract p. v 1 INTRODUÇÃO p Objetivos p Objetivos Específicos p. 3 2 ASPECTOS TEÓRICOS p Evolução das Aplicações Web p Páginas Estáticas p Páginas com Conteúdo Multimídia p Aplicações Ricas da Internet p Gears p HTML p Javascript p Ajax e DOM p Gears p Módulos do Gears p Arquitetura de Sistemas Baseados em Gears p METODOLOGIA p. 14

4 ii 3.1 Aplicação de anotações p Aplicação em Django p Estrutura Básica de Sistemas Django p Implementando Ajax p Implementação do Gears p Implementação Modal ou Amodal p Conteúdo Estático p Identificando Estado Online/Offline p Camada de Dados p Sincronização p CONCLUSÃO p Análise da Arquitetura Proposta p Contribuições p Dificuldades Encontradas p Propostas de Extensão p. 29 Referências Bibliográficas p. 30 Apêndice A -- Aplicação em Django utilizando Gears p. 31 A.1 Interface p. 31 A.2 Arquivos p. 33 A.2.1 Django p. 34 A.2.2 Gears p. 36

5 iii Lista de Figuras 1 Arquitetura tradicional de aplicações Web p Diagrama de sequência tradicional para aplicações Web p Arquitetura proposta pelo Gears p Diagrama de sequência para aplicações Web baseadas em Gears p Confirmação para permitir que a aplicação use o Gears para guardar dados.. p Tela listando todas as notas p Tela mostrando uma determinada nota p. 32

6 iv Resumo Aplicações Ricas da Internet é o nome dado às aplicações Web que fazem uso pesado de Javascript para implementar uma interface dinâmica provendo uma experiência similar a das aplicações desktop convencionais. Este trabalho mostra um pouco da história das aplicações Web, e especula sobre o futuro, fazendo um estudo de tecnologias emergentes como o Gears que trazem novas possibilidades a essa plataforma.

7 v Abstract Rich Internet Applications is the name for the Web applications that make heavy use of Javascript to implement dynamic interfaces providing a user experience similar to a regular Desktop Application. This work shows the history of Web applications, and discusses about the future of the Web as an application platform. Also it explores emerging technologies such as Gears that bring new features to this platform.

8 1 1 INTRODUÇÃO Nos últimos anos pudemos vivenciar a popularização de hardware e Internet em todo o mundo. É comum hoje em dia o indivíduo ter um computador desktop em casa, um notebook para o trabalho e mais aquele computador da namorada que ele usa nos finais de semana. Seus arquivos acabam espalhados em diversos computadores e pen drives. Alguém distraído pode facilmente se perder em meio às diferentes versões de arquivos que vão sendo criadas ao longo do tempo. Agora imagine fazer backup de tudo isso de uma maneira organizada. Pode-se pensar em muitas soluções para estes problemas, dentre elas: criar um servidor FTP em um servidor pago para centralizar tudo, usar um pen drive para ter mobilidade e manter backups nos diversos computadores ou ainda criar um elegante sistema de versões mantendo repositórios distintos que iriam sendo mesclados usando uma ferramenta de controle de versões como o GIT. Cada uma dessas soluções tem um problema, seja ele um ponto único de falha, um custo monetário mensal ou um grau de complexidade elevado. Mas com certeza nenhuma delas é uma solução trivial o suficiente para ser amplamente utilizada pelo usuário final. A computação nas nuvens [Miller 2008] surge para resolver este problema. Esse novo conceito de computação propõe que todos os dados e, às vezes, até mesmo as aplicações fiquem na Internet. As empresas como o Google começam a oferecer muitos Giga Bytes grátis para que o usuário possa guardar seus s no Gmail ou documentos no GoogleDocs. Esses são dois exemplos onde tanto os dados quanto a aplicação estão nas nuvens, ou seja, nos servidores do Google. Tudo é facilmente acessível de um navegador, onde quer que o usuário esteja. É fácil, é confiável, é seguro e é muito funcional. Com a disseminação da computação nas nuvens o computador pessoal deixou de rodar as aplicações e guardar os dados passando a ser apenas uma janela para a Internet. Na prática só se precisa de um Sistema Operacional (SO) e um navegador para ter acesso a um mundo de aplicações como editores de imagem, planilhas eletrônicas, editores de texto, , etc. As aplicações desktop ficaram um tanto ameaçadas porque é improvável que elas consigam oferecer em curto prazo as vantagens da computação nas nuvens. Porém as aplicações na Internet

9 2 têm a desvantagem de estar atreladas ao navegador e por isso ter certas limitações. Volta-se a era dos terminais burros e mainframes, com os dados e aplicações centralizadas na Internet e os computadores fazendo o papel dos terminais burros. Os computadores de hoje são muito superiores, em termos de recursos, aos terminais burros de antigamente, porém esses recursos são muito mal utilizados nas aplicações Web. A falta de acesso direto ao SO não permite que as aplicações acessem o sistema de arquivos ou façam algum processamento mais complexo em paralelo. Todas estas aplicações estão presas ao protocolo HTTP que é simples e sem estado [Tanenbaum e Steen 2007] além de linguagens script para processamento client side muito lentas se comparado a uma biblioteca nativa. Caso o usuário esteja em um local sem Internet todos os seus documentos estão inacessíveis e seu computador passa a ser um peso de papel. Além disso a questão da usabilidade é importante já que as interfaces das aplicações Web são diferentes das interfaces de programas desktop equivalentes, o usuário pode sentir dificuldade em se acostumar ao novo ambiente, o que pode gerar uma queda de produtividade expressiva [Krug 2005]. Algumas iniciativas vêm sendo tomadas para integrar as aplicações Web ao desktop a fim de eliminar ou reduzir estas desvantagens das aplicações Web. Algumas empresas lançaram seus produtos em caráter experimental usando suas próprias abordagens para o problema. A Adobe criou o AIR que permite criar aplicações Web em Flash e ActionScript que rodam como se fossem aplicações nativas, se aproveitando de recursos como aceleração 3D enquanto o Google, com o seu Gears, teve uma abordagem diferente privilegiando a possibilidade de guardar arquivos no lado do cliente e fazer processamento Javascript em paralelo. A integração tem um papel tanto de usabilidade, trazendo transparência no acesso à aplicação Web, quanto em termos de funções, já que as aplicações desktop não estão presas ao navegador especificamente. Por isso tem mais liberdade de acesso aos recursos da máquina.

10 3 1.1 Objetivos O objetivo deste documento é fazer uma análise da evolução das aplicações Web e como o Gears pode resolver limitações desta plataforma, introduzindo funcionalidades novas Objetivos Específicos Usar o Gears para contornar limitações das aplicações Web. Mostrar como o uso de um framework forte facilita a criação de aplicações mais ricas. Estudar os problemas mais comuns na implementação do Gears.

11 4 2 ASPECTOS TEÓRICOS 2.1 Evolução das Aplicações Web De maneira geral a evolução das aplicações Web pode ser definida em 3 fases distintas [Taivalsaari e Ingalls 2008]. Páginas "clássicas", apenas com texto e imagens estáticas. Páginas multimídia, com animações e conteúdo multimídia com o uso de plugins. Rich Internet Applications ou Aplicações Ricas da Internet Páginas Estáticas Nos primórdios a Web era usada para manter arquivos HTML estáticos que possuíam links entre eles. Era como um livro gigantesco, no qual o usuário tinha a opção de pular direto para a seção que mais lhe interessava com facilidade. Este modelo foi se modernizando e as páginas começaram a se tornar dinâmicas. Linguagens simples eram usadas para gerar as páginas antes estáticas. Lentamente foram surgindo linguagens e frameworks focados na Web e a arquitetura dos sites foi se tornando cada vez mais complexa Páginas com Conteúdo Multimídia Mesmo com as páginas sendo geradas dinamicamente a interface do usuário ainda era estática. O usuário clicava num link e isso acarretava num recarregamento da página. Com o tempo foi surgindo a necessidade de adicionar dinamismo a interface do usuário. Os Java applets e o Flash deram essa possibilidade ao desenvolvedor. Os sites podiam ser melhor customizados. Animações, som e vídeo abriam um novo leque de possibilidades para

12 5 os webdesigners. Este modelo exigia que o usuário instalasse um plugin proprietário no navegador, caso contrário este não conseguiria acessar o conteúdo. Porém não era mais preciso lidar com problemas de incompatibilidade entre os navegadores, visto que todos usavam o mesmo plugin. Essa metodologia trouxe novos problemas. O conteúdo em Flash, não era indexado pelos mecanismos de busca, o que logo se tornou um grande problema a medida que os mecanismos de busca se estabeleceram como a principal porta de entrada para a Web. Além disso uma falta de padronização de interface trouxe dificuldades de usabilidade e acessibilidade. Cada desenvolvedor criava interfaces ricas diferenciadas e que o usuário não reconhecia de imediato [Krug 2005] Aplicações Ricas da Internet As Aplicações Ricas da Internet começaram a fazer uso mais intensivo das linguagens e frameworks modernos. Além disso houve o aparecimento do Ajax. Ajax (Asynchronous Javascript and XML) é um conjunto de técnicas para alterar o conteúdo de uma página Web depois dela ter sido carregada. Na prática ela permite que apenas uma parte da página seja atualizada ao invés de fazer um novo carregamento. Por ser assíncrona essa técnica permite que o usuário interaja com a página enquanto as informações são carregadas. Esta funcionalidade existe nos navegadores desde o ano 2000, mas o termo Ajax surgiu apenas em 2005 quando a tecnologia foi popularizada. O Ajax trouxe um dinamismo novo às antigas páginas estáticas melhorando a experiência do usuário drasticamente e permitindo aos desenvolvedores reinventar a Web como uma plataforma para o desenvolvimento de aplicações. O Flash deixou de ser a melhor opção para gerar interfaces ricas. E foi lentamente, sendo rebaixada para a categoria de mídia player para sites. Sites como o Youtube usam o Flash apenas para exibir vídeos e áudio, enquanto que o Ajax predomina na interface Gears As aplicações Web ficam centralizadas na nuvem. Isso significa que todos os códigos, arquivos e dados ficam em servidores e não na máquina cliente, que serve apenas como uma janela para enxergar essas aplicações.

13 6 Antes da aparição do Gears não existia uma maneira de guardar estes dados e arquivos. Os cookies podem guardar apenas uma quantidade limitada de dados, e são geralmente usados para manter sessões de usuários, provendo uma funcionalidade não inclusa no HTTP. Não existe uma maneira de guardar dados relacionais como os que são guardados nos bancos de dados do lado do servidor. Com o Gears o desenvolvedor tem uma nova opção. Pode armazenar dados no computador do usuário em um banco de dados local implementado dentro do navegador na forma de uma extensão. Isso cria um novo precedente no desenvolvimento de aplicações Web. Pode-se criar aplicações Web seguras que nunca enviam os dados para a nuvem, ou acelerar aplicações existentes trazendo os dados todos para o lado do cliente. Bem como tornar aplicações antes apenas acessíveis através da Internet completamente offline. Aplicações Web contruídas desta forma podem deixar de ser do tipo thin-client/fat-server e passar a ser fat-client/thin-server. Exatamente como aplicações desktop tradicionais HTML5 A nova especificação do HTML, prevista para ser finalizada em 2010, inclui algumas funcionalidades análogas as providas pelo Gears. Como será uma funcionalidade padrão do navegador pode-se antecipar que será utilizada por muitos desenvolvedores a medida que os usuários começam a utilizar os navegadores que implementam o HTML5. Além de contar com a funcionalidade de guardar dados localmente o HTML provê tags multimídia para exibir videos ou sons, e uma API Javascript para controlar essas funcionalidades. O Objetivo do HTML5 é introduzir funcionalidades antes providas apenas por extensões e que provaram ser importantes para a construção de aplicações mais ricas baseadas na Web. O Gears provê hoje a habilidade de escrever aplicações que usam as algumas funcionalidades do HTML5 antes que este seja liberado. O Google anunciou recentemente uma camada de abstração que permite o uso tanto do Gears como do HTML5, caso este esteja disponível, através da mesma interface [Google 2009].

14 7 2.2 Javascript O Javascript é um dialeto da especificação ECMAScript e é hoje a linguagem mais utilizada para fazer programação client side. Por ser a única linguagem amplamente implementada por todos os grandes navegadores, ela não tem muita concorrência. A programação client side foi por muito tempo chamada de DHTML ou Dynamic HTML, pois a maior utilidade para o Javascript era adicionar dinamismo ao HTML. Este dinamismo, era geralmente uma questão visual e não interferia em nada com o funcionamento das aplicações. Uma das funcionalidade mais utilizada era para prover validação a formulários. Com a popularização do Ajax o Javascript tornou-se parte integrante das aplicações. Uma vez que a lógica das aplicações começou a ser escrita no lado do cliente a linguagem precisou evoluir para suprir as necessidades dos desenvolvedores. Hoje o Javascript é uma linguagem poderosa orientada a objetos e que faz uso extensivo de eventos para capturar a interação do usuário com a página. É importante que o desenvolvedor tenha um bom domínio dessas funcionalidades na hora de implementar grandes aplicações, criando bibliotecas reutilizáveis e simples de manter [Keith 2005] Ajax e DOM O DOM ou Document Object Model, é uma representação em árvore da estrutura HTML de uma página Web. O DOM permite interações como consulta, adição, remoção ou alterações dos nós desta árvore. O Javascript possui uma interface para uso do DOM permitindo alteração dinâmica [Keith 2005]. O uso em conjunto do DOM e do Ajax é o que permite o carregamento de informação adicionais dentro de uma página sem recarregar todo o conteúdo novamente. Cada navegador implementa o Javascript em cima das especificação ECMAScript. Porém as vezes há diferenças entre as implementações. Essas diferenças entre os navegadores sempre foram uma dor de cabeça para os desenvolvedores. A medida que as aplicações crescem, e o código Javascript cresce fica mais difícil encontrar bugs e essa diferença entre os navegadores não ajuda em nada os desenvolvedores. Existem bibliotecas Javascript que padronizam a interface de comandos Ajax e para interação com o DOM. Essas bibliotecas resolvem problemas como incompatibilidades com navegadores e deixa tempo para o programador lidar com seus próprios bugs. Dentre as bibliotecas

15 8 mais utilizadas estão o jquery, Prototype e Dojo. As Aplicações Ricas de Internet geralmente fazem uso constante do DOM e Ajax, e por este motivo é comum o uso de alguma destas bibliotecas.

16 9 2.3 Gears O Gears é um projeto de código livre que possibilita a construção de aplicações Web mais poderosas e integradas ao desktop, as chamadas Rich Internet Applications. O Gears foi idealizado pelo Google e lançado em maio de 2007 [Gears API 2008], atualmente está em sua versão e é desenvolvido por funcionários do Google e membros voluntários de uma comunidade de desenvolvedores que se formou ao redor do projeto. O uso mais comum para Gears é fazer com que aplicações Web, ou pelo menos parte delas, fiquem acessíveis mesmo que não haja acesso a Internet [Kilani 2007], ou para acelerar o funcionamento da aplicação para que ela fique o mais parecido possível com o funcionamento de uma aplicação desktop. Atualmente as plataformas suportadas são: Windows XP/Vista, Windows Mobile, Mac, Android e Linux. O Gears é implementado como um extensão para os navegadores Firefox, Internet Explorer, Safari ou Chrome. O seu trabalho é fazer uma ponte entre a aplicação Web e o SO, fornecendo os recursos do SO para a aplicação através de uma API em Javascript. Entre os sistemas que já se beneficiam do Google Gears estão diversas aplicações do Google, MySpace, Zoho, Remember the Milk [Kilani 2007], entre outras.

17 Módulos do Gears O Gears é um sistema modular e a idéia é que no futuro mais e mais módulos sejam adicionados permitindo flexibilidade enquanto mantém o core do Gears bem leve. Dentre os módulos atualmente disponíveis estão: Database Provê um banco de dados local no cliente para guardar dados e recuperá-los, possibilitando que esses dados possam ser utilizados mesmo sem que haja conexão com a Internet. No Gears esta camada faz uso do SQLite, um banco de dados open source pequeno mas com muitas funcionalidades. Desktop Fornece acesso ao desktop como por exemplo a possibilidade de criar ícones na máquina cliente facilitando o acesso a aplicação Web e tornando-a mais próxima de aplicações locais. Geolocation Permite que a aplicação Web acesse dispositivos da máquina cliente que informam a localização do usuário como um módulo GPS. Esse recurso é utilizado por exemplo em uma aplicação de mapas rodando em um celular para poder localizar a posição exata em que o usuário se encontra em um mapa. LocalServer Permite que requisições HTTP que normalmente seriam enviadas pela Internet para um servidor remoto, sejam respondidas pela mesma máquina cliente num servidor local. Este recurso acelera o funcionamento de uma aplicação Web e inclusive permite que uma certa aplicação funcione sem acesso a Internet, e conseqüentemente ao seu servidor. Dentro do LocalServer existem ResourceStores que são utilizados para guardar conteúdo estático. WorkerPool Fornece recursos para fazer processamento Javascript em paralelo para evitar que um script complexo interrompa a fluidez da aplicação Arquitetura de Sistemas Baseados em Gears Como regra geral as aplicações Web são aplicações distribuídas do tipo fat server/thin client [Tanenbaum e Steen 2007], uma vez que o cliente ou browser é responsável apenas por renderizar a interface de usuário como mostra a Figura 1. Neste modelo cada vez que o usuário realiza qualquer interação com a aplicação é feita uma requisição ao servidor e este retorna uma página HTML que representa um snapshot do sistema como ilustrado na Figura 2.

18 11 Figura 1: Arquitetura tradicional de aplicações Web Figura 2: Diagrama de sequência tradicional para aplicações Web

19 12 Figura 3: Arquitetura proposta pelo Gears O Gears propõe uma arquitetura diferente [Gears API 2008]. Através dos módulos Local- Server e Database, descritos na seção 2.3.1, o Gears tem o poder de prover páginas localmente sem precisar contactar o servidor. Isso agiliza as chamadas e possibilita o uso das aplicações mesmo sem uma conexão a Internet. Nessa arquitetura as requisições passam primeiramente por um data switch que irá identificar se os dados devem ser requisitados para o servidor remoto ou para o servidor local. Caso a requisição vá para o servidor remoto o data switch encaminha a requisição para a camada de dados remotos, que por sua vez implementa a API para recuperar os dados remotamente. Caso a requisição seja encaminhada para a camada de dados local, os dados serão recuperados do banco de dados interno do Gears. Existe ainda uma camada opcional de sincronização responsável por sincronizar os dados do banco de dados local com os dados do servidor remoto, essa sincronização normalmente é feita por um Worker Pool sendo assim executado em segundo plano. Esta arquitetura está ilustrada na Figura 3. Na arquitetura do Gears nem sempre as requisições precisam passar pelo servidor, vide Figura 4. Isto torna o processo todo bem mais rápido já que não depende da conexão com a Internet. O próprio Gears trata de encaminhar as requisições que não podem ser feitas localmente e sincronizar os dados remotos com os dados locais.

20 Figura 4: Diagrama de sequência para aplicações Web baseadas em Gears 13

21 14 3 METODOLOGIA Este capítulo mostra os passos principais no desenvolvimento de uma aplicação de anotações em Django que faz uso do Gears. 3.1 Aplicação de anotações A aplicação que foi desenvolvida é uma aplicação simples usada como base para implementar o Gears utilizando o Django como framework do lado do servidor. Dentre as características da aplicação podemos citar: Criação de anotações com título e conteúdo. Possibilidade de visualizar as anotações mesmo sem acesso a Internet. Possibilidade de criar anotações mesmo sem acesso a Internet. Sincronização de anotações enquanto a aplicação está online, para enviar ao servidor as anotações criadas em modo offline. 3.2 Aplicação em Django O Django é um framework de código livre de alto nível que encoraja o desenvolvimento rápido de aplicações Web com design limpo e pragmático utilizando a linguagem Python. A linguagem Python por sua vez tem como principais características a rápida prototipação e o fato de ter uma biblioteca básica muito completa. O framework Django se baseia no design pattern MVC (Model View Controller) que propõe uma divisão clara entre as camadas de modelo, visão e controle (representação de dados, interface com usuário e lógica de negócio, respectivamente) da aplicação. Esta divisão facilita

22 15 a manutenção dos sistemas e a independência das camadas entre si e torna fácil a reestruturação completa de uma dessas camadas com poucas ou nenhuma modificação nas outras camadas. Os sistemas em Django são geralmente divididos em diversas aplicações Django. Cada aplicação implementa uma ferramenta específica e estas são plugáveis no sistema como um todo. Elas podem interagir entre si mas há uma separação clara de código. Este modelo mais uma vez facilita a manutenção dos sistemas e estimula o reaproveitamento de código de maneira muito prática Estrutura Básica de Sistemas Django Esta seção visa exemplificar a estrutura geral de uma aplicação Django e como os diferentes aplicativos são organizados e reutilizados. Bem como os pontos importantes para criar aplicações em Ajax com Django. Este trabalho não pretende documentar todos os passos envolvidos no desenvolvimento de aplicações Django. Uma análise mais detalhada pode ser encontrada na bibliografia [Holovaty e Kaplan-Moss 2008] ou na home page do projeto Django 1. Após usar o comando python django-admin.py startproject project, o Django cria uma pasta project com a seguinte estrutura. project/ -- init.py -- manage.py -- settings.py -- urls.py O arquivo settings.py possui configurações diversas como informações do banco de dados, diretórios com templates, aplicações Django instaladas, entre outros. O arquivo urls.py possui o mapeamento de urls para views, em outras palavras indica qual função irá ser executada quando cada url for acessada. Já o arquivo manage.py disponibiliza uma extensa coleção de scripts que gerenciam e automatizam a administração do sistema, pode-se usá-lo para criar 1

23 16 uma nova aplicação Django. $ python manage.py startapp notes $ ls project/ -- init.py -- notes -- init.py -- models.py -- views.py -- manage.py -- settings.py -- urls.py Neste momento é criada uma pasta notes que irá agrupar os arquivos referentes a este aplicativo e nele já existem os arquivos models.py e views.py que devem ser reescritos para conter a descrição dos dados e lógica de negócio. O código utilizado neste documento pode ser encontrado no Apêndice A. Após escrever estas duas camadas o aplicativo pode ser plugado alterando a seguinte sessão no arquivo settings.py. INSTALLED_APPS = ( django.contrib.auth, django.contrib.contenttypes, django.contrib.sessions, django.contrib.sites, project.notes, ) Desta forma o aplicativo notes é plugado no sistema. É perceptível que o Django já vem com alguns aplicativos habilitados por padrão como por exemplo o django.contrib.auth que é responsável por gerenciar usuários do sistema. Uma vez que a maioria dos sistemas Web tem usuários, é natural que o Django já venha com esta aplicação, seguindo o modelo all under the hood do Python. Claro que esta aplicação pode ser desligada facilmente desabilitando o suporte a usuários e permissões.

24 17 Após plugar a aplicação, pode-se invocar o comando python manage.py syncdb para que o Django crie no banco de dados as tabelas que refletem os modelos definidos no arquivo models.py. O Django provê uma interface orientada a objeto para acesso aos dados através da camada de modelos. Desse modo não é preciso lidar com queries SQL, o que facilita o desenvolvimento e cria uma independência do DBMS Implementando Ajax Uma boa prática no desenvolvimento de aplicações com Ajax, é se certificar de que a aplicação continuará funcionando corretamente mesmo sem o Javascript [Keith 2005]. Uma estratégia para atingir este objetivo é seguir os seguintes passos: 1. Construa uma aplicação sem Javascript utilizando links e formulários em HTML puro e crie a lógia no servidor para responder a estas requisições. 2. Depois adicione Javascript para interceptar essas chamadas e submissões de formulário realizando-as por Ajax e atualizando apenas parte da página. Desta forma é fácil criar aplicações Ajax que são compatíveis com navegadores sem Javascript, ou que continuem funcionando caso haja algum erro de Javascript. A lógica em Javascript usada para interceptar as requisições na aplicação anotações, pode ser encontrada no conteúdo do arquivo notes.js, na página 42 do apêndice A.2.2. Após implementar a lógica para interceptar essas requisições em Javascript é importante certificar-se que o servidor não irá responder da mesma forma as requisições simples e as requisições em Ajax. Felizmente o Django provê uma maneira simples de identificar a origem da requisição através da função request.is_ajax() dentro de uma view. Isso é possível graças ao jquery que insere um cabeçalho a mais na requisição HTTP facilitando sua identificação. No caso de a requisição ser feita via Ajax, a view não precisa retornar a página completa, apenas os dados que serão inseridos dentro da página. Estes dados podem ser retornados como HTML, texto puro, XML ou Json. O Json tem a vantagem de ser um formato compatível com um objeto Javascript e devido a isso o trabalho de extrair os dados se torna mais simples. 2 Data Base Management System: Sistema gerenciador de bancos de dados

25 18 Neste exemplo utilizamos o Django para listar todas as notas, gerar Json caso a requisição seja feita via Ajax e renderizar a página completa caso seja uma requisição normal. def note_list(request): n = Note.objects.all() form = NoteForm() if request.is_ajax(): response = HttpResponse(mimetype="application/json") json_serializer = serializers.get_serializer("json")() json_serializer.serialize(n, ensure_ascii=false, stream=response) return response else: return render_to_response( notes/note_list.html, { object_list : n, form : form, context_instance=requestcontext(request))

26 Implementação do Gears O Gears é flexível e a maneira como o desenvolvedor vai implementa-lo depende das necessidades da aplicação e da dificuldade de implementação. O desenvolvedor deve ponderar a quantidade de trabalho a ser realizado e o benefício para o usuário final. Na maioria das vezes não faz sentido fazer com que toda aplicação esteja disponível offline [Gears FAQ 2008]. A medida que se acrescentam funcionalidades offline se torna necessário um mecanismo de sincronização. Este provavelmente é o momento mais complexo e sujeito a erros na implementação do Gears. Para inicializar o Gears sempre se deve usar o arquivo gears_init.js que o Google disponibiliza. Este script torna disponível a variável global google dentro do Javascript caso o Gears esteja instalado. Com isso podemos redirecionar o usuário para uma página de instalação caso o Gears não esteja instalado. if (!window.google!google.gears) { location.href = + message=baixe o Google Gears para Continuar + &return= ; Uma vez que o Gears esteja instalado é exibido para o usuário um diálogo de segurança como o ilustrado na figura 5. Figura 5: Confirmação para permitir que a aplicação use o Gears para guardar dados