Desenvolvimento de Aplicações para Plataforma Google Android

Capítulo 5 Desenvolvimento de Aplicações para Plataforma Google Android Fábio de Jesus Lima Gomes, Manoel Taenan Ferreira de Souza, Rafael Madureira Lins de Araújo Abstract Com a evolução da tecnologia móvel, os dispositivos móveis tornaram-se uma importante fonte de transmissão e recepção de informações, gerando a necessidade de sistemas operacionais mais robustos e uma considerável demanda para o desenvolvimento de serviços e aplicações. A plataforma Google Android surgiu para preencher esta lacuna. Dessa forma, este mini-curso pretende disseminar conceitos envolvidos no desenvolvimento de serviços e aplicações para a plataforma Google Android. Também será abordado como aplicações para dispositivos móveis podem consumir serviços web através da arquitetura REST. Resumo With the evolution of mobile technology, mobile devices have become an important source of transmission and reception of information, creating the need for more robust operating systems and a considerable demand for the development of services and applications. The Google Android platform was created in order to fill this gap. Thus, this mini-course aims disseminate concepts about developing services and applications for the Google Android platform. Also we will describe how mobile applications can consume web services via REST architecture. 5.1. Introdução O Google Android OS, também chamado apenas de Android, é um sistema operacional de código aberto para dispositivos móveis e utiliza uma versão modificada do Sistema Operacional Linux. Permite a desenvolvedores criarem aplicações Java que controlam o dispositivo através de bibliotecas desenvolvidas pela Google. O Android também provê uma infra-estrutura robusta de execução de aplicações Java. Apesar de ser recente (seu 100

lançamento foi em 2008), o Android foi adotado rapidamente por diversos fabricantes de dispositivos móveis e atualmente é a plataforma que mais cresce no mundo. Atualmente, a plataforma Google Android é mantida pela OHA (Open Handset Alliance), um grupo formado por mais de 40 empresas que se uniram para inovar e acelerar o desenvolvimento de aplicações e serviços para dispositivos móveis, trazendo aos consumidores uma experiência mais rica em termos de recursos e menos onerosa financeiramente para o mercado. Pode-se dizer que a plataforma Google Android é a primeira plataforma completa, aberta e livre para dispositivos móveis. O Android SDK é o kit de desenvolvimento que disponibiliza as ferramentas e APIs necessárias para desenvolver aplicações para a plataforma Google Android, utilizando a linguagem Java. Este mini-curso visa abordar conceitos envolvidos sobre desenvolvimento de aplicações para a plataforma Google Android, apresentando os principais aspectos do desenvolvimento de aplicações para dispositivos móveis, com enfoque para o desenvolvimento de aplicações que consomem serviços web utilizando a linguagem Java. Pretende-se capacitar os participantes no desenvolvimento de aplicações Java para plataforma Google Android com base no Android SDK e demonstrar a arquitetura REST (Representational State Transfer) de desenvolvimento de aplicações web. O curso procura explorar as funcionalidades dessas tecnologias através do desenvolvimento passo a passo de aplicações-exemplos. 5.2. Arquitetura do Google Android Android é uma pilha de software para dispositivos móveis que inclui sistema operacional, middleware e aplicações-chave. Esta pilha possui 4 níveis (Google, 2011): Figura 5.1 Arquitetura da Plataforma Google Android (Google, 2011) 101

