Artigo Java Magazine 45 - Mini-curso: programação Java ME

Mini-curso

Programação Java ME

Parte 2: Ferramentas e Primeiros Passos

Comece a programar para a plataforma Java ME, com o Wireless Toolkit e o Eclipse, MTJ e EclipseME

Este artigo continua a série iniciada na edição anterior, na qual introduzimos toda a complexa variedade de configurações, perfis e APIs que fazem parte da plataforma Java, Micro Edition. (Note que este artigo é bastante independente do anterior, podendo ser acompanhado inteiramente tendo-se apenas conhecimento inicial sobre Java ME.)

Como anunciado, daqui em diante iremos nos concentrar na configuração CLDC e no perfil MIDP, por serem os mais populares – e de aplicabilidade mais provável – devido à enorme disponibilidade dos dispositivos que implementam este perfil, os telefones celulares.

Aliás, se você tem um celular razoavelmente recente, este é um aparelho tão poderoso que usá-lo para fazer ligações de voz parece um desperdício! Algo como usar uma Ferrari para ir comprar pão na esquina. Vamos, então, pôr as mãos à obra e dar um bom uso à surpreendente capacidade de processamento que carregamos no bolso.

Ferramentas para MIDP

O programador Java moderno está habituado a ferramentas de desenvolvimento de alto nível, e se precisamos delas para criar sofisticadas GUIs (interfaces gráficas) ou gigantescos servidores “Enterprise Edition”, não é porque o Java ME é “micro” que nos contentaremos com ferramentas rudimentares. Pelo contrário, existe hoje uma boa variedade de IDEs com bom suporte para esta variante do Java.

Conheceremos três destas ferramentas aqui: o Wireless Toolkit (WTK) da Sun, e os plug-ins para Eclipse MTJ e EclipseME. Vamos explorar as funcionalidades disponíveis nestes programas, a sua configuração, e usar um projetinho “alô mundo” para nos ambientarmos. No próximo artigo da série, cobriremos também o NetBeans Mobility Pack, e construiremos uma MIDlet completa (mas sem depender de nenhum IDE ou plug-in específico, somente do WTK).

Trabalhando com o Java Wireless Toolkit

O WTK é o “JDK do Java ME”, por dois motivos. Primeiro, contém ferramentas essenciais para desenvolvimento para Java ME, como o pré-verificador (bin/preverify), o emulador de dispositivos CLDC (bin/emulator), e as bibliotecas necessárias para compilar e testar seus programas. Segundo, ferramentas mais avançadas, como plug-ins de IDEs, costumam depender do WTK. Se você instalar algum IDE ou mesmo um plug-in Java ME que não exige uma instalação prévia do WTK, tipicamente é porque o WTK já vem embutido.

O WTK pode ser baixado de java.sun.com/products/sjwtoolkit. Neste artigo apresentamos o WTK 2.5, cujo release final foi recentemente disponibilizado. Este release necessita do Java SE 5.0 ou superior. Se você já usou versões anteriores do WTK, veja o quadro “As novidades do WTK 2.5”.

Figura 1. Tela principal do WTK.

Após a instalação, execute o Wireless Toolkit (ktoolbar). Ao contrário do JDK, que só oferece ferramentas de linha de comando, o WTK inclui muitas ferramentas gráficas. A Figura 1 mostra a principal delas, o emulator, em ação, logo após compilar e executar um projeto. Para fazer esta execução de teste, selecione Open Project, abra um projeto (é apresentada uma lista com todos os demos incluídos no WTK), e execute-o com Run. Você verá um emulador de celular, como mostrado na Figura 2. As teclas do aparelho emulado podem ser acionadas pelo teclado ou clicando sobre as mesmas com o mouse. Após a execução, serão exibidas algumas estatísticas de desempenho.

Figura 2. Emulador de celular, exibindo o demo JBricks.

Finalmente, o botão Settings permite visualizar e modificar a configuração de um projeto. A Figura 3 mostra uma das páginas do extenso diálogo de configuração. Este diálogo configura tanto as opções de compilação (que ficam num project.properties no diretório-raiz do projeto) quanto os descritores de deployment (MANIFEST.MF) que as MIDlets exigem.

Figura 3. Propriedades de um projeto do WTK.

 Não investiremos tempo criando programas com o WTK, que não é, sozinho, um IDE completo. Mas apresentaremos uma visão geral das suas ferramentas. A Tabela 1 lista todos os programas encontrados no seu diretório bin, cujo conhecimento é útil mesmo que na maior parte do tempo você use IDEs. Os IDEs, em grande parte, irão automatizar o uso destas ferramentas, portanto os conceitos e capacidades são um aprendizado reusável.

Tabela 1. Programas executáveis do WTK 2.5.

