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

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (0)  (0)

Artigo publicado pela revista WebMobile edição 3

 

Esse artigo faz parte da revista WebMobile edição 3. Clique aqui para ler todos os artigos desta edição

WM03_capa.JPG

imagem_pdf.jpg

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.

image001.png

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.

image003.png

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)

"

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?