1. LINUX KERNEL: a base da pilha é o kernel. O Google usou a versão 2.6 do Linux para construir o kernel do Android, que inclui serviços essenciais do sistema, tais como, gerenciamento de memória, gerenciamento de processos, gerenciamento de energia, configurações de segurança, configurações de rede e drivers. O kernel também atua como uma camada de abstração entre o hardware do dispositivo e os outros níveis da pilha de software. 2. RUNTIME ANDROID e LIBRARIES: acima do kernel estão as bibliotecas do Android e o android runtime. Android runtime consiste de um conjunto de bibliotecas que fornece a maioria das funcionalidades disponíveis nas principais bibliotecas da linguagem de programação Java e de uma Máquina Virtual Dalvik (DVM). Uma aplicação Android roda em seu próprio processo, com a sua própria instância da máquina virtual Dalvik. Dessa forma, nenhuma aplicação é dependente de outra; se uma aplicação pára, ela não afeta quaisquer outras aplicações executando no dispositivo e isso simplifica o gerenciamento de memória. Dalvik foi escrito de modo que um dispositivo possa executar várias VMs eficientemente. Android possui um conjunto de bibliotecas C/C ++ usado por diversos componentes da plataforma. As principais bibliotecas são listadas abaixo: System C library uma implementação da biblioteca padrão C (libc), derivada do sistema operacional BSD, alterada para dispositivos embarcados baseados no Linux; Media Libraries baseada no OpenCORE da PacketVideo; estas bibliotecas suportam reprodução e gravação de muitos formatos populares de áudio, vídeo e imagem, tais como, MPEG4, H.264, MP3, AAC, AMR, JPG, e PNG. Surface Manager gerencia acesso ao sub-sistema de exibição e compõe as camadas gráficas 2D e 3D para as aplicações. LibWebCore um moderno engine para um navegador web que alimenta o navegador do Android. SGL engine de gráficos 2D. 3D libraries uma implementação baseada nas APIs OpenGL ES 1.0; estas bibliotecas usam aceleração de hardware 3D (quando disponível) ou o software embutido no sistema. FreeType renderizador de bitmap e fontes vetorizadas. SQLite engine leve e poderoso de banco de dados relacional para as aplicações. 3. APPLICATION FRAMEWORK: O próximo nível é o framework de aplicação que consiste nos programas que gerenciam as funções básicas do telefone, tais como, alocação de recursos, aplicações de telefone, mudança entre processos ou programas e informações sobre a localização física do aparelho. Os desenvolvedores de aplicações têm acesso total ao framework de aplicação do Android. Isso possibilita tirar vantagem das capacidades de processamento e do suporte de recursos do Android. 102

4. APPLICATIONS: No topo da pilha estão as aplicações em si. Aqui se encontram as funções básicas do dispositivo, como fazer chamadas telefônicas, acessar o navegador web ou acessar sua lista de contatos. Esta é a camada do usuário comum, que utiliza a interface de usuário. Apenas os programadores do Google, os desenvolvedores de aplicação e os fabricantes de hardware acessam as camadas inferiores da pilha. O Android contém um conjunto de aplicativos, implementados em Java, como um cliente de e-mail, programa para SMS (Short Message Service), calendário, mapas, navegador e gerenciador de contatos. 5.3. Componentes de uma aplicação Android As aplicações Android podem ser divididas em quatro tipos de componentes básicos que são definidos pela própria arquitetura (ABLESON,2007), são eles: 5.3.1. Activities Funcionam como mediadores que definem como as informações serão apresentadas ao usuário, além de controlar o fluxo da aplicação. Elas podem interagir com o usuário e trocar informações com outras activities ou services (MEIER,2009). A maioria do código que escreveremos para uma aplicação Android irá executar no contexto de uma activity. Activities normalmente correspondem a telas: cada activity mostra uma tela para o usuário. Quando esta não está em execução, o sistema operacional pode eliminá-la para liberar memória. 5.3.1.1. Ciclo de vida de uma Activity Ao longo de sua criação até o momento de sua eliminação da memória, uma activity atravessará seis estados, podemos referenciar cada estado pelos métodos: OnCreate É chamado quando a activity é criada. Ela é obrigatória e chamada apenas uma vez, deve referenciar a tela que será apresentada ao usuário. OnStart É chamado quando a activity está ficando visível e já tem uma tela definida. OnResume É chamado quando a activity foi parada temporariamente e está retornando à execução. OnPause É chamado quando a activity está sendo tirada do topo da execução. Geralmente é utilizado para salvar o estado da aplicação. OnStop É chamado quando a activity não está mais visível e está em segundo plano. OnDestroy Executa os últimos processamentos antes da activity ser literalmente encerrada. 103

5.3.2. Services Figura 5.2. Ciclo de vida de uma Activity. São programas que executam em segundo plano. Não interagem diretamente com o usuário e podem ficar executando por tempo indefinido. 5.3.3. Broadcast e Intent Receivers São componentes que ficam aguardando a ocorrência de um determinado evento, podese entender como evento a inicialização do sistema operacional, uma chamada de voz, a chegada de um SMS, um evento disparado por uma aplicação (MEIER,2009). Intents são elementos chave no Android, porque facilitam a criação de novas aplicações a partir de aplicações já existentes. Precisaremos utilizar Intents para interagir com outras aplicações e serviços que proporcionarão informações necessárias para nossa aplicação. 5.3.4. Content Providers São os compartilhadores de conteúdo entre as aplicações, uma aplicação pode requisitar informações de outra, por exemplo, uma aplicação pode receber dados da lista de contatos que é nativa do Android, e com base nesses dados, realizar algum processamento (LECHETA,2010). 104