Um fato que já podemos deduzir desta relação de ferramentas, ainda mais se você executá-las e explorá-las um pouco, é que o desenvolvimento de aplicações para celulares, seja com Java ou outra plataforma, pode ser bastante complexo, porque não envolve somente o aparelho. Muitas APIs e operações necessitam também da infra-estrutura da rede móvel.

Por exemplo, o projeto SIPDemo ilustra comunicação P2P com o protocolo SIP (Session Initiation Protocol). Mas isso só vai funcionar se houver um Registrar – uma espécie de serviço de nomes do SIP – na rede. Isso será tipicamente implementado pela própria operadora ou por parceiros que operem na sua rede privada. Já no ambiente de desenvolvimento, tudo precisa ser emulado: o fone, a rede, e quaisquer serviços de rede de que necessitemos. Os diversos utilitários lançados pelo programa utils (Figura 4) fazem isso; na Figura 5, vemos o servidor de SIP.

Funcionalidades de rede que dependem somente dos dispositivos não exigem programas adicionais; por exemplo, se você carregar o projeto BluetoothDemo, pode executá-lo duas vezes, e os dois celulares emulados irão se “enxergar” e se comunicar, como se fosse via Bluetooth.

Figura 4. O lançador utils, mostrando várias ferramentas e serviços de rede móvel.

Figura 5. O serviço SIP Proxy & Registrar, necessário para executar aplicações SIP.

Outra capacidade do WTK que devemos destacar é seu extenso suporte a monitoração de rede. Com o utilitário prefs, página Monitor, você pode ativar diversas opções de monitoração. Após a ativação, inicie novamente o BlueoothDemo no emulador para ver o Network Monitor. Testando com o SIPDemo, podemos examinar o tráfego do protocolo SIP na rede móvel emulada. Veja isso na Figura 6: o monitor faz uma exibição detalhada e bem estruturada não só desse, mas de doze protocolos (afinal, o ponto forte de um celular é a comunicação, não?).

Figura 6. O Network Monitor, destacando a aba do protocolo SIP.

No quesito de desempenho, podemos ativar também um profiler muito completo (também ativado em prefs>Monitor). Veja o quadro “Primeiras palavras sobre desempenho”.

Primeiras palavras sobre Desempenho

...ah não, lá vem o Osvaldo com sua obsessão por desempenho, mal começou a série e ainda nem vimos uma linha de código! Bem, neste caso isso é justificado. Os dispositivos não são chamados “limitados” devido ao seu tamanho, e sim devido à falta de gigahertz, gigabytes, e gigabits-por-segundo. Programadores habituados com técnicas, ferramentas e frameworks de altíssimo nível – que fazem tudo ficar mais fácil, porém maior e mais lento – têm dificuldade em entrar no mundo do Java ME, onde não existe nenhum “giga”. Será preciso ter parcimônia ao gastar tempo, espaço e banda. O exemplo que se segue é um primeiro pontapé para acordar seus instintos de hacker escovador de bits!

A Figura Q1 mostra o resultado do profiling do demo JBricks (Figura 2), o milésimo clone do clássico jogo Breakout[1]. O resultado do profile é extremamente revelador: parece que o programa está gastando nada menos que 47% do tempo de processamento (cycles) num único método de API, Graphics.drawArc(). Suspeitei, e verifiquei nos fontes (Ball.java), que o jogo usa este método para desenhar a bolinha, o único elemento animado na maior parte dos frames. Se fosse numa VM Java SE, cujas operações gráficas são aceleradas pela Java 2D e por modernas placas de vídeo, isso não teria importância: desenhar uma bolinha com uma dúzia de pixels de diâmetro teria um custo desprezível. Mas no Java ME não é bem assim. Muitos celulares já têm boa aceleração de gráficos 2D, mas isso não é algo com que você possa contar, especialmente nos aparelhos mais baratos. (E só os modelos de última geração, ainda muito caros, têm aceleração 3D.) Então, essa forma de desenhar a bolinha do jogo é absurdamente ineficiente[2].

Ineficiente e sem nenhuma justificativa: a bolinha nunca muda, e quanto à qualidade, veja a Figura Q2: é péssima, pois algoritmos de rasterização de curvas são notoriamente ruins com tamanhos muito pequenos e especialmente sem antialiasing. Esta bolinha certamente teria um aspecto muito melhor se fosse desenhada à mão, pixel por pixel, e gravada numa imagem estática como resource do programa, exigindo apenas um (eficiente) Grapics.drawImage() a cada frame.

Morais da história:

1.      As plataformas mais limitadas suportadas pelo Java ME nos obrigarão a esquecer alguns vícios de programação para desktop e servidores, como ficar muito à vontade com técnicas tão lentas quanto desenho de curvas, parsing de XML, ou frameworks ultra-abstratos que parecem teses de PhD em design patterns.

2.      Use os programas de monitoração do WTK. São ferramentas excepcionais, e irão poupá-lo de muita dor de cabeça.

