Professional Documents
Culture Documents
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
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
Java ME 2.1 O que e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 2.1.2 2.2 2.3 2.4 Aplicacoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Vantagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ferramentas de desenvolvimento 3.1 3.2 Sun Wireless Toolkit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IDEs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 3.2.2 NetBeans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Bibliograa
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
1.3
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
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 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
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:
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
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
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
Ferramentas de desenvolvimento
3.1
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
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.1
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
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
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.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.2
7.2.1
Estrutura do c digo o
Commands
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
* */
7.2.2
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); }
35
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
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