5.4. Android SDK e seus pacotes para implementação de aplicações O SDK é um conjunto de ferramentas utilizadas para desenvolver aplicações para a plataforma Android. Possui um emulador para simular o dispositivo móvel e uma API completa para a linguagem Java, com todas as classes necessárias para desenvolver as aplicações (BURNETTE, 2008). Existem atualmente três versões do SDK para atender a maior parte dos desenvolvedores: versão para Windows, Linux e Mac OS. O ambiente de desenvolvimento que nos utilizaremos nos exemplos seguintes é composto, além do JDK e Android SDK, pelo Eclipse IDE versão Galileo e o Android Development Plugin (ADT), um plugin que ajudará na integração da IDE com o emulador. Os componentes do ambiente de desenvolvimento podem ser encontrados nos links a seguir: JDK: http://www.oracle.com/technetwork/java/javase/downloads/index.html Android SDK: http://developer.android.com/sdk/ Eclipse IDE: http://www.eclipse.org/downloads/ ADT: http://developer.android.com/sdk/eclipse-adt.html 5.4.1. Conceitos básicos do Android 5.4.1.1 Criando uma Activity A classe android.app.activity é utilizada para criar uma tela na aplicação. Essa tela é composta de vários elementos visuais, os quais no Android são representados pela classe android.view.view (LECHETA, 2010). A classe android.view.view pode representar algo simples como um botão, um checkbox ou imagem, como também pode representar algo complexo como um gerenciador de layout, a qual pode conter várias views aninhadas para organizar na tela. Figura 5.3. Exemplo de uma Activity. O método setcontentview(view) é o que faz a ligação entre a activity e a view e recebe como parâmetro a view que será exibida na tela. 105

5.4.1.2 A classe R A classe R é criada automaticamente pelo ADT e não pode ser alterada manualmente. Nela existem constantes para os recursos do projeto. Cada constante é nomeada com o nome do recurso, que deve ser escrito com letra minúscula e sem espaço, e recebe um valor inteiro. 5.4.1.3 O arquivo AndroidManifest.xml Toda aplicação Android deve ter um arquivo AndroidManifest.xml em seu diretório raiz. Esse arquivo apresenta informações essenciais sobre a aplicação para o sistema operacional, que deve possuir informações do sistema antes que possa executar qualquer solicitação do código do aplicativo (MEDNIEKS,2009). Ele armazena informações como o nome do pacote da aplicação, descreve os componentes da aplicação, determina qual processo da aplicação vai armazenar os componentes, declara de que formas as solicitações devem ter permissões para acessar partes protegidas da API e interagir com outras aplicações. Declara também as permissões que os outros processos serão obrigados a ter, fim de interagir com os componentes da aplicação, enumera classes e perfis e fornece outras informações sobre como a aplicação será executada, declara qual o nível mínimo da API que o aplicativo exige e enumera bibliotecas que estarão relacionadas com a aplicação. Figura 5.4. Exemplo de arquivo AndroidManifest.xml 5.4.1.4 Criação de uma interface visual O Android fornece um sofisticado e poderoso modelo, baseado em componentes, para construir sua interface, baseado no esquema de classes fundamentais: android.view.view e android.view.viewgroup, e inclui também as suas classes filhas chamadas de widgets e layouts respectivamente(lecheta, 2010). Podemos citar alguns exemplos de widgets como Button, TextView, EditText, ListView, CheckBox, RadioButton, Gallery, Spinner, e outros. Podemos citar, também, exemplos de layouts como LinearLayout, FrameLayout, RelativeLayout entre outros. Para exemplificar a criação da interface visual criaremos uma tela de login, a qual conterá os campos de nome de usuário e senha, e um botão para submetê-los. 106

Figura 5.5. Representação gráfica da tela de login. Figura 5.6. Código da tela de login 107