Figura Q1. Profiler de métodos. No lado esquerdo vemos a árvore de invocações de métodos, com o tempo relativo gasto por cada um. No lado direito, estatísticas detalhadas de execução de todos os métodos dentro do nó selecionado na árvore.

Figura Q2. A bolinha do jogo JBricks, ampliada. Como descobrimos, o programa desenha esta bolinha, incluindo efeitos de sombra e brilho, com várias operações gráficas, inclusive a drawArc() que consome quase metade de toda a CPU usada pelo programa. E tudo isso para um resultado imperfeito.

As Novidades do WTK 2.5

Após um longo período sem releases estáveis – o WTK 2.3 nunca saiu de beta, e a versão anterior foi o 2.2 no final de 2004 – a versão 2.5 restaura o status de produção ao toolkit do Java ME. A lista de novidades, comparando com o WTK 2.2, é extensa.

Muitos itens são suporte para novas APIs: Security and Trust Services (JSR 177), Location (JSR 179), SIP (JSR 180), Content Handler (JSR 211), Scalable 2D Vector Graphics (JSR 226), Payment (JSR 229), Advanced Multimedia Supplements (JSR 234), Mobile Internationalization (JSR 238), Java Binding for the OpenGL ES (JSR 239). (Veja o artigo anterior desta série para mais sobre estas APIs.)

O suporte às APIs da plataforma ME costuma ser mais difícil que em Java SE/EE: normalmente não basta apenas adicionar um JAR com as novas classes no classpath. Ferramentas do WTK, em especial o emulador, precisam ser modificadas para dar suporte a muitas das novas APIs, e algumas dessas APIs precisam de ferramentas novas (ex.: a SIP API necessita da siptool). Por isso, a adição de novas APIs Java ME costuma exigir novas versões do WTK.

A ktoolbar, que pode ser considerada um mini-IDE – não possui editor de código ou depurador, mas inclui facilidades de gerenciamento de projeto, compilação e testes – foi reconstruída sobre a NetBeans Platform. Também há melhoras no emulador e em praticamente todas as demais ferramentas.

Outra novidade importante é o suporte à MSA. Veja o quadro “JTWI e MSA: As novas especificações da plataforma CLDC”.

JTWI e MSA: As novas especificações da plataforma CLDC

No artigo anterior comentamos todas as configurações, perfis e extensões do Java ME, o que é um panorama confuso, pois mesmo havendo API padronizadas para quase tudo, os dispositivos variam no número de APIs que cada um implementa. Em alguns casos a variação é inevitável devido à fragmentação do próprio hardware: por exemplo, não adianta obrigar todos os dispositivos CLDC/MIDP a implementar a JSR 82 (Bluetooth & OBEX), pois nem todos os aparelhos possuem as interfaces físicas correspondentes. E a maioria dos que não possuem nem permite adicioná-las – celulares e PDAs em geral não são uma arquitetura aberta como os PCs, onde milhares de periféricos podem ser adquiridos posteriormente e conectados a slots PCI, portas USB e outras interfaces.

No entanto, os dispositivos estão em constante evolução, e também os serviços e protocolos utilizados nas redes wireless. E há muitas APIs que não são dependentes de capacidades específicas de hardware, e só não são obrigatórias hoje devido a fatores como o tamanho (consumo adicional de ROM). Além disso, existe uma necessidade de maior padronização de comportamentos detalhados: por exemplo, quais variações do formato de arquivo JPEG são obrigatoriamente suportadas, ou qual a resolução mínima do clock (usada por System.currentTimeMillis() e Timer, e importante para qualquer manipulação de mídia ou jogo animado). Para melhorar esta situação existem duas especificações de plataforma adicionais, a JTWI e MSA, que por motivo de espaço não comentamos no artigo anterior.

A JTWI

A JTWI procurou reduzir a fragmentação do mercado de dispositivos por volta de 2003, agregando o CLDC 1.0 e MIDP 2.0 (ou versões superiores) a uma coleção um pouco maior de APIs obrigatórias: JSR 135 (Mobile Media) e 205 (Wireless Messaging).

Mais que exigir novas APIs, a JTWI também inclui esclarecimentos de algumas questões de interoperabilidade e segurança, e exigências maiores de capacidade dos dispositivos. Por exemplo, a tela deve ter no mínimo 128x128 pixels com 4.096 cores / tons de cinza. (O MIDP 2.1 ainda se contenta com 96x54, preto e branco.)

Também há exigências de comportamento mais estritas para algumas API: por exemplo, a resolução do clock deve ser de pelo menos 40 milissegundos; cada aplicação deve poder criar pelo menos cinco Record Stores, e pelo menos cinco timers simultâneos... e por aí vai. Estas exigências extra significam que os dispositivos identificados como compatíveis com a especificação JTWI oferecerão ao desenvolvedor uma quantidade maior de APIs e capacidades padronizadas, melhorando a portabilidade das aplicações.

