Wendel Malta de Assis

Avaliao da tecnologia J2ME no contexto de desenvolvimento de jogos

multiplayers para celulares

Monografia apresentada ao Departamento de Cincia da Computao da Universidade Federal de Lavras, como parte das exigncias do Curso de Cincia
da Computao, para obteno do ttulo de Bacharel.

Orientador
Prof. Ricardo Martins de Abreu Silva

Lavras
Minas Gerais - Brasil
Junho de 2003

Wendel Malta de Assis

Avaliao da tecnologia J2ME no contexto de desenvolvimento de jogos

multiplayers para celulares

Monografia apresentada ao Departamento de Cincia da Computao da Universidade Federal de Lavras, como parte das exigncias do Curso de Cincia
da Computao, para obteno do ttulo de Bacharel.

Aprovada em 17 de Junho de 2003

Prof. Guilherme Bastos Alvarenga

Prof. Ricardo Martins de Abreu Silva

(Orientador)

Lavras
Minas Gerais - Brasil

Avaliao da tecnologia J2ME no contexto de

desenvolvimento de jogos multiplayers para celulares
Resumo
Atualmente, a telefonia celular encontra-se em uma fase de grande expanso, momento em que esto surgindo novas tecnologias de transmisso e aparelhos cada vez mais modernos e com maiores funcionalidades. Estes novos aparelhos permitem o desenvolvimento de
aplicaes mais complexas, como os jogos.
O objetivo deste trabalho consiste em apresentar as dificuldades e facilidades encontradas ao se utilizar a plataforma J2ME no desenvolvimento de um jogo multiplayer para celulares, chamado Alea Jacta
Est, e, em seguida, avali-la de um modo geral com relao ao desenvolvimento deste tipo de aplicao.

Evaluation of the J2ME technology in the context of

development of multiplayers games for cellulars
Abstract
Currently, the cellular telephony is on a great expansion phase, contributing to the sprouting of new transmission technologies and moderns devices with more functionalities. These new devices allow the
development of complex applications, like games.
The purpose of this work consists of the presentation of difficulties and
easiness, found during the use of J2ME platform on the development
of a multiplayer game for cell phones, named Alea Jacta Est, and
after, evaluate it on a general way with the development of this kind
of application.
v

vi

Sumrio
1

Introduo

Tecnologia Java para o segmento de aplicaes wireless

2.1 Comunicaes wireless . . . . . . . . . . . . . . . . . . . . . . .
2.2 Dispositivos mveis embutidos . . . . . . . . . . . . . . . . . . .
2.3 A tecnologia Java . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.1 A linguagem de programao Java . . . . . . . . . . . . .
2.3.2 A plataforma Java . . . . . . . . . . . . . . . . . . . . .
2.3.3 A plataforma Java na atualidade . . . . . . . . . . . . . .
2.4 Java 2 Platform, Micro Edition (J2ME) . . . . . . . . . . . . . . .
2.4.1 Por que usar J2ME? . . . . . . . . . . . . . . . . . . . .
2.4.2 Um pouco de histria . . . . . . . . . . . . . . . . . . . .
2.4.3 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.4 J2ME Connected Limited Device Configuration (CLDC) .
2.4.5 Os profiles para o CLDC . . . . . . . . . . . . . . . . . .
2.4.6 J2ME Connected Device Configuration (CDC) . . . . . .
2.4.7 Os profiles para o CDC . . . . . . . . . . . . . . . . . . .
2.4.8 Especificaes adotadas pelos celulares . . . . . . . . . .
2.4.9 Distribuindo a aplicao . . . . . . . . . . . . . . . . . .
2.5 O escopo da tecnologia wireless em Java . . . . . . . . . . . . . .
2.6 Por que usar a tecnologia Java para o desenvolvimento de aplicaes wireless? . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.7 Jogos multiplayers . . . . . . . . . . . . . . . . . . . . . . . . .
2.8 Conexes via sockets . . . . . . . . . . . . . . . . . . . . . . . .
2.9 Threads de execuo . . . . . . . . . . . . . . . . . . . . . . . .
vii

9
10
10
11
12
14
16
18
18
19
21
25
30
50
51
53
53
56
57
58
60
62

Estudo de caso: avaliao da plataforma J2ME na implementao do

jogo Alea Jacta Est
3.1 O jogo Alea Jacta Est . . . . . . . . . . . . . . . . . . . . . . .
3.2 Ferramentas utilizadas no desenvolvimento do jogo AleaJactaEst
3.2.1 Editores de cdigo . . . . . . . . . . . . . . . . . . . . .
3.2.2 Emuladores . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.3 Criao de aplicaes . . . . . . . . . . . . . . . . . . . .
3.3 O desenvolvimento do jogo Alea Jacta Est . . . . . . . . . . . .
3.3.1 A interface . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.2 A dinmica do jogo . . . . . . . . . . . . . . . . . . . . .
3.3.3 A arquitetura de comunicao . . . . . . . . . . . . . . .

65
66
67
67
68
69
73
77
89
93

Resultados e discusses
101
4.1 Vantagens na utilizao do profile MIDP 1.0 para a construo de
jogos multiplayers . . . . . . . . . . . . . . . . . . . . . . . . . . 101
4.2 Desvantagens na utilizao do profile MIDP 1.0 para a construo
de jogos multiplayers . . . . . . . . . . . . . . . . . . . . . . . . 103

Concluses
105
5.1 Concluses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
5.2 Sugestes para trabalhos futuros . . . . . . . . . . . . . . . . . . 106

viii

Lista de Figuras
1.1
1.2
1.3
1.4

Principais usos da Internet Mvel pelos usurios atuais. . . . . . .

Contedos mais procurados pelos usurios de dispositivos mveis.
Previses de crescimento no nmero de usurios das telefonias
mvel e fixa no Brasil. . . . . . . . . . . . . . . . . . . . . . . .
Previses de crescimento do mercado de jogos para celulares. . . .

Processo de compilao e execuo de um programa na tecnologia

Java. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Um exemplo da portabilidade de Java. . . . . . . . . . . . . . . .
2.3 A estrutura da plataforma Java. . . . . . . . . . . . . . . . . . . .
2.4 A plataforma Java 2 e seus dispositivos alvos. . . . . . . . . . . .
2.5 Pilha de software genrica a ser implementada por um dispositivo
J2ME. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.6 Classes que fazem parte do Generic Connection Framework (GCF),
segundo a especificao CLDC. . . . . . . . . . . . . . . . . . .
2.7 Abertura de conexo utilizando o mtodo open da classe Connector. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.8 Transies de estados em uma MIDlet. . . . . . . . . . . . . . . .
2.9 Trecho de cdigo ilustrando o corpo de uma MIDlet. . . . . . . .
2.10 Classes que fazem parte do pacote javax.microedition.
lcdui, para manipulao de interfaces. As setas em vermelho
indicam uma relao de uso da classe que aponta a seta pela classe
alvo dela. A classes que no apresentam nenhuma relao de herana e no so interfaces herdam diretamente da classe Object
do pacote java.lang. . . . . . . . . . . . . . . . . . . . . . .
2.11 Cdigo que apresenta a utilizao de alguns elementos da interface
de alto nvel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4
4
5
7

2.1

ix

13
14
16
18
23
27
28
32
33

35
37

2.12 Resultado da execuo, em um emulador de celular, do cdigo da

Figura 2.11. Em a vemos o celular apresentando as aplicaes
disponveis para serem ativadas e em b a sada do cdigo. . . . . .
2.13 Modificaes feitas no GCF pelo profile MIDP verso 1.0. As novas interfaces implementadas encontram-se circuladas de vermelho.
2.14 Processo de construo de fundos com a utilizao de tiles em uma
TiledLayer. . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.15 Processo de construo de imagens de fundo utilizando uma TiledLayer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.16 Hierarquia de classes do pacote javax.microedition.lcdui.
game. As classes circuladas de azul no fazem parte do pacote de
jogos, apenas so extendidas por algumas de suas classes. . . . . .
2.17 Modificaes feitas no GCF pelo profile MIDP verso 2.0. As
novas interfaces includas por esta especificao encontram-se circuladas de vermelho. . . . . . . . . . . . . . . . . . . . . . . . .
2.18 Profiles que fazem parte da configurao CLDC. . . . . . . . . .
2.19 Relao entre o CLDC e CDC. . . . . . . . . . . . . . . . . . . .
2.20 Profiles baseados na configurao CDC e suas relaes. . . . . . .
2.21 Pilha de software atualmente implentada pelos aparelhos celulares.
2.22 Pilha de software a ser implementada pelos aparelhos celulares. . .
2.23 Funcionamento de um JAM. . . . . . . . . . . . . . . . . . . . .
2.24 Over-the-air provisioning (OTA). . . . . . . . . . . . . . . . . . .
2.25 Arquitetura de comunicao ponto a ponto. . . . . . . . . . . . .
2.26 Arquitetura de comunicao baseada em servidor e suas variaes.
2.27 Requisio de conexo de um cliente a um servidor via sockets. . .
2.28 Conexo estabelecida entre um cliente e um servidor via sockets. .
2.29 Modo de execuo de uma thread nica. . . . . . . . . . . . . . .
2.30 Execuo de mltiplas threads em um nico programa. . . . . . .
3.1
3.2
3.3
3.4
3.5
3.6
3.7

O ambiente de trabalho do editor JEdit 4.0. . . . . . . . . . . . .

Organizao de uma sute de MIDlets. . . . . . . . . . . . . . . .
KToolBar, principal ferramenta do J2ME Wireless Toolkit. . . . .
Processo de construo e teste de uma MIDlet. . . . . . . . . . .
Processo de empacotamento de uma MIDlet. . . . . . . . . . . . .
Classes que fazem parte do jogo Alea Jacta Est. . . . . . . . . .
Pilha de especificaes J2ME utilizada na implementacao do Alea
Jacta Est. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
x

38
40
46
47

48

49
51
52
53
53
54
54
56
59
60
61
61
62
63
68
72
73
74
74
76
76

3.8

3.9
3.10
3.11
3.12
3.13
3.14
3.15
3.16
3.17
3.18

3.19
3.20
3.21
3.22
3.23
3.24
3.25
3.26
3.27
3.28

Modelo navegacional das interfaces desenvolvidas para o jogo Alea

Jacta Est. A classe TelaInicial corresponde ao incio do
fluxo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Interface definida pela classe TelaInicial. . . . . . . . . . . .
Trecho de cdigo enfocando a definio da classe TelaInicial. . . .
Trecho de cdigo enfocando a insero de um ImageItem pela
classe TelaInicial. . . . . . . . . . . . . . . . . . . . . . . . . . .
Trecho de cdigo que mostra a criao de um StringItem. . . .
Trecho de cdigo mostrando como inserir Commands em um Form.
Interface definida pela classe TelaIniciarJogo. . . . . . . .
Trecho de cdigo da classe TelaIniciarJogo. . . . . . . . .
Classe TelaJogo, na qual toda a interao entre os jogadores
ocorre. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tiles utilizados na construo do mapa do jogo. . . . . . . . . . .
Sprites disponibilizados para a interao com o jogo. Os nmeros
entre parnteses correspondem ao valor de ataque, defesa e tempo
de construo, respectivamente. . . . . . . . . . . . . . . . . . .
Tiles utilizados na construo do mapa do jogo. . . . . . . . . . .
Estrutura de classes criadas para utilizar a idia de sprite, tile e
janela de visualizao. . . . . . . . . . . . . . . . . . . . . . . .
Fluxo de execuo criado para a thread de manipulao de eventos
de teclado no Alea Jacta Est. . . . . . . . . . . . . . . . . . . .
Mensagens trocadas entre o jogador Wendel e o servidor durante
o processo de criao de uma cidade com sucesso. . . . . . . . . .
Loops de controle de execuo definidos pelos profiles MIDP 1.0
e 2.0. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Trecho de cdigo que mostra a estrutura tradicional utilizada por
uma classe em MIDP 1.0 para um loop de jogo. . . . . . . . . . .
Trecho de cdigo que mostra a estrutura tradicional utilizada por
uma classe em MIDP 2.0 para um loop de jogo. . . . . . . . . . .
Trecho do cdigo do Alea Jacta Est que mostra a abertura de
conexes por sockets. . . . . . . . . . . . . . . . . . . . . . . . .
Processo de construo de um cabealho para uma primitiva de
comunicao. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Trecho de cdigo mostrando a maneira como o cliente envia ou
recebe mensagens. . . . . . . . . . . . . . . . . . . . . . . . . .
xi

79
80
80
81
81
82
82
83
84
85

85
87
88
90
90
92
92
93
95
97
98

3.29 Trecho de cdigo mostrando o loop onde o jogador permanece at

que inicie o seu turno. . . . . . . . . . . . . . . . . . . . . . . . .

xii

99

Lista de Tabelas
3.1
3.2
5.1

Emuladores disponibilizados pelo J2ME Wireless Toolkit e verses

de MIDP implementadas por cada um deles. . . . . . . . . . . . .
Caractersticas dos emuladores disponibilizados pelo J2ME Wireless Toolkit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

70
71

Resumo das concluses obtidas com relao a utilizao da plataforma J2ME no desenvolvimento de jogos multiplayers. . . . . . . 107

Captulo 1

Introduo
Atualmente, vivemos em um mundo onde a informao a principal ferramenta das pessoas e empresas para garantir a sua sobrevivncia no mercado. Este
novo paradigma iniciou-se com a chegada da Internet, em meados da dcada de
90. Considerada o maior repositrio de informaes do mundo, ela permite a troca
de conhecimentos de maneira mais rpida e fcil.
Os pequenos dispositivos mveis (como o Personal Digital Assistant (PDA) e,
recentemente, os celulares mais poderosos) e a comunicao wireless formam uma
das principais armas das pessoas para que estas se mantenham constantemente informadas, conectadas ao mundo, onde quer que estejam e sem que tenham que
carregar muito peso. Portanto, estas tecnologias foram as responsveis por criar
um mercado totalmente novo, o de desenvolvimento de aplicaes para os dispositivos mveis. Alguns tipos de aplicaes geralmente procuradas so acesso
informaes e notcias, leitura de correio eletrnico, transaes bancrias e entretenimento. O uso da Internet por estes dispositivos tambm tem crescido muito
nestes ltimos tempos, caracterizando o conceito de Internet Mvel (ou Internet
sem fio).
A Figura 1.1 apresenta uma pesquisa da Revista Poder [POD2002] sobre os
principais usos da Internet sem fio por parte das pessoas. A Figura 1.2 tambm
apresenta uma pesquisa desta mesma revista com relao ao tipo de contedo mais
desejado pelos consumidores do mercado de dispositivos mveis.
De acordo com a diviso proposta por Monica Pawlan[PAW2002], o mercado
para os servios e aplicaes wireless muito grande, podendo ser dividido em
dois segmentos:
Segmento consumidor: consiste de jogos, servios standalone, aplicaes de
3

Figura 1.1: Principais usos da Internet Mvel pelos usurios atuais.

Figura 1.2: Contedos mais procurados pelos usurios de dispositivos mveis.

produtividade entre outras aplicaes teis. Este segmento corresponde ao

tipo de aplicao que ser distribuda pelas prestadoras de servios celulares.
Segmento de negcios: consiste no acesso as informaes da empresa, a
qualquer instante, atravs de aplicaes wireless padronizadas instaladas em
dispositivos mveis.
4

Este projeto visa atender ao segmento de mercado voltado para o consumidor

e tambm a demanda das pessoas por aplicaes de entretenimento em seus dispositivos mveis. Assim, foi avaliada a utilizao da plataforma Java 2 Platform,
Micro Edition (J2ME)1 , da Sun Microsystems2 , no desenvolvimento de jogos multiplayers para celulares.
Os primeiros celulares possuam poucos recursos e serviam apenas para a realizao e recebimento de chamadas (funo bsica de todo telefone celular). Os
aparelhos atuais, por sua vez, possuem um maior grau de processamento tornando
possvel a execuo de aplicaes mais diversificadas, como jogos.
Para se ter uma idia da situao atual e do alto potencial de crescimento do
mercado de dispositivos mveis, em especial dos celulares, os prximos pargrafos
iro apresentar alguns nmeros muito interessantes.
Segundo o vice-presidente da Anatel, Antnio Carlos Valente, existem hoje no
Brasil, aproximadamente, 32 milhes de celulares em operao [INF2002A]. A
Figura 1.3 apresenta um grfico da Anatel que ilustra as previses de crescimento
no nmero de usurios de telefonia mvel no pas com relao a telefonia fixa.

Figura 1.3: Previses de crescimento no nmero de usurios das telefonias mvel

e fixa no Brasil.
De acordo com dados da Frost & Sullivan, em 2000, o Brasil movimentou
1

No restante desta monografia, quando se for realizar uma referncia a plataforma Java 2 Platform Micro Edition, se utilizar a sigla J2ME.
2
Por vrias vezes, no restante desta monografia, ser utilizada a abreviao Sun quando se for
fazer uma referncia a Sun Microsystems.

mais de 15 bilhes de dlares com seu mercado wireless [IBI2002].

Segundo os dados publicados pela revista InfoExame[INF2001], a Finlndia est entre os mercados de telefonia celular mais desenvolvidos do mundo,
quase 80% da populao tm celular, parcialmente por causa do sucesso da Nokia,companhia finlandesa e maior fabricante de aparelhos celulares do mundo.
Em 2001, a telefonia celular ultrapassou a telefonia fixa na Amrica Latina
com relao ao nmero de usurios. De acordo com um estudo da Pyramid
Research[INF2002B], a penetrao da telefonia celular chegou a 17%, enquanto
a da telefonia fixa ficou em 16,9%. Nos prximos anos, a Pyramid acredita que
a diferena entre estes ndices deva aumentar ainda mais, principalmente com a
entrada das novas operadoras e dos servios 2,5G e 3G. Em 2006, a penetrao
do telefone celular j dever ter ultrapassado os 30%, enquanto a da telefonia fixa
ainda dever estar na faixa dos 20%.
Uma pesquisa realizada pela Jupiter Media Metrix[IBI2002] revelou que o nmero de usurios de Internet sem fio nos EUA saltaria dos 4,1 milhes, em 2001,
para 96 milhes em 2005. Estendendo para a Amrica Latina, teria-se aproximadamente 50 milhes de usurios acessando a Internet por telefone celular at 2005,
o que tornaria o uso das redes sem fio to disseminado na regio quanto o acesso
baseado em PCs.
Os dados publicados no site da IBiznet[IBI2002] mostram que, na Unio Europia, em 2010, a previso de que 75% das pessoas entre 15 e 50 anos carreguem
consigo um dispositivo mvel. A venda de telefones mveis com acesso Internet
deve passar de um bilho de unidades por ano em 2004. Ainda de acordo com esta
pesquisa, o Japo, em 2005, ter 96 milhes de aparelhos celulares, dos quais 94
milhes tero acesso aos servios de Internet mvel.
Em conjunto com o crescimento do nmero de usurios de dispositivos mveis, aparece o mercado de jogos para estes dispositivos, em especial para os celulares. As operadoras do mundo inteiro j faturam 436 milhes de dlares ao ano
com esse mercado e esperam crescer a 9,3 bilhes de dlares at 2008, de acordo
com John Smedley, diretor de operaes da Sony Online Entertainment.
Segundo David Fox[FOX2002], em dezembro de 2002, executivos de alto escalo de companhias como Sony, Disney, Sega, THQ e Newscorp estavam reunidos
no Mobile Entertainment Summit em Las Vegas, Nevada. O objetivo era discutir o
presente e o futuro dos jogos wireless. Frost & Sullivan aposta que o mercado de
jogos mveis movimentar 9,3 bilhes de dlares at 2008. Ovum acredita em 4,4
bilhes at 2006. In-Stat/MDR, entretanto, prev que os jogos sero somente 2,8
bilhes de dlares at 2006. Como visto, as estimativas apresentadas pelos parti6

cipantes variaram grandemente, mas isto no significa que este mercado no crescer, uma vez que a pior previso apresentada ainda revela aumento de mercado.
O grfico, elaborado pelo autor, apresentado pela Figura 1.4 ilustra as previses de
crescimento esperadas no mercado de jogos para celulares nos prximos anos.

Figura 1.4: Previses de crescimento do mercado de jogos para celulares.

Acompanhando este mercado promissor, vrias empresas anunciaram o desenvolvimento de tecnologias que permitem a criao de aplicaes para os dispositivos mveis. Assim, surgiram nomes no mercado como WAP, J2ME, BREW,
i-mode (celulares japoneses), dentre vrios outros. Cada uma dessas tecnologias
visa explorar ao mximo esse mercado de dispositivos mveis com capacidade de
comunicao wireless.
A tecnologia J2ME vem se destacando devido a sua alta portabilidade, o que
permite o desenvolvimento de aplicaes para um grande nmero de diferentes
dispositivos sem maiores problemas, e pela sua grande aceitao no mercado atual.
Vrios fabricantes como a Nokia, Siemens e Motorola j produzem aparelhos com
suporte a esta tecnologia.
Para facilitar a anlise da tecnologia J2ME foi proposto o desenvolvimento de
um jogo modelo. Assim, iniciou-se a construo de um jogo de estratgia multiplayer denominado Alea Jacta Est. Durante o desenvolvimento deste jogo foi
possvel relacionar as dificuldades e facilidades encontradas na utilizao da tecnologia J2ME para a sua implementao e tambm verificar os pontos negativos e
positivos desta tecnologia no desenvolvimento de jogos multiplayers para celulares.
Este trabalho encontra-se altamente relacionado com o projeto Alea Jacta
Est Um prottipo de jogo de estratgia interativo multiplayer para dispositivos
7

mveis, desenvolvido pelo aluno Diego Mello da Silva do curso de Cincia da

Computao, da Universidade Federal de Lavras. Deve-se ressaltar que os dois
projetos so complementares, sendo que o jogo modelo Alea Jacta Est est melhor documentado na monografia do Diego, enquanto os detalhes da implementao e a anlise da tecnologia J2ME utilizada no seu desenvolvimento encontram-se
neste documento.
Esta monografia est organizada em cinco captulos, como descrito nos tpicos
abaixo:
O captulo 1 corresponde a Introduo ao tema.
O captulo 2 descreve, de modo completo, as principais tecnologias utilizadas neste trabalho.
O captulo 3 apresenta o jogo modelo proposto para servir de base para a
anlise da tecnologia J2ME, bem como as etapas que foram necessrias para
o seu desenvolvimento. Tambm sero apresentadas as diretrizes seguidas
para a realizao da avaliao da tecnologia e algumas anlises iniciais.
O captulo 4 apresenta os resultados encontrados de uma maneira mais clara
e uma discusso dos mesmos.
O captulo 5 apresenta as concluses finais sobre a utilizao da tecnologia
J2ME para o desenvolvimento de jogos multiplayers para celulares e recomendaes para trabalhos futuros.

Captulo 2

Tecnologia Java para o segmento

