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

Usando conexões HTTP em um jogo J2ME/MIDP

Leitura Recomendada: WebMobile 1, artigo Desenvolvimento de jogos J2ME/MIDP para celular.

Leitura Recomendada: WebMobile 2, artigo Incrementando um jogo J2ME/MIDP usando RMS: Uma introdução ao Record Managament System (RMS).

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.

Listagem 1. Representação de um recorde em XML.

<record>

<nome>XAXIM</nome>

<hiscore>32370</hiscore>

</record>

Já a Listagem 2 apresenta a representação de um recorde para o mesmo jogo utilizando um padrão simples que possui 25 bytes de tamanho.

Listagem 2. Representação de um recorde em padrão simples.

NOME=XAXIM

HISCORE=32370

Por fim, a Listagem 3 mostra a representação em hexadecimal do mesmo recorde usando simplesmente um int para representar uma pontuação e uma String em UTF para representar um nome. Esta representação possui 11 bytes no total.

Listagem 3. Representação hexadecimal do recorde usando um padrão otimizado.

/* int */

0x00,0x00,0x7E,0x72 // 4 bytes representando o int: 32370, veja que 0x00007E72 = 32370

/* string em UTF */

0x00,0x05 // 2 bytes = tamanho da String: 0x0005 = 5 letras

0x58,0x41,0x58,0x49,0x4D  // os outros 5 bytes representam a String “XAXIM”:

 // X: 0x58, A: 0x41, X: 0x58, I: 0x49, M: 0x4D

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. " [...] continue lendo...