A JTWI, agora com quatro anos de idade, já pode ser considerada como nível mínimo de compatibilidade para qualquer aparelho MIDP fabricado nos últimos dois anos.

A MSA

A JTWI foi um bom tapa-buraco para deficiências das especificações CLDC 1.0 e MIDP 2.x. Mas para a nova geração de aparelhos a partir deste ano, há uma nova especificação mais ambiciosa, a MSA ­– Mobile Systems Architecture (JSR 248)[3] – cujo release final saiu em dezembro de 2006. Quando você ler este artigo, já deveremos ter os primeiros produtos compatíveis no mercado.

A primeira boa notícia é que a MSA exige a CLDC 1.1 e a MIDP 2.1, enterrando de vez o CLDC 1.0 (que não suporta números float e double, um enorme impedimento para portabilidade; mas felizmente, o CLDC 1.1 já é padrão de fato no mercado, e na prática já não precisamos nos preocupar com dispositivos CLDC 1.0).

Em cima disso, a MSA torna seis extensões obrigatórias: as duas do JTWI e mais as JSRs 75 (FileConnection & PIM), 82 (Bluetooth), 184 (M3G) e 226 (SVG). Também relaciona mais oito APIs opcionais: 172 (Web Services), 177 (Security & Trust), 179 (Location), 180 (SIP), 211 (Content Handler), 229 (Payment), 234 (Multimedia Supplements) e 238 (I18N).

Um dispositivo “MSA” deve conter todas estas 14 APIs extra; um dispositivo “MSA Subset” deve conter as seis obrigatórias. Comparando com os aparelhos hoje no mercado, a maioria dos aparelhos intermediários já possui as APIs da MSA Subset, pois Bluetooth, MMAPI, SVG e mesmo M3G já são amplamente suportadas. Já a MSA “full” inclui várias APIs ainda raras em aparelhos mais comuns. Em compensação, daqui a 1-2 anos quando a maioria dos aparelhos já for aderente à MSA “full” com todas estas 14 APIs além de outras exigências, os desenvolvedores poderão contar com uma oferta muito maior de APIs cuja presença poderá ser presumida em qualquer aparelho.

A MSA é uma extensão da JTWI, pois além de exigir as mesmas APIs e mais outras 12, a MSA também inclui as mesmas clarificações e exigências de comportamentos de APIs. E inclui ou aumenta outras. Por exemplo, a tela deve suportar pelo menos 65.536 cores, o número mínimo de Record Stores por aplicação sobe de cinco para 10, etc.

Trabalhando com o Eclipse, opção 1: Mobile Tools for Java

Apesar de todas as capacidades do WTK, precisamos de um ambiente de desenvolvimento mais completo: com editor, depurador e outras ferramentas, tudo isso integrado às facilidades do WTK. Investigaremos em primeiro lugar o suporte para Java ME do IDE Eclipse.

O suporte para Java ME é um ponto fraco histórico do Eclipse, que até há pouco tempo nem tinha subprojetos específicos para as plataformas “micro”, deixando seus usuários dependentes de soluções de terceiros. Felizmente havia o projeto EclipseME, também open source, porém não muito avançado. Isso além de outras soluções comerciais.

Ainda que com atraso, a Fundação Eclipse acordou para a demanda, disparando em 2006 uma série de projetos para construir ferramentas que suportem plataformas limitadas. O projeto-master é o Device Software Development Platform (DSDP), que contém os subprojetos Device Debugging, eRCP, Mobile Tools for Java (MTJ), Native Application Builder e Target Management. Note que nem todos estes projetos se ocupam exclusivamente de Java ME, pois o escopo da Fundação Eclipse é mais amplo do que a plataforma Java ou, ainda que usando apenas Java, mais amplo do que as APIs abençoadas pelo JCP. Mas neste artigo inicial vamos examinar somente o MTJ, que é o principal: uma extensão do JDT para desenvolver aplicações Java ME.

O MTJ ainda está em desenvolvimento, sendo a versão 1.0 esperada para junho de 2006 (data do release do “Europa” – Eclipse 3.3). Na data em que escrevo, o melhor release estável do MTJ é o 0.7, que ainda é compatível com o Eclipse 3.2.x. Testei o MTJ 0.7 com o Eclipse 3.2.2.

Instalando e configurando o MTJ

Para instalar, basta descompactar o mtj-runtime-<versão>.zip sobre a sua instalação do Eclipse. Ao reiniciar o Eclipse você verá um novo menu MTJ na barra de menu principal, mas isso só contém duas opções, para deployment e gerenciamento de segurança. A configuração principal do MTJ fica em Window>Preferences, veja a Figura 7.

