Tecnologia Java Aplicada a Telemóveis - ipp.ptpaf/proj/Set2003/Java... · 2003. 9. 8. · O 5º...

Instituto Superior de Engenharia do Porto

Departamento de Engenharia Informática

Tecnologia Java Aplicada a Telemóveis

Trabalho realizado no âmbito da disciplina de Projecto, do 5º ano da licenciatura de engenharia informática. Aluno: José Filipe Soeiro Teixeira Orientador: Eng.º Luís Pinho

Porto, 2003

Tecnologia Java aplicada a telemóveis

II

III

Tecnologia Java Aplicada a Telemóveis

Realizado por: José Filipe Soeiro Teixeira

Orientador ISEP: Eng.º Luís Pinho

Data de realização: Agosto, 2003


IV

V

Índice ÍNDICE................................................................................................................V

AGRADECIMENTOS........................................................................................VII

1. INTRODUÇÃO................................................................................................1

2. TELEMÓVEIS E TECNOLOGIA.....................................................................3

2.1.AUDIO .........................................................................................................3 2.1.1. Sons polifónicos.................................................................................3 2.1.2. Leitores de MP3.................................................................................4

2.2. VÍDEO ........................................................................................................4 2.2.1. Captura de Imagens ..........................................................................4 2.2.2. Display ...............................................................................................5

2.3. MEMÓRIA....................................................................................................6 2.4. SOFTWARE .................................................................................................6

2.4.1. Exemplos ...........................................................................................8 2.4.2. Suporte ............................................................................................10

3. JAVA.............................................................................................................11

3.1 – CONCEITOS BÁSICOS ...............................................................................12 3.1.1 – A linguagem de programação........................................................12 3.1.2 – A plataforma...................................................................................15

3.2 – J2SE / J2EE / JAVA CARD.......................................................................16 3.3 – J2ME.....................................................................................................18

3.3.1 – Arquitectura do J2ME ....................................................................18 3.3.1.1. Configuração.........................................................................................19 3.3.1.2. Perfil ......................................................................................................21

3.3.2 – Connected Limited Device Configuration.......................................23 3.3.2.1. CLDC Java Virtual Machine ..................................................................23 3.3.2.2. Virtual Machine e especificações de linguagem...................................24 3.3.2.3. Carregamento de classes .....................................................................26 3.3.2.4. Considerações de segurança ...............................................................26 3.3.2.5. Compilar e correr código com KVM ......................................................29

3.3.3 – O Mobile Information Device Profile e MIDlets ..............................36 3.3.3.1. MIDP .....................................................................................................36 3.3.3.2. Requisitos de hardware do MIDP .........................................................37 3.3.3.3. Requisitos de software do MIDP...........................................................38 3.3.3.4. A plataforma MIDP................................................................................39 3.3.3.5. MIDlets e MIDlet suites .........................................................................40 3.3.3.6. Segurança nas MIDlets.........................................................................41 3.3.3.7. MIDlet packaging ..................................................................................42 3.3.3.8. Ciclo de vida e ambiente de execução das MIDlets .............................44

4. ALTERNATIVAS AO J2ME..........................................................................51

4.1. EXECUTION ENGINE (EXEN).......................................................................52 4.2. MOPHUN ..................................................................................................53 4.3. WIRELESS GRAPHICS ENGINE (WGE) ........................................................54 4.4. BINARY RUNTIME ENVIRONMENT FOR WIRELESS (BREW) ...........................55 4.5. SYMBIAN OS ............................................................................................56


VI

5. QUESTÕES FUNDAMENTAIS AO DESENVOLVIMENTO PARA TELEMÓVEIS ...................................................................................................59

5.1. MEMÓRIA..................................................................................................59 5.2. PROCESSADOR .........................................................................................59 5.3. DISPLAY ...................................................................................................60 5.4. SOM.........................................................................................................61 5.5. INPUT .......................................................................................................61 5.6. SEGURANÇA .............................................................................................61 5.7. FUNCIONALIDADE ......................................................................................62 5.8 – INSTALAÇÃO............................................................................................62

6. FERRAMENTAS PARA O DESENVOLVIMENTO DE APLICAÇÕES ........63

6.1. J2SE SDK...............................................................................................63 6.2. J2ME WIRELESS TOOLKIT .........................................................................64

6.2.1. Default Device Selection..................................................................65 6.2.2. Documentation.................................................................................65 6.2.3. KToolbar ..........................................................................................66 6.2.4. OTA Provisioning .............................................................................84 6.2.5. Preferences ................................................................................84 6.2.6. Run MIDP Application... ..............................................................84 6.2.7. Utilities .........................................................................................86

6.3. EDITOR JAVA ............................................................................................86

7. DESENVOLVIMENTO ..................................................................................87

7.1. HELLO WORLD ..........................................................................................89 7.2. PRINCÍPIOS BÁSICOS .................................................................................91 7.3. DESENVOLVIMENTO DE UMA MIDLET ..........................................................94

8. CONCLUSÃO.............................................................................................117

9. BIBLIOGRAFIA ..........................................................................................119

10. ANEXO .....................................................................................................123

11. ÍNDICE DE FIGURAS...............................................................................129

12. ÍNDICE DE TABELAS ..............................................................................131

VII

Agradecimentos Existem algumas pessoas sem as quais não teria sido possível a realização deste projecto e, por isso, merecem um especial agradecimento. Quero agradecer em primeiro lugar à minha Mãe e à minha Avó (adoro-vos) que, apesar de infelizmente, já não estarem entre nós, sempre me apoiaram no decurso deste projecto e, de certeza, ainda estão comigo. Quero também agradecer ao meu Pai (também te adoro) que me apoiou em tudo, especialmente nos momentos mais difíceis. Um agradecimento especial à Ana, que está sempre comigo e me aturou durante este tempo todo (um enorme beijinho para ti!). Um abraço para os meus amigos, com quem posso contar para tudo! Obrigado Samuel (pelas ideias), Rui “Les” Matos, Wilson “Bizu” Carvalho, Nuno “Presi” Soares, Ana “Timon” Azevedo, Aníbal “Flintstone” Couto, Luís “Viagra” Leal, Leandro “Julieta” Castro, Daniel “Spielberg” Martinho, Victor, Romeu, Mário, Nuno e o resto do pessoal do ISEP que me apoiou e, mesmo não notando, ajudou à realização deste projecto. Quero agradecer também ao meu orientador Luís Pinho que foi uma ajuda fundamental em todas as formalidades necessárias ao sucesso deste projecto. Para finalizar, como de certeza que me esqueci de alguém, quero agradecer a essa pessoa e pedir desculpa pelo esquecimento. Obrigado!

Este projecto é dedicado à minha Mãe e à minha Avó.


VIII

1

1. Introdução Nestes últimos anos, tem-se vindo a observar uma enorme evolução no

campo das novas tecnologias, nomeadamente na área das telecomunicações. O aparecimento do telemóvel foi revolucionário, e alterou radicalmente o modo de estar e de pensar de milhares de pessoas que possuem e até dependem deste pequeno aparelho.

Desde a viragem do milénio, o telemóvel tem evoluído a uma velocidade estonteante e é agora muito mais do que um simples meio de comunicação. Os grandes telefones portáteis com um pequeno visor monocromático onde apenas se escreviam números, transformaram-se em pequenos aparelhos dotados de uma grande capacidade de memória, destinados às mais diversas operações, desde captura de imagens ou filmes, até leitores de MP3 e, mais recentemente, consola de jogos.

O telemóvel é agora uma ferramenta de trabalho e lazer com grandes potencialidades, para a qual se consegue antever um futuro muito promissor.

Porém, uma grande evolução tecnológica tem que ser acompanhada por uma evolução a nível de software de modo a que seja possível tirar partido de todas as capacidades desta nova ferramenta de trabalho.

O recente aparecimento de telemóveis que suportam linguagens de programação de alto nível, nomeadamente Java, vem fundamentar esta teoria. Este suporte vem alargar consideravelmente as potencialidades deste aparelho. Novos programas ou jogos podem ser desenvolvidos e facilmente inseridos no telemóvel.

Em comparação com outros aparelhos portáteis como PDAs ou consolas de jogos, o telemóvel tem inúmeras vantagens. As pessoas habituaram-se a levar o telemóvel para todo o lado, ao contrário do que acontece com outros dispositivos e, por isso, é muito mais confortável ter todas as funcionalidades necessárias aí incluídas. Num futuro próximo, qualquer pessoa poderá consultar a sua agenda, navegar na internet ou jogar um jogo, enquanto toma café ou espera numa fila, apenas utilizando o seu telemóvel que anda sempre consigo.

O objectivo deste documento é dar a conhecer o estado actual das

tecnologias móveis de comunicação, as suas verdadeiras potencialidades e o modo de as explorar. Só através do conhecimento das tecnologias e desenvolvimento de software é possível tirar partido das funcionalidades que os telemóveis têm actualmente para oferecer.

Ao longo deste documento, no capítulo 2 irão ser ilustradas as

características principais dos telemóveis mais actuais, como capacidade de memória, número de cores ou resolução suportada.

No capítulo 3 será abordada a linguagem Java como linguagem principal para o desenvolvimento de aplicações destinadas a este tipo de plataformas móveis. Neste capítulo, será feita uma distinção entre a linguagem Java normal (J2SE), que é utilizada em inúmeras aplicações para computador, e a sua versão “micro” que se destina a plataformas móveis, como é o caso dos telemóveis.


2

No capítulo 4, será feita uma breve referência a outras linguagens

existentes que, em alternativa ao J2ME, também podem ser utilizadas para desenvolver aplicações destinadas a telemóveis.

O 5º capítulo faz uma abordagem a algumas questões fundamentais que o programador deve ter em conta quando programa para esta plataforma.

Mais adiante, no capítulo 6, será feita uma análise ás ferramentas necessárias para o desenvolvimento de aplicações em J2ME para telemóveis. É importante conhecer as aplicações utilizadas, de modo a optimizar e toda a fase de desenho e programação de aplicações.

Por fim, no capítulo 7, será descrito passo a passo todo o processo de desenvolvimento de uma pequena aplicação J2ME (jogo), desde a sua criação utilizando as ferramentas adequadas, até à sua instalação, passando por diversos exemplos de codificação das características mais importantes de uma aplicação deste tipo.

Todo o código referente à aplicação desenvolvida no capítulo 7, será

disponibilizado em anexo.

2. Telemóveis e tecnologia Actualmente quando alguém quer comprar um telemóvel tem uma enorme variedade de marcas e modelos à escolha, cada um com características diferentes desde o seu formato, até à sua memória ou número de cores do ecrã. A gama de telemóveis varia desde o mais barato que serve apenas para telefonar e escrever mensagens (Nokia 3310, ...) até ao mais caro, topo de gama com câmara de vídeo incorporada, ecrã a cores, Bluetooth e suporte para linguagens de programação de alto nível, como J2ME (Nokia 3650, ...). Os telemóveis mais actuais disponibilizam um enorme leque de capacidades para uso do consumidor. Agora, para além de comunicar, é possível gravar vídeo e tirar fotografias com o telemóvel, navegar na internet, ouvir música ou mesmo jogar. Estas são algumas das tecnologias mais recentes que se podem encontrar nos telemóveis:

2.1.Audio A componente audio dos telemóveis foi a primeira a ser explorada. Desde já há algum tempo que os telemóveis têm variados tipos de toques para todos os gostos. No entanto, a evolução a este nível continua e, nos últimos anos, apareceram os toques polifónicos e os leitores de MP3.

2.1.1. Sons polifónicos Esta tecnologia permite aos telemóveis um nível sonoro bastante melhorado. Isto é possível através do uso de 16, 32 ou mais canais em vez de apenas 1, como acontece nos telemóveis mais antigos. Deste modo, é possível ouvir o som de diversos “instrumentos” diferentes ao mesmo tempo, elevando assim a sua qualidade. É importante ter em conta este facto quando se programa para um telemóvel. No caso da criação de um jogo (que é actualmente o mais habitual...), é possível separar a musica de fundo dos efeitos sonoros. Aqui está uma lista de telemóveis que suportam toques polifónicos:

Marca Modelos Motorola C330, C350, T720I, ... Nokia 3510, 3650, 5100, 7650, ... Panasonic GD700, GD87, GU87, ... Samsung SGH-X400(40), SGH-V200(40), ... Sony Ericsson P800, T310(32), T610(32), ...

Tabela 2. 1 - Toques Polifónicos


4

2.1.2. Leitores de MP3 Por outro lado, temos os telemóveis que funcionam como leitor de MP3.

Nestes aparelhos, é possível armazenar uma quantidade variável de musicas no formato MP3, dependendo da qualidade de gravação e da memória do aparelho.

2.2. Vídeo Esta componente só há relativamente pouco tempo é que começou a

sofrer alterações. Inicialmente, um telemóvel servia apenas para telefonar e continha um visor monocromático, o que era suficiente para as suas funcionalidades. Actualmente já não é bem assim...

Quando se fala da componente vídeo num telemóvel, fala-se de captura de vídeo ou imagens, e da resolução, tamanho e número de cores suportadas pelo ecrã. Estas são características cada vez mais importantes a ter em consideração, quando se pensa em adquirir um telemóvel.

2.2.1. Captura de Imagens No que diz respeito à captura de imagens, não se pode considerar um

factor de muita importância para a programação, pois a maioria dos programas não necessita de câmara digital. De qualquer forma, a lista que se segue indica alguns dos telemóveis mais recentes que suportam esta tecnologia.

Marca Modelo Tipo de câmara Resolução Captura de vídeo

Nokia 7650 Incorporada 640x480 Sim (por software)

Nokia 3650 Incorporada 640x480 Sim Nokia 6600 Incorporada 640x480 Sim Nokia 6650 Incorporada 640x480 Sim Panasonic GU87 Incorporada 132x176 Não Samsung SGH-V200 Incorporada 640x480 Não Siemens SL55 Incorporada 640x480 Não Sony Ericsson T310,

T300 Como acessório

640x480 Não

Sony Ericsson T610 Incorporada 288x352 Não Sony Ericsson P800 Incorporada 640x480 Não

Tabela 2. 2 - Captura de imagens/vídeo

Note-se porém, que a programação destinada a este tipo de plataformas

moveis está ainda a dar os primeiros passos e tudo indica que futuramente se faça uso das capacidades de captura de vídeo para o desenvolvimento de programas, por exemplo, de videoconferência ou até mesmo de entretenimento.

Telemóveis e tecnologia

5

A grande popularidade das câmaras digitais nos telemóveis, irá certamente despertar o interesse de muitos programadores que tentarão tirar o melhor partido desta tecnologia.

2.2.2. Display Este é um dos factores mais importantes a ter em conta quando se programa para um telemóvel. É necessário ter em atenção a resolução, o tamanho do ecrã e mesmo a quantidade de cores suportada varia, o que quer dizer que um determinado programa pode funcionar apenas num determinado modelo de telemóveis, ou pode ser mais genérico e adaptar-se a um leque mais variado de modelos. Actualmente a grande maioria dos programas desenvolvidos para telemóveis são jogos, e como tal, possuem uma elevada componente visual. O grafismo deste tipo de aplicações é muito importante e, se por um lado um jogo fica melhor quando desenvolvido para uma mais alta resolução e um elevado número de cores, por outro lado, isto pode limitar a sua compatibilidade e restringi-lo a um ou dois modelos disponíveis no mercado. Segue-se uma lista das características do display de alguns dos telemóveis mais recentes.

Marca Modelo Resolução Cores Nokia N-Gage 176x208 px 4,096 Nokia 7650 176x208 px 4,096 Nokia 6600 176x208 px 65,536 Nokia 3650 176x208 px 4,096 Nokia 6800 128x128 px 4,096 Nokia 5100 128x128 px 4,096 Panasonic GU87 132x176 px 65,536 Panasonic X70 132x176 px 65,536 Samsung SGH-X400 128x160 px 65,536 Samsung SGH-V200 128x160 px 65,536 Samsung SGH-C100 128x128 px 65,536 Samsung SGH-S200 128x144 px 65,536 Samsung SPH-N270 128x160 px 65,536 Samsung SPH-A500 128x160 px 4,096 Siemens SL55 101x80 px 4,096 Sony Ericsson T310 101x80 px 256 Sony Ericsson T610 128x160 px 65,536 Sony Ericsson P800 208x320 px 4,096

Tabela 2. 3 - Características do display

Desta extensa lista, presta-se especial atenção ao Nokia N-Gage que se apresenta não só como um telemóvel mas, principalmente, como uma consola de jogos, tendo já feito referência a alguns jogos de nome já conhecido (“Tomb Raider”, “Sonic”, ...) desenvolvidos pela Sega especialmente para o N-Gage.


6

2.3. Memória Outra característica muito importante a ter em conta é a memória disponível no telemóvel, para os programas desenvolvidos. Actualmente, estes aparelhos possuem uma memória muito escassa o que dificulta a programação e limita a qualidade dos programas. Por isso, é necessário ter em consideração a capacidade de memória do telemóvel para o qual se pretende desenvolver uma aplicação. Existem três tipos de memória a ter em atenção: a memória de armazenamento, a memória de execução e o tamanho máximo dos ficheiros JAR.

• Memória de armazenamento - A memória de armazenamento limita o tamanho máximo disponível para o programa. Esta é a memória onde o programa desenvolvido fica alojado. Alguns telemóveis suportam o uso de cartões de memória externos para aumentar a sua capacidade.

• Memória de execução – Esta é a memória utilizada em tempo de execução por uma aplicação, ou seja, é a capacidade máxima de memória que uma aplicação pode utilizar durante a sua execução.

• Ficheiros JAR – Esta memória define o tamanho máximo suportado para os ficheiros JAR. Note-se que um ficheiro JAR é um ficheiro comprimido que contém código e é muitas vezes utilizado como forma de reduzir o tamanho de uma aplicação, o que é muito útil no caso da programação para este tipo de suporte.

As capacidades de memória de alguns dos telemóveis mais propícios ao

desenvolvimento de programas, encontram-se na seguinte tabela:

Marca Modelo Armazenamento Execução Ficheiros JAR Nokia N-Gage 4MB+MMC (memory cards) 2.8MB 4MB Nokia 7650 4MB 1.4MB 4MB Nokia 6600 6MB+MMC 3MB (não disponível)

Nokia 3650 3.4MB+MMC 1.4MB 4MB Nokia 6800 5.2MB 200KB 64KB Nokia 5100 725KB 200KB 64KB

Tabela 2. 4 - Capacidades de memória

Embora seja fundamental que um programador saiba as características

de memória do telemóvel para o qual se destina uma aplicação a ser desenvolvida, está é ainda uma informação de difícil acesso.

Deste modo, só foi possível obter as características de memória, relativas aos telemóveis Nokia, disponibilizadas no site da marca.

2.4. Software O software criado para telemóveis encontra-se actualmente numa fase ainda inicial de desenvolvimento. No entanto, tem-se notado uma rápida evolução neste campo. Todos os dias surgem novos programas destinados a estas plataformas e cada vez mais programadores interessados por esta tecnologia.


7

Existem actualmente diversas plataformas de programação suportadas pelos telemóveis mais recentes, sendo o Java a mais popular e, quando se fala em Java para telemóveis, fala-se em jogos e programas ligados à área de entretenimento. A verdade é que a grande maioria do software que se pode inserir num telemóvel são jogos, desenvolvidos quer por grandes empresas, quer por programadores independentes. Já na industria da informática, os jogos ocupam um lugar de destaque e representam uma parcela considerável das vendas e dos lucros, no que diz respeito a software. Daqui se pode concluir que as novas tecnologias não são só uma ferramenta de trabalho, mas também um instrumento de lazer para que se possa fugir do stresse do dia-a-dia. É por isso natural que nos telemóveis, a área do entretenimento prospere ainda mais. Se pelo ponto de vista do utilizador os jogos são mais apelativos e um óptimo meio para descontrair, para a grande parte dos programadores, desenvolver um jogo é mais motivante e vende-se melhor. Também à semelhança do que acontece com os computadores pessoais, são os jogos que vão tirar o máximo partido de todas as capacidades do aparelho. São estes programas que vão combinar uma elevada resolução de imagem com uma boa qualidade sonora, o que dá a conhecer ao utilizador todas as capacidades do seu telemóvel, e permite ao programador, usar as mais recentes tecnologias no desenvolvimento de aplicações. Além disso, a utilidade de outro tipo de ferramentas num telemóvel, como uma folha de cálculo, uma base de dados ou um processador de texto, é bastante questionável. O aparecimento de alguns modelos de telemóveis como o SGH-X400 da Samsung e o N-Gage da Nokia vêm reforçar a ideia de que os jogos têm uma crescente importância neste meio. O N-Gage, mais do que um telemóvel é já considerado uma consola capaz até de rivalizar num futuro próximo com o já conhecido “Game Boy”. Para este caso, a Nokia assumiu uma parceria com a Sega que produzirá jogos de grande qualidade (“Sonic”, “Tomb Raider”, ...) para esta consola/telemóvel. Em seguida, serão mostrados alguns exemplos de software que se pode obter para as diversas plataformas suportadas pelos telemóveis mais recentes.

Figura 2. 1 - Nokia N-Gage


8

2.4.1. Exemplos

Título: Dragon Island Desenvolvido por: Macrospace Tipo: Jogo Plataforma: J2ME Memória: 65K Preço: 3,00 � Telemóveis: Nokia 7650, 3650, 6800, 5100, ...; Siemens SL55; ... Comentário: Este é um dos mais recentes jogos desenvolvidos para a plataforma J2ME. Como pode ser visto nas imagens, foi feito um bom aproveitamento das 4,096 cores utilizadas, o que também torna este jogo compatível com um maior número de telemóveis. Aqui está um bom exemplo do que se consegue desenvolver para um telemóvel.

Título: XFinity Desenvolvido por: Synergenix Tipo: Jogo Plataforma: Mophun Memória: 118K Preço: 5,00 � Telemóveis: Sony Ericsson T300, T310, ... Comentário: Este é um exemplo de uma aplicação desenvolvida sobre a plataforma Mophun. A qualidade mantêm-se bastante boa e, existe bastante suporte para Mophun, quer em termos de software disponível, quer em termos de telemóveis . Note-se que este é um jogo mais caro, e ocupa bastante mais memória.

Figura 2. 2 - Imagens de Dragon Island

Figura 2. 3 - Imagens de XFinity


9

Título: Hurricane Space Fighters Desenvolvido por: TTPCom Tipo: Jogo Plataforma: WGE Memória: Não disponível Preço: Não Disponível Telemóveis: Innostream I-1000, ... Comentário: Aqui temos uma plataforma que demonstra

possuir grandes potencialidades mas, encontrar uma aplicação desenvolvida para “Wireless Graphics Engine”, revela-se uma tarefa quase impossível. Além da falta de software, existem ainda poucos telemóveis a suportar WGE.

Título: Crash Bandicoot Desenvolvido por: In-Fusio Tipo: Jogo Plataforma: ExEn Memória: Não disponível Preço: Não Disponível Telemóveis: Panasonic GD67, GD87, ... Comentário: O “Execution Engine” (ExEn) revela-se uma plataforma capaz de produzir bons resultados.

Apesar disso, existe alguma dificuldade de encontrar software desenvolvido para ExEn.

Também se nota alguma escassez de telemóveis a suportar esta plataforma.

Título: Fantom Overdrive Desenvolvido por: Overloaded Tipo: Jogo Plataforma: Symbian OS Memória: 581K Preço: 5,95� Telemóveis: Nokia 3650, 7650, Sony Ericsson P800, ... Comentário: Embora não tenha a popularidade do Java, a plataforma Symbian possui já bastante software disponível, com uma boa qualidade. Além disso, existe já uma vasta gama de telemóveis com este suporte.

Figura 2. 4 - Imagens de Hurricane Space Fighters

Figura 2. 5 - Imagens de Crash Bandicoot

Figura 2. 6 - Imagens de Fantom Overdrive


10

2.4.2. Suporte Um dos principais aspectos a ter em conta quando se pretende desenvolver uma aplicação para uma determinada plataforma, é o suporte disponibilizado. Antes de se começar a desenvolver, é necessário saber que telemóveis suportam as diversas plataformas existentes, de forma a fazer a opção mais adequada. Aqui está uma pequena lista de telemóveis que suportam as diversas tecnologias.

Marca Modelo Plataformas Fujitsu F2051 J2ME, Symbian Innostream I-1000 WGE Motorola V600 J2ME Motorola T725 J2ME Nokia N-Gage J2ME, Symbian Nokia 7650 J2ME, Symbian Nokia 6600 J2ME, Symbian Nokia 3650 J2ME, Symbian Nokia 6800 J2ME Nokia 5100 J2ME Panasonic GU87 ExEn Panasonic X70 J2ME, ExEn Sagem my G-5 ExEn Sagem my X-5 ExEn Samsung SGH-X400 J2ME Samsung SGH-V200 J2ME Samsung SGH-C100 J2ME Samsung SGH-S200 J2ME Siemens SL55 J2ME Siemens U10 J2ME Sony Ericsson

T310 Mophun

Sony Ericsson

T610 J2ME, Mophun

Sony Ericsson

P800 J2ME, Symbian

Tabela 2. 5 – Tecnologias suportadas

Como se pode observar, o Java ocupa actualmente a maior parcela de mercado, comparativamente com outras plataformas de programação.

3. Java

Actualmente os telemóveis de ultima geração, associam-se à tecnologia Java, mesmo que não se saiba exactamente o que isso é.

A grande quantidade de publicidade feita a esta plataforma tem resultado e, para comprovar, pode-se observar a crescente importância do Java na área das comunicações móveis, e a quantidade de software e suporte existente para esta tecnologia. As campanhas publicitárias feitas aos telemóveis já nos habituaram à palavra Java, falando insistentemente de jogos Java e tecnologia Java, de tal maneira que quando se vai comprar um telemóvel,

é normal perguntar ao vendedor: “Este modelo suporta Java?” Muitas das vezes a resposta é afirmativa e o cliente vai para casa

satisfeito por ter adquirido um telemóvel que até ficou um pouco mais caro mas suporta Java. No entanto, a verdadeira pergunta é: Mas afinal o que é o Java? E qual é a vantagem de ter Java no telemóvel?

Este documento é destinado pessoas que já possuem algum conhecimento na área da programação e, certamente já estão familiarizados com o conceito Java como linguagem de programação mas, de qualquer maneira existem algumas diferenças quando se programa nesta linguagem para plataformas móveis. Neste capítulo, irá ser feita uma breve referência à linguagem Java e à sua utilização em telemóveis. Quem tenciona desenvolver uma aplicação destinada às mais recentes tecnologias móveis usando esta plataforma deve, em primeiro lugar, saber as características e o modo de funcionamento desta linguagem de programação, em particular da sua versão “Micro” que se destina exactamente a máquinas com baixa capacidade de memória e processamento (telemóveis).


