Minicurso

Desenvolvimento para Dispositivos Móveis utilizando JavaME

Por Erisvaldo Júnior

Resumo: O presente minicurso tem como objetivo introduzir o

desenvolvimento de aplicações para dispositivos móveis utilizando a

tecnologia JavaME, através de uma abordagem prática. Em um primeiro

momento, será mostrada a plataforma, sua arquitetura e como produzir

aplicativos básicos, utilizando os componentes nativos do J2ME.

Depois, focar-se-á na confecção de telas em baixo nível, nos desafios

de portabilidade, persistência de dados e exemplos demonstrando o uso

de APIs opcionais para manipulação de câmera, envio de SMS/MMS e

integração com a Web através de requisições HTTP. Por fim, serão

mostradas algumas aplicações comerciais desenvolvidas, consolidando o

conteúdo ministrado.

Erisvaldo Júnior é tecnólogo em Sistemas para Internet pelo Instituto Federal de

Educação, Ciência e Tecnologia da Paraíba (IFPB), bem como graduando em Ciência

da Computação pela Universidade Federal da Paraíba (UFPB). Além disso, é

pesquisador no Laboratório de Tecnologias para Ensino Virtual e Estatística

(LabTEVE), também situado na UFPB, fazendo parte da equipe de jogos educacionais

multiplataforma.

E-mail / Gtalk: erisvaldojunior@gmail.com

Site: http://erisvaldojunior.com

Twitter: http://twitter.com/erisvaldojunior

Minicurso

Desenvolvimento para Dispositivos Móveis utilizando JavaME

Por Erisvaldo Júnior

Introdução

Entre as tecnologias para desenvolvimento de aplicações para celulares, destaca-se o J2ME, também chamado de JavaME ou, ainda, JME. Trata-se de uma versão simplificada do Java, executada sobre uma máquina virtual Java reduzida, a KVM, que demanda menos recursos que a JVM (Java Virtual Machine).

O J2ME possui duas configurações básicas: CDC (Connected Device Configuration) e CLDC (Connected Limited Device Configuration). O CDC se destina a dispositivos com maior capacidade de processamento, o que permite a presença de recursos não disponíveis na configuração mais básica, o CLDC. Esta, porém, é a configuração utilizada pelos celulares, pagers e alguns PDAS (Personal Digital Assistant) menos poderosos, uma vez que tais dispositivos não dispõem de alto poder de processamento.

Uma vez definida a configuração, entra-se no âmbito dos perfis (profiles), responsáveis por determinar características mais específicas do dispositivo para o qual se está desenvolvendo. O perfil, em conjunto com a configuração, fornece um conjunto de APIs para o desenvolvimento focado no grupo de dispositivos desejado. Assim, no caso do desenvolvimento de aplicações para celulares, utiliza-se a configuração CLDC (versão 1.0 ou 1.1) e o perfil MIDP (Mobile Information Device Profile), na sua versão 1.0, 2.0 ou 2.1.

O MIDP 1.0 é compatível com quase todos os aparelhos ativos no Brasil, mas peca em não fornecer tantos recursos quanto a versão 2.0, principalmente no que tange à existência de componentes específicos para a criação de jogos e aplicações multimídia. Estudando-se o mercado brasileiro atual, conclui-se que a melhor escolha para o desenvolvimento de aplicações com J2ME é usando a configuração CLDC 1.1 e o profile MIDP 2.0, que formam uma espécie de padrão da indústria de celulares no momento, dos mais baratos aos mais caros (alguns já suportam MIDP 2.1, mas a compatibilidade é retroativa, ou seja, um celular com suporte a MIDP 2.1 roda código MIDP 1.0 e também 2.0).

A Figura 1, desenvolvida pela Sun [SUN, 2008], fornece uma visão geral da plataforma Java. Nessa figura, é possível visualizar o JavaME. No caso dos celulares, a camada-base é a KVM. A camada de configuração, CLDC, está logo acima, sob a camada de perfil, MIDP. Por fim, sobre o MIDP, ainda podem existir pacotes opcionais, como os SDKs (Software Development Kit) da Nokia, por exemplo, fornecendo maiores facilidades para os desenvolvedores.

Figura 1 [SUN, 2008]

Ferramentas