Podemos observar que foram utilizados três tipos de widgets e um layout. Dois TextView que são utilizados para renderizar strings na tela e dois EditText que são caixas para receber texto. Foi utilizado, também, um Button para enviar os dados e um LinearLayout para organizá-los na tela. Podemos observar, também, alguns atributos como o id que serve como identificador de cada componente, o text que tem o funcionamento semelhante ao value do HTML e o atributo password que esconde os caracteres digitados no nosso EditText. 5.4.1.5 O método findviewbyid() Ao construir uma tela usando um arquivo XML de layout, surge a necessidade de recuperar os objetos definidos no arquivo dentro do código-fonte da aplicação para obter seus valores ou definir atributos (LECHETA, 2010). Podemos recuperar um objeto de visão através do seu identificador único (android:id), passando-o como parâmetro no método findviewbyid(id). Esse método recebe o id do componente desejado e retorna uma subclasse de android.view.view, como as classes Button, TextView e EditText. Na figura a seguir é mostrado como recuperar a senha inserida pelo usuário através do método findviewbyid(id) e uma pequena ajuda da classe R. Figura 5.7. Exemplo da utilização do método findviewbyid() 5.4.2 Intent Uma intent representa uma intenção da aplicação em realizar alguma ação. Ela envia uma mensagem ao sistema operacional chamada de broadcast. Ao receber essa mensagem, o sistema operacional tomará as decisões necessárias (LECHETA, 2010). 108

Uma intent é representada pela classe android.content.intent e pode ser utilizada para enviar uma mensagem ao sistema operacional, abrir uma nova tela da aplicação, utilizando o método startactivity(intent), solicitar ao sistema operacional que ligue para determinado número de celular, abrir o browser em um determinado endereço da internet, exibir algum endereço, localização ou rota no Google Maps dentre outros. 5.4.2.1 Navegação entre telas com passagem de parâmetros Existem dois métodos de se iniciar uma nova tela (activity), através dos métodos startactivity(intent) e startactivityforresult(intent,codigo) que apenas inicia uma nova activity ou inicia uma nova activity e cria um vínculo para ser utilizado ao retornar respectivamente (PEREIRA, 2009). Para que o sistema operacional possa reconhecer nossa nova activity, é necessário adicionar seu endereço no arquivo AndroidManifest.xml. Figura 5.8. Trecho do arquivo AndroidManifest.xml que contém a nova activity. Podemos enviar informações para outras telas através de uma intent. Figura 5.9. Exemplo de passagem de parâmetro e troca de tela através de uma intent Podemos observar na figura 5.8, que é criada uma intent com a activity da telaalvo, é passado como parâmetro através do método putextra() o texto contido no EditText referente ao usuário para a próxima tela, e finalmente, a nova activity é iniciada através do método startactivity(intent). 109

Figura 5.10. Código da classe SegundaTela. Observando essa classe, vemos que a intent é capturada através do método getintent() e recebemos o parâmetro do login através do método getstringextra(string). O conteúdo da tela é apenas um TextView com uma mensagem de boas vindas. 5.4.2.2 Intents Nativas do Android Vimos no exemplo anterior que é possível iniciar uma nova activity através das intents. O Android possui alguns tipos de intents pré-definidas que podemos utilizar para enviar mensagens ao SO, porém, algumas delas necessitam de permissões para executar, tais permissões precisam ser registradas no arquivo AndroidManifest.xml (PEREIRA,2009). Várias intents como a ACTION_VIEW, que serve para iniciar o navegador, a ACTION_CALL, que é utilizada para realizar chamadas, a ACTION_PICK, que serve para visualizar todos os contatos, dentre outras, são utilizadas em aplicações Android. A seguir veremos um exemplo de como chamar o navegador através de uma intent pré-definida no Android. Figura 5.11. Exemplo da iniciação do navegador através de uma Intent. O exemplo demonstra a utilização da intent ACTION_VIEW, mas, para usar essa intent é necessária a permissão INTERNET que deve ter sido registrada previamente. Figura 5.12. Inserindo a permissão INTERNET no arquivo AndroidManifest.xml 110

5.4.3 Intent Filter Podemos utilizar intents para enviar mensagens ao sistema operacional, definindo uma ação que identifique essa intent. Então quando a mensagem for enviada ao sistema operacional ela seja identificada por essa ação, e somente uma activity que esteja mapeada para aquela ação será executada (MEDNIEKS, 2009). Esse tipo de rotina é bem prática quando queremos que mais de um programa esteja configurado para receber uma ação (LECHETA, 2010). Para definir essa ação, basta criar uma Intent usando seu construtor, que recebe uma string que identifica a ação, como, por exemplo: Figura 5.13. Exemplo de uma chamada de ação por uma Intent. Logicamente, alguém tem que responder por essa ação. Para isto, precisamos mapear um Intent Filter no arquivo AndroidManifest.xml, para escutar esse chamado e delegar a execução à uma activity. Figura 5.14. Código fonte da classe SegundaTela. 5.4.4 BroadcastReceiver Figura 5.15. Exemplo de mapeamento de uma Intent Filter. A classe BroadcastReceiver é utilizada para responder a determinados eventos enviados por uma intent. Ela sempre é executada em segundo plano durante pouco tempo, normalmente dez segundos. Não deve ter interface gráfica ou interação com o usuário (LECHETA, 2010). 111