12

3.1 – Conceitos básicos O Java é um ambiente de programação que combina uma plataforma específica com uma linguagem de alto nível, muito prática e funcional.

3.1.1 – A linguagem de programação O Java é uma linguagem de programação de alto nível, orientada ao objecto e de fácil compreensão. Esta linguagem possui determinadas características que a tornam muito apetecível para programadores que trabalham sobre qualquer plataforma. Podemos então definir o Java como uma linguagem de programação que se distingue pelas seguintes características:

• Simples – O Java é uma linguagem simples e não necessita de treino extensivo de programação para que se consiga obter resultados. Os conceitos básicos do Java são facilmente apreendidos e as ferramentas são intuitivas e facilitam o trabalho do programador.

• Orientada ao objecto – O Java adopta o conceito de objecto, para facilitar e organizar todo o processo de programação. O código passa a ser encapsulado e reutilizável, podendo abstrair o programador de funções mais complexas ou permitir o uso de objectos já desenvolvidos. Podem ser utilizadas librarias externas com código já desenvolvido bem como quaisquer outros objectos que possam ser úteis para a programação de uma aplicação.

• Arquitectura neutra – O Java foi desenhado de forma a poder interagir com diversos sistemas, com diversas arquitecturas distintas e heterogéneas. Para que isto seja possível e para que seja independente da plataforma utilizada, o compilador Java compila o código desenvolvido para uma arquitectura intermédia denominada byte codes, neutra e independente, destinada a transportar o código eficientemente entre diferentes plataformas de hardware e software.

• Portável – A arquitectura neutra utilizada pelo Java, torna-o numa linguagem altamente portável e compatível com diferentes tipos de máquinas ou software. Cada máquina (plataforma) é responsável pela interpretação do código de byte codes, através de uma Java Virtual Machine (JVM). Assim sendo o código desenvolvido em Java pode correr em qualquer plataforma desde que esta possua uma JVM.

• Distribuída – Devido à sua grande portabilidade, o Java consegue estabelecer comunicação entre diversas plataformas distintas o que a torna ideal para a programação distribuída.

Java

13

• Interpretada – O Interpretador Java pode executar byte codes em qualquer máquina para a qual tenha sido portado o sistema. Por outras palavras, num sistema interpretado, como é o caso do Java, a fase de linkagem do programa é simples, incremental e de baixo processamento, tornando os ciclos de desenvolvimento mais rápidos, comparativamente a outras linguagens.

• Robusta – Esta linguagem de programação foi criada tendo em vista o desenvolvimento de software robusto e de confiança. São efectuadas diversas verificações durante as fases de desenvolvimento, compilação e em execução. Além disso, a gestão de memória é encapsulada, feita implicitamente pelo Java, diminuindo drasticamente os erros e facilitando a sua gestão. Um programador pode desenvolver uma aplicação com a confiança de que quaisquer erros serão rapidamente encontrados e resolvidos.

• Segura – O Java foi desenhado para operar em ambientes distribuídos, por isso, foi prestada uma especial atenção ao factor segurança. Deste modo, quaisquer aplicações desenvolvidas estão seguras contra possíveis ataques vindos do exterior.

• Alta performance – Numa linguagem de programação, a performance é sempre importante. No Java, o interpretador pode correr e converter os byte codes em código, sem ter que fazer verificações ao sistema. Algumas empresas estão a tentar desenvolver um compilador de Java para a arquitectura nativa da máquina o que aumentará a performance.

• Multi-processo – O Java suporta programação multi-processo. Num único programa, podem estar múltiplos processos independentes a correr código distinto e continuamente, de uma forma concorrente.

• Dinâmica – A fase de linkagem é dinâmica. As classes desenvolvidas são linkadas apenas quando necessário o que permite que, a qualquer altura, novas classes internas, externas ou até vindas de uma rede, possam ser linkadas com o programa em desenvolvimento. As aplicações desenvolvidas podem assim ser actualizadas em qualquer altura.

• Garbage Collector – Não é necessário fazer qualquer alocação explícita de memória no Java. A memória é alocada quando necessário e recolhida pelo Garbage Collector quando deixa de ser necessária.

Ao contrário da maior parte das linguagens de programação, em que um programa pode ser compilado ou interpretado para que possa correr num computador, com Java o programa é compilado e interpretado. Primeiro o compilador traduz o programa para uma linguagem intermédia e independente da plataforma, denominada byte codes. A partir daí, o interpretador é responsável por correr o código desenvolvido em cada plataforma.


14

No caso do Java, o código é compilado apenas uma vez, e interpretado cada vez que é corrido.

Figura 3. 1 - Esquema de funcionamento do Java

Cada interpretador, quer seja uma aplicação ou um browser que suporte Java applets é uma implementação de uma Java Virtual Machine (JVM) preparada para receber o código em byte codes e corre-lo. É isto que faz com que o Java seja uma linguagem do tipo “write once, run anywhere”. Uma aplicação pode ser desenvolvida e compilada sobre qualquer plataforma, e depois corrida em cima de qualquer implementação da JVM, independentemente da nova plataforma utilizada.

Figura 3. 2 - Portabilidade do Java

Java

15

3.1.2 – A plataforma Uma plataforma pode ser descrita como o ambiente de hardware e software onde pode ser corrido um programa. Ao contrario da maior parte das plataformas conhecidas que resultam na combinação de componentes de hardware com software específico, a plataforma Java é baseada apenas numa componente de software que corre em cima de hardware de outras plataformas. A plataforma Java é constituída por dois componentes:

• Java Virtual Machine (JVM); • Java Application Programming Interface (API);

Tal como foi já referenciado, o JVM é um interpretador que analisa o

código traduzido para byte codes e faz com que possa ser corrido sobre qualquer plataforma. O JVM é portanto toda a base da portabilidade do Java.

O Java API (Application Programming Interface) é uma colecção de

componentes de software já desenvolvidos que disponibilizam muitas utilidades aos programadores, como por exemplo, um interface gráfico (GUI).

A API está agrupada em librarias de interfaces e classes relacionados, que são conhecidas como packages.

Os programadores podem assim utilizar livremente quaisquer packages disponibilizados afim de facilitar e optimizar o desenvolvimento de aplicações sobre esta plataforma.

O esquema que se segue, mostra a plataforma Java e os seus constituintes:

Devido ao uso de um estado intermédio de compilação, onde são gerados os byte codes, a plataforma Java torna-se um pouco mais lenta do que código nativo, contudo, com a utilização de bons compiladores e interpretadores, a performance pode-se aproximar bastante do código nativo sem porém pôr em causa a sua portabilidade. O Java é portanto ideal para trabalhar em diversas plataformas distintas e, por isso, teoricamente, seria apenas necessário desenvolver uma JVM que se pudesse aplicar às diversas plataformas moveis existentes. À primeira vista, o Java adaptar-se-ia perfeitamente como linguagem para programar aplicações destinadas a telemóveis.

Figura 3. 3 - Constituintes do Java


16

3.2 – J2SE / J2EE / Java Card

De modo a optimizar a programação em áreas muito distintas, foram desenvolvidas diferentes versões do Java, destinadas a diferentes utilizações.

• J2SE – Standard Edition – A edição standard é a base da tecnologia Java. No J2SE está contido tudo o que é essencial para programar em Java, incluindo o compilador, ferramentas e APIs para desenvolver applets e aplicações. Esta edição é mais direccionada aos programadores que pretendem desenvolver aplicações standalone ou que corram como cliente.

• J2EE – Enterprise Edition – Esta edição considerada “empresarial” pela “Sun”, além dos componentes básicos e essenciais para programar em Java, contém algumas outras funcionalidades mais vocacionadas para o desenvolvimento em empresas ou aplicações que corram do lado do servidor. O J2EE suporta Enterprise Java Beans (EJB) para optimizar a programação distribuída e segura, com bom suporte de bases de dados, e contém uma API para o desenvolvimento de Java Servlets, Java Server Pages e tecnologia XML.

• Java Card – O Java Card foi desenhado especialmente para plataformas com memória muito limitada que usa smart cards (cartões de memória) como a maioria dos telemóveis, cartões de identificação, etc. Esta tecnologia permite correr pequenas aplicações denominadas applets que utilizam a tecnologia Java.

Embora o Java demonstre ter muitas capacidades e uma grande

vocação para se apresentar em diversas plataformas muito distintas, existem ainda alguns pormenores que impedem de ter um bom desempenho numa plataforma móvel.

Tanto a Standard Edition como a Enterprise Edition não se adequam a ser utilizadas num telemóvel, pelo que foi necessário fazer algumas alterações ás versões existentes de modo a adaptar esta linguagem de grande potencial a estas novas plataformas.

Figura 3. 4 - Diversas versões do Java

Java

17

Também a tecnologia Java Card, embora suficientemente simplificada para poder ser utilizada em plataformas móveis (como já é o caso), demonstra-se demasiado limitativa, permitindo apenas a criação de pequenas applets muito simples. Deste modo, as já grandes potencialidades dos telemóveis mais recentes não seriam minimamente aproveitadas.

Era então necessário o aparecimento de uma nova edição Java que conseguisse conjugar as grandes vantagens e potencialidades disponibilizadas pelo J2SE e J2EE com a vertente mais leve e simplificada da tecnologia JavaCard.

Foi assim lançada recentemente uma nova edição do Java denominada J2ME (Micro Edition).

A figura que se segue dá uma ideia mais clara das diferentes versões do

Java:

Figura 3. 5 - Plataformas Java


18

3.3 – J2ME A edição Micro do Java é uma versão reduzida e altamente optimizada para máquinas com recursos limitados de memória, vídeo e processamento. O J2ME destina-se a pequenos aparelhos como telemóveis, PDAs, sistemas móveis de navegação e quaisquer outros tipos de plataformas móveis que necessitem de um bom desempenho sobre recursos muito limitados. Anunciado em 1999, o J2ME traz muitas das funcionalidades multi-plataforma presentes no Java, permitindo assim o desenvolvimento de aplicações bastante poderosas para as plataformas moveis que têm vindo a surgir. Em seguida, serão analisadas cuidadosamente todas as funcionalidades mais relevantes, presentes no J2ME, dando mais ênfase à plataforma específica dos telemóveis, visto ser esse o tema e objectivo deste documento. Para ter uma boa compreensão do modo de funcionamento da tecnologia Java aplicada aos telefones móveis e saber o procedimento mais adequado para o desenvolvimento de uma aplicação robusta e funcional, é necessário obter o máximo de informação acerca da linguagem / plataforma a utilizar. Serão aqui introduzidos e explicados alguns conceitos essenciais para o desenvolvimento de aplicações com esta tecnologia, que serão utilizados mais adiante, já na fase de desenvolvimento de aplicações.

3.3.1 – Arquitectura do J2ME

De modo a ser mais eficaz e ao mesmo tempo versátil, o J2ME usa “configurações” e “perfis” para personalizar o seu ambiente de trabalho em runtime (Java Runtime Environment – JRE).

O JRE do J2ME é altamente configurável, podendo ser especificado o tipo de JVM utilizado e o perfil que se adequa a modelos mais restritos de plataformas. Conforme cada situação, são seleccionadas classes especificas que melhor se enquadram no tipo de programa que irá ser desenvolvido e na plataforma que servirá de suporte.

A “configuração” define um tipo básico de ambiente para runtime

baseado num conjunto específico de classes, e uma JVM apropriada ao tipo de máquina que será alvo da programação.

O “perfil” é responsável pela definição da aplicação. Aqui, são

adicionadas classes à configuração do J2ME que definem determinadas utilidades adequadas ás máquinas em questão.

Java

19

3.3.1.1. Configuração A configuração é uma especificação que define o ambiente de software

para uma gama de aparelhos definidos por determinadas características, tais como:

• Tipo e quantidade de memória disponível; • Tipo e velocidade do processador; • Tipo de ligação de rede disponível para o aparelho;

A configuração deve representar o suporte mínimo para a plataforma em

questão, e não definir outras funcionalidades opcionais. Os fabricantes devem garantir que as especificações estão implementadas de modo a que os programadores possam desenvolver software consistente e o mais independente de plataforma possível.

Actualmente existem duas configurações possíveis no J2ME: Connected Limited Device Configuration (CLDC)

A configuração CLDC destina-se a aparelhos com recursos mais limitados. Uma plataforma típica CLDC é um telemóvel ou um PDA com um máximo de 512 KB de memória disponível. É por esta razão que o CLDC está muito ligado à vertente wireless do Java, que permite aos utilizadores de telemóveis o download de aplicações denominadas MIDlets.

Um grande número de fabricantes de telefones móveis assinaram já acordos com a Sun Microsystems que lhes permite o uso desta tecnologia. Por isso mesmo, prevê-se que o número de telemóveis programáveis em Java, cresça muito rapidamente durante os próximos anos.

Connected Device Configuration (CDC)

O CDC destina-se aos aparelhos com capacidades superiores aos abrangidos pelo CLDC, mas que se encontram abaixo dos computadores pessoais.

Estes aparelhos, normalmente dispõem de uma memória superior a 2 MB e processadores mais potentes, pelo que podem usufruir de um ambiente muito mais complexo e poderoso do que os anteriores.

Esta configuração é muito utilizada nos PDAs topo de gama.

Cada configuração consiste numa JVM e numa colecção base de classes Java que fornecem um ambiente adequado, para o desenvolvimento de aplicações de software.


20

As muitas limitações em termos de processamento e memória,

especialmente em aparelhos com menos recursos como é o caso dos telemóveis, tornam impossível para uma J2ME Virtual Machine suportar todas as funcionalidades, instruções em byte code e optimizações de software suportadas pela Virtual Machine do J2SE. Por isso mesmo, as VMs do J2ME são definidas mediante o caso para o qual se pretende programar, ou seja, uma VM irá ser adequada a um tipo concreto de configuração. Por exemplo, como na maioria dos casos, os aparelhos abrangidos pelo CDLC não suportam operações com virgula flutuante, a VM do CLDC não tem que suportar tipos de dados como float e double, ou quaisquer classes ou métodos que envolvam este tipo de operações.

Note-se no entanto que as configurações não requerem o uso de VMs específicas. Os fabricantes são livres de criar as suas próprias VMs ou licenciar VMs que respondam melhor aos seus requisitos.

A Sun fornece já VMs específicas para cada tipo de configuração: • Com a configuração CLDC, está incluída uma VM denominada

Kilobyte Virtual Machine (KVM). Esta é uma VM com funcionalidades reduzidas, necessita de pouca memória e possui um garbage collector optimizado para ambientes com poucos recursos. Embora a KVM seja muito provavelmente a mais utilizada em implementações CLDC, existe uma outra VM da IBM denominada “J9”, que também pode ser utilizada nestes casos.

• O CDC inclui uma VM denominada “CVM” que suporta a grande parte das funcionalidades da VM utilizada pelo J2SE, à excepção de alguns aspectos incluídos nas versões mais recentes. Também para este caso existem alternativas lançadas pela IBM.

As configurações também incluem algumas classes Java essenciais. As

librarias de classes Java definidas para uma determinada configuração ( e perfil) são baseadas na plataforma Java 2. Isto permite aumentar a compatibilidade entre aplicações desenvolvidas em J2ME e J2SE, e diminui o tempo e dificuldade de aprendizagem para os programadores de J2ME. Por outras palavras, isto quer dizer que os programadores podem confiar no seguinte:

• Sempre que possível, o J2ME reutiliza as classes e packages do J2SE. Isto quer dizer que tudo o que se sabe do J2SE pode ser aplicado ao J2ME, tendo em conta as limitações do suporte físico, configuração e perfil escolhido.

• Quando uma classe J2SE é incorporada no J2ME, não podem ser acrescentados novos métodos ou campos. Isto assegura que, se uma aplicação J2ME é feita exclusivamente com classes vindas do J2SE, então é possível compilar e correr essa aplicação em J2SE. Isto permite a troca de código entre plataformas distintas.

Para o caso específico da programação aplicada a telemóveis, a

configuração mais adequada seria a CLDC, com o uso da KVM.

Java

21

Adiante será vista mais pormenorizadamente esta configuração, bem como a Virtual Machine que lhe está associada (KVM) e que será utilizada no desenvolvimento de aplicações para este tipo de plataforma.

3.3.1.2. Perfil Um perfil complementa a configuração acrescentando classes adicionais que disponibilizam funcionalidades apropriadas a um tipo particular de aparelho ou segmento de mercado. Ambas as configurações do J2ME têm um ou mais perfis associados, alguns dos quais podendo até estar dependentes de outros perfis. Os perfis actualmente existentes são os seguintes: Mobile Information Device Profile (MIDP)

Este perfil acrescenta componentes de rede, interface de utilizador e armazenamento ao CLDC. O MIDP é destinado a aparelhos com recursos gráficos e de armazenamento limitados, como é o caso dos telemóveis e, deste modo, disponibiliza um interface de utilizador relativamente simples e funções básicas de rede, baseadas em HTTP 1.1. O MIDP é o perfil mais conhecido e utilizado do J2ME porque é a base para o Java destinado a plataformas móveis (Wireless Java) e é actualmente o único perfil disponível para aparelhos que utilizem o sistema operativo “PalmOS”.

PDA Profile (PDAP)

O PDA Profile é muito similar ao MIDP mas destina-se a PDAs com melhores ecrãs e mais memória disponível do que os telemóveis. O PDAP oferece uma libraria de interface de utilizador mais sofisticada e uma Java API que fornece algumas utilidades do sistema operativo.

Foundation Profile

Este perfil é uma extensão ao CDC que inclui quase todas as librarias do Java 2 versão 1.3. Tal como o seu nome sugere, este perfil destina-se a servir de base à maioria dos outros perfis que estendem o CDC.

Personal Basis e Personal Profile

O Personal Basis Profile acrescenta funcionalidades básicas do interface de utilizador ao Foundation Profile sendo assim destinado a ser utilizado por aparelhos com um interface de utilizador menos sofisticado. Por exemplo, este perfil permite apenas uma única janela activa de cada vez.

Para plataformas que suportem um interface de utilizador mais complexo, é utilizado Personal Profile.


22

RMI Profile

O perfil RMI acrescenta librarias de invocação remota de métodos (Remote Method Invocation) do J2SE ao Foundation Profile.

Game Profile

O Game Profile que se encontra ainda em desenvolvimento, vai disponibilizar uma plataforma para o desenvolvimento de jogos em aparelhos com configuração CDC.

Para o desenvolvimento de aplicações para telemóveis, será utilizado o perfil MIDP, visto ser este o perfil especialmente desenvolvido para o caso. Note-se porém que já existem outros perfis em desenvolvimento que podem eventualmente substituir o MIDP. Também a rápida evolução deste tipo de tecnologia pode influenciar a escolha de um perfil adequado e é certo que num futuro próximo o MIDP poderá ser substituído por outro perfil que ofereça novas potencialidades. No entanto, para já, para desenvolver aplicações para telemóveis, o MIDP é a solução mais adequada. A figura que se segue ilustra as configurações e os perfis referidos:

Figura 3. 6 - Configurações e Perfis

Java

23

3.3.2 – Connected Limited Device Configuration O CLDC é a base em que são construídos os perfis destinados a pequenos aparelhos móveis como é o caso dos telemóveis ou PDAs de pouca capacidade. A especificação CLDC destina-se a dispositivos com as seguintes características:

• 160 a 512 KB de memória total disponível para a plataforma Java; • Processadores de 16 bits ou 32 bits; • Baixo consumo de energia (alimentação por bateria); • Ligação à rede intermitente e sem fios, com largura da banda

limitada; Estes aparelhos são caracterizados pelos recursos de memória limitados e baixo poder de processamento, o que torna impossível o suporte de uma plataforma Java completa e funcional. No CLDC está especificado um conjunto mínimo de packages e classes, assim como uma JVM com funcionalidades reduzidas que pode ser utilizada tendo em consideração as limitações impostas por este tipo de aparelhos. Seguidamente serão descritas as funcionalidades fornecidas pela VM do CLDC, bem como as principais diferenças entre essa VM e a VM do J2SE. Ao longo deste capítulo serão também vistos alguns packages e classes disponibilizadas pelo CLDC.

3.3.2.1. CLDC Java Virtual Machine As limitações de hardware e software impostas pelo tipo de aparelhos aos quais se destina o CLDC, tornam impraticável o suporte de uma versão completa do JVM ou até mesmo do conjunto das classes suportadas pelo J2SE. Uma aplicação que corre na plataforma Windows, por muito simples que seja (por exemplo uma aplicação do tipo “Hello World”), necessita que cerca de 16 MB de memória sejam alocados. Pelo contrario, os requisitos mínimos para o CLDC são:

• 128 KB de memória ROM, flash, ou qualquer outro tipo não volátil para armazenamento da JVM e librarias de classes constituintes da plataforma CLDC;

• 32 KB de memória volátil para alocação em runtime. Esta memória destina-se a satisfazer os requisitos dinâmicos das aplicações Java que incluem o carregamento de classes e alocação de espaço de pilha para objectos.

Para suportar um ambiente Java com tão poucos recursos, o CLDC define requisitos muito reduzidos para a VM, para a linguagem ou mesmo até para as librarias utilizadas. Além dos requisitos de memória, o CLDC faz algumas assunções acerca da plataforma que o suporta, por exemplo, é assumido que o aparelho tem sempre um ecrã e um mecanismo de input, e não é necessário que haja memória disponível para o armazenamento de aplicações. É assumido que estas questões são da responsabilidade dos fabricantes dos aparelhos.


24

O CLDC limita o número de requisitos para maximizar o número de plataformas em que pode ser implementado. Em termos de ambiente de software, o CLDC assume que o aparelho já possui um sistema operativo capaz de gerir e executar a VM.

Embora o Java suporte programação milti-processo, não é necessário que esta funcionalidade seja suportada ou sequer reconhecida pelo sistema operativo. Por outro lado, a VM tem por obrigação conseguir a simulação de ambiente multi-processo, usando qualquer funcionalidade que lhe seja disponibilizada. A especificação completa do CLDC pode ser encontrada em http://jcp.org/jsr/detail/30.jsp.

3.3.2.2. Virtual Machine e especificações de linguagem A especificação do CLDC define algumas características que a VM tem que ter, descrevendo as partes da especificações da Java Virtual Machine completa e da linguagem Java que não requerem suporte e as partes em que existem limitações ou alterações. A Sun disponibiliza uma VM denominada Kilobyte Virtual Machine que satisfaz os requisitos do CLDC. Contudo, os fabricantes não são obrigados a basear os seus produtos na KVM. Pode ser utilizada qualquer VM que satisfaça os requisitos do CLDC.

Suporte de virgula flutuante

Visto que a maior parte dos processadores englobados pelo CLDC não suporta o uso de operações com virgula flutuante, a VM também não necessita de suportar este tipo de operações. Isto leva às seguintes restrições:

• Variáveis do tipo float ou double, ou arrays de variáveis destes tipos, não podem ser usados ou declarados;

• Constantes do tipo float ou double (ex: 1.5, 354.98, ...) não podem ser usadas;

• Os argumentos dos métodos não podem ser do tipo float ou double;

• Métodos não podem retornar valores do tipo float ou double; • Objectos do tipo Float ou Double não podem ser criados, aliás,

esses métodos nem sequer existem no CLDC;

A Sun não tem uma versão diferente do compilador Java para aplicações CLDC, pelo que é possível usar o compilador normal do J2SE e, assim, usar virgula flutuante e violar as regras acima descritas. No entanto, as classes criadas seriam rejeitadas quando carregadas na Virtual Machine do CLDC, durante a fase de verificação de classes.

Java

25

Omissões de linguagem

Além das restrições de virgula flutuante, existem algumas funcionalidades da linguagem Java que também não estão disponíveis para aplicações CLDC:

• Reflection – O package “java.lang.reflect” assim como todas as funcionalidades de “java.lang.Class” que estão de alguma maneira ligadas ao reflection, não estão disponíveis. Esta restrição é aplicada em parte para poupar memória, mas também porque evita determinar se o código tem ou não privilégios para aceder a estas funcionalidades.

• Weak References – Weak references e o package

“java.lang.ref” não são fornecidos devido à elevada quantidade de memória necessária para a sua implementação.

• Finalização de objectos – A finalização de objectos é de uma

elevada complexidade para a VM e, no entanto, traz muito poucos benefícios. Deste modo, a finalização não está implementada e a classe “java.lang.Object” não tem o método finalize().

• Threads – O CLDC suporta threads mas não permite a

criação de deamons (threads que são terminados quando todos os outros threads na VM terminam), ou grupos de threads.

• Erros e Excepções – O J2SE tem um grande número de

classes que representam erros e excepções. Visto que, em geral, não é esperado que as aplicações Java recuperem deste tipo de condições (excepções derivadas da classe “java.lang.error”), a maioria das classes representativas destes erros não está incluída no CLDC. Quando há uma situação de erro, o próprio aparelho é responsável por tomar as devidas medidas, em vez de enviar o erro para o código da aplicação.

• Interface Nativo do Java – O CLDC não contém a

funcionalidade JNI (Java Native Interface) do J2SE, que permite que código nativo seja invocado por classes Java. O JNI é omitido pois requer muita memória para a sua implementação e, em parte, para proteger aparelhos que usem o CLDC de problemas de segurança causados por código.


26

3.3.2.3. Carregamento de classes No J2SE o carregamento de classes é feito por class loaders, incluindo class loaders, definidos pelas aplicações que podem implementar um conjunto de mecanismos para localizar e carregar classes Java. Pelo contrario, a especificação CLDC requer implementações específicas para conseguir os seus próprios mecanismos de carregamento de classes, que depois não podem ser estendidos ou sobrepostos por código das aplicações, pois isto teria algumas implicações no que diz respeito a segurança. O CLDC especifica que todas as implementações da VM têm que ser capazes de carregar aplicações comprimidas em ficheiros JAR. É sob a forma de ficheiros JAR que a grande maioria das aplicações desenvolvidas para telemóveis se encontra, sendo por isso que esta característica é muito importante. Por isso, é também importante saber a capacidade que cada aparelho disponibiliza para correr ficheiros JAR. No entanto, o CLDC não exclui outros meios dependentes da plataforma de representação ou acesso ao código de aplicações. Este tipo de tarefas seria delegado a software específico, dependente da plataforma e fora do âmbito do CLDC. Cada aparelho pode transformar aplicações apresentadas sob qualquer formato externo, num formato interno que seja mais apropriado ou mais eficiente.