de aplicaes wireless
Este captulo tem por objetivo principal introduzir o leitor as tecnologias wireless utilizadas no projeto. Alguns outros conceitos, necessrios para o entendimento do jogo modelo construdo, como sockets, threads de execuo e jogos
multiplayers tambm sero apresentados.
A seo 2.1 e a seo 2.2 tem como objetivo apresentar de forma breve os
conceitos bsicos relacionados a comunicao wireless e aos dispositivos mveis
embutidos, respectivamente. A seo 2.3 apresenta as caractersticas principais
da tecnologia Java, permitindo uma melhor compreenso da plataforma J2ME e
da tecnologia de sockets e de threads de execuo em Java. A seo 2.4 apresenta a plataforma J2ME em grandes detalhes, pois esta a tecnologia alvo de
anlise deste projeto. A seo 2.5 apresenta algumas consideraes que procuram
mostrar que quando falamos sobre wireless em Java no estamos falando apenas
da plataforma J2ME. A seo 2.6 mostra os motivos que levam as pessoas a optar por Java para o desenvolvimento de solues mveis, utilizando-a de ponta a
ponta no projeto. A seo 2.7 apresenta os conceitos relacionados a jogos multiplayers, focando-se nas maneiras de se implement-los. As prximas sees tem
o objetivo de apresentar conceitos necessrios ao entendimento do funcionamento
do jogo modelo construdo. Assim, a seo 2.8 apresenta os conceitos bsicos de
sockets e a seo 2.9 fala sobre threads de execuo de um programa.
9

2.1

Comunicaes wireless

O termo comunicaes wireless pode ser definido como o conjunto de todas

as formas de comunicao que no utilizam fios (ou qualquer outro sistema fsico)
para se propagarem.
Segundo a prpria Sun Microsystems[SUN2003A], o campo de atuao da tecnologia de comunicao wireless enorme, sendo que ela est presente nas transmisses de rdio e televiso passando pelos pagers, telefones mveis e nas comunicaes via satlite. Outra face desta tecnologia que est crescendo rapidamente
so as redes locais sem-fio (LANs wireless ou WLANs).
Conceitualmente, comunicaes wireless podem ser dividas em dois tipos,
rea local e grande rea. Um dispositivo local similar aos chaveiros de alarme
de carros com botes que travam e destravam o carro, um telefone sem fio de
900MHz, um brinquedo de controle remoto ou uma rede Bluetooth. Todos estes
dispositivos operam sobre pequenas distncias, tipicamente alguns poucos metros
[SUN2003A].
Dispositivos wireless de grande rea operam efetivamente sobre uma enorme
rea. Um pager ou um telefone mvel (celular) so bons exemplos. Estes dispositivos conseguem operar a grandes distncias devido a uma rede mais elaborada.
Um celular no tem muito mais poder que o controle remoto de um brinquedo. Ele
possui uma rede de antenas celulares cuidadosamente instaladas que permite com
que o telefone celular continue funcionando se ele estiver no limite de pelo menos
uma torre [SUN2003A].

2.2

Dispositivos mveis embutidos

Produtos de consumo baseados em microprocessadores, como os alarmes, mquinas de caf, televises, ar condicionados e telefones so chamados de dispositivos embutidos (ou dispositivos embarcados) pelo fato de eles possurem pequenos
computadores dentro deles com uma funo muito bem delimitada. Os celulares tradicionais so exemplos de dispositivos embutidos. Entretanto, os aparelhos
mais novos j se assemelham aos computadores deskop, ou seja, permitem a execuo de aplicaes variadas.
Dispositivos embutidos de consumo e que no esto conectados a parede por
um fio, mas ao invs disso usam tecnologia wireless para se comunicar so chamados de dispositivos mveis embutidos. Entre os vrios tipos destes dispositivos
podemos citar o handheld, telefones celulares, pagers e todos os tipos de PDAs
10

[PAW2002].
A maioria destes dispositivos pode se comunicar atravs de links wireless. Estes links podem ser estabelecidos atravs de luz infravermelha (IR, do ingls infrared) ou, mais freqentemente, ondas de rdio (RF, do ingls radio frequency)
[JON2002].
Um exemplo comum de dispositivo mvel que utiliza IR para estabelecer um
link de comunicao o controle remoto do aparelho de som ou da televiso. Os
telefones celulares e dispositivos wireless usam RF para se comunicar e utilizam
um sistema mais elaborado, baseado em antenas, que no ser detalhado neste
projeto [JON2002].

2.3 A tecnologia Java

A tecnologia Java surgiu como um produto indireto de um pequeno projeto,
conhecido por Green Project, iniciado por Patrick Naughton, Mike Sheridan e James Gosling da Sun Microsystems em 1991. A equipe do Green Project, chamada
de Green Team, era composta por 13 pessoas e foi incumbida pela Sun de antecipar
e planejar o futuro da computao. A concluso inicial do grupo foi que havia uma
tendncia que consistia da convergncia de dispositivos controlados digitalmente
e computadores [BYO2002][SUN2002A].
Em 1992, o grupo apresentou um trabalho demo, um handheld capaz de controlar o sistema de entretenimento de uma casa atravs de uma interface por toque
na tela e animada. A linguagem de programao utilizada neste dispositivo foi
criada por James Gosling. Gosling chamou a nova linguagem de Oak, devido a
rvore de frente a sua janela (Oak em portugus significa carvalho) [BYO2002].
Apesar do dispositivo criado pelo grupo no ter feito grande sucesso no mercado, sendo considerado por muitos um produto a frente de seu tempo, a nova
linguagem criada por Gosling destacou-se rapidamente. O Oak era uma linguagem orientada a objeto e capaz de trabalhar sobre redes de maneira distribuda.
Alm disso, possua uma grande preocupao com a segurana, j implementando
criptografia e procedimentos de autenticao [BYO2002].
Depois de vrias tentativas de popularizar o Oak no mercado de dispositivos
embutidos, o grupo finalmente conseguiu enxergar que, pelo menos na poca, este
no era o mercado ideal para a sua nova tecnologia, mas sim a Internet, que estava comeando a ganhar destaque e tambm possua as caractersicas de redes
distribudas to visadas pela equipe.
Em 1995, o Oak foi renomeado para Java e um novo trabalho demo, um na11

vegador chamado de WebRunner, foi desenvolvido. Ele foi apresentado por Gosling no Hollywood-Meets-Silicon-Valley juntamente com dois exemplos de applets animadas, aplicativos Java que executam em um navegador web.
O lanamento oficial ocorreu em 23 de maio de 1995 durante a conferncia
SunWorld.
Nesta poca, a tecnologia Java fugiu um pouco de sua idia original, que era
trabalhar com dispositivos embutidos, e utilizou a web para ganhar popularidade.
Entretanto, atualmente, sabe-se que seu campo de atuao bem maior do que
apenas o desenvolvimento de applets.
As pessoas geralmente se referem a tecnologia Java no sentido nico da linguagem de programao Java, mas isto no est correto. Na verdade, trata-se de
uma linguagem de programao e de uma plataforma. As prximas subsees iro
explicar melhor estes dois conceitos.

2.3.1

A linguagem de programao Java

Segundo James Gosling e Henry McGilton[GOS & MCG1996], a linguagem

de programao Java uma linguagem de alto nvel que tem como caractersticas
principais:
simples;
orientada a objetos;
independente de arquitetura;
portvel;
interpretada;
distribuda;
alta-performance;
multithreaded;
robusta;
dinmica;
segura.
12

Na maioria das linguagens de programao, pode-se compilar ou interpretar o

cdigo fonte para permitir a execuo em um computador. A linguagem de programao Java diferente neste aspecto, realizando as duas etapas. Na etapa de
compilao feita uma traduo do programa (cdigo fonte) em uma linguagem
intermediria chamada bytecodes, que so cdigos independentes de mquina interpretados na plataforma Java. O interpretador tem a funo de analisar e executar
cada bytecode Java. Assim, a compilao realizada apenas uma vez, enquanto
que a interpretao realizada sempre que o programa executado. A Figura 2.1,
ilustra este processo.

Figura 2.1: Processo de compilao e execuo de um programa na tecnologia

Java.
Pode-se pensar nos bytecodes Java como instrues em cdigo de mquina
para a Java Virtual Machine, em portugus Mquina Virtual Java. Todo interpretador Java, no importando se est integrado a um ambiente de desenvolvimento ou
em um navegador que pode executar applets, uma implementao desta mquina
[CAM & WAL2002].
Como um programa Java interpretado ao ser executado, isto o torna um pouco
mais lento quando comparado com linguagens de programao que possuem compiladores que geram cdigos nativos, isto , cdigos para uma plataforma especfica. Entretanto, a Sun Microsystems tem melhorado cada vez mais os seus
interpretadores, atravs de tecnologias como just-in-time compiler, para garantir
performance sem perder portabilidade. Esta tentativa de manter a portabilidade e
garantir eficincia a principal dificuldade enfrentada por Java.
atravs desta estrutura que Java garante a sua promessa de independncia de
plataforma. Os bytecodes Java realmente tornam a to famosa frase escreva uma
vez, execute em qualquer lugar (em ingls, write once, run anywhere) possvel.
A Figura 2.2, de Mary Campione e Kathy Walrath[CAM & WAL2002], apresenta de forma clara a questo da portabilidade em Java. Pode-se compilar o
programa em bytecodes em qualquer plataforma que possua o compilador Java
e depois execut-los em qualquer implementao de mquina virtual Java. Isto
significa que desde que um computador possua uma mquina virtual Java insta13

lada, o mesmo programa escrito na linguagem de programao Java pode executar

em plataformas to diferentes quanto Windows 2000, Solaris ou iMac.

Figura 2.2: Um exemplo da portabilidade de Java.

impossvel falar da linguagem de programao Java sem compar-la com
a linguagem de programao C++, a qual ela apresenta semelhana sinttica. O
objetivo aqui no o de julgar as duas linguagens e dizer qual a melhor, mas apenas apresentar as suas diferenas principais. A linguagem Java aloca e desaloca
memria automaticamente quando o programa cria e destri objetos, enquanto
programadores que usam C++ devem alocar e desalocar explicitamente a memria utilizada. Em Java no se utilizam ponteiros, mas apenas referncias a objetos
para resolver o problema da alocao dinmica de memria. Outra diferena fundamental entre as duas linguagens que Java inclui um mecanismo de herana
conhecido como interface, que substitui o conceito de herana mltipla em C++
[SUN2003A].
A sintaxe e a estrutura da linguagem Java tambm so muito simples, tornando
fcil e rpida a construo de programas e a sua compreenso.
A especificao da linguagem Java pode ser encontrada no livro The Java Language Specification [GOS, JOY, STE & BRA2000].

2.3.2

A plataforma Java

Uma plataforma o hardware ou ambiente de software no qual um programa

executa. A maioria das plataformas podem ser descritas como uma combinao
de sistema operacional e hardware. A plataforma Java difere de todas as outras
por ser uma plataforma nicamente de software que executa no topo das outras
plataformas baseadas em hardware [CAM & WAL2002].
A plataforma Java tem dois componentes:
14

 A Mquina Virtual Java (Java VM);

A Interface de Programao de Aplicaes Java (Java Application Programming Interface - Java API).
A mquina virtual a base da plataforma Java e ela portada para vrias
plataformas de hardware, mantendo assim a caracterstica portabilidade desta tecnologia.
Quando um desenvolvedor Java escreve um programa como se ele estivesse
escrevendo para a mquina virtual e no para uma arquitetura especfica. a mquina virtual a responsvel por traduzir o cdigo criado pelo programador em um
cdigo compatvel com a arquitetura em que o programa ser executado. Assim,
ela est na camada intermediria entre a aplicao e a plataforma. A mquina
virtual tambm controla tarefas relacionadas com a gerncia de memria, fornecendo segurana contra cdigos maliciosos, e de mltiplos threads de execuo do
programa.
A especificao dizendo o que uma mquina virtual deve apresentar pode ser
R Virtual Machine Specification[LIN & YEL1999].
encontrada no livro The Java
A API Java uma grande coleo de componentes de software que prov
as mais variadas funcionalidades ao programador, como interface grfica com o
usurio, criptografia, conexes entre vrias outras. Ela est agrupada em um conjunto de bibliotecas (pacotes) de classes e interfaces relacionadas [SUN2003A]
[CAM & WAL2002].
A classe Object do pacote java.lang a classe me para todas as outras
definidas pela linguagem.
Um pacote da API Java padro que foi bastante utilizado neste projeto foi o
java.net. Este pacote, em conjunto com o java.io, permite uma manipulao completa de sockets, descritos na seo 2.8. Outro pacote utilizado foi o
java.util, que inclui classes utilitrias (como a manipulao de vetores).
Para construir o jogo foi necessrio a utilizao de vrias threads de execuo
em paralelo e, conseqentemente, de um modo de sincronizao entre elas. A
estrutura para a manipulao de threads encontra-se disponvel no pacote java.
lang, que o principal pacote da API Java. Threads de execuo sero descritas
na seo 2.9.
A Figura 2.3 apresenta a estrutura da plataforma Java.
15

Figura 2.3: A estrutura da plataforma Java.

2.3.3

A plataforma Java na atualidade

A primeira verso de Java liberado pela Sun Microsystems foi chamado de

Java 1.0.2. O 1.0.2 passou a referir a verso do Java Development Kit (JDK) que
inclua tudo que era necessrio para desenvolver e executar programas Java nas
plataformas Windows e Solaris. Aps a verso 1.1, a Sun passou a referir-se as
verses de Java como Java Software Development Kit (JSDK) e a possuir um runtime em separado chamado de Java Run-Time Environment (JRE).
Segundo Enrique Ortiz[ORT & GIG2001], Java 1.0.2 foi notvel por duas coisas:
Definiu o Abstract Windowing Toolkit (AWT), para a criao de interfaces
grficas com o usurio;
Definiu applets, uma maneira na qual os navegadores podem executar aplicativos Java de maneira segura.
A prxima verso foi a Java 1.1, que acrescentou novas caractersticas a tecnologia e corrigiu muitos problemas identificados na verso anterior. Ainda de
acordo com Enrique Ortiz[ORT & GIG2001], as principais mudanas foram:
Melhorias no AWT, atravs do Swing. Agora uma interface construda em
Java totalmente independente de plataforma;
Remote Method Invocation (RMI), permitindo que dois programas Java possam conversar facilmente via rede;
Serializao de objetos;
Compilao just-in-time.
Durante o desenvolvimento da verso 1.2 a Sun resolveu fazer maiores modificaes na maneira como a tecnologia era distribuda e licenciada. Assim, a
16

verso 1.2 foi chamada de Java 2 e uma diviso da plataforma em edies foi realizada. Esta diviso permite organizar melhor o desenvolvimento e crescimento
da tecnologia Java em trs grandes reas:
Servidores;
Desktops;
Pequenos Dispositivos.
Cada edio possui todas as ferramentas e suprimentos necessrios para o desenvolvimento e execuo de aplicativos. Por fim, as edies que fazem parte da
atual plataforma Java 2 so:
Java 2 Platform, Standard Edition (J2SE) [JSE2002], cujo alvo so as aplicaes desktop convencionais;
Java 2 Platform, Enterprise Edition (J2EE) [JEE2002], com nfase no desenvolvimento de aplicaes server-side para empresas com necessidade de
servir seus consumidores, fornecedores e empregados com solues slidas e completas de negcios pela Internet. Projetada para multiusrios e
aplicaes que tem por base a modularizao, reutilizao e padronizao
de componentes. Ela um superconjunto da J2SE e adiciona APIs para a
computao do lado do servidor;
Java 2 Platform, Micro Edition (J2ME) [JME2002], um conjunto de tecnologias e especificaes desenvolvidas para pequenos dispositivos como
smart cards, pagers e telefones celulares. Ela usa um subconjunto dos componentes J2SE, tais como subconjuntos das mquinas virtuais e APIs mais
fracas. Representa um retorno s origens do Java.
A Figura 2.4 ilustra de maneira didtica a relao entre as edies atuais da
plataforma Java 2 e os dispositivos que elas buscam atender. Alguns nomes citados
na figura sero explicados posteriormente neste captulo.
As especificaes para J2SE, J2EE e J2ME so desenvolvidas de acordo com
o Java Community Process (JCP). Uma especificao comea seu ciclo de vida
como uma Java Specification Request (JSR). Um grupo de experts consistindo de
representantes dos interesses de companhias formado para criar a especificao.
O JSR ento ir passar por vrios estgios na JCP at ser terminado. Quem continua decidindo tudo a Sun Microsystems, mas as empresas passam a ter acesso a
revises de produtos e podem dar as suas opinies sobre eles. Maiores informaes
sobre o JCP podem ser encontradas no site oficial[ORT & GIG2003].
17

Figura 2.4: A plataforma Java 2 e seus dispositivos alvos.

2.4

Java 2 Platform, Micro Edition (J2ME)

Esta seo tem o objetivo de apresentar detalhes tcnicos sobre a plataforma

J2ME, focando-se na sua arquitetura e em como utiliz-la para o desenvolvimento
de aplicaes mveis para celulares. Mas, antes de entrar em tais detalhes, interessante apresentar algumas justificativas para a sua escolha neste projeto e as
tecnologias que surgiram antes dele e que, de certa forma, foram a sua origem.

2.4.1

Por que usar J2ME?

A plataforma J2ME utilizada para construir aplicaes smart-client, ou seja,

voltadas para o mercado dos dispositivos com restries de recursos.
H alternativas ao J2ME, que no fazem parte da plataforma Java, que quase
sempre executam mais rpido e tem acesso a maiores capacidades do dispositivo.
No entanto, aplicaes J2ME so portveis, de acordo com a idia principal de
Java, e executam de uma maneira relativamente eficiente, apesar de serem interpretados.
Outra justificativa o fato de J2ME ser considerado um padro industrial, por
ser definido por uma comunidade de desenvolvimento (o JCP) e ser suportado pela
maioria dos vendedores de dispositivos.
Segundo Enrique Ortiz[ORT & GIG2001] e John Muchow[MUC2002], as vantagens de se utilizar J2ME podem ser resumidas em:
O J2ME uma plataforma portvel, o que significa que um programa pode
ser executado em aparelhos de diversos fabricantes sem nenhuma alterao;
18

 J2ME suportado por vrios fabricantes: Motorola, RIM, Ericsson, Nokia,

Panasonic, Nextel entre outros;
Suporte a aplicaes standalone e baseadas em servidor;
Alta integrao com as outras plataformas Java;
Utiliza a linguagem Java, a qual fcil de aprender e utilizar para a escrita
de cdigos;
J2ME baseado em padres abertos e definido pelo JCP.
Com a introduo do J2ME, os pequenos dispositivos de consumo, como celulares, podem executar aplicaes que no sejam somente aquelas que vem de
fbrica.

2.4.2

Um pouco de histria

O J2ME no a primeira aventura da Sun Microsystems no mundo dos dispositivos embutidos e dos handhelds, mas sim uma volta ao objetivo inicial da empresa
ao iniciar o projeto que deu origem ao Java. Ele o descendente das primeiras plataformas da Sun para pequenos dispositivos: a parte Oak do projeto Green (no
incio de 1990), JavaCard (1996), PersonalJava (1997), EmbeddedJava (1998) e,
mais recentemente, o Spotless System e o KVM (1999). Hoje, a plataforma J2ME
atinge todos os tipos de dispositivos eletrnicos, dos low-end aos high-end, com
uma nica plataforma Java. O JavaCard ainda est separado do J2ME, embora
altamente relacionado a ele1 .
Em seguida, sero apresentados maiores detalhes das tecnologias anteriores ao
J2ME citadas acima.
Oak - O projeto Green: o surgimento da tecnologia Java deu-se com o Oak,
uma linguagem de programao orientada a objetos, independente de mquina e
um ambiente para a programao de dispositivos de consumo eletrnicos. O Oak
foi uma linguagem interpretada e projetada para executar em dispositivos com
restries de recursos. Mas, como j apresentado, seu surgimento aconteceu em
um mercado que no estava preparado para seus novos ideais. A Sun, por sua vez,
no mais dedicou esforos na tecnologia Java para dispositivos eletrnicos at a
chegada do PersonalJava.
1

Esta seo foi baseada no artigo de Enrique Ortiz[ORT2002A] sobre J2ME, onde o autor dedica
um pouco do seu espao para falar sobre o mundo wireless da Sun antes da chegada do J2ME e como
se deu o seu surgimento.

19

PersonalJava: esta nova tecnologia buscou atingir os dispositivos com capacidade de conexo a algum tipo de rede e com interface grfica, tais como os PDAs
e outros dispositivos baseados na web.
O ambiente de aplicaes PersonalJava, baseado primeiramente nas APIs do
JDK1.1 (com poucos pacotes da JDK1.2), requer suporte completo tanto para a
especificao da linguagem Java como da mquina virtual Java. A atual e talvez a
ltima verso da especificao do PersonalJava a verso 1.2a.
Esta tecnologia deixar de surgir como uma parte separada da plataforma Java,
pois na prxima reviso ela ser includa no Personal Profile, uma parte do J2ME
que ser discutida posteriomente neste captulo.
EmbeddedJava: o ambiente de aplicaes EmbeddedJava foi criado com o objetivo de atingir os dispositivos embutidos com funcionalidade dedicada e restries de memria, tais como dispositivos de controle de processos ou automotivos
(como um sistema de localizao). Baseado na JDK1.1, este ambiente de execuo
muito similar ao ambiente de execuo PersonalJava, mas ao invs de definir um
subconjunto especfico da plataforma Java ele permite a companhias ou indivduos
licenciarem a tecnologia para o uso somente dos componentes necessrios para um
dispositivo em particular. A ltima verso do EmbeddedJava a verso 1.1.
As especificaes EmbeddedJava deixam que o licenciado escolha quais so
as caractersticas da plataforma Java que eles querem dar suporte em seus dispositivos. A idia que eles no podem expor estas caractersticas para uso por uma
terceira parte, somente os seus prprios desenvolvedores podem escrever aplicaes que executem neste dispositivo.
A Sun descontinuou a especificao EmbeddedJava e parou de oferecer suporte para ela, aconselhando queles que usam EmbbededJava a procurarem a
configurao e profile J2ME que mais se adequarem as suas necessidades2 .
JavaCard: a tecnologia JavaCard complementar a do J2ME. Ela adapta a
plataforma Java para o uso em smart cards, um ambiente muito especializado, com
severas restries de memria e processamento, no adequado para a programao
de propsito geral. Um tpico dispositivo JavaCard tem uma CPU de 8 a 16 bits,
de 1 a 5MHz e com memria da ordem de 1KB de RAM e 32KB de memria no
voltil (EEPROM ou flash).
Aplicaes comuns da tecnologia JavaCard (chamadas applets JavaCard) incluem identificao digital, armazenamento seguro e cartes Subscriber Identity
Module (SIM), que podem ser inseridos em diferentes celulares para fazer ligaes utilizando a prpria conta pessoal. Os celulares GSM utilizam este tipo de
2

Os conceitos de configurao e profile em J2ME sero explicados posteriormente neste captulo.

20

carto para a identificao do cliente.

O Spotless System e a KVM: A mquina virtual K (KVM), o resultado de
um projeto de pesquisa da Sun conhecido por Spotless System, foi lanada para o
pblico em 1999. Este projeto adaptava a tecnologia Java para dispositivos com
srias restries de recursos de uma maneira diferente do ambiente de aplicaes
PersonalJava, mas um pouco similar ao ambiente de execuo JavaCard.
Como descrito no The Spotless System, um artigo tcnico de Antero Taivalsaari, Bill Bush e Doug Simon, o time de pesquisas tinha o seguinte objetivo:
construir a menor mquina virtual Java possvel e completa, que deveria suportar
um conjunto completo de bytecodes, class loading, bibliotecas padres no grficas e suporte a arquivos de classe bsicos para pequenas aplicaes. A equipe
concentrou-se na portabilidade e tamanho de cdigo ao invs de rapidez na execuo.
Quando foi publicada, a KVM foi bem recebida pela comunidade Java. Hoje a
Spotless System est envolvida na J2ME Connected Limited Device Configuration,
que ser apresentada na prxima seo.

2.4.3

Arquitetura

