Daniel Ricardo dos Santos

Diogo de Campos
Mauricio Oliveira Haensch

Desenvolvendo Jogos com Java ME

Daniel Ricardo dos Santos

Diogo de Campos
Mauricio Oliveira Haensch

Desenvolvendo Jogos com Java ME

PET Computaca o

U NIVERSIDADE F EDERAL DE S ANTA C ATARINA

C ENTRO T ECNOL OGICO

D EPARTAMENTO DE I NFORM ATICA E E STATI STICA

T UTORIAL
P ROGRAMA DE E DUCAC AO

Licenca:
Atribuica o-Uso Nao-Comercial-Compartilhamento pela mesma Licenca 2.5 Brasil

Para cada novo uso ou distribuica o, voce deve deixar claro para outros os
termos da licenca desta obra.
Qualquer uma destas condico es podem ser renunciadas, desde que Voce obtenha permissao do autor.
Nada nesta licenca prejudica ou restringe os direitos morais dos autores.

Sumario

Introduca o

p. 5

1.1

A plataforma Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 5

1.2

Java Card . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 5

1.3

Java Micro Edition (ME) . . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 6

1.4

Java Standard Edition (SE) . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 6

1.5

Java Enterprise Edition (EE) . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 6

Java ME
O que e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 7

2.1.1

Aplicaco es . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 7

2.1.2

Vantagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 7

2.2

Principais diferencas entre Java SE e Java ME . . . . . . . . . . . . . . . . .

p. 8

2.3

Configuraco es e perfis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 9

2.4

JCP e JSRs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 11

2.1

p. 7

Ferramentas de desenvolvimento

p. 12

3.1

Sun Wireless Toolkit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 12

3.2

IDEs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 12

3.2.1

NetBeans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 12

3.2.2

Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 13

Bibliotecas Java ME

p. 14

4.1

p. 14

Java SE x Java ME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.2
5

p. 14

Desenvolvendo para Dispositivos Moveis

p. 16

5.1

Uso de memoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 16

5.2

Resoluca o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 16

5.3

Configuraco es e perfis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 17

Desenvolvendo Jogos

p. 18

6.1

A classe MIDLet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 18

6.2

Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 19

6.3

Displays e Displayables . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 20

6.4

Canvas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 20

6.5

Sprites e Tiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 21

6.5.1

Sprites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 21

6.5.2

TiledLayer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 22

Sons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 23

6.6
7

Bibliotecas disponveis . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Estudo de Caso - Liga Quatro

p. 26

7.1

Introduca o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 26

7.2

Estrutura do codigo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 26

7.2.1

Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 26

7.2.2

Eventos do menu principal . . . . . . . . . . . . . . . . . . . . . . .

p. 29

7.2.3

A classe TelaDoJogo . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 30

7.2.4

A classe Bola . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 33

7.2.5

PlayTone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 35

Bibliografia

p. 36

Introduca o

1.1

A plataforma Java

Java e uma tecnologia que se estende muito alem da propria linguagem de programaca o.
Trata-se, na verdade, de uma plataforma de desenvolvimento.
A plataforma Java compreende um conjunto de softwares e especificaco es da Sun Microsystems para o desenvolvimento de aplicativos. A grande vantagem desta plataforma e a sua compatibilidade nao apenas entre sistemas operacionais, mas tambem entre diversas arquiteturas,
variando de PDAs e set-top boxes ate servidores. As aplicaco es desenvolvidas nesta plataforma
tambem sao diversas, variando de aplicativos embarcados a jogos e aplicativos web.
Devido a essa grande variedade a plataforma e dividida em quatro diferentes edico es.
Cada edica o e composta de um pacote de softwares que permitem o desenvolvimento e a
execuca o de programas escritos na linguagem Java.
As plataformas sao desenhadas nao para um processador especfico, mas para uma Java Virtual Machine (JVM) e um compilador com um conjunto de bibliotecas. A principal vantagem
do uso da maquina virtual e aumentar a portabilidade do codigo.

1.2

Java Card

Java Card e a edica o mais limitada da plataforma Java e e destinada a smart cards ou dispositivos similares com pouqussima memoria. Seu principal foco e a seguranca, com suporte ao
encapsulamento de dados no aplicativo, firewall entre aplicativos e criptografia.
Atualmente, encontra-se em desenvolvimento a versao 3 da plataforma.

1.3

Java Micro Edition (ME)

Voltada para dispositivos com pouca capacidade de processsamento e memoria limitada,

principalmente dispositivos moveis. Muito usada em celulares e PDAs, estende-se tambem
para aparelhos como set-top boxes e Blu-ray players. Apresenta algumas dificuldades no desenvolvimento devido a grande variedade de dispositivos e suas especificidades.
A plataforma Java ME e detalhada no proximo captulo.

1.4

Java Standard Edition (SE)

E a edica o usada para o desenvolvimento de aplicaco es portaveis de proposito geral. Contem

o que necessario para o desenvolvimento de aplicaco es desktop e applets, como pacotes de interface grafica, entrada e sada, comunicaca o com bancos de dados, etc.
Atualmente, encontra-se na versao 6.

1.5

Java Enterprise Edition (EE)

Java EE e a maior das edico es de Java, compreendendo tudo o que esta presente na Standard
Edition alem de coisas mais especficas, como o servidor de aplicaco es GlassFish. Voltada
para aplicaco es que rodam no lado do servidor e pensada para tornar as aplico es robustas,
seguras, escalaveis e portaveis. E usada para o desenvolvimento de aplicaco es web e baseadas
na arquitetura orientada a servicos (SOA), como web services.
Atualmente, encontra-se na versao 5.

Java ME

2.1

O que e

Java ME e uma das edico es da plataforma Java e, como tal, e composta pela propria linguagem, por uma Maquina Virtual e por uma coleca o de APIs.
A linguagem e a mesma usada nas outras edico es, portanto e familiar para qualquer pessoa
que ja tenha programado Java em qualquer plataforma. Para se entender Java ME, entao, e
necessario conhecer a Maquina Virtual e a coleca o de APIs.
Java ME aceita diferentes implementaco es de maquinas virtuais e normalmente a maquina
virtual e definida pela Configuraca o.
Alem desses elementos comuns, esta edica o da plataforma Java apresenta alguns elementos
especficos como Profiles e Configuraco es, que serao estudados adiante.

