Desenvolvendo Jogos Com Java ME

download Desenvolvendo Jogos Com Java ME

of 37

Transcript of Desenvolvendo Jogos Com Java ME

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 Computacao

U NIVERSIDADE F EDERAL DE S ANTA C ATARINA C ENTRO T ECNOL OGICO D EPARTAMENTO DE I NFORM ATICA E E STATSTICA I P ROGRAMA DE E DUCAC AO T UTORIAL

Licenca: Atribuicao-Uso N o-Comercial-Compartilhamento pela mesma Licenca 2.5 Brasil a

Para cada novo uso ou distribuicao, voc deve deixar claro para outros os e termos da licenca desta obra. Qualquer uma destas condicoes podem ser renunciadas, desde que Voc obte e nha permiss o do autor. a Nada nesta licenca prejudica ou restringe os direitos morais dos autores.

Sum rio a

1

Introducao 1.1 1.2 1.3 1.4 1.5 A plataforma Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Java Card . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Java Micro Edition (ME) . . . . . . . . . . . . . . . . . . . . . . . . . . . . Java Standard Edition (SE) . . . . . . . . . . . . . . . . . . . . . . . . . . . Java Enterprise Edition (EE) . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 5 p. 5 p. 5 p. 6 p. 6 p. 6 p. 7 p. 7 p. 7 p. 7 p. 8 p. 9 p. 11 p. 12 p. 12 p. 12 p. 12 p. 13 p. 14 p. 14

2

Java ME 2.1 O que e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 2.1.2 2.2 2.3 2.4 Aplicacoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Vantagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Principais diferencas entre Java SE e Java ME . . . . . . . . . . . . . . . . . Conguracoes e pers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . JCP e JSRs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

Ferramentas de desenvolvimento 3.1 3.2 Sun Wireless Toolkit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IDEs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 3.2.2 NetBeans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

Bibliotecas Java ME 4.1 Java SE x Java ME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.2 5

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

p. 14 p. 16 p. 16 p. 16 p. 17 p. 18 p. 18 p. 19 p. 20 p. 20 p. 21 p. 21 p. 22 p. 23 p. 26 p. 26 p. 26 p. 26 p. 29 p. 30 p. 33 p. 35 p. 36

Desenvolvendo para Dispositivos M veis o 5.1 5.2 5.3 Uso de mem ria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o Resolucao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conguracoes e pers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

Desenvolvendo Jogos 6.1 6.2 6.3 6.4 6.5 A classe MIDLet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Displays e Displayables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Canvas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sprites e Tiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.5.1 6.5.2 6.6 Sprites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TiledLayer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

7

Estudo de Caso - Liga Quatro 7.1 7.2 Introducao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Estrutura do c digo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 7.2.1 7.2.2 7.2.3 7.2.4 7.2.5 Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Eventos do menu principal . . . . . . . . . . . . . . . . . . . . . . . A classe TelaDoJogo . . . . . . . . . . . . . . . . . . . . . . . . . . A classe Bola . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PlayTone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

Bibliograa

5

1

Introducao

1.1

A plataforma Java

Java e uma tecnologia que se estende muito al m da pr pria linguagem de programacao. e o Trata-se, na verdade, de uma plataforma de desenvolvimento. A plataforma Java compreende um conjunto de softwares e especicacoes da Sun Microsys tems para o desenvolvimento de aplicativos. A grande vantagem desta plataforma e a sua compatibilidade n o apenas entre sistemas operacionais, mas tamb m entre diversas arquiteturas, a e variando de PDAs e set-top boxes at servidores. As aplicacoes desenvolvidas nesta plataforma e tamb m s o diversas, variando de aplicativos embarcados a jogos e aplicativos web. e a Devido a essa grande variedade a plataforma e dividida em quatro diferentes edicoes. Cada edicao e composta de um pacote de softwares que permitem o desenvolvimento e a execucao de programas escritos na linguagem Java. As plataformas s o desenhadas n o para um processador especco, mas para uma Java Vira a tual Machine (JVM) e um compilador com um conjunto de bibliotecas. A principal vantagem do uso da m quina virtual e aumentar a portabilidade do c digo. a o

1.2

Java Card

Java Card e a edicao mais limitada da plataforma Java e e destinada a smart cards ou dispo sitivos similares com pouqussima mem ria. Seu principal foco e a seguranca, com suporte ao o encapsulamento de dados no aplicativo, rewall entre aplicativos e criptograa. Atualmente, encontra-se em desenvolvimento a vers o 3 da plataforma. a

6

1.3

Java Micro Edition (ME)

Voltada para dispositivos com pouca capacidade de processsamento e mem ria limitada, o principalmente dispositivos m veis. Muito usada em celulares e PDAs, estende-se tamb m o e para aparelhos como set-top boxes e Blu-ray players. Apresenta algumas diculdades no desenvolvimento devido a grande variedade de dispositivos e suas especicidades. A plataforma Java ME e detalhada no pr ximo captulo. o

1.4

Java Standard Edition (SE)

E a edicao usada para o desenvolvimento de aplicacoes port veis de prop sito geral. Cont m a o e o que necess rio para o desenvolvimento de aplicacoes desktop e applets, como pacotes de ina terface gr ca, entrada e sada, comunicacao com bancos de dados, etc. a Atualmente, encontra-se na vers o 6. a