É utilizada normalmente para executar algum processamento sem que o usuário perceba, em segundo plano. Assim como uma activity, devemos declará-lo no arquivo AndroidManifest.xml através da tag <receiver>, deve ser declarada, também, um Intent Filter para o broadcast, ou podemos registrá-lo dinâmicamente, utilizando o método registerreceiver(receiver,filtro), que tem como parâmetros uma classe-filha de IntentReceiver e uma instância da classe IntentFilter que possui a configuração da ação e a categoria (LECHETA, 2010). O método para enviar uma mensagem para um broadcast é diferente do utilizado para uma intent que chama uma activity. O método utilizado é o sendbroadcast(intent) que envia uma mensagem para todas as aplicações instaladas no celular. Para implementar um BroadcastReceiver deve-se extender a classe BroadcastReceiver e implementar o método onreceive() que será executado assim que o IntentFilter receber a mensagem. Figura 5.16. Utilizando o método sendbroadcast(intent). 112

Figura 5.17. Exemplo de um BroadcastReceiver. Apenas por motivos didáticos foi utilizado a classe Toast para verificar o funcionamento do BroadcastReceiver. Recomenda-se que não tenha nenhum tipo de interação com o usuário. 5.4.5 Notification Figura 5.18. Exemplo do mapeamento de um BroadcastReceiver. A classe Notification é utilizada para exibir informações ao usuário sem que este seja interrompido se estiver executando alguma atividade. O usuário pode escolher visualizar as informações neste momento, ou depois (LECHETA, 2010). A notificação é exibida na barra de status do celular para chamar a atenção do usuário. Ao ser visualizada, a intent configurada pode uma abrir uma nova activity ou pode ser usada para iniciar um serviço por exemplo (MEIER, 2009). Um exemplo de notificação é a recepção de uma nova SMS, onde usuário pode decidir visualizá-la ou não. Para criar uma notificação é necessário capturar um serviço do Android chamado de NOTIFICATION_SERVICE, será necessário, também utilizar a classe PendingIntent que criará uma intent que ficará pendente até o usuário decidir visualizar a notificação: 113

Figura 5.19. Exemplo da criação de uma notificação. Podemos observar, que o construtor da classe Notification recebe três parâmetros: o ícone que deverá ser exibido, o título da notificação e a hora que aparecerá do lado da notificação. Observamos, também, que deve-se informar através do método setlatesteventinfo, a mensagem que aparecerá na barra de status assim que a notificação for reconhecida pelo serviço de notificações do android, o título da notificação e a intent que deverá ser chamada quando o usuário visualizar a notificação. Figura 5.20. Classe que será instanciada quando a notificação for visualizada. A figura anterior mostra a classe que será instanciada quando o usuário visualizar a notificação. Capturamos o serviço de notificações do android, e pedimos 114

para que a notificação não apareça mais na barra de status através do método cancel(int) que recebe como parâmetro o id da notificação. 5.4.6 Service Têm as mesmas características dos serviços dos sistemas operacionais de computador. São utilizados quando queremos executar algo por tempo indeterminado em segundo plano e que exija um alto consumo de recursos, memória e CPU (LECHETA, 2010). Geralmente são iniciados por um BroadcastReceiver para executar algum processamento demorado, pois um BroadcasReceiver tem um tempo determinado para executar (PEREIRA, 2009). É interessante que os serviços tenham suas próprias threads para que fiquem independentes do programa hospedeiro. Eles também possuem um ciclo de vida próprio, semelhante ao de uma Activity, mas possuem apenas três estágios: o oncreate, onstart e ondestroy, que desempenham o mesmo papel que o de uma Activity. Para iniciar um serviço é necessário criar uma activity que chame o método startservice(intent). Para parar um serviço existem duas maneiras: a primeira é chamar o método stopservice(intent), a mesma intent utilizada para iniciar o serviço deve ser usada para pará-lo, e a segunda forma é o próprio serviço chamar o método stopself(). Figura 5.21. Chamando um serviço. Para implementar um serviço é necessário estender a classe android. 115

