Introdução
Após muita reflexão sobre o conteúdo deste post, achei relevante abordar como nossas aplicações são empacotadas, pois esse conhecimento facilitará e contextualizará o leitor para a distribuição das aplicações a terceiros, bem como permitirá testar em telefones celulares reais. Assim, quando codificarmos alguns exemplos e desejarmos testá-los nos ambientes apropriados, já saberemos o essencial para gerar o software – conhecido como gerar um pacote da distribuição.
A Suite de MIDlet
Um MIDlet é uma aplicação Java projetada para ser executada sobre um dispositivo móvel. Mais especificamente, um MIDlet tem no seu core classes do Java de CLDC e MIDP. Uma suite de MIDlet consiste de uma ou mais MIDlets empacotados através de um arquivo JAR (Java ARchive). Bem, em outras palavras, quase todos as aplicações vem com um instalador ou executável no qual rodamos nosso software, no caso de uma aplicação MIDlet, esse padrão obedece a mesma abordagem que Java SE e suas bibliotecas. Será através desse arquivo que o gerenciador da aplicação (AMS - Application Manager Software, post anterior), irá instalar, executar e remover os MIDlets.
Quando o AMS inicia um MIDlet ele basicamente fará as seguintes verificações:
- acesso ao CLDC e a máquina virtual java;
- acesso as classes definidas de MIDP; geralmente definem as implementações das interfaces do usuário, esquema de persistência, suporte a rede através dos protocolos de comunicação (ex. HTTP), tempos e configurações do usuário com o celular;
- acesso ao arquivo JAR; se a aplicação usa arquivos de imagens, estas deverão estar empacotadas neste aquivo JAR, caso contrário ocorrerão erros.
- acesso as informações do arquivo JAD (Java Application Descriptor); Se uma suite de MIDlet tiver um arquivo JAD, então seu conteúdo deverá estar disponível, podendo descrever mais de um MIDlet no mesmo pacote de aplicação.
JAR
Uma aplicação irá geralmente consistir em muitos arquivos. Além das tradicionais classes do Java (arquios .class), adicionalmente teremos imagens, sons e dados diversos, conhecidos como recursos (resources ou res). Dentro do JAR teremos obrigatoriamente um arquivo que define todas as propriedades da aplicação, bem como o MIDlet Suite. Esse arquivo segue a regra de Java SE, me refiro ao arquivo MANIFEST (manifest.mf). A figura 1 ilustra as propriedades desse arquivo.
As principais propriedades são aquelas que indicarão para o AMS o nome de nossa aplicação, a sua localização do nome da classe MIDlet (pode conter vários pacotes no caminho), a versão do CLDC e MIDP. Na prática, toda vez que desejarmos testar nossa aplicação em algum celular necessitaremos especificar esse arquivo, pois caso contrário, o AMS não encontrará o MIDlet para ser executado. Vejamos um exemplo real de um MANIFEST da aplicação Mobile English Learning que estou mantendo:
Manifest-Version: 1.0
MIDlet-Vendor: Oxe Tche group
MIDlet-Version: 1.0.0
MIDlet-1: English Learning,res/firststeps16.PNG,oxetche.EnglishLearningMIDlet
MicroEdition-Configuration: CLDC-1.1
MIDlet-Name: English Learning
MicroEdition-Profile: MIDP-2.0
Já o arquivo JAD desta aplicação possui as seguintes propriedades:
MIDlet-1: English Learning,res/firststeps16.PNG,oxetche.EnglishLearningMIDlet
MIDlet-Jar-Size: 31462
MIDlet-Jar-URL: projeto-MobileEnglishLearning.jar
MIDlet-Name: English Learning
MIDlet-Vendor: Oxe Tche group
MIDlet-Version: 1.0.0
MicroEdition-Configuration: CLDC-1.1
MicroEdition-Profile: MIDP-2.0
Observe que quando iremos realizar experimentos práticos, utilizaremos ferramentas, plugins e emuladores que farão automaticamente a geração desse JAD/JAR, que servirão como ponto de entrada para realizar o teste de nosso software.
No próximo post, veremos como desenvolver um exemplo de aplicação, passando pelas fases clássicas: codificar, compilar e testar os programas; tudo isso usando um ambiente de emulação do celular.