Artigo Webmobile 8 - Multi-Plataforma em J2ME

Esse artigo faz parte da revista WebMobile Edição 08. Clique aqui para ler todos os artigos desta edição

Clique aqui para ler esse artigo em PDF.

Multi-Plataforma em J2ME

Utilizando os blocos de pré-processamento no NetBeans 4.1

 Embora a plataforma de desenvolvimento J2ME/MIDP seja multi-plataforma por natureza, a grande variedade nas características dos aparelhos celulares implica que isso nem sempre seja verdade. Construir um aplicativo que funcione com o mesmo arquivo Jar (Java byte codes) em todos os aparelhos é muito difícil e, portanto, é comum encontrar aplicações comerciais com arquivos Jar diferentes para cada aparelho. Isso acontece porque a aplicação normalmente quer utilizar ao máximo os recursos do aparelho – e para isso são necessárias pequenas mudanças nas aplicações para cada aparelho.

Com o objetivo de apoiar o desenvolvimento de um aplicativo que rode em diferentes plataformas, o NetBeans 4.1 Mobility Pack oferece uma ferramenta muito útil para tratar, no mesmo código, as diferenças de cada aparelho – através de diretivas de pré-processamento. Com elas, você pode modificar a sua aplicação de forma a maximizar o uso de recursos de cada aparelho. Neste artigo fazemos uma breve introdução do NetBeans 4.1 Mobility Pack, ensinamos como utilizar as diretivas de pré-processamento na teoria, discutimos alguns efeitos práticos do uso dessa ferramenta na construção de aplicações reais e, então, fazemos um estudo de caso de uma aplicação utilizando as duas formas de desenvolvimento.

Introdução

Os primeiros celulares com suporte a Java tinham compatibilidade com o perfil MIDP 1.0. Inicialmente as funcionalidades desse perfil eram bastante limitadas, até mesmo devido à limitação no hardware dos aparelhos da época. Além disso, não se sabia na época que o J2ME seria difundido como é hoje. Com o avanço dos aparelhos celulares, as funcionalidades desse perfil se tornaram insuficientes. Alguns exemplos de funcionalidades que esse perfil não cobria são: suporte a uma aplicação tela cheia, suporte a multimídia, conexão segura e manipulação direta de imagens. Sendo assim, os fabricantes foram obrigados a criar API’s específicas para os seus celulares, preenchendo ao menos as funcionalidades mais críticas para o desenvolvimento de aplicações.

Parte desse problema foi solucionada com a criação do perfil MIDP 2.0, que englobou várias funcionalidades que faltavam ao MIDP 1.0. O perfil MIDP 2.0 fornece algumas API’s padrão para fazer algumas coisas que antes só poderiam ser feitas com o uso de API’s proprietárias dos fabricantes. Um exemplo é o uso de tela cheia, que no MIDP 2.0 pode ser utilizado diretamente (no MIDP 1.0 os fabricantes forneciam API’s específicas para seus aparelhos (como o FullCanvas, da Nokia API)).

Tudo isso contribuiu para tornar o cenário ainda mais heterogêneo. Existem alguns aparelhos com suporte apenas ao MIDP 1.0, outros com suporte ao MIDP 1.0 e API’s proprietárias dos fabricantes, e outros ainda com suporte ao MIDP 2.0. Para complicar ainda mais esse cenário, existem funcionalidades que não são cobertas dentro do MIDP 2.0, como o acesso ao Bluetooth, que é feito pela JSR 82 (Java Specification Request – Requerimento de Especificação Java).

Para ilustrar esse cenário heterogêneo observe a Figura 1. Ela mostra dois aparelhos novos com suporte a J2ME MIDP 2.0: Nokia 6600 e Sony-Ericsson k300i. Você poderia pensar que os dois aparelhos são similares no que diz respeito ao desenvolvimento de aplicações. Entretanto, as API’s que cada máquina virtual suporta são bem diferentes, o hardware dos aparelhos é diferente, as capacidades de cada um são diferentes. Tudo isso vai implicar em mudanças na forma de pensar do desenvolvedor de aplicações. Apenas para ilustrar os pontos principais: o Nokia 6600 possui suporte a CLDC 1.0, enquanto o Sony-Ericsson k300i possui suporte a CLDC 1.1. Para o desenvolvedor, isso quer dizer que o Sony-Ericsson k300i tem suporte a tipos primitivos de ponto flutuante (float e double), enquanto o Nokia 6600 não possui. Além disso, o k300i tem suporte ao Java 3D (muito usado para o desenvolvimento de jogos), enquanto o 6600 tem suporte a conexões Bluetooth pela JSR 82 (o k300 nem possui o hardware para o Bluetooth). A diferença no tamanho da tela influencia bastante no desenvolvimento de jogos, pois modifica o tamanho das imagens que serão utilizadas para renderizar a tela. Por fim, as diferenças de capacidade de memória implicam em um maior gerenciamento da memória alocada pela aplicação, para que a máquina virtual não caia por OutOfMemoryError (erro ocasionado por falta de memória na máquina virtual).

Figura 1. Comparativo entre o Nokia 6600 e o Sony-Ericsson K300i (ambos com o perfil MIDP 2.0).

Somando ainda mais a esse cenário heterogêneo, surge a necessidade de se construir uma aplicação portável. Com isso, temos um problema de difícil solução: Como criar uma aplicação portável, que maximize a utilização de recursos e minimize o tempo de desenvolvimento? Não existe uma solução simples para essa pergunta, mas o NetBeans 4.1 Mobility Pack fornece uma ferramenta que ajuda a resolver este problema através de um mecanismo que não existe na maioria dos compiladores Java e nem é previsto pela linguagem. Isso ocorre através das diretivas de pré-processamento.

Esse termo é muito comum para desenvolvedores C para o sistema Unix, onde o mesmo código-fonte deve ser compilado para arquiteturas de processadores diferentes, com diferentes conjuntos de API’s de cada distribuição Unix. Ele permite definir blocos de código que serão inseridos ou descartados durante o processo de criação do arquivo executável (ou o arquivo Jar, no caso de J2ME). Um exemplo são as mensagens de debug que devem aparecer no desenvolvimento, mas não podem aparecer na versão final do produto. Marcando esse trecho de código para pré-processamento, o desenvolvedor pode escolher, na hora da compilação, se ele vai ser inserido (versão de testes) ou retirado (versão final)."