O MTJ precisa de pelo menos uma “definição de plataforma Java ME”; isto é, o Wireless Toolkit. Na página Mobile Tools for the Java Platform>Device Platform, acione Add e selecione o diretório de instalação do WTK, que deverá finalmente aparecer na lista de Device Platforms. Abaixo desta, será exibida a lista de Devices suportados pela plataforma selecionada. Deveremos ver as quatro definições de dispositivos que são incluídas no Sun WTK 2.5.

Figura 7. Configuração do Mobile Tools for Java no Eclipse.

Em seguida, vá à página Runtime Platform e selecione Add. Dessa vez você não escolherá um diretório, e sim uma das Device Platform já cadastradas. A diferença é que a Device Platform é utilizada para compilar os projetos, e a Runtime Platform é usada para executá-los. Na lista de Device Platform, o botão Info permite visualizar detalhes de cada plataforma, ou seja as APIs suportadas. Já na lista de Runtime Platform, o botão correspondente Edit permite visualizar e também customizar o runtime selecionado, como na Figura 8.

Figura 8. Customizando uma definição de runtime do MTJ.

Se você tiver feito o download dos SDKs para Java ME específicos para algum fornecedor de aparelhos – como Nokia, SonyEricsson etc. – estes costumam conter versões customizadas do WTK (provavelmente do WTK 2.2, pois o 2.5 ainda é muito recente na data em que escrevo). A vantagem destes WTKs customizados é que eles possuem definições de dispositivo que correspondem mais fielmente a todos os modelos de celulares daquele fornecedor. Se quiser, você pode configurar o MTJ para utilizar também estas definições. Verifique a documentação do SDK do celular quanto a outras funcionalidades, especialmente capacidades de depuração no aparelho real (que pode exigir mais plug-ins, cabos seriais e novas configurações, detalhes que não cobriremos aqui).

Na página Security, podemos escolher qual gerenciador de segurança será usado pelo MTJ. Pelo menos para mim, o MTJ selecionou por default a opção MTJ Security Manager for IBM’s JRE (v.5.0.0) Keytool. Isso só é boa idéia se você estiver utilizando a JVM da IBM para executar o Eclipse. Se você é como 95% dos usuários do Eclipse e usa a JVM da Sun, selecione a opção MTJ Security Manager for SUN’s JRE (v.1.4.2) Keytool. Da mesma forma, na página Signing, se você não usa a JVM da IBM, selecione o MTJ Signing Provider for SUN’s WTK(v2.2)jadtool.

Criando um projeto

Tudo configurado, na perspectiva Java (o MTJ não cria uma perspectiva específica para Java ME), crie um novo projeto do tipo Mobile Tools for the Java Platform>MIDlet Project. Na primeira página de propriedades do projeto, escolha algum nome, como “AloMundoMTJ”. Na segunda página (Java ME Runtime Platform), escolha uma plataforma. A terceira página também não apresenta novidades e não exige customizações. A quarta página (Configure MIDlet Suite) apresenta várias propriedades descritivas da MIDlet, como nome do JAR, autor e versão, e principalmente, o perfil (mantenha o default MIDP-2.0) e configuração (mantenha CLDC-1.1). Na quinta e última página (Templates), você tem a opção de selecionar um template de projeto; faça isso, escolhendo o único template disponível: Hello_World_MIDP. Este template fará o projeto já ser preenchido com o mínimo de código exigido para uma MIDlet. Acione Finish.

O template Hello_World_MIDP gera um package hello_world_midp_package com uma classe Hello_World_MIDP; nomes bastante inadequados e fora do padrão de estilo do Java, sem dúvida de propósito para lembrar-nos de começar a customizar o código. A Listagem 1 mostra esta classe já um pouco alterada: adicionei código para criar um Command (acionado por uma soft-key do celular), que quando acionado, adiciona uma nova mensagem ao form.

Listagem 1. Código completo da MIDlet AloMundoME.

package alo;

import javax.microedition.lcdui.Command;

import javax.microedition.lcdui.CommandListener;

import javax.microedition.lcdui.Display;

import javax.microedition.lcdui.Displayable;

import javax.microedition.lcdui.Form;

import javax.microedition.midlet.MIDlet;

import javax.microedition.midlet.MIDletStateChangeException;

public class AloMIDP extends MIDlet implements CommandListener {

  protected Form form;

  protected void startApp () throws MIDletStateChangeException {

    Display d = Display.getDisplay(this);

    d.setCurrent(getForm());

  }

  protected void pauseApp () {

  }

  protected void destroyApp (boolean flag) throws MIDletStateChangeException {

  }

  protected Form getForm () {

    if (form == null) {

      form = new Form("Título da Form");

      form.addCommand(new Command("Clique-me!", Command.ITEM, 1));

      form.setCommandListener(this);

    }

    return form;

  }

