O documento descreve um minicurso sobre desenvolvimento de aplicações para dispositivos móveis utilizando JavaME. O minicurso irá cobrir a plataforma JavaME, produção de aplicativos básicos, confecção de telas, desafios de portabilidade, persistência de dados e exemplos de APIs para câmera, SMS e integração com a Web.

1. 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

2. 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.

3. 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.

4. 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”.

5. 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.

6. 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

7. 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

8. 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.

9. 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

10. 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.