Artigo Webmobile 3 - Usando conexões HTTP em um jogo J2ME/MIDP

A comunicação móvel é fundamental para a vida moderna. Independente do lugar em que nos encontramos, podemos ver o horário do cinema, consultar nosso saldo bancário, verificar a cotação de moedas e bolsas de valores, enviar e receber e-mails, navegar pela web (de forma restrita na maioria dos dispositivos, mas já é um começo).

Tendo isso em mente, iremos abordar a terceira parte de uma série de artigos que começou na primeira edição da WebMobile com o artigo: “Desenvolvimento de jogos J2ME/MIDP para celular”, onde foram apresentados conceitos básicos sobre MIDP e J2ME e o processo de elaboração de jogos. Para demonstrar os conceitos apresentados, os autores Eduardo Peixoto e Renato Iida criaram o jogo Mobile Invaders.

A segunda edição da WebMobile apresentou a segunda parte desta série: “Incrementando um jogo J2ME/MIDP usando RMS: Uma introdução ao Record Management System (RMS)” no qual o autor, Fábio Mesquita, acrescentou novas funcionalidades, tais como fases com nível de dificuldade crescente, pontuação e armazenamento local de pontos; demonstrando os conceitos relacionados a RMS.

Para aumentar a atratividade e a vida útil do jogo, vamos modificar este jogo para estimular a competitividade entre os jogadores por meio do registro on-line dos recordes.

Neste artigo você aprenderá a programar essa nova funcionalidade. Além disso, o artigo discute como aperfeiçoar a transmissão de dados pela internet, e para isso, serão abordados alguns conceitos teóricos, como transmissão de dados usando GPRS, otimização da quantidade de dados a ser transmitida, protocolo HTTP, Generic Connection Framework (GCF) e Servlets. Estes conceitos serão necessários para compreender o que está ocorrendo no servidor e no celular quando enviamos um recorde ao servidor responsável pelo seu armazenamento e gerenciamento, e como isto se reflete na implementação deste tipo de aplicação em dispositivos móveis.

Após realizar toda essa etapa móvel, você aprenderá a criar um servlet para receber os recordes e deixá-los disponíveis para consulta no lado do servidor.

Com isto, esperamos que ao final do artigo você seja capaz de criar um serviço com um cliente móvel acessando um servidor usando conexões HTTP.

Transmissão de dados pela internet

Dispositivos móveis geralmente possuem conexão limitada. O tipo de serviço mais comum em aparelhos GSM é o GPRS – General Packet Radio Service – com taxa de transferência máxima teórica de 171,2 kbps. Entretanto, esse máximo teórico é muito caro para as operadoras de telefonia móvel e geralmente não é suportado pelos aparelhos disponíveis no mercado. O que se consegue na prática costuma ser em torno de 21,5 kbps. Alem disso, o tempo para iniciar uma sessão GPRS e realizar a primeira entrega de dados pode durar entre 2 e 15 segundos, dependendo do tráfego aéreo de dados e de voz, e também da qualidade dos equipamentos das operadoras.

Outra limitação importante a ser destacada é o custo pago pelo usuário final para utilizar os serviços de envio e recebimento dos dados através de GPRS. As operadoras costumam cobrar por cada kilobyte enviado/recebido um valor entre R$ 0,005 e R$ 0,02, ou seja, algumas operadoras chegam a oferecer 2 KB por centavo.

Portanto, devemos nos preocupar com a quantidade de conexões que o celular irá realizar, bem como a quantidade de dados que vamos enviar, pois isso reflete diretamente na interatividade do aplicativo e no custo para o usuário final.

Otimização da quantidade de dados para o envio

Existe uma relação de troca entre a eficiência na quantidade de dados e a interoperabilidade da aplicação, ou seja, quanto mais interoperabilidade na representação dos dados desejamos, menos eficiência na transmissão dos dados obteremos. Isso ocorre principalmente, pois a quantidade de dados a serem transmitidos aumenta à medida que aumentamos a sua interoperabilidade. Com isso, se compararmos um padrão de comunicação de alta interoperabilidade com um padrão mais simples, percebemos grande diferença na eficiência na transmissão de dados, como veremos com mais detalhes a seguir.

A Listagem 1 mostra a representação de um recorde para o jogo Mobile Invaders no formato XML – mais complexo – que  possui 65 bytes de tamanho para envio.

O gráfico da Figura 1 mostra que devemos escolher o formato de nível mais simples, isto é, aquele em que cabem mais dados por byte.

Figura 1. Eficiência dos padrões de comunicação.

No jogo que estamos desenvolvendo, escolhemos a opção de baixo nível devido à sua eficiência, na qual a pontuação é armazenada em 32 bits, que corresponde ao tamanho de um int na linguagem Java. O nome é armazenado em uma String codificada em UTF-8, isso significa que usaremos no máximo 7 bytes; 2 bytes indicando o tamanho da string e 5 bytes para o máximo de 5 letras definido no jogo. A Figura 2 mostra a codificação UTF para os caracteres possíveis no jogo.

Figura 2. Codificação UTF-8 com 1 byte por caractere.