  public void commandAction (Command c, Displayable d) {

    form.append("Alô... tem alguém aí?\n");

  }

}

As partes da listagem em negrito são o código que adiconei. Observe que, para tratar o evento de comand, fiz a própria classe de MIDlet implementar a interface CommandListener. Num programa Java SE com uma GUI Swing, normalmente criaríamos uma inner class para isso; mas embora seja possível usar inner classes em Java ME, este não é o procedimento normal. Uma inner class aumenta o tamanho do programa, muito mais do que um novo método na mesma classe. Vá se acostumando com estas novas regras... caso contrário, suas aplicações nem vão instalar nos dispositivos reais (muitos rejeitam qualquer JAR com mais de 300 Kb[4]).

Para executá-lo, você poderá se surpreender porque o menu do projeto Run As não apresenta nenhuma opção para MIDlet ou Java ME, só as opções convencionais como Java Application, que não funcionarão. Pode ser uma limitação ou bug da versão 0.7 do MTJ. Então, me acompanhe: Acione Run As>Run, e no final da lista de configurações de lançamento, selecione o nó MTJ Application e escolha New no seu menu de contexto. Isso cria a configuração de lançamento apropriada, já configurada para o seu projeto e classe de MIDlet. Modifique somente o nome da configuração, que deve ser algo como “New Configuration”; veja a Figura 9.

Figura 9. Criando uma configuração de lançamento para o projeto AloMundoME.

Execução e Deployment

Execute Run na configuração. O resultado não será muito surpreendente: o já familiar emulador de celular em execução, exibindo uma tela em branco exceto pelo título, e o item de comando “Clique-me!”, que quando acionado exibe uma mensagem. Se ao acompanhar a seção sobre o WTK você ativou os monitores de rede ou de memória, estes serão lançados junto com o emulador. Assim, todo o poder das principais ferramentas do WTK fica disponível a partir do nosso IDE. Mas como o MTJ ainda não possui páginas de configuração ou ações correspondentes a todas as opções e ferramentas do WTK, você às vezes pode ter que acionar o WTK diretamente, por exemplo, lançando o programa prefs para habilitar ou desabilitar os monitores.

Figura 10. O Eclipse & MTJ em ação.

A Figura 10 mostra o ambiente de desenvolvimento completo, com o programa AloMundoMTJ sendo executado no emulador; a view Output do Eclipse mostrando mensagens do emulator, e outras views comuns de depuração (veja a subseção “Depurando” a seguir).

Na árvore de projetos, vemos que além da pasta de fontes (src), META-INF e resources (res), que são elementos comuns em projetos Java SE ou EE (ainda que o layout dos projetos em IDEs possa variar), temos alguns novos elementos. A pasta verified contém classes que já passaram pelo pré-verificador (o MTJ invoca o programa preverify do WTK). E a pasta deployed contém os arquivos finais para instalação num celular (ou execução num emulador). Resumindo, o fluxo de dependências dos de arquivos é: src (código-fonte Java editado por você) ? bin (arquivos .class compilados pelo Eclipse) ? verified (arquivos .class processados pelo MTJ, que aciona o preverify) ? deployed (arquivos JAR e JAD gerados pelo MTJ).

No sistema de deployment das MIDlets, temos sempre um arquivo JAR e um arquivo JAD, sendo que este último é um descritor que os aparelhos lêem antes de baixar o JAR – para quem já conhece os arquivos JNLP do WebStart, é algo parecido. (No seu sistema operacional, ao clicar no arquivo JAD, o emulator será lançado, desde que o JAR correspondente esteja no mesmo diretório.) A Figura 10 também mostra o editor de arquivos JAD do MTJ. Se você quiser instalar o programa AloMundoMTJ no seu celular para testá-lo “pra valer”, só precisa do AloMundoME.jar.

A configuração mínima que devemos fazer no arquivo JAD é adicionar, na página MIDlets, uma entrada como: Name = Alô Mundo, Class = alo.AloMIDP. A coluna Icon pode ficar em branco. Isto deveria fazer o MTJ gerar um META-INF/MANIFEST.MF com uma linha como “MIDlet-1: Alô Mundo, alo.AloMIDP”, só que isso não funciona. Se você gerar os arquivos de deploy, terá que abrir o JAR e acrescentar esta linha ao META-INF/MANIFEST.MF. (Não adianta editar o MANIFEST.MF que aparece no projeto, pois o MTJ o recria sem a linha “MIDlet-1...”.)

Depuração

Para executar a MIDlet no depurador do Eclipse, você terá primeiro que modificar algumas configurações default do Eclipse, para contornar limitações do emulador do WTK: Em Window>Preferences>Java>Debug, desative as opções Suspend execution on uncaught exceptions e Suspend execution on compilation errors, e aumente Debugger timeout (ms) para 15000 ou mais.