3.3.2.4. Considerações de segurança No J2SE, o modelo de segurança é suficientemente poderoso para permitir que código originário de diferentes fontes, tenha diferentes níveis de privilegio e consequentemente diferentes níveis de acesso aos recursos do sistema. Se por um lado, por defeito, as aplicações instaladas no sistema não têm restrições de acesso, por outro lado uma applet descarregada de um site, opera num ambiente extremamente restrito que não permite o acesso a recursos locais, e apenas um aceso muito limitado à rede. Entre estes extremos, o modelo de segurança permite que os privilégios sejam individualmente atribuídos a uma aplicação ou applet baseados num “nível de segurança”. Código dito “de confiança” pode vir acompanhado de um certificado que assegura a sua proveniência. É possível também o uso de uma assinatura criptográfica que assegure que o código não foi modificado durante o seu percurso desde a origem até ao seu destino.

A VM do CLDC poderia ser usada num dispositivo que não permitisse a instalação de código pelo utilizador e que, por isso mesmo, não necessitaria de uma segurança muito apertada. Poderia também ser utilizado num telemóvel ligado a uma rede que permitisse que aplicações fossem descarregadas directamente, possivelmente provenientes de fontes não seguras. Neste caso estaria sujeita ao mesmo tipo de verificações efectuadas pelo J2SE a applets. Também seria útil a definição de estados intermédios de segurança para código confiável.

Java

27

Infelizmente estes cenários são impraticáveis para a grande maioria dos casos pois a memória e o processamento necessários para a implementação do modelo de segurança do J2SE, verificação de assinaturas criptográficas, verificação de certificados, e principalmente a definição de diversos níveis de segurança estão muito acima dos disponibilizados por este tipo de aparelhos. As funcionalidades de chaves criptográficas e assinaturas só começam a ser possíveis, com o lançamento do MIDP 2.0.

Assim sendo, a VM do CLDC corre as aplicações num ambiente isolado que assegura que o dispositivo no qual a aplicação está a ser executada, não pode ser danificado.

Este tipo de ambiente é conseguido da seguinte forma: Controlo de carregamento de classes

Cada implementação do CLDC é responsável por carregar as suas classes que podem ser provenientes de diversas localizações distintas. Ao contrário do que acontece no J2SE, as aplicações não podem criar os seus próprios class loaders, pelo que não é possível afectar o class loader do sistema ou as classes que este utiliza.

Como consequência desta restrição, o código das aplicações não

pode actualizar as suas próprias versões das hierarquias dos packages Java e “javax.microedition”. Se isto fosse permitido, poderia comprometer a segurança do ambiente onde é corrida a aplicação. Quaisquer classes que estejam incluídas numa aplicação e que se digam fazer parte destes packages serão ignoradas.

Acesso a código nativo

Como já foi referenciado, o CLDC não inclui uma implementação do JNI e, por isso mesmo, não é possível fazer uma ligação dinâmica ao código nativo em tempo de execução, mesmo que esse código pudesse ser instalado como parte de uma aplicação. Como efeito secundário, é impedido o acesso directo a funcionalidades disponibilizadas pelo sistema operativo do aparelho, a não ser que exista para isso um interface Java específico fornecido pelo CLDC ou por um dos seus perfis. Esta restrição impede que o código de uma aplicação aceda a informação contra a vontade do utilizador.

Contudo é possível estender a API disponível para aplicações Java, efectuando uma pré-linkagem de código nativo com a VM, mas esta funcionalidade está apenas disponível para aplicações que corram sobre uma VM desenvolvida de uma forma personalizada, pelo que não constitui um risco genérico.


28

Verificação de classes

O J2SE sempre disponibilizou um verificador de byte codes capaz de verificar a integridade de ficheiros class do Java. Isto assegura que os ficheiros class não põe em risco a segurança do sistema, falhando na aplicação de regras da linguagem Java que normalmente são verificadas e reforçadas pelo compilador, tais como:

• Todas as variáveis devem ser inicializadas antes de serem usadas;

• Aquando da criação de um objecto, o seu construtor deve ser chamado antes de qualquer utilização;

• Cada construtor deve começar com a invocação de um construtor da sua “superclasse” (com a excepção do construtor de java.lang.Object);

• Variáveis locais, instâncias e membros estáticos declarados contendo referências a objectos de um tipo particular, devem conter sempre uma referência a um objecto cujo tipo lhe esteja legalmente associado;

Por defeito a VM do J2SE corre um verificador de byte codes por

todas as classes vindas de fontes externas, mas não pelas classes locais. Em ambientes móveis, é aconselhável fazer a verificação em todo o código, contudo, os algoritmos necessários a este tipo de verificações necessitam de muita memória e poder de processamento, tornando impossível a sua execução neste tipo de aparelhos. Para isso, esta verificação foi dividida em duas etapas:

• É feita uma pré-verificação nos ficheiros class antes de estes serem instalados. Esta operação envolve a parte mais complexa e consumidora de recursos da verificação de código e é feita como parte ou durante a fase de compilação. O resultado desta pré-verificação é guardado nos ficheiros class onde pode ser acedido em tempo de execução.

• A verificação em tempo de execução é efectuada no próprio aparelho. Dependendo da natureza do aparelho, a verificação pode ser feita quando a classe é carregada ou como parte da instalação da aplicação, impedindo assim o código instalado de ser posteriormente modificado. Este passo utiliza a informação guardada pela pré-verificação em conjunto com uma passagem linear pelos byte codes apenas para assegurar que as regras da linguagem foram respeitadas. É um procedimento muito mais rápido do que a pré-verificação e necessita de muito menos recursos.

Java

29

3.3.2.5. Compilar e correr código com KVM Para compilar e correr código utilizando o KVM, é necessário fazer o download de algum software:

• Java 2 SDK (Software Development Kit) ou outro ambiente de desenvolvimento que contenha um compilador Java em linha de comandos;

• O CLDC reference implementation da Sun;

Caso não esteja instalado nenhum Java 2 SDK adequado, pode-se fazer o download em http://java.sun.com/j2se/.

O CLDC reference implementation contém o código fonte e a

documentação da implementação do CLDC da Sun, que corre em Windows, Linux e Solaris, contendo ainda o KVM e as ferramentas a ele associadas na forma executável. Isto pode ser obtido em http://java.sun.com/products/cldc/.

Esta implementação é fornecida sob a forma de um ficheiro executável

apropriado à plataforma em questão, que deve ser descompactado para a directoria conveniente.

Para referir as directorias de instalação do SDK e CLDC, são utilizadas

as seguintes variáveis: %JAVA_HOME% (Windows) ou $JAVA_HOME (Solaris/Linux)

Aqui será indicada a directoria base da instalação do Java 2 SDK. Normalmente, no caso do Windows é “c:\jdk1.3.1”. %CLDC_HOME% (Windows) ou $CLDC_HOME (Solaris/Linux) Aqui será indicada a directoria base de instalação do CLDC Reference Implementation, por exemplo, “c:\CLDC”. O arquivo extrai-se automaticamente para a directoria “j2me_cldc”, abaixo desta localização. %CLDC_PATH% (Windows) ou $CLDC_PATH(Solaris/Linux)

Esta variável refere-se à directoria “bin” dentro da directoria de instalação do CLDC.


30

Exemplo de compilação de uma aplicação Para exemplificar o processo de compilação, vamos supor que temos uma pequena aplicação do tipo “Hello World”, desenvolvida para CLDC, e que a compilação irá ser feita em Windows:

Hello World package ora.ch2; public class HelloWorld{ public static void main(String [] args) { System.out.println(“Hello World”); } }

O primeiro passo é abrir uma linha de comandos e definir a variável PATH com os ficheiros executáveis do Java 2 SDK e CDLC Reference Implementation. PATH=%JAVA_HOME%\bin; %CLDC_PATH%\win32; %PATH% O Segundo passo é compilar o exemplo de código acima, de forma a produzir um ficheiro class. Para simplificar este exemplo, muda-se a directoria de trabalho para “%HelloWorld%\src”, sendo que esta é a directoria onde se encontra o código fonte da aplicação “hello world”.

Em seguida, devem ser introduzidos os seguintes comandos: md tmpclasses javac –bootclasspath %CLDC_PATH%\common\api\classes –d tmpclasses ora\ch2\HelloWorld.java Estes comandos compilam o código fonte “ora\ch2\HelloWorld.java” originando um único ficheiro do tipo class com o nome “tmpclasses\ora\ch2\HelloWorld.class”. O uso da opção “–d” serve para indicar ao compilador que deve colocar o ficheiro class na directoria criada (“tmpclasses”) em vez da mesma directoria onde se encontra o código fonte, como definido por defeito. Isto porque todos os ficheiros class a ser carregados na KVM têm de ser pré-verificados, resultando daí um ficheiro class modificado. Esse ficheiro será utilizado como entrada para a pré-verificação, e o ficheiro de saída será colocado na directoria onde se encontra o código fonte. Também foi utilizada a opção “–bootclasspath” para mudar a localização de onde as classes são carregadas, durante a compilação. O CLDC não contém todos os packages e classes disponíveis para uma aplicação J2SE, por isso, é necessário que o compilador utiliza as librarias do CLDC em vez do J2SE, o que seria feito por defeito.

Java

31

Antes que os ficheiros class sejam utilizados pelo KVM, é necessário fazer uma pré-verificação. Isto pode ser feito usando o comando “preverify” do CLDC. Para pré-verificar um ficheiro class e gravar o ficheiro resultante na mesma directoria do código fonte, é usado o seguinte comando:

preverify –classpath %CLDC_PATH%\common\api\classes; tmpclasses –d . ora.ch2.HelloWorld A opção “–classpath” indica a directoria na qual o comando “preverify” deve procurar os ficheiros class tanto os das librarias como os que irão ser pré-verificados.

A opção “–d” será para indicar a directoria para onde será gravado o ficheiro resultante da pré-verificação.

No caso de uma aplicação consistir em mais do que um ficheiro class, é necessário efectuar uma pré-verificação para cada ficheiro. Existem duas maneiras para executar esta operação: Podem ser listadas todas as classes na linha de comandos: preverify –classpath %CLDC_PATH%\common\api\classes; tmpclasses –d . ora.ch2.HelloWorld ora.ch2.HelloWorld2 Alternativamente, pode ser fornecida a directoria onde se encontram os ficheiros. O comando “preverify” irá percorrer a directoria e verificar todos os ficheiros class, ZIP e JAR: preverify –classpath %CLDC_PATH%\common\api\classes –d . tmpclasses Finalmente, o programa pode ser executado pelo comando “kvm”: kvm –classpath . ora.ch2.HelloWorld Como output, será mostrada a seguinte mensagem: Hello World Note-se que neste caso é apenas necessário indicar a directoria onde se encontra o programa a ser corrido, pois o comando “kvm” já sabe onde se encontram todas as librarias necessárias.


32

3.3.2.6. Librarias de classes do CLDC Como já foi referenciado, o CLDC abrange um largo número de dispositivos que não têm capacidade suficiente para suportar as librarias disponibilizadas pelo J2SE, e porque o CLDC é uma configuração e não um perfil, não pode conter funcionalidades opcionais. Por isso, os packages e as classes contidas no CLDC devem ser adequadas mesmo aos aparelhos que tenham apenas os requisitos mínimos suportados pelo CLDC. A libraria de classes do CLDC é extremamente pequena, contendo apenas um package com funcionalidades específicas do J2ME denominado “javax.microedition.io” e uma selecção de classes dos seguintes packages da especificação J2SE:

• Java.io; • Java.lang; • Java.util;

Todos os perfis e configurações J2ME incluem packages ou classes do

J2SE. Quando J2ME incorpora interfaces de software do J2SE, deve respeitar as seguintes regras:

• Os nomes das classes ou packages deve ser o mesmo sempre que possível;

• A semântica de classes ou métodos, transportados para o J2ME devem ser idênticos aos que tenham o mesmo nome em J2SE;

• Não é possível acrescentar campos do tipo public ou protected ou métodos a uma classe partilhada entre o J2ME e o J2SE;

Por causa destas regras, os packages e classes do J2ME serão sempre

derivados do J2SE. Assim sendo, o comportamento do J2ME será muito similar ao J2SE facilitando a tarefa de aprendizagem aos programadores familiarizados com o Java tradicional.

Não é também permitido às configurações e perfis do J2ME adicionar quaisquer funcionalidades extra aos packages e classes partilhadas com o J2SE, sendo deste modo preservada a compatibilidade com o J2SE.

Seguidamente serão analisados os packages mais importantes do

J2ME.

Java

33

Java.lang O package “java.lang” do CLDC tem apenas cerca de metade das classes da sua versão J2SE e, mesmo assim, algumas das classes implementadas não são versões completas.

• Classe Object – A classe “java.lang.Object” não contém o método “finalize()” visto que a VM não suporta finalização. Também o objecto “clone()” foi removido bem como o interface “java.lang.Clonable”.

• Classes relacionadas com números – Como mencionado anteriormente, o CLDC não suporta operações com virgula flutuante e, como consequência, as classes “java.lang.Float” e “java.lang.Double” foram retiradas. As outras classes numéricas (“Byte”, “Integer”, “Long” e “Short”) estão incluídas, à excepção da sua classe base do J2SE “java.lang.Number”. As classes numéricas são portanto derivadas de Object em vez de Number. Também é de referir que o interface “java.lang.Comparable” não existe no CLDC, pelo que não é possível fazer comparações directas.

• Funcionalidades de Reflection – todos os métodos relacionados com esta funcionalidade foram removidos. É porém possível fazer algumas operações limitadas em classes cujo tipo não é conhecido na altura da compilação, usando métodos como “forName()” ou “newInstance()”.

• Propriedades do sistema – O CLDC define apenas um pequeno conjunto de funcionalidades do sistema, e nenhuma destas está incluída no J2SE. As propriedades que uma implementação deve disponibilizar estão listadas na seguinte tabela: Nome Detalhes Exemplo microedition.configuration Nome da configuração J2ME

suportada e sua versão CLDC-1.0

microedition.encoding A codificação default de caracteres suportada pelo aparelho ISO8859_1

microedition.platform Nome da plataforma ou dispositivo J2ME microedition.profiles Perfis J2ME suportados MIDP-1.0

Tabela 3. 1 - Propriedades do sistema

O valor de uma propriedade específica pode ser obtido usando o método getProperty() (ex: System.getProperty(microedition.profiles)). Visto que o package “java.util” do CLDC não inclui a classe “Properties”, a classe “system” não inclui o método “getProperties()”, não sendo assim possível obter uma lista de todas as propriedades disponíveis. Os fabricantes são livres de incluir propriedades específicas mas as aplicações não as conseguem definir, devido à ausência do método “setProprerty()”. Um dispositivo que suporte um ou mais perfis, deve inclui-los na propriedade “microedition.profiles” e estes definem as suas próprias propriedades automaticamente.

• Classes de sistema e de execução – As classes de execução e de sistema do J2SE fazem operações de mais baixo nível. Devido à natureza dependente de plataforma e às restrições impostas pela VM, algumas funcionalidades destas classes foram removidas, incluindo as seguintes:


34

o Acesso directo às propriedades do sistema usando os métodos “getProperties()”, "setProperty()” e “setProperties()”;

o Métodos que permitam que o standard input, output e error sejam modificados;

o Os métodos que permitem o acesso a librarias de código nativo foram removidas visto que o JNI não é suportado;

o A habilidade para obter referências ou modificar o SecurityManager;

• Threads – O CLDC permite programação multi-thread mesmo que a plataforma base não o permita. Todos os objectos base utilizados pelo J2SE para suportar threads, estão incluídos no CLDC. Contudo não são suportados grupos de threads e algumas funcionalidades da classe thread do J2SE foram omitidas:

o Todos os métodos e construtores relacionados com ThreadGroups foram removidos;

o Os métodos “getName()” e “setName()” não são suportados e, por isso, foram removidos;

o Os métodos “resume()”, “suspend()” e “stop()” foram removidos;

o Os métodos “destroy()”, “interrupt()” e “isInterrupted()” não existem;

o O método “dumpStack()” foi removido; • Erros e excepções

O CLDC suporta a maioria das excepções definidas pelo package “java.lang” do J2SE mas a maioria das classes respeitantes a erros foi removida, deixando apenas as seguintes:

o “java.lang.Error”; o “java.lang.OutOfMemoryError”; o “java.lang.VirtualMachineError”;

java.util O “package java.util” do CLDC contém classes relacionadas com colecções de objectos e com o tratamento de tempo e datas.

• Classes de colecções – O CLDC contém as seguintes classes relacionadas com colecções de objectos:

o “Hashtable”; o “Stack”; o “Enumeration”; o “Vector”;

• Classe Data – Contrariando a complexidade do objecto Data do J2SE, aqui, “Data” é apenas um valor do tipo long que representa uma data e um tempo. Apenas tem construtores que permitem a criação do objecto Data, representando o tempo corrente ou um tempo especificado, um par de métodos que permitem a especificação e obtenção do tempo, e um método “equals()” que possibilita a comparação entre dois objectos do tipo Data.

Java

35

• Classe TimeZone – Esta classe especifica o tempo de uma determinada zona. No CLDC esta classe está muito mais restrita do que no J2SE, suportando apenas GMT e UTC (que, para todos os efeitos, é idêntico ao GMT).

• Classe Callendar – A classe Callendar do CLDC é uma versão simplificada da mesma classe do J2SE, cuja função principal é fazer a conversão de um tempo no formato Data no valor correspondente em termos de anos, meses, dias, horas, minutos e segundos, e vice-versa.

java.io O CLDC disponibiliza apenas uma versão muito limitada do extensivo package java.io do J2SE. As únicas fontes de input ou output que podem ser ligadas a uma fonte real de dados são ByteArrayInputStream e ByteArrayOutputStream. Estas fontes podem ser usadas pare ler de ou escrever para um array de bytes directamente, ou, quando incluídas num DataInputStream ou DataOutputStream servem para armazenamento ou transmissão de tipos de dados primitivos do Java. O acesso a outros tipos de dados é feito através de implementações privadas de InputStream e OutputStream que são obtidas com a invocação de métodos de outras classes. Os métodos openInputStream() e openOutputStream() são bons exemplos desta situação, pois fazem parte do interface StreamConnection que é utilizado para aceder a fontes de dados externas. O package java.io do CLDC também possibilita o input e output de caracteres, associando byte streams com um InputStreamReader ou OutputStreamReader. No entanto, o tipo de codificação de caracteres que pode ser usado com estas classes é dependente da implementação e é necessário que seja uma extensão da codificação do aparelho. Javax.microedition.io Este package, que não é herdado do J2SE, contém uma colecção de interfaces que definem o Generic Connection Framework que se destina a ser usado por perfis baseados em CLDC de forma a fornecer um mecanismo para acesso a recursos de rede e outros recursos que podem ser endereçáveis por nome e podem enviar ou receber dados via InputStream ou OutputStream.

Um exemplo típico é uma página HTML ou um servlet Java que podem ser identificáveis pelo seu Uniform Resource Locator (URL).


36

3.3.3 – O Mobile Information Device Profile e MIDlets O CLDC fornece a base para correr Java em dispositivos que não têm recursos suficientes para suportar uma Virtual Machine completa, com a versão completa dos packages do J2SE. No entanto, é extremamente improvável que um programador alguma vez necessite desenvolver uma aplicação baseada apenas nas APIs disponibilizadas pelo CLDC, visto que estas não contêm nada que permita interacção com utilizadores, armazenamento ou funcionalidades de rede. O CLDC foi desenhado de forma a servir como base em cima da qual um alargado leque de perfis pode assentar e disponibilizar as funcionalidades em falta, de acordo com a classe do dispositivo. O Mobile Information Device Profile (MIDP) é um perfil que se destina a ser utilizado com aparelhos que possuam um interface de utilizador limitado, na forma de um pequeno ecrã, e com alguma capacidade de input. Ao longo deste capítulo será feita uma introdução ao MIDP e serão analisadas algumas das suas características e funcionalidades.

3.3.3.1. MIDP O MIDP é uma versão da plataforma Java baseada no CLDC e na KVM, que se destina a aparelhos que disponham de poucos recursos, principalmente telemóveis. A especificação MIDP pode ser encontrada para download em http://jcp.org/jsr/detail/37.jsp. O MIDP enquadra-se na arquitectura de software de um dispositivo como é demonstrado no seguinte esquema.

Figura 3. 7 - MIDP e MIDlets

Java

37

O software responsável pela implementação do MIDP corre na KVM fornecida pelo CLDC, e disponibiliza serviços adicionais para benefício do código escrito usando APIs do MIDP. Estas aplicações serão denominadas “MIDlets”. Como é mostrado no esquema, as MIDlets podem ser usadas com MIDP, ou directamente com as APIs herdadas do CLDC. As MIDlets não têm acesso à plataforma do sistema operativo, e não o podem fazer sem prescindir da sua portabilidade. Como o JNI não é suportado pela KVM, a única maneira de ter acesso a código nativo da plataforma é através de uma Virtual Machine personalizada. A Sun disponibiliza uma implementação do MIDP que pode ser utilizada com o Windows, o Wireless Toolkit, que contém versões do MIDP para Windows, Solaris e Linux, e um MIDP específico para uso com PDAs baseados em Palm-OS. Normalmente os fabricantes utilizam a implementação da Sun como base para os seus produtos, e acrescentam código adicional para instalação, remoção e gestão de MIDlets que não são portáveis entre aparelhos distintos. Como demonstrado no esquema, o código OEM pode usar uma combinação de serviços MIDP e CLDC, dependendo também da plataforma do sistema. Também algumas partes nucleares do software MIDP são dependentes da plataforma e, por isso, fornecidos pelo fabricante. Normalmente estas partes contêm suporte de rede, componentes de interface de utilizador e código que permite armazenamento persistente.

3.3.3.2. Requisitos de hardware do MIDP Como referido anteriormente, o MIDP destina-se a ser utilizado por pequenos aparelhos com recursos de memória, CPU e display muito limitados.

• Memória – O MIDP inclui muito software que não faz parte da base da plataforma Java e, por isso, requer mais memória do que o mínimo requisitado pelo CLDC. A especificação MIDP requer um mínimo de 128 KB de RAM para armazenamento da sua própria implementação, acima do necessário para o CLDC. Além disso são necessários mais 32 KB disponíveis para o heap do Java que, mesmo assim, se tornam muito limitativos e exigem que um programador tenha muito cuidado na alocação de objectos e tome as medidas possíveis para evitar guardar referências a objectos que já não são necessários, de forma a que o Garbage Collector recupere o espaço da heap o mais rápido possível. O MIDP requer também um mínimo de 8 KB de memória não volátil para ser usada como armazenamento persistente, de forma a que as MIDlets possam manter a informação mesmo que o aparelho seja desligado. Porém não é garantido que esta informação se mantenha no caso de mudanças de bateria.

• Display – Os aparelhos MIDP são caracterizados por terem ecrãs muito pequenos. A especificação requer que um ecrã tenha no mínimo 96 pixels de largura e 54 pixels de altura, e que cada pixel seja aproximadamente quadrado. O ecrã deve suportar no mínimo duas cores (como a maioria dos telemóveis) e pode ir até 65.536 cores (no caso de alguns telemóveis topo de gama).


38

• Dispositivos de input – Embora o MIDP suporte diversos tipos de dispositivos de input, normalmente usados para PDAs, no caso da programação destinada a telemóveis é usado o input mínimo suportado pelo MIDP que permite a um utilizador escrever números de 0 a 9, utilizar setas e um botão de selecção, como demonstra a figura.

• Rede – O MIDP não assume que tenham acesso permanente a uma rede, ou que a rede suporte TCP/IP. No entanto, um fabricante deve incluir no aparelho, pelo menos, uma simulação de suporte de HTTP 1.1.

3.3.3.3. Requisitos de software do MIDP Como o MIDP não é um produto comercial, é esperado que os fabricantes adoptem esta implementação para o seu hardware e software, e desenvolvam código de forma a ligar as potencialidades do código da Sun com o hardware e software do sistema operativo. A implementação do MIDP faz as seguintes assunções acerca das características oferecidas pelo software base do sistema operativo:

• O sistema operativo deve providenciar um ambiente protegido de execução no qual a VM pode correr;

• É necessária alguma forma de suporte de rede. O fabricante deve disponibilizar algum meio de acesso a uma rede, via HTTP 1.1;

Figura 3. 8 - Keypad normal de um telemóvel

Java

39

• O software deve permitir o acesso ao teclado (input) do sistema. O software deve ser capaz de reconhecer eventos relativos a quando uma tecla é pressionada ou solta. O fabricante deve mapear os códigos das teclas de forma a que se obtenham os mesmos resultados em plataformas de hardware diferentes.

• Deve ser possível o acesso ao ecrã do aparelho. O MIDP permite que as MIDlets tratem o ecrã como um array rectangular de pixels, a cada um dos quais deve poder ser atribuída independentemente uma das cores suportadas pelo aparelho.

• A plataforma deve providenciar uma qualquer forma de armazenamento persistente de dados, que não perca a informação quando o aparelho é desligado. Para isto, o MIDP permite o acesso ao nível de registo, sendo portanto necessário que o software anfitrião contenha um interface programático para o seu mecanismo de armazenamento persistente.

3.3.3.4. A plataforma MIDP Esta é a plataforma disponível para as MIDlets, fornecida pelo CLDC em conjunto com uma colecção de packages específicos para o MIDP, sob a hierarquia do package “javax.microedition”. As librarias base, quase não são afectadas pela especificação MIDP. A única alteração é a adição do timer do Java 1.3, ao package “java.util”. A especificação MIDP coloca os seguintes requisitos às librarias base:

• Tal como acontece nos applets, as MIDlets são geridas num ambiente de execução ligeiramente diferente das aplicações. O ponto principal de entrada para uma MIDlet não é o método “main()” da classe “MIDlet”, e não é permitido à MIDlet terminar a execução da VM. De forma a aplicar esta restrição, os métodos “exit()” das classes de sistema e de execução, se invocados, devem lançar a excepção “SecurityException”;

• Em adição às propriedades do sistema definidas pelo CLDC, os aparelhos MIDP devem conter a propriedade “microedition.locale” de modo a reflectir a região onde o aparelho está a operar. Os identificadores do locale estão formados de uma maneira ligeiramente diferente dos usados pelo J2SE: enquanto no J2SE a língua e o país estão separados por um underscore, no MIDP estão separados por um hífen. Esta informação não tem grande utilidade para as MIDlets em geral, e é utilizada principalmente para MIDlets externas, para que possa ser seleccionada a versão mais apropriada conforme a localização do aparelho. Esta informação será portanto interpretada por um agente externo (como um servlet a correr num browser) para este efeito;

• A propriedade do sistema “microedition.profiles” deve conter pelo menos o valor “MIDP-1.0”. No futuro, à medida que novas especificações do MIDP forem lançadas (MIDP 2.0), os dispositivos que suportem diversos perfis devem lista-los a todos, separando os seus nomes com espaços;


40