2.1.1

Aplicaco es

E usado principalmente para o desenvolvimento em sistemas moveis e embarcados, alguns

exemplos de sistemas que adotam Java ME sao:
Celulares;
PDAs;
Set-top boxes;
Blu-ray players.

2.1.2

Vantagens

Por ter um campo de aplicaca o bem especificado, Java ME apresenta diversas facilidades
para os desenvolvedores, tais como:

Portabilidade: Um aplicativo criado utilizando Java ME pode ser portado para diversos aparelhos, desde que sigam as mesmas especificaco es. Isso e muito importante no desenvolvimento para celulares, pois um mesmo aplicativo desenvolvido podera rodar em modelos
de diferentes fabricantes.
Boa compatibilidade entre aparelhos: Como ja foi citado acima, desde que sigam as mesmas
especificaco es, nao ha grandes problemas de compatibilidade entre os aparelhos que irao
rodar um aplicativo.
Constante desenvolvimento: Assim como todo o resto da tecnologia Java, Java ME se encontra em constante desenvolvimento, com novas funco es e capacidades sendo adicionadas
a todo momento. Esse processo de desenvolvimento segue a JCP (Java Community Process), que sera detalhado mais a frente.
Boa documentaca o: A plataforma conta com uma vasta documentaca o online, no proprio site
da Sun, alem de inumeros outros exemplos e tutoriais que podem ser encontrados em sites
e foruns.
Desenvolimento integrado: Uma das principais vantagens de Java ME e o desenvolvimento
integrado, proporcionado por ferramentas como o Wireless Toolkit (WTK) e IDEs como
o NetBeans.

2.2

Principais diferencas entre Java SE e Java ME

As principais diferencas entre Java SE e Java ME sao descritas a seguir:

Maquina Virtual: As maquinas virtuais utilizadas em Java ME sao desenhadas para serem
mais compactas e eficientes que a maquina virtual utilizada em Java SE, por isso alguns
recursos sao perdidos.

Numeros
de ponto flutuante: O suporte a ponto flutuante so foi adicionado na versao 1.1 do
CLDC, por isso ao desenvolver aplicaco es para dispositivos mais antigos e possvel que
o desenvolvedor nao encontre suporte para esta representaca o numerica.
Reflexao: O pacote java.lang.reflect so esta presente no CDC. Por isso nao e possvel utilizar
reflexao em dispositivos de menor capacidade.
APIs de alto nvel (Swing e AWT): Algumas APIs de mais alto nvel, como as utilizadas para
interface grafica nao estao presentes em Java ME.

Acesso ao sistema de arquivos: Para se ter acesso ao sistema de arquivos e necessario utilizar
o PDA Profile, ou uma implementaca o especfica de um fabricante.
Grupos de threads: O suporte a grupos de threads, threads que podem ser manipuladas em
conjunto, tambem so e provido pelo CDC.
A figura abaixo mostra uma visao geral dos componentes de Java ME e como eles se relacionam as outras tecnologias Java:

2.3

Configuraco es e perfis

As configuraco es (Configurations) e perfis (Profiles) representam as configuraco es e APIs

mnimas disponveis em um dispositivo movel.
Cada aplicativo desenvolvido necessita de uma configuraca o mnima para ser rodado, e a
garantia de que o dispositivo alvo tera essa configuraca o e fornecida pelo sistema de Configurations e Profiles.
As principais Configurations sao o CDC e o CLDC e o principal Profile e o MIDP, que sao
explicados a seguir.
O MIDP e a definica o de uma arquitetura, e define varias APIs que devem estar disponveis
em uma plataforma para promover um ambiente de desenvolvimento para as suas MIDlets. A
diferenca mais importante entre o MIDP 1.0 e o MIDP 2.0 e a introduca o de uma API para jogos,

10