A plataforma J2ME no define uma nova linguagem. Ela faz uma adaptao
da tecnologia Java existente para handhelds e outros dispositivos embutidos.
J2ME mantm a compatibilidade com a J2SE sempre que possvel. De fato,
ele procura ao mesmo tempo remover partes desnecessrias das outras plataformas e definir novas classes para as extremas limitaes dos pequenos dispositivos
[ORT2002A].
Ao contrrio do J2SE, J2ME no uma pea de software e nem uma especificao nica. Ao invs disso, ele uma coleo de tecnologias e especificaes
que foram projetadas para diferentes partes do mercado de pequenos dispositivos.
[SUN2003A].
O J2ME possui objetivos diferentes quando comparado com J2SE e J2EE,
resultando em uma arquitetura muito diferente. Segundo James White e David
Hemphill[WHI & HEM2002], os objetivos chave que guiam esta arquitetura so:
Proporcionar suporte a uma grande variedade de dispositivos com diferentes
capacidades. Estes dispositivos freqentemente variam em caractersticas
como interface com o usurio, armazenamento de dados, conectitividade a
rede, largura de banda, memria, consumo de energia, segurana e requisitos
de desenvolvimento;
21

 Proporcionar uma arquitetura que possa ser otimizada para dispositivos pequenos e com alta restrio de recursos;
Foco em dispositivos que podem ser altamente personalizados, freqentemente utilizados apenas por uma nica pessoa;
Proporcionar conectitividade a rede atravs de uma grande variedade de servios e capacidades de acesso. A conectitividade a rede fundamental para
os dipositivos que fazem parte do campo de atuao de J2ME;
Proporcionar uma maneira de entregar as aplicaes e dados sobre uma rede,
principalmente wireless, para o cliente;
Proporcionar uma maneira de se desenvolver aplicaes para dispositivos
sem ter que se preocupar com o modelo e fabricante para o qual se est
desenvolvendo;
Maximizar a atuao de Java entre as vrias plataformas possveis e, ao
mesmo tempo, utilizar das vantagens nicas de cada dispositivo.
Para atender a estes objetivos o J2ME foi dividido em configuraes e profiles3 .
Uma configurao define o ambiente de execuo J2ME bsico. Este ambiente inclui uma mquina virtuale um conjunto de classes derivadas da plataforma
J2SE. Cada configurao est voltada para uma famlia especfica de dispositivos
que possuem capacidades similares. Uma configurao, por exemplo, pode ser
projetada para dispositivos que tem menos que 512KB de memria e uma conexo
intermitente a rede.
Um profile construdo sobre uma configurao de maneira a extend-la atravs da adio de APIs mais especficas para criar um ambiente completo para
a construo de aplicaes. Em outras palavras, os profiles proporcionam classes que esto voltadas a usurios de um tipo de dispositivo mais especfico que o
abrangido por uma configurao e cuja algumas funcionalidades (como a interface
com o usurio) no foram cobertas por ela. Nem todos os dispositivos suportam
todos os profiles. No Japo, por exemplo, a NTT DoCoMo lanou um grande
nmero de celulares baseados em CLDC, mas com seu prprio profile. Assim,
aplicaes escritas para estes dispositivos no iro trabalhar com celulares que no
foram desenvolvidos pela NTT DoCoMo [ORT & GIG2001].
3
O termo profiles, apesar de ser em ingls, ser altamente utilizado neste texto, devido ao seu uso
consagrado, ao invs de perfis, sua traduo para o portugus.

22

As APIs adicionadas por um profile a uma configurao so direcionadas a

uma certa classe de dispositivos. Assim, um profile para o mercado de telefones
celulares separado de um direcionado para o mercado de organizadores pessoais,
mas todos eles trabalham com a mesma configurao de dispositivo mvel.
Embora uma configurao descreva uma mquina virtual e um conjunto bsico
de APIs, ela no suficientemente especfica para possibilitar a construo de
aplicaes completas. Profiles geralmente incluem APIs para o ciclo de vida da
aplicao, interface com o usurio e armazenamento persistente.
Resumindo, um dispositivo que venha a utilizar a tecnologia J2ME deve implementar a pilha de software genrica apresentada na Figura 2.5. Esta figura no
apresenta as APIs especficas do fabricante, j que estas no fazem parte das configuraes e profiles padro. Essas APIs devem ser pensadas como extenses do
prprio fabricante aos profiles implementados. claro que um desenvolvedor que
resolva optar por utilizar algum pacote desta API estar perdendo portabilidade
[ORT2002A].

Figura 2.5: Pilha de software genrica a ser implementada por um dispositivo

J2ME.
Atualmente, duas configuraes esto definidas: a Connected Device Configuration(CDC)4 e a Connected Limited Device Configuration (CLDC)5 . Ambas
4

No restante desta monografia, quando se utilizar a sigla CDC ser para indicar uma referncia a
Connected Device Configuration
5
No restante desta monografia, quando se utilizar a sigla CLDC ser para indicar uma referncia
a Connected Limited Device Configuration

23

objetivam cobrir dispositivos com alguma capacidade de conexo, no importando

se um link fixo de alta velocidade ou um link wireless de baixa velocidade.
O CLDC[CLC2003] abrange os pequenos dispositivos: telefones celulares,
Personal Digital Assistants (PDAs) e pagers interativos. Estes dispositivos formam uma classe de produtos que possuem limitaes srias de memria, processamento, consumo de energia e largura de banda.
O CDC[CDC2003] foi projetado para dispositivos mais robustos, em termos
de memria e poder de processamento, e com melhor conexo a rede. Alguns
PDAs (como os da srie Pocket PC da Microsoft) e laptops so bons exemplos de
dispositivos CDC.
A linha que separa os dispositivos CDC e CLDC no muito clara, fazendo
com que em algumas situaes, esta distino seja feita a critrio do fabricante do
aparelho. Segundo Enrique Ortiz[ORT & GIG2001], talvez a principal diferena
entre o CDC e o CLDC est no fato de que o primeiro exige uma mquina virtual
compatvel com a implementada pelo J2SE. A Sun lanou uma nova mquina virtual Java para a configurao CDC, a Compact VM (CVM), que mais portvel e
eficiente que a mquina virtual padro.
Alm das configuraes e dos profiles, existem os chamados pacotes opcionais. Segundo Eric Giguere [GIG2002], um pacote opcional um conjunto de
APIs, mas no chega a ser como um profile. Eles no definem um ambiente de
execuo completo e so sempre utilizados em conjunto com uma configurao
ou um profile.
Os pacotes opcionais proporcionam suporte a caractersticas de dispositivos
que no so to universais a ponto de serem includas em um perfil ou tem que ser
compartilhadas por diferentes especificaes. Estes pacotes tambm so gerenciados de acordo com as normas do Java Community Process.
Alguns pacote opcionais atualmente disponveis so:
JSR 66: RMI Optional Package. Remote method invocation (RMI), uma
caracterstica do J2SE que permite que objetos escritos em Java executando
em uma mquina virtual possam chamar mtodos Java de objetos que esto
executando em outra mquina virtual. Este pacote um subconjunto da
especificao padro e est disponvel para profiles baseados em CDC;
JSR 120: Wireless Messaging API. Proporciona o envio e recebimento de
mensagens atravs do servio Short Message Service (SMS);
JSR 135: Mobile Media API. Proporciona a capacidade de reproduo e
gravao de contedo multimdia;
24

 JSR 169: JDBC for CDC/FP. JDBC a maneira atravs da qual as aplicaes Java padres se comunicam com banco de dados relacionais. Este
pacote cria uma verso otimizada e reduzida do JDBC padro para o profile
CDC.
As prximas subsees apresentam as configuraes e profiles mais importantes que integram a plataforma J2ME 6 .

2.4.4

J2ME Connected Limited Device Configuration (CLDC)

O CLDC no requer muitos recursos de sistema, podendo ser executado em

dispositivos com 128KB ou mais de memria no voltil (persistente) e 32KB ou
mais de memria voltil. Dispositivos CLDC requerem acesso a qualquer tipo de
conexo de rede, por isso o nome connected device, embora ela possa ser intermitente e de baixa velocidade. Geralmente, os processadores alvos deste tipo de
configurao vo de 16 a 32 bits.
O CLDC define requisitos para o ambiente Java. O primeiro o suporte completo a linguagem Java, exceto por algumas diferenas. Estas diferenas, enumeradas por Enrique Ortiz[ORT & GIG2001], so:
Suporte inexistente a pontos flutuantes. Tipos de ponto flutuante ou constantes no so suportados, assim como nenhuma das classes do ncleo do
J2SE que trabalham especificamente com tais valores, como a java.lang.
Float e a java.lang.Double. Em conseqncia, mtodos que recebem ou retornam pontos flutuantes tambm foram retirados;
Sem suporte a finalizao de objetos. Para simplificar a tarefa do coletor
de lixo automtico, o mtodo finalize foi removido de java.lang.
Object. O coletor de lixo ir simplesmente atuar sobre objetos no referenciados;
Erros de execuo so tratados de uma maneira dependente da implementao. Erros de execuo so excees lanadas pela mquina virtual
e que so subclasses de java.lang.Error. O CLDC define somente
6

As caractersticas da configurao CLCD e das duas verses do profile MIDP sero apresentadas
em maiores detalhes, pois esta organizao a mais adequada para o desenvolvimento de aplicaes
para celulares. Como o objetivo principal deste projeto analisar a tecnologia J2ME no desenvolvimento de jogos multiplayers para celulares, as anlises, discusses e concluses sero feitas sobre
esta organizao. Assim, justifica-se a importncia de defini-las corretamente e de maneira ampla.

25

trs classes de erros: java.lang.Error, java.lang. OutOfMemoryError e java.lang.VirtualMachineError. Qualquer outra

exceo tratada pela mquina virtual Java de uma maneira dependente da
implementao, a qual geralmente representa o trmino da aplicao.
O segundo requisito o suporte completo a mquina virtual Java exceto pelas
seguintes diferenas, tambm enumeradas por Enrique Ortiz[ORT & GIG2001]:
Suporte inexistente a pontos flutuantes. Se no existe suporte na linguagem, no h necessidade de se prover suporte na mquina virtual;
Sem suporte a finalizao de objetos e referncias fracas. Para simplificar
a tarefa do coletor de lixo automtico;
Sem suporte a JNI ou qualquer outra interface de alto nvel que depende delas. Em particular, no h serializao de objetos em CLDC. A
mquina virtual pode ter uma interface nativa, mas no requerido e no
deve ser uma interface padro J2SE;
Sem suporte a grupo de threads. Threads so suportadas, mas grupos
de threads no so. A mquina virtual pode escolher implementar threads
deixando-as ao cuidado do sistema operacional ou por realizar uma prpria
troca de contexto;
Tratamento de erros definidos pela implementao. De acordo como foi
apresentado anteriormente;
Verificao de classes realizada de maneira diferente. O processo padro de verificao de classes computacionalmente muito exigente, por
isso, uma alternativa foi definida. O sistema alternativo transfere a maior
parte deste processo para um passo de pr-verificao que ocorre no computador desktop e no no dispositivo. O aparelho ainda executa uma segunda
etapa de pr-verificao, mas muito mais simples que a anterior.
O terceiro requisito que todas as classes que so escritas ou herdadas de
J2SE devem ser subconjuntos das classes da verso J2SE 1.3. Mtodos podem
ser omitidos, mas nenhum mtodo pblico novo ou conjunto de dados pode ser
adicionado.
O requisito final que as classes definidas pelo CLDC e seus profiles devem
estar no pacote javax.microedition ou em seus subpacotes. Desta maneira
torna-se fcil identificar classes que so especficas do CLDC.
26

O CLDC inclui classes e interfaces herdadas de trs pacotes J2SE:

java.lang;
java.io;
java.util.
Como pode ser notado, a maioria das classes J2SE foram excludas, inclusive pacotes importantes, como java.awt (interface grfica com o usurio),
java.net (utilitrios para acesso a rede) e java.sql (utilizao de consultas
SQL). At mesmo nos pacotes que foram incudos, algumas classes foram retiradas, juntamente com muitos mtodos das classes que ficaram.
O pacote java.io sofreu uma otimizao enorme, pois apenas as suas definies de classe j excedem o limite de espao definido para dispositivos CLDC.
Por isso, apenas as classes mais utilizadas permaneceram na verso da plataforma
J2ME, mas ainda tiveram que sofrer algumas modificaes em sua estrutura.
Alm dos pacotes citados anteriormente, um nico pacote foi escrito especialmente para CLDC, o javax.microedition.io. As classes que fazem parte
deste pacote so ditas parte do Generic Connection Framework ou apenas GCF.
O GCF abstrai os conceitos de arquivos, sockets, requests HTTP e outros mecanismos de entrada de uma maneira simples, voltada para os dispositivos com
srias restries de recursos. Em outras palavras, o GCF proporciona a mesma
funcionalidade das classes java.io e java.net.
importante ressaltar que o CLDC apesar de definir o GCF no obriga o suporte para qualquer tipo de protocolo. O suporte a protocolos realizado a nvel
de profile.
A Figura 2.6 ilustra o conjunto de interfaces que fazem parte do pacote javax.microedition.io definidas pela CLDC.

Figura 2.6: Classes que fazem parte do Generic Connection Framework (GCF),
segundo a especificao CLDC.
27

A seguir sero descritas as principais caractersticas das interfaces que fazem

parte do GCF:
A interface Connection corresponde ao tipo de conexo genrica mais
bsica existente. Somente o mtodo close definido. Nenhum mtodo
open definido nesta classe pelo fato de todo o processo de abertura de objetos do tipo Connection ser definido atravs do mtodo esttico open
da classe Connector, tambm do pacote javax.microedition.io.
A flexibilidade do GCF encontra-se no fato de se poder utilizar qualquer implementao de protocolo para uma dada conexo, bastando que se carregue
as suas definies atravs do mtodo esttico forName da classe Class
do pacote java.lang.
O trecho de cdigo mostrado pela Figura 2.7 ilustra o processo de abertura
de conexes.

Figura 2.7: Abertura de conexo utilizando o mtodo open da classe Connector.

Note que ao se abrir uma conexo atravs do mtodo open, da classe Connector, o resultado obtido um objeto do tipo Connection, que deve
ser posteriormente convertido, atravs de um type casting, pelo tipo de co28

nexo a ser utilizado. Se houver a necessidade de se carregar o protocolo

de comunicao na memria, deve-se descomentar a linha com o comando
forName e passar para este mtodo o caminho onde se encontra as definio do protocolo desejado.
A interface InputConnection define as caractersticas que um fluxo de
conexo de entrada deve possuir;
A interface OutputConnection semelhante a InputConnection,
com a diferena que ela agora manipula fluxos de sada.
A interface StreamConnectionNotifier define as caractersticas que
um notificador de conexes deve possuir. Esta classe define apenas um mtodo, que tem a funo de ouvir conexes e retornar um objeto que pode
ser utilizado para trocar dados entre os elementos conectados. Pode ser utilizado para a construo de aplicaes servidoras, ou seja, que precisam
escutar por requisies de clientes.
A interface DatagramConnection define as caractersticas que uma conexo por datagramas deve possuir, mas a sintaxe para o endereamento de
datagramas definida apenas a nvel de profile.
A interface StreamConnection define as caractersticas que um protocolo que suporta conexes bi-direcionais deve possuir. Note que ela herda
das interfaces que definem um fluxo de entrada e de sada, mas no implementa nenhum mtodo novo.
A interface ContentConnection apresenta alguns mtodos para manipular o contedo que est passando atravs do fluxo de comunicao.
Alm destas interfaces existem outras classes que so: DataInput, DataOutput e Datagram. As duas primeiras definem os mtodos para se converter
os dados de um fluxo binrio em um tipo primitivo de dados Java, enquanto que
a ltima herda das outras de maneira a prover as abstraes necessrias para um
pacote do tipo datagrama.
Esto disponveis duas mquinas virtuais para esta configurao, a K e a CLDC
HotSpot. A mquina virtual K consiste de uma implementao da mquina virtual
Java destinada execuo em dispositivos com grandes restries de recursos (memria e processamento). O K na mquina virtual indica que ela trabalha com uma
memria total de pouco mais de cem kilobytes, na maioria das vezes, cerca de
29

128 KB. As especificaes dos dispositivos apropriados para trabalhar com esta
mquina so: processador de 16/32 bits RISC/CISC com pelo menos de 160KB
de memria total, sendo 128 KB para a mquina virtual e o restante destinado s
aplicaes. Esta mquina foi desenvolvida na linguagem C e objetiva ser completa
(de acordo com a especificao CLDC) e to rpida quanto possvel (executando
de 30% a 80% mais rpido que a mquina padro do J2SE). A KVM, como conhecida esta mquina virtual, apenas uma implementao de referncia da Sun,
ou seja, ela foi construda apenas para exemplificar a especificao CLDC. Assim, os fabricantes de dispositivos podem escolher port-la para seus aparelhos ou
simplesmente desenvolver sua prpria mquina virtual.
A mquina virtual CLDC HotSpot foi projetada para a nova gerao de dispositivos mveis que possuem grande memria disponvel. As especificaes
dos dispositivos que podem utilizar esta mquina so: processadores de 32 bits
RISC/CISC com memria de 512KB a 1MB.
Atualmente, a verso da configurao CLDC mais utilizada a 1.0, que possui
as caractersticas citadas acima. No entanto, encontra-se em processo de desenvolvimento a verso 1.1, que acrescentar caractersticas to importantes quanto o
suporte a pontos flutuantes.

2.4.5

Os profiles para o CLDC

Esto disponveis dois profiles para esta configurao, o Mobile Information

Device Profile (MIDP verses 1.0 e 2.0)7 e o Personal Digital Assistant Profile
(PDAP). O primeiro voltado para o mercado de telefones celulares, enquanto
que o segundo busca aproveitar melhor as caractersticas dos PDAs. A Sun, no
entanto, possui uma implementao do profile MIDP verso 1.0 para o sistema
Palm OS conhecida por MIDP4Palm8 .
Em MIDP uma aplicao chamada de MIDlet e as duas verses do profile definem o seu ciclo de vida de maneira idntica. Assim, a primeira coisa
a se fazer ao desenvolver MIDlets herdar a classe MIDlet do pacote javax.microedition.midlet. Esta classe define os mtodos que representam
os estados do ciclo de vida de uma aplicao.
A mquina de estados da MIDlet projetada de maneira a garantir um ambiente de execuo de aplicaes consistente e prximo das expectativas dos fabri7

Durante o restante da monografia, a sigla MIDP ser por vrias vezes utilizada como uma referncia a Mobile Information Device Profile.
8
Esta seo encontra-se fortemente baseada na documentao da API das duas verses do profile
MIDP.

30

cantes e usurios, mais especificamente:

a latncia no processo de inicializao de uma aplicao deve ser curta;
deve ser possvel colocar a aplicao em um estado no qual ela se encontra
inativa. Isto permite o atendimento de chamadas enquanto se executa algum
programa e a confiana de que ao terminar a ligao o estado da MIDlet ser
corretamente recuperado;
a finalizao da MIDlet deve ser possvel em qualquer momento.
Os estados vlidos para uma MIDlet so controlados pelo application manager
software e podem ser resumidos em:
ativo, a aplicao est executando normalmente;
pausado, a aplicao ainda no comeou a executar ou encontra-se em um
estado de pausa;
destrudo, a aplicao foi terminada.
Uma tpica seqncia de execuo de uma MIDlet ocorre da seguinte maneira:
1. O application management software cria uma nova instncia da MIDlet.
Nesta situao o construtor padro da MIDlet chamado e ela entra no estado de pausa.
2. O application management software decide o momento apropriado para iniciar a execuo da MIDlet, ento ele chama o mtodo MIDlet.startApp
para coloc-la no estado ativo. Neste ponto a MIDlet coleta os recursos de
que necessita para iniciar a sua tarefa.
3. O application management software decide que precisa executar alguma tarefa. Assim, ele envia um sinal para a MIDlet parar de executar os seus
servios temporariamente atravs de uma chamada ao mtodo MIDlet.
pauseApp. A MIDlet pode ento liberar alguns recursos para o sistema.
Quando a aplicao puder voltar a executar, uma chamada ao mtodo MIDlet.startApp refeita.
31

4. O application management software determina que a MIDlet no mais

necessria. Assim, ele envia um sinal para ela atravs do mtodo MIDlet.destroyApp dizendo que ela uma candidata a ser destruda. A
MIDlet salva seu estado e libera todos os recursos do sistema que havia
alocado para si.
A Figura 2.8 ilustra o processo tpico de trocas de estados que uma MIDlet
pode sofrer.

Figura 2.8: Transies de estados em uma MIDlet.

A interface da classe MIDlet define os seguintes mtodos:
pauseApp, a MIDlet deve liberar recursos temporrios e tornar-se passiva;
startApp, a MIDlet deve requerer todos os recursos necessrios e iniciar
a sua execuo;
destroyApp, a MIDlet deve salvar seu estado e liberar todos os recursos;
notifyDestroyed, a MIDlet notifica o application management software que ela deseja ser terminada;
notifyPaused, a MIDlet notifica o application management software
que ela deseja ser pausada.
resumeRequest, a MIDlet pergunta ao application management software se ela pode iniciar novamente a sua execuo;
32

 getAppProperty, obtm a propriedade nome da MIDlet.

A figura 2.9 apresenta um trecho de cdigo que ilustra os estados do ciclo
de vida de uma MIDlet. Note que todos os mtodos referentes ao estado de uma
MIDlet devem ser obrigatoriamente implementados.

Figura 2.9: Trecho de cdigo ilustrando o corpo de uma MIDlet.

O Mobile Information Device Profile verso 1.0[MID2003] (JSR-37) trabalha com dispositivos celulares. Segundo Enrique Ortiz[ORT2002A], ele o
primeiro e mais maduro profile J2ME e suportado pelos principais fabricantes de
dispositivos mveis, como Motorola, Nokia e Ericsson. Os requisitos de hardware
e software para ele so:
Hardware:
Tela de tamanho mnimo de 96x54 pixels;
33

 Um dos seguintes mecanismos de entrada: teclado de telefone, teclado

QWERTY ou toque na tela;
Capacidade de comunicao bidirecional;
Pelo menos 128KB de memria no voltil para o software MIDP, 8KB
para armazenamento persistente e 32KB para o ambiente de execuo.
Esta quantidade adicional ao CLDC e a qualquer API especfica do
fabricante.
Software, caractersticas que o sistema operacional deve possuir para adotar
o MIDP 1.0:
Converso da entrada do usurio nos eventos apropriados;
Gerncia do ciclo de vida de uma aplicao;
Maneiras de se acessar a memria no voltil, de acessar a rede e escrever na tela.
Os itens a seguir, extrados do livro de Enrique Ortiz[ORT & GIG2001], resumem o que o profile MIDP 1.0 pode e no pode fazer:
Interface com o usurio. O MIDP implementa um conjunto simples de
classes (definidas em javax.microedition.lcdui e quase sempre
referidas como LCDUI) para a criao de interfaces em celulares.
O MIDP 1.0 define dois nveis de interface com o usurio, chamados de
interface com o usurio de baixo nvel e alto nvel.
A interface com o usurio de alto nvel define uma aplicao em termos
abstratos. Ao invs de controlar exatamente o que ser desenhado na tela
e como ser feito o mapeamento dos botes pressionados pelo usurio, ela
define classes genricas que so portveis ao longo de todos os dispositivos
MIDP, deixando que cada implementao em particular decida como portar
estas classes de maneira adequada ao aparelho. No se tem acesso direto
a tela e nem aos eventos gerados pela entrada do usurio. Este tipo de interface mais til para o desenvolvimento de aplicaes enterprise, como
aplicaes de e-commerce.
A interface com o usurio de baixo nvel, por outro lado, prov acesso direto
a tela e aos eventos de entrada. A aplicao pode desenhar na janela atravs
do uso de ferramentas de desenho de primitivas 2D e notificada quando
o usurio realiza alguma entrada. Esta liberdade til quando se est desenvolvendo um jogo, mas no garante portabilidade entre os dispositivos
34