Figura 5.22. Exemplo de um serviço. Para exemplificar o funcionamento de um serviço, utilizamos esta classe, que quando iniciada, cria uma série de logs. Podemos observar que mesmo fechando a aplicação que iniciou o serviço, ele continua criando logs até chamar o método stopself(). É necessário mapear o serviço no arquivo AndroidManifest.xml e configurar um IntentFilter com a ação que iremos passar como parâmetro pela nossa Intent. 116

5.4.7 AlarmManager Figura 5.23. Exemplo do mapeamento de um serviço. São eventos agendados no sistema operacional para serem executados no futuro (LECHETA, 2010). É utilizado quando é necessário executar algo uma vez em determinado horário ou ficar repetindo de tempos em tempos. Quando agendados, ficam ativos no sistema até que sejam explicitamente cancelados, ou o sistema for reiniciado. Para agendar um alarme, primeiro temos que definir uma intent com o BroadcastReceiver que irá responder pelo nosso alarme. Depois temos que capturar o serviço do Android responsável pelo gerenciamento dos alarmes, o AlarmManager. Figura 5.24. Agendando um alarme. 117

Figura 5.25. BroadcastReceiver que será chamado pelo nosso alarme. 5.5. Arquitetura REST de desenvolvimento de aplicações Web Vivemos hoje uma febre de Apps pequenos aplicativos auto-contidos que tem uma única função e comumente são interfaces para sistemas Web. A maioria desses aplicativos é extremamente dependente de dados para serem úteis e esses dados podem vir dos mais variados lugares por exemplo, a plataforma Android disponibiliza ao desenvolvedor uma pequena base dados SQLite onde ele pode criar suas tabelas, armazenar e buscar dados, mas cada vez mais esses dados vêm de serviços web. A Web é uma plataforma orientada a recursos. Um Recurso pode ser definido como qualquer coisa que é exposta a Web através de um identificador e que possamos manipular (ler e/ou escrever) (WEBBER; PARASTATIDIS, 2010).. Desde sua formalização REST1 vem sendo um termo e, mais adequadamente, uma arquitetura de software de sistemas Web cada vez mais utilizado, estudado e discutido. Esta arquitetura foi proposta pelo Dr. Roy T. Fielding em 2000 e desde então vem sendo adotada em vários sistemas de grande porte como Twitter, Facebook, Flickr e todas as APIs de serviços públicos do Google como Google Agenda, Google Health, Google Data e Google Maps. Veremos a seguir o que é REST e, em seguida, formas de se trabalhar com REST em Java. 5.5.1 Definição O protocolo HTTP, e consequentemente servidores HTTP, é um protocolo simples e sem muitos recursos. Em sua primeira versão ele apresentou endereçamento e statelessness: duas características de seu projeto que o tornou um avanço perante seus rivais e que ainda o mantém escalável mesmo nos mega-sites de hoje (RICHARDSON; RUBY, 2007). Sistemas com esta arquitetura são sistemas Clientes-Servidores comuns, entretanto suas requisições e respostas são construídas ao redor da transferência da representação de recursos. Recursos são os blocos fundamentais de sistemas baseados na web, ao ponto que a Web é considerada como orientada a recursos (WEBBER; PARASTATIDIS, 2010). A abstração chave de informação do REST são os recursos. Qualquer informação que pode ser nomeada pode ser um recurso: documentos, imagens, informações sobre o tempo, uma pessoa, e assim sucessivamente (FIELDING, 2000). 1 Representational State Transfer Transferência de Estado Representacional 118