que facilita muito a criaca o deste tipo de aplicativo. A maioria dos aplicativos desenvolvidos
para dispositivos moveis sao capazes de rodar em plataformas MIDP 1.0, que devem ter as
seguintes caractersticas, entre outras:
Tamanho da tela mnimo de 96x54pixels.
Input atraves de One handed keyboard ou Two handed keyboard ou Touch Screen.
128Kbytes de memoria para os componentes MIDP.
8Kbytes de memoria para dados das aplicaco es.
32Kbytes de memoria dinamica.
O MIDP 1.0 e baseado em aparelhos que seguem a configuraca o CLDC, ou seja, os aparelhos compatveis com MIDP tambem o serao com CLDC.
Dispositivos CLDC (Connected Limited Device Configuration) sao os aparelhos mais simples, que possuem uma interface menor e pouca memoria e velocidade de processamento. Devem ter no mnimo as seguintes caractersticas:
128Kb de memoria para rodar a maquina virtual.
32Kb de memoria dinamica.
Comunicaca o em rede com baixa largura de banda.
Baixa potencia (para diminuir o gasto de energia).
Dispositivos CDC (Connected Device Configuration) sao aparelhos mais potentes que os
CLDC e devem ter pelo menos as seguintes caractersticas:
512Kb de memoria para executar a maquina virtual.
256Kb de memoria dinamica.
Capacidade para comunicaca o em rede com alta largura de banda.
Suporte a` persistencia.

11

2.4

JCP e JSRs

O Java Community Process (JCP) e um processo formalizado para que varias partes interessadas colaborem no desenvolvimento de especificaco es e futuras versoes da plataforma Java.
Entre os membros da JCP podemos encontrar operadoras de telefonia como a NTT DoCoMo, desenvolvedores de dispositivos moveis como a Nokia, a Sony Ericsson e a Motorola,
outras empresas e ate mesmo pessoas fsicas.
Os documentos descrevendo as especificaco es e tecnologias propostas sao chamados Java
Specification Request (JSR).
Esses documentos sao publicamente revisados ate que um JSR se torne final e seja votado
pelo Comite Executivo da JCP.
Um JSR final prove uma implementaca o de referencia, na forma de codigo fonte e um
Technology Compatibility Kit para verificar a especificaca o da API.
O proprio JCP e descrito por um JSR, o JSR 215 de 2006.
Os JSRs sao especialmente importantes em Java ME, por causa do numero de recursos
novos e da velocidade com que mudam em dispositivos moveis.
Alguns exemplos de JSRs em Java ME:
JSR 30: J2ME CLDC 1.0
JSR 37: MIDP 1.1
JSR 68: J2ME Platform Specification
JSR 82: Bluetooth
JSR 118: MIDP 2.0
JSR 133: Java Game Profile
JSR 139: CLDC 1.1
JSR 184: Mobile 3D Graphics API for J2ME

12

Ferramentas de desenvolvimento

3.1

Sun Wireless Toolkit

O Wireless Toolkit, ou WTK, e uma ferramenta de auxlio ao desenvolvimento de aplicaco es

em Java ME (CLDC e MIDP). O WTK possui exemplos, documentaca o, funco es de otimizaca o
e um emulador para dispositivos moveis.
Ha algumas IDEs (Integrated Development Enviroment, ou ambiente de desenvolvimento)
que ja vem com o Sun Wireless ToolKit integrado, outras possuem plugins para integraca o e
tambem e possvel usar apenas o WTK para desenvolver suas aplicaco es.

3.2

IDEs

Duas IDEs ja bem conhecidas para desenvolvimento em Java (e tambem em outras linguagens de programaca o) sao o Eclipse e o NetBeans. Ambos os ambientes suportam o desenvolvimento em Java ME e serao descritos com um pouco mais de caractersticas a seguir.

3.2.1

NetBeans

O ambiente de desenvolvimento NetBeans se iniciou como um projeto de dois estudantes, e

posteriormente foi comprado pela Sun Microsystems. Por aproximadamente um ano, a empresa
manteve o ambiente como software proprietario, mas apos esse perodo o codigo foi aberto e
a partir disso foram surgindo muitas melhoras no ambiente em si e diversos plugins foram
criados. Entre esses avancos, surgiu o NetBeans Mobility Pack, que e uma extensao da IDE
para desenvolvimento com Java ME.
O NetBeans Mobility Pack ja vem integrado com o emulador da Sun (WTK), alem de suportar outros emuladores. Essa extensao tambem tem algumas ferramentas que auxiliam no
desenvolvimento para dispositivos moveis, como algumas classes que podem ser utilizadas nas

13

suas aplicaco es fora as padroes da biblioteca Java ME. Um exemplo disso e a SplashScreen,
que estende a classe Canvas do Java ME e pode ser bem u til para as aplicaco es desenvolvidas.
O Mobility Pack tambem possui o Game Builder, que auxilia o desenvolvimento de jogos.
Atraves dessa ferramenta, fica mais facil criar Sprites e Tiles para seu jogo, e o Game Builder
tambem permite a construca o de cenas (combinaco es de objetos estaticos e dinamicos) de uma
maneira mais simples e rapida, ajudando na criaca o do seu jogo.
Alem de todas as vantagens do ambiente para o desenvolvimento de aplicaco es com JavaME, e um ambiente gratuito e com boa documentaca o, alem de um forte apoio da comunidade.

3.2.2

Eclipse

Existem plugins para a IDE Eclipse para desenvolvimento com Java ME. A grande vantagem de se desenvolver com esse ambiente sao todas as facilidades do Eclipse, que e bem
poderoso e versatil para geraca o de software em Java.
Um dos plugins existentes para desenvolvimento com JavaME no ambiente Eclipse e o chamado EclipseME. Este plugin e um pouco antigo e so funciona com algumas versoes tambem
antigas da IDE. Porem, existem diversos outros plugins que podem ser utilizados para desenvolvimento de aplicaco es para a plataforma ME do Java. Esses plugins podem ser encontrados
na propria pagina da IDE Eclipse, na seca o de plugins, mas varios deles sao pagos.

14

Bibliotecas Java ME

4.1

Java SE x Java ME

O Java Micro Edition possui apenas um subconjunto dos componentes da Standard Edition,
com uma maquina virtual e algumas APIs mais limitadas. As APIs presentes no Java ME sao definidas no JCP (Java Community Process). A limitaca o de memoria dos dispositivos que rodam
Java ME acabou resultando na retirada de algumas das bibliotecas presentes no Java Standard
Edition, para manter a plataforma pequena e adequada ao seu objetivo. Porem, o Java Micro
Edition nao possui apenas uma especificaca o. Dependendo da configuraca o e perfil escolhidos,
voce pode utilizar diferentes APIs para desenvolver sua aplicaca o. Com a evoluca o do poder de
processamento e capacidade de memoria dos dispositivos, surgem novas funcionalidades mais
complexas atraves dos JSRs. Como exemplo disso, podemos citar a ausencia de variaveis do
tipo ponto flutuante (como o double) em versoes mais antigas de configuraco es e perfis do Java
ME. Devido a` essa diferenca entre as duas edico es, nem toda aplicaca o desenvolvida em Java
SE funcionara num dispositivo que roda Java ME.

4.2

Bibliotecas disponveis

Como dito anteriormente, as APIs disponveis para desenvolver a sua aplicaca o resultam
da combinaca o de configuraca o e perfil adotados pelo programador. Utilizando como exemplo
a versao 1.1 do CLDC (Connected Limited Device Configuration), os pacotes presentes para o
desenvolvimento da sua aplicaca o sao:
java.io
java.lang
java.lang.ref
java.util

15