MIDP. Assim, o desenvolvedor deve ser capaz de construir a aplicao da

maneira mais portvel possvel.
Interfaces com o usurio de alto e baixo e nvel podem ser utilizadas em uma
mesma aplicao, mas nunca ao mesmo tempo;
A Figura 2.10 apresenta as classes que fazem parte do pacote javax.
microedition.lcdui.

Figura 2.10: Classes que fazem parte do pacote javax.microedition.

lcdui, para manipulao de interfaces. As setas em vermelho indicam uma relao de uso da classe que aponta a seta pela classe alvo dela. A classes que no
apresentam nenhuma relao de herana e no so interfaces herdam diretamente
da classe Object do pacote java.lang.
As interfaces implementadas pelo pacote javax.microedition.lcdui
so:
Choice, define a API para componentes que implementam seleo a
partir de um determinado nmero de alternativas;
CommandListener, utilizada por aplicaes que precisam tratar
eventos de alto nvel.
ItemStateListener, utilizada para receber eventos que indicam
mudanas no estado interno de um item de formulrio.
35

A seguir esto relacionadas as principais caractersticas das classes do pacote javax.microedition.lcdui:

Display, representa o gerenciador de telas e dispositivos de entrada
do sistema;
Displayable, objeto que tem a capacidade de ser colocado em uma
tela;
Command, encapsula as propriedades de um comando, mas no o seu
comportamento, que definido pela interface CommandListener.
Font, permite a manipulao de fontes;
Image, permite manipular imagens;
Screen, superclasse comum a todos componentes de alto nvel.
Canvas, classe bsica para a escrita de aplicaes que precisam manipular eventos de baixo nvel e chamar primitivas grficas para desenhar
na tela;
Graphics, define os mtodos para se desenhar em um Canvas.
Possui suporte a primitivas 2D de desenho;
Ticker, implementa a capacidade de se inserir um texto rolvel ao
longo da tela;
TextBox, representa uma tela onde o usurio pode inserir e editar
textos;
List, uma tela contendo uma lista com um conjunto de escolhas;
Alert e AlertType, proporcionam a capacidade de utilizao de
uma tela capaz de mostrar ao usurio dados enquanto ele espera pelo
resultado de algum processamento;
Form, corresponde a uma tela que contm uma mistura de itens arbitrrias: imagens, campos de textos editveis ou no, campos de data e
grupos de listas;
Item, superclasse dos elementos que podem ser inseridos em um
Form ou Alert;
ImageItem, componente que permite a insero de uma imagem em
um Form ou Alert;
DateField, componente editvel para a apresentao de informaes de datas e tempo (calendrio);
36

 StringItem, utilizado para apresentar uma String;

TextField, campo de texto editvel;
ChoiceGroup, implementa a mesma funcionalidade de um List
para um Form;
Gauge, representa uma barra grfica que indica a completude de uma
tarefa;
O trecho de cdigo apresentado pela Figura 2.11 ilustra a utilizao de alguns elementos de alto nvel do pacote LCDUI.

Figura 2.11: Cdigo que apresenta a utilizao de alguns elementos da interface

de alto nvel.
Este pequeno cdigo tem a funo de apresentar na tela do celular a mensagem Hello, MIDP!. Note que as linhas 16, 20 e 22 implementam os
mtodos obrigatrios que correspondem ao estado de uma MIDlet e a linha
2 importa o pacote javax.microedition.midlet, que apresenta as
definies de uma MIDlet.
A linha 1 importa o pacote javax.microedition.lcdui, que utilizado para a manipulao de interfaces. A linha 6 informa que esta classe
ser responsvel por tratar eventos relacionadas a objetos Commands.
A construo da interface ocorre dentro do construtor da MIDlet, a partir da
linha 10 at a 13, onde um objeto de nome mMainForm, do tipo Form,
37

instanciado. Aps a instanciao, um Item, do tipo StringItem, contendo a frase a ser exibida no celular adicionado ao objeto mMainForm,
seguido por um objeto Command. A linha 13 diz a MIDlet qual classe ir
responder aos eventos do tipo Command. Neste exemplo a prpria classe
ir tratar este tipo de evento.
Na linha 17, obtm-se uma referncia ao objeto Display que utilizada
para setar a tela atual para mMainForm, que por ser do tipo Screen pode
ser apresentado no display do dispositivo.
A sada deste programa pode ser vista na Figura 2.12, que apresenta a captura de uma tela de celular.

Figura 2.12: Resultado da execuo, em um emulador de celular, do cdigo da

Figura 2.11. Em a vemos o celular apresentando as aplicaes disponveis para
serem ativadas e em b a sada do cdigo.
Persistncia de dados. Qualquer tipo de aplicao requer uma maneira de
gravar informaes de maneira a poder acess-las posteriormente. Com as
aplicaes para dispositivos mveis no diferente, mas como fazer para
armazenar dados em aparelhos MIDP. Existem duas alternativas, a primeira
se refere ao armazenamento, atravs da utilizao da rede, em um banco
de dados. O problema o custo de acesso a rede e o fato de ela no estar
38

sempre disponvel. A segunda, e exigida pela especificao MIDP 1.0, o

armazenamento local.
O MIDP 1.0 define um conjunto de classes e interfaces (em javax. microedition.rms) chamadas Record Management System (RMS) para
armazenamento local. O RMS implementado como um conjunto de registros e torna disponvel diversas funes para lidar com estes regitros, inclusive funes de ordenao. O acesso a um registro individual feito atravs
de ndices e a leitura e escrita so operaes atmicas que utilizam vetores
de bytes para trabalhar com os dados. Uma caracterstica importante que
os dados armazenados por uma aplicao no podem ser acessados por outra
aplicao;
Conectividade wireless. Como j apresentado, o GCF definido pela CLDC
no requer suporte a qualquer tipo de protocolo de comunicao, seja ele
para acesso a dados locais, a portas seriais ou a rede. O MIDP 1.0, por outro
lado, requer suporte ao acesso bidirecional a rede e implementa obrigatoriamente um protocolo.
O protocolo implementado pelo MIDP 1.0 um subconjunto do HTTP 1.1.
Este protocolo o mesmo utilizado por um navegador web e habilita uma
aplicao a se comunicar com qualquer servidor web na . O HTTP um protocolo do tipo request-response, mas pode ser utilizado para comunicao
bidirecional, com a nica restrio de que o cliente deve iniciar a conversa.
Os demais protocolos existentes, como datagramas e sockets, no so obrigatrios e nem mesmo definidos pela especificao MIDP 1.0, mas isso no
impede que os fabricantes de aparelhos os implementem atravs do GCF ou
de bibliotecas prprias. A questo que como o protocolo HTTP o nico
obrigatrio, ele o nico que garante a portabilidade;
A Figura 2.13 apresenta as modificaes feitas na estrutura de interfaces do
GCF pelo MIDP 1.0.
Como pode ser notado a nica modificao realizada est na presena da
classe HttpConnection que herda de ContentConnection e prov
as funcionalidades do protocolo HTTP para os celulares.
Suporte a imagens. O nico tipo de imagem aceito pelo MIDP 1.0 o
padro PNG. Um detalhe que a implementao de transparncia no
obrigatria;
39

Figura 2.13: Modificaes feitas no GCF pelo profile MIDP verso 1.0. As novas
interfaces implementadas encontram-se circuladas de vermelho.
Classes adicionadas do J2SE pelo MIDP 1.0. As classes java.lang.
IllegalStateException, java.util.Timer e java.util. TimerTask foram includas de maneira a possibilitar a escrita de cdigo que
executa em threads de background em tempos especficos;
APIs de acesso ao sistema. O MIDP 1.0 no possui classes que permitem
o acesso direto as caractersticas de um dispositivo, como gerenciamento de
energia e telefonia;
Segurana. O MIDP 1.0 no acrescenta nenhum pacote com mecanismos
de segurana ao CLDC. Em particular, apesar de suportar o protocolo HTTP
no suporta o protocolo HTTPS, que a verso segura do HTTP.
Resumindo, os pacotes que fazem parte da API do MIDP 1.0, excludos os
implementados pelo CLDC, so:
javax.microedition.lcdui, interface com o usurio;
javax.microedition.rms, armazenamento persistente;
javax.microedition.midlet, ciclo de vida da aplicao;
javax.microedition.io, acesso a rede e incluso de suporte ao protocolo HTTP.
O Mobile Information Device Profile verso 2.0[MID2003] (JSR-118) acrescentou diversas caractersticas e melhorias a especificao MIDP 1.0, mas continuou com o objetivo da primeira verso de ser um ambiente de desenvolvimento
aberto e desenvolvido em conjunto com diversas empresas.
40

O MIDP 2.0 objetiva explorar melhor a capacidade dos novos aparelhos celulares que esto chegando no mercado. Segundo Qusay Mahmoud[MAH2003], no
MIDP 2.0, um dispositivo deve possuir as seguintes caractersticas mnimas:
Uma tela de tamanho 96x54 e profundidade de 1 bit (preto e branco);
Um dos seguintes mecanismos de entrada: teclado de telefone, teclado QWERTY
ou toque na tela;
Conectividade a rede: wireless e com largura de banda limitada;
Habilidade de reproduzir tons (suporte a sons);
256KB de memria (incluindo CLDC), 8 KB de memria no voltil para
armazenamento persistente e 128KB de memria voltil para o ambiente de
execuo Java.
A especificao do MIDP 2.0 baseada na do MIDP 1.0 e completamente
compatvel com ela. Assim, aplicaes escritas para MIDP 1.0 iro executar sem
problemas nos novos aparelhos que suportam MIDP 2.0. Algumas novas caractersticas do MIDP 2.0, enumeradas por [MAH2003], so:
Comunicao via sockets e datagramas;
Suporte a HTTPS e secure sockets (SSL);
Incluso do over-the-air provisioning, apresentado na seo 3.2;
APIs especficas para o desenvolvimento de jogos;
APIs para udio e vdeo.
Os novos pacotes adicionados pelo MIDP 2.0 foram:
javax.microedition.lcdui.games, voltado ao desenvolvimento
de jogos;
javax.microedition.pki, voltado a segurana, permite o uso de certificados para autenticar informaes em conexes seguras;
javax.microedition.media, proporciona acesso a funes multimdias;
41

 javax.microedition.media.control, define tipos especficos de

controles para serem usados como um player multimdia.
O nico problema do MIDP 2.0 que ainda no existem aparelhos que o implementem, apenas emuladores. De acordo com Jonathan Knudsen[KNU2002], o
processo para que o MIDP 2.0 comece a ser implementado deve ainda passar pelas
seguintes etapas:
1. A especificao torna-se uma verso final aps reviso pblica (passo em
execuo);
2. A implementao de referncia lanada;
3. Fabricantes de dispositivos implementam MIDP 2.0;
4. Fabricantes verificam se os dispositivos esto de acordo com as leis governamentais;
5. Dispositivos so lanados.
A estimativa de quando os dispositivos MIDP 2.0 sero encontrados em grande
volume no mercado no incio do segundo semestre de 2003. Mas isso no impede
que se apresente em detalhes as suas principais novidades com relao a verso
anterior:
Conexes seguras. MIDP 2.0 requer que os dispositivos implementem
HTTPS, que basicamente o HTTP sobre Secure Sockets Layer (SSL). SSL
um protocolo de sockets que criptografa os dados enviados sobre a rede e
proporciona mtodos de autenticao para os dois lados da comunicao.
O fato de o MIDP 2.0 obrigar a implementao deste protocolo faz com que
se torne possvel o desenvolvimento de aplicaes que necessitem de segurana, como em transaes com cartes de crdito. O suporte a HTTPS
proporcionado atravs do CLDCs Generic Connection Framework no pacote javax.microedition.io.
Multimdia. As APIs disponveis esto relacionadas a um subconjunto de
manipulao de sons da Mobile Media API (MMAPI). Tambm h a possibilidade de gravao de udio. obrigatrio o suporte apenas para arquivos
WAV.
42

 Melhorias nos objetos de interface de alto nvel com o usurio. As grandes mudanas foram realizadas nas classes Form e Item. O layout de formulrios consideravelmente mais sofisticado que no MIDP 1.0. Os itens
antigamente s podiam ser colocados da esquerda para a direita em linhas
de cima para baixo. Agora, este layout pode ser modificado, mas a implementao que ainda decide exatamente onde os itens sero colocados e o
seu tamanho. A novidade que agora pode-se definir um tamanho mnimo
e preferencial que pode ser escolhido pela aplicao.
Um novo integrante dos objetos de layout no MIDP 2.0 o Spacer, Item
no navegvel que representa um espao em branco e permite um ajuste
mais cuidadoso do layout. O seu funcionamento idntico as imagens espaadoras que so utilizadas na confeco de sites. No item ChoiceGroup
foi includo o tipo POPUP.
Comandos podem ser adicionados a qualquer Item em MIDP 2.0, no apenas a um Displayable.
Um novo Item, chamado CustomItem, foi implementado. Este novo
item auxilia na personalizao dos controles, permitindo a criao de novos
itens pelo prprio desenvolvedor. O conceito similar ao de um Canvas,
o CustomItem permite o desenho de qualquer nova forma e a resposta a
eventos de interface com o usurio.
A API de jogos (GAME API). Este pacote ser muito detalhado devido a
sua importncia no desenvolvimento de jogos e tambm para tornar possvel
uma comparao com a implementao do jogo modelo que foi desenvolvido sem as novas tcnicas disponibilizadas por este pacote.
Esta foi uma das grandes mudanas no MIDP 2.0. A Sun e as empresas
que ajudaram no desenvolvimento dessa nova especificao reconheceram
a importncia do mercado de jogos para celulares e deram especial ateno
na construo de um pacote especfico para a sua criao. Este novo pacote
possibilita a automatizao de vrios processos necessrios a fase de desenvolvimento de um jogo e especialmente til para jogos 2D baseados em
tiles.
A idia bsica por trs deste novo pacote est no fato de o contedo de
uma tela poder ser composto de diferentes camadas. Assim, pode-se colocar qualquer contedo em uma camada e ir encaixando-as uma sobre a
outra para formar o efeito desejado. As camadas podem ser manipuladas
independentemente.
43

Dispositivos wireless tem poder de processamento mnimo, de tal maneira

que esta API procura melhorar a performance ao diminuir a quantidade de
processamento feito em Java. Esta abordagem tambm adiciona o benefcio de ser capaz de reduzir o tamanho da aplicao. A API est estruturada
de uma maneira a proporcionar ao fabricante de dispositivos uma liberdade
considervel para a sua implementao, permitindo o uso extensivo de cdigo nativo, acelerao de hardware e formatos de dados de imagem especficos de dispositivo quando necessrio.
A API composta de cinco classes que esto descritas a seguir, de acordo
com as caractersticas apresentadas pela Sun Microsystems[SUN2002C]:
GameCanvas. Esta classe uma subclasse de Canvas no pacote javax.microedition.lcdui e porporciona a funcionalidade bsica de uma tela para um jogo. Em adio aos mtodos herdados de
Canvas h a possibilidade de se consultar o estado atual das teclas do
jogo e sincronizar o envio de grficos para a tela. Estas caractersticas
foram implementadas de maneira a simplificar o desenvolvimento de
jogos e provocar uma melhora de performance.
Outra caracterstica implementada est relacionada com a possibilidade de se obter o objeto de desenho Graphics de qualquer ponto
do programa. Assim, no h mais a necessidade de se repintar a tela
apenas atravs do mtodo paint;
Layer. Esta classe representa um elemento visual em um jogo. uma
classe abstrata que forma a base para o desenvolvimento de camadas
(as classes Sprite e TiledLayer a extendem). Ela tambm proporciona atributos bsicos, como localizao, tamanho e visibilidade.
Pode ser herdada para o desenvolvimento de classes que representam
camadas de uma maneira personalizada;
LayerManager. Para jogos que empregam diversos objetos da classe
Layer, o LayerManager simplifica o desenvolvimento atravs de
uma automatizao do processo de formao de imagens, renderizando
as regies corretas de cada Layer na ordem apropriada.
O LayerManager mantm uma lista ordenada com as Layers que
lhe foram passadas. Estas camadas possuem um ndice que indica a
sua posio no eixo z. Assim, um ndice 0 indica maior proximidade
com o usurio. As camadas podem ter sua posio trocada livremente
pelo desenvolvedor.
44

A ordem das camadas em um LayerManager indica a seqncia em

que elas sero renderizadas.
A classe LayerManager proporciona vrias caractersticas que podem
ser utilizadas para controlar como as camadas so renderizadas na tela.
Uma delas a presena de uma janela de visualizao que controla o
tamanho da regio visvel pelo usurio e tem a sua posio relativa ao
sistema de coordenadas do objeto LayerManager. Ao trocar a posio
da janela de visualizao obtm-se um efeito de rolagem de tela. Podese definir o tamanho da janela de visualizao e sua posio.
O mtodo paint desta classe utilizado quando se desejar pintar a
tela. Ele pede como parmetro uma localizao (x,y) que indica a partir de onde no display do dispositivo do usurio se iniciar a renderizao da janela de visualizao. Quando necessrio o mtodo paint
realiza o recorte das imagens;
Sprite. Representa uma camada animada capaz de apresentar vrios
quadros grficos. Cada quadro possui um objeto Image relacionado
e todos so de mesmo tamanho. Para prover animao seqncial
dos quadros pode-se definir uma seqncia de animao arbitrria. A
classe Sprite ainda proporciona mtodos para a realizao de transformaes e deteco de coliso, simplificando em muito a implementao da lgica de um jogo.
Os sprites so os elementos de interao do jogo, ou seja, so eles que
podem ter suas posies alteradas pelo jogador durante uma partida.
TiledLayer. Esta classe habilita o desenvolvedor a criar grandes reas
de contedo grfico de maneira fcil, a partir de um objeto Image de
referncia. Ela faz com que no seja necessrio carregar uma grande
imagem de fundo, permitindo que se verifique os elementos da figura
que se repetem e, assim, carreg-los apenas uma vez.
Esta classe define uma matriz de clulas onde cada uma pode apresentar um entre os vrios tiles que fazem parte de um nico objeto
Image.
As clulas da tabela tambm podem ser preenchidas com tiles animados, onde os dados da imagens so carregados rapidamente. Esta abordagem permite a animao de uma grande regio, como o movimento
das guas em um lago, sem exigir muito tempo de processamento para
renderizar a imagem, pois seu carregamento em memria ocorre apenas uma vez.
45

O objetivo desta classe facilitar o processo de criao de fundos de

tela rolveis quando se est desenvolvendo jogos 2D.
Os tiles so elementos de tela estticos e que so utilizados para preencher as clulas de um objeto TiledLayer. Uma imagem quebrada
em uma srie de tiles de mesmo tamanho, especificado pelo desenvolvedor. Esta imagem, chamada de imagem fonte, fornece os tiles
que sero utilizados para a construo dos mais variados arranjos de
camadas, dependendo da situao do jogo, como mostra a Figura 2.14.

Figura 2.14: Processo de construo de fundos com a utilizao de tiles em uma

TiledLayer.
Cada tile possui um nico identificador, sendo que o localizado no
canto superior esquerdo da imagem fonte recebe o nmero 1 e os seguintes so numerados consecutivamente (linha a linha). Este tiles
recebem a denominao de estticos pelo fato de haver um link fixo
entre ele e a imagem associada.
Um tile esttico criado quando um objeto TiledLayer instanciado,
mas pode ser atualizado atravs de uma chamada ao mtodo setStaticTileSet().
Tiles animados so criados com o mtodo createAnimatedTile(),
o qual retorna o ndice a ser usado para fazer referncia a este novo tile.
46

Este ndice negativo e comea a partir do -1. Cada tile animado faz
referncia a um esttico que corresponde a figura inicial que ser apresentada.
As clulas na matriz de um objeto TiledLayer possuem todas o
mesmo tamanho, sendo que o nmero de linhas e colunas de cada clula especificado no construtor. O tamanho das clulas o mesmo
tamanho dos tiles.
O contedo de cada clula especificado pelo ndice do tile. Um ndice
0 indica que a clula est vazia, portanto nada ser desenhado em seu
lugar. Por padro todas as clulas contm o ndice 0.
O contedo alterado atravs dos mtodos setCell() e fillCells(). Vrias clulas podem conter o mesmo tile, entretanto, uma
nica clula no pode conter mais de um tile.
A Figura 2.15 ilustra como construir um fundo utilizando uma TiledLayer.

Figura 2.15: Processo de construo de imagens de fundo utilizando uma TiledLayer.

Neste exemplo, a rea da gua preenchida com um tile animado de
ndice -1, o qual faz uma referncia inicial ao tile esttico 5. A rea
inteira da regio de gua pode ser animada com a mudana do tile esttico associado atravs do mtodo setAnimatedTile(-1, 7).
Uma TiledLayer pode ser renderizada manualmente atravs de uma
47

chamada ao mtodo paint ou automaticamente usando um objeto

LayerManager.
A Figura 2.16 apresenta a hierarquia de classes do pacote de desenvolvimento de jogos disponibilizado pelo MIDP 2.0.

Figura 2.16: Hierarquia de classes do pacote javax.microedition.lcdui.

game. As classes circuladas de azul no fazem parte do pacote de jogos, apenas
so extendidas por algumas de suas classes.
Mtodos que modificam o estado de objetos Layer, LayerManager,
Sprite e TiledLayer, geralmente, no tem seu efeito visualizado imediatamente. Ao invs disso, eles so simplesmente armazenados dentro do
objeto e usados nas prximas chamadas ao mtodo paint(). Esta abordagem adequada para aplicaes de jogo, onde h um ciclo de jogo dentro
do qual objetos so atualizados e onde a tela repintada no final do ciclo.
Imagens RGB. Os dados de uma imagem so representados atravs de um
inteiro de 32 bits por pixel, onde cada 8 bits so para o nvel de transparncia, vermelho, verde e azul;
Permisses e assinatura de cdigo. O MIDP 2.0 voltou-se muito para a
rea de segurana, que no caso do MIDP 1.0 foi deixada um tanto de lado.
Uma das novidades foi em relao ao conceito de cdigo confivel e no
confivel. Cdigos no confiveis no podem abrir nenhum tipo de conexo
sem a autorizao do usurio, enquanto que cdigos confiveis so assinados digitalmente pelo desenvolvedor de maneira que o dispositivo consiga
reconhecer esta assinatura e dar total liberdade a aplicao de executar.
Vrios protocolos de comunicao. O MIDP 2.0 define outros protocolos
de comunicao alm do HTTP, como datagrama, socket e socket server. A
especificao no requer que se implemente-os, faz apenas uma recomendao e disponibiliza a API de suporte necessria.
48

Atravs desta abordagem o fabricante que for implementar algum protocolo

alm do HTTP e HTTPS no precisa mais criar a sua prpria API, pode-se
utilizar das interfaces definidas pelo prprio profile. Com isso, garante-se a
portabilidade das aplicaes.
A Figura 2.17 apresenta a hierarquia de interfaces do GCF implementadas
pelo MIDP 2.0;