Para executar as aplicações desenvolvidas em J2ME no computador faz-se necessário o uso de um emulador. A Sun disponibiliza o WTK (Java Wireless Toolkit), um kit que facilita o desenvolvimento e os testes das aplicações J2ME no computador. O WTK conta com um emulador, documentação, exemplos diversos e ferramentas que permitem, entre outras coisas, monitorar o uso de memória da aplicação.

Em conjunto com o emulador, costuma-se utilizar uma IDE (Integrated Development Environment) para facilitar o processo de desenvolvimento. A IDE que será adotada no decorrer deste minicurso é o NetBeans 6.5, que pode ser baixado gratuitamente em seu site oficial (www.netbeans.org). A principal razão para a escolha do NetBeans é a presença de ferramentas visuais que aumentam bastante a produtividade, tais como o Game Builder (muito útil para os jogos) e o Visual Mobile Designer (utilizado para a confecção de telas de aplicação bem como estabelecer o seu fluxo). Apesar dessas ferramentas não substituírem por completo a codificação, podem aumentar a produtividade consideravelmente, desde que usadas na medida certa. A Figura 2 mostra a IDE NetBeans 6.5 integrada ao emulador do WTK 2.5.2 (o NetBeans na sua versão Mobility ou na versão completa já possui o WTK). Pode-se visualizar, ainda, a existência de diversas cenas de um jogo, construídas com o Game Builder.

Figura 2

O MIDlet

Uma aplicação JavaME é chamada de MIDlet, de forma análoga aos Applets

(aplicações que são executadas no navegador) e os Xlets (aplicações de TV Digital).

Os MIDlets são controlados por um gerenciador chamado de AM (Application

Manager). A Figura 3, desenvolvida por Fonseca [FONSECA, 2005], demonstra o

ciclo de vida de um MIDlet. Quando um MIDlet é invocado, o Application Manager faz

uma chamada ao método startApp(), responsável por tornar o estado do MIDlet “ativo”,

conforme pode ser visto na figura. No decorrer da execução, a aplicação pode ser

pausada, seja por desejo do usuário ou por uma chamada ou mensagem recebida.

Quando isso ocorre, é executado o método pauseApp() do MIDlet. A própria aplicação

pode pausar a si mesma se necessário, utilizando o método notifyPaused(). Nesse

momento, o estado da aplicação se torna “pausado”. Já quando a aplicação é

finalizada, o método destroyApp() do MIDlet é invocado, seja por parte do AM ou da

própria aplicação, utilizando o método notifyDestroyed(). Nesse caso, a aplicação

entra no estado “destruído”. Percebe-se pela Figura 3, ainda, que do estado

“pausado” pode-se retornar para o “ativo”, pois o método startApp() é novamente

chamado após o fim da pausa. Outra possibilidade é que a aplicação pode ser

finalizada, dirigindo-se diretamente do estado “pausado” para o estado “destruído”.

Figura 3 [FONSECA, 2005]

Classes do JavaME

A Figura 4, também desenvolvida por Fonseca [FONSECA, 2005], mostra a hierarquia

de classes do J2ME ou, mais precisamente, do perfil MIDP. No maior nível da

hierarquia, existe a classe Display, que representa a tela do aparelho. A classe

Displayable, por sua vez, representa qualquer componente que possa ser exibido no

Display e divide-se em dois grupos: as classes de alto nível (que herdam da classe

abstrata Screen) e as classes de baixo/médio nível (representadas pela classe Canvas

e, no MIDP 2.0, também por sua classe filha, a GameCanvas). A classe abstrata

Screen contém quatro subclasses básicas: List, Form, Alert e TextBox. São

consideradas de alto nível porque se comportam para o desenvolvedor como

componentes apropriados para a criação de interfaces, no caso listas, formulários,

mensagens de aviso e caixas de texto, respectivamente. Na outra vertente, a classe

Canvas é a classe derivada de Displayable que representa o topo das classes de

baixo/médio nível, por permitir um controle maior do dispositivo, permitindo ao

programador moldar o display do aparelho livremente. Assim, é visível que a classe

Canvas é de extrema importância para o desenvolvimento de interfaces ricas e, por

isso, requer atenção especial. As demais classes, derivadas de Screen, apesar de

serem bastante úteis para o desenvolvimento de aplicações gerais, geralmente são

substituídas, em aplicações comerciais, por telas mais ricas que utilizam o poder de