Um dos recursos mais comuns da Web são páginas HTML, que em sistemas são comumente a representação de um recurso interno do sistema, por exemplo, uma página de exibição de um vídeo do YouTube é a representação do recurso vídeo do sistema. Um mesmo recurso pode ter várias representações diferentes. Utilizando o exemplo do vídeo do YouTube, uma representação é a página HTML onde é mostrado o vídeo, comentários, etc. outra representação é vista quando o vídeo é incorporado em outra página. Nessa representação vemos apenas um player que carrega o vídeo em questão. Outra representação, um pouco menos conhecida, é a representação em XML2 ou mais recentemente JSON3, ambas tecnologias de transição de dados hierárquicos. Devido a essas características REST também requer que as aplicações façam total distinção entre cliente e servidor através da implementação das seguintes características: 1. Cliente-Servidor: Clientes são separados dos Servidores por uma interface uniforme. Essa divisão faz com que o cliente não se preocupe com, por exemplo, armazenamento de dados ao passo que o servidor não se preocupa com interface com o usuário; 2. Stateless (Sem Estado): A comunicação cliente-servidor ocorre sem que nenhum contexto relativo ao cliente seja armazenado no servidor entre as requisições. Cada requisição de cada cliente contém toda informação necessária para atender aquela requisição e a reposta deve conter toda a informação para satisfazer a requisição; 3. Cache: Como é comum na Web, o cliente pode manter um cache das respostas do servidor, portanto é recomendado que as respostas contenham informações sobre se podem e como deve ser feito o cache a fim de evitar que clientes requisitem um mesmo recurso repetidamente. Um bom cache elimina várias interações clienteservidor desnecessárias o que proporciona escalabilidade e performance; 4. Camadas: Um cliente não pode normalmente distinguir se ele está ou não conectado ao servidor final ou apenas a um intermediário. Um sistema com vários servidores permite o balanceamento de carga, caches compartilhados e ajudam a manter uma boa segurança; 5. Código sob demanda (opcional): Servidores podem ser capazes de estender a funcionalidade de um cliente transferindo lógica para que ele execute. Exemplos disso são componentes compilados como Applets Java ou scripts no lado cliente como JavaScript; 6. Interface uniforme: Todo cliente obedece ao mesmo formato de requisição e recebe o mesmo formato de resposta. 2 3 XML extensible Markup Language Linguagem de marcação extensível. JavaScript Object Notation Notação de Objetos JavaScript. 119

A arquitetura REST está fundamentada sob o protocolo HTTP e seus métodos. Clientes que acessam recursos informando sua intenção através do método que executam sob o recurso. A maioria dos sistemas hoje em dia segue a seguinte convenção de métodos HTTP, concebidos para simular operações de CRUD: GET: Leitura; POST: Escrita; PUT: Alteração ou Atualização; DELETE: Remoção. Muitas aplicações novas estão utilizando os princípios REST a fim de obterem um bom nível de escalabilidade. Normalmente essas aplicações disponibilizam a seus usuários uma API dos métodos REST disponíveis, suas entradas e suas saídas. Para compreender melhor, vejamos a API de um sistema referência em tecnologia REST: o Twitter. O Twitter disponibiliza em seu website uma extensa e detalhada documentação da API de seu sistema4. uma plataforma de apoio aos desenvolvedores que desejam criar clientes para o Twitter com páginas de ajuda onde são descritos os métodos da API, um guia ao desenvolvedor e ferramentas para ajudá-lo. Chamadas a alguns métodos da API podem ser feitas, para testes, através de um navegador web qualquer. Durante a escrita deste texto, a API do Twitter aceita a seguinte chamada: http://api.twitter.com/1/users/show.xml?screen_name=fat. Para chamar este método da API basta abrir esta URL em qualquer navegador web. Ao abrir esta URL em um navegador, o que é feito é uma chamada a API através do método HTTP GET. Chamadas a qualquer API REST na Web são compostas de 3 partes: 1. A URL correspondente ao método da API http://api.twitter.com/1/users/show 2. Os parâmetros da chamada ao método screen_name = fat 3. O método HTTP utilizado para chamada aquela URL Por padrão, toda transação HTTP dos navegadores atuais utiliza o método GET. A URL é uma chamada ao método 1/users/show da API do Twitter. Uma particularidade dessa API é a possibilidade de escolha do formato de representação do recurso: XML ou JSON, representado pela extensão do arquivo na URL. 4 Disponível em http://dev.twitter.com/ - Acesso em 12 outubro 2011 120

