ipal>PAN> 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).

O desenvolvedor, para não perder o mercado consumidor restringindo os celulares compatíveis com sua aplicação, tem duas soluções no desenvolvimento tradicional para J2ME. Ou utilizar somente os recursos mais simples que todos os celulares suportam (utilizando somente as API’s do perfil MIDP 1.0) ou construir uma versão diferente para cada aparelho (ou família de aparelhos) usando o máximo de recursos que cada aparelho suporta. A segunda solução é mais trabalhosa pois implica na manutenção de código fonte para vários aparelhos, porém é também mais vantajosa do ponto de vista do consumidor, pois possibilita o desenvolvimento de aplicações mais complexas e conseqüentemente mais atrativas para os usuários.

Desse cenário surge a motivação para esse artigo: como desenvolver uma mesma aplicação para múltiplas plataformas sem o fardo de manter vários códigos-fonte utilizando as diretivas de pré-processamento para otimizar a aplicação para cada aparelho? Isso será mostrado utilizando o estudo de caso, em que uma mesma aplicação é criada utilizando as técnicas de desenvolvimento tradicional e as ferramentas do NetBeans Mobility Pack.

NetBeans 4.1 Mobility Pack

O Mobility Pack foi desenvolvido para agregar ao NetBeans a capacidade de desenvolvimento de aplicativos MIDP (você pode fazer o download do Mobility Pack junto com o NetBeans ou separadamente, para instalar na sua versão do NetBeans – ambos estão disponíveis no site www.netbeans.org). A lista resumida de funcionalidades é:

·         Suporte a J2ME MIDP 2.0 e CLDC 1.1.

·         Suporte a emuladores fornecidos pelos fabricantes. Os fabricantes fornecem emuladores específicos dos seus aparelhos e com o Mobility pack, o desenvolvedor pode integrar esses emuladores para usá-los em seus projetos.

·         Integração ao J2ME Wireless ToolKit 2.2. Integração para usar os emuladores fornecidos no WTK dentro da interface do NetBeans.

·         Integração a obfuscação (técnicas empregadas para dificultar a recuperação do código original através de decompiladores) e suporte a otimização (capacidade de otimizar os códigos em termos de tamanho e performance).

·         Suporte a configuração e diretivas de pré-processamento: essa funcionalidade vai ser abordada em detalhes nesse artigo.

Configurações e habilidades

Para utilizar as diretivas de pré-processamento, o NetBeans 4.1 Mobility Pack faz uso de configurações e habilidades. Configuração é o termo que o NetBeans utiliza para aparelho-alvo. Ou seja, cada aparelho (ou família de aparelhos) tem uma configuração específica. Para cada configuração definida, o NetBeans irá compilar um arquivo Jar específico para essa configuração, contendo o código definido para essa configuração.

O Mobility Pack define também habilidades, que podem ser associadas às configurações. As habilidades são características que definem as configurações. A Nota 1 apresenta a forma de utilização das configurações e habilidades dentro do NetBeans.

Por exemplo, reveja a Figura 1. Os dois aparelhos podem ser configurações – Nokia6600 e SonyEricssonk300, enquanto suas características e API’s podem ser habilidades – MIDP2, Java3D, Bluetooth. Assim, a configuração Nokia6600 teria as habilidades MIDP2 e Bluetooth, enquanto a configuração SonyEricssonK300 teria as habilidades MIDP2 e Java3D. Quando o código for compilado, dois arquivos Jar diferentes serão criados – um para o Nokia6600 e outro para o SonyEricssonK300, e essas habilidades serão levadas em conta na hora da compilação. ...

Quer ler esse conteúdo completo? Tenha acesso completo