Figura 2.17: Modificaes feitas no GCF pelo profile MIDP verso 2.0. As novas
interfaces includas por esta especificao encontram-se circuladas de vermelho.
A seguir encontra-se uma descrio das classes que no faziam parte da
verso anterior do profile MIDP:
CommConnection, define uma conexo com uma porta serial;
HttpsConnection, define os mtodos e constantes necessrios para
estabelecer uma conexo segura via rede;
SecureConnection, define um fluxo de conexo por sockets seguro;
SecurityInfo, define os mtodos necessrios para se accessar informaes sobre uma rede segura;
ServerSocketConnection, define um servidor baseado em sockets;
SocketConnection, define uma conexo por sockets;
UDPDatagramConnection, esta interface define uma conexo por
datagramas no confivel.
49

Para este projeto foi utilizada a interface SocketConnection para estabelecer uma conexo com o servidor. A utilizao da API do MIDP 2.0
restringiu-se a esta classe.
Push Registry. Este novo sistema permite que um servidor inicie remotamente uma aplicao, devidamente registrada, no aparelho do usurio;
Compartilhamento de dados. Aplicaes em MIDP 2.0 podem compartilhar seus arquivos de registro.
O Personal Digital Assistant Profile estende as capacidades do MIDP 1.0 (por
isso, deve ser construdo sobre este profile) e requer o CLDC 1.1. Ela proporciona
APIs para a interface com o usurio e o armazenamento de dados para dispositivos
como o handheld, Personal Digital Assistants e Palm Pilots, com as seguintes
caractersticas:
No menos que 1000KB de memria total (ROM + RAM) disponvel para
o ambiente de execuo Java e bibliotecas e no mais que 16MB;
Potncia limitada;
Tipicamente operado a bateria;
Acesso bidirecional a rede, intermitente e com largura de banda limitada;
Interfaces com o usurio com variados graus de sofisticao, mas tendo displays com uma resoluo mnima de pelo menos 128x128 pixels, um dispositivo de apontamento e uma entrada de caracteres.
O PDA o primeiro profile baseado na CLDC criado especificamente para
dispositivos PDAs. Esta especificao foi desenvolvida com o objetivo de aproveitar melhor alguns recursos comuns a todos os PDAs, como acesso a agenda
de endereos e a listas de coisas a fazer. Os PDAs tambm tender a possuir mais
capacidades que os simples dispositivos baseados no MIDP.
A relao entre o MIDP e o PDAP ilustrada na Figura 2.18, retirada do artigo
de Enrique Ortiz[ORT2002A].

2.4.6

J2ME Connected Device Configuration (CDC)

A especificao J2ME Connected Device Configuration (CDC), JSR36, baseada na especificao da mquina virtual Java clssica. Ela define um ambiente
50

Figura 2.18: Profiles que fazem parte da configurao CLDC.

de execuo completo que inclui toda a funcionalidade de um ambiente para o
desktop.
Esta configurao direcionada a dipositivos mais robustos, com grande capacidade de acesso a rede, wireless ou no, com pelo menos poucos megabytes de
memria disponvel e que podem se conectar a Internet ou a outros dispositivos.
As caractersticas exigidas por esta configurao so:
ROM disponvel de pelo menos 512KB;
RAM disponvel de pelo menos 256KB;
Processadores de 32 bits;
Conectividade a algum tipo de rede;
Suporte para uma implementao completa da mquina virtual Java, como
a definida em [LIN & YEL1999].
Apesar da especificao exigir apenas 256KB de RAM, o ideal que este valor
seja de no mnimo 2MB.
O CDC um superconjunto do CLDC, como mostra a Figura 2.19. Assim,
o CDC inclui todas as classes definidas pelo CLDC, outras do ncleo do J2SE e
mais algumas novas, no existentes nem no J2SE.

2.4.7

Os profiles para o CDC

Os profiles disponveis para o CDC so o Foundation Profile (FP), o Personal

Basis Profile (PBP) e o Personal Profile (PP).
A especificao J2ME Foundation Profile, JSR46, adequada para dispositivos que necessitam de um amplo suporte a plataforma Java, mas no necessitam
de interface grfica. Ele estende o CDC adicionando novas classes J2SE e tambm proporciona a base para que outros profiles possam ser construdos sobre ele,
51

Figura 2.19: Relao entre o CLDC e CDC.

adicionando uma interface grfica com o usurio e outros comportamentos. Ele
adequado a dispositivos com as seguintes caractersticas:
ROM disponvel de no mnimo 1MB;
RAM disponvel de no mnimo 512KB;
Conectividade a algum tipo de rede;
Nenhuma interface grfica com o usurio.
O J2ME Personal Basis Profile construdo sobre o Foundation Profile. Este
profile define um subconjunto otimizado da classe AWT, utilizada para a construo de interfaces grficas.
A proposta de especificao J2ME Personal Profile, JSR62, reempacota o PersonalJava[tm] Application Environment para assim prover a especificao J2ME
para dispositivos que necessitam de um alto grau de conectividade a Internet. Os
dispositivos que venham a implementar este profile devem possuir as seguintes
caractersticas:
ROM disponvel de no mnimo 2.5MB;
RAM disponvel de no mnimo 1MB;
Conectividade de alto nvel com algum tipo de rede;
Interface grfica com o usurio (GUI) com um alto grau de fidelidade a web
e capacidade de executar applets.
O J2ME Personal Profile ser compatvel com o PersonalJava Application
Environment especificaes 1.1.x e 1.2.x.
A relao entre estes profiles ilustrada pela Figura 2.20.
52

Figura 2.20: Profiles baseados na configurao CDC e suas relaes.

2.4.8

Especificaes adotadas pelos celulares

Como j apresentado, os telefones celulares tn caractersticas que vo de encontro as especificaes da configurao CLDC. Assim, eles iro implementar os
profiles existentes para esta configurao, mais especificamente o profile MIDP.
Com isso, as anlises realizadas no prsimo captulo sero realizadas exclusivamente sobre esta organizao.
A Figura 2.21 apresenta a organizao atualmente implementada pelos aparelhos celulares.

Figura 2.21: Pilha de software atualmente implentada pelos aparelhos celulares.

A Figura 2.22 apresenta a organizao futura a ser implementada pelos aparelhos celulares. Em meados do segundo semestre de 2003 acredita-se que j estaro
disponveis no mercado dispositivos com MIDP 2.0, mas ainda com a verso 1.0
da configurao CLDC.

2.4.9

Distribuindo a aplicao

Esta seo foi baseada em um artigo introdutrio de J2ME de BillDay, que

pode ser encontrado no seu site oficial[DAY2001].
53

Figura 2.22: Pilha de software a ser implementada pelos aparelhos celulares.

Uma vez que a aplicao est pronta para ser distribuda necessrio um mecanismo que a carregue para o dispositivo desejado. Esse mecanismo denominado
Java Application Manager (JAM).
A especificao MIDP descreve claramente as caractersticas que o dispositivo
deve possuir para tratar esta situao. A especificao d um certo grau de flexibilidade para os fabricantes definindo apenas o que o mecanismo a ser criado deve
ter, no entrando em detalhes sobre como deve ser feita a sua implementao.
O JAM deve ser capaz de copiar um cdigo atravs de uma conexo wireless,
saber onde ele deve ser armazenado e como o usurio deve iniciar a aplicao.
Estes passos precisam ser feitos de maneira altamente eficiente, de modo a economizar tempo e dinheiro do usurio.
A Figura 2.23 demonstra um esquema de como o JAM deve trabalhar.

Figura 2.23: Funcionamento de um JAM.

54

Neste cenrio, um consumidor vai a uma pgina web, ou pgina wap. A pgina
lista as aplicaes disponveis para cpia.
Se o consumidor quer comprar sua aplicao, ele a seleciona da pgina web
usando seu aparelho de telefone mvel. Ao selecionar a aplicao inicia-se automaticamente o download do arquivo .jad, da ordem de dezenas de bytes, da rede
para o aparelho. Como este arquivo muito pequeno ele copiado rapidamente e
de maneira barata atravs da conexo wireless.
O arquivo JAD tem a funo de dizer algumas coisas bsicas ao consumidor,
como:
A verso da aplicao a ser instalada, evitando assim que se faa o download
de uma verso igual ou menor a uma j instalada no aparelho;
Tamanho da aplicao atual, se o usurio tem somente 2KB de espao disponvel e a aplicao tem 6KB ele pode mostrar uma janela dizendo que o
usurio no tem espao suficiente para armazenar aquela aplicao. Isto
bom para o consumidor porque ele no perde tempo e dinheiro na sua conexo wireless copiando uma aplicao para a qual ele no tem memria
suficiente.
Uma vez que o consumidor est pronto para fazer o download da aplicao e
o JAM confirmou que h espao suficiente, a cpia inciada. O JAM ir salvar a
aplicao no dispositivo e ento apresentar um menu de seleo para que o usurio
possa inici-la.
Segundo a especificao MIDP, a abilidade de realizar o download e instalao
de contedo, por demanda, sobre uma rede wireless conhecida pelo termo overthe-air provisioning (OTA).
Da perspectiva dos clientes mveis, como j foi apresentado, o conceito de
OTA est relacionado como a maneira com que o dispositivo se comporta na operao de encontrar uma aplicao interessante na web, iniciar o download via rede
wireless, instal-la e deix-la pronta para o uso.
Segunto Enrique Ortiz[ORT2002B], os participantes deste processo so:
Dispositivo Cliente, que deve possuir uma aplicao que torne possvel a
busca de aplicaes na rede;
A rede, que qualquer rede wireless;
Servidor de downloads, que um servidor visvel na rede onde se est executando um aplicativo web server que tem acesso a um repsitrio de contedo. o responsvel por apresentar ao cliente as aplicaes disponveis;
55

 O repositrio de contedo, onde permanecem todas as sutes de MIDlets que

esto disponveis para download.
A Figura 2.24 apresenta a estrutura do sistema OTA.

Figura 2.24: Over-the-air provisioning (OTA).

A primeira verso da especificao MIDP OTA era somente uma prtica recomendada. Atualmente, muitos dispositivos suportam a recomendao do MIDP
1.0. O MIDP 2.0 tornou a sua implementao obrigatria.

2.5

O escopo da tecnologia wireless em Java

A Sun Microsystems[SUN2003A] conceitua a tecnologia wireless Java como

a interseo de dois grandes mundos, o da comunicao de dados wireless e o da
plataforma Java. Segundo a prpria Sun a tecnologia wireless Java abrange partes
do J2ME, PersonalJava, J2SE e J2EE. Assim, alguns conceitos devem ento ser
aqui esclarecidos:
Tecnologia wireless Java e J2ME no so a mesma coisa. J2ME incorpora
mais que apenas dispositivos wireless. Enquanto algumas partes do J2ME
so explicitamente projetadas para dispositivos wireless, outras partes no
so. Dispositivos CDC tem por padro conexes Ethernet. Por sua vez, a
tecnologia Java wireless no est confinada apenas ao J2ME. Pode-se ter um
laptop ou palmtop, executando aplicaes J2SE, conectado a outros computadores via uma rede local sem fio;
56

 MIDP no tudo do J2ME. MIDP apenas o primeiro perfil terminado e o

primeiro a ser incorporado aos dispositivos. Algumas pessoas assumem que
sempre que esto falando sobre MIDP esto falando sobre J2ME. J2ME tem
muitas outras especificaes, sendo que o MIDP foi apenas o primeiro da
fila;
MIDP no toda a tecnologia wireless Java. A plataforma Java oferece
uma enorme variedade de escolhas para os programadores wireless, como o
PersonalJava e o J2SE em dispositivos wireless.

2.6

Por que usar a tecnologia Java para o desenvolvimento

de aplicaes wireless?

A tecnologia Java, como j foi dito anteriormente, est presente em uma grande
gama de dispositivos, desde cartes de crdito, passando por mquinas desktop at
aplicaes para servidores. Assim, possvel interligar todos estes dispositivos,
fazendo com que eles trabalhem juntos, atravs do uso de uma nica linguagem.
A Sun Microsystems[SUN2003A] apresenta trs grandes vantagens na utilizao da tecnologia Java e da plataforma J2ME para o desenvolvimento de projetos:
A plataforma Java segura. Cdigos Java sempre executam dentro dos limites da mquina virtual que, por sua vez, prov um ambiente seguro para
a execuo de cdigo abaixado da Internet. Uma aplicao binria poderia travar o aparelho ou at mesmo obrigar-nos a reinici-lo. No caso de
uma aplicao Java, o mximo que poderia ocorrer algum problema com
a mquina virtual, sem afetar o funcionamento do aparelho;
A linguagem Java excelente e permite uma programao robusta. Algumas
caractersticas, como o coletor de lixo automtico, so muito eficientes na
preveno de bugs comuns em outras linguagens de programao. A sintaxe
de Java torna fcil a escrita de programas e a sua compreenso;
Portabilidade uma grande vitria para a tecnologia Java wireless. Um
nico executvel pode ser executado em mltiplos dispositivos. Por exemplo, quando se escreve um MIDlet, uma aplicao MIDP, ela ir executar
em qualquer dispositivo que implementa a especificao MIDP. At mesmo
se uma aplicao Java faz uso de APIs especficas de um certo fabricante, as
aplicaes escritas em Java so mais fceis de serem modificadas em comparao quelas feitas em C ou C++.
57

2.7

Jogos multiplayers

Jogo multiplayer o nome dado ao estilo de jogo no qual os jogadores no

interagem apenas com personagens manipulados pelo programa, mas tambm com
pessoas reais.
Apesar dos estudos em Inteligncia Artificial estarem se desenvolvendo em
uma velocidade incrvel nos ltimos anos e de estar cada vez mais presente nos
novos jogos, muito ainda falta para se construir um personagem que se comporte
igual a um humano de verdade. Na grande maioria das vezes, aps uma certa ambientao com o jogo, o movimento dos personagens gerenciados pelo computador
torna-se previsvel. Por isso, a possibilidade de jogar com pessoas reais foi bem recebida entre os consumidores de jogos eletrnicos, uma vez que o comportamento
de um indivduo realmente imprevisvel.
O fato de se reunir com os amigos e realizar disputas entre vrias pessoas ao
mesmo tempo tambm mais divertido, permitindo uma fuga do tradicional um a
um nos imposto pelos jogos mais antigos.
O advento dos jogos multiplayers se deu com os computadores desktop e com a
popularizao da Internet, que permitiu a disputa de partidas com qualquer pessoa
no mundo.
No entanto, este problema com a velocidade de conexo foi bem resolvido
com a popularizao das redes locais. Atravs delas vrias pessoas passaram a
se reunir com os amigos para montar a sua prpria rede e disputar suas partidas.
Este tipo de encontro conhecido pelo nome de LAN Party. Os jogos multiplayers
tambm popularizaram outro termo, as LAN Houses. LAN Houses so lojas que
possuem vrios computadores interligados em rede e vrios jogos de maneira que,
atravs do pagamento de uma taxa por tempo de uso dos computadores, as pessoas
possam disputar partidas.
O incio desta seo j deve ter deixado claro que a implementao de jogos
neste estilo no to simples. Atualmente, so vrias as pesquisas que vem sendo
desenvolvidas para solucionar problemas conhecidos destes tipos de jogos. Uma
das frentes de pesquisa nesta rea est relacionada com a arquitetura de comunicao entre os clientes de um jogo. Outros tpicos mais avanados correspondem
a como compensar o atraso na troca de dados em uma rede muito lenta, evitando
que se renderize uma imagem com atraso em relao a outro jogador que possua
uma conexo mais rpida.
O tipo de arquitetura a ser utilizada no desenvolvimento do jogo modelo proposto por este trabalho foi uma deciso importante. Assim, o restante desta seo
ir apresentar uma breve descrio dos modelos de arquitetura de comunicao
58

mais conhecidos 9 :
Topologia Peer-to-Peer (ponto-a-ponto). Em um projeto de sistema ponto
a ponto, existem diferentes estaes de trabalho interconectadas de maneira
que cada uma delas pode enviar mensagens diretamente a qualquer ponto
da rede. Aqui podem ocorrer trs tipos de comunicao entre os pontos da
rede:
Multicast. Neste tipo de comunicao as mensagens so enviadas a
grupos de pontos dentro da rede ou at mesmo para a rede toda.
Unicast. Permite a comunicao apenas entre dois pontos de cada vez.
Neste tipo de topologia os clientes, geralmente, mantm informaes completas do estado atual do jogo. Esta caracterstica cria um problema em potencial: o fato de ela no ser escalvel, ou seja, quanto maior for o nmero de
clientes maior vai ser o nmero de atualizaes a serem feitas e conseqentemente o overhead de mensagens ser enorme. Assim, ela freqentemente
utilizada quando o nmero de clientes reduzido.
A Figura 2.25 ilustra este tipo de arquitetura.

Figura 2.25: Arquitetura de comunicao ponto a ponto.

Topologia baseada em servidor. Neste tipo de projeto os clientes no trocam mensagens entre si, apenas as enviam a um servidor. O servidor o
responsvel por controlar a lgica do jogo, deixando apenas a renderizao
e outros trabalhos mais simples por conta dos clientes. Nesta arquitetura podem ocorrer duas situaes, uma onde existe uma rede de servidores(ServerNetwork) e a outra na qual um nico servidor (Client/Server ) o responsvel por todo o controle do jogo.
9

O modelo utilizado por este projeto ser melhor detalhado no prximo captulo.

59

Neste tipo de topologia deve-se evitar sobrecarregar o servidor, visto que ele
ser o elemento crtico da rede. O ideal otimizar a freqncia com que as mensagens so enviadas. Os problemas ocorrem quando o servidor no consegue responder a tempo todas as requisies vindas dos clientes.
A Figura 2.26 ilustra os modelos de arquitetura baseados em servidor.

Figura 2.26: Arquitetura de comunicao baseada em servidor e suas variaes.

2.8

Conexes via sockets

Um socket um ponto final de um link de comunicao bi-direcional entre

dois programas executando em uma rede. Um socket limitado a um nmero de
porta de tal maneira que o protocolo TCP pode identificar a aplicao para a qual
os dados so destinados e envi-los corretamente10 .
Os passos para se estabelecer uma conexo via sockets entre dois computadores so:
1. Deve-se estabelecer um servidor que ficar esperando por requisies de
conexes por parte dos clientes. Normalmente, um servidor executa sobre
um computador especfico e define um socket que est limitado a um nmero
de porta especfico. O servidor apenas espera, escutando atravs do socket,
por uma requisio de conexo de um cliente qualquer;
2. Depois de estabelecido o servidor, qualquer cliente que conhea o nome de
domnio (hostname) do computador e o nmero de porta pela qual o servidor
espera por conexes pode tentar fazer uma conexo;
10

Esta seo foi escrita com base no captulo de sockets do Java Tutorial[SUN2002E].

60

3. Se tudo ocorrer bem, o servidor aceita a conexo e obtm um novo socket com uma porta diferente. Esta etapa de criao de um novo socket
necessria para permitir que a porta atual fique livre para continuar a receber requisies de outros clientes enquanto atende as necessidades do atual
cliente conectado;
4. Do lado do cliente, se a conexo aceita, um socket criado e passa a ser
utilizado para realizar a comunicao com o servidor. Note que o socket do
lado do cliente no limitado ao nmero de porta usado para conectar-se ao
servidor. Ao invs disso, ao cliente atribudo um nmero de porta local,
ou seja, da sua prpria mquina;
5. O cliente e o servidor podem agora comunicar-se livremente, apenas escrevendo e lendo de seus sockets.
A Figura 2.27 e a Figura 2.28 representam, respectivamente, um cliente tentando realizar uma conexo com um servidor e uma conexo j estabelecida entre
dois computadores.

Figura 2.27: Requisio de conexo de um cliente a um servidor via sockets.

Figura 2.28: Conexo estabelecida entre um cliente e um servidor via sockets.

O jogo desenvolvido para a anlise da plataforma J2ME utiliza sockets como
protocolo de comunicao entre os celulares e um servidor, criado utilizando a
plataforma J2SE.
61

Para desenvolver o servidor no qual os celulares se conectam para jogar foram

utilizados os pacotes java.net e java.io da API do J2SE. O primeiro pacote
oferece uma classe, Socket, que implementa o lado cliente de uma conexo bidirecional entre um programa Java e outro programa na rede. Para estabelecer um
socket servidor, capaz de escutar por requisies de clientes, foi utilizada a classe
ServerSocket.
O pacote java.io utilizado para obter os fluxos de comunicao com o
cliente atravs do socket criado em uma conexo aceita pelo servidor.

2.9

Threads de execuo

A maioria dos programadores esto familiarizados com a escrita de programas

seqnciais, como aplicaes que ordenam listas ou encontram os 100 primeiros
nmeros primos. Nestes tipos de programas, tudo tem um comeo, uma seqncia
de execuo e um final 11 .
Uma thread similar aos programas seqnciais que a maioria dos programadores desenvolvem. Para ser mais claro, um programa deste tipo corresponde a
uma thread de execuo iniciada pelo sistema operacional, por exemplo. Assim,
uma nica thread tambm possui um comeo, uma seqncia e um final. Entretanto, uma thread no pode executar a si prpria. Ao invs disso, ela executa
dentro de um programa. A Figura 2.29 apresenta esta relao de um modo mais
claro.

Figura 2.29: Modo de execuo de uma thread nica.

Resumindo, uma thread um fluxo seqncial nico dentro de um programa.
Como pode ser notado, no h nada de novo no conceito de uma nica thread.
A novidade est no fato de que se pode utilizar mltiplas threads de execuo no
11

Esta seo foi escrita com base no captulo de threads do Java Tutorial[SUN2002E].

62

mesmo programa, ao mesmo tempo e realizando tarefas diferentes. Esta caracterstica torna possvel a construo de aplicaes muito mais complexas. Este
esquema ilustrado na Figura 2.30

Figura 2.30: Execuo de mltiplas threads em um nico programa.

O servidor do jogo modelo desenvolvido faz uso de threads mltiplas para
manter vrias sees de jogos abertas simultaneamente, enquanto que o cliente as
utiliza para poder trocar dados com o servidor sem atrapalhar o fluxo de execuo
normal da MIDlet.

63

64

Captulo 3

Estudo de caso: avaliao da

plataforma J2ME na
implementao do jogo Alea
Jacta Est
Este captulo tem como objetivo principal apresentar como o jogo modelo desenvolvido para a anlise da plataforma J2ME foi implementado. Esta apresentao ser feita de acordo com trs perspectivas: interface, dinmica do jogo e
arquitetura de comunicao utilizada. Neste captulo tambm esto relacionadas
as ferramentas necessrias para o desenvolvimento do projeto, as dificuldades e
facilidades encontradas na implementao do jogo e algumas anlises iniciais da
tecnologia.
Para atingir os objetivos propostos foi realizada a diviso do captulo em trs
sees: a seo 3.1 faz uma breve descrio do jogo modelo desenvolvido; a seo 3.2 discute todas as ferramentas utilizadas no projeto e a seo 3.3 apresenta a
maneira como o jogo foi implementado, ressaltando as dificuldades e facilidades
encontradas, e algumas anlises iniciais da plataforma J2ME, seguindo as perspectivas propostas no pargrafo anterior.
65

3.1

O jogo Alea Jacta Est

Alea Jacta Est um jogo de estratgia multiplayer em que cada participante