Estas instruções são baseadas na documentação do EclipseME, mas se aplicam a ambos os plug-ins cobertos neste artigo, e provavelmente qualquer outro depurador para Java ME que use o WTK. Se você tentar utilizar o depurador sem ter executado estes “preparativos”, o resultado será uma variedade de erros, de crashes da KVM[5] até breakpoints sendo ignorados.

Para fazer um teste, crie um breakpoint no método comandAction() e acione o comando “Clique-me!” no emulador. A execução deverá ser interrompida, permitindo rodar o programa passo-a-passo, ver variáveis e pilha de invocações etc., como mostrado na Figura 10. Surpreendentemente, até alguns recursos avançados como breakpoints condicionais funcionam. Mas nem tudo; por exemplo, a facilidade “hot code replace” (editar-e-continuar) não funciona – já seria exigir demais da KVM, otimizada para dispositivos enxutos. (Como estas são limitações da máquina virtual, não adianta procurar outro IDE ou plug-in para Java ME.)

MTJ: Em construção...

Já verificamos que o MTJ suporta as funcionalidades essenciais para criar aplicações MIDP, mas este é um projeto ainda em desenvolvimento. Na versão preliminar que testamos (0.7), o MTJ ainda tem algumas limitações:

·          O MANIFEST.MF não é gerado corretamente. Isso não impede o lançamento do programa a partir do IDE / emulador, mas um arquivo JAR sem este arquivo correto será rejeitado por dispositivos reais. Pode-se contornar o problema editando os manifestos à mão.

·          Não há suporte para funcionalidades e ferramentas externas importantes, como ofuscadores de bytecode, Mobile JUnit ou Antenna (comentados adiante, na seção do EclipseME).

·          Não existe editor visual de GUIs.

·          Para aborrecimento dos entusiastas que gostam de acompanhar os mais recentes releases de desenvolvimento do Eclipse, o MTJ ainda não é compatível com o Eclipse 3.3 (testei com o 3.3M5eh). Será necessário usar o Eclipse 3.2. 

Como o MTJ 0.7 é de novembro de 2006 e escrevo em março, é bem possível que, quando você ler este artigo, uma versão melhor esteja disponível (o release 1.0 é esperado para Junho). Mas até lá, se você já tiver passado da fase de investigação e quiser trabalhar seriamente em projetos Java ME, pode ser melhor procurar uma ferramenta alternativa como o EclipseME.

Trabalhando com o Eclipse II: EclipseME

O EclipseME é um projeto open source independente, disponível em eclipseme.org, e que tradicionalmente tem servido às necessidades dos usuários do Eclipse que precisam de suporte à plataforma Java ME. Assim, enquanto o MTJ não fica pronto, podemos usar o EclipseME.

Os dois plugins são parecidos, por isso descreveremos rapidamente a configuração do EclipseME. (Ambos podem ser instalados simultaneamente no Eclipse; fiz isso e não tive problemas.) No Update Manager, utilize a URL http://www.eclipseme.org/updates para instalar o EclipseME.

Vá então em Window>Preferences>J2ME. Na página principal, no grupo Antenna Settings, sete o WTK Root para o diretório-raiz do WTK, e Antenna JAR para o arquivo antenna-bin-<versão>*.jar (que você obterá de antenna.sourceforge.net). Esta biblioteca Antenna é uma coleção de tasks do Ant para Java ME, que é suportada pelo EclipseME. Seu uso não é obrigatório, mas é muito conveniente para os fãs de scripts do Ant (o EclipseME gera os scripts de build).

Na página Device Management, clique Import..., forneça o diretório do WTK e acione Refresh; aguarde a detecção dos devices e confirme com Finish.

Na página Packaging / Obfuscation, forneça o diretório de instalação do ProGuard, um ofuscador e otimizador de bytecode open source (baixe de proguard.sourceforge.net). O ofuscamento não é obrigatório, mas é recomendado para MIDlets. Mesmo que você não precise de proteção contra descompiladores, a redução de tamanho dos JARs proporcionada por ofuscadores é importante. A Figura 11 mostra as páginas de configuração do EclipseME, destacando as opções de ofuscador (muitas podem ser sobrepostas nas páginas de propriedades de cada projeto).

Figura 11. Configuração do obfuscador ProGuard, suportado pelo EclipseME.

Criando o projeto

Crie um projeto do tipo J2ME>J2ME MIDlet Suite; aceite os defaults para as propriedades específicas ao EclipseME. O projeto criado será semelhante ao do MTJ, com os mesmos folders res, verified e deployed (este último criado em demanda quando for feito o primeiro build). Não haverá fontes nem source folder, pois o EclipseME não oferece templates. Crie um source folder src e copie para lá os mesmos fontes do projeto do MTJ.