javax.microedition.io
Outra diferenca de bibliotecas entre a Standard Edition e a Micro Edition e em relaca o a`
interface das aplicaco es. O SWT e Swing da edica o padrao de Java nao se encontram na versao
ME. A Micro Edition conta com um novo pacote para este fim, chamado java.microedition.lcdui,
que pode ser encontrado em qualquer versao do MIDP. A versao 2.0 do MIDP contem os seguintes pacotes:
java.io
java.lang
java.util
javax.microedition.io
javax.microedition.lcdui
javax.microedition.lcdui.game
javax.microedition.media
javax.microedition.media.control
javax.microedition.midlet
javax.microedition.pki
javax.microedition.rms
Como podemos notar, existe uma serie de pacotes exclusivos do JavaME (os iniciados com
javax.microedition). Assim, com a presenca de alguns pacotes exclusivos, tambem pode-se
afirmar que nem toda aplicaca o escrita em Java ME funcionara na plataforma Java SE.

16

Desenvolvendo para Dispositivos

Moveis

5.1

Uso de memoria

Os dispositivos para os quais se desenvolve em Java ME, em geral, possuem pouca memoria,
sendo isso um fator de risco para o desenvolvimento de aplicaco es desse tipo, juntamente com
a capacidade de processamento. Para evitar isso, deve-se ter um cuidado maior para essa classe
de software.
A utilizaca o de estruturas de dados e tipos de dados mais simples e um bom comeco para
reduzir o uso de memoria. Outra sada e reduzir o numero de objetos criados, ou reduzir o
tamanho dos objetos que sao utilizados na aplicaca o. As imagens utilizadas tambem sao uma
grande fonte de Out of Memory Error, a exceca o que ocorre ao se utilizar memoria em excesso.
Se mesmo com esses cuidados ainda existem problemas com memoria, voce pode usar um
profiler para auxiliar a encontrar usos desnecessarios ou ineficientes de memoria. Um Profiler
e uma ferramenta que ajuda a encontrar bottlenecks da sua aplicaca o, achando memory leaks
e rastreando a vida dos objetos. Com essas informaco es, e mais facil encontrar problemas na
implementaca o que ocasionam os erros de uso de memoria da sua aplicaca o.

5.2

Resoluca o

Os diferentes dispositivos que suportam aplicaco es em Java ME possuem resoluco es de tela

diferentes. Assim, na hora de desenvolver esse tipo de software, e preciso ter em mente alguma
resoluca o um pouco mais especfica para a qual sera desenvolvida a aplicaca o. E muito mais
facil desenvolver para uma resoluca o especfica do que tentar fazer um software mais geral que
rode em varias resoluco es diferentes.
Normalmente sao lancadas algumas versoes do software, cada uma para uma resoluca o di-

17

ferente. Isso tambem ajuda na questao de capacidade do dispositivo. Geralmente dispositivos

com uma mesma resoluca o da tela possuem uma capacidade de processamento e memoria parecidos, facilitando com que uma aplicaca o funcione em uma quantidade maior de aparelhos
moveis ao ser desenvolvida especificamente para um conjunto de dispositivos similares.

5.3

Configuraco es e perfis

A escolha da configuraca o e sua versao, assim como a versao do perfil adotado pelo programador, devera levar em conta o dispositivo para o qual se esta desenvolvendo a aplicaca o,
assim como as funcionalidades da aplicaca o sendo desenvolvida. Essa escolha acaba definindo
em que tipos de dispositivos a sua aplicaca o ira rodar. Por esse motivo, e fundamental que se
verifique as configuraco es e perfis suportados pelo dispositivo de destino da sua aplicaca o.

18

Desenvolvendo Jogos

6.1

A classe MIDLet

A classe MIDlet corresponde a` s aplicaco es do MIDP, e deve ser estendida para que o
software que gerencia as aplicaco es do dispositivo consiga controlar e modificar o estado das
aplicaco es (rodando ou pausada, por exemplo). A classe principal de sua aplicaco es deve estender a esta classe e implementar os metodos utilizados para criar, comecar, pausar e destruir
a aplicaca o. A MIDLet funciona como uma interface entre o gerenciador de aplicaco es e a sua
aplicaca o. Essa comunicaca o funciona atraves de sinais enviados entre o software gerenciador
do dispositivo e a aplicaca o.
Para comecar a sua aplicaca o, a classe MIDlet possui o metodo startApp, que faz com que
o estado atual se torne Active, enviando um sinal para o software gerenciador de aplicaco es.
Caso alguma exceca o ocorra durante a execuca o desse metodo, a aplicaca o e destruda automaticamente e o metodo destroyApp e chamado. A aplicaca o tambem pode ser pausada com o
pauseApp, entrando no estado Paused. Nesse estado, o MIDlet deve liberar todos os recursos
alocados.
Alem dos metodos que enviam um sinal ao MIDlet para a mudanca de estado, ha tambem
metodos da classe que enviam um sinal ao gerenciador de aplicaco es para informar da mudanca
de estado da sua aplicaca o, como o notifyDestroyed e notifyPaused. Ao utilizar o notifyDestroyed, por exemplo, o software gerenciador nao ira chamar o destroyApp, mas o proprio MIDlet deve ter realizado as mesmas operaco es que o metodo de destruica o, como a liberaca o de
recursos.
Atraves da combinaca o desses metodos da classe MIDlet monta-se o ciclo de vida de sua
aplicaca o. E importante manter correta a comunicaca o entre a aplicaca o e o software gerenciador de aplicaco es, estando sempre atento a` questao de liberaca o de recursos e troca de sinais
para mudanca de estado.

19

6.2

Commands

Os commands do Java ME sao usados para gerar e tratar eventos. Por exemplo, um comando
pode ser associado a um botao, ou imagem, de modo que, quando este for selecionado, ou
clicado, o evento sera disparado.
Um command guarda a informaca o semantica de uma aca o, como pode ser visto pelos tipos
de comandos existentes, mostrados mais abaixo. Desse modo, ele e responsavel apenas pelo significado, e nao a` aca o propriamente dita. A aca o fica como responsabilidade da implementaca o
de um CommandListener associado a` tela em o Command se encontra.
Um comando deve ser criado da seguinte maneira:
Command(String shortLabel, String longLabel, int commandType, int priority)
Onde shortLabel e o nome abreviado do comando, longLabel e o nome completo do comando e commandType e o tipo do comando. Ha tambem um outro construtor para objetos da
classe Command, com a ausencia do parametro longLabel.
Os tipos possveis do commandType sao os seguintes:
OK
ITEM
SCREEN
HELP
BACK
CANCEL
EXIT
STOP
A prioridade de um comando so e importante se algum objeto disparar mais de um evento
de uma vez, neste caso, somente o comando de maior prioridade e avaliado.
Estes comandos devem entao ser tratados por uma classe que implementa a interface CommandListener. Nesta classe sera definido o metodo commandAction que vai decidir que aca o
deve ser tomada quando cada evento e disparado.

20

Exemplos de implementaco es de commands e CommandListeners podem ser encontrados

no final desta apostila, na seca o Estudo de Caso - Liga Quatro ou neste site: http://pt.
wikibooks.org/wiki/J2ME/Li%C3%A7%C3%B5es/CommandListener

6.3

Displays e Displayables

O Display e u nico por MIDlet e e o responsavel por funco es relacionadas a` tela do dispositivo. Para obter uma referencia ao Display, a aplicaca o deve utilizar o metodo getDisplay.
Atraves dessa classe, e possvel chamar metodos para obter algumas informaco es importantes
para a sua aplicaca o, como o numero de cores do aparelho, ou ate mesmo se ele suporta cores.
A classe Display tambem possui metodos para controlar funco es do dispositivo, como vibrar,
atraves do metodo vibrate, e um efeito de luz do aparelho, com o metodo flashBackLight.
Um objeto so possui a capacidade de ser inserido no Display ao estender a classe Displayable. Porem, um Displayable apenas tem capacidade para ter comandos, listeners, ttulos
e tickers associados a ele. Tudo que e mostrado e a sua interaca o com o usuario e definida
atraves de subclasse, como e o exemplo do Canvas. A utilizaca o do Displayable e feita com
os metodos setCurrent e getCurrent da classe Display, que troca e retorna o objeto do tipo
Displayable atualmente na tela, respectivamente.
Caso nao seja definido nas subclasses do Displayable, a configuraca o inicial do seu objeto
sera:
Nao visvel no Display;
Ttulo null;
Nenhum ticker associado ao Displayable em questao;
Nenhum command existente;
Nenhum listener para comandos.