representa um general romano. O objetivo expandir o seu prrpio imprio e
conquistar todos os demais generais. A vitria sobre os generais conseguida
atravs de disputas entre as unidades militares de cada jogador e tambm entre
estas unidades e as cidades inimigas.
Alea Jacta Est faz referncia a uma clebre frase pronunciada pelo general
romano Jlio Csar e que traduzida do latim significa A sorte est lanada. Jlio
Csar a pronunciou quando entrou em Roma para atacar Pompeu, que havia se
rebelado contra as leis impostas pelo Senado e se declarado imperador, e viu quo
fraco era o seu exrcito em comparao com o do inimigo. Pelo fato de a ao do
jogo ocorrer na poca do grande Imprio Romano esta frase foi escolhida para ser
seu ttulo.
A lgica do jogo simples: aps criada uma cidade, inicia-se a construo de
novas unidades militares ou de outras unidades construtoras. Com isso, pode-se
montar um verdadeiro exrcito e iniciar uma guerra, promover a paz ou construir
novas cidades visando uma expanso cada vez maior do imprio. Assim, uma
partida sempre diferente da outra.
Algumas opes de unidades militares a serem construdas so: cohorts, pretorianos, falanges, bigas, catapultas e trirremes. Estas unidades so as reponsveis
pela maior parte da interao do jogo.
O jogo disputado em turnos, isto , todos os jogadores, na sua vez, devem
executar uma ao para cada unidade militar ou cidade que possui antes que outro
possa iniciar sua jogada. O nmero de jogadores simultneos em uma partida
determinado pelo jogador que iniciou a sesso de jogo.
Alea Jacta Est traz para as pequenas telas dos celulares os grandes sucessos em jogos de estratgica lanados para computadores desktop, como Age of
Empires[MIC2003] da Microsoft ou Civilization [MIP2003] da Microprose.
Maiores informaes sobre o Alea Jacta Est podem ser encontradas no projeto Alea Jacta Est Um prottipo de jogo de estratgia interativo multiplayer
para dispositivos mveis, do aluno Diego Mello da Silva do curso de Cincia da
Computao, da Universidade Federal de Lavras.
66

3.2

Ferramentas utilizadas no desenvolvimento do jogo

AleaJactaEst

Atualmente, existem vrias ferramentas que auxiliam no desenvolvimento de

aplicaes utilizando a tecnologia J2ME. O objetivo principal desta seo apresentar aquelas que foram utilizadas neste projeto, incluindo editores de texto para
a escrita dos cdigos, emuladores para a realizao dos testes e ambientes para a
compilao das aplicaes.

3.2.1

Editores de cdigo

Um editor de cdigos utilizado para escrever o cdigo das aplicaes a serem desenvolvidas. Ele pode ser um simples editor de texto, como o notepad do
Windows ou o joe do Linux, ou estar incorporado a um grande ambiente de desenvolvimento integrado (IDE, do ingls Integrated Development Environment),
como o Sun One Studio[ONE2003] da Sun Microsystems ou o JBuilder[JBU2003]
da Borland.
Java no exige que se use nenhum editor em especial, permitindo ao desenvolvedor utilizar aquele que mais lhe agrada.
Alguns editores gratuitos e famosos para se escrever aplicaes em Java so o
JCreator LE[JCR2003], o Sun One Studio e o JEdit[JED2003]. Segue uma breve
descrio de cada uma destas ferramentas:
O Sun One Studio, como o prprio nome j diz, distribudo pela Sun e
um ambiente totalmente integrado para o desenvolvimento de aplicaes
Java em qualquer plataforma. Est disponvel em verses para Linux e Windows.
O JCreator LE uma verso gratuita de um ambiente mais poderoso chamado JCreator Pro. Est disponvel somente para Windows.
O JEdit um editor muito famoso pela quantidade de plug-ins que oferece
e tambm por ser totalmente escrito em Java, o que garante a sua portabilidade.
No fcil determinar critrios que permitam avaliar qual o melhor editor
a ser utilizado por um projeto, na maioria das vezes esta escolha uma questo
pessoal. Neste projeto, o JEdit foi o escolhido devido a sua grande facilidade de
67

uso, a alta funcionalidade apresentada, o fato de ser portvel e por j ser utilizado
freqntemente pelo autor do projeto.
A Figura 3.1 apresenta a janela de trabalho do JEdit.

Figura 3.1: O ambiente de trabalho do editor JEdit 4.0.

3.2.2

Emuladores

Antes de iniciarmos esta seo interessante apresentar alguns conceitos:

Um emulador um programa, ou dispositivo, que permite que um equipamento, um sistema operacional ou um programa, emule outro.
Emular comportar-se (programa ou equipamento) como outro, aceitando
as mesmas entradas e produzindo as mesmas sadas, ainda que no com a
mesma velocidade ou pelos mesmos processos.
Um emulador necessrio para que seja possvel testar as aplicaes construdas em inmeros dispositivos sem que seja necessrio comprar todos os aparelhos.
68

Para a realizao deste projeto foram utilizados os emuladores fornecidos pela

Palm (POSE - PalmOS Emulator) e pela Sun (integrado ao J2ME Wireless Toolkit).
Estas ferramentas esto melhor descritas a seguir:
POSE[POS2003]: o PalmOS Emulator um software que emula o hardware de vrios modelos de PDAs da Palm. Ele cria handhelds virtuais que
podem ser utilizados no Windows, Mac OS ou Unix para o teste de aplicaes. Para utilizar o emulador necessrio obter as ROMs dos dispositivos
que se deseja emular.
J2ME Wireless Toolkit[SUN2002D]: esta ferramenta inclui emuladores de
vrios dispositivos compatveis com os profiles MIDP 1.0 e MIDP 2.0. Est
disponvel para Windows, Solaris e Linux e pode ser integrado a vrios ambientes de desenvolvimento, como o Sun One Studio e o JBuilder.
Atualmente, o J2ME Wireless Toolkit est disponvel em duas verses: a verso 1.0.4_01 implementa o profile MIDP 1.0, enquanto que a verso 2.0 Beta 2
implementa o MIDP 2.0. Os emuladores disponibilizados estes toolkits esto relacionados na Tabela 3.1. As caractersticas de cada um deles podem ser encontradas
na Tabela 3.21 .
As caractersticas dos aparelhos que podem ser emulados pelo POSE variam
enormemente, devido a grande diversidade de dispositivos da Palm para os quais
ele apresenta suporte. Entretanto, possuem geralmente um display de 160x160,
resoluo indo de preto e branco a 16 bits, entrada realizada por Graffiti e hard
buttons, nenhum soft button e teclas especiais, como MENU e HOME.
O emulador da Palm foi utilizado apenas com a inteno de verificar a real
portabilidade de J2ME, pois o foco deste projeto est em avaliar a plataforma no
contexto de desenvolvimento de jogos multiplayers para celulares.
Um dos objetivos futuros deste trabalho executar o jogo desenvolvido em
emuladores de celulares reais, como os disponibilizados pela Nokia.

3.2.3

Criao de aplicaes

Antes de se iniciar uma discusso sobre o processo de criao de uma aplicao necessrio apresentar uma definio para o termo MIDlet, que ser freqentemente citado. Uma MIDlet uma aplicao feita segundo o profile MIDP. Caso
fosse utilizado o profile PDA seria uma PDAlet.
1
As tabelas foram compiladas a partir dos manuais do Wireless Toolkit, distribudos pela Sun
Microsystems[SUN2002B][SUN2003B].

69

Tabela 3.1: Emuladores disponibilizados pelo J2ME Wireless Toolkit e verses de

MIDP implementadas por cada um deles.
Emulador
DefaultColorPhone

MIDP
1.0 e 2.0

DefaultGrayPhone

1.0 e 2.0

MinimumPhone

1.0

RIMJavaHandheld

1.0

Motorola_i85s

1.0

PalmOS_Device

1.0

MediaControlSkin

2.0

QwertyDevice

2.0

Descrio
Telefone genrico
com um display colorido.
Telefone genrico
com um display em
tons de cinza.
Telefone genrico
com um display
de
capacidade
limitada.
RIM do Research
In Motion Ltd.
Motorola i85s da
Motorola, Inc.
Palm OS Personal
Digital Assistant da
Palm, Inc (A emulao usa o POSE.).
Telefone genrico
com controles de
udio e vdeo
Dispositivo
handheld
genrico que usa o
estilo de teclado
QWERTY.

Um outro termo utilizado ser a sute de MIDlet. Uma sute de MIDlet, segundo a Sun Microsystems[SUN2002B], um agrupamento de MIDlets que podem compartilhar recursos em tempo de execuo. Mais formalmente, uma sute
de MIDlet inclui:
70

Tabela 3.2: Caractersticas dos emuladores disponibilizados pelo J2ME Wireless

Toolkit.

Dispositivo

Display

Resoluo Mecanismos de
Entrada

DefaultColorPhone

180x208

256 cores

DefaultGrayPhone

180x208

MinimumPhone

96x54

RIMJavaHandheld

198x202

Motorola_i85s

111x100

MediaControlSkin

180x208

256 tons
de cinza
preto e
branco
preto e
branco
preto e
branco
256 cores

QwertyDevice

640x240

256 cores

ITU-T
keypad
ITU-T
keypad
ITU-T
keypad
teclado
QWERTY
ITU-T
keypad
ITU-T
keypad
teclado
QWERTY

Nmero Teclas
de
EspeciSoft
ais
Buttons
2
2
0
0

BACK,
MENU
MENU

MENU

2
2

MENU,
Shift,
Ctrl,
Char

Um arquivo descritor de aplicaes (Java Application Descriptor - JAD):

apresenta um conjunto pr-definido de atributos que podem ser utilizados
pelo software gerenciador de aplicaes para identificar e instalar uma MIDlet. Pode-se definir atributos prprios alm dos padronizados;
Um arquivo Java Archive (JAR), que por sua vez possui:
Classes Java de cada MIDlet na sute;
Classes Java compartilhadas entre as MIDlets;
Arquivos extras usados pelas MIDlets;
71

 Um arquivo manifesto descrevendo o contedo do arquivo JAR (parecido com o arquivo JAD).
A Figura 3.2 apresenta a organizao dos componentes citados acima:

Figura 3.2: Organizao de uma sute de MIDlets.

Para compilar, distribuir e realizar testes de performance mais avanados a
ferramenta J2ME Wireless Toolkit, o kit de desenvolvimento wireless da Sun, ser
novamente utilizada.
O Wireless Toolkit no apenas um emulador, mas um conjunto de ferramentas que torna fcil o processo de criao, distribuio e teste de performance
de aplicaes MIDP (a sua interface grfica automatiza uma srie de processos)
[SUN2002B].
O KToolBar2 , includo no J2ME Wireless Toolkit, um ambiente de desenvolvimento mnimo. Ele possui uma interface para compilao, empacotamento, teste
e execuo de aplicaes MIDP. As nicas ferramentas extras necessrias so um
depurador e um editor de cdigos [SUN2002B].
A Figura 3.3 apresenta a ferramenta KToolBar, parte do J2ME Wireless Toolkit.
Ao compilar uma MIDlet, todos os arquivos .java no diretrio de arquivos
fontes do projeto atual so compilados utilizando o compilador do J2SE. Esta
2

Uma explicao detalhada sobre como utilizar o J2ME Wireless Toolkit e sua ferramenta KToolBar pode ser encontrada nas duas verses dos manuais Users Guide Wireless
Toolkit[SUN2002B][SUN2003B] distribudos pela Sun Microsystems.

72

Figura 3.3: KToolBar, principal ferramenta do J2ME Wireless Toolkit.

no uma compilao normal, devido ao fato de os arquivos deverem ser compilados em um ambiente MIDP ao invs de em um ambiente J2SE. Para entender a dificuldade deste processo basta imaginar uma MIDlet que use a classe
java.lang.System, ela possui diferentes APIs no J2SE e no MIDP. Assim,
ao compilar o projeto, deve-se ser capaz de analisar quais classes so permitidas
[KNU & NOU2002].
Aps a compilao, as classes MIDP devem ser pr-verificadas antes de serem
executadas em um dispositivo. Isto tambm ocorre no J2SE, onde h um verificador de bytecodes que checa os arquivos .class antes de eles serem carregados.
Entretanto, no MIDP a verificao foi dividida em duas fases. A primeira realizada em tempo de construo do projeto e busca simplificar o estgio final da
verificao de bytecode na mquina virtual CLDC, aumentando a eficincia de
execuo no dispositivo. A segunda realizada pelo dispositivo mvel quando ele
carrega as classes. [KNU & NOU2002]
Finalmente, as MIDlets so construdas em uma sute de MIDlet para serem
distribudas aos dispositivos atuais.
Todas as etapas citadas acima so facilmente executadas atravs do J2ME Wireless Toolkit.
A Figura 3.4 e a Figura 3.5, do manual do Wireless Toolkit[SUN2002B], ilustram o processo de construo da aplicao e empacotamento, respectivamente.

3.3

O desenvolvimento do jogo Alea Jacta Est

O jogo Alea Jacta Est foi desenvolvido de acordo com a arquitetura clienteservidor. Neste modelo, o servidor controla toda a lgica do jogo e o cliente fica
responsvel apenas pela renderizao de imagens e outras tarefas mais simples.
73

Figura 3.4: Processo de construo e teste de uma MIDlet.

Figura 3.5: Processo de empacotamento de uma MIDlet.

Assim, no caso da construo do jogo modelo, no foi possvel se preocupar apenas com a implementao do celular, que seria o cliente, mas tambm com a construo de um servidor para controlar toda a lgica do jogo.
O servidor, por ser o responsvel por controlar todas as sesses de jogo em
aberto e pela troca de dados entre os clientes conectados, no pode ser implementado em um simples aparelho celular. H a necessidade de se execut-lo em
74

um computador com maior capacidade de processamento, como os computadores

desktop, para que ele seja capaz de tratar o overhead de dados que possa vir a
acontecer. Portanto, foi necessrio utilizar outra linguagem para a implementao
do servidor. A linguagem escolhida para o seu desenvolvimento, aproveitando-se
da grande integrao existente entre a plataforma J2ME e as outras plataformas da
tecnologia Java, foi a definida pela API do J2SE.
A implementao do servidor no ser apresentada neste projeto, pois o seu
enfoque na anlise da plataforma J2ME. No entanto, cabe ressaltar que o J2SE
supriu todas as necessidades do projeto e, em algumas vezes, foi necessrio deixar
de utilizar alguma funcionalidade fornecida pela arquitetura por limitaes impostas pelo J2ME.
Tendo como base a experincia adquirida no desenvolvimento do Alea Jacta
Est, pode-se afirmar que, para aplicaes mveis que utilizem o modelo clienteservidor, o uso da combinao J2SE no servidor e J2ME no cliente altamente
recomendada. A integrao e intercompatibilidade com outros produtos da famlia
Java uma caracterstica importante de J2ME, pois permite o desenvolvimento de
solues completas baseadas em uma nica tecnologia.
O cliente foi implementado de acordo com os profiles MIDP 1.0 e 2.0, que
foram projetados especialmente para o mercado de desenvolvimento de aplicaes
para celulares3 . O captulo 2 apresenta em detalhes estes dois profiles e faz uma
breve descrio dos outros definidos pela plataforma.
A idia original era implementar o cliente de acordo com a especificao MIDP
1.0, at mesmo pelo fato de o MIDP 2.0 ter sido lanado durante o desenvolvimento do projeto. No entanto, a utilizao da API do MIDP 2.0 tornou-se necessria devido a uma deficincia encontrada na verso inicial com relao a comunicao via sockets, que a maneira como o cliente troca dados com o servidor.
Alea Jacta Est compatvel com MIDP 2.0, mas importante deixar claro
que a utilizao da API fornecida por este profile ficou limitada apenas ao que foi
necessrio para suprir a deficincia encontrada na verso anterior.
No entanto, sero feitas comparaes entre estas verses do profile MIDP durante todas as fases de implementao do jogo. Essas comparaes sero teis para
mostrar as melhorias implementadas pela nova verso, principalmente as relacionadas com o novo pacote criado especialmente para facilitar o desenvolvimento de
jogos baseados em tiles.
O conjunto de classes criadas para a implementao da parte cliente do jogo
3
Existe uma implementao do MIDP 1.0 feita pela Sun para o sistema operacional Palm OS,
mas o mercado de PDAs no o objetivo deste profile

75

Alea Jacta Est est definido na Figura 3.6.

Figura 3.6: Classes que fazem parte do jogo Alea Jacta Est.
A pilha de especificaes definidas pela plataforma J2ME e que foi utilizada
no desenvolvimento do Alea Jacta Est est ilustrada na Figura 3.7.

Figura 3.7: Pilha de especificaes J2ME utilizada na implementacao do Alea

Jacta Est.
As prximas sees iro apresentar os detalhes de implementao (incluindo
as dificuldades e facilidades encontradas), a avaliao da tecnologia e, sempre
que possvel, uma comparao entre as verses dos profiles MIDP. Tudo isto ser
feito de acordo com a perspectiva de interface, dinmica de jogo e arquitetura de
comunicao.
76

3.3.1

A interface

O fato de os dispositivos mveis, em especial os celulares, no seguirem um

padro para o tamanho de suas telas, como ocorre com os monitores tradicionais, e
no possurem grande capacidade de processamento, como os computadores desktop, torna a tarefa de construo de interfaces um pouco complexa.
Em geral, os projetistas de interface para dispositivos mveis devem se preocupar com duas questes bsicas:
processamento. A renderizao de imagens na tela no pode exigir muito
do processador do aparelho;
portabilidade. Uma interface de um programa que deve executar em vrios
modelos de dispositivos precisa ser capaz de se adaptar automaticamente
aos mais variados tamanhos de telas dos aparelhos mveis.
Segundo o MIDP Style Guide[SUN2002F], existem algumas metas que o desenvolvedor deve buscar atender ao desenvolver interfaces para os pequenos dispositivos mveis:
simplicidade. Deve-se construir as interfaces de maneira mais simples possvel, mas sem perder a funcionalidade;
previsibilidade. O usurio deve ser capaz de saber o que vai acontecer aps
realizar alguma ao, mesmo sem ter lido qualquer tipo de manual;
separao de tarefas importantes. As tarefas mais utilizadas e as mais
importantes devem estar disponveis de modo direto para o usurio. Esta
atitude evita que ele tenha que ficar navegando entre telas para iniciar alguma tarefa comumente realizada;
rapidez de resposta. A resposta deve ocorrer imediatamente aps a disparada de alguma ao. A espera uma atividade extremamente irritante para
o usurio;
retorno constante. O usurio deve sempre receber algum tipo de retorno
para as suas aes e tambm ser constantemente informado sobre o estado
de alguma ao que esteja realizando no momento;
O documento MIDP Style Guide[SUN2002F] apresenta uma discusso muito
interessante sobre as maneiras corretas de se projetar interfaces para dispositivos
77

mveis utilizando o profile MIDP. Alm disso, ele tambm possui uma viso geral
de todos os componentes disponveis para a construo destas interfaces. Assim,
recomenda-se a sua leitura antes de se iniciar o desenvolvimento de softwares com
esta especificao.
A API do profile MIDP 1.0, conforme apresentado no captulo 2, proporciona
dois modelos para a construo de interfaces: alto nvel e baixo nvel.
O jogo Alea Jacta Est foi desenvolvido sempre pensando em manter a portabilidade da aplicao. No entanto, no possvel desenvolver um jogo apenas com
os componentes de alto nvel disponibilizados. H a necessidade de se controlar a
tela completamente, permitindo a manipulao pixel a pixel dos elementos a serem
inseridos. Assim, os elementos de alto nvel, apesar de garantirem a portabilidade
das aplicaes, no puderam ser utilizados em todas as telas do jogo.
Os elementos de interface de alto nvel foram utilizados na confeco das telas
relacionadas com a apresentao do jogo, ajuda, opo de escolha de qual servidor
se deseja conectar e se o participante ir criar um novo jogo ou entrar em uma
sesso existente. Alm destas, apenas a tela apresentada ao vencedor ou perdedor
do jogo e a que possibilita a escolha da unidade a ser construda por uma cidade
usaram componentes de alto nvel.
A interface de baixo nvel precisou ser utilizada na confeco da tela onde
ocorre a interao do jogo.
Alea Jacta Est, portanto, uma aplicao desenvolvida de acordo com os
dois modos de interface existentes.
O desenvolvimento de um jogo multiplayer seguir sempre o padro de se
utilizar componentes de alto nvel para as telas iniciais e de baixo nvel para a tela
onde ocorre a interao definida pelo jogo.
O restante desta seo ir apresentar como foi a implementao da interface do
jogo, iniciando pelas de alto nvel, onde sero apresentados trechos de cdigos de
algumas telas criadas, mostrando a facilidade de sua construo. Por fim, ser feito
uma apresentao do desenvolvimento da interface onde ocorre toda a interao do
jogo, que foi desenvolvida com componentes de baixo nvel.
Os detalhes de implementao apresentados neste captulo dizem repeito a
como os componentes foram utilizados e no como se pode us-los. Para maiores
informaes sobre os mtodos definidos por cada classe dos pacotes MIDP deve-se
consultar a sua especificao, disponvel no site ofical deste profile[MID2003].
Para iniciar a discusso, a Figura 3.8 apresenta o modelo navegacional das
interfaces desenvolvidas, do ponto de vista das classes. Nesta figura, a nica interface de baixo nvel a definida pela TelaJogo.
78

Figura 3.8: Modelo navegacional das interfaces desenvolvidas para o jogo Alea
Jacta Est. A classe TelaInicial corresponde ao incio do fluxo.
Para analisar os detalhes de implementao dos componentes da interface de
alto nvel foram escolhidas duas das classes da Figura 3.8, a TelaInicial e a
TelaIniciarJogo.
A Figura 3.9 apresenta a interface definida pela classe TelaInicial e ressalta
alguns detalhes de implementao.
A classe TelaInicial, por ser um Form, pode ser apresentada na tela dos
celulares. O trecho de cdigo da Figura 3.10 apresenta a definio da classe, permitindo verificar que ela herda Form.
O objetivo desta classe e criar uma tela de apresentao do programa. Para
isso foram utilizados os seguintes elementos:
um componente ImageItem, que apresenta o logotipo do jogo. O trecho
de cdigo da Figura 3.11 apresenta como ele foi implementado.
um StringItem que foi utilizado como texto de apresentao e uma breve
descrio do programa. O trecho de cdigo da Figura 3.12 ilustra o seu
processo de criao e utilizao.
trs elementos Command, que permitem a realizao de aes ao serem
selecionados. As aes definidas para esta classe foram: sair do programa,
iniciar um jogo e visualizar a ajuda. Note que, quando so inseridos mais de
trs Commands ao mesmo tempo em uma tela um menu suspenso, como o
79

Figura 3.9: Interface definida pela classe TelaInicial.

Figura 3.10: Trecho de cdigo enfocando a definio da classe TelaInicial.

da letra c da Figura 3.9, automaticamente criado. A Figura 3.13 apresenta
como estes trs comandos foram construdos.
importante notar o fato de a rolagem de tela ocorrer de maneira automtica,
sempre que necessrio. Na classe TelaInicial, a imagem e o texto de apresentao ocuparam um espao maior que o display do celular, obrigando o surgimento
da barra de rolagem.
A observao dos trechos de cdigos apresentados permite verificar a facilidade na construo das interfaces de alto nvel, bastando que se declare, crie e
adicione, atravs dos mtodos append ou addCommand, os componentes dese80

Figura 3.11: Trecho de cdigo enfocando a insero de um ImageItem pela

classe TelaInicial.

Figura 3.12: Trecho de cdigo que mostra a criao de um StringItem.

jados. A nica preocupao que deve-se possuir com relao a ordem com que os
elementos sero inseridos na tela, pois o tamanho e todas as outras caractersticas
so definidas pela implementao do profile MIDP no celular.
81

Figura 3.13: Trecho de cdigo mostrando como inserir Commands em um Form.

A Figura 3.14 apresenta a interface definida pela classe TelaIniciarJogo
e ressalta alguns detalhes de sua implementao. Agora, sero discutidos apenas
os elementos que no foram apresentados na TelaInicial.

Figura 3.14: Interface definida pela classe TelaIniciarJogo.

82