Edite também o arquivo JAD para registrar a nossa MIDlet. O EclipseME não tem o mesmo bug do MTJ, e irá gerar o MANIFEST.MF corretamente nos arquivos JAR criados.

Testando

Para executar a MIDlet com o EclipseME, também será preciso criar à mão a configuração de lançamento, só que o tipo será Wireless Toolkit Emulator. Note que nesta configuração, na aba Midlet, o default da opção Executable é Over-the-Air; isto significa que o emulador é lançado com uma opção que simula a instalação da MIDlet através da rede móvel. Mas eu tive problemas com esta opção. Com Executable = Midlet <classe>, tudo funcionou corretamente. A execução em modo de debug exige as mesmas configurações do Eclipse que comentamos ao discutir o MTJ.

Escolhendo seu plug-in Java ME para Eclipse

Apesar do atual status – o MTJ em pré-release com algumas limitações e bugs importantes, e o EclipseME mais maduro (sem contar outros plug-ins / IDEs comerciais baseados no Eclipse), não tenha dúvida: o MTJ é o futuro do desenvolvimento Java ME na plataforma Eclipse, pois faz parte de um plano mais abrangente, e é suportado pela Fundação Eclipse.

A semelhança entre os dois projetos, ex.: o editor de JAD é exatamente igual. Isso não é coincidência, pois o código-fonte do EclipseME foi uma das contribuições iniciais para o projeto MTJ. (Outra foi o Carbide.J da Nokia.) O autor do EclipseME, Craig Setera, também faz parte da equipe do MTJ, assim como desenvolvedores da Nokia, SonyEricsson, IBM, e vários outros fornecedores de IDEs e/ou tecnologia de dispositivos móveis. O MTJ (ou mais precisamente o Device Software Development Platform como um todo) é mais um “rolo compressor” da Fundação Eclipse, unificando os esforços de praticamente toda a comunidade e eventualmente resultando num ferramental extremamente completo. Os planos do MTJ incluem, especialmente, a edição visual de GUIs MIDP, que também falta no EclipseME.

Uma das vantagens da absorção destes projetos de terceiros pela Fundação é a maior integração entre todos os seus componentes. Se a equipe do MTJ precisar de um aperfeiçoamento no núcleo do Eclipse ou em seus frameworks (Platform, JDT, VE...), este pedido será atendido com uma presteza bem maior do que seria para uma solicitação externa (a não ser que o interessado implementasse a melhoria por conta própria, o que é possível pois o Eclipse é open source – mas não necessariamente fácil!).

Comprovando isso, já existem discussões sobre algumas destas melhorias. Por exemplo, muitos desenvolvedores de aplicações Java ME utilizam ferramentas de pré-processamento e compilação condicional. Esta é uma facilidade de linguagens como C/C++ que foi banida do design do Java, mas é importante tanto para reduzir o tamanho dos programas quanto para conviver com uma oferta de dispositivos nem sempre tão compatíveis quanto deveriam com as especificações Java ME. O EclipseME já suporta isso – igual a C/C++, com diretivas #include, #define, #ifdef etc. Mas não é um suporte ideal, por exemplo as diretivas de pré-processamento precisam ser colocadas dentro de comentários “//”, ferramentas do JDT como o outliner não reconhecem as diretivas, a compilação exige um novo folder oculto com os fontes pré-processados e é mais lenta, etc. Já no MTJ, estas restrições serão resolvidas porque componentes do JDT, como o editor de código, compilador Java, outliner e outros, serão modificados para dar suporte a pré-processamento. Isso não quer dizer necessariamente que o JDT passe a suportar fontes Java com diretivas de pré-processador; basta que os plug-ins do JDT, como o editor, outliner, depurador e outros, disponibilizem “pontos de extensão” estratégicos que permitem que um outro plug-in, como o MTJ, faça isso.

Conclusões

No primeiro artigo desta série, apresentamos e analisamos a impressionante amplitude de tecnologias, especificações e APIs que formam a plataforma (ou mais precisamente, família de plataformas) Java ME. Neste artigo, começamos a pôr as mãos na massa, vendo que esta plataforma exigem um arsenal de ferramentas que não fica devendo nada aos IDEs para aplicações Enterprise Edition. (Quem eles estão tentando enganar com esse termo “dispositivos limitados”? Podem ser um pouco limitados em CPU e memória, mas certamente, nem tanto em funcionalidades!)

Espero ter ajudado o leitor a vencer a barreira inicial de tantas definições, especificações e ferramentas novas, e a partir daqui, começar a desenvolver aplicações para dispositivos MIDP, o perfil de foco da série deste artigo em diante. No próximo artigo completaremos o assunto de IDEs com o NetBeans Mobility Pack, e começaremos a programar para valer.

Links

java.sun.com/javame

Página oficial do Java ME

java.sun.com/products/midp

Página oficial do perfil MIDP

java.sun.com/products/cldc

Configuração CLDC