1.5

Java Enterprise Edition (EE)

Java EE e a maior das edicoes de Java, compreendendo tudo o que est presente na Standard a Edition al m de coisas mais especcas, como o servidor de aplicacoes GlassFish. Voltada e para aplicacoes que rodam no lado do servidor e pensada para tornar as aplicoes robustas, seguras, escal veis e port veis. E usada para o desenvolvimento de aplicacoes web e baseadas a a na arquitetura orientada a servicos (SOA), como web services. Atualmente, encontra-se na vers o 5. a

7

2

Java ME

2.1

O que e

Java ME e uma das edicoes da plataforma Java e, como tal, e composta pela pr pria lingua o gem, por uma M quina Virtual e por uma colecao de APIs. a A linguagem e a mesma usada nas outras edicoes, portanto e familiar para qualquer pessoa que j tenha programado Java em qualquer plataforma. Para se entender Java ME, ent o, e a a necess rio conhecer a M quina Virtual e a colecao de APIs. a a Java ME aceita diferentes implementacoes de m quinas virtuais e normalmente a m quina a a virtual e denida pela Conguracao. Al m desses elementos comuns, esta edicao da plataforma Java apresenta alguns elementos e especcos como Proles e Conguracoes, que ser o estudados adiante. a

2.1.1

Aplicacoes

E usado principalmente para o desenvolvimento em sistemas m veis e embarcados, alguns o exemplos de sistemas que adotam Java ME s o: a Celulares; PDAs; Set-top boxes; Blu-ray players.

2.1.2

Vantagens

Por ter um campo de aplicacao bem especicado, Java ME apresenta diversas facilidades para os desenvolvedores, tais como:

8

Portabilidade: Um aplicativo criado utilizando Java ME pode ser portado para diversos apare lhos, desde que sigam as mesmas especicacoes. Isso e muito importante no desenvolvi mento para celulares, pois um mesmo aplicativo desenvolvido poder rodar em modelos a de diferentes fabricantes. Boa compatibilidade entre aparelhos: Como j foi citado acima, desde que sigam as mesmas a especicacoes, n o h grandes problemas de compatibilidade entre os aparelhos que ir o a a a rodar um aplicativo. Constante desenvolvimento: Assim como todo o resto da tecnologia Java, Java ME se encontra em constante desenvolvimento, com novas funcoes e capacidades sendo adicionadas a todo momento. Esse processo de desenvolvimento segue a JCP (Java Community Process), que ser detalhado mais a frente. a Boa documentacao: A plataforma conta com uma vasta documentacao online, no pr prio site o da Sun, al m de in meros outros exemplos e tutoriais que podem ser encontrados em sites e u e f runs. o 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 s o descritas a seguir: a M quina Virtual: As m quinas virtuais utilizadas em Java ME s o desenhadas para serem a a a mais compactas e ecientes que a m quina virtual utilizada em Java SE, por isso alguns a recursos s o perdidos. a Numeros de ponto utuante: O suporte a ponto utuante s foi adicionado na vers o 1.1 do o a CLDC, por isso ao desenvolver aplicacoes para dispositivos mais antigos e possvel que o desenvolvedor n o encontre suporte para esta representacao num rica. a e Reex o: O pacote java.lang.reect s est presente no CDC. Por isso n o e possvel utilizar a o a a reex o em dispositivos de menor capacidade. a APIs de alto nvel (Swing e AWT): Algumas APIs de mais alto nvel, como as utilizadas para interface gr ca n o est o presentes em Java ME. a a a

9

Acesso ao sistema de arquivos: Para se ter acesso ao sistema de arquivos e necess rio utilizar a o PDA Prole, ou uma implementacao especca de um fabricante. Grupos de threads: O suporte a grupos de threads, threads que podem ser manipuladas em conjunto, tamb m s e provido pelo CDC. e o A gura abaixo mostra uma vis o geral dos componentes de Java ME e como eles se relaa cionam as outras tecnologias Java:

2.3

Conguracoes e pers

As conguracoes (Congurations) e pers (Proles) representam as conguracoes e APIs mnimas disponveis em um dispositivo m vel. o Cada aplicativo desenvolvido necessita de uma conguracao mnima para ser rodado, e a garantia de que o dispositivo alvo ter essa conguracao e fornecida pelo sistema de Congua rations e Proles. As principais Congurations s o o CDC e o CLDC e o principal Prole e o MIDP, que s o a a explicados a seguir. O MIDP e a denicao de uma arquitetura, e dene v rias APIs que devem estar disponveis a 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 introducao de uma API para jogos,

10