A classe TelaIniciarJogo permite a obteno de algumas informaes

do usurio, como o seu nome, o servidor e porta na qual deseja se conectar e se
ele quer entrar em uma sesso de jogo existente ou criar uma nova. Esta classe
tambm foi implementada a partir de um Form.
A Figura 3.15 apresenta um trecho de cdigo da TelaIniciarJogo mostrando como foi inserido um TextField e um ChoiceGroup no Form.

Figura 3.15: Trecho de cdigo da classe TelaIniciarJogo.

Os elementos de construo de interfaces de alto nvel disponibilizados pela
verso 1.0 do MIDP atendem completamente as necessidades que possam vir a
surgir quando se est desenvolvendo jogos multiplayers. Neste contexto, a sua
utilizao fica restrita a construo das telas iniciais e, em algumas vezes, de telas
de status e de opes que possam vir a se tornar disponveis durante o jogo.
O MIDP 2.0 adicionou novos elementos de interface de alto nvel a sua API,
como pode ser visto no captulo 2. No entanto, estes novos componentes so
teis apenas na criao de aplicaes enterprise, pois estas exigem interfaces mais
complexas.
Algumas consideraes que podem ser feitas com relao ao MIDP verso 1.0
no desenvolvimento de interfaces de alto nvel so:
83

 grande facilidade na manipulao dos componentes existentes;

alta portabilidade;
o processamento necessrio para renderizar os componentes bastante otimizado.
A nica classe do jogo Alea Jacta Est construda utilizando a interface de
baixo nvel foi a TelaJogo. Ela herda da classe Canvas e utiliza dos mtodos
de desenho da classe Graphics para pintar imagens e outras primitivas grficas
na tela.
A Figura 3.16 apresenta a interface gerada pelo cdigo da classe TelaJogo.

Figura 3.16: Classe TelaJogo, na qual toda a interao entre os jogadores

ocorre.
A interface da classe TelaJogo foi modelada de modo a manter a portabilidade do jogo entre os mais diversos dispositivos e implementada de acordo com a
idia de tiles, sprites e janela de visualizao. Assim, ao se instanciar um objeto
desta classe, a primeira tarefa realizada a verificao do nmero de tiles que podem ser inseridos no display do dispositivo. Esta atitude, ao invs da utilizao de
um nmero fixo, permite explorar ao mximo a tela do dispositivo do jogador e,
ainda assim, garantir a portabilidade da aplicao. No entanto, quanto maior for a
interface do dispositivo melhor ser a jogabilidade.
Os tiles so utilizados para construir o mapa de fundo da tela. O Alea Jacta
Est possui ao todo 24 tiles para a definio do seu mapa. Cada um deles, por
sua vez, possui dimenses de 20x20 pixels. Este tiles so apresentados pela Figura 3.17.
Os sprites utilizados para a interao do jogador com os demais participantes
so apresentados na Figura 3.18.
84

Figura 3.17: Tiles utilizados na construo do mapa do jogo.

Figura 3.18: Sprites disponibilizados para a interao com o jogo. Os nmeros

entre parnteses correspondem ao valor de ataque, defesa e tempo de construo,
respectivamente.
O mapa completo do jogo constitui-se de uma matriz de altura e largura igual
a 100 tiles. No entanto, o dispositivo MIDP mantm em memria apenas um
trecho de mapa de dimenses quadradas de 20 tiles. Esta estrutura foi utilizada de
maneira a permitir que novos mapas possam ser criados pelo servidor com os tiles
armazenados no cliente e impedir que a matriz com os dados do mapa a serem
guardados na memria fosse muito grande.
Uma alternativa seria no armazenar nenhum dado referente ao mapa em memria, fazendo com que o servidor enviasse o trecho do mapa coberto pela janela
de visualizao sempre que uma requisio de movimentao fosse realizada. O
problema que isto geraria um grande overhead de dados e atraso na repintura da
tela.
A outra alternativa seria armazenar os dados completos do mapa no aparelho.
Entretanto, esta abordagem faz com que seja necessrio ocupar um grande espao
85

da memria de armazenamento e tambm no permite que novos mapas sejam

gerados dinamicamente pelo servidor.
A base para a rolagem de tela est na utilizao da janela de visualizao. Esta
janela correponde a viso de usurio do mapa do jogo e possui sempre o tamanho
da tela do dispositivo, limitado a dimenso do trecho de mapa. A necessidade de
se rolar a tela pode ser verificada atravs de uma checagem se a posio (x, y)
do sprite ou cidade a ser mostrado encontra-se na rea determinada pela posio
inicial (xjanela, yjanela) da janela e o seu tamanho.
A pintura da tela tambm realizada baseada na janela de visualizao. Assim,
quando houver necessidade de se renderiz-la para mostrar o resultado de uma
ao, o Canvas ser preenchido de acordo com a posio inicial da janela de
visualizao.
A Figura 3.19 ilustra o processo de pintura determinado pela classe TelaJogo. Nesta figura, interesssante notar as constantes definidas, que so referentes as dimenses do mapa, e o mtodo paint, que permite o desenho em um
Canvas. A ordem estabelecida para a pintura dos elementos na tela a apresentada pelas funes inseridas no corpo do mtodo paint. O Objeto Graphics,
para os desenhos de primitivas grficas, disponibilizado como parmetro pelo
gerenciador da MIDlet quando uma renderizao da tela solicitada.
A tela do jogo sempre repintada por completo. Assim, para evitar atraso nesta
renderizao, uma vez que os tiles so imagens que necessitam ser carregadas
de um arquivo local, modelou-se um sistema que acessa os arquivos de imagens
apenas quando se muda de trecho de mapa.
O sistema de otimizao de pintura da tela consiste em armazenar os ndices
dos tiles do trecho de mapa em um vetor e fazer uma busca por aqueles que so
utilizados neste trecho, armazenando os tiles necessrios para a pintura da tela em
uma lista de objetos TileClient (que armazenam o ndice e uma referncia
a sua imagem de arquivo correspondente). Assim, quando se for repintar a tela,
basta procurar nesta lista pelo tile correspondente ao ndice desejado e recuperar
a referncia a sua imagem. Deste modo, utiliza-se as referncias em memria ao
invs de se acessar o sistema de arquivos. Este processo realizado sempre que
uma notificao informando o novo trecho de mapa for recebida.
O tratamento de coliso entre os sprites realizado pelo servidor. Quando o
jogador do turno faz uma solicitao de movimentao de sprite, o servidor verifica
se a nova posio coincide com algum sprite ou cidade dos outros jogadores da
mesma partida e se o tile de fundo tambm permite o movimento. Caso alguma
coliso ocorra, o prprio servidor toma as decises necessrias para trat-la. A
86

Figura 3.19: Tiles utilizados na construo do mapa do jogo.

classe Tile implementada no servidor possui um atributo que indica se o tile

pode ser ultrapassado ou no pelo cliente.
As primitivas de desenho do MIDP 1.0 foram suficientes para os propsitos do
jogo desenvolvido e, acredita-se, que sejam tambm adequadas para a construo
de outros jogos multiplayers baseados em tiles. No entanto, a API no disponibiliza nenhuma facilidade para a manipulao e criao de tiles, sprites e da janela
de visualizao, sendo necessrio construir todas as classes para abstrair os conceitos destas primitivas. A Figura 3.20 ilustra a relao entre as classes construdas.
Entretanto, o projeto de jogos que no seguem o modelo 2D baseados em tile no
to simples de ser elaborado nesta plataforma, apesar de ser possvel.
Uma das novidades da especificao MIDP 2.0 foi a criao de um novo pacote exclusivo para a manipulao de jogos. Este pacote simplifica o desenvolvimento de jogos que seguem o estilo do Alea Jacta Est. Para ser mais claro, ele
disponibiliza toda a API necessria para a manipulao de sprites, tiles e janelas
de visualizao. A seo 2.4.5 do captulo 2, apresenta estas classes de maneira
87

Figura 3.20: Estrutura de classes criadas para utilizar a idia de sprite, tile e janela
de visualizao.
completa.
Os tpicos a seguir apresentam como algumas classes do pacote de jogos do
MIDP 2.0 poderiam facilitar e melhorar a implementao do Alea Jacta Est.
A classe Sprite implementa mtodos de verificao de coliso com outro
sprite ou tile na tela, mas como esta verificao feita pelo servidor no
chega a ser uma vantagem para jogos multiplayers. A criao de sprites animados possvel atravs da definio de um conjunto de quadros de mesmo
tamanho e uma seqncia de exibio. A utilizao de tais sprites seria
interessante para aplicar animao as unidades militares disponibilizadas.
A classe TiledLayer j abstrai toda a estrutura de matriz de tiles criada para
a manipulao da tela.
A classe LayerManager possibilita a manipulao de vrias TiledLayer
de modo a gerenciar o modo como a tela repintada. Abstrai tambm o
conceito de janela de visualizao, permitindo que a classe que gerencia o
jogo se preocupe apenas com a manipulao correta dos ndices (x, y) que
indicam a posio atual da janela no sistema de coordenadas do LayerManager.
A utilizao da API de jogos do MIDP 2.0 altamente recomendada pelo
fato de j fornecer as implementaes otimizadas de quase todos os elementos
necessrios a criao de jogos 2D baseados em tiles.
Caso o Alea Jacta Est tivesse sido elaborado a partir da API de jogos do
MIDP 2.0 o seu desenvolvimento se daria de um modo muito mais rpido e um
ganho de performance seria obtido.
88

A classe TelaJogo a responsvel por gerenciar os processos de renderizao da interface do jogo.

Algumas outras consideraes que podem ser realizadas com relao ao projeto de interfaces em MIDP 1.0 para jogos multiplayers so:
dificuldade de se manipular grficos 3D, pois no existe suporte a valores
de pontos flutuante e primitivas grficas de desenhos de tringulos. Com
isso, no possvel realizar os desenhos de formas geomtricas em terceira
dimenso. Esta caracterstica tambm permanece na verso 2.0 do profile.
O suporte a ponto flutuante uma caracterstica da configurao. A configurao CLDC verso 1.1 deve prover este tipo de suporte.
no apresenta suporte a incluso de sons nas aplicaes, o que pode prejudicar a interao do jogo. No entanto, MIDP 2.0 j apresenta um pacote
dedicado a este propsito.
o suporte a transparncia nas figuras no obrigatrio na verso 1.0, apenas
na 2.0. Isto faz com que seja necessrio criar um arquivo para cada combinao de sprite e fundo possvel de ser ultrapassado para que se obtenha o
efeito de superposio. Essa abordagem consome mais espao no aparelho.

3.3.2

A dinmica do jogo

No cliente, a classe responsvel por coordenar a renderizao da tela, armazenar as informaes necessrias do jogador, manipular estes dados e formatar as
mensagens que sero definidas a partir das interaes do jogador com o dispositivo
a TelaJogo.
Para ilustrar o fluxo de execuo implementado, o processo de criao de uma
cidade pelo jogador que se encontra em seu turno ser detalhado. Em MIDP 1.0
existem trs threads que em conjunto determinam o fluxo de controle do jogo: a
de manipulao de eventos de teclado, a de pintura e a de controle. A Figura 3.21
ilustra o fluxo de jogo definido para a thread de manipulao de eventos de teclado
no Alea Jacta Est.
Voltando ao exemplo proposto, o jogador que deseja criar uma cidade pressiona o boto 0 do aparelho celular. Ao pressionar uma tecla o manipulador de
eventos de teclado ativado e inicia o processamento desta tecla. No caso do
Alea Jacta Est, ele primeiro verifica se a ao que est sendo executada de um
sprite ou de uma cidade, pois para cada um destes elementos as teclas so mapeadas de modo diferente. Como a ao de um sprite ele vai iniciar o processamento
89

Figura 3.21: Fluxo de execuo criado para a thread de manipulao de eventos

de teclado no Alea Jacta Est.
que foi definido para a tecla 0 deste elemento de interao. Neste caso, iniciado
o processo de criao de uma cidade, envolvendo troca de mensagens com o servidor. A troca de mensagens com o servidor para a situao onde no h problema
com relao a criao da cidade no local desejado ilustrada na Figura 3.22.

Figura 3.22: Mensagens trocadas entre o jogador Wendel e o servidor durante o

processo de criao de uma cidade com sucesso.
Aps trocadas as mensagens e atualizado o estado do jogo no celular solicitada uma repintura da tela. Neste ponto, uma falha da especificao MIDP 1.0
pode ser identificada. No h como garantir que o mtodo paint() seja executado no momento em que chamado, pois por estar em uma thread separada quem
determina isso a MIDlet. A nica coisa que se pode fazer solicitar que uma
renderizao seja feita quando houver a oportunidade. A classe GameCanvas do
MIDP 2.0 corrige este problema permitindo que se force a repintagem da tela e
que se obtenha o objeto de desenho Graphics de qualquer ponto do jogo.
O controle de execuo baseado em threads separadas dificulta a criao de um
jogo e a manuteno do seu estado. Alm disso, permite a ocorrncia de situaes
em que o jogador executa duas aes sem ter sua tela repintada ou, at mesmo,
renderizada de acordo com uma mistura dos dados de cada uma dessas aes.
No exemplo adotado, supondo que a renderizao da tela ocorresse simultaneamente com a sua solicitao, a cidade seria desenhada no lugar do sprite constru90

tor que iniciou o seu processo de construo.

Uma das dificuldades que este tipo de controle provocou no desenvolvimento
do Alea Jacta Est foi com relao a atualizao da tela do jogador que no se
encontra em seu turno. Este jogador permanece em um loop onde ele fica escutando por mensagens do servidor e processando-as. Algumas destas mensagens
esto relacionadas com a destruio de seu prprio sprite por um inimigo ou a movimentao deste. Assim, o ideal seria que o jogador tivesse a sua tela atualizada
de maneira que ele pudesse acompanhar o desenrolar da ao do jogo. No entanto,
apesar de ser solicitada uma repintura de tela sempre que mensagens deste tipo
sejam recebidas ela no ocorre at que o jogador inicie o seu turno. Esta caracterstica prejudicou muito a interatividade do Alea Jacta Est.
Para cada ao realizada por um jogador em seu turno, uma mensagem enviada para o servidor. O nmero de mensagens de retorno, entretanto, varivel.
Pode-se fazer mais duas consideraes sobre a dinmica de execuo em MIDP
1.0 para jogos multiplayers:
no permitido verificar o estado atual das teclas do aparelho. A nica
maneira de se tratar as aes do usurio atravs do manipulador de eventos
padro, que executa em uma thread separada. Entretanto, MIDP 2.0 permite
esse acesso;
o acesso as teclas do dispositivo realizada de maneira simples e portvel
pela API.
A Figura 3.23 apresenta de uma maneira clara como o loop de controle implementado por um jogo nas duas verses do profile MIDP.
A Figura 3.24 apresenta o trecho de cdigo de um loop de controle implementado de acordo com o profile MIDP 1.0 e a Figura 3.25 o implementado pela verso
2.0 deste profile.
A classe GameCanvas permite que toda a funcionalidade do jogo ocorra dentro de um simples loop. Neste loop geralmente so realizadas as seguintes tarefas:
1. obteno do objeto Graphics para desenho na tela;
2. atualizao do estado do jogo;
3. obteno do estado das teclas do jogo;
4. processamento da entrada do cliente;
91

Figura 3.23: Loops de controle de execuo definidos pelos profiles MIDP 1.0 e
2.0.

Figura 3.24: Trecho de cdigo que mostra a estrutura tradicional utilizada por uma
classe em MIDP 1.0 para um loop de jogo.

5. cdigo de pintura da tela;

6. forar a pintura dos elemento modificados pelos passos anteriores;
7. esperar por algum tempo.
92

Figura 3.25: Trecho de cdigo que mostra a estrutura tradicional utilizada por uma
classe em MIDP 2.0 para um loop de jogo.

3.3.3

A arquitetura de comunicao

Alea Jacta Est, como j foi mencionado anteriormente, foi implementado

utilizando o modelo de comunicao cliente-servidor. Este tipo de arquitetura
freqentemente encontrada nos jogos multiplayers de computadores desktop.
A seo 2.7 apresenta outro tipo de arquitetura muito conhecida, o modelo
peer-to-peer. Nesta abordagem, ao invs de se centralizar todas as decises do
jogo em um nico computador que executa um aplicativo servidor, os clientes
so os responsveis por controlar a lgica do jogo. Assim, exige-se uma maior
capacidade de processamento e o armazenamento local de quase todos os dados
relativos ao jogo.
Alto grau de processamento e grande capacidade de armazenamento no so
caractersticas comuns em aparelhos celulares. Portanto, a arquitetura clienteservidor a mais indicada para se trabalhar com este tipo de aparelho. Ela permite realizar o processamento todo do lado do servidor e deixar o cliente livre
para a execuo de tarefas mais simples, como a renderizao da tela e a captura
das aes dos usurios. O servidor o nico elemento dentro da arquitetura que
mantm todos os dados do jogo constantemente atualizados.
Na arquitetura cliente-servidor, a implementao do servidor e os modelos de
mensagens trocados entre ele e o cliente devem ser muito otimizadas. Assim, evitase o overhead de dados e a incapacidade de processamento de todas as requisies
das conexes atuais.
Neste ponto da implementao foi verificada uma grande deficincia na API da
verso 1.0 do profile MIDP, a falta de suporte a abertura de conexes via sockets.
O nico protocolo exigido pela especificao MIDP o HTTP. Este protocolo,
93

por ser do tipo request-response, no pode ser utilizado pelo jogo e muito menos
por qualquer outro jogo multiplayer, uma vez que h situaes onde necessrio
enviar dados para o cliente sem que este os tenha requisitado.
Outra caracterstica do protocolo HTTP que dificulta a sua utilizao em aplicaes multiplayers est no fato de ele ser baseado em sesses e cada uma ser
independente da outra. Por isso, feito um request e recebido o response a sesso
de comunicao ser encerrada, no havendo meio de se manter o estado da comunicao durante toda a partida sem a utilizao de algum tipo de controle extra.
A sesso tambm encerrada caso o response demore para ocorrer aps um tempo
pr-definido.
No Alea Jacta Est, quando no se possui a vez, o jogador colocado em uma
situao onde permanece escutando por mensagens do servidor e processando-as.
Este tipo de comunicao impossvel de ser realizada sobre um protocolo que
no mantm informaes sobre os clientes conectados durante toda a partida e
tambm no permite o envio de mensagens quando estas no so solicitadas.
No entanto, a verso 2.0 do profile MIDP apresenta a estrutura de classes necessrias a abertura de conexes via sockets, mas ainda no obriga a sua implementao. O MIDP 2.0 exige apenas que o aparelho tenha suporte ao HTTP e ao
HTTPS. Entretanto, enquanto na verso 1.0 no definido nem ao mesmo as classes que um fabricante deveria escrever caso quisesse permitir o uso do protocolo
de sockets, a verso 2.0 deixa claro que caso ele venha a ser oferecido deve-se
implementar as classes presentes na documentao da especificao.
No MIDP 1.0 o suporte a sockets realizado apenas atravs de APIs prprias
do fabricante, obrigando uma reescrita do cdigo de acordo com o aparelho em
que se deseje executar a aplicao. Entretanto, no MIDP 2.0 todos os dispositivos
que permitem a utilizao deste protocolo implementam a mesma API.
No MIDP 2.0 utiliza-se da classe SocketConnection do pacote javax.
microedition.io para fazer alguma requisio de conexo a um servidor via
sockets.
O fato de no haver suporte obrigatrio a um protocolo de comunicao to comum quanto sockets em MIDP 1.0 representa uma grande falha desta plataforma
na hora de se desenvolver jogos multiplayers. No caso de aplicaes enterprise o
protocolo HTTP suficiente. J o MIDP 2.0, apesar de definir uma API para sockets, ainda no obriga a sua implementao. Assim, o problema de suporte a este
tipo de conexo foi apenas parcialmente resolvido na nova verso da especificao.
O jogo Alea Jacta Est s no completamente portvel devido ao fato de
utilizar sockets para se conectar ao servidor.
94

A Figura 3.26 apresenta um trecho de cdigo com a abertura de uma conexo

via sockets com o servidor escolhido pelo jogador.

Figura 3.26: Trecho do cdigo do Alea Jacta Est que mostra a abertura de conexes por sockets.
Na arquitetura cliente-servidor, alm de se preocupar com o protocolo de comunicao, necessrio definir o formato de mensagens a serem trocadas.
As primitivas envolvidas na comunicao do jogo modelo construdo so classificadas em trs categorias: primitivas de ao (formatadas pelo cliente), primitivas de notificao (formatadas pelo servidor) e primitivas de gerncia de sesso de
jogo (abertura e manuteno das partidas). Um subconjunto delas est relacionado
na listagem abaixo:
NOV_ACT: utilizada para solicitar ao servidor a criao de uma nova sesso
de jogo.
SES_NOT: primitiva enviada como resposta a uma solicitao de criao de
sesso de jogo ou em resposta a solicitao de participar de uma sesso de
jogo pr-existente.
COM_ACT: primitiva enviada pelo jogador que criou a sesso solicitando o
incio da mesma.
COM_NOT: primitiva enviada pelo servidor para o jogador que realizou uma
solicitao COM_ACT indicando o incio do jogo.
95

 MOV_ACT: primitiva utilizada para indicar uma ao envolvendo o movimento de alguma unidade militar.
CID_ACT: primitiva utilizada para indicar uma requisio para construir
uma cidade a partir de uma unidade construtora.
SPR_ACT: primitiva utilizada para indicar uma requisio para construir
unidades militares a partir de uma cidade pr-existente.
MAP_ACT: primitiva utilizada para codificar uma requisio para o servidor
enviar um trecho do mapa do jogo.
Para cada ao de um cliente enviada ao servidor ele recebe uma notificao
correspondente. Um exemplo desta comunicao pode ser verificado atravs da
troca que ocorre quando uma mensagem de MOV_ACT enviada pelo cliente ao
servidor. O formato da primitiva MOV_ACT o seguinte:
MOV_ACT;<id_sprite>;<posX>;<posY>;
Uma possvel conversa com o servidor na qual o cliente quer movimentar
o sprite de identificador igual a 5 para a posio (10, 15) ocorreria da seguinte
maneira:
1. Cliente envia para o servidor: MOV_ACT;5;10;15;
2. Servidor recebe a mensagem, processa, verifica que a movimento possvel e retorna para o cliente: MOV_NOT;5;10;15;
O formato das demais mensagens trocadas entre o jogador e o servidor no
ser apresentado neste projeto. A discusso ser realizada com relao as maneiras
utilizadas para se manipular tais mensagens.
As duas verses do profile MIDP no apresentam suporte a serializao de
objetos. Por isso, no existe a possibilidade de se transmitir e receber objetos
atravs dos fluxos de comunicao com o servidor. Para se transmitir dados
necessrio convert-los em bytes. Esta abordagem exige que se utilize um sistema
de cabealho fixo em conjunto com as mensagens a serem transmitidas.
A estrutura de cabealhos foi implementada da seguinte forma:
Primeiro definiu-se um tamanho padro para o cabealho, tanto do lado do
servidor quanto do cliente. Este valor foi fixado em trs bytes;
96

 Ao se transmitir uma mensagem, deve-se calcular o seu tamanho, montar o

cabealho de acordo com este tamanho, acrescentar a mensagem em bytes
ao cabealho e, finalmente, enviar os dados.
Ao receber uma mensagem, deve-se, inicialmente, ler os trs primeiros bytes
do fluxo de entrada, verificar o valor obtido (que corresponde ao tamanho da
mensagem), criar um novo vetor de bytes para a mensagem com o tamanho
especificado no cabealho e s ento ler o fluxo de entrada para obter o
restante dos dados.
A Figura 3.27 ilustra o processo de definio de um cabealho para uma primitiva de comunicao.