6.4

Canvas

A classe Canvas e uma subclasse de Displayable, e e utilizada para objetos da sua aplicaca o
que precisam fazer alteraco es graficas na tela, ou receber eventos de teclas pressionadas no
dispositivo. Em geral, os jogos utilizam muito essa classe, para poder interagir com o usuario
tanto na recepca o de estmulos quanto na apresentaca o dos resultados desses estmulos.

21

Esta classe e responsavel por tratar eventos de entrada, como teclas pressionadas, soltas
ou mantidas pressionadas (keyPressed, keyReleased e keyRepeated, respectivamente) e tambem
eventos com um pointer de um PDA (similares aos de tecla). E possvel verificar qual das
teclas foi pressionadas com o metodo getKeyCode, mas em Java ME existe um artifcio que e
recomendado para os desenvolvedores de jogos, que e o sistema de Game Actions.
Os Game Actions sao definidos para aplicaco es portaveis que utilizam as teclas de setas de
um dispositivo e eventos relacionados a jogos. O MIDP prove os seguintes Game Actions: UP,
DOWN, LEFT, RIGHT, FIRE, GAME A, GAME B, GAME C e GAME D. Cada Game Action
pode estar a associado a mais de um Key Code, porem cada tecla so pode estar associada a` um
Game Action. A aplicaca o pode traduzir um Key Code para um Game Action atraves do metodo
getGameAction e fazer o oposto atraves de getKeyCode. Apesar de varios Key Codes poderem
estar associados ao mesmo Game Action, apenas um deles e retornado com este metodo.
Outra funca o do Canvas e o controle grafico do que e exibido. Isso e feito atraves do
setFullScreenMode, que tanto coloca quanto tira do modo de exibica o em tela cheia, e o metodo
repaint, que renderiza o Canvas por completo ou apenas uma regiao dele, artficio muito u til
para reduzir o tempo gasto com processamento para repintar uma a rea sem alteraco es.

6.5

Sprites e Tiles

Entre as bibliotecas do Java ME, existem as classes Sprite e TiledLayer, que sao utilizadas para fazer os objetos animados e o fundo do seu jogo, respectivamente. Um Sprite, por
sua definica o, e uma imagem ou animaca o em duas ou tres dimensoes que sera utilizada para
representar um objeto, e muitas vezes sao usados para detectar colisoes ou fazer algum tipo
de interaca o do jogo. Ja os Tiles sao usados para representar o fundo da tela, usualmente uma
paisagem, um tabuleiro ou alguma cena de um jogo.

6.5.1

Sprites

Para a classe Sprite, um arquivo de imagem e dividido em varios frames de tamanho igual,
e voce pode criar livremente uma sequencia dos frames para gerar sua animaca o. Para animar
sua sequencia, sao usados metodos como o nextFrame, setFrame e prevFrame. Com esta classe
do Java ME tambem e possvel definir a a rea de colisao de um sprite, assim como verificar se
houve colisao entre dois sprites, entre um sprite e um Tile ou ate mesmo entre um sprite e uma
imagem, utilizando metodos como defineCollisionRectangle e collidesWith.

22

Os Sprites em Java ME sao produzidos a partir de uma u nica imagem com todos os frames
que serao utilizados para renderizar a animaca o. E possvel fazer apenas um frame, mas nos
demais casos a imagem fonte e dividida igualmente em frames de uma determinada largura e
altura. A sequencia da animaca o e criada atraves de uma Frame Sequence, que nada mais e do
que um array com os ndices dos frames gerados.
Um objeto do tipo Sprite pode ter um pixel de referencia. Esse pixel e definido por padrao
como a posica o (0,0) do sprite, podendo ser redefinida para qualquer outra posica o, ate mesmo
fora dos limites do sprite. Esse pixel existe para permitir algumas operaco es que sao realizadas baseadas em algum referencial, como transformaco es de rotaca o e espelhamento do sprite.
Segue abaixo um exemplo de sprite com um pixel de referencia influenciando na rotaca o.

Figura 6.1: Imagens retiradas de: http://java.sun.com/javame/reference/apis/jsr118/javax/

microedition/lcdui/game/Sprite.html

6.5.2

TiledLayer

Uma TiledLayer se trata de uma imagem composta de uma grade de celulas, onde cada
celula e preenchida com uma imagem estatica chamada tile. Essa composica o de imagens
menores permite economia de espaco, e e uma tecnica muito usada em diversos jogos de duas
dimensoes.
Cada posica o na grade da TiledLayer recebe um indce, ao qual e associado um tile. Cada
um desses tiles e considerado estatico e fica ligado a` imagem que ele representa. Existe tambem
um animated tile, que e um tile virtual associado dinamicamente a` um estatico. Com os tiles
animados, ao se utilizar o mesmo animated tile em diversas celulas da grade, e possvel mudalas ao mesmo tempo apenas modificando o tile estatico ao qual eles estao associados.
A grade da TiledLayer possui um numero de celulas de mesmo tamanho distribudas por

23

linhas e colunas, definidas na criaca o do objeto. As celulas da grade nao podem receber mais
de um tile por vez, mas varias celulas podem receber o mesmo tile. Para mudar o conteudo de
uma das celulas, podem ser utilizados os metodos setCell e fillCells.

6.6

Sons

O JavaME possui uma API responsavel por funcionalidades multimdia, como gravaca o de
a udio e vdeo, alem dos controle de sons. A Mobile Media API, ou MMAPI, funciona basicamente atraves das classes Manager, Player e os controladores VolumeControl e ToneControl.
A classe Manager e utilizada para criar os Players. Isso pode ser feito atraves do metodo
createPlayer, onde voce passa como parametros um InputStream do arquivo de som que sera
tocado e o tipo (wave, midi, mp3, etc). Assim, voce obtem um Player para tocar o som/musica
desejada e devera controlar esse novo objeto para obter o efeito desejado. Alguns exemplos de
formatos e as Strings que devem ser passados como parametro para o createPlayer:
Wave - audio/x-wav
AU - audio/basic
MP3 - audio/mpeg
Midi - audio/midi
Tone - audio/x-tone-seq
O Player que foi obtido pode ser utilizado de uma forma simples, apenas chamando o
metodo start para que ele comece e pare ao chegar ao fim da mdia especificada.
InputStream stream = getClass().getResourceAsStream(sound_file);
Player p = Manager.createPlayer(stream, format);
p.start();
O Player permite uma maior variedade de aco es, com a combinaca o dos metodos da classe
e o seu sistema de estados. Os estados da classe Player sao: Unrealized, Realized, Started,
Closed e Prefetched. A imagem abaixo mostra como sao feitas as transico es entre os estados
atraves dos metodos mostrados nas flechas presentes na figura.

24

O estado Unrealized indica que o Player nao possui nem informaco es nem recursos necessarios para funcionar. Realized indica que apenas os recursos nao foram adquiridos ainda. O
estado Prefetched significa que todos os recursos ja foram adquiridos. Ja o estado Closed mostra
que o Player esta fechado e, por fim, Started e o estado de um Player que ja foi iniciado.
Alem dos estados e dos metodos para se trocar entre eles, a classe Player tem tambem
metodos para descobrir a duraca o da mdia a ela atribuda, fixar um numero de repetico es para
a mdia e descobrir o estado atual, entre outros (getDuration, setLoopCount e getState, respectivamente).
A Mobile Media API tambem possui o Control, cujos objetos podem ser utilizados para
controlar algumas funco es das mdias. Por exemplo, o Player suporta um VolumeControl, que
pode ser utilizado para controlar o volume do audio desse Player. Existe tambem o ToneControl,
que e responsavel por manipular sequencias de tons monotonicos, uma outra forma de produzir
sons para a sua aplicaca o.
A classe Manager ainda possui o metodo playTone, que e uma maneira bem mais simples de
se colocar sons no seu jogo. Este metodo recebe como parametros a nota, a duraca o e o volume,
e produz um tom monotonico como resultado. Este tipo de som pode ser u til em diversos tipos
de jogos ou aplicaco es, que nao necessitam de algo mais complexo do que pequenos tons para
os efeitos sonoros. Ha apenas o risco de esse tipo de soluca o ocupar muitos recursos da CPU,

25

que acontece apenas em casos de dispositivos que nao possuem suporte para geraca o de tons.

26

Estudo de Caso - Liga Quatro

7.1

Introduca o

Nesta seca o vamos falar um pouco sobre o jogo que nos escolhemos para implementar na
plataforma Java ME, o Liga Quatro.
O jogo, tambem conhecido em ingles como Four in a Row, Four in a Line, ou pelo nome
registrado Connect 4, e um jogo simples de tabuleiro para dois jogadores, que jogam em turnos
alternados colocando suas fichas em colunas com o objetivo de ser o primeiro a conectar quatro
fichas, seja na vertical, na horizontal ou em qualquer diagonal. Cada jogador escolhe uma
coluna por turno e sua ficha e depositada no primeiro espaco livre daquela coluna.
Este jogo foi escolhido por dois motivos principais: a possibilidade de se comparar a
implementaca o do jogo em Java ME e Java SE, ampliando o aprendizado da tecnologia em
estudo, e a interface simples.
A possibilidade de comparaca o de implementaco es se deu porque os bolsistas envolvidos
ja estavam desenvolvendo o jogo em Java SE para a disciplina de Estruturas de Dados. Essa
comparaca o permitiu uma analise detalhada das diferenca entre as duas tecnologias e as dificuldades de se portar o codigo para uma plataforma movel.
Uma das maiores dificuldades foi modificar alguns trechos para se adaptar a` baixa capacidade de processamento e de memoria dos dispositivos moveis.