Canvas.

Figura 4 [FONSECA, 2005]

A Figura 5, por sua vez, mostra a hierarquia de classes expandida, incluindo as

classes derivadas de Screen e outras classes presentes apenas no MIDP 2.0 ou

superior, bastante úteis para jogos e animações, como a classe Sprite.

Figura 5

Classe Screen e suas derivadas

Como dito anteriormente, a classe Screen possui diversos componentes destinados a

criação de elementos úteis para a interface de uma aplicação qualquer. Esses

elementos são representados por classes derivadas de Screen, como List, TextBox,

Alert e Form.

A classe Alert é responsável pela criação de mensagens de alerta ao usuário. Essas

mensagens se caracterizam por possuírem um tempo pré-determinado de exibição. Ao

término desse tempo, a mensagem desaparece.

A classe Form é utilizada para a criação dos famosos “forms”, comuns em ferramentas

RAD. Um Form é composto por componentes denominados Item.

Pode-se entender o Form como um agrupamento lógico de itens, tais como TextField,

DateField, ChoiceGroup, Gauge, ImageItem e StringItem. Assim, o Form disponibiliza

métodos como insert, para adicionar um Item, delete, para remover um Item, além de

outros métodos úteis, como append e set.

List, por sua vez, é responsável por criar listas seletivas. Podem ser listas de múltipla

escolha ou única escolha, sendo os itens selecionados pelas teclas de navegação ou

teclas de atalho do aparelho.

Por fim, a TextBox, como o próprio nome diz, é uma caixa de texto. Uma instância de

TextBox possui um título que é mostrado na parte superior da tela, um subtítulo ou

texto descritivo, o tamanho da caixa (em caracteres) e o tipo de dado do campo.