que facilita muito a criacao deste tipo de aplicativo. A maioria dos aplicativos desenvolvidos para dispositivos m veis s o capazes de rodar em plataformas MIDP 1.0, que devem ter as o a seguintes caractersticas, entre outras: Tamanho da tela mnimo de 96x54pixels. Input atrav s de One handed keyboard ou Two handed keyboard ou Touch Screen. e 128Kbytes de mem ria para os componentes MIDP. o 8Kbytes de mem ria para dados das aplicacoes. o 32Kbytes de mem ria din mica. o a O MIDP 1.0 e baseado em aparelhos que seguem a conguracao CLDC, ou seja, os apare lhos compatveis com MIDP tamb m o ser o com CLDC. e a Dispositivos CLDC (Connected Limited Device Conguration) s o os aparelhos mais sima ples, que possuem uma interface menor e pouca mem ria e velocidade de processamento. Deo vem ter no mnimo as seguintes caractersticas: 128Kb de mem ria para rodar a m quina virtual. o a 32Kb de mem ria din mica. o a Comunicacao em rede com baixa largura de banda. Baixa pot ncia (para diminuir o gasto de energia). e Dispositivos CDC (Connected Device Conguration) s o aparelhos mais potentes que os a CLDC e devem ter pelo menos as seguintes caractersticas: 512Kb de mem ria para executar a m quina virtual. o a 256Kb de mem ria din mica. o a Capacidade para comunicacao em rede com alta largura de banda. ` Suporte a persist ncia. e

11

2.4

JCP e JSRs

O Java Community Process (JCP) e um processo formalizado para que v rias partes intea ressadas colaborem no desenvolvimento de especicacoes e futuras vers es da plataforma Java. o Entre os membros da JCP podemos encontrar operadoras de telefonia como a NTT DoCoMo, desenvolvedores de dispositivos m veis como a Nokia, a Sony Ericsson e a Motorola, o outras empresas e at mesmo pessoas fsicas. e Os documentos descrevendo as especicacoes e tecnologias propostas s o chamados Java a Specication Request (JSR). Esses documentos s o publicamente revisados at que um JSR se torne nal e seja votado a e pelo Comit Executivo da JCP. e Um JSR nal prov uma implementacao de refer ncia, na forma de c digo fonte e um e e o Technology Compatibility Kit para vericar a especicacao da API. O pr prio JCP e descrito por um JSR, o JSR 215 de 2006. o Os JSRs s o especialmente importantes em Java ME, por causa do n mero de recursos a u novos e da velocidade com que mudam em dispositivos m veis. o Alguns exemplos de JSRs em Java ME: JSR 30: J2ME CLDC 1.0 JSR 37: MIDP 1.1 JSR 68: J2ME Platform Specication JSR 82: Bluetooth JSR 118: MIDP 2.0 JSR 133: Java Game Prole JSR 139: CLDC 1.1 JSR 184: Mobile 3D Graphics API for J2ME

12

3

Ferramentas de desenvolvimento

3.1

Sun Wireless Toolkit

O Wireless Toolkit, ou WTK, e uma ferramenta de auxlio ao desenvolvimento de aplicacoes em Java ME (CLDC e MIDP). O WTK possui exemplos, documentacao, funcoes de otimizacao e um emulador para dispositivos m veis. o H algumas IDEs (Integrated Development Enviroment, ou ambiente de desenvolvimento) a que j v m com o Sun Wireless ToolKit integrado, outras possuem plugins para integracao e a e tamb m e possvel usar apenas o WTK para desenvolver suas aplicacoes. e

3.2

IDEs

Duas IDEs j bem conhecidas para desenvolvimento em Java (e tamb m em outras linguaa e gens de programacao) s o o Eclipse e o NetBeans. Ambos os ambientes suportam o desenvol a vimento em Java ME e ser o descritos com um pouco mais de caractersticas a seguir. a

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 propriet rio, mas ap s esse perodo o c digo foi aberto e a o o 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 extens o da IDE a para desenvolvimento com Java ME. O NetBeans Mobility Pack j vem integrado com o emulador da Sun (WTK), al m de sua e portar outros emuladores. Essa extens o tamb m tem algumas ferramentas que auxiliam no a e desenvolvimento para dispositivos m veis, como algumas classes que podem ser utilizadas nas o

13

suas aplicacoes fora as padr es da biblioteca Java ME. Um exemplo disso e a SplashScreen, o que estende a classe Canvas do Java ME e pode ser bem util para as aplicacoes desenvolvidas. O Mobility Pack tamb m possui o Game Builder, que auxilia o desenvolvimento de jogos. e Atrav s dessa ferramenta, ca mais f cil criar Sprites e Tiles para seu jogo, e o Game Builder e a tamb m permite a construcao de cenas (combinacoes de objetos est ticos e din micos) de uma e a a maneira mais simples e r pida, ajudando na criacao do seu jogo. a Al m de todas as vantagens do ambiente para o desenvolvimento de aplicacoes com Jae vaME, e um ambiente gratuito e com boa documentacao, al m de um forte apoio da comuni e dade.

3.2.2

Eclipse

Existem plugins para a IDE Eclipse para desenvolvimento com Java ME. A grande van tagem de se desenvolver com esse ambiente s o todas as facilidades do Eclipse, que e bem a poderoso e vers til para geracao de software em Java. a Um dos plugins existentes para desenvolvimento com JavaME no ambiente Eclipse e o cha mado EclipseME. Este plugin e um pouco antigo e s funciona com algumas vers es tamb m o o e antigas da IDE. Por m, existem diversos outros plugins que podem ser utilizados para desene volvimento de aplicacoes para a plataforma ME do Java. Esses plugins podem ser encontrados na pr pria p gina da IDE Eclipse, na secao de plugins, mas v rios deles s o pagos. o a a a

14

4

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 m quina virtual e algumas APIs mais limitadas. As APIs presentes no Java ME s o dea a nidas no JCP (Java Community Process). A limitacao de mem ria dos dispositivos que rodam o 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. Por m, o Java Micro e Edition n o possui apenas uma especicacao. Dependendo da conguracao e perl escolhidos, a voc pode utilizar diferentes APIs para desenvolver sua aplicacao. Com a evolucao do poder de e processamento e capacidade de mem ria dos dispositivos, surgem novas funcionalidades mais o complexas atrav s dos JSRs. Como exemplo disso, podemos citar a aus ncia de vari veis do e e a tipo ponto utuante (como o double) em vers es mais antigas de conguracoes e pers do Java o ` ME. Devido a essa diferenca entre as duas edicoes, nem toda aplicacao desenvolvida em Java SE funcionar num dispositivo que roda Java ME. a