3.3.3.5. MIDlets e MIDlet suites Aplicações Java que corram em aparelhos MIDP, são conhecidas como MIDlets. Uma MIDlet consiste em pelo menos uma classe Java derivada da classe abstracta do MIDP “javax.microedition.midlet.MIDlet”. As MIDlets correm num ambiente de execução com uma Java VM que fornece ciclos de vida controlados e bem definidos via métodos da classe “MIDlet” que cada MIDlet deve implementar. Uma MIDlet pode também utilizar métodos da classe “MIDlet” para obter acesso a serviços do seu ambiente e, para manter a portabilidade, deve apenas usar APIs definidos na especificação do MIDP. Um conjunto de MIDlets relacionadas, pode ser agrupado numa MIDlet suite. Todas as MIDlets pertencentes a uma suite são incluídas num package e posteriormente instaladas num aparelho como uma entidade única, podendo apenas ser removidas também em conjunto. As MIDlets numa suite partilham os recursos estáticos e de execução do seu ambiente, da seguinte forma:

• Em runtime, se um aparelho suporta concorrência entre MIDlets, todas as MIDlets de uma suite correm na mesma Java VM partilhando as mesmas instâncias das classes Java e outros recursos carregados na Java VM. Entre outras coisas, isto quer dizer que pode haver partilha de dados entre MIDlets e que as primitivas de sincronização do Java podem ser usadas para proteger não só acessos concorrentes de uma MIDlet, mas também execução concorrente de MIDlets da mesma suite.

• O armazenamento persistente de dados nestes aparelhos é gerido pela MIDlet ao nível da suite. As MIDlets podem aceder aos seus próprios dados persistentes, bem como aos dados persistentes de MIDlets da mesma suite. No entanto não é possível a uma MIDlet obter acesso a dados persistentes pertencentes a MIDlets de outras suites, porque o mecanismo utilizado para identificação dos dados inclui implicitamente a MIDlet suite. Isto é em parte para evitar conflitos de nome entre MIDlets de fontes distintas e, por outro lado, é uma medida de segurança para que os dados de uma MIDlet não possam ser lidos ou corrompidos por código importado de uma fonte não segura.

Como exemplo de partilha de classes e dados entre MIDlets, vamos

supor que uma MIDlet suite contém uma classe chamada “Counter”, destinada a contar o número de instâncias de MIDlets daquela suite que se encontram a correr num dado momento.

Java

41

Counter public class Counter { private static int instances; public static synchronized void increment (){ instances ++; } public static synchronized void decrement (){ instances --; } public static int getInstances(){ return instances; } } Apenas uma única instância da classe será carregada na Java VM,

independentemente da quantidade de MIDlets daquela suite que estão a correr na VM. Isto quer dizer que a mesma variável estática instances é usada para todas as MIDlets e, consequentemente, os métodos increment e decrement afectam o mesmo contador. O facto destes métodos estarem sincronizados protege a variável instances de acessos concorrentes por quaisquer threads em todas as MIDlets.

3.3.3.6. Segurança nas MIDlets Para o programador, é extremamente simples lidar com a segurança nas MIDlets, pelo simples facto de não haver praticamente nenhuma! O modelo de segurança usado no J2SE é poderoso e flexível mas muito dispendioso em termos de recursos de memória e requer uma certa quantidade de funcionalidades administrativas que estão muito para além do esperado, quando se fala em telemóveis. Devido a isto, nem o CLDC nem o MIDP incluem qualquer verificação de segurança nas chamadas aos APIs com a excepção dos métodos de “Runtime” e “System exit” que, por sua vez, não podem ser utilizados por uma MIDlet. Para um normal utilizador, isto pode querer dizer que uma MIDlet é mais insegura para o telemóvel do que uma applet para o browser, visto que a MIDlet não está constrangida ao mesmo ambiente limitado de programação imposto pelo browser a uma applet através do “SecurityManager”. Um utilizador deste tipo de aparelho, deve ter cuidado ao instalar MIDlets e, de preferência, deve aceitar software vindo apenas de fontes confiáveis. Infelizmente até há muito pouco tempo não havia maneira se saber ao certo quem está a fornecer a MIDlet ou se a MIDlet não foi corrompida durante a transferência. Mecanismos de autenticação que disponibilizam estas funcionalidades no J2SE (como chaves criptográficas ou certificados), fazem apenas parte da especificação MIDP 2.0.


42

A alternativa segura do protocolo HTTP (HTTPS) que poderá ajudar a aliviar este problema, está também incluída na versão 2.0 do MIDP, mas enquanto isso não acontecia, a segurança nas MIDlets ficava muito limitada. O facto de não ser permitido à API das MIDlets aceder a informação pessoal do telemóvel (como listas de telefone ou agenda) e não ser possível à MIDlet controlar directamente o aparelho, faz com que o problema da segurança seja um pouco menos preocupante.

3.3.3.7. MIDlet packaging Antes de instalados no aparelho, as MIDlets devem ser acomodadas em “pacotes” de informação, numa operação designada aqui por packaging. A subclasse “MIDlet” que funciona como ponto de entrada para a MIDlet assim como quaisquer outras classes necessárias (à excepção das classes do MIDP), imagens e outros ficheiros acedidos em tempo de execução, devem ser inseridos num único ficheiro JAR. A informação do packaging que informa o aparelho acerca do conteúdo do ficheiro JAR deve estar contida no ficheiro de manifesto do JAR. Informação muito similar a esta deve também estar contida num ficheiro denominado Java Aplication Descriptor (JAD) que é independente do JAR.

Um ficheiro JAR pode conter mais do que uma MIDlet mas, neste caso, as MIDlets devem pertencer à mesma suite, por outras palavras, todas as MIDlets pertencentes à mesma suite devem ser acondicionadas no mesmo ficheiro JAR.

Tanto o ficheiro de manifesto do JAR como o JAD, são ficheiros de texto

simples que, em cada linha, têm informação do tipo: nome_do_atributo: valor_do_atributo O valor_do_atributo é separado do nome_do_atributo por dois pontos e,

opcionalmente, por um espaço. Todos os atributos que têm alguma relevância para a instalação das MIDlets, devem ter nomes com o prefixo “MIDlet-”. Seguidamente irá ser mostrada uma lista de todos estes atributos, assim como uma breve descrição. Os valores das colunas JAR e JAD indicam se o atributo associado é obrigatório (O), facultativo (F) ou ignorado (I).

Java

43

Nome do atributo JAR JAD Valor e significado

MIDlet-Name O O O nome da MIDlet suite contida no ficheiro JAR. Esta informação pode ser visualizada pelo utilizador.

MIDlet-Version O O A versão da MIDlet suite contida no JAR, na forma 1.2.3

MIDlet-Vendor O O O nome de quem forneceu a MIDlet suite. Este atributo está sob a forma de texto e serve para visualização do utilizador.

MIDlet-n O I

Atributos que descrevem as MIDlets da MIDlet suite. O n é substituído por um valor numérico a começar em 1 para identificar individualmente as MIDlets.

MicroEdition-Profile O I

A versão ou versões da especificação MIDP suportadas pelas MIDlets contidas na MIDlet suite. As versões são comparadas com as listadas na propriedade microedition.profiles do aparelho, para determinar a compatibilidade.

MicroEdition-Configuration O I

A configuração J2ME necessária para as MIDlets desta suite. Este valor é comparado com a propriedade microedition.configuration do aparelho, para determinar a compatibilidade.

MIDlet-Description F F A descrição da MIDlet suite para ser mostrada ao

utilizador.

MIDlet-Icon F F

Um ícone que pode ser usado para representar a MIDlet suite durante ou após a instalação. Este ícone deve ser um ficheiro do tipo PNG (Portable Network Graphics).

MIDlet-Info-URL F F O URL de um ficheiro que contenha informação adicional da MIDlet suite.

MIDlet-Data-Size F F

O valor mínimo de memória de armazenamento persistente necessária para esta MIDlet suite. Este valor está especificado em bytes e refere-se ao espaço para dados usados pela MIDlet suite, e não para a sua instalação e gestão. Se não for dado nenhum valor, é assumido que a MIDlet suite não necessita de nenhum espaço persistente para dados.

MIDlet-JAR-URL I O O URL do ficheiro JAR que contém a MIDlet ou MIDlet suite descrita por estes atributos.

MIDlet-JAR-Size I O O tamanho do ficheiro JAR em bytes.

MIDlet-Install-Notify I F

O URL usado para assinalar o sucesso ou falha da instalação de uma MIDlet, feita a partir de um servidor remoto.

MIDlet-Delete-Confirm I F

A mensagem que aparecerá ao utilizador antes de uma MIDlet ser apagada do aparelho onde foi instalada.

MIDlet-Specific-Attributes F F

Os programadores podem limitar a configuração das MIDlets, incluindo atributos que podem ser recolhidos em tempo de execução.

Tabela 3. 2 - Atributos do MIDlet packaging


44

Como pode ser observado, a maior parte destes atributos deve estar contida no ficheiro de manifesto que pertencente ao ficheiro JAR, e no ficheiro JAD, que é independente. Para se perceber a razão disto, convém perceber a razão da utilização destes dois ficheiros. O ficheiro de manifesto serve para indicar o nome e a versão da MIDlet suite ao aparelho, e especificar quais dos ficheiros class correspondem a MIDlets individuais. No entanto, para aceder a esta informação, o aparelho tem que obter o ficheiro JAR, extrair o manifesto e, só depois disto, pode obter os seus atributos. A informação obtida serve para o utilizador decidir se quer ou não instalar a MIDlet. Mas o ficheiro JAR que contém a MIDlet suite pode ser grande e demorar algum tempo a ser transferido numa rede lenta à qual normalmente os telemóveis têm acesso. Se apenas a informação relativa ao manifesto fosse transferida, iria ser poupado muito tempo na transferência. Para resolver esta questão, muita da informação contida no manifesto do ficheiro JAR, assim como alguma informação extra, foram duplicadas para o ficheiro JAD. Deste modo, em vez de ser transferido todo o ficheiro JAR, o MIDP primeiro vai buscar o ficheiro JAD que é muito mais pequeno e pode ser transferido rapidamente. É então mostrado o conteúdo do ficheiro ao utilizador que então decide se quer ou não descarregar o ficheiro JAR associado. De modo a ser completamente portável, um ficheiro JAD deve ser codificado usando o ISO-8859-1, pois todas as implementações do MIDP devem suportar este tipo de codificação de caracteres. Em execução uma MIDlet pode aceder a ficheiros do JAR usando o método “getResourcesAsStream()” do “java.lang.Class”. Qualquer ficheiro do JAR à excepção dos ficheiros class pode ser acedido desta forma.

3.3.3.8. Ciclo de vida e ambiente de execução das MIDlets Todas as MIDlets são derivadas de da classe abstracta base “javax.microedition.midlet.MIDlet”, que contém métodos chamados pela plataforma MIDP para controlar o ciclo de vida das MIDlets, assim como métodos utilizados pela própria MIDlet para alterar o seu estado. Uma MIDlet tem que ter um construtor público que não necessite de argumentos, e que pode ser criado pelo programador caso haja necessidade de efectuar alguma inicialização ou, quando não existe nenhum construtor explícito, um construtor vazio é criado automaticamente pelo compilador Java. Uma classe MIDlet pode ter por base este aspecto:

Java

45