A Figura 6 mostra todos esses componentes, além da classe Canvas (responsável

pelas telas de baixo nível, Command (comandos que são adicionados na tela para

reger a navegação do aplicativo) e a interface CommandListener, responsável por

definir ações para os comandos adicionados às telas.

Figura 6

Classe Canvas

Canvas é a derivada de Displayable (vide Figura 6) que permite ao programador uma

manipulação da tela em mais baixo nível. Utilizando a classe Graphics, por exemplo,

podem-se desenhar primitivas (quadrados, retângulos, linhas), inserir imagens e

caracteres em qualquer posição da tela. Permite, ainda, a manipulação de threads

para a criação de animações e a manipulação de eventos, que podem ser acionados

pelas teclas do aparelho, por exemplo.

No caso das animações, é usual utilizar a estratégia de renderização dependente de

tempo. Para isso, o uso das classes Timer e TimerTask é recomendado.

Pacote Game do MIDP 2.0

O MIDP 2.0 presenteia os programadores de jogos com um pacote especial para

jogos, o Game API. Esse pacote provê uma série de classes que possibilita o

desenvolvimento de jogos ricos para os dispositivos móveis.

As classes disponibilizadas pelo pacote são: GameCanvas, Layer, LayerManager,

TiledLayer e Sprite.

A classe GameCanvas é uma subclasse de Canvas e provê as funcionalidades

básicas de tela. GameCanvas traz uma série de melhorias em relação a Canvas,

como a captura dos estados das teclas especiais e uma melhor sincronização gráfica.

Layer é uma classe abstrata que representa um elemento visual do jogo, como um

Sprite ou um TiledLayer. Layer provê atributos básicos, como a localização, o tamanho

e a visibilidade do elemento.

LayerManager, como o próprio nome diz, é um gerenciador de camadas. Através

dessa classe, é possível trabalhar a interface do jogo em camadas, possibilitando que

se façam alterações em uma camada enquanto outra está sendo mostrada na tela.

Esse recurso é extremamente interessante para a criação de jogos.

TiledLayer permite ao desenvolvedor a construção de grandes áreas gráficas que são

subdivididas em células, denominadas tiles. Pode-se imaginar um TiledLayer como

uma tabela dividida em linhas e colunas na qual cada célula apresenta uma imagem,

que pode ser facilmente manipulada. Esse recurso facilita muito a construção dos

jogos tile-based, tais como puzzles¸ rpgs, etc.

Por fim, a classe Sprite, que permite a divisão de arquivos de imagens em frames,

além de transformações sobre essas imagens e, ainda, detecção de colisão. Sprite

provê uma série de métodos que tornam a animação de personagens uma tarefa fácil

e rápida. Sprite também pode ser muito útil para criação de aplicações com interfaces

ricas, podendo representar botões, barras de progresso e outros componentes de

interface que possuam algum tipo de animação.

Persistência de dados no JavaME

A persistência de dados no JavaME se dá através do RMS (Record Management

Store), um esquema de armazenamento bastante simples. Uma aplicação pode

acessar múltiplos Record Stores e cada um pode ter uma quantidade variável de

registros. Alguns aparelhos limitam o tamanho máximo de um Record Store (para a

ordem de algumas dezenas ou centenas de Kbytes), aconselhando-se, assim, que os

mesmos possuam tamanho reduzido.

O RMS possui recursos interessantes, como navegar pelos registros através de uma

enumeração que é instância da classe RecordEnumeration, além de filtrá-los da

maneira que o programador preferir, implementando uma classe de filtro que herda de

RecordFilter e, também, ordená-los de forma adequada, implementando uma classe

comparadora que herda de RecordComparator.

O armazenamento dos registros no RMS é seqüencial, bem como o seu acesso, que é

relativamente lento. Se o RMS for muito grande, poderá haver atrasos significativos no

acesso aos registros, principalmente quando estiverem sendo utilizados filtros e

comparadores nas consultas. A Figura 7 mostra como funciona o RMS internamente.

Como se pode notar, o acesso é seqüencial, pouco diferindo da leitura de um arquivo,

por exemplo.

Figura 7

APIs opcionais

Além das classes acima citadas, disponibilizadas obrigatoriamente em uma

implementação JavaME com configuração e perfil adequados, vários outros pacotes

podem estar disponíveis para o programador. São as chamadas APIs opcionais,

disponibilizadas através de JSRs (Java Specification Requests). Essas APIs estão

disponíveis em alguns aparelhos e em outros não, dependendo exclusivamente das

capacidades do mesmo e da vontade do fabricante em questão em fornecê-las. Entre

elas, destacam-se: WMA 2.0 (Wireless Messaging API), disponibilizada com a JSR

205 e que permite o envio e recebimento de SMS/MMS; MMAPI 1.1 (Mobile Media

API), disponibilizada com a JSR 135 e que permite a manipulação da câmera do

aparelho e outros recursos multimídia; Bluetooth API, disponibilizada com a JSR 82 e

que permite comunicação entre aplicações através de Bluetooth; Mobile 3D Graphics

API, disponibilizada através da JSR 184 e que permite a criação de jogos e aplicações

tridimensionais; entre outras. Algumas dessas APIs serão mostradas no decorrer do

minicurso.

Conhecendo os celulares

Após testar as aplicações no emulador, é necessário estudar os dispositivos para os

quais se pretende portar a aplicação, suas capacidades e limitações. No caso da

Nokia, o Fórum Nokia possui um acervo com todos os dispositivos da empresa e suas

respectivas especificações, que pode ser acessado em http://forum.nokia.com. Cada

aparelho listado possui informações de memória disponível, capacidade de

processamento, dimensões de tela e, ainda, características específicas da

implementação do JavaME naquele aparelho, como a configuração utilizada (CLDC

1.0 ou 1.1), o perfil (MIDP 1.0, 2.0 ou 2.1) e as APIs opcionais que ele apresenta.

Além disso, é possível baixar os kits de desenvolvimento para o grupo de aparelhos no

qual se está desenvolvendo. No caso da Nokia, existem emuladores para cada família

de aparelhos (Series 40 ou Series 60). Esses emuladores representam com maior

fidelidade a máquina Java daqueles aparelhos e, com isso, tem-se uma garantia maior

que sua aplicação funcionará adequadamente nesses dispositivos.

Referências

[FONSECA, 2005] Fonseca, Enrico. iMasters – Ciclo de vida do MIDlet. Disponível

em: http://imasters.uol.com.br/artigo/3416/java/ciclo_de_vida_do_midlet. Acessado em 13 de janeiro de 2008.

[SUN, 2008] Sun Microsystems – Sun Developer Network (SDN). JavaME

Technology – Powering your Devices Everywhere. Disponível em:

http://java.sun.com/javame/technology/index.jsp. Acessado em 13 de janeiro de 2008.