4.2

Bibliotecas disponveis

Como dito anteriormente, as APIs disponveis para desenvolver a sua aplicacao resultam da combinacao de conguracao e perl adotados pelo programador. Utilizando como exemplo a vers o 1.1 do CLDC (Connected Limited Device Conguration), os pacotes presentes para o a desenvolvimento da sua aplicacao s o: a 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 relacao a ` interface das aplicacoes. O SWT e Swing da edicao padr o de Java n o se encontram na vers o a a a ME. A Micro Edition conta com um novo pacote para este m, chamado java.microedition.lcdui, que pode ser encontrado em qualquer vers o do MIDP. A vers o 2.0 do MIDP cont m os sea a e guintes 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 s rie de pacotes exclusivos do JavaME (os iniciados com e javax.microedition). Assim, com a presenca de alguns pacotes exclusivos, tamb m pode-se e armar que nem toda aplicacao escrita em Java ME funcionar na plataforma Java SE. a

16

5

Desenvolvendo para Dispositivos M veis o

5.1

Uso de mem ria o

Os dispositivos para os quais se desenvolve em Java ME, em geral, possuem pouca mem ria, o sendo isso um fator de risco para o desenvolvimento de aplicacoes desse tipo, juntamente com a capacidade de processamento. Para evitar isso, deve-se ter um cuidado maior para essa classe de software. A utilizacao de estruturas de dados e tipos de dados mais simples e um bom comeco para reduzir o uso de mem ria. Outra sada e reduzir o n mero de objetos criados, ou reduzir o o u tamanho dos objetos que s o utilizados na aplicacao. As imagens utilizadas tamb m s o uma a e a grande fonte de Out of Memory Error, a excecao que ocorre ao se utilizar mem ria em excesso. o Se mesmo com esses cuidados ainda existem problemas com mem ria, voc pode usar um o e proler para auxiliar a encontrar usos desnecess rios ou inecientes de mem ria. Um Proler a o e uma ferramenta que ajuda a encontrar bottlenecks da sua aplicacao, achando memory leaks e rastreando a vida dos objetos. Com essas informacoes, e mais f cil encontrar problemas na a implementacao que ocasionam os erros de uso de mem ria da sua aplicacao. o

5.2

Resolucao

Os diferentes dispositivos que suportam aplicacoes em Java ME possuem resolucoes de tela diferentes. Assim, na hora de desenvolver esse tipo de software, e preciso ter em mente alguma resolucao um pouco mais especca para a qual ser desenvolvida a aplicacao. E muito mais a f cil desenvolver para uma resolucao especca do que tentar fazer um software mais geral que a rode em v rias resolucoes diferentes. a Normalmente s o lancadas algumas vers es do software, cada uma para uma resolucao dia o

17

ferente. Isso tamb m ajuda na quest o de capacidade do dispositivo. Geralmente dispositivos e a com uma mesma resolucao da tela possuem uma capacidade de processamento e mem ria pa o recidos, facilitando com que uma aplicacao funcione em uma quantidade maior de aparelhos m veis ao ser desenvolvida especicamente para um conjunto de dispositivos similares. o

5.3

Conguracoes e pers

A escolha da conguracao e sua vers o, assim como a vers o do perl adotado pelo pro a a gramador, dever levar em conta o dispositivo para o qual se est desenvolvendo a aplicacao, a a assim como as funcionalidades da aplicacao sendo desenvolvida. Essa escolha acaba denindo em que tipos de dispositivos a sua aplicacao ir rodar. Por esse motivo, e fundamental que se a verique as conguracoes e pers suportados pelo dispositivo de destino da sua aplicacao.

18

6

Desenvolvendo Jogos

6.1

A classe MIDLet

` A classe MIDlet corresponde as aplicacoes do MIDP, e deve ser estendida para que o software que gerencia as aplicacoes do dispositivo consiga controlar e modicar o estado das aplicacoes (rodando ou pausada, por exemplo). A classe principal de sua aplicacoes deve es tender a esta classe e implementar os m todos utilizados para criar, comecar, pausar e destruir e a aplicacao. A MIDLet funciona como uma interface entre o gerenciador de aplicacoes e a sua aplicacao. Essa comunicacao funciona atrav s de sinais enviados entre o software gerenciador e do dispositivo e a aplicacao. Para comecar a sua aplicacao, a classe MIDlet possui o m todo startApp, que faz com que e o estado atual se torne Active, enviando um sinal para o software gerenciador de aplicacoes. Caso alguma excecao ocorra durante a execucao desse m todo, a aplicacao e destruda auto e maticamente e o m todo destroyApp e chamado. A aplicacao tamb m pode ser pausada com o e e pauseApp, entrando no estado Paused. Nesse estado, o MIDlet deve liberar todos os recursos alocados. Al m dos m todos que enviam um sinal ao MIDlet para a mudanca de estado, h tamb m e e a e m todos da classe que enviam um sinal ao gerenciador de aplicacoes para informar da mudanca e de estado da sua aplicacao, como o notifyDestroyed e notifyPaused. Ao utilizar o notifyDes troyed, por exemplo, o software gerenciador n o ir chamar o destroyApp, mas o pr prio MIa a o Dlet deve ter realizado as mesmas operacoes que o m todo de destruicao, como a liberacao de e recursos. Atrav s da combinacao desses m todos da classe MIDlet monta-se o ciclo de vida de sua e e aplicacao. E importante manter correta a comunicacao entre a aplicacao e o software gerenci ` ador de aplicacoes, estando sempre atento a quest o de liberacao de recursos e troca de sinais a para mudanca de estado.

19

6.2

Commands

Os commands do Java ME s o usados para gerar e tratar eventos. Por exemplo, um comando a pode ser associado a um bot o, ou imagem, de modo que, quando este for selecionado, ou a clicado, o evento ser disparado. a Um command guarda a informacao sem ntica de uma acao, como pode ser visto pelos tipos a de comandos existentes, mostrados mais abaixo. Desse modo, ele e respons vel apenas pelo siga nicado, e n o a acao propriamente dita. A acao ca como responsabilidade da implementacao a ` ` 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 co mando e commandType e o tipo do comando. H tamb m um outro construtor para objetos da a e classe Command, com a aus ncia do par metro longLabel. e a Os tipos possveis do commandType s o os seguintes: a OK ITEM SCREEN HELP BACK CANCEL EXIT STOP A prioridade de um comando s e importante se algum objeto disparar mais de um evento o de uma vez, neste caso, somente o comando de maior prioridade e avaliado. Estes comandos devem ent o ser tratados por uma classe que implementa a interface Coma mandListener. Nesta classe ser denido o m todo commandAction que vai decidir que acao a e deve ser tomada quando cada evento e disparado.

20

Exemplos de implementacoes de commands e CommandListeners podem ser encontrados no nal desta apostila, na secao 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 unico por MIDlet e e o respons vel por funcoes relacionadas a tela do dispoa sitivo. Para obter uma refer ncia ao Display, a aplicacao deve utilizar o m todo getDisplay. e e Atrav s dessa classe, e possvel chamar m todos para obter algumas informacoes importantes e e para a sua aplicacao, como o n mero de cores do aparelho, ou at mesmo se ele suporta cores. u e A classe Display tamb m possui m todos para controlar funcoes do dispositivo, como vibrar, e e atrav s do m todo vibrate, e um efeito de luz do aparelho, com o m todo ashBackLight. e e e Um objeto s possui a capacidade de ser inserido no Display ao estender a classe Diso playable. Por m, um Displayable apenas tem capacidade para ter comandos, listeners, ttulos e e tickers associados a ele. Tudo que e mostrado e a sua interacao com o usu rio e denida a atrav s de subclasse, como e o exemplo do Canvas. A utilizacao do Displayable e feita com e os m todos setCurrent e getCurrent da classe Display, que troca e retorna o objeto do tipo e Displayable atualmente na tela, respectivamente. Caso n o seja denido nas subclasses do Displayable, a conguracao inicial do seu objeto a ser : a N o visvel no Display; a Ttulo null; Nenhum ticker associado ao Displayable em quest o; a 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 aplicacao que precisam fazer alteracoes gr cas na tela, ou receber eventos de teclas pressionadas no a dispositivo. Em geral, os jogos utilizam muito essa classe, para poder interagir com o usu rio a tanto na recepcao de estmulos quanto na apresentacao dos resultados desses estmulos.

21

Esta classe e respons vel por tratar eventos de entrada, como teclas pressionadas, soltas a ou mantidas pressionadas (keyPressed, keyReleased e keyRepeated, respectivamente) e tamb m e eventos com um pointer de um PDA (similares aos de tecla). E possvel vericar qual das teclas foi pressionadas com o m todo getKeyCode, mas em Java ME existe um artifcio que e e recomendado para os desenvolvedores de jogos, que e o sistema de Game Actions. Os Game Actions s o denidos para aplicacoes port veis que utilizam as teclas de setas de a a um dispositivo e eventos relacionados a jogos. O MIDP prov os seguintes Game Actions: UP, e 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, por m cada tecla s pode estar associada a um e o Game Action. A aplicacao pode traduzir um Key Code para um Game Action atrav s do m todo e e getGameAction e fazer o oposto atrav s de getKeyCode. Apesar de v rios Key Codes poderem e a estar associados ao mesmo Game Action, apenas um deles e retornado com este m todo. e Outra funcao do Canvas e o controle gr co do que e exibido. Isso e feito atrav s do a e setFullScreenMode, que tanto coloca quanto tira do modo de exibicao em tela cheia, e o m todo e repaint, que renderiza o Canvas por completo ou apenas uma regi o dele, artcio muito util a para reduzir o tempo gasto com processamento para repintar uma area sem alteracoes.

6.5

Sprites e Tiles

Entre as bibliotecas do Java ME, existem as classes Sprite e TiledLayer, que s o utilizaa das para fazer os objetos animados e o fundo do seu jogo, respectivamente. Um Sprite, por sua denicao, e uma imagem ou animacao em duas ou tr s dimens es que ser utilizada para e o a representar um objeto, e muitas vezes s o usados para detectar colis es ou fazer algum tipo a o de interacao do jogo. J os Tiles s o usados para representar o fundo da tela, usualmente uma a a paisagem, um tabuleiro ou alguma cena de um jogo.

6.5.1

Sprites

Para a classe Sprite, um arquivo de imagem e dividido em v rios frames de tamanho igual, a e voc pode criar livremente uma sequ ncia dos frames para gerar sua animacao. Para animar e e sua sequ ncia, s o usados m todos como o nextFrame, setFrame e prevFrame. Com esta classe e a e do Java ME tamb m e possvel denir a area de colis o de um sprite, assim como vericar se e a houve colis o entre dois sprites, entre um sprite e um Tile ou at mesmo entre um sprite e uma a e imagem, utilizando m todos como deneCollisionRectangle e collidesWith. e

22

Os Sprites em Java ME s o produzidos a partir de uma unica imagem com todos os frames a que ser o utilizados para renderizar a animacao. E possvel fazer apenas um frame, mas nos a demais casos a imagem fonte e dividida igualmente em frames de uma determinada largura e altura. A sequ ncia da animacao e criada atrav s de uma Frame Sequence, que nada mais e do e e que um array com os ndices dos frames gerados. Um objeto do tipo Sprite pode ter um pixel de refer ncia. Esse pixel e denido por padr o e a como a posicao (0,0) do sprite, podendo ser redenida para qualquer outra posicao, at mesmo e fora dos limites do sprite. Esse pixel existe para permitir algumas operacoes que s o realiza a das baseadas em algum referencial, como transformacoes de rotacao e espelhamento do sprite. Segue abaixo um exemplo de sprite com um pixel de refer ncia inuenciando na rotacao. e

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 c lulas, onde cada e c lula e preenchida com uma imagem est tica chamada tile. Essa composicao de imagens e a menores permite economia de espaco, e e uma t cnica muito usada em diversos jogos de duas e dimens es. o Cada posicao na grade da TiledLayer recebe um indce, ao qual e associado um tile. Cada ` um desses tiles e considerado est tico e ca ligado a imagem que ele representa. Existe tamb m a e ` um animated tile, que e um tile virtual associado dinamicamente a um est tico. Com os tiles a animados, ao se utilizar o mesmo animated tile em diversas c lulas da grade, e possvel mud e a las ao mesmo tempo apenas modicando o tile est tico ao qual eles est o associados. a a A grade da TiledLayer possui um n mero de c lulas de mesmo tamanho distribudas por u e

23

linhas e colunas, denidas na criacao do objeto. As c lulas da grade n o podem receber mais e a de um tile por vez, mas v rias c lulas podem receber o mesmo tile. Para mudar o conte do de a e u uma das c lulas, podem ser utilizados os m todos setCell e llCells. e e

6.6

Sons

O JavaME possui uma API respons vel por funcionalidades multimdia, como gravacao de a audio e vdeo, al m dos controle de sons. A Mobile Media API, ou MMAPI, funciona basica e mente atrav s das classes Manager, Player e os controladores VolumeControl e ToneControl. e A classe Manager e utilizada para criar os Players. Isso pode ser feito atrav s do m todo e e createPlayer, onde voc passa como par metros um InputStream do arquivo de som que ser e a a tocado e o tipo (wave, midi, mp3, etc). Assim, voc obt m um Player para tocar o som/m sica e e u desejada e dever controlar esse novo objeto para obter o efeito desejado. Alguns exemplos de a formatos e as Strings que devem ser passados como par metro para o createPlayer: a 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 m todo start para que ele comece e pare ao chegar ao m da mdia especicada. e InputStream stream = getClass().getResourceAsStream(sound_file); Player p = Manager.createPlayer(stream, format); p.start(); O Player permite uma maior variedade de acoes, com a combinacao dos m todos da classe e e o seu sistema de estados. Os estados da classe Player s o: Unrealized, Realized, Started, a Closed e Prefetched. A imagem abaixo mostra como s o feitas as transicoes entre os estados a atrav s dos m todos mostrados nas echas presentes na gura. e e

24

O estado Unrealized indica que o Player n o possui nem informacoes nem recursos nea cess rios para funcionar. Realized indica que apenas os recursos n o foram adquiridos ainda. O a a estado Prefetched signica que todos os recursos j foram adquiridos. J o estado Closed mostra a a que o Player est fechado e, por m, Started e o estado de um Player que j foi iniciado. a a Al m dos estados e dos m todos para se trocar entre eles, a classe Player tem tamb m e e e m todos para descobrir a duracao da mdia a ela atribuda, xar um n mero de repeticoes para e u a mdia e descobrir o estado atual, entre outros (getDuration, setLoopCount e getState, respec tivamente). A Mobile Media API tamb m possui o Control, cujos objetos podem ser utilizados para e controlar algumas funcoes das mdias. Por exemplo, o Player suporta um VolumeControl, que pode ser utilizado para controlar o volume do a dio desse Player. Existe tamb m o ToneControl, u e que e respons vel por manipular sequ ncias de tons monot nicos, uma outra forma de produzir a e o sons para a sua aplicacao. A classe Manager ainda possui o m todo playTone, que e uma maneira bem mais simples de e se colocar sons no seu jogo. Este m todo recebe como par metros a nota, a duracao e o volume, e a e produz um tom monot nico como resultado. Este tipo de som pode ser util em diversos tipos o de jogos ou aplicacoes, que n o necessitam de algo mais complexo do que pequenos tons para a os efeitos sonoros. H apenas o risco de esse tipo de solucao ocupar muitos recursos da CPU, a

25

que acontece apenas em casos de dispositivos que n o possuem suporte para geracao de tons. a

26

7

Estudo de Caso - Liga Quatro

7.1

Introducao

Nesta secao vamos falar um pouco sobre o jogo que n s escolhemos para implementar na o plataforma Java ME, o Liga Quatro. O jogo, tamb m conhecido em ingl s como Four in a Row, Four in a Line, ou pelo nome e e registrado Connect 4, e um jogo simples de tabuleiro para dois jogadores, que jogam em turnos alternados colocando suas chas em colunas com o objetivo de ser o primeiro a conectar quatro chas, seja na vertical, na horizontal ou em qualquer diagonal. Cada jogador escolhe uma coluna por turno e sua cha e depositada no primeiro espaco livre daquela coluna. Este jogo foi escolhido por dois motivos principais: a possibilidade de se comparar a implementacao do jogo em Java ME e Java SE, ampliando o aprendizado da tecnologia em estudo, e a interface simples. A possibilidade de comparacao de implementacoes se deu porque os bolsistas envolvidos j estavam desenvolvendo o jogo em Java SE para a disciplina de Estruturas de Dados. Essa a comparacao permitiu uma an lise detalhada das diferenca entre as duas tecnologias e as dicul a dades de se portar o c digo para uma plataforma m vel. o o ` Uma das maiores diculdades foi modicar alguns trechos para se adaptar a baixa capacidade de processamento e de mem ria dos dispositivos m veis. o o