7.2
7.2.1

Estrutura do codigo
Commands

Aqui estao declarados os atributos da classe MidletL4 do tipo Command. O construtor do

Command recebe como primeiro parametro o texto que sera mostrado ao usuario para representar o comando. Outro parametro e o tipo de comando, que pertence a um Enum (BACK, EXIT,

27

HELP, OK, CANCEL, SCREEN, STOP, ITEM). O terceiro parametro corresponde a` prioridade
do comando com relaca o aos outros comandos da mesma tela, sendo o menor numero a maior
prioridade. Neste caso, como todos tem a mesma prioridade, os comandos irao aparecer na
ordem em que sao adicionados. Com prioridades diferentes, os comandos ficam listados por
ordem de maior prioridade para menor, para facilitar o acesso do usuario aos comandos mais
importantes.
private Command botaoIrParaMenu = new Command("Voltar", Command.BACK, 0);
private Command botaoOK = new Command("OK", Command.OK, 0);
private Command botaoSairDoJogo = new Command("Sair", Command.EXIT, 0);

A nossa classe MidletL4 implementa a interface CommandListener e precisamos implementar o metodo commandAction. Assim, ele recebe um comando e a tela (Displayable) em que
o comando foi executado. No codigo demonstrado, fazemos comparaco es para saber em qual
tela o jogo se encontra atualmente. Ha algumas telas em que so existe uma aca o possvel, como
por exemplo as telas de Splash. Desse modo, nao e preciso saber qual comando foi executado,
ja que obrigatoriamente deveremos passar para a tela seguinte.

Sempre que o comando botaoSairDoJogo for executado, a aca o e fechar o aplicativo, nao
importando em qual tela o jogo se encontra atualmente.

Ja com o comando botaoIrParaMenu, podemos notar que existe uma condica o que verifica
se o usuario esta no meio do jogo. Caso isso seja verdade, o jogo fica pausado e a tela de menu
recebe um novo botao Continuar Jogo.
/**
* Recebe os eventos que ocorreram, e a tela em qual ocorreu e
* realiza a a
ca
~o correspondente.
*
* @param comando
*

O evento recebido.

* @param tela
*

A tela na qual o evento ocorreu.

28

*/
public void commandAction(Command comando, Displayable tela) {
if (tela == telaSplashL4) {
trocarTela(getTelaSplashPET());
} else if (tela == telaSplashPET) {
trocarTela(getTelaMenu());
}
if (tela == telaOpcoes) {
setarOpcoes();
trocarTela(getTelaMenu());
} else if (comando == botaoSairDoJogo) {
fecharMIDlet();
} else if (tela == telaVitoria || tela == telaDerrota
|| tela == telaEmpate) {
trocarTela(telaMenu);
} else if (comando == botaoIrParaMenu) {
if (Controlador.getInstance().jogoNaoAcabou()
&& tela == telaJogo) {
pausado = true;
telaMenu.insert(0, getBotaoDeContinuarJogo());
}
trocarTela(telaMenu);
}
}

As trocas de tela sao feitas utilizando o metodo abaixo:

/**
* Troca a tela atualmente exibida no celular.
*
* @param proximaTela

29

Tela a ser exibida.

*/
public void trocarTela(Displayable proximaTela) {
display = getDisplay();
display.setCurrent(proximaTela);
}

7.2.2

Eventos do menu principal

Os comandos executados na tela principal do jogo sao tratados de forma um pouco diferente.
Os comandos foram associados a` botoes da telaMenu. Assim, toda vez que um botao e pressionado, emitindo um evento, o comando e disparado e tratado por um ItemCommandListener.
/**
* Cria um Listener para comandos nos itens do menu principal do jogo.
*/
private ItemCommandListener listenerDeItens = new ItemCommandListener() {
public void commandAction(Command comando, Item item) {
if (item == botaoDeNovoJogo) {
Controlador.getInstance().resetar();
comecarNovoJogo();
if (pausado == true) {
pausado = false;
telaMenu.delete(0); //Remove a opcao de continuar o jogo
}
} else if (item == botaoDeContinuarJogo) {
trocarTela(telaJogo);
pausado = false;
telaMenu.delete(0);
} else if (item == botaoDeOpcoes) {

30

trocarTela(getTelaOpcoes());
} else if (item == botaoDeAjuda) {
trocarTela(getTelaAjuda());
} else if (item == botaoDeSobre) {
trocarTela(getTelaSobre());
} else if (item == botaoDeSair) {
fecharMIDlet();
}
}
};