Figura 3.27: Processo de construo de um cabealho para uma primitiva de comunicao.

A utilizao de um sistema de cabealhos til pelo fato de permitir que se leia
de um fluxo o nmero de bytes corretos de uma mensagem. Com isso, impede-se
que se leia caracteres a menos, prejudicando a interpretao da mensagem, ou a
mais, obtendo um trecho da prxima mensagem enviada ou fazendo o fluxo esperar
por um caracter que ainda no foi enviado pelo servidor.
Em jogos multiplayers os dados devem ser transmitidos de maneira rpida
entre o cliente e o servidor, para evitar atrasos de renderizao nas imagens. Por
isso, como a transmisso de bytes mais rpida, ela deve ser preferencialmente
utilizada. Assim, o fato de a transmisso de objetos no ser possvel em MIDP no
representa um ponto negativo da plataforma J2ME.
No Alea Jact Est, as mensagens so geradas em formato de String e
convertidas em bytes antes de serem enviadas. A API do MIDP 1.0 foi bastante
completa nas tarefas de converso de uma String em um vetor de bytes a ser
enviado e na de um vetor recebido em uma String a ser processada. No h
nenhuma crtica negativa a ser feita com relao a esta parte da implementao.
No jogo Alea Jacta Est, um objeto da classe GerenciadorMensagem
o responsvel por enviar e receber dados. Este objeto, ao ser instanciado, obtm o
97

nmero da porta e o endereo do servidor no qual o cliente deseja se conectar. Por

ser uma thread, ele deve ser iniciado logo em seguida.
A utilizao da classe GerenciadorMensagem como uma thread foi necessria pelo fato de a leitura e escrita em sockets travar a execuo da MIDlet
caso no ocorra em um contexto de execuo separado.
Ao se iniciar a execuo da thread aberta uma conexo com o servidor, obtido
os fluxos de entrada e sada e, em seguida, passa-se para o estado de processamento
das mensagens.
O trecho de cdigo ilustrado na Figura 3.28 apresenta o loop que permite o
envio ou o recebimento de mensagens.

Figura 3.28: Trecho de cdigo mostrando a maneira como o cliente envia ou recebe
mensagens.
Na classe GerenciadorMensagem foram definidas rotinas que lem e escrevem nos fluxos de acordo com o sistema de cabealhos definido.
A seqncia de troca de mensagens entre o servidor e a MIDlet ocorre da
seguinte maneira: ao receber uma mensagem de notificao dizendo que o turno
do jogador em questo, inicia-se uma contagem do nmero de aes que podero
ser realizadas pelo jogador (que varia de acordo com o nmero de sprites e de
cidades que no esto em produo). Passada esta etapa, o jogador pode executar
aes de movimento, construo de sprites, construo de cidades entre outros.
Cada ao gera uma mensagem que enviada ao servidor para que ele a processe e retorne as notificaes necessrias. Enquanto isso, os demais participantes
encontram-se em um loop que os obriga a ler o fluxo de entrada com o servidor at
que o jogador atual termine seu turno e o servidor decida qual jogador possuir a
98

vez.
A Figura 3.29 apresenta o trecho de cdigo onde o jogador, que no est na
sua vez, fica parado lendo as mensagens enviadas pelo servidor.

Figura 3.29: Trecho de cdigo mostrando o loop onde o jogador permanece at

que inicie o seu turno.

99

100

Captulo 4

Resultados e discusses
Este captulo objetiva expor em maiores detalhes e de um modo mais claro as
caracterticas positivas e negativas encontradas na plataforma J2ME para o desenvolvimento de jogos multiplayers para celulares.
Para cumprir o objetivo proposto, o captulo foi dividido em duas sees. A
seo 4.1 apresenta as caractersticas identificadas no projeto que justificam a escolha da plataforma J2ME para o desenvolvimento de jogos multiplayers e a seo 4.2 aquelas que poderiam ser responsveis pela no escolha da tecnologia no
desenvolvimento de aplicaes com estas caractersticas. Estas anlises sero realizadas tendo como base o profile MIDP 1.0, pelo fato de este perfil ser o mais
adequado para o desenvolvimento de aplicaes para celulares em J2ME e a verso 1.0 ter sido utilizada durante a maior parte da implementao do jogo modelo.
No entanto, sempre que for necessrio, ser realizada uma referncia a verso 2.0
do profile.

4.1

Vantagens na utilizao do profile MIDP 1.0 para a

construo de jogos multiplayers

Integrao com outros produtos da plataforma Java. Esta caracterstica

permite o desenvolvimento de solues completas baseadas na tecnologia
Java de ponta a ponta;
linguagem de programao com sintaxe simples. A linguagem Java, que
a utilizada por J2ME, possui uma sintaxe de fcil compreenso, responsvel
por facilitar o desenvolvimento e a depurao dos cdigos;
101

 linguagem orientada a objetos. A linguagem Java puramente orientada

a objetos. Esta caracterstica muito importante no desenvolvimento de
grandes projetos, como um jogo multiplayer;
manipulao de todos os botes padres do teclado de celular de um
modo portvel. Esta caracterstica garante que a funo atribuda a um
boto ser a mesma em todos os aparelhos celulares;
manipulao de eventos gerados por todos os botes do celular. Em
MIDP, pode-se responder a eventos dos soft buttons, dos botes de navegao e de todo o teclado padro do celular;
primitivas de desenho bem completas. Os mtodos da classe Graphics
para o desenho em um Canvas so bem completos para o caso de primitivas
2D;
API bem estruturada. As classes so bem organizadas em pacotes dentro
da especificao, facilitando o entendimento dos seus objetivos;
disponibilidade de ferramentas de desenvolvimento. A Sun Microsystems
disponibiliza todas as ferramentas necessrias para o desenvolvimento em
J2ME de modo gratuito;
documentao completa. A Sun Microsystems tambm disponibiliza em
seu site oficial uma srie de artigos e tutoriais que cobrem todos os tpicos
desta arquitetura;
garbage collector. O coletor de lixo automtico permite o desenvolvimento
de cdigos mais confiveis, permitindo que no se preocupe com alocao
de memria;
pacotes otimizados para a maioria das estruturas de dados. A API do
MIDP inclui classes otimizadas para a maioria das estruturas de dados comumente utilizadas, como a Vector;
suporte a multithreading. A utilizao de threads til em jogos de tempo
real, onde uma thread de execuo pode ser definida para escutar o fluxo
de entrada de dados do servidor enquanto outra controla o fluxo normal do
programa.
102

 facilidade na manipulao de bytes. A API do MIDP 1.0 bastante completa com relao ao fornecimento de mtodos para a manipulao de bytes.
Esta caracterstica facilita a manipulao das mensagens a serem trocadas
entre o cliente e o servidor.

4.2

Desvantagens na utilizao do profile MIDP 1.0 para

a construo de jogos multiplayers

falta de suporte a ponto flutuante e primitivas de desenho de tringulos.

Esta caracterstica dificulta o uso de grficos 3D no celular;
repintagem da tela ocorre em thread separada. Uma vez solicitada uma
requisio de repintura da tela, no h como saber quando este processo
ser realizado. Isto pode fazer com que sejam geradas imagens estranhas
no display do usurio, j que pode-se repintar a tela durante o processo de
mudana do estado atual do jogo, por exemplo. No MIDP 2.0 pode-se forar
a repintura no fluxo normal de execuo do programa, fazendo com que a
execuo do cdigo no continue at que esta seja completada;
manipulao dos eventos de pressionamento de teclas ocorre em threads
separadas. Esta caracterstica pode causar o mesmo tipo de problema do
tpico anterior, ou seja, pode-se acionar um boto durante a repintagem da
tela, fazendo com que o resultado da ao no seja mostrado corretamente
no aparelho. No MIDP 2.0 este problema foi solucionado pela adio de um
mtodo que permite a verificao do estado atual das teclas do jogo durante
a thread principal do programa;
falta de suporte a transparncia nas imagens. Esta caracterstica impede
que se obtenha o efeito de superposio de tiles. No MIDP 2.0 este suporte
j foi implementado;
suporte nico a imagens do tipo png. Este tipo de imagem gera arquivos
muito grandes, ocupando grande quantidade de espao no dispositivo;
falta de suporte ao protocolo de comunicao via sockets. Esta a principal deficincia do MIDP, uma vez que este protocolo essencial em alguns
tipos de aplicaes;
103

 falta de suporte a sons. Em alguns casos, a interface com o jogador pode

ficar prejudicada pela falta de sons que poderiam indicar a completude de
uma ao. No MIDP 2.0 foi includa uma API especfica para a utilizao
de elementos de multimdia;
linguagem interpretada. O fato de J2ME ser uma plataforma interpretada,
motivo pelo qual sua portabilidade garantida, faz com que aplicativos escritos nesta linguagem no executem to rapido quanto como aqueles escritos em linguagens que geram cdigos nativos do aparelho.
inexistncia de qualquer tipo de abstrao para o desenvolvimento de
jogos baseados em tiles. A API do MIDP 1.0 no fornece nenhuma facilidade com relao ao desenvolvimento deste tipo de jogo. Entretanto, MIDP
2.0 definiu um pacote especfico para este tipo de aplicao.

104

Captulo 5

Concluses
Este captulo apresenta as concluses finais do projeto com relao ao uso da
tecnologia J2ME no desenvolvimento de aplicaes multiplayers para celulares e
algumas sugestes para trabalhos futuros. Para tal, o captulo foi dividido em duas
sees: a seo 5.1 apresenta as concluses finais e a seo 5.2 as propostas para
trabalhos futuros.

5.1

Concluses

A utilizao do profile MIDP 1.0, apesar dos problemas encontrados, pode ser
considerada adequada para o desenvolvimento de jogos multiplayers para celulares.
Entretanto, apesar de ainda no ser implementado por nenhum dispositivo real,
a utilizao do profile MIDP verso 2.0 torna o o desenvolvimento de jogos no
estilo 2D, baseados na idia de tiles, muito simples e tambm deixa as aplicaes
mais eficientes. Estas melhoras ocorrem pois a API desta verso do MIDP possui
classes altamente otimizadas que abstraem a maioria dos conceitos necessrios ao
desenvolvimento de jogos deste estilo.
O nico problema real verificado nas duas verses do profile MIDP est relacionado com o fato de no ser obrigatria a implementao de outros protocolos
de comunicao que no o HTTP. Este problema deve ser bem dimensionado ao
se desenvolver qualquer tipo de aplicao em J2ME para celulares, pois no pode
ser resolvido atravs de nenhuma tcnica fornecida pela linguagem. Esta questo totalmente dependente da arquitetura do aparelho alvo. A falta de suporte a
conexes via sockets uma de suas principais deficincias.
105

Conclui-se, ento, que a utilizao da plataforma J2ME ou, mais especificamente, do profile MIDP no desenvolvimento de jogos multiplayers baseados em
tiles para celulares satisfatria quando se estiver utilizando a verso 1.0 deste perfil. No entanto, ao se utilizar a verso 2.0, esta qualificao sofrer uma melhora
considervel, devido as grandes facilidades implementadas. A integrao com
as outras plataformas da tecnologia Java e a facilidade de construo de cdigos
nesta linguagem so caractersticas que acrescentam pontos positivos a plataforma
J2ME.
A construo de jogos multiplayers que no usam tiles para construir a sua interface torna-se mais complexa nesta plataforma, pois exige a manipulao constante das primitivas grficas e um controle maior sobre os mtodos de desenho na
tela. A API de jogos do MIDP 2.0 no apresenta muita utilidade nesta situao.
No entanto, ainda vivel utilizar J2ME para este tipo de aplicao.
A Tabela 5.1 apresenta as consideraes mais importantes obtidas com relao
a utilizao da plataforma J2ME no desenvolvimento de aplicaes multiplayers
para celulares.

5.2

Sugestes para trabalhos futuros

Atravs dos resultados obtidos por este projeto pode-se ainda desenvolver outros trabalhos. Algumas propostas de continuidade so:
melhorar a especificao do jogo modelo, permitindo tambm uma melhora
no quesito diverso proporcionada ao jogador;
implementar a verso cliente do jogo modelo de uma maneira mais eficiente,
utilizando ainda a verso 1.0 do profile MIDP;
implementar a verso cliente do jogo modelo utilizando-se das melhorias
oferecidas pela API do MIDP 2.0;
definir mtricas que permitam uma comparao mais detalhada das duas
verses do profile MIDP no desenvolvimento de jogos multiplayers;
realizar testes em aparelhos e emuladores de dispositivos reais. Estes testes
permitiriam verificar a performance da aplicao em uma rede celular real.
definir uma proposta de metodologia para o desenvolvimento de jogos multiplayers em celulares usando o profile MIDP. Esta metodologia forneceria
106

Tabela 5.1: Resumo das concluses obtidas com relao a utilizao da plataforma
J2ME no desenvolvimento de jogos multiplayers.
Caractersticas
Potencial para comercializao

Manipulao
bytes
Fluxo de jogo

de

Controle
centralizado no MIDP
2.0.
Fcil manipulao.

Interface
Imagens

Arquitetura
comunicao

de

Linguagem Java
API

Vantagens
Grande nmero de
dispositivos com
suporte a MIDP
1.0.
Fcil manipulao.

Suporte a transparncia no MIDP

2.0.
Fcil
integrao com outras
plataformas Java.
Simples, OO e portvel.
Bem estruturada e
otimizada. API especfica para jogos
no MIDP 2.0.

Desvantagens
MIDP 2.0 ainda
no disponvel no
mercado.

Threads separadas
no MIDP 1.0.
No suporta grficos 3D.
Suporte nico a
imagens do tipo
png.
Suporta apenas o
protocolo HTTP.
Interpretada.

tcnicas para tratar melhor os problemas que possam ocorrer na implementao deste tipo de aplicao e maximizar os benefcios oferecidos pela plataforma.

107

108

Referncias Bibliogrficas
[POD2002] Revista Poder. URL: http://www.poderonline.com.br.
Acessado em novembro de 2002.
[PAW2002] Pawlan, Monica. Introduction to Wireless Technologies. URL:
http://wireless.java.sun.com/getstart/articles/
intro/. 09 de outubro de 2002.
[INF2002A] InfoExame, Planto Info. 32 milhes de celulares no pas, diz Anatel.
URL: http://www.infoexame.com.br. 21 de novembro de 2002.
[INF2002B] InfoExame, Planto Info. H mais linhas celulares do que fixas na
AL. URL: http://www.infoexame.com.br. 08 de janeiro de 2002.
[INF2001] InfoExame, Planto Info. Mais de 90% dos jovens finlandeses tm celular. URL: http://www.infoexame.com.br. 17 de julho de 2001.
[IBI2002] IBiznet 2002, Estatsticas. URL: http://www.ibiznet.com.
br. Acessado em 26 de novembro de 2002.
[FOX2002] Fox, David. Will Mobile Games Sweep the Nation? URL: http:
//www.onjava.com. 10 de dezembro de 2002
[NOK2002] Site Oficial da Nokia. URL: http://www.nokia.com.br.
Acessado em 26 de novembro de 2002.
[DAT2002] Data Monitor Market Analysis. URL: http://datamonitor.
com/. Acessado em 28 de novembro de 2002.
[TEL2002] Telecom Web. URL: http://www.telecomweb.com.br. Acessado em 26 de novembro de 2002.
109

R Technology.
[SUN2003A] Sun Microsystems. Introduction to Wireless Java
URL: http://wireless.java.sun.com/getstart/. 04 de fevereiro de 2003.

[SUN2003B] Sun Microsystems. Users Guide Wireless Toolkit Version 2.o Beta
R 2 Platform, Micro Edition. Janeiro de 2003.
2 - Beta Draft. Java
[SUN2002A] Sun Microsystems. A Brief History of the Green Project. URL:
http://java.sun.com/people/jag/green/. 28 de novembro de
2002.
[SUN2002B] Sun Microsystems. Users Guide Wireless Toolkit Version 1.0.4.
R 2 Platform, Micro Edition. Junho de 2002.
Java
[SUN2002C] Sun Microsystems. Version 2.0 of Mobile Information Device Profile Specification. URL: http://jcp.org/aboutJava/
communityprocess/final/jsr118/index.html. 2002.
[SUN2002D] Sun Microsystems. Wireless Toolkit. URL: http://java.sun.
com/j2me/toolkit. Acessado em novembro de 2002.
R Tutorial URL: http://java.
[SUN2002E] Sun Microsystems The Java
sun.com. 2002.

[SUN2002F] Sun Microsystems MIDP Style Guide, Mobile Information Device

Profile (MIDP) 1.0a. URL: http://java.sun.com Agosto de 2002.
[JON2002] Pawlan, Jonathan. World of Wireless Communications. URL:
http://wireless.java.sun.com/getstart/articles/
hardware/. 09 de outubro de 2002.
R Technology: an early history. URL: http://
[BYO2002] Byous, Jon. Java
java.sun.com/features/1998/05/birthday.html. 07 de junho de 2002.

[GOS & MCG1996] Gosling, James & McGilton, Henry. The Java Language
Environment. A White Paper. URL: http://java.sun.com/docs/
white/langenv/index.html. Maio de 1996.
[GOS, JOY, STE & BRA2000] Gosling, James & Joy, Bill & Steele, Guy & Bracha, Gilad. The Java Language Specification. Second Edition. 2000.
110

[CAM & WAL2002] Campione, Mary & Walrath, Kathy. About the Java Technology. URL: http://developer.java.sun.com/developer/
onlineTraining/new2java/overview.html. Janeiro de 2002.
R Virtual Machine
[LIN & YEL1999] Lindholm, Tim & Yellin, Frank. The Java
Specification. Second Edition. 1999.

[ORT & GIG2003] Ortiz, C. Enrique & Gigure, Eric. Java Comunnity Process.
URL: http://jcp.org. Acessado em 22 de maro de 2003.
[ORT2002A] Ortiz, C. Enrique. A Survey of J2ME Today. URL: http://
wireless.java.sun.com/getstart/articles/survey/. Novembro de 2002.
[ORT2002B] Ortiz, C. Enrique. Introduction to OTA Application Provisioning.
URL:
http://wireless.java.sun.com/midp/articles/
ota/. November 2002.
[ORT & GIG2001] Ortiz, C. Enrique & Gigure, Eric. Mobile Information Device
Profile for Java 2 MicroEdition. Wiley Computer Publishing. 2001.
[JSE2002] Java 2 Standard Edition. URL: http://java.sun.com/j2se/.
Acessado em 02 de novembro de 2002.
[JEE2002] Java 2 Enterprise Edition. URL: http://java.sun.com/
j2ee/. Acessado em 02 de novembro de 2002.
[JME2002] Java 2 Micro Edition. URL: http://java.sun.com/j2me/.
Acessado em 02 de novembro de 2002.
[MUC2002] Muchow, John W. Core J2ME Technology & MIDP. Sun Press. 2002.
[WHI & HEM2002] White, james P. & Hemphill, David A. Java 2 Micro Edition,
Java in Small Things. Manning Publications. 2002.
[GIG2002] Giguere, Eric. J2ME[tm] Optional Packages. URL: http:
//wireless.java.sun.com/midp/articles/optional/. Dezembro de 2002.
[CLC2003] Connected Limited Device Configuration - CLDC. URL: http://
java.sun.com/products/cldc. Abril de 2003.
111

[CDC2003] Connected Device Configuration - CDC. URL: http://java.

sun.com/products/cdc. Abril de 2003.
[MID2003] Mobile Information Device Profile - MIDP. URL: http://java.
sun.com/products/midp. Abril de 2003.
[MAH2003] Mahmoud, Qusay H. Future Java Technology for the Wireless
Services Industry. URL: http://wireless.java.sun.com/midp/
articles/j2mefuture/. Fevereiro de 2003.
[KNU2003] Knudsen, Jonathan. Creating 2D Action Games with the Game
API. URL: http://wireless.java.sun.com/midp/articles/
game/. Maro de 2003.
[KNU2002] Knudsen, Jonathan. Whats New in MIDP 2.0. URL:
http://wireless.java.sun.com/midp/articles/midp20/.
Novembro de 2002.
[KNU & NOU2002] Knudsen, Jonathan & Nourie, Dana. Wireless Development
Tutorial Part I: Getting Started with MIDlet Development. URL: http:
//wireless.java.sun.com/midp/articles/wtoolkit. 12 de
fevereiro de 2002.
[ONE2003] Sun One Studio - Sun One for Developers. URL: http://
sunonedev.sun.com/. Acessado em maro de 2003.
R development solution. URL: http://
[JBU2003] JBuilder - The leading Java
www.borland.com/jbuilder/index.html. Acessado em maro
de 2003.

[JCR2003] JCreator LE por Wendel de Witte. URL: http://www.

jcreator.com. Acessado em maro de 2003.
[JED2003] Jedit - Open Source programmers text editor. URL: http://www.
jedit.org. Acessado em maro de 2003.
[POS2003] Palm OS Emulator. URL: http://www.palmos.com/dev/
tools/emulator. Acessado em maro de 2003.
R 2 Plat[DAY2001] Day, Bill. Developing Wireless Applications using the Java
form, Micro Edition. 2001. URL: http://www.billday.com. 2001.

112

[MIC2003] Microsoft Microsoft Age of Empires URL: http://www.

microsoft.com/catalog/display.asp?subid=22&site=
10977&x=45&y=11 2003.
[MIP2003] Microprose Civilization URL: http://www.infogrames.com.
br/jogos.asp?jogo_id=17 2003.

113

114

Resumo estendido
Assis, Wendel Malta. AVALIAO DA TECNOLOGIA J2ME NO CONTEXTO DE DESENVOLVIMENTO DE JOGOS MULTIPLAYERS PARA
CELULARES. 121p. 2003. Este trabalho apresenta uma avaliao da utilizao da plataforma Java 2 Platform Micro Edition (J2ME) da Sun Microsystems,
que vem se destacando no mercado de construo de aplicaes para dispositivos
mveis, no desenvolvimento de jogos multiplayers para celulares.
Atualmente, a telefonia celular encontra-se em uma fase de grande expanso,
momento em que esto surgindo novas tecnologias de transmisso e aparelhos
cada vez mais modernos e com maiores funcionalidades. Estes novos aparelhos,
por apresentarem um maior poder computacional, permitem o desenvolvimento de
aplicaes mais complexas, como os jogos.
Dentre o mercado de jogos para celulares e outros dispositivos mveis, os jogos multiplayers vem se destacando por permitirem disputas entre vrios jogadores
ao mesmo tempo e no apenas contra o computador, garantindo um maior nvel
de diverso durante as partidas. Assim, apresentam um maior grau de interao
com os usurios e exigem um controle de concorrncia avanado, representando
um grande desafio de implementao.
O objetivo deste trabalho consiste em apresentar as dificuldades e facilidades
encontradas ao se utilizar a plataforma J2ME no desenvolvimento de um jogo modelo multiplayer para celulares, chamado Alea Jacta Est, e, em seguida, avalila de um modo geral com relao ao desenvolvimento deste tipo de aplicao.
Para se desenvolver aplicaes para celulares utilizando J2ME deve-se escolher entre uma das verses da especificao Mobile Information Device Profile
(MIDP) definida pela plataforma. A concluso final do projeto foi que a utilizao
do MIDP 1.0 cumpre satisfatoriamente com as necessidades de um desenvolvedor
de jogos multiplayers para celulares. No entanto, a verso 2.0 do MIDP, ainda
no implementada em aparelhos reais, proporciona melhores ferramentas para o
desenvolvimento de tais aplicaes.