7.27.2.1

Estrutura do c digo oCommands

Aqui est o declarados os atributos da classe MidletL4 do tipo Command. O construtor do a Command recebe como primeiro par metro o texto que ser mostrado ao usu rio para represena a a tar o comando. Outro par metro e o tipo de comando, que pertence a um Enum (BACK, EXIT, a

27

` HELP, OK, CANCEL, SCREEN, STOP, ITEM). O terceiro par metro corresponde a prioridade a do comando com relacao aos outros comandos da mesma tela, sendo o menor n mero a maior u prioridade. Neste caso, como todos t m a mesma prioridade, os comandos ir o aparecer na e a ordem em que s o adicionados. Com prioridades diferentes, os comandos cam listados por a ordem de maior prioridade para menor, para facilitar o acesso do usu rio aos comandos mais a 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 m todo commandAction. Assim, ele recebe um comando e a tela (Displayable) em que e o comando foi executado. No c digo demonstrado, fazemos comparacoes para saber em qual o tela o jogo se encontra atualmente. H algumas telas em que s existe uma acao possvel, como a o por exemplo as telas de Splash. Desse modo, n o e preciso saber qual comando foi executado, a j que obrigatoriamente deveremos passar para a tela seguinte. a

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

J com o comando botaoIrParaMenu, podemos notar que existe uma condicao que verica a se o usu rio est no meio do jogo. Caso isso seja verdade, o jogo ca pausado e a tela de menu a a recebe um novo bot o Continuar Jogo. a /** * Recebe os eventos que ocorreram, e a tela em qual ocorreu e * realiza a aao correspondente. c~ * * @param comando * * O evento recebido. A tela na qual o evento ocorreu. * @param tela

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 s o feitas utilizando o m todo abaixo: a e /** * 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 s o tratados de forma um pouco diferente. a ` Os comandos foram associados a bot es da telaMenu. Assim, toda vez que um bot o e pressio a onado, 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 (bot o) possui somente um comando, o m todo s precisa avaliar qual foi a e o o item pressionado.

Abaixo, temos um exemplo de associacao de um comando a um bot o. Em seguida, associ a amos ao bot o o ItemCommandListener mostrado no c digo acima. a o botaoDeNovoJogo.addCommand(botaoOK); botaoDeNovoJogo.setItemCommandListener(listenerDeItens);

7.2.3

A classe TelaDoJogo

A classe TelaDoJogo estende GameCanvas e e respons vel pela tela principal do jogo, a incluindo deteccao das teclas pressionadas, atualizacao do que e mostrado na tela e efeitos sonoros.

O m todo abaixo e respons vel pela atualizacao da tela. Os par metros recebidos servem e a a para delimitar a regi o que ser redesenhada na tela, para quest es de minimizacao de esforco a a o em certos momentos da execucao do programa. O m todo ushGraphics chamado e o que e atualiza na tela aquilo que estava no buffer dentro de area desejada.

31

/** * Atualiza uma parte da tela do jogo. * @param x * * @param y * * * */ public void refresh(int x, int y, int largura, int altura) { layer.paint(g, 0, 0); flushGraphics(x, y, largura, altura); } Posi~o vertical em pixels onde comea a area a ser atualizada. ca c Largura em pixels da area a ser atualizada. Altura em pixels da area a ser atualizada. * @param largura * @param altura Posi~o horizontal em pixels onde comea a area a ser atualizada. ca c

Para a deteccao de estmulos do usu rio, o m todo keyPressed e denido recebendo o a e c digo da tecla pressionada como par metro. O que fazemos e detectar se o que foi passado o a ` corresponde as teclas 4, 6 ou 5, que movimentam a cha do jogador para esquerda, para a direita ou conrma a jogada, respectivamente. H outro trecho condicional que verica se o c digo da a o ` tecla pressionada corresponde a algum gameAction.

O gameAction e um mapeamento das teclas especiais de movimentacao um aparelho celular especco para jogos. Assim, com os dois tipos de vericacao de teclas apresentados abaixo, e possvel utilizar tanto as teclas num ricas quanto as direcionais para se jogar. e /** * Detecta as teclas que s~o pressionadas durante o jogo. a * @param keyCode * */ public void keyPressed(int keyCode) { switch (keyCode) { case KEY_NUM4: Cdigo da tecla pressionada. o

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, s o utilizadas v rias camadas. Cada camada adicionada e posicia a onada num array, e a camada mais pr xima do usu rio e a situada na primeira posicao, e a da o a ultima posicao e a que ca ao fundo de todas. Desse modo, o m todo append insere a camada e adicionada no nal do array e portanto mais ao fundo. Demonstrando o sistema de camadas da classe GameCanvas, no m todo abaixo adicionamos primeiramente a grade transparente do e

33

tabuleiro, que e na verdade a camada que ca acima de todas na tela, em seguida as duas bolas usadas para a animacao das jogadas e por ultimo o fundo com o tabuleiro totalmente pintado. Assim, as bolas cam na frente do fundo e por tr s das grades, o que cria o efeito das bolas a 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 chas utilizadas no jogo, assim como m todos para operar sobre esses sprites. e

Este campo e o pr prio sprite, que vai ser utilizado nos m todos da classe. o e private Sprite bola;

Segue abaixo a sequ ncia que representa a ordem dos frames do sprite e serve para denir e a animacao da bola. Os n meros dos frames s o denidos durante a criacao do sprite. Neste u a caso, ao executar a sequ ncia (com o m todo bola.nextFrame()), a bola parece estar caindo. e e private int[] sequenciaDeSaida = {0, 1, 2, 4}; bola.setFrameSequence(sequenciaDeSaida);

34

Para criar o sprite, passamos como par metro a imagem contendo os frames desejados, e a tamb m a dimens o do sprite (neste caso, a altura e a largura s o iguais). e a a bola = new Sprite(imagemDaAmarela, diametro, diametro);

Abaixo temos o m todo respons vel por mover a bola para a direita. O m todo inicia toe a e mando a posicao atual da bola. A seguir, o sprite e atualizado para o ultimo frame da sequ ncia e do sprite, que representa uma imagem vazia. Essa imagem e pintada na tela com o m todo e refresh da classe TelaDoJogo. Isso faz com que a bola suma na tela do usu rio. a Logo ap s, o sprite e movido uma casa para a direita e o sprite e atualizado para o primeiro o frame da sequ ncia, que cont m a bola cheia. Essa bola e pintada novamente na tela com o e e mesmo m todo, fazendo com que ela reapareca. e Por quest es de otimizacao, o m todo refresh() pinta apenas a area em que a bola est se o e a movimentando, para n o pintar desnecessariamente as regi es em que n o h modicacao na a o a a 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 m todo simples move o sprite x pixels no eixo x e y no eixo y. e

35

public void mover(int x, int y) { bola.move(x, y); }

7.2.5

PlayTone

Para a utilizacao de sons no jogo, optamos pelo uso do m todo playTone. Este m todo e e ` pertence a classe Manager do Java ME e e respons vel por produzir um tom, dado sua duracao a e a nota. Os sons presentes no Liga Quatro s o produzidos ap s cada jogada e ao mostrar a tela a o de vit ria, derrota ou empate. Um exemplo pode ser conferido abaixo: o /** * 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 m todo playTone recebe como primeiro par metro a nota, que deve ser um n mero entre e a u 0 e 127 e e calculada atrav s de uma f rmula encontrada em http://java.sun.com/javame/ e o reference/apis/jsr118/. Como segundo par metro, e passada a duracao da nota em milisa segundos. O terceiro par metro do m todo corresponde ao volume do tom, que deve ser entre 0 a e 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 n o se sobreponham durante sua a execucao.

36

8

Bibliograa

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