Como cada Item (botao) possui somente um comando, o metodo so precisa avaliar qual foi
o item pressionado.

Abaixo, temos um exemplo de associaca o de um comando a um botao. Em seguida, associamos ao botao o ItemCommandListener mostrado no codigo acima.
botaoDeNovoJogo.addCommand(botaoOK);
botaoDeNovoJogo.setItemCommandListener(listenerDeItens);

7.2.3

A classe TelaDoJogo

A classe TelaDoJogo estende GameCanvas e e responsavel pela tela principal do jogo,

incluindo detecca o das teclas pressionadas, atualizaca o do que e mostrado na tela e efeitos
sonoros.

O metodo abaixo e responsavel pela atualizaca o da tela. Os parametros recebidos servem

para delimitar a regiao que sera redesenhada na tela, para questoes de minimizaca o de esforco
em certos momentos da execuca o do programa. O metodo flushGraphics chamado e o que
atualiza na tela aquilo que estava no buffer dentro de a rea desejada.

31

/**
* Atualiza uma parte da tela do jogo.
* @param x
*

Posi
c~
ao horizontal em pixels onde come
ca a a
rea a ser atualizada.

* @param y
*

Posi
c~
ao vertical em pixels onde come
ca a a
rea a ser atualizada.

* @param largura
*

Largura em pixels da a
rea a ser atualizada.

* @param altura
*

Altura em pixels da a
rea a ser atualizada.

*/
public void refresh(int x, int y, int largura, int altura) {
layer.paint(g, 0, 0);
flushGraphics(x, y, largura, altura);
}

Para a detecca o de estmulos do usuario, o metodo keyPressed e definido recebendo o

codigo da tecla pressionada como parametro. O que fazemos e detectar se o que foi passado
corresponde a` s teclas 4, 6 ou 5, que movimentam a ficha do jogador para esquerda, para a direita
ou confirma a jogada, respectivamente. Ha outro trecho condicional que verifica se o codigo da
tecla pressionada corresponde a` algum gameAction.

O gameAction e um mapeamento das teclas especiais de movimentaca o um aparelho celular