5.5.2. REST em Java Em Java chamadas a APIs REST são feitas utilizando chamadas HTTP simples, normalmente com objetos java.net.url e java.net.httpurlconnection. Nos exemplos a seguir utilizaremos a API do Twitter como exemplo. A forma mais simples de se executar uma chamada é a seguinte: String apicall = "<url de chamada a API>"; URL url = new URL(apiCall); HttpURLConnection conn; conn = (HttpURLConnection) url.openconnection(); Ao invocar o método openconnection() uma requisição HTTP GET é feita a URL especificada em apicall. Após essa chamada, é importante verificar o código de resposta dado pelo servidor. Normalmente um código de resposta 200 significa que tudo ocorreu como esperado. Outros códigos de resposta podem ser especificados pela API. if (conn.getresponsecode() == 200) { } // Tudo ocorreu como esperado. Dessa forma podemos tomar alguma providência caso ocorra algum erro, e garantir um bom funcionamento da aplicação. Após a confirmação do sucesso da chamada o próximo passo é ler os dados da resposta do servidor. É necessário um cuidado especial com o tipo de dado esperado pois a resposta da API pode ser uma imagem, ou um documento, ou até mesmo um Stream de dados. Vamos considerar que a resposta a nossa chamada está em formato textual, caso qual podemos utilizar a seguinte técnica para captar o resultado num formato mais cômodo para manipulação: BufferedReader reader = new BufferedReader(new InputStreamReader(conn.getInputStream())); StringBuilder str = new StringBuilder(); String line; while ((line = reader.readline())!= null) { str.append(line); } reader.close(); Após o recebimento da resposta, é uma boa prática sempre fechar a conexão junto ao servidor invocando o método disconnect(): conn.disconnect(); Dessa forma podemos fazer chamadas a quaisquer API REST utilizando Java. 121

5.5.2.1 Interpretando Respostas Em Java podemos quase sempre considerar um recurso disponibilizado pelo servidor com um Objeto. Comumente recebemos respostas em XML o qual é uma serialização de um objeto que está no servidor. Devido a isso um ponto que requer especial atenção é a interpretação das respostas. APIs REST utilizam representações do estado de um recurso (um Objeto) do sistema. Nestes casos a forma mais comum de representação é textual, segundo um padrão determinado pela API, XML ou JSON. Existem várias bibliotecas disponíveis para se trabalhar com os formatos XML e JSON, algumas bastante sofisticadas e simples de usar. Para XML temos, por exemplo, uma biblioteca chamada jdom5 que interpreta XML e dá ao desenvolvedor uma representação do documento XML na forma de um grafo de objetos com uma interface nativa Java que podem ser facilmente percorridos e manipulados. Para JSON há uma biblioteca chamada Gson6 disponibilizada pelo Google que pode transformar Objetos Java em sua representação JSON e vice-versa: Gson gson = new Gson(); String json = gson.tojson(meuobjeto); MeuObjeto obj = gson.fromjson(json, MeuObjeto.class); Através do uso de bibliotecas auxiliares é possível criar objetos concretos Java a partir de representações textuais dos mesmos. A utilização de JSON é recomendada nestes casos pois grande parte dos sistemas REST atuais são voltados para a interatividade entre sistemas de Websites, os quais são em sua maioria feitos utilizando JavaScript, linguagem-mãe da notação JSON e que dá suporte nativo a interpretação e construção de objetos a partir de sua representação textual e vice-versa. Referências bibliográficas ABLESON, W. Frank; Unlocking Android - A Developer s Guide. Ed. Manning, 2007. BURNETTE, Ed.Hello, Android:Introducing Google`s Mobile Development Plataform. Pragmatic Bookshelf, 2008. Google Android. Disponível em <http://developer.android.com/guide/basics/what-isandroid.html>. Acesso em 12 outubro 2011. LECHETA, Ricardo R. Google Android. São Paulo: Novatec, 2010, 2 ª ed. MEDNIEKS, Zigurd; MEIKE, Blake. Desenvolvimento de Aplicações Android. São Paulo: Novatec, 2009, 1ª ed. MEIER, Reto. Professional Android Application Development. Indianapolis: Wiley Publishing, 2009, 1ª. ed. 5 6 http://www.jdom.org/ - Acesso em 12 outubro 2011 http://code.google.com/p/google-gson/ - Acesso em 12 outubro 2011 122

PEREIRA, Lúcio C. Oliva. Android para Desenvolvedores. São Paulo: Brasport, 2009, 1ª ed. WEBBER, Jim; PARASTATIDIS, Savas; ROBINSON Ian. REST in Practice: Hypermidia and Systems Architecture. O Reilly Media, 2010. RICHARDSON, Leonard; RUBY Sam. RESTful web services. O Reilly Media, 2007. FIELDING, Roy; Architectural Styles and the Design of Network-based Software Architectures. Dissertação de Doutorado, University of California, 2000. 123