Mesmo sabendo que os padrões de baixo nível são mais eficientes, às vezes temos de usar padrões mais interoperáveis e complexos. É o caso de aplicações móveis que desejam usar web services. Nesse caso é necessário enviar os dados em um formato que o web service saiba interpretar, como o XML.

Existem casos em que se fosse adotado um padrão complexo, o celular passaria a ter uma eficiência intolerável, ou seja, a maioria dos usuários cancelaria a operação antes dela terminar. Para esses casos podemos adotar uma solução envolvendo um middleware (veja Nota 1). Este serviria de intermediário entre o celular e o serviço a ser acessado. A responsabilidade por processamentos mais complexos é transferida do dispositivo móvel para o middleware, que retorna informações simplificadas para o celular.

Nota 1. Middlewares

Middleware é um conjunto de agentes que atuam como intermediários entre diferentes componentes de aplicações. Geralmente, são usados em aplicações distribuídas complexas.

Um exemplo clássico é o gerenciador de transações, que é o componente colocado entre os usuários clientes e um banco de dados em aplicações cliente/servidor. Nestas situações, o middleware reduz o número de conexões de alto custo que devem ser feitas e as faz da maneira mais eficiente possível. Desse modo, a velocidade de atendimento aos clientes aumenta significativamente. Alguns exemplos de middlewares baseados em transações são: CICS, IBM Websphere MQ, Tibco e Tuxedo.

Outra razão para o uso de middlewares é o fornecimento de:

·         Serviços;

·         Abstrações de alto nível para aplicações (APIs – Application Programming Interfaces).

Estes fatores facilitam:

·         O desenvolvimento de aplicações;

·         A integração de aplicações;

·         As tarefas de gerenciamento de sistemas.

Os Middlewares atuais usam, comumente, as seguintes tecnologias:

·         XML;

·         SOAP;

·         Web services;

·         Arquiteturas Orientadas a Serviço (SOA – Service-Oriented Architecture).

Grupos como Apache Software Foundation e ObjectWeb Consortium apóiam o desenvolvimento de middleware open-source.

Vejamos agora alguns conceitos sobre o protocolo usado para enviar esses dados para um servidor remoto na nossa aplicação.

Introdução ao HTTP – HyperText Transfer Protocol

As comunicações entre o celular e o servidor web são feitas usando o protocolo HTTP. Este define as requisições que um cliente pode enviar para um servidor e as respostas que o servidor retorna. Cada requisição contém uma URL, que é uma string que identifica um componente web ou um objeto estático como uma página HTML ou um arquivo de imagem.

O Tomcat, que é um servidor J2EE converte uma requisição HTTP em um objeto de requisição HTTP e o entrega ao componente web identificado pela URL de requisição. O componente web completa um objeto de resposta HTTP, que o servidor converte em uma resposta HTTP e envia ao cliente.

Uma requisição HTTP consiste em um método de requisição, uma URL de requisição, campos de cabeçalho e um corpo. O protocolo HTTP 1.1 define os seguintes métodos de requisição:

·         GET: recupera o recurso identificado pela URL de requisição.

·         HEAD: retorna os cabeçalhos identificados pela URL de requisição.

·         POST: envia dados de tamanho ilimitado para o servidor web.

·         PUT: guarda um recurso na URL de requisição

·         DELETE: remove o recurso identificado pela URL de requisição.

·         OPTIONS: retorna os métodos HTTP que o servidor suporta.

·         TRACE: retorna os campos de cabeçalho enviados com a requisição TRACE.

O protocolo HTTP 1.0 inclui apenas os métodos GET, HEAD e POST.

Uma resposta HTTP contém o código de resultado, campos de cabeçalho e um corpo. O protocolo HTTP espera que o código de resultado e todos os campos de cabeçalho sejam retornados antes de qualquer conteúdo do corpo. Alguns códigos de resultado comumente usados são:

·         404: indica que o recurso requisitado não está disponível.

·         401: indica que a requisição requer autenticação HTTP.

·         500: indica que um erro ocorreu dentro do servidor HTTP que impediu o atendimento da requisição.

·         503: indica que o servidor HTTP está temporariamente sobrecarregado e incapaz de tratar a requisição.

Para maiores informações veja os seguintes RFCs (Request for Comment):

·         HTTP/1.0 (RFC 1945)

·         HTTP/1.1 (RFC 2616)

Eles podem ser encontrados em: http://www.ietf.org/rfc.html ou http://www.rfcs.org.

Usamos o método POST e o método GET na nossa aplicação para ilustrar como usar cada um deles. Para enviar recordes usamos o método POST e para receber recordes usamos o método GET.

Para usar o protocolo HTTP em nossa aplicação, usamos a interface HttpConnection do Generic Connection Framework.

Generic Connection Framework (GCF)

Os pacotes java.io.* e java.net.* do J2SE necessitam de mais memória que a maioria dos dispositivos móveis possuem. O Generic Connection Framework (GCF) foi definido para atender a necessidade de usar recursos de rede em dispositivos que possuem a configuração CLDC – Connected Limited Device Configuration. ...