Classe MyMIDlet public class MyMidlet extends MIDlet { // constructor opcional MyMIDlet(){ } protected void startApp() throws MIDletStateChangedException{ } protected void pauseApp(){ } protected void destroyApp(Boolean unconditional) throws MIDletStateChangedException{ } }

A qualquer altura uma MIDlet pode-se encontrar num dos seguintes três estados: parado, activo ou destruído. A figura seguinte demonstra como estes três estados se relacionam entre si.

Figura 3. 9 - Ciclo de vida de uma MIDlet


46

Quando uma MIDlet é carregada, fica inicialmente parada e é nesta altura que são feitas as inicializações das suas classes e instâncias. Se é lançada alguma excepção pela MIDlet durante a execução do seu construtor, a MIDlet é destruída, terminando assim a sua execução. Caso contrário, a MIDlet poderá ser executada mais tarde. O seu estado muda de paused para active (activo) e é chamado o método “startApp()”. Este método é declarado do seguinte modo: protected void startApp()throws MIDletStateChangeException O facto deste método ser abstracto, quer dizer que tem que ser implementado na MIDlet, e o facto de ser protected implica que possa apenas ser chamado a partir da própria classe MIDlet ou de outras classes do package “javax.microedition.midlet”. Na implementação, os métodos referentes ao ciclo de vida da MIDlet são chamados a partir de uma classe deste package denominada “Scheduler”, mas não há nada na especificação do MIDP que obrigue ao uso desta classe. É muito usual os programadores de MIDlets redefinirem o método “startApp()” como público, que é uma opção segura mas desnecessária pois as implementações do fabricante devem continuar a funcionar mesmo que sejam métodos declarados como protected. O método “startApp()” pode iniciar com sucesso, permitindo assim que a MIDlet possa correr, ou pode informar a plataforma MIDP de que a MIDlet não será corrida a este ponto, o que pode ser causado pelos seguintes motivos:

• Se o método “startApp()” detecta uma condição de erro que o impede de compilar, mas que pode mais tarde deixar de existir, deve ser lançada a excepção “MIDletStateChangeException”. Esta acção coloca a MIDP no estado parado para que possa mais tarde ser feita uma nova tentativa para recomeçar;

• Se o método “startApp()” detecta uma condição de erro cuja recuperação seja improvável, deve ser chamado o método “notifyDestroyed()”;

• Por fim, a MIDlet pode lançar uma excepção diferente de “MIDletStateChangeException” deliberadamente, porque foi lançada por um método invocado, e o método “startApp()” não a apanha. Neste caso é assumido que ocorreu um erro fatal e a MIDlet é destruída, com a invocação do método “destroyApp()”;

Se não ocorrer nenhum destes casos, a MIDlet encontrar-se-á no estado

activo e irá correr até que seja parada ou destruída. Depois de completado o método “StartApp()”, a MIDlet retorna e não

existe nenhum método ao qual possa ser passado o controlo da aplicação. Normalmente a MIDlet tem um interface de utilizador que executa código como resultado de eventos gerados pelas teclas do aparelho. As MIDlets podem também iniciar threads em background para correr código que não dependa do interface de utilizador, ou podem utilizar um temporizador (timer) para executar tarefas periodicamente. Caso seja utilizado algum destes métodos, é importante uma gestão adequada dos threads de background ou temporizador, quando a MIDlet é parada ou destruída.

Java

47

A qualquer altura, a plataforma MIDP pode parar a MIDlet. Num telemóvel isto pode acontecer quando é detectada uma chamada e o ecrã tem que ser libertado para que a chamada possa ser atendida. Para parar uma MIDlet é chamado o método “pauseApp()”: protected abstract void pauseApp(); Tal como acontece com o “startApp()”, o MIDP tem que ter uma implementação para este método. A acção apropriada para a mudança deste estado depende da própria MIDlet mas, geralmente, são libertados todos os recursos e guardado o seu estado corrente para que mais tarde, quando reactivada a MIDlet, o seu estado possa ser carregado. As principais consequências da passagem ao estado parado, é que a MIDlet deixa de ter acesso ao ecrã, os threads criados não são terminados e os temporizadores continuam activos. A MIDlet pode optar por terminar threads ou temporizadores quando parada, mas não é obrigada a isso. Se a plataforma decide reactivar uma MIDlet parada, depois de acabada uma chamada por exemplo, o método “startApp()” é invocado novamente para indicar à MIDlet que esta recuperou o acesso ao ecrã. Por isso, o método “startApp()” deve ser cuidadosamente programado e, se for caso disso, deve mesmo ser distinguida a primeira vez que é corrida a MIDlet das outras chamadas ao método (quando a MIDlet está simplesmente parada), de forma a evitar que os mesmos recursos sejam alocados várias vezes. Claro que isso depende da maneira como foi escrita a MIDlet. Se de cada vez que for parada, a MIDlet libertar todos os seus recursos, é necessário que estes sejam novamente alocados tal como da primeira vez, quando a MIDlet for reiniciada. No entanto, uma MIDlet bem programada irá retomar ao seu estado anterior, em vez de voltar a mostrar o seu ecrã inicial. O facto do método “startApp()” poder ser chamado mais do que uma vez durante o ciclo de vida de uma MIDlet levanta a questão da inicialização ser feita no método ou no construtor. Neste caso, o programador é livre de escolher o local que achar mais indicado para alocar os recursos e preparar o estado da MIDlet. No geral, os recursos libertados no “pauseApp()” devem ser alocados no “startApp()”. Outros recursos podem ser alocados quer no “startApp()” quer no construtor, tendo em atenção que os recursos alocados no “startApp()” não devem ser novamente alocados no ciclo de vida da MIDlet. Uma diferença importante entre o método “startApp()” e o construtor é que, segundo a especificação MIDP, a MIDlet só tem garantido o acesso ao objecto “Display”, que corresponde ao ecrã, a partir do momento em que o “startApp()” é invocado pela primeira vez. Tendo em atenção o que é referido na especificação, qualquer inicialização que envolva objectos do “Display”, não pode ser efectuada no construtor. Uma MIDlet pode recusar a passagem do seu estado parado para activo, lançando a excepção “MIDletStateChangeException” quando o método “startApp()” é chamado.


48

Quando a plataforma quer terminar a MIDlet, chama o método “destroyApp()”: public abstract void destroyApp(boolean unconditional) throws MIDletStateChangeException; No método “destroyApp()”, a MIDlet deve libertar todos os recursos alocados, terminar threads que estejam a correr em background e parar os temporizadores activos. Quando uma MIDlet termina deste modo, o argumento “unconditional” tem o valor true para indicar que a MIDlet não pode impedir a continuação deste processo. Em algumas circunstâncias, pode ser útil dar a opção de não terminar o processo à MIDlet, por exemplo, por causa de dados que ainda não foram guardados. Neste caso, o método “destroyApp()” pode ser invocado com o argumento false, e assim a MIDlet pode indicar se quer continuar, lançando a excepção “MIDletStateChangeException”. O código apresentado a seguir, demonstra como esta técnica pode ser implementada:

MIDlet destroy try{ // Chama o destroyApp para libertar os recursos destroyApp(false); // Tenta destruir a MIDlet notifyDestroyed(); }catch(MIDletStateChangeException ex){ // A MIDlet não quer fechar }

Este código pode ser usado para responder a um botão de saída no interface de utilizador da MIDlet. Logo de início é invocado o método "destroyApp()” da MIDlet directamente, para que os recursos sejam libertados. Se a MIDlet não se encontra num estado apropriado para terminar e é chamado o “destroyApp()” com o argumento false, deve ser lançada a excepção “MIDletStateChangeException”. O código deve então apanhar a excepção lançada e não fazer nada. Por outro lado, se a MIDlet está preparada para terminar, deve prosseguir com o método “destroyApp()” normalmente, sendo então chamado o método “notifyDestroyed()” da MIDlet que diz à plataforma MIDP que a MIDlet quer terminar. Este exemplo também ilustra o uso do método “notifyDestroyed()” que é utilizado por uma MIDlet para terminar voluntariamente. È importante perceber o relacionamento entre os métodos “destroyApp()” e “notifyDestroyed()” e quando são usados:

Java

49

• Quando a MIDlet está a ser terminada pela plataforma, muito provavelmente a pedido do utilizador, o método “destroyApp()” é chamado com o argumento true e a MIDlet é destruída quando o método acaba a sua execução. Neste caso não é necessário que a MIDlet invoque o método ”notifyDestroyed()”;

• Quando a própria MIDlet quer terminar, normalmente porque finalizou a sua execução ou porque o utilizador premiu uma tecla de saída, tem que invocar o método ”notifyDestroyed()” que indica à plataforma que a MIDlet deve ser destruída. Neste caso a plataforma não chama o método ”destroyApp()” da MIDlet, assumindo que essa MIDlet já está preparada para ser terminada. A maioria das MIDlets chama o seu próprio método ”destroyApp()” para fazer uma limpeza antes da invocação do ”notifyDestroyed()”.

Note-se que chamar o ”notifyDestroyed()” é a única maneira de uma

MIDlet terminar voluntariamente. As MIDlets não conseguem terminar invocando métodos de saída do sistema ou de execução, pois será lançada uma excepção de segurança (SecurityException).

Existem mais dois métodos que podem ser usados pela MIDlet de forma

a influenciar o seu ciclo de vida: public final void notifyPaused(); public final void resumeRequest(); O método ”notifyPaused()” informa a plataforma que a MIDlet deseja

transitar para o estado parado. Isto tem o mesmo efeito da invocação do método ”pauseApp()” pela plataforma. Quando a MIDlet chama ”notifyPaused()”, a plataforma não invoca o método ”pauseApp()”, da mesma forma que também não chama o método ”destroyApp()” em resposta ao ”notifyDestroyed()”, porque assume que a MIDlet já se preparou para ser parada. Normalmente a MIDlet precede a invocação do ”notifyPaused()” com uma chamada ao ”pauseApp()” para que sejam tomadas as medidas apropriadas à paragem. O método ”resumeRequest()” é o contrário do ”notifyPaused()”. Este método informa a plataforma de que a MIDlet parada deseja retornar ao seu estado activo. Posteriormente a plataforma pode retomar ao seu estado activo, chamando o método ”startApp()”. O método ”resumeRequest()” é tipicamente chamado por um thread em background ou por um temporizador que fica activo enquanto a MIDlet está parada.


50

4. Alternativas ao J2ME Já muito se falou acerca do mercado dos telemóveis e das aplicações desenvolvidas para esta plataforma, assim como das tecnologias inerentes a esta programação. Até agora foi abordado o Java como a tecnologia principal no que toca a desenvolvimento de aplicações para pequenas plataformas móveis. No entanto, e como pode ser observado no segundo capítulo deste documento, existem também outras tecnologias suportadas por telemóveis e usadas por programadores para desenvolver aplicações robustas e fiáveis, tirando o melhor partido das vantagens que cada linguagem tem para oferecer. Embora já tenham sido referidas muitas das potencialidades do Java, é preciso ter em atenção que grande maioria das aplicações desenvolvidas para telemóveis são jogos e, o Java, não foi originalmente desenvolvido para este tipo específico de aplicações. Quando comparado com algumas plataformas específicas para jogos, a versão 1.0 do MIDP demonstra ter algumas limitações o que torna muito difícil a programação de jogos tecnicamente mais desenvolvidos. O lançamento da versão 2.0 do MIDP veio alterar este cenário aumentando significativamente a potencialidade do J2ME para este tipo de aplicações. O MIDP 2.0 fornece:

• Novas funcionalidades ao nível do interface de utilizador como o controlo do tamanho e layout do ecrã;

• Um melhor suporte de multimédia permitindo ao programador sequências audio no formato WAV e sequências de vídeo;

• Uma API específica para o desenvolvimento de jogos que simplifica a programação e permite um melhor controlo a nível gráfico e de performance;

• Conectividade expandida, com o suporte de HTTPS, datagramas, sockets e comunicação por porta paralela;

• Uma arquitectura push que permite que as MIDlets possam ser registadas antes de activadas, quando um aparelho recebe informação do servidor;

• A funcionalidade Over-The-Air (OTA) que permite controlar a instalação, remoção ou actualização dinâmica de aplicações no telemóvel;

• Um modelo de segurança robusto que protege a rede, as aplicações e a informação do telemóvel;

O MIDP veio assim equilibrar os pratos da balança que começavam a

pesar mais para o lado de outras tecnologias, desenvolvidas objectivamente para o desenvolvimento de jogos.

Mais informações acerca do MIDP 2.0, podem ser encontradas em http://java.sun.com/products/midp/.

Neste capítulo irá ser feita uma pequena abordagem a outras tecnologias existentes no mercado, vocacionadas para este tipo de programação.


52

4.1. Execution Engine (ExEn) O Execution Engine (também conhecido como ExEn), foi desenvolvido pela In-Fusio para combater as limitações impostas pelo MIDP 1.0 do J2ME, no desenvolvimento de jogos. Inicialmente, a In-Fusio tentou ultrapassar essas limitações, trabalhando em conjunto com a SUN, chegando mesmo a apresentar propostas para uma API específica para jogos, para ser incluída no MIDP 2.0. O ExEn é uma linguagem simples, poderosa e está-se a tornar bastante popular para os programadores de jogos. Visto que o ExEn é baseado em Java, nota-se cada vez mais uma aproximação entre o ExEn e o J2ME, aliás, a versão 2 do ExEn, estará em conformidade com o MIDP e CLDC do Java, em questões como interface de utilizador, armazenamento persistente, rede e modelo de aplicação. A In-Fusio promete até que, num futuro próximo, haverá compatibilidade entre o ExEn e a API de jogos do MIDP 2.0. Este motor, assenta também no conceito de Virtual Machine e, neste campo, existem algumas melhorias. Esta VM consegue ser até 30 vezes mais rápida do que uma VM genérica, e necessita de muito pouca memória. Apesar disto, em termos de gráficos e processamento, o ExEn fica um pouco aquém das potencialidades de algumas outras tecnologias existentes. Uma razão importante pela qual muitos programadores escolhem ExEn para programar jogos, é o seu modelo de negócio. Este modelo está dividido em dois níveis: standard e premium. No nível standard (livre de encargos), está incluído o SDK, um emulador, suporte técnico on-line e, mais tarde, a possibilidade de uma transição para o nível premium. Os programadores que atingem este nível passam a ter os seus jogos comercializados pela In-Fusio que os promove directamente nas operadoras que possuem telemóveis que suportam esta tecnologia. As perspectivas de crescimento do Execution Engine são bastante boas. O modelo de negócio muito atractivo para programadores independentes, e o lançamento do ExEn versão 2 com melhorias a nível tecnológico vão motivar o desenvolvimento de jogos para esta plataforma. Em termos de suporte, embora não dê sequer para comparar com o J2SE, o ExEn não está assim tão mau e vão aparecendo cada vez mais telemóveis que suportam este motor. Espera-se que, com a compatibilidade com o MIDP 2.0, o ExEn aumente a sua popularidade. Todas as informações acerca do ExEn, assim como alguns jogos, podem ser encontrados em http://www.in-fusio.com .

Figura 4. 1 - Sagem myG-5 com suporte ExEn

Alternativas ao J2ME

53

4.2. Mophun O Mophun é descrito pelos seus criadores da Synergix como uma “consola de jogos baseada em software”. Embora o desenvolvimento desta plataforma tenha começado no final de 1999, a sua implantação no mercado só se fez notar em novembro de 2002. A sua implementação tardia, aliada ao facto de só existirem três aparelhos que suportam esta tecnologia (Sony Ericsson T300, T310 e T610), levou a que muitos programadores desistissem da ideia de desenvolver aplicações para Mophun. Também as previsões de mercado um pouco irrealistas feitas pelos próprios criadores do Mophun, que punham esta tecnologia a competir na Europa directamente com o líder de mercado (J2ME) em 2003, deram a sugestão de que algo estava mal com esta plataforma e assustaram as operadoras e fabricantes de telemóveis. Tecnicamente falando, o Mophun é muito bom. Testes efectuados por organizações independentes demonstram que o Mophun chega a ter uma performance até 150 vezes maior em comparação com o J2ME. A Synergix acrescenta também que em alguns aparelhos, parte do código da VM é traduzido directamente para código nativo, sendo possível atingir até 90% da capacidade total do aparelho. Outras características técnicas são muito similares ás apresentadas pelo ExEn. Tal como acontece com o J2ME e o ExEn, o Mophun é distribuído livremente. Em alguns aspectos, o modelo de negócio apresentado pela Synergix é parecido com o da In-Fusio: depois de desenvolvido, o jogo é certificado, distribuído e comercializado pela Synergix. No entanto, o facto do mercado não ser muito alargado leva a que muitos programadores optem por uma plataforma teoricamente mais fraca mas mais apelativa, como é o caso do ExEn. O futuro do Mophun é ainda incerto. Só agora é que a Synergix está a conseguir arranjar mais suporte para a sua plataforma. O recente lançamento de um motor 3D para jogos Mophun baseado no sistema operativo Symbian vai alargar em muito o suporte desta tecnologia (para alguns telemóveis Nokia incluindo o N-Gage) e é um ponto a favor que irá influenciar positivamente o seu desenvolvimento. Note-se também que a Synergix lançou recentemente uma versão beta de uma API destinada ao desenvolvimento de jogos em 3D (Mophun 3D) que também traz algumas melhorias a nível sonoro (inclusão do formato WAV) e das librarias 2D. Os aspectos tecnológicos desta plataforma são bastante bons e podem tornar o Mophun num líder de mercado. Agora, tudo depende do seu suporte, aceitação por parte dos programadores e evolução da concorrência (MIDP 2.0, ExEn 2, ...). Outras informações sobre esta plataforma podem ser obtidas em http://www.mophun.com.

Figura 4. 2 - Sony Ericsson T610 com suporte Mophun


54

4.3. Wireless Graphics Engine (WGE) O WGE é a solução lançada pela TTPCom. Embora inicialmente, o WGE fosse apontado como o principal candidato à liderança de mercado no que diz respeito a plataformas de programação para jogos, a falta de suporte por parte dos programadores e fabricantes de telemóveis afectou em muito estas previsões. O WGE é um motor de jogos desenhado para servir de base a aplicações em C++ e Java. O WGE não contém uma Virtual Machine e executa o código compilado. Assim sendo, os jogos e aplicações correm mais rápido e requerem menos memória. O WGE também disponibiliza métodos seguros para executar e descarregar aplicações. É impossível negar que o WGE, de um ponto de vista puramente tecnológico, tem tudo para ganhar. Embora seja um pouco mais lento do que o Mophun, o WGE, entre outras coisas, possui APIs que tornam a programação 2D e 3D muito mais simples (já com funcionalidades pré-desenvolvidas, como detecção de colisões), permite um acesso simplificado a funções de rede e garante um bom suporte sonoro. Tal como acontece com os seus concorrentes directos, o download do SDK é livre de encargos, e o modelo de negocio da TTPCom tenta atrair os programadores, ajudando na venda e distribuição dos jogos. Infelizmente, a falta de suporte por parte dos principais fabricantes de telemóveis, acabou por limitar o sucesso do WGE. Uma grande parte das grandes software houses evitou esta plataforma, o que levou a que pequenas empresas e programadores individuais acabassem por seguir o mesmo caminho. O resultado está à vista: existem apenas pouco mais de 30 jogos disponíveis (o que não é praticamente nada, comparando com uns milhares de jogos disponíveis para J2ME), e muito poucos telemóveis a suportar WGE (para já, apenas 1....). Embora por um lado, a falta de interesse das grandes empresas seja benéfica para os pequenos programadores, fazendo com que um bom jogo seja mais facilmente aceite no mercado, por outro lado, existe um número muito reduzido de consumidores, o que irá diminuir os lucros resultantes da comercialização de jogos. Considerando a forte competição e a fragmentação de mercado que se tem vindo a observar, se a TTPCom não conseguir atrair algumas software houses, vai ser muito difícil obter o apoio dos principais fabricantes de telemóveis. Mas sem o apoio dos fabricantes, também não se consegue atrair software houses... Se a TTPCom não conseguir quebrar este ciclo num futuro próximo, pode-se adivinhar o fim desta plataforma que até demonstra ter algumas potencialidades. O site onde podem ser obtidas todas as informações acerca do WGE é o http://www.9dots.net/index.html.

Figura 4. 3 - Innostream I-1000 com suporte

WGE


55

4.4. Binary Runtime Environment for Wireless (BREW) Esta é a proposta da Qualcomm como sistema para o desenvolvimento de aplicações para telemóveis. O BREW é uma plataforma de execução de aplicações, que podem ser desenvolvidas em Java, C, C++, XML, Flash, etc., e que demonstra ser muito versátil não só para jogos, mas também para outros tipos de aplicações. Esta plataforma é mais rápida em comparação com o J2ME, pois não utiliza o conceito de Virtual Machine, correndo ao nível do firmware, apoiada no chipset CDMA (Code Division Multiple Access), também desenvolvido pela Qualcomm. Por outro lado, existe uma limitação de portabilidade, causada pela dependência do CDMA. O BREW fica dependente deste chipset e, assim sendo, é mais difícil alargar esta tecnologia a novos telemóveis. Também a distribuição de programas do BREW é um pouco diferente do habitual. O BDS (BREW Distribuition System) permite que os utilizadores descarreguem aplicações BREW para os seus telemóveis. É através deste sistema que são tratados todos os assuntos relativos à distribuição e cobrança, assim como pagamentos a programadores. No entanto, todas as aplicações BREW têm que ser certificadas pela Qualcomm, antes de descarregadas para um telemóvel. Se por um lado, esta certificação serve para garantir a segurança para o utilizador e, ao mesmo tempo, assegurar o reconhecimento dos programadores, por outro lado alguns programadores podem ver este sistema como um entrave à distribuição livre de aplicações. Apesar das vantagens a nível tecnológico apresentadas pelo BREW, esta tecnologia possui algumas limitações de memória que se podem revelar bastante problemáticas. A ausência de um Garbage Collector para gestão de memória vai agravar esta situação. Além disso, nota-se ainda alguma falta de documentação para os programadores que optam por desenvolver aplicações para esta plataforma. O BREW e o J2ME são parecidos em muitos aspectos, e talvez por isso, e para aumentar a popularidade do BREW, a Qualcomm lançou uma implementação da Virtual Machine do J2ME. Deste modo, embora com alguns requisitos extra de memória e processamento, torna-se possível correr aplicações J2ME sobre BREW. Esta tecnologia, embora não tenha a popularidade doutras plataformas, tem já alguns seguidores e um número razoável de suporte quer ao nível de software, quer a nível fabricantes de telemóveis, e o lançamento da VM para o J2ME de certo que será mais uma vantagem. Qualquer informação acerca do BREW, pode ser encontrada no site oficial da Qualcomm: http://www.qualcomm.com/brew.

Figura 4. 4 - Samsung SCH-A530 com suporte BREW


56

4.5. Symbian OS O Symbian OS é um sistema operativo destinado a plataformas móveis mais avançadas e, no caso dos telemóveis, só os modelos topo de gama que possuem mais capacidade de memória e processamento é que contêm Symbian.

Embora a linguagem nativa do Symbian seja o C++, esta plataforma também suporta Java e Visual Basic.

A grande vantagem do Symbian é a capacidade de desenvolvimento de aplicações mais complexas, tirando partido de sistemas tecnologicamente mais avançados.

O Symbian permite ao programador um controlo total do telemóvel, pois tem acesso ao código nativo da máquina. Deste modo, é possível utilizar directamente uma câmara digital incorporada, bluetooth, infra vermelhos, ou até mesmo fazer chamadas telefónicas. Isto pode ser muito atractivo para os programadores mas, existem também algumas questões ao nível da segurança.

Ao contrario do que acontece com o J2ME, no Symbian não existe um ambiente isolado para execução de aplicações e, por isso mesmo, uma aplicação vinda de uma fonte não segura, pode maliciosamente danificar o aparelho, interferindo com a sua memória, espaço de armazenamento ou dispositivos associados.

Outra desvantagem é a questão da portabilidade. Devido ao facto de ser possível o acesso a funcionalidades específicas do hardware do telemóvel e à grande diversidade das tecnologias móveis existentes, é muito comum ser necessário reprogramar algumas partes do sistema operativo Symbian para que este possa funcionar correctamente noutros aparelhos.

Embora com mais capacidades e mais rápida, a linguagem C++ torna-se mais difícil de programar do que o Java. As aplicações para esta plataforma, tendem a ser maiores, necessitar de mais memória e poder de processamento, e demoram mais tempo a ser desenvolvidas. No caso particular do Symbian, as aplicações devem ter uma especial atenção à gestão de memória para que sejam mais robustas e fiáveis. Também o custo associado ao desenvolvimento destas aplicações tende a ser mais elevado.

Existe já um número razoável de telemóveis com suporte Symbian, alguns dos quais, de fabricantes bastante conceituados, como é o caso da Nokia (3650, 7650, ...). Uma grande parte dos telemóveis com suporte Symbian, também suporta J2ME. Usualmente, as aplicações desenvolvidas para Symbian são aplicações que necessitam de mais poder de processamento e memória, o que dificulta a sua programação em J2ME (aplicações em 3D, por exemplo).

O Symbian está actualmente em crescimento e terá certamente uma crescente importância com a evolução tecnológica que se tem vindo a notar. A sua inclusão em telemóveis como o N-Gage da Nokia, revela o seu estatuto de “linguagem com potencial” visto que os jogos comercializados em cartucho para esta consola, serão programados em C++.

O site oficial é http://www.symbian.com.

Figura 4. 5 - Nokia 3650 com Symbian OS

v6.1


57

Estas são algumas das alternativas ao J2ME existentes actualmente no mercado. Pode-se prever que, num futuro próximo, mais plataformas destinadas aos telefones móveis aparecerão no mercado, lançadas por grandes empresas. Mesmo a Microsoft prometeu já entrar na corrida com o seu Stinger, destinado possivelmente à gama mais alta de telemóveis.

Neste já grande mercado dos telemóveis, é preciso ter em atenção o tipo de aplicações que têm maior importância – Jogos.

Uma boa plataforma de programação de aplicações para este tipo de aparelhos, tem que ter um bom suporte para Jogos, visto que a grande maioria dos programadores se interessa mais por esse tipo de aplicações e, ao mesmo tempo, os consumidores querem passar o seu tempo livre a jogar. Os jogos são por isso aplicações mais vendáveis e, consequentemente, de grande importância actualmente.

Outro ponto de grande importância é o suporte disponível para as plataformas existentes. Existem muito boas plataformas no mercado que , por uma ou por outra razão, não tiveram o suporte dos programadores ou dos fabricantes (veja-se o caso do WGE) e, só por causa disso, podem não ter o sucesso merecido.

Nesta guerra das plataformas para telemóveis, o J2ME vai muito à

frente, principalmente por causa do elevado número de telemóveis que suportam esta tecnologia e enorme quantidade de software (jogos) existentes para download.

Os programadores tendem a escolher uma plataforma que, embora mais fraca do que algumas outras concorrentes, tem um suporte muito mais elevado o que, logicamente, é uma potencial razão para o aumento das vendas e lucros. Por outro lado, os fabricantes têm vantagens em incluir nos seus telemóveis uma plataforma que é utilizada pela maioria dos programadores. É um ciclo vicioso actualmente favorável ao J2ME.

Algumas outras plataformas tentam sobreviver neste meio e optam por suportar software desenvolvido para o J2ME, o que acaba por beneficiar programadores, fabricantes e consumidores.

No futuro, tudo depende da evolução tecnológica de cada plataforma e da sua aceitação no mercado.

Para já, o J2ME tem grandes vantagens a seu favor conseguidas não só pela grande portabilidade e suporte por parte da grande maioria dos telemóveis existentes e marcas lideres de mercado, mas também pelo recente lançamento do MIDP 2.0 que relança o J2ME na competição com outras plataformas teoricamente mais avançadas.

Também a inclusão desta plataforma, no N-Gage que se anuncia já como a consola portátil da Nokia, vai motivar muitos programadores e leva a supor que esta plataforma continuará a evoluir sempre com o intuito de acompanhar outras tecnologias concorrentes.

Pode-se portanto concluir que, embora não seja a mais evoluída, a plataforma J2ME é de facto a mais utilizada e suportada, merecendo por isso uma maior atenção por parte dos programadores de telemóveis.


58

5. Questões fundamentais ao desenvolvimento para telemóveis

Os telemóveis são plataformas onde podem ser corridos diversos tipos de programas, mas são muito diferentes dos habituais computadores pessoais. Um programador que tencione desenvolver uma aplicação destinada a este tipo de plataforma móvel, deve ter em consideração diversos aspectos que são característicos dos telemóveis e, na maior parte dos casos, são muito limitativos para as próprias aplicações.

5.1. Memória • Espaço para aplicações – Estes aparelhos têm uma memória muito

reduzida, pelo que as aplicações devem ocupar pouco espaço e, por isso, todas as funcionalidades que se considerem desnecessárias devem ser retiradas. Também se deve ter um cuidado especial ao guardar informação referente à aplicação, como opções do utilizador, estado da aplicação ou pontuações.

• Memória de runtime – A memória disponível para correr aplicações é também muito reduzida. De modo a minimizar a utilização deste tipo de memória, deve ser minimizada a utilização de objectos complexos e feita reutilização de código (variáveis, objectos, etc.). A declaração e inicialização de objectos que não são estritamente necessários irá resultar num desperdício de memória.

Os objectos devem ser alocados apenas à medida que são necessários e, logo que possível, devem ser libertados, colocando as suas referências a null.

Embora a função do Garbage Collector seja gerir a memória convenientemente, muitas vezes pode ser mais eficaz que um programador faça essa gestão directamente.

Excepções ocupam memória, pelo que devem ser evitadas.

5.2. Processador • Programas simplificados – Estas plataformas têm um baixo poder

de processamento. As aplicações devem ser simples, de forma a ficarem mais rápidas e robustas.

Funcionalidades adicionais devem ser separadas ou convertidas em aplicações secundárias para reduzir o processamento extra.

• Variáveis locais – É mais rápido aceder a classes locais do que a membros de classes.

• Concatenação de strings – A concatenação de strings diminui a performance e aumenta o consumo de memória da aplicação e, portanto, deve ser evitada.


60

• Threads e sincronização – Qualquer operação que dure mais do que um décimo de segundo, requer um thread para a sua realização.

Evitar a sincronização entre threads pode aumentar a performance.

• MVC – Pode ser usado o Model View Controller para separar a lógica, do código responsável pela apresentação.

• Design – A aplicação deve ser cuidadosamente desenhada e codificada de forma a não ter redundâncias de código e ciclos mais pequenos (e se possível poucos).

O modo de programar influência muito a performance (tempo de processamento) e o tamanho da aplicação.

5.3. Display • Cores – Deve-se ter em atenção o número de cores a utilizar para

uma aplicação, visto que variam muito entre os diferentes tipos de telemóveis existentes. Actualmente são suportadas entre 2 a 56.536 cores.

No caso de programação para aparelhos a cores, embora o uso das 56.536 cores seja mais apelativo, é aconselhável o uso de 4.096 cores para uma maior compatibilidade.

• Resolução – Tal como acontece com as cores, são suportadas diversas resoluções entre os telemóveis. É preciso ter em atenção a gama de telemóveis à qual se destina a aplicação e, mediante isso, escolher a resolução adequada. Se é pretendida uma maior compatibilidade, o facto de actualmente não existir nenhuma resolução standard, vai dificultar essa tarefa. No caso de se permitir que uma aplicação esteja adequada a várias resoluções distintas, é preciso ter cuidado com a memória utilizada e processamento. Provavelmente é melhor desenvolver varias aplicações distintas, adaptadas à resolução de cada aparelho.

• Ecrã – Outro aspecto a ter em atenção é o ecrã. Apesar de existirem muitas resoluções diferentes, o ecrã continua a ser muito pequeno (um ecrã grande tem 208x320 pixels), logo, suportam pouca quantidade de informação. No caso de jogos ou outras aplicações com um ambiente gráfico mais avançado, é necessário ter uma especial atenção à informação que aparece no ecrã ao mesmo tempo, e se essa informação é perceptível para o utilizador.

Note-se que o próprio formato do ecrã difere entre as várias resoluções. Existem ecrãs rectangulares verticais (176x208 – Nokia 3650), rectangulares horizontais (101x80 – Siemens SL55) ou quadrados (128x128 – Nokia 5100).

Questões fundamentais ao desenvolvimento para telemóveis

61

5.4. Som

• Tom – Caso a aplicação necessite de suporte audio, é preciso ver qual a capacidade do aparelho ou aparelhos neste campo. Os telemóveis mais antigos estão limitados a apenas alguns tons sonoros num único canal e, os mais recentes suportam tons polifónicos que utilizam entre 16, 32 ou mais canais distintos. O aumento da qualidade sonora de uma aplicação pode resultar na diminuição da sua compatibilidade.

• Formatos externos – Existem alguns modelos de telemóveis que suportam formatos audio externos como o WAV, MIDI ou outros, o que pode facilitar a composição e instalação de som em aplicações, porém, a questão da compatibilidade mantém-se. Os aparelhos mais antigos não suportam estes formatos.

5.5. Input

• Tipo de input – A maioria dos telemóveis, como dispositivo de input apenas suporta o seu teclado, que é comum a todos. O teclado é constituído por 9 teclas numeradas de 0 a 9, uma tecla “#”, uma tecla “*” e pelo menos uma tecla de selecção. Hoje em dia, existem já muitos telemóveis com teclas direccionais (cima, baixo, esquerda, direita) que também podem ser utilizados para aplicações.

Mais uma vez, por razões de compatibilidade, é necessário ter em atenção a gama de telemóveis a que se destina a aplicação e o teclado que estes possuem.

• Teclado – Um aspecto importante acerca do teclado, é o facto de, na grande maioria dos telemóveis, não ser suportado que mais do que uma tecla seja pressionada ao mesmo tempo. Quando isto acontece, apenas é enviado o código referente à primeira tecla pressionada, ignorando a segunda.

5.6. Segurança

• Sandbox – Quando importados para um telemóvel, o programas correm num ambiente isolado denominado sandbox por razões de segurança. Apesar de ser um bom mecanismo de defesa para o utilizador impedindo que possam ser causados danos no telemóvel, pode ser também um factor limitativo para o programador. No J2ME as aplicações não têm acesso ao sistema operativo do telemóvel nem ás suas funções base de código nativo.

• Falta de segurança – A falta de suporte de segurança por parte do J2ME sempre foi um factor importante. Embora de um modo geral, o ambiente sandbox seja o suficiente, o facto de algumas aplicações poderem não ser consideradas seguras, pode levar a que os utilizadores não as descarreguem para o telemóvel.


62

5.7. Funcionalidade • Funcionalidades do telemóvel – É sempre importante conhecer as

funcionalidades contidas no telemóvel ou gama de telemóveis para os quais se pretende programar. Alguns modelos de telemóveis possuem funcionalidades interessantes como bluetooth, câmara digital, MP3, toque por vibração (muito utilizado em jogos), etc., que podem ser úteis para o desenvolvimento de uma determinada aplicação. Outro aspecto importante é saber como aceder ou até mesmo se é possível aceder a estas funcionalidades.

• Recepção de chamadas – É também importante ter em conta que a principal funcionalidade de um telemóvel é efectuar e receber chamadas. Quando é recebida uma chamada, o telemóvel interrompe a aplicação para que a chamada possa ser atendida e, estes casos têm que estar previstos pelo programador. É necessário guardar as informações do estado da aplicação para que, após finalizada a conversação, a aplicação possa ser retomada a partir do ponto onde foi interrompida.

5.8 – Instalação

• Net – Na grande maioria dos casos, a instalação de aplicações é feita via internet através de um download de fontes que muitas vazes não são consideradas seguras. É importante disponibilizar toda a informação possível acerca da aplicação para que o consumidor (e possível comprador) se sinta seguro e faça o download da aplicação pretendida.

• Tamanho – Aplicações mais pequenas requerem um menor tempo de download e instalação e ocupam menos espaço no telemóvel. Isto pode ser um factor decisivo na escolha (ou não) de uma determinada aplicação por parte do utilizador. Aplicações muito grandes, demoram muito tempo a percorrer a rede ainda lenta, suportada pelos telemóveis e, ocupam demasiado espaço no telemóvel, por isso, geralmente o utilizador prefere duas aplicações pequenas a uma aplicação grande.

6. Ferramentas para o desenvolvimento de aplicações

Para iniciar o desenvolvimento de aplicações destinadas a telemóveis, são necessárias algumas ferramentas que podem ser facilmente obtidas. Este tipo de programação requer as seguintes ferramentas:

• J2SE SDK; • J2ME Wireless Toolkit; • Editor Java;

Tudo o que é necessário para desenvolver aplicações em J2ME para

telemóveis, encontra-se incluído nestas ferramentas, que irão ser abordadas em seguida mais pormenorizadamente.

6.1. J2SE SDK O Software Development Kit do J2SE, contém tudo o que é necessário para o desenvolvimento de aplicações em Java. Apesar de, no caso dos telemóveis ser utilizada a Micro Edition, todo o código desenvolvido e compilado continua a ser Java, pelo que são necessárias todas as funcionalidades base contidas no SDK do J2SE. Entre essas funcionalidades, estão presentes as seguintes:

• Ferramentas de desenvolvimento – Ferramentas e utilidades cuja função é auxiliar o desenvolvimento, execução e debug, assim como alguns programas escritos em Java.

• Ambiente de trabalho - Uma implementação do Java 2 Runtime Environment que inclui uma Virtual Machine, librarias e outros ficheiros de suporte à programação e execução de programas escritos em Java.

• Librarias adicionais – Librarias adicionais e ficheiros de suporte para as ferramentas de desenvolvimento.

• Applets e aplicações exemplo – Exemplos com código fonte, de programas desenvolvidos em Java.

• Ficheiros “header” de C - Ficheiros “header” que suportam programação em código nativo com o Java Native Interface (JNI) e outras funcionalidades da plataforma Java 2.

• Código fonte – Os ficheiros fonte Java para todas as classes que constituem a API do Java 2.

O J2SE SDK é a base na qual se irá apoiar a programação em Java

para telemóveis. Note-se que nas ferramentas de desenvolvimento já está incluída uma VM. No entanto, será mais correcto utilizar a VM que vem incluída no Wireless Toolkit (KVM), pois esta é específica para plataformas móveis, nomeadamente telemóveis. O download do J2SE SDK é gratuito e pode ser feito em http://java.sun.com/j2se/1.4.2/download.html (versão 1.4.2).


64

6.2. J2ME Wireless Toolkit O Wireless Toolkit é a ferramenta mais importante na programação para telemóveis e, por isso, será analisada mais pormenorizadamente. O WTK é uma emulação de um ambiente destinado ao desenvolvimento de aplicações para aparelhos baseados em CLDC que corram com o Mobile Information Device Profile (MIDP). Com a utilização deste toolkit, os programadores podem ter a certeza de que as aplicações desenvolvidas serão compatíveis com quaisquer implementações do CLDC/MIDP, e estarão optimizadas para correr em ambientes muito limitados, equiparáveis aos actuais telemóveis. O J2ME WTK inclui:

• CLDC – Este toolkit inclui a especificação CLDC, destinada à programação para plataformas móveis mais limitadas. No CLDC, está incluída a KVM, que será a Virtual Machine utilizada para esta tipo de aplicações;

• MIDP 2.0 - O WTK também inclui as especificações do MIDP 2.0 que, além das funcionalidades disponibilizadas pela primeira versão do MIDP, traz também algumas melhorias, tais como:

o Uma API específica para jogos; o Melhorias nas capacidades audio; o Possibilidade de criação de componentes personalizados para

forms; o Possibilidade de uso de arrays simples de inteiros, para

manipulação de imagens; o Arquitectura de segurança melhorada, com suporte HTTPS; o MIDlets podem receber ligações da rede;

• Mobile Media API – A MMAPI possibilita o uso de audio, vídeo e outros tipos de multimédia em aparelhos com recursos limitados. Esta funcionalidade aumenta consideravelmente a performance da aplicação, quando são manipulados dados mais “pesados” como é o caso de dados multimédia;

• Wireless Messaging API – Esta API fornece acesso independente de plataforma a recursos de comunicação sem fios. Esta funcionalidade pode ser útil para aplicações que requeiram acesso a informação exterior, ou mesmo na instalação ou actualização de aplicações;

• Emulador – O J2ME WTK inclui um emulador de um telemóvel que permite testar aplicações desenvolvidas em J2ME. Com este emulador é possível testar aplicações num ambiente bastante aproximado do real, sem ser necessário fazer o upload da aplicação para o telemóvel;

• Monitorização – O WTK permite um melhor controlo da execução da aplicação e monitorização da sua performance.

O J2ME WTK é portanto uma “caixa de ferramentas” muito útil para este

tipo de programação, que pode ser facilmente instalado. Em alternativa, podem ser instalados os componentes necessários (CLDC, MIDP 2.0, KVM) separadamente.

Ferramentas para o desenvolvimento de aplicações

65

Após a instalação do WTK, o programador tem acesso a uma série de funcionalidades que serão explicadas de seguida. Essas funcionalidades são:

• Default Device Selection; • Documentation; • KToolbar; • OTA Provisioning; • Preferences; • Run MIDP Application ...; • Utilities;

6.2.1. Default Device Selection Se não for especificado o dispositivo a ser emulado, o Emulador usa o dispositivo default que é aqui indicado.

Figura 6. 1 - Escolha do dispositivo default

Aqui existem quatro opções de dispositivos a ser emulados:

• Default Color Phone – Telemóvel genérico com ecrã a cores; • Default Gray Phone – Telemóvel genérico com ecrã a escala de

cinza; • Media Control Skin – Telemóvel genérico com ecrã a cores e

controlo para reprodução de audio e vídeo; • Qwerty Device – Dispositivo genérico que usa um teclado do estilo

QWERTY;

Muito provavelmente, o dispositivo escolhido por defeito será o telemóvel a cores (Default Color Phone).

6.2.2. Documentation Documentation não é mais do que um documento HTML que contém a documentação necessária para o WTK, assim como alguns links para mais informação útil acerca deste toolkit. Aqui pode ser encontrada toda a informação acerca do modo de funcionamento do J2ME WTK.


66

6.2.3. KToolbar Este é o ponto de entrada para o WTK. A KToolbar é um ambiente de desenvolvimento mínimo, com um interface gráfico (GUI) para compilar e executar aplicações MIDP. A partir desta toolbar, podem ser feitas as seguintes operações:

• Criar novos projectos ou abrir projectos já existentes; • Compilar, correr e fazer debug de MIDlets; • Optimizar aplicações MIDlet; • Agrupar projectos em packages; • Modificar atributos da MIDlet suite;

Ao correr a KToolbar, o programador tem acesso à janela principal:

Figura 6. 2 - Consola principal da KToolbar

Como se pode observar, a navegação pela KToolbar é bastante simples.

O menu file, contém as seguintes opções: • New Project ...; • Open Project...; • Save Console...; • Utilities...; • Exit;


67

New Project Esta opção permite a criação de um novo projecto. Ao seleccionar esta opção, aparecerá uma janela a pedir o nome do projecto e o nome da classe MIDlet principal.

Figura 6. 3 - Criação de um novo projecto

Depois de executada esta operação, irão aparecer na consola os

locais indicados para colocar os ficheiros referentes ao projecto criado. O botão “New Project...” da janela principal, tem o mesmo efeito.

Open Project

Esta opção serve para abrir um projecto já existente. Ao seleccionar esta opção, aparecerá uma janela com a lista de todos os projectos existentes.

Figura 6. 4 - Abrir um projecto existente

O botão “Open Project...” da janela principal, tem o mesmo efeito.

Save Console

Esta opção permite ao programador guardar o conteúdo da consola num ficheiro de texto “txt”.


68

Utilities

Ao seleccionar esta opção, é aberta uma janela onde se podem utilizar algumas funcionalidades referentes ao emulador.

Figura 6. 5 - Consola de utilities

• Clean Database (Database) – O emulador simula um dispositivo cliente com capacidade de armazenamento local, mantendo para isso uma pequena base de dados no computador. Esta funcionalidade limpa a base de dados;

• Open Session (Memory Monitor) – O Memory Monitor mostra ao programador a quantidade de memória que está a ser usada em tempo de execução. O Open Session do Memory Monitor permite ao programador examinar a informação previamente guardada, acerca destes dados;

• Open Session (Network Monitor) – O Network Monitor monitoriza o tráfego de rede gerado pelas aplicações, e protocolos como HTTP, HTTPS, etc. Aqui pode ser acedida informação previamente guardada, acerca destes dados;


69

• Open Session (Profiler) – O Profiler recolhe dados do emulador durante a execução, como tempo de execução de métodos, número de chamadas ou relações hierárquicas. A análise destes dados pode servir para localizar potenciais problemas. O Open Session do Profiler permite ao programador aceder a esta informação.

• Open Console (WMA) – Abre a Wireless Messaging API; • Sign MIDlet (Security) – Abre a consola Sign MIDlet

Suite; • Menage Certeficates (Security) – Abre o Certeficate

Manager;

Wireless Messaging API O WMA serve para testar aplicações que suportem o envio de mensagens SMS (Short Message Service) ou CBS (Cell Broadcast Service). Ao seleccionar esta opção, irá ser apresentada a seguinte consola:

Figura 6. 6 - Consola WMA

Os botões “Send SMS...” e “Send CBS” abrem janelas para o envio de mensagens do tipo SMS e CBS respectivamente. O botão “Clear” limpa a consola e o botão “Exit” fecha a consola.


70

Send SMS

Figura 6. 7 - Envio de mensagem SMS

Esta consola está dividida em duas pastas. A pasta “Text SMS“

destina-se ao envio de mensagens do tipo texto, enquanto a pasta “Binary SMS“ destina-se a ficheiros binários, como imagens, audio, etc..

O botão “Add Unlisted Client...” permite adicionar novos clientes à lista “To Selected Clients”, aos quais será enviada a mensagem.

O campo de texto denominado “Port (Optional)”, é opcional e pode indicar um canal específico de comunicações através do qual será enviada a mensagem. Se nada for indicado, a mensagem será enviada directamente para o dispositivo cliente.

O conteúdo da mensagem será especificado no campo “Message”.

A pasta “Binary SMS”, em vez de um campo de texto para a mensagem, dá a possibilidade do programador escolher um ficheiro que será posteriormente enviado.


71

Send CBS

Figura 6. 8 - Envio de mensagem CBS

Tal como no caso anterior, existem duas pastas, uma destinada

ao envio de mensagens de texto e outra o envio de ficheiros binários. Neste caso, a mesma mensagem será enviada em broadcast para

todos os emuladores que estejam a correr. O programador terá que fornecer um identificador da mensagem

que será especificado no campo “Message Identifier”, e o conteúdo da mensagem que, no caso da pasta “Text CBS” será texto inserido num campo de texto (análogo ao exemplo anterior) e, no caso da pasta “Binary CBS”, terá que ser escolhido um ficheiro a enviar.

Para especificar o ficheiro, pode ser escrita a sua localização no campo “Send the contents of this file:” ou pode ser escolhido directamente, premindo o botão “Browse”.

O botão “Send” envia a mensagem e o botão “Cancel” fecha a consola.


72

Sign MIDlet Suite

O WTK permite o uso de certificados para aumentar a segurança e autenticar quem envia a aplicação. Nesta consola, pode-se assinar aplicações (MIDlets) desenvolvidas, com chaves publicas e privadas afim de aumentar a segurança e confiança dos possíveis utilizadores.

A consola tem o seguinte aspecto:

Figura 6. 9 - Assinatura da MIDlet suite

Do lado esquerdo, a “Alias List” contém uma lista das chaves

disponíveis e, do lado direito são mostrados os conteúdos da chave seleccionada.

O botão “Sign MIDlet Suite...” permite assinar uma MIDlet que será escolhida pelo programador.

O par de chaves atribuído pode ser novo (criado através do botão “New Key Pair...” ) ou importado.

No caso da criação de um novo par de chaves, é pedida alguma informação como nome de identificação (Alias), nome do servidor (Dname:C) e nome da organização (O).

O menu “Action” contém as mesmas opções já referidas, acrescidas da opção “Delete Selection” que permite apagar um determinado par de chaves, e da opção “Exit” que fecha esta consola.

Figura 6. 10 - Novo par de chaves


73

Certeficate Manager Os certificados são usados para verificar a confiança da rede e

das MIDlets assinadas. Se for usado um protocolo de segurança como o HTTPS ou SSL para acesso a um site, o certificado desse site é verificado para comprovar a sua validade, e o certificado da MIDlet também é verificado afim de comprovar se tem permissão para aceder a esse site.

Os certificados podem ser geridos na seguinte consola:

Figura 6. 11 - Gestor de certificados

Do lado esquerdo na “Certificate List” pode-se ver uma lista dos

certificados existentes e, à direita, aparecerão os detalhes acerca do certificado seleccionado.

Uma lista de certificados é guardada num determinado “Keystore”. Caso se pretenda obter um certificado guardado, pode-se abrir uma keystore através do botão “Open Keystore...”. Os certificados também podem ser importados de uma “Certificate Authority”, através do botão “Import Certificate...”.

O menu “File” contém as opções “Open Keystore...” e “Exit” que permite sair da consola.

O menu “Action”, em adição à opção “Import Certificate...”, contém as opções “Import J2SE Certificate” que permite importar certificados da keystore do J2SE, e “Delete Selection” que permite apagar um determinado certificado seleccionado.


74

No menu “Edit” da KToolbar podem ser encontradas algumas opções referentes às configurações desta ferramenta de trabalho. Este menu contém apenas duas opções:

• Preferences...; • Clear Console;

Preferences

Esta opção permite realizar algumas configurações da KToolbar. Ao escolher “preferences”, aparecerá uma consola com várias pastas referentes a diferentes áreas de configuração. Esta consola tem o seguinte aspecto:

Figura 6. 12 - Configuração de rede

No caso do programador pretender que uma aplicação aceda à rede apenas através de um proxy, por exemplo, se o servidor tiver uma firewall, é necessário definir o endereço e a respectiva porta desse proxy, no campo “HTTP”.

Para especificar a informação do proxy para uma ligação HTTPS, deverá ser definido o nome do servidor HTTPS e a sua porta no campo “Security”.

Na área “Http Version” é possível escolher a versão do HTTP que se está a utilizar. Note-se que a especificação MIDP requer a versão 1.1 do HTTP.


75

Figura 6. 13 - Performance

Esta pasta contém as configurações relativas à performance. A barra “Graphics primitives latency” deixa especificar o tempo em

milisegundos entre o pedido efectuado e a apresentação do gráfico no ecrã. O “Display refresh” especifica a maneira como os gráficos serão apresentados. Existem três modos de display:

• Double Buffer – O gráfico é renderizado numa área fora do ecrã e só depois é mostrado;

• Immediate – O gráfico é renderizado directamente no ecrã; • Periodic – Deixa definir a frequência com que o ecrã é

renovado, em frames por segundo. Quando se testa uma MIDlet no emulador, não se consegue obter

uma ideia real da velocidade de execução da aplicação. Num telemóvel, a aplicação será bastante mais lenta. Contudo, é possível tentar aproximar a velocidade simulada à velocidade real, definindo uma velocidade mais lenta para a VM. Isto pode ser feito na barra “Enable VM speed emulation”.

Do mesmo modo se pode proceder quanto à velocidade de transmissão de dados numa rede. Se uma aplicação requer ligação a uma rede, é conveniente testar a performance dessa aplicação quando utilizar uma rede mais lenta, equiparada com as capacidades de um telemóvel. A velocidade de transmissão de dados na rede em bits/seg pode ser definida em “Enable network throughput emulation”.


76

Figura 6. 14 - Monitorização

Na pasta “Monitor” Podem ser escolhidas algumas opções de

monitorização para uma MIDlet. Na área “Memory Monitor” estão contidas algumas opções

relativas à monitorização da memória em uso. “Enable Memory Monitor” permite que, em tempo de execução, seja mostrada uma janela que demonstra a utilização de memória pela aplicação e o “Excessive GC Mode” permite determinar a quantidade de memória necessária. Na janela de monitorização de memória, pode ser guardada a informação para que, mais tarde, possa ser consultada.

A área “Network Monitor” é referente à monitorização de transmissão de dados em rede. Aqui, quando escolhida a opção “Enable Network Monitoring”, é mostrada uma janela em tempo de execução, que demonstra o tráfego na rede. Esta informação também pode ser guardada.

Em “Profiler” pode ser escolhida a opção “Enable Profiling” que, depois de corrida a MIDlet, mostra uma consola que explicita dados referentes à execução da aplicação, tais como tempo de execução de métodos ou número de chamadas efectuadas. De modo a permitir fazer uma análise mais cuidada, é possível guardar esta informação.

Por fim, em “Trace” podem ser escolhidas algumas opções referentes à monitorização de código.


77

A consola pode demonstrar o que se passa a nível do garbage collector, carregamento de classes, excepções ocorridas ou chamadas a métodos. Isto pode ser considerado uma forma muito simples de debug que facilita a detecção de erros de código por parte do programador.

Figura 6. 15 - Armazenamento

A pasta “Storage” contém algumas definições acerca da memória

utilizada. Pode ser especificada a directoria para armazenamento no campo

“Storage Root Directory”. Nessa directoria será criada uma pequena base de dados com a informação armazenada.

Aqui pode também ser definida a memória de pilha a ser utilizada com as MIDlets e a capacidade máxima de armazenamento, em “Heap Size” e “Storage Size” respectivamente.

Por defeito, a memória de pilha está definida para 500 KB mas pode variar entre 32 KB e 64 MB.

Figura 6. 16 - Disponibilidade de APIs

Caso o dispositivo para onde se pretende desenvolver uma aplicação não suporte MMAPI ou WMA, pode-se retirar essa opção nesta pasta. Deste modo, assegura-se que a aplicação não faz uso destas APIs e corre sem problemas no aparelho ao qual é destinada.


78

Figura 6. 17 - WMA

Na pasta WMA existem algumas configurações referentes ao Wireless Messaging API.

A qualquer momento, pode ser útil partir do princípio que o próximo emulador contém um número de telefone específico, afim de testar aplicações que envolvam trocas de mensagens por exemplo. Esse número pode ser definido em “Phone Number of Next Emulator”.

Visto que se está a trabalhar num emulador, também não existe número para um centro de mensagens, pelo que pode ser simulado. Esse número pode ser definido em “SMSC Phone Number”.

Também para aproximar este ambiente da realidade, é possível simular a perda de pacotes de mensagens ou o atraso entre o envio de uma mensagem e a sua recepção (“Random Message Fragment Loss” e “Message Fragment Delivery Delay (ms)” respectivamente).

Figura 6. 18 - MMedia

Na pasta “MMedia” podem ser especificados os formatos (WAV, MIDI ou Vídeo) e outras funcionalidades (misturas de audio, gravação audio, captura vídeo e tons MIDI) que podem ser suportadas pelo aparelho ao qual se destina a aplicação.


79

Deste modo, garante-se que uma aplicação que não utilize estas funcionalidades, é compatível com o telemóvel ao qual se destina.

Figura 6. 19 - Segurança

A pasta “Security” permite definir o nível de confiança que o possuidor de um certificado tem que ter para aceder a uma API protegida, bem como o seu nível de acesso a essa API. No “Security Domain” podem ser definidos quatro tipos de domínios de segurança:

• Untrusted – Uma MIDlet para a qual a origem e a integridade do ficheiro JAR não são de confiança para o aparelho;

• Trusted – Uma MIDlet com um ficheiro JAR assinado e com um certificado que pode ser verificado pelo aparelho;

• Minimum – Um domínio de segurança em que todas as permissões a APIs protegidas são negadas;

• Maximum - Um domínio de segurança em que todas as permissões a APIs protegidas são concedidas;

Clear Console

A opção “Clear Console” limpa a consola. Tem o mesmo efeito que o botão “Clear Console”.

Após a escolha de um projecto, o menu “Project” fica activo, assim como os botões “Settings”, “Build” e “Run”.

No menu “Project” existem as seguintes opções: • Build; • Clean; • Run; • Package

o Create Package; o Create Obfuscated Package;

• Sign; • Run via OTA; • Debug; • Settings;


80

Build A opção “Build” compila e pré-verifica o código desenvolvido. Clean A opção “Clean” apaga todos os ficheiros temporários e ficheiros class da directoria corrente do projecto. Run Esta opção corre o código compilado. Se não for compilado previamente, esta opção chama primeiro a opção “Build”. Quando corrido o código, é chamado automaticamente o emulador (telemóvel) com o programa desenvolvido a correr no ecrã. Package Esta opção cria um ficheiro JAR pronto a ser instalado num aparelho. Neste caso, as classes são compiladas sem qualquer informação de debug para reduzir o tamanho do ficheiro. Dentro desta opção existem dois métodos de criação de ficheiros JAR:

• “Create Package” – Cria um ficheiro JAR “normal”. • “Create Obfuscated Package” – Utiliza métodos externos para

criar um ficheiro JAR mais pequeno.

Sign Abre a consola “Sign MIDlet Suite”. Run via OTA Ao escolher esta opção, é possível correr uma aplicação como se fosse descarregada da internet. Logo de início é corrido o emulador com uma aplicação de gestão de aplicações, a partir da qual é possível instalar a aplicação desenvolvida. Deste modo, é possível simular todo o ambiente móvel para o qual se está a programar, mesmo na fase de download e instalação de uma aplicação via internet. Debug Quando é escolhida esta opção, é pedido o valor da porta TCP/IP que pode ser usada por um debugger externo. Em seguida, é corrida a aplicação em modo debug (com o emulador) e fica à espera da ligação de um debugger externo para que possa prosseguir com a aplicação. Deste modo, é feia uma ligação entre o emulador e um debugger externo, fornecido com a aplicação de desenvolvimento Java.


81

Settings A opção “Settings” permite modificar os atributos da MIDlet.

Figura 6. 20 - Atributos requeridos

A pasta “Required” permite alterar ou definir os atributos

obrigatórios para a MIDlet. No exemplo, foi aberto o projecto “Games” que contém os atributos descritos acima.

Figura 6. 21 - Atributos opcionais

A pasta “Optional” destina-se aos atributos opcionais da MIDlet.

Figura 6. 22 - Atributos definidos pelo utilizador

Aqui são estão os atributos definidos pelo utilizador. Note-se que estes atributos podem ser adicionados ou removidos.


82

Figura 6. 23 - Atributos das MIDlets

Estes atributos referem-se ao posicionamento das MIDlets no

menu principal de escolha. Neste caso, os atributos podem ser adicionados, alterados ou eliminados, podendo também a sua ordem ser alterada.

Figura 6. 24 - Push registry

Nesta pasta é configurado o uso de “push registry” com a MIDlet

desenvolvida. Este mecanismo permite que uma MIDlet seja lançada automaticamente sem qualquer interacção do utilizador e, para que isso seja possível, é necessário que a MIDlet esteja registada no “push registry”.

Aqui, o campo “Key” é gerado automaticamente à medida que se adicionam registos. O “Connection URL” é uma string que identifica o protocolo de ligação e a porta associada, o atributo “Class” é referente ao nome da classe a que pertence a MIDlet e o campo “Allowed Sender” refere-se a uma entidade com permissões para lançar esta MIDlet.

Cada MIDlet pode ter vários registos e, cada um destes registos pode ser adicionado, alterado ou removido.


83

Figura 6. 25 - Permissões

Para funcionar correctamente, pode ser necessário que uma

MIDlet suite aceda a APIs protegidas e, para isso, é necessário obter permissão. Para esse efeito, podem ser editados os atributos “MIDlet Permissions” e “MIDlet Permissions opt” (optional) na pasta “Permissions”.

Para adicionar as permissões, basta clicar no botão “Add” e escolher as APIs a que se pretende dar permissão, entre as que estão listadas.

Também é possível remover permissões, bastando para isso seleccionar a permissão que se pretende remover, e clicar no botão “Remove”.

A opção “Settings” também pode ser acedida através do botão

“Settings” da KToolbar.

O menu “Help” apenas contém uma breve referência aos termos de licença desta aplicação.


84

6.2.4. OTA Provisioning O “OTA Provisioning” fornece um outro tipo de emulação do ambiente em que corre uma aplicação. O simulador é o mesmo. A única diferença é que a aplicação não poderá correr logo directamente no emulador.

Neste caso, não é simulado somente o ambiente de execução, mas sim o modo de funcionamento de um telemóvel que não contém a aplicação que se pretende testar. Assim, além da execução da aplicação, pode ser também testado o seu download e a sua instalação. Em vez de mostrar logo a aplicação, o simulador corre um interface para gestão de aplicações (já existente na maioria dos telemóveis que suportam Java), a partir do qual se terá que descarregar e instalar a aplicação a ser testada. A intenção é tornar o ambiente de execução o mais real possível, não deixando ao acaso nenhuma das partes do desenvolvimento de toda a aplicação. Esta funcionalidade pode também ser acedida a partir da KToolbar através do menu “Project”, seleccionando a opção “Run via OTA”.

6.2.5. Preferences

Este atalho permite ao programador personalizar as configurações da KToolbar, tal como referenciado anteriormente. Estas configurações também podem ser acedidas através do menu “Edit” da KToolbar, seleccionando a opção “Preferences...”.

6.2.6. Run MIDP Application...

Esta é uma maneira fácil e rápida de correr uma aplicação MIDP que já se encontre desenvolvida. Aqui é pedido apenas o nome do ficheiro JAD referente à aplicação, que contém algumas informações necessárias, e é corrida a aplicação no emulador.

Caso a aplicação não contenha um ficheiro JAD associado, este pode ser construído a partir das informações contidas no ficheiro de manifesto do JAR.

Figura 6. 26 - Emulador OTA


85

Por exemplo, vamos supor que temos uma aplicação com o nome “StreetFighter.JAR” e não contém o ficheiro JAD associado. O seu ficheiro de manifesto seria o seguinte:

MANIFEST.MF Manifest-Version: 1.0 MicroEdition-Configuration: CLDC-1.0 MIDlet-Data-Size: 0 MIDlet-Version: 1.0 Created-By: 1.3.1 (Sun Microsystems Inc.) MIDlet-Vendor: JShape Software MicroEdition-Profile: MIDP-1.0 MIDlet-1: msf, , msf MIDlet-Name: msf

O ficheiro JAD daí resultante seria o seguinte:

StreetFighter.JAD MIDlet-Name: msf MIDlet-Vendor: JShape Software MIDlet-Version: 1.0 MIDlet-Jar-URL: mstreetfighter.jar MIDlet-Jar-Size: 34843

Em que:

• MIDlet-Name corresponde ao nome da MIDlet e pode ser retirado do ficheiro de manifesto;

• MIDlet-Vendor corresponde ao fabricante, e pode também ser retirado do ficheiro de manifesto;

• MIDlet-Version corresponde à versão da MIDlet, e também consta do ficheiro de manifesto;

• MIDlet-Jar-URL corresponde ao nome e localização do ficheiro JAR associado. Este parâmetro não está no ficheiro de manifesto mas pode ser facilmente preenchido;

• MIDlet-Jar-Size corresponde ao tamanho do ficheiro JAR. Embora também não esteja no ficheiro de manifesto, esta informação é muito fácil de obter.

Depois de escolhido o ficheiro JAD, é lançado o emulador com a aplicação a correr.


86

6.2.7. Utilities

Aqui podem ser utilizadas algumas funcionalidades relativas ao emulador tal como foi já referido.

Outro modo de aceder a esta consola, é através do menu “File” da KToolbar, seleccionando a opção “Utilities”. A versão 2.0 do J2ME Wireless Toolkit é gratuita e pode ser obtida no site da Sun em http://java.sun.com/products/j2mewtoolkit/download-2_0.html.

6.3. Editor Java Para finalizar, é necessário um editor Java com uma boa ferramenta de

debug e um ambiente de trabalho apropriado. A escolha de um editor é mais a nível pessoal. Cada programador escolhe o editor com que está mais familiarizado, ou que se adapta melhor à sua forma de trabalhar. Existem inúmeras ferramentas deste tipo. Aqui estão alguns exemplos:

• Ultra Edit - http://www.ultraedit.com; • Eclipse - http://www.eclipse.org; • Sun One Studio -

http://developer.java.sun.com/developer/earlyAccess/j2meconwizard; • JBuilder - http://www.borland.com/jbuilder;

A Sun recomenda o Sun One Studio, garantindo que esta ferramenta tem uma óptima interligação com o Wireless Toolkit.

7. Desenvolvimento Antes de iniciar o ciclo de desenvolvimento, é necessário criar uma estrutura de directórios que suporte a construção da MIDlet suite. Note-se que a MIDlet suite é um conjunto de MIDlets que partilham os mesmos recursos. Vamos supor que será desenvolvida uma aplicação com o nome HelloWorld. Em primeiro lugar, será criado um novo projecto através do WTK:

Figura 7. 1 - Criação de um novo projecto

Após clicado o botão “Create Project”, será criada uma nova estrutura de directórios dentro da directoria “WTK20/apps” (directoria base da instalação do WTK. Aí será criada uma directoria com o nome da aplicação que se pretende desenvolver (neste caso “HelloWorld”) e, dentro desta, serão criadas as seguintes sub-directorias:

• bin; • classes; • lib; • res; • src;

Após concluída com sucesso a criação, aparecerá a janela de “Settings”

para que seja inserida mais informação acerca da MIDlet. Alguma informação aparecerá por defeito:

Figura 7. 2 - Janela de settings


88

Depois de concluídas estas operações, aparecerá na consola principal do WTK a seguinte informação:

Figura 7. 3 - Consola principal após a criação de um projecto

Esta informação refere-se à estrutura de directórios criada e indica o local onde devem ser colocados os ficheiros referentes ao projecto:

• Ficheiros de código � HelloWorld/src; • Outros ficheiros necessários à aplicação � HelloWorld/res; • Librarias � HelloWorld/lib;

Agora já é possível passar à codificação de aplicações (MIDlets). O

desenvolvimento de código será feito à parte, num editor de texto ou editor Java, e os ficheiros com código (ficheiros JAVA) serão colocados na directoria “src” do respectivo projecto.

Toda a fase de compilação e pré-verificação será feita no WTK, bastando para isso utilizar a função “Build”.

Em seguida, o código pode ser testado directamente no emulador, utilizando a função “Run”.

No caso de se pretender utilizar a(s) MIDlet(s) desenvolvida(s) num

telemóvel, é necessário realizar mais algumas operações: • Criar um ficheiro de manifesto (MF) – O ficheiro de manifesto do

JAR contém informação importante acerca da aplicação desenvolvida e deve ser criado antes da criação do JAR. Para criar este ficheiro basta editar um ficheiro de texto e proceder segundo as regras já enunciadas.

• Criar um package (JAR) – É possível compactar o código desenvolvido num ficheiro JAR, para que possa ser descarregado para um telemóvel, a partir da função “Package/Create Package” do menu “Project “do WTK.

• Criar um ficheiro descritor (JAD) – Este ficheiro é muito parecido com o ficheiro MF e serve para fornecer informação da aplicação a um possível utilizador sem que este tenha que descarregar toda a aplicação. Este ficheiro também pode ser criado apenas com a edição de um ficheiro de texto.

• Instalação – Por fim, para que uma aplicação possa ser instalada num telemóvel, é necessário que seja inserida num sistema próprio para disponibilizar aplicações, para que depois essa aplicação possa ser descarregada para o telemóvel.

Desenvolvimento

89

7.1. Hello World Para dar uma ideia melhor da programação de uma MIDlet, será demonstrado o código de uma aplicação muito simples: “Hello World”. Hello World import javax.microedition.lcdui.Display; import javax.microedition.lcdui.Displayable; import javax.microedition.lcdui.Form; import javax.microedition.midlet.MIDlet; /*Cria o programa "Hello world" no J2ME MIDP. Note-se que a classe tem que ser publica para que a aplicação de gestão de software do dispositivo a possa instanciar.*/ public class HelloWorld extends MIDlet { //Este componente é mostrado no ecrã. private Form form; //Display. Este objecto controla todos os componentes do display. private Display display; /*É necessário um constructor público, sem argumentos, mesmo que não seja utilizado.*/ public HelloWorld() { super(); } public void destroyApp(boolean destroy) { form = null; notifyDestroyed(); } public void pauseApp() { } public void startApp() { //Cria um novo form para ser mostrado. form = new Form("Hello, World"); // Acrescenta uma string ao form. String msg = "My first MIDlet!"; form.append(msg); //Agora é mostrado o form criado acima. display = Display.getDisplay(this); display.setCurrent(form); } }


90

Esta pequena aplicação, apenas mostra uma frase no ecrã. Depois de pré-verificado e compilado, o código é corrido e obtém-se o seguinte resultado:

Figura 7. 4 - Aplicação Hello World no telemóvel

Aqui aparece o nome da aplicação desenvolvida, pronta a ser chamada. Para correr a MIDlet no telemóvel, basta premir o botão “Launch”. Seria então obtido o seguinte ecrã:

Figura 7. 5 - Resultado da aplicação Hello World

A frase “My first MIDlet” aparecerá no ecrã do telemóvel. Este primeiro exemplo serve de base para iniciar o desenvolvimento de aplicações com esta tecnologia.

Desenvolvimento

91

7.2. Princípios básicos Existem alguns princípios básicos que de devem ter em conta quando se inicia o desenvolvimento de uma aplicação deste género. Em primeiro lugar, é útil relembrar as funcionalidades que estão ao alcance do programador.

Logo de início é possível constatar que se está a trabalhar com uma API relativamente pequena e compacta, constituída por sete packages:

• java.io – Contém classes relativas a dados que, entre outras coisas, são úteis para fazer leituras de fontes externas como imagens ou sons;

• java.lang – Inclui as classes base do Java, derivadas da API do J2SE. Aqui estão as classes mais importantes e a classe Math com funcionalidades reduzidas;

• java.util – Este package é derivado do java.util do J2SE, e contém algumas classes de grande utilidade como Random, Vector, Hashtable e TimerTask;

• java.microedition.io – Este package contém todas as classes e interfaces relativos a funcionalidades de rede;

• java.microedition.lcdui – Este é o package mais poderoso. Aqui estão contidas as classes para operações de alto e baixo nível. Os componentes de alto nível incluem Forms, Lists, TextFields e Commands, e são todos importantes para controlar o input e a navegação do utilizador. Entre os objectos de baixo nível estão o Canvas, Graphics e Image que disponibilizam acções típicas de aplicações com interface gráfico (como jogos), tais como desenhar no ecrã e apanhar instruções do utilizador;

• java.microedition.midlet – Este package define o ponto de entrada e saída para as aplicações MIDP (MIDlets). Aqui está contida a classe MIDlet que é usada pelo AMS (Application Management Software) para controlar o ciclo de vida ou o estado da MIDlet. Todas as MIDlets desenvolvidas têm que ter uma classe que seja uma extensão da classe MIDlet para permitir ao AMS começar e terminar a aplicação;

• java.microedition.rms – O package rms fornece mecanismos para guardar dados de um modo persistente. É muito útil para guardar dados referentes às aplicações, como pontuações ou estados das aplicações. Os elementos básicos de armazenamento são referidos como registos (records) que podem ser lidos através da classe RecordStore;

Tal como mencionado anteriormente, a base e ponto de entrada da

aplicação, é efectivamente a classe ”MIDlet”. Também foi mencionado que o AMS é o software do dispositivo encarregue de gerir o ciclo de vida das aplicações. Quando um utilizador decide abrir a sua lista de aplicações e iniciar um programa, o AMS vai criar uma nova instância da classe principal, que é uma extensão da classe ”MIDlet”. Para fazer isto, o AMS vai utilizar o construtor sem argumentos da classe ”MIDlet”.


92

Depois disto, se não ocorrer nenhum erro ou excepção, vai ser chamado o método ”startApp()” da nova instância da MIDlet.

A MIDlet fica então no estado “Activo” e é aqui que se obtém controlo da aplicação e pode começar a correr. Um factor de grande importância para aplicações do tipo “jogo” é o Canvas, que define todos os métodos importantes para desenhar no ecrã e capturar instruções do utilizador. A classe “Canvas”, é uma extensão de uma classe chamada “Displayable” que é uma base indispensável para que objectos como Lists ou Forms possam ser colocados no ecrã. Nesta classe são definidos alguns métodos muito importantes, que serão bastante utilizados na interacção do utilizador com o jogo ou aplicação:

• keyPressed( int keyCode ) – Este método indica se uma tecla está a ser pressionada. A tecla pressionada pode ser identificada através do parâmetro int do método;

• paint( Graphics g ) – Este método é chamado pela Virtual Machine para mostrar objectos no ecrã. O parâmetro ”Graphics” é o objecto que será renderizado no Canvas. Note-se que o paint nunca deve ser chamado manualmente;

• keyReleased( int keyCode ) – funciona do mesmo modo que o keyPressed, mas é activado quando uma tecla é solta;

Um esquema mais geral das classes existentes e disponíveis para o

programador, pode ser visto na imagem que se segue:

Figura 7. 6 - Esquema de classes

Desenvolvimento

93

Limites a ter em consideração Uma ultima coisa que se deve fazer antes de se proceder ao desenvolvimento da MIDlet, é relembrar algumas das limitações da plataforma para onde se está a programar. Algumas das considerações mais importantes são as seguintes:

• Não acreditar no mito que diz que o MIDP não suporta imagens transparentes. A maior parte dos dispositivos e emuladores suporta imagens transparentes e mesmo alguns telemóveis Nokia suportam transparências com a variável alpha;

• O MIDP não suporta operações com virgula flutuante, e por isso, não suporta tipos de dados como Double ou Float;

• O número de cores mais comuns para telemóveis é 4096; • A maior parte dos dispositivos não suporta que várias teclas sejam

premidas simultaneamente; • Deve-se ter cuidado com o tamanho das aplicações. Para telemóveis

com ecrã a cores, uma aplicação não deve exceder os 64 KB para manter a compatibilidade;

• Deve-se tentar reduzir ao máximo o número de classes da aplicação. Cada classe aumentará o espaço ocupado pela aplicação e o seu consumo de memória;

Note-se que o lançamento do MIDP 2.0 veio reduzir consideravelmente

a lista de limitações do J2ME. Com a versão 2.0 deste perfil, foram lançadas inúmeras funcionalidades

(algumas já referidas), nomeadamente a nível gráfico e de manipulação de imagens, que vieram facilitar o desenvolvimento de aplicações que requeiram um maior detalhe a nível visual, como é o caso dos jogos.

Posto isto, pode-se proceder com o desenvolvimento de uma aplicação

em J2ME que, neste caso, será um pequeno jogo. Foi escolhido um jogo para este exemplo por diversas razões. Em

primeiro lugar, é o tipo de aplicação mais comum nesta tecnologia. Pode-se dizer que mais de 80% das aplicações desenvolvidas para telemóveis (não só em J2ME) são jogos, e são estes que dominam actualmente o mercado e as preferências dos programadores.

Em segundo lugar, o desenvolvimento deste tipo de aplicação é mais atractivo para a maioria dos programadores. O tema é mais apelativo e toda a lógica da aplicação é de fácil compreensão.

Por último, é este tipo de aplicações que tira melhor partido de todas as funcionalidades oferecidas pelos dispositivos. Um jogo requer sempre uma grande componente de interacção com o utilizador, bons recursos sonoros e uma apresentação visual mais cuidada.

Tal como já acontece nos PCs, são os jogos que vão explorar ao máximo as capacidades ao nível do hardware disponibilizadas pelos dispositivos.


94

7.3. Desenvolvimento de uma MIDlet Para criar a MIDlet, será utilizado o J2ME Wireless Toolkit com todas as suas ferramentas. Como já foi referenciado, a ferramenta mais importante é a KToolbar que será utilizada para criar e gerir os projectos MIDlet. Em primeiro lugar, tal como foi feito com o “HelloWorld”, será criado um novo projecto na KToolbar, com a opção “New Project...”:

Figura 7. 7 - Criação do projecto MyGame

O projecto criado tem o nome “MyGame” e a classe principal da MIDlet chamar-se-á “Startup”. Agora é necessário definir alguns atributos referentes à MIDlet criada.

Figura 7. 8 - Definição dos atributos da MIDlet MyGame

Estes são os atributos principais da MIDlet. Esta informação é obrigatória e, para facilitar a operação, já são sugeridos alguns valores para estes atributos.

Desenvolvimento

95

Os atributos aqui apresentados correspondem ao seguinte: • MIDlet-Jar-Size – Este é um atributo do JAD, que deve reflectir o

número exacto de bytes que ocupa o ficheiro JAR. Se a criação do ficheiro JAR for feita através da KToolbar, este valor é tratado automaticamente. Note-se que, se o valor não corresponder à realidade, não será possível instalar a MIDlet;

• MIDlet-Jar-URL – Este atributo corresponde ao URL do ficheiro JAR. Normalmente basta indicar o nome do ficheiro;

• MIDlet-Name – O nome da MIDlet que aparecerá na lista de MIDlets do telemóvel;

• MIDlet-Vendor – O nome do programador ou da empresa que desenvolveu a MIDlet;

• MIDlet-Version – A versão corrente da MIDlet; • MicroEdition-Configuration – A configuração usada pela MIDlet; • MicroEdition-Profile – O perfil usado pela MIDlet

Quando completado o processo de criação de um novo projecto,

aparecerá na consola a seguinte informação:

Figura 7. 9 - Resultado da criação do projecto MyGame

Isto quer dizer que a KToolbar criou a estrutura de directórios para o

projecto. Os projectos da KToolbar são colocados na sua própria directoria, dentro de “apps”.

Agora, o código fonte criado para esta aplicação deve ser colocado em “src”, dentro da directoria do projecto.


96

Criação de uma MIDlet básica Para começar, será criado uma MIDlet muito simples. Na pasta “src” será criado o ficheiro “Startup.java” que contém a classe principal da MIDlet. A classe Startup é uma extensão de “javax.microedition.midlet.MIDlet”, que possui três métodos abstractos que necessitam de ser implementados. Estes métodos são responsáveis pelo controlo do ciclo de vida das MIDlets. O código fonte contido no ficheiro “Startup.java”, é o seguinte: Startup.java import javax.microedition.midlet.*; public class Startup extends MIDlet { /*Constructor utilizado pelo AMS para criar uma instância da classe MIDlet principal.*/ public Startup() { // Imprime uma mensagem na consola quando o Startup é criado. System.out.println("Constructor: Startup()"); } /*O startApp() é chamado pelo AMS depois de criar com sucesso a instância da classe MIDlet. O startApp() faz com que a MIDlet transite para o estado Activo.*/ protected void startApp() throws MIDletStateChangeException { // Imprime uma mensagem na consola quando o Startup é chamado. System.out.println("startApp()"); } /*O destroyApp() é chamado pelo AMS quando a MIDlet é destruida (terminada).*/ protected void destroyApp( boolean unconditional ) throws MIDletStateChangeException { } /*O pauseApp() é chamado pelo AMS quando a MIDlet é parada. Note-se que este não é um pause típico de um jogo, mas sim um pause que funciona no ambiente da própria aplicação. O exemplo mais comum acontece quando é recebida uma chamada e a aplicação tem que ser interrompida. Aqui são tomadas as devidas precauções para salvaguardar o estado e a integridade da aplicação.*/ protected void pauseApp() { } }

Desenvolvimento

97

Compilação, pré-verificação e execução Para compilar o código fonte do projecto (actualmente apenas o “Startup.java” basta escolher a opção “Build”. O que a KToolbar faz agora, é compilar o código com as APIs do MIDP e do CLDC (com todas as librarias contidas na pasta “lib” do emulador seleccionado) para uma pasta chamada “tmpclasses”. O comando executado é muito similar ao seguinte: Javac –d tmpclasses –bootclasspath %wtk%\lib\midpapi.zip –classpath tmpclasses;classes src\*.java O próximo passo dado pela KToolbar é fazer a pré-verificação dos ficheiros “class” e colocá-los na pasta “classes” do projecto. Os ficheiros “class” devem ser pré-verificados antes de executados num dispositivo MIDP. O comando executado é o seguinte: preverify –classpath %wtk%\lib\midpapi.zip tmpclasses –d clases O “preverify.exe” é uma ferramenta disponibilizada pelo WTK e encontra-se na pasta “bin”. Agora que a MIDlet foi compilada e pré-verificada, pode ser corrida através da opção “Run”. Visto que para já, a única coisa que a MIDlet faz é imprimir duas linhas de texto na consola, não se vai observar nada no emulador. No entanto, a consola deverá mostrar o seguinte:

Figura 7. 10 - Execução do MyGame

Isto demonstra que a classe “Startup” foi criada pelo construtor e, depois disso, foi chamado o “startApp()”. Embora não contenha muita funcionalidade, esta MIDlet é importante para começar e ter uma percepção de como as coisas funcionam.


98

Forms e Commands Forms e Commands, são componentes de alto nível do interface de utilizador, que podem ser úteis para construir menus e mostrar instruções do jogo no ecrã.

A classe “Form” é uma subclasse de “Displayable”, o que quer dizer que pode ser mostrada directamente no ecrã do dispositivo. O Displayable do dispositivo pode ser utilizado com a ajuda da classe “Display”. Para obter uma referência para o objecto “Display”, pode ser chamado o método estático “getDisplay()” na classe “Display”. O método leva um parâmetro que é uma referência para uma instância da classe “MIDlet”: Display display = Display.getDisplay( midletInstance ); Agora pode ser atribuído o “display” a qualquer objecto que seja uma extensão de “Displayable” chamando: display.setCurrent( nextDisplayable ); Sabendo isto, pode-se proceder à construção de um form que será posteriormente mostrado. Em primeiro lugar é necessário criar o form. A maneira mais fácil para isto é criar um form vazio com um título: Form basicForm = new Form( “Form Title” ); É então acrescentada uma string ao form, fazendo o seguinte: basicForm.append( “My Form” );

Agora é preciso mostrar o form:

display.setCurrent( basicForm );

Agora basta inserir isto no método “StartApp()”, que é o primeiro método a ser chamado quando a MIDlet é executada. Visto que as classes “Form” e “Display” pertencem ao package ”javax.microedition.lcdui”, este deve ser importado no ficheiro de código.

Desenvolvimento

99

Depois do código compilado e executado, obtém-se o seguinte resultado:

Figura 7. 11 - Criação de um form

Agora que se criou o form, irá ser criado um Command de modo a obter alguma interacção de alto nível com o utilizador. O Command irá permitir ao utilizador gerar um número aleatório, e mostra-lo no form criado. Antes de mais, convém saber que um Command é um componente que despoleta uma acção na MIDlet. Para capturar um evento despoletado quando um utilizador activa o Command, é necessário utilizar o interface “CommandListener”. Este interface define um método que é necessário implementar: commandAction( Command c, Dislayable d ); Quando o utilizador faz com que o Command seja despoletado, a implementação chama o método “commandAction” do “CommandListener” associado. O “CommandListener” é activado pelo método “setCommandListener()” no Displayable onde o Command foi adicionado. appendCommand = new Command( “Random”, Command.SCREEN, 0 ); O construtor “Command” leva três parâmetros: a string associada ao Command; o tipo de Command (indica à implementação qual o tipo de acção que este Command irá realizar o que, por vezes, afecta a localização do Command no ecrã); e a prioridade (ou ordem de display) associada ao Command . O Command será então adicionado ao Form (como o método “addCommand()” é herdado de Displayable, todos os Displayables podem ter Commands). basicForm.addCommand( appendCommand );


100

Agora que o Command foi adicionado ao Form, o próximo passo é activar o CommandListener do Form. A classe “Startup” terá que implementar o CommandListener e ignorar o método “commandAction()”, para executar estas acções. basicForm.setCommandListener( this ); Visto que a intenção é gerar um número aleatório, é necessário acrescentar um gerador de números aleatórios à aplicação. Para isto, é necessário importar o “java.util.Random” e criar um novo gerador: generator = new Random( System.currentTimeMillis() ); Isto cria um gerador de números aleatórios que se irá basear no tempo actual do sistema, em milisegundos. Método commandAction public void commandAction( Command c, Displayable d ) { /*verifica se o evento commandAction é despoletado pelo appensCommand*/ if( c == appendCommand ) { /*adiciona uma string ao form, com um número aleatório entre 0 e 50.*/ basicForm.append("Random: " + ( Math.abs( generator.nextInt() ) %50 ) + "\n"); } } Agora basta compilar o código e executar. O resultado obtido será o seguinte:

Figura 7. 12 - Geração de um número aleatório

Neste caso, o número sorteado foi o 21!Esta foi uma breve introdução aos componentes de alto nível da API MIDP. Assim, de um modo simples, é possível obter input do utilizador e mostrar informação no ecrã.

Desenvolvimento

101

Canvas O aspecto mais importante num jogo, é talvez a habilidade de desenhar coisas no ecrã, sejam estas os personagens, objectos ou cenário. Para fazer isto no MIDP, é necessário recorrer ao uso das classes “Canvas”, “Graphics” e “Image”. Estas classes são utilizadas para processamento gráfico de baixo nível. “Canvas” é uma classe abstracta e, por isso, deve conter uma subclasse para que possa ser utilizada. Será então criada uma nova classe denominada “GameScreen” que é uma extensão de Canvas. Como foi visto anteriormente, a classe “Canvas” define o método abstracto “paint( Graphics g )”. No entanto, na classe “GameScreen” criada, este método vai ser ignorado, o que vai permitir desenhar no objecto “Graphics” passado ao método “paint()” pela Virtual Machine. Isto deixa a classe “GameScreen” com o seguinte código: GameScreen import javax.microedition.lcdui.*; public class GameScreen extends Canvas { //Construtor para a classe GameScreen. public GameScreen() { } //Chamado quando o Canvas está a ser desenhado protected void paint( Graphics g ) { } } Agora que já foi criado o básico para desenhar no ecrã, será implementado o input para utilizador. A classe “Canvas” define três métodos que controlam eventos das teclas: “keyPressed()”, “keyReleased()”, “keyRepeated()”. O Canvas contém implementações vazias para estes métodos, por isso, cabe ao programador desenvolvê-los da maneira que achar mais adequada. Eventos das teclas // Chamado quando uma tecla é pressionada neste canvas protected void keyPressed( int keyCode ) { } // Chamado quando uma tecla é libertada neste canvas protected void keyReleased( int keyCode ) { }


102

Como pode ser observado, só foram implementados os eventos “keyPressed()”, “keyReleased()” e não o “keyRepeated()”. Não se deve confiar muito no evento “keyRepeated()”, pois a frequência da chamada a este método varia muito de aparelho para aparelho. De qualquer modo, este evento não é fiável para verificar se o utilizador está continuamente a pressionar uma tecla ou não. Agora já está tudo pronto para obter informação do utilizador e desenhar no ecrã, mas antes de continuar, é necessário certificar de que se sabe o modo como o Canvas será mostrado no ecrã. Para isso, a classe “Startup” feita anteriormente sofrerá algumas alterações. Agora, esta classe serve apenas como ponto de entrada à aplicação, e cria e mostra uma nova instância da classe “GameScreen”. Startup protected void startApp() throws MIDletStateChangeException { Display display = Display.getDisplay( this ); /*GameScreen é uma extensão de Canvas que, por sua vez, estende de Displayable para que possa ser mostrado ditrectamente no ecrã.*/ display.setCurrent( new GameScreen() ); }

Um novo GameScreen está a ser criado e mostrado. Agora podem ser testados alguns métodos primitivos de desenho, disponibilizados pela classe “Graphics”. Definição de uma cor para o cenário //definir a cor actual do contexto gráfico para um azul escuro //0xRRGGBB g.setColor( 0x000088 ); /*desenhar um rectângulo preenchido, nas coordenadas 0(x), 0(y), com um comprimento e uma altura iguais aos do Canvas.*/ g.fillRect( 0, 0, this.getWidth(), this.getHeight() );

Ao definir a cor através do “setColor( int rgbColor )”, irão ser afectadas todas as operações de renderização subsequentes a este contexto gráfico. Deste modo, a chamada do “fillRect( x, y, width, height )” vai desenhar um rectângulo preenchido da cor seleccionada. Isto também introduz dois métodos de alguma importância, pertencentes à classe “Canvas”: “getWidth()” e “getHeight()”. Estes métodos são usados para obter o espaço total disponível para desenhar no canvas. Estes métodos são especialmente úteis quando se pretende desenvolver aplicações destinadas a diferentes aparelhos em que haja variação do tamanho dos ecrãs.

Desenvolvimento

103

É aconselhável utilizar estes métodos em vez de forçar os valores do tamanho do ecrã, pois deste modo vai ser mais fácil portar a aplicação para outro telemóvel distinto. Do mesmo modo, também é aconselhável fazer com que todos os objectos desenhados no ecrã sejam relativos à altura e comprimento do Canvas. O aspecto final destas alterações é o seguinte:

Figura 7. 13 - Primeira utilização do Canvas

Input Só para se ter uma ideia do modo de manuseamento dos eventos associados às teclas, serão feitas algumas alterações ao programa anterior para que o rectângulo preenchido mude de cor conforme a tecla pressionada. Deste modo, o rectângulo terá as seguintes teclas associadas às cores:

• Vermelho – Esquerda; • Verde – Direita; • Preto – Cima; • Branco – Baixo; • Azul – Fogo;

Como já foi referenciado, um evento associado a uma tecla pressionada,

é representado por um valor inteiro (int) que reflecte o código da tecla pressionada pelo utilizador. Este código pode ser tratado de duas maneiras diferentes: ou através do seu valor real (KEY_NUM0 a KEY_NUM9, KEY_STAR ou KEY_POUND que perfazem o teclado de um telemóvel tradicional); ou através do seu valor associado ao jogo (UP, DOWN, LEFT, RIGHT, FIRE, GAME_A, GAME_B, GAME_C, GAME_D).

Mas porquê estas duas opções? Isto deve-se ao facto de existirem inúmeras configurações diferentes dos teclados dos telemóveis. Ao utilizar o valor das teclas através do seu valor de jogo associado, permite a identificação das teclas de um modo mais portável.


104

Para obter o código das teclas associado ao jogo, é utilizado o método “getGameAction( int keyCode )” da classe “Canvas”.

Manuseamento de eventos das teclas //Chamado quando o Canvas é mostrado protected void paint( Graphics g ) { /*definir a cor actual do contexto gráfico para o valor RGB associado*/ g.setColor( colour ); /*desenha um rectângulo preenchido em x, y com as coordenadas 0,0 e com comprimento e altura do Canvas*/ g.fillRect( 0, 0, this.getWidth(), this.getHeight() ); } //Chamado quando uma tecla é pressionada no Canvas actual protected void keyPressed( int keyCode ) { //obtém o código da tecla associada ao jogo int gameAction = getGameAction( keyCode ); switch( gameAction ) { case LEFT: //Muda a cor actual para vermelho colour = 0xFF0000; break; case RIGHT: //Muda a cor actual para verde colour = 0x00FF00; break; case UP: //Muda a cor actual para preto colour = 0x000000; break; case DOWN: //Muda a cor actual para branco colour = 0xFFFFFF; break; case FIRE: //Muda a cor actual para azul colour = 0x0000FF; break; } /*como ainda não foi definido nenhum loop para o jogo, é necessário redesenhar o Canvas de cada vez que se prime uma tecla.*/ repaint(); }

Desenvolvimento

105

O resultado obtido será então o seguinte:

Ao olhar para a última linha do método “keyPressed()” vê-se uma chamada ao “repaint()” que serve para forçar o canvas a ser redesenhado. Normalmente isto não seria feito no método “keyPressed()” mas sim no fim do loop do jogo.

Figura 7. 14 - Tecla "cima" Figura 7. ~15 – Tecla “baixo”

Figura 7.16 - Tecla "esquerda" Figura 7. 14 - Tecla "direita" Figura 7. 15 - Tecla "disparo"


106

Loop A classe “Thread” será usada para reactivar a thread do jogo que irá ser utilizada para o loop principal. Existem dois modos diferentes de criar threads. Uma das hipóteses é criar uma subclasse de “Thread” e ignorar o método “run()” da classe “Thread”, mas como aqui não são possíveis múltiplas heranças (e a classe “GameScreen” já é uma extensão de “Canvas”) vai ser utilizado o segundo método. Assim, será implementado o interface “Runnable” e o seu método “run()”. Isto quer dizer que se pode criar um novo thread passando a instância da classe “GameScreen” (que implementa o “Runnable”) para o construtor do thread. Criação de um novo thread //Constructor para a classe GameScreen. public GameScreen() { //Cria um novo thread e começa-o imediatamente new Thread( this ).start(); } /*O método run() definido no interface Runnable, chamado pela Virtual Machine quando a thread é iniciada.*/ public void run() { }

Agora, ao construir o GameScreen, vai ser criado e iniciado um novo thread que despoleta uma chamada ao método “run()”. É porém pretendido que o loop principal seja chamado em intervalos fixos de tempo e, para este exemplo, será estipulado o intervalo de 15 vezes por segundo (embora seja impossível definir com precisão um intervalo de tempo fixo que possa ser aplicado a todos os jogos, 15fps (frames per second) é um indicativo médio razoável para começar). Dentro do método “run()” está implementada a lógica de temporização para o loop. Lógica de temporização para o loop /*Método run() definido no interface Runnable, chamado pela Virtual Machine quando o thread é iniciado*/ public void run() { //definir o atraso do loop para 1/15 segundos int loopDelay = 1000 / 15; while( true ) { //apanhar o tempo no início do loop long loopStartTime = System.currentTimeMillis(); /*chamar a função tick() que funcionará como o bater do coração

Desenvolvimento

107

para o jogo*/ tick(); //apanhar o tempo no final do loop long loopEndTime = System.currentTimeMillis(); //calcular a diferença do tempo entre o início e o fim do loop int loopTime = (int)(loopEndTime - loopStartTime); //se a diferença for maior do que a desejada if( loopTime < loopdelay ) { try { /*então o programa adormece durante o tempo suficiente para completar o desejado*/ thread.sleep( loopdelay - looptime ); } catch( exception e ) { } } } } public void tick() { } Para testar o loop, será feita uma pequena alteração ao programa anterior para que o cenário mude para uma cor aleatória em cada frame. Pode-se aproveitar a ocasião para posicionar o “repaint” no loop do jogo. Aplicação do loop // o loop chamado num intervalo fixo de tempo pelo thread do jogo public void tick() { //obter um número aleatório dentro dos limites das cores RRGGBB colour = generator.nextInt() & 0xFFFFFF; //fazer o repaint do canvas repaint(); /*força que cada repaint pendente tratado e bloqueia até ao retorno do paint()*/ serviceRepaints(); } Como resultado, a imagem de fundo do ecrã estará a variar constantemente entre diversas cores aleatoriamente.


108

Imagens As imagens no MIDP são extremamente fáceis de utilizar. O modo mais fácil é chamar o método estático “createImage( String name )” da classe “Image”. A string passada ao método, corresponde à localização da imagem no ficheiro JAR da MIDlet. Deste modo, a primeira coisa a fazer é criar uma imagem para ser posteriormente usada no jogo. O tipo de imagem suportada pelo MIDP é “PNG”. Ao usar a KToolbar, a única coisa que é preciso fazer é colocar o ficheiro de imagem na directoria “res” do projecto. Neste caso, será criada uma imagem com o nome “sprite.png” e será colocada na directoria correspondente. A imagem será a seguinte:

Figura 7. 169 - Imagem PNG que será utilizada

Normalmente as imagens devem ocupar o menos espaço possível e, para isso, existem vários truques possíveis. Para ganhar mais alguns bytes, a imagem pode ser optimizada por exemplo com o “XAT Image Optimizer” ou com o “PNGCrush” que são ferramentas que chegam a conseguir uma optimização de 30%. Note-se que, para imagens transparentes (aliás, como é o caso), é necessário que sejam PNGs de 24 bits. A criação da imagem é feita do seguinte modo: Criação de uma imagem try { myImage = Image.createImage("/sprite.png"); } catch( Exception e ) { e.printStackTrace(); } A criação de imagens demora tempo e ocupa muita memória, pelo que deve ser feita em áreas controladas da aplicação. Para desenhar uma imagem criada no ecrã, é usado o método “drawImage()” da classe “Graphics”. g.drawImage( myImage, x, y, Graphics.top | Graphics.left );

Desenvolvimento

109

O parâmetro “Graphics.top | Graphics.left” é chamado “âncora”. Aqui é definido como a imagem deve ser desenhada, relativamente às coordenadas x e y. A constante “Graphics.top” faz com que o topo da imagem esteja na coordenada y, e a constante “Graphics.left” faz com que a parte esquerda da imagem corresponda à coordenada x. Deste modo, se se pretende colocar a imagem no centro do ecrã, deve-se definir a “âncora” para os centros vertical e horizontal do ecrã. g.drawImage( myImage, this.getWidth()/2, this.getHeight()/2, Graphics.VCENTER | Graphics.HCENTER ); Depois do código compilado e corrido, será obtido o seguinte resultado:

Figura 7. 20 - Utilização de imagens

A imagem escolhida está colocada no centro do ecrã, os botões direccionais e o botão “select”, mudam a cor de fundo. Double Buffering Para evitar irregularidades quando alguma coisa está a ser desenhada no ecrã (imagem a piscar) têm que ser utilizadas as já conhecidas técnicas de “double buffering”, em que todos os objectos são renderizados fora do ecrã, e só depois mostrados. Algumas implementações fazem já o “double buffering” automaticamente. É possível verificar se um aparelho faz “double buffering” automaticamente, através do método “isDoubleBuffered()” do Canvas. A vantagem de se saber se o “double buffering” é ou não automático é que este é um procedimento que ocupa algum espaço e memória, pelo que é bom evitar quando possível. Pode-se facilmente adaptar o código aos dois casos possíveis. Enquanto são carregadas e criadas todas as imagens, pode também ser criado o buffer se necessário.


110

Teste de “double buffer” //Cria todas as imagens. É chamado na criação da classe GameScreen public void createImages() { try { //se o aparelho não faz double buffering automático if( !isDoubleBuffered() ) { //cria uma imagem for a do ecrã bufferImage = Image.createImage( getWidth(), getHeight() ); /* apanha o contexto Graphics onde pode ser renderizado a imagem do buffer */ buffer = bufferImage.getGraphics(); } myImage = Image.createImage("/sprite.png"); } catch( Exception e ) { e.printStackTrace(); } }

É criada uma nova imagem vazia com a chamada de “Image.createImage(width, height)”. Esta imagem deve ter exactamente o mesmo tamanho da área visível do Canvas. No MIDP existem imagens mutáveis e imutáveis. A diferença é que as imagens imutáveis, criadas a partir de ficheiros, não podem ser modificadas depois de criadas. Uma imagem mutável, normalmente criada através da chamada de “Image.createImage(width, height)” pode ser modificada, obtendo o contexto “Graphics” onde será renderizada. Isto é feito chamando o “getGraphics()” da imagem, e foi este o procedimento para o segundo buffer. Com umas pequenas alterações ao método “paint()” podem ser tratados os aparelhos que não fazem “double buffering” automático. Double buffering // Chamado quando o Canvas vai ser mostrado protected void paint( Graphics g ) { //mantém uma referência para o contexto Graphics original Graphics original = g; // se o aparelho não faz double buffering automático if( !isDoubleBuffered() ) { /*muda a referência ao objecto g para o segundo buffer do contexto Graphics*/ g = buffer; } //Define a cor do contexto Graphics para a cor RRGGBB especificada

Desenvolvimento

111

g.setColor( colour ); /*desenha um rectângulo a cheio em x, y com as coordenadas 0, 0 e uma altura e largura iguais ás do Canvas*/ g.fillRect( 0, 0, this.getWidth(), this.getHeight() ); //desenha uma imagem no centro do ecrã g.drawImage( myImage, this.getWidth()/2, this.getHeight()/2, Graphics.VCENTER | Graphics.HCENTER ); if( !isDoubleBuffered() ) { //desenha a imagem fora do ecrã no contexto Graphics original original.drawImage( bufferImage, 0, 0, Graphics.TOP | Graphics.LEFT ); } } Inicialmente, este procedimento pode parecer um pouco confuso mas, em resumo, foi feito o seguinte: em cima do método “paint()”, é mantida uma referência ao contexto “Graphics” original que é passado como parâmetro ao método. Em seguida, foi verificado se realmente era necessário fazer double buffering e, em caso afirmativo, é mudado o contexto “Graphics” referenciado pela variável “g”, para o contexto “Graphics” obtido a partir da imagem do buffer. No final do método “paint()” é novamente verificado se é necessário fazer double buffering e é desenhada a imagem do buffer no contexto “Graphics” guardado anteriormente. Para acabar, é adicionada alguma funcionalidade de movimentação à imagem, de forma a obter uma interacção mais interessante com o utilizador. Double buffering //Chamado quando uma tecla é pressionada no Canvas corrente protected void keyPressed( int keyCode ) { //apanha o código das teclas associadas ao jogo int gameAction = getGameAction( keyCode ); switch( gameAction ) { case LEFT: //move imagem para a esquerda imageDirection = LEFT; break; case RIGHT: // move imagem para a direita imageDirection = RIGHT; break;


112

case UP: // move imagem para cima imageDirection = UP; break; case DOWN: // move imagem para baixo imageDirection = DOWN; break; case FIRE: //muda o cenário para uma cor aleatória colour = generator.nextInt()&0xFFFFFF; break; } } //O loop principal do jogo, chamado num intervalo fixo de tempo public void tick() { int myImageSpeed = 4; switch( imageDirection ) { case LEFT: myImageX-=myImageSpeed; break; case RIGHT: myImageX+=myImageSpeed; break; case UP: myImageY-=myImageSpeed; break; case DOWN: myImageY+=myImageSpeed; break; } //faz o repaint do Canvas repaint(); /*força que cada repaint pendente tratado e bloqueia até ao retorno do paint()*/ serviceRepaints(); }

Desenvolvimento

113

O resultado final será o seguinte:

A nave move-se em todas as direcções (cima, baixo, esquerda e direita), e a tecla de disparo faz com que o fundo mude para uma côr aleatória.

O código completo desta aplicação, pode ser consultado em anexo. Instalação Agora que a aplicação está desenvolvida, é necessário que seja instalada num telemóvel. Existem muitos métodos para fazer isto. Normalmente os programadores recorrem ao uso de cabos serie ou USB, e software fornecido pelo fabricante, para transmitir dados directamente do computador para o telemóvel, ou transmissão via infravermelhos. Também é possível instalar a aplicação num servidor, para que depois possa ser descarregada para o telemóvel. Neste caso é necessário verificar se o servidor reconhece ficheiros JAR e JAD. Esta hipótese é normalmente denominada de “OTA Provisioning” (Over The Air Provisioning). A KToolbar permite testar a instalação de aplicações vis OTA. Para isso, basta abrir o projecto correspondente à aplicação que se pretende testar (neste caso, “MyGame”), e escolher a opção “Run via OTA” do menu “Project” da KToolbar. Isto corre automaticamente o servidor OTA da KToolbar, assim como o emulador. Aqui, o emulador não estará a correr a aplicação mas sim o seu AMS (Application Management Software). É a partir daqui que será simulada a instalação da aplicação.

Figura 7. 21 - Movimentação da imagen no ecrã: "cima"+"esquerda"

Figura 7. 22 - Movimentação da imagem no ecrã: "baixo"+"direita"


114

Figura 7. 23 - Ecrã inicial do AMS

No emulador, depois de premir a tecla correspondente a “Apps”, aparecerá o seguinte menu:

Figura 7. 24 - Instalar a aplicação

Como não existe nenhuma aplicação no telemóvel, a única hipótese é fazer a instalação de uma nova aplicação. O passo seguinte é premir o botão “Menu” e escolher a opção “Launch”.

Desenvolvimento

115

Figura 7. 25 - Introdução da localização da aplicação

Este ecrã pede a localização do jogo que se pretende instalar. Neste caso, o emulador sugere automaticamente o endereço do jogo, visto que ele próprio é o servidor. No caso de ser uma instalação num telemóvel, terá que ser especificado o endereço real de onde se encontra a aplicação. Para continuar a instalação, terá que ser escolhida a opção “Go” do “Menu”.

Figura 7. 26 - Escolha da aplicação a instalar

Agora é dada a opção do utilizador escolher a aplicação que pretende instalar. Para continuar terá que ser escolhida a opção “Install”.


116

Figura 7. 177 - Confirmação da instalação

Este é o ecrã de confirmação. Aqui é mostrada alguma informação acerca da aplicação a instalar, e pedida a confirmação ao utilizador. Ao seleccionar a opção “Install” o jogo irá ser, finalmente, instalado.

Figura 7. 28 - Execução do jogo

Agora, como se pode constatar, o jogo está instalado no dispositivo. Para correr basta seleccionar a opção “Launch” do menu. Apesar disto, a verdadeira intenção deste tipo de aplicação, é ser instalada mesmo num telemóvel. Para isso, antes de ser descarregada via OTA, os ficheiros referentes ao jogo devem ser colocados num servidor público apropriado, que esteja acessível na internet. Para que seja possível o download de aplicações deste tipo, o servidor deve reconhecer os tipos de ficheiro associados (JAD e JAR). Deste modo, a extensão JAD deve estar mapeada com o tipo ”text/vnd.sun.j2me.app-descriptor” e a extensão JAR, deve estar mapeada com o tipo ”application/java-archive”. Note-se que as versões 4.0 ou superior do servidor Tomcat já incluem estes mapeamentos nas suas configurações.

Agora basta proceder como foi feito com o simulador e correr e jogar.

8. Conclusão A programação destinada a plataformas moveis está ainda a dar os seus primeiros passos. Por outro lado, os telemóveis estão a ganhar importância na vida das pessoas e a perder as suas muitas limitações. Hoje em dia, estão constantemente a surgir novos telemóveis com mais potencialidades e tecnologias mais capazes e com mais funcionalidades, que permitem o desenvolvimento de aplicações mais poderosas. Prevê-se que futuramente os telemóveis continuem a evoluir e, consequentemente, se tornem numa ferramenta indispensável no dia-a-dia, tanto a nível de trabalho, como de lazer. As pessoas vão cada vez mais depender destes pequenos aparelhos para realizar as mais diversas funções. Por isso, do ponto de vista dos programadores, é uma tecnologia que actualmente merece uma especial atenção. A programação destinada a este tipo de dispositivos ainda tem um longo caminho a percorrer, e cabe aos programadores explorar as capacidades das linguagens disponíveis e dos aparelhos. Esta é uma área na qual se pode apostar, devido ao crescimento que se tem vindo a observar nos últimos tempos e ás perspectivas futuras. As marcas de telemóveis estão a desenvolver aparelhos mais potentes e sofisticados, enquanto empresas como a Sun ou até a Microsof” desenvolvem novas linguagens de programação que consigam tirar melhor partido das tecnologias e permitir aos programadores obter melhores resultados. Também a introdução dos telemóveis no universo das consolas de jogos (Nokia N-Gage) eleva esta tecnologia a um outro nível. A maior parte dos consumidores de telemóveis topo de gama, são pessoas que se interessam por jogos e outros tipos de aplicações de lazer. Além disso, os jogos atraem muitos programadores amadores que desenvolvem aplicações e ajudam a expansão desta tecnologia conseguindo ganhar algum dinheiro com isso. O J2ME é actualmente a tecnologia mais utilizada pelos programadores e com mais suporte a nível de telemóveis, o que faz com que seja líder no desenvolvimento deste tipo de aplicações. Embora tenha uma forte concorrência, a Sun está empenhada em continuar com a evolução tecnologia J2ME que merece por isso muita atenção por parte dos programadores.


118

9. Bibliografia

• Sun [Online] – Site de referência da linguagem Java da Sun Disponível na WWW: <java.sun.com>.

• Nokia [Online] – Site oficial da Nokia Disponível na WWW: <www.nokia.com>.

• Sony Ericsson [Online] – Site oficial da Sony Ericsson portuguesa

Disponível na WWW: <www.sonyericsson.com/pt>. • Samsung [Online] – Site oficial da Samsung

Disponível na WWW: <www.samsung.com>.

• Panasonic [Online] – Site oficial da Panasonic Disponível na WWW: <www.panasonic.com/consumer_electronics/cellular/default.asp>.

• Siemens [Online] – Site oficial de telemóveis Siemens Disponível na WWW: <www.siemens.com/index.jsp?sdc_p=dpo1071950fcls2mnt4u&sdc_sid=22824419811>.

• Motorola [Online] – Site oficial da Motorola

Disponível na WWW: <www.motorola.com>. • Sagem [Online] – Site oficial da Sagem

Disponível na WWW: <www.sagem.com/en>.

• KObjects [Online] – Lista de dispositivos e suas características Disponível na WWW: <www.kobjects.org/devicedb>.

• In-Fusio [Online] – Site oficial do ExEn

Disponível na WWW: <www.developer.in-fusio.com>.

• Synergenix [Online] – Site oficial do Mophun Disponível na WWW: <www.mophun.com>.

• TTPCom [Online] – Site oficial da TTPCom

Disponível na WWW: <www.ttpcom.com>.

• 9Dots [Online] – Site oficial do WGE Disponível na WWW: <www.9dots.net>.

• Symbian [Online] – Site oficial do Symbian

Disponível na WWW: <www.symbian.com>.


120

• Ultra Edit [Online] – Site oficial do Ultra Edit (ferramenta de programação Java) Disponível na WWW: <www.ultraedit.com>.

• Eclipse [Online] – Site oficial do Eclipse (ferramenta de programação

Java) Disponível na WWW: <www.eclipse.org>.

• JBuilder [Online] – Site oficial do JBuilder (ferramenta de

programação Java da Boreland) Disponível na WWW: <www.boreland.com/jbuilder>.

• Midlet Org [Online] – Repositório de MIDlets e oportunidade de

publicidade a jogos Disponível na WWW: <www.midlet.org>.

• Billday [Online] – Recursos e informação de J2ME

Disponível na WWW: <www.billday.com/j2me>. • MIDlet Review [Online] – Site de crítica a MIDlets

Disponível na WWW: <www.midlet-review.com>. • Macrospace [Online] – Jogos comerciais da Macrospace

Disponível na WWW: <games.macrospace.com>. • Microjava [Online] – Site de notícias tutoriais e artigos de J2ME

Disponível na WWW: <www.microjava.com>. • IGN [Online] – Secção de jogos wireless da IGN

Disponível na WWW: <wireless.ign.com>. • Qualcomm [Online] – Informação referente a Brew

Disponível na WWW: <www.qualcomm.com/brew>.

• Motocoder [Online] – Site de desenvolvimento da Motorolla Disponível na WWW: <www.motocoder.com>.

• John W. Muchow – “Core J2ME Technology & MIDP”. Sun Microsystems, 2001.

• “J2ME: Step by step”. IBM Developer Networks.

• “MIDlet development with J2ME and MIDP”. IBM Developer Networks.

• Michael Taylor – “J2ME IDE Comparison”. Developnet Consulting

Limited, 2002.

• Monica Pawla – “Essencials of Java Programing Language: A Hands-On Guide, Part 1”. Sun.

Anexo

121

• Java Comunity Process [Online] – Site da comunidade Java

Disponível na WWW: <jcp.org>.


122

10. Anexo Código fonte referente ao jogo desenvolvido no capítulo 7 – “MyGame” Startup.java import javax.microedition.midlet.*; import javax.microedition.lcdui.*; public class Startup extends MIDlet { /*Constructor utilizado pelo AMS para crier uma instância da classe MIDlet principal*/ public Startup() { } /* O startApp() é chamado pelo AMS depois de criar com sucesso a instância da classe MIDlet. O startApp() faz com que a MIDlet transite para o estado Activo. */ protected void startApp() throws MIDletStateChangeException { Display display = Display.getDisplay( this ); /*GameScreen é uma extensão de Canvas que, por sua vez, estende de Displayable para que possa ser mostrado ditrectamente no ecrã.*/ display.setCurrent( new GameScreen() ); } /*O destroyApp() é chamado palo AMS quando a MIDlet é destruida (terminada).*/ protected void destroyApp( boolean unconditional ) throws MIDletStateChangeException { } /* O pauseApp() é chamado pelo AMS quando a MIDlet é parada. Note-se que este não é um pause típico de um jogo, mas sim um pause que funciona no ambiente da própria aplicação. O exemplo mais comum acontece quando é recebida uma chamada e a aplicação tem que ser interrompida. Aqui são tomadas as devidas precauções para salvaguardar o estado e a integridade da aplicação. */ protected void pauseApp() { } }


124

GameScreen.java import javax.microedition.lcdui.*; import java.util.*; public class GameScreen extends Canvas implements Runnable { Random generator; Graphics buffer; Image myImage; Image bufferImage; int colour; int myImageX; int myImageY; int imageDirection; //Constructor para a classe GameScreen. public GameScreen() { //activa o gerador de números aleatórios generator = new Random( System.currentTimeMillis() ); //cria das imagens necessárias createImages(); /*Define a posição inicial da imagem para o centro do ecrã*/ myImageX = getWidth()/2; myImageY = getHeight()/2; //cria um novo thread e iniciar imediatamente new Thread( this ).start(); } /*Cria todas as imagens necessaries. É chamado na criação da classe GameScreen*/ public void createImages() { try { /*se o aparelho não suporta double buffering automático*/ if( !isDoubleBuffered() ) { //cria uma imagem for a do ecrã bufferImage = Image.createImage( getWidth(), getHeight() ); /*obtém um contexto Graphics onde pode ser renderizado a imagem do buffer*/ buffer = bufferImage.getGraphics(); } myImage = Image.createImage("/sprite.png"); }

Anexo

125

catch( Exception e ) { e.printStackTrace(); } } /*método run()definido no interface Runnable. É chamado pela Virtual Machine quando o thread é iniciado*/ public void run() { while( true ) { //define o atraso do loop para 1/15 de segundo int loopDelay = 1000 / 15; //apanha o tempo no início do loop long loopStartTime = System.currentTimeMillis(); /*chama a função tick() que funcionará como o bater do coração para o jogo*/ tick(); //apanha o tempo no final do loop long loopEndTime = System.currentTimeMillis(); // calcula a diferença do tempo entre o início e o fim do loop int loopTime = (int)(loopEndTime - loopStartTime); //se a diferença for maior do que a desejada if( loopTime < loopDelay ) { try { /*então o programa adormece durante o tempo suficiente para completar o desejado Thread.sleep( loopDelay - loopTime ); } catch( Exception e ) { } } } } /*O loop chamado num intervalo fixo de tempo, pelo thread do jogo*/ public void tick() { int myImageSpeed = 4; switch( imageDirection ) { case LEFT: myImageX-=myImageSpeed; break; case RIGHT: myImageX+=myImageSpeed; break;


126

case UP: myImageY-=myImageSpeed; break; case DOWN: myImageY+=myImageSpeed; break; } //faz o repaint do Canvas repaint(); // força que cada repaint pendente tratado e bloqueia até ao retorno do paint() serviceRepaints(); } //Chamado quando o Canvas vai ser mostrado protected void paint( Graphics g ) { /*mantém uma referência para o contexto Graphics original*/ Graphics original = g; //se o aparelho não faz double buffering automático if( !isDoubleBuffered() ) { /*muda a referência ao objecto g para o segundo buffer do contexto Graphics*/ g = buffer; } //Define a cor do contexto Graphics para a cor RRGGBB especificada g.setColor( colour ); /*desenha um rectângulo a cheio em x, y com as coordenadas 0, 0 e uma altura e largura iguais ás do Canvas*/ g.fillRect( 0, 0, this.getWidth(), this.getHeight() ); //desenha uma imagem no centro do ecrã g.drawImage( myImage, myImageX, myImageY, Graphics.VCENTER | Graphics.HCENTER ); if( !isDoubleBuffered() ) { //desenha a imagem fora do ecrã no contexto Graphics original original.drawImage( bufferImage, 0, 0, Graphics.TOP | Graphics.LEFT ); } } // Chamado quando uma tecla é pressionada no Canvas corrente protected void keyPressed( int keyCode ) { // apanha o código das teclas associadas ao jogo int gameAction = getGameAction( keyCode ); switch( gameAction ) { case LEFT: //move a imagem para a esquerda imageDirection = LEFT; break;

Anexo

127

case RIGHT: //move a imagem para a direita imageDirection = RIGHT; break; case UP: //move a imagem para cima imageDirection = UP; break; case DOWN: //move a imagem para baixo imageDirection = DOWN; break; case FIRE: //set muda o cenário para uma cor aleatória colour = generator.nextInt()&0xFFFFFF; break; } } //Chamado quando uma tecla é solta no Canvas actual protected void keyReleased( int keyCode ) { imageDirection = 0; } }


128

129

11. Índice de figuras Figura 2.1 – Nokia N-Gage ...............................................................................15 Figura 2.2 – Imagens de Dragon Island ............................................................16 Figura 2.3 – Imagens de XFinity .......................................................................16 Figura 2.4 – Imagens de Hurricane Space Fighters..........................................17 Figura 2.5 – Imagens de Crash Bandicoot........................................................17 Figura 2.6 – Imagens de Fantom Overdrive .....................................................17 Figura 3.1 – Esquema de funcionamento do Java............................................14 Figura 3.2 – Portabilidade do Java ...................................................................14 Figura 3.3 – Constituintes do Java....................................................................23 Figura 3.4 – Diversas versões do Java.............................................................24 Figura 3.5 – Plataformas Java ..........................................................................25 Figura 3.6 – Configurações e Perfis..................................................................30 Figura 3.7 – MIDP e MIDlets.............................................................................44 Figura 3.8 – Keypad normal de um telemóvel ..................................................46 Figura 3.9 – Ciclo de vida de uma MIDlet .........................................................53 Figura 4.1 – Sagem myG-5 com suporte ExEn.................................................60 Figura 4.2 – Sony Ericsson T610 com suporte Mophun ...................................61 Figura 4.3 – Innostream I-1000 com suporte WGE.......................................... 62 Figura 4.4 – Samsung SCH-A530 com suporte BREW ....................................63 Figura 4.5 – Nokia 3650 com Symbian OS v6.1 ...............................................64 Figura 6.1 – Escolha do dispositivo default.......................................................65 Figura 6.2 – Consola principal da KToolbar......................................................66 Figura 6.3 – Criação de um novo projecto ........................................................67 Figura 6.4 – Abrir um projecto existente ...........................................................67 Figura 6.5 – Consola de utilities ........................................................................68 Figura 6.6 – Consola WMA ...............................................................................69 Figura 6.7 – Envio de mensagem SMS ............................................................70 Figura 6.8 – Envio de mensagem CBS.............................................................71 Figura 6.9 – Assinatura da MIDlet suite ............................................................72 Figura 6.11 – Gestor de certificados .................................................................73 Figura 6.12 – Configuração de rede .................................................................74 Figura 6.13 – Performance ...............................................................................75 Figura 6.14 – Monitorização..............................................................................76 Figura 6.15 – Armazenamento..........................................................................77 Figura 6.16 – Disponibilidade de APIs ..............................................................77 Figura 6.17 – WMA ...........................................................................................78 Figura 6.18 – MMedia .......................................................................................78 Figura 6.19 – Segurança...................................................................................79 Figura 6.20 – Atributos requeridos....................................................................81 Figura 6.21 – Atributos opcionais......................................................................81 Figura 6.22 – Atributos definidos pelo utilizador ...............................................81 Figura 6.23 – Atributos das MIDlets..................................................................82 Figura 6.24 – Push registry ...............................................................................82 Figura 6.25 – Permissões .................................................................................83 Figura 6.26 – Emulador OTA ............................................................................92


130

Figura 7.1 – Criação de um novo projecto ........................................................87 Figura 7.2 – Janela de settings .........................................................................87 Figura 7.3 – Consola principal após a criação de um projecto .........................88 Figura 7.4 – Aplicação Hello World no telemóvel..............................................90 Figura 7.5 – Resultado da aplicação Hello World .............................................90 Figura 7.6 – Esquema de classes.....................................................................92 Figura 7.7 – Criação do projecto MyGame .......................................................94 Figura 7.8 – Definição dos atributos da MIDlet MyGame..................................94 Figura 7.9 – Resultado da criação do projecto MyGame ..................................95 Figura 7.10 – Execução do MyGame................................................................97 Figura 7.11 – Criação de um form ....................................................................99 Figura 7.12 – Geração de um número aleatório .............................................100 Figura 7.13 – Primeira utilização do Canvas ..................................................103 Figura 7.14 – Tecla "cima" ..............................................................................113 Figura 7.15 – Tecla "baixo" .............................................................................113 Figura 7.16 – Tecla "esquerda".......................................................................113 Figura 7.17 – Tecla "disparo"..........................................................................113 Figura 7.18 – Tecla "direita" ............................................................................113 Figura 7.19 – Imagem PNG que será utilizada ...............................................108 Figura 7.20 – Utilização de imagens...............................................................117 Figura 7.21 – Movimentação da imagem no ecrã: "cima"+"esquerda" ...........121 Figura 7.22 – Movimentação da imagem no ecrã: "baixo"+"direita" ...............121 Figura 7.23 – Ecrã inicial do AMS...................................................................114 Figura 7.24 – Instalar a aplicação ...................................................................114 Figura 7.25 – Introdução da localização da aplicação ....................................115 Figura 7.26 – Escolha da aplicação a instalar ................................................115 Figura 7.27 – Confirmação da instalação .......................................................116 Figura 7.28 – Execução do jogo .....................................................................116

131

12. Índice de tabelas Tabela 2.1 – Toques polifónicos .......................................................................11 Tabela 2.2 – Captura de imagens/vídeo ...........................................................12 Tabela 2.3 – Características do display ............................................................13 Tabela 2.4 – Capacidades de memória ............................................................14 Tabela 2.5 – Tecnologias suportadas ...............................................................18 Tabela 3.1 – Propriedades do sistema .............................................................41 Tabela 3.2 – Atributos do MIDlet packaging .....................................................51

Tecnologia Java Aplicada a Telemóveis - ipp.ptpaf/proj/Set2003/Java... · 2003. 9. 8. · O 5º...

Documents

Transcript of Tecnologia Java Aplicada a Telemóveis - ipp.ptpaf/proj/Set2003/Java... · 2003. 9. 8. · O 5º...