especfico para jogos. Assim, com os dois tipos de verificaca o de teclas apresentados abaixo, e
possvel utilizar tanto as teclas numericas quanto as direcionais para se jogar.
/**
* Detecta as teclas que s~
ao pressionadas durante o jogo.
* @param keyCode
*

C
odigo da tecla pressionada.

*/
public void keyPressed(int keyCode) {
switch (keyCode) {
case KEY_NUM4:

32

controle.clicouParaEsquerda();
return;
case KEY_NUM6:
controle.clicouParaDireita();
return;
case KEY_NUM5:
controle.clicouPraBaixo();
controle.animando = true;
return;
}
switch (getGameAction(keyCode)) {
case LEFT:
controle.clicouParaEsquerda();
return;
case RIGHT:
controle.clicouParaDireita();
return;
case DOWN:
controle.clicouPraBaixo();
controle.animando = true;
return;
case FIRE:
controle.clicouPraBaixo();
controle.animando = true;
return;
}
}

Para fazer a tela do jogo, sao utilizadas varias camadas. Cada camada adicionada e posicionada num array, e a camada mais proxima do usuario e a situada na primeira posica o, e a da
u ltima posica o e a que fica ao fundo de todas. Desse modo, o metodo append insere a camada
adicionada no final do array e portanto mais ao fundo. Demonstrando o sistema de camadas
da classe GameCanvas, no metodo abaixo adicionamos primeiramente a grade transparente do

33

tabuleiro, que e na verdade a camada que fica acima de todas na tela, em seguida as duas bolas
usadas para a animaca o das jogadas e por u ltimo o fundo com o tabuleiro totalmente pintado.
Assim, as bolas ficam na frente do fundo e por tras das grades, o que cria o efeito das bolas
deslizando para dentro do tabuleiro.
/**
* Junta as camadas com imagens do fundo, sprites e grade
* transparente do tabuleiro da tela do jogo.
*/
private void juntarCamadasDeImagens() {
layer.append(tabuleiro.getTabuleiroTransparente());
layer.append(bolaDeEscolha.getSprite());
layer.append(bolaAuxiliarDeAnimacao.getSprite());
layer.append(tabuleiro.getFundoDoTabuleiro());
flushGraphics();
}

7.2.4

A classe Bola

Os objetos da classe Bola possuem os sprites das fichas utilizadas no jogo, assim como
metodos para operar sobre esses sprites.

Este campo e o proprio sprite, que vai ser utilizado nos metodos da classe.
private Sprite bola;

Segue abaixo a sequencia que representa a ordem dos frames do sprite e serve para definir
a animaca o da bola. Os numeros dos frames sao definidos durante a criaca o do sprite. Neste
caso, ao executar a sequencia (com o metodo bola.nextFrame()), a bola parece estar caindo.
private int[] sequenciaDeSaida = {0, 1, 2, 4};
bola.setFrameSequence(sequenciaDeSaida);

34

Para criar o sprite, passamos como parametro a imagem contendo os frames desejados, e
tambem a dimensao do sprite (neste caso, a altura e a largura sao iguais).
bola = new Sprite(imagemDaAmarela, diametro, diametro);

Abaixo temos o metodo responsavel por mover a bola para a direita. O metodo inicia tomando a posica o atual da bola. A seguir, o sprite e atualizado para o u ltimo frame da sequencia
do sprite, que representa uma imagem vazia. Essa imagem e pintada na tela com o metodo
refresh da classe TelaDoJogo. Isso faz com que a bola suma na tela do usuario.
Logo apos, o sprite e movido uma casa para a direita e o sprite e atualizado para o primeiro
frame da sequencia, que contem a bola cheia. Essa bola e pintada novamente na tela com o
mesmo metodo, fazendo com que ela reapareca.
Por questoes de otimizaca o, o metodo refresh() pinta apenas a a rea em que a bola esta se
movimentando, para nao pintar desnecessariamente as regioes em que nao ha modificaca o na
tela.
/**
* Move a bola para uma casa para a direita.
*/
public void moverParaDireita() {
int x = bola.getX();
int y = bola.getY();
bola.setFrame(3);
TelaDoJogo.getInstance().refresh(x, y, diametro, diametro);
bola.move(diametro, 0);
bola.setFrame(0);
TelaDoJogo.getInstance().refresh(x + diametro, y, diametro,
diametro);
}

Este metodo simples move o sprite x pixels no eixo x e y no eixo y.

35

public void mover(int x, int y) {

bola.move(x, y);
}

7.2.5

PlayTone

Para a utilizaca o de sons no jogo, optamos pelo uso do metodo playTone. Este metodo
pertence a` classe Manager do Java ME e e responsavel por produzir um tom, dado sua duraca o
e a nota. Os sons presentes no Liga Quatro sao produzidos apos cada jogada e ao mostrar a tela
de vitoria, derrota ou empate. Um exemplo pode ser conferido abaixo:
/**
* Toca o efeito sonoro da bola amarela.
*/
public void tocarEfeitoBolaAmarela() {
try {
Manager.playTone(79, 100, 100);
Thread.sleep(100);
Manager.playTone(77, 100, 100);
} catch (InterruptedException ex) {
ex.printStackTrace();
} catch (MediaException ex) {
ex.printStackTrace();
}
}

O metodo playTone recebe como primeiro parametro a nota, que deve ser um numero entre
0 e 127 e e calculada atraves de uma formula encontrada em http://java.sun.com/javame/
reference/apis/jsr118/. Como segundo parametro, e passada a duraca o da nota em milissegundos. O terceiro parametro do metodo corresponde ao volume do tom, que deve ser entre 0
e 100. Assim, produzimos dois tons para o efeito sonoro da bola amarela, com uma pausa entre
eles. O Thread.sleep e utilizado para que os tons produzidos nao se sobreponham durante sua
execuca o.

36

Bibliografia

CLDC 1.1 http://java.sun.com/javame/reference/apis/jsr139/

MIPD 2.0 http://java.sun.com/javame/reference/apis/jsr118/
IDE Netbeans http://www.netbeans.org/
Sun http://www.sun.com/
Wikipedia http://en.wikipedia.org/wiki/Java_Community_Process
Asked Questions List http://bellsouthpwp.net/m/c/mcpierce/javamefaq.html