O que é JME?  Corte fora do normal, o excesso e ter deixado ainda com outros conjuntos de APIs Java.  Desde que estas APIs não possam rodar em uma máquina virtual tradicional de Java (JVM),  devido ao tamanho limitado de dispositivos móveis, em consideração à disponibilidade da memória e do recurso, JME define uma versão limitada do JVM também.  Em um Nutshell:

            JME combina um checagem de recurso JVM e um conjunto de APIs Java para desenvolver aplicações para dispositivos móveis

Os fabricantes do dispositivo instalam e pré empacotam seus dispositivos com este JVM (e as APIs associadas).  Como um desenvolvedor, necessitará somente desenvolver as aplicações que utilizam estes dispositivos e instalá-los. 

JME pode ser dividido em três partes, como mostrado em figura 1:  uma configuração, um perfil, e pacotes opcionais.  Uma configuração contem o JVM (não o JVM tradicional, mas a versão cut-down) e algumas bibliotecas da classe;  as configurações de um perfil no alto destes baseiam bibliotecas da classe fornecendo um jogo útil de APIs;  e os pacotes opcionais, são bem, um jogo opcional de APIs que poderá ou não usar quando criar suas aplicações.  Os pacotes opcionais não são empacotados tradicional pelos fabricantes do dispositivo, e terá que empacotá-los e distribuir com sua aplicação.  A configuração e o perfil são fornecidos pelos fabricantes do dispositivo e embutidos nos dispositivos.

                                                                                                    Figura 1. A pilha de JME

O perfil e a configuração os mais populares que a Sun fornece são o perfil móvel do dispositivo de informação (Mobile Information Device Profile-MIDP) e a configuração de dispositivo limitada conectada (Connected Limited Device Configuration-CLDC), respectivamente.  Enquanto o nome sugere, CLDC é para dispositivos com configurações limitadas;  por exemplo, dispositivos que têm somente 128 a 512KB da memória disponível para aplicações de Java.  Conseqüentemente, o JVM que fornece é muito limitado e suporta somente um número pequeno de classes de Java tradicional.  (este JVM limitado é chamado de KVM.)  Em contrpartida, a configuração do dispositivo conectada (Connected Device Configuration-CDC) são para dispositivos com ao menos 2MB de memória disponível e suportam um JVM de característica mais rica (mas não ainda um JVM padrão).

O perfil MID complementa a configuração CLDC muito bem porque minimiza  a memória e o poder, ambos requeridos para dispositivos limitados.  Fornece API básica que é usada para criar aplicação para estes dispositivos.  Por exemplo, fornece o pacote de javax.microedition.lcdui que  nos permite criar elementos GUI que podem ser mostrados em dispositivo (limitado) que roda no perfil MID no topo de uma configuração CLDC.  Note que MIDP não pode ser usado com dispositivos do CDC.  Os dispositivos do CDC começam seu próprio conjunto de perfis, como a Foundation e os Personal profiles.  Entretanto, eu não cobrirei estes perfis ou o CDC aqui, e será concentrado somente no uso do MIDP e CLDC.

    2. Adquirindo e instalando o kit de desenvolvimento do JME

Começar com desenvolvimento de aplicações (a partir de agora chamadas "MIDlets") para a plataforma de JME é fácil.  Embora os fabricantes do dispositivo instalem e pré empacotam seus dispositivos com este JVM (e as APIs associadas), necessitará ainda instalar o JME Wireless Toolkit 2.2 em seu ambiente de desenvolvimento.  Antes deverá também ter o kit de desenvolvimento Java (JDK), versão 1.4.2 ou superior instalado.

Aviso:  Existiram problemas no início com o Wireless Toolkit para trabalhar bem com JDK 5.0.  Se não necessitar as características de versões anteriores a 5.0, será melhor ficar com alguma versão 1.4.2.  Foi usada a versão 1.4.2_05 para todos os exemplos nesta série.

Necessitará deste Toolkit porque contem as ferramentas que são importantes na geração de MIDlets.  Este Toolkit fornece o ambiente de desenvolvimento para o MIDP 2.0 e CLDC 1.1 (e para MIDP 1.0 e CLDC 1.0, desde que estes parâmetros para trás sejam compatíveis), fornece tambem os pacotes opcionais requeridos para as bibliotecas opcionais, como 3D e aplicações Mobile Media.  Ultimamente, fornece a habilidade de assinar seu MIDlets de modo que possam ser autenticados antes da instalação em um dispositivo móvel remoto.

Uma vez feito o download da instalação do pacote para o Toolkit, instale-o no diretório de sua escolha.  O default, em Windows, é C:\WTK22, e este será o diretório da instalação para os exemplos nesta série também.  Não serão explicados os diretórios criados sobre estas pastas agora.  Antes de fazer isto, a princípio, iremos tentar e compreender o processo de geração de um MIDlet.

       3. Entendendo o processo de criação do MIDlet - sem o kit de ferramentas

Existem sete etapas na criação de um MIDlet.  Estas etapas são:  desenho, codificação, compilação, pré-verificação, empacotamanto, teste, e distribuição.  Algumas destas etapas não são estritamente MIDlet-centric (por exemplo, cada aplicação necessita ser projetada, codificada, e compilada), mas para cobrirmos aqui porque existem algumas diferenças MIDlet-centric.  O Toolkit abstrai muitas destas etapas de modo que sejam mais fáceis por todos os lados.  Isto é bonito uma vez que conhece o processo, mas quando está começando, deverá ser codificado a mão, melhor que usar um abstração sugar-coated.

Assegure-se que consigamos um entendimento hands-on destas etapas, deixando-nos pegar ajuda de um exemplo simples.  Criaremos um MIDlet que, quando executado, imprima a data atual e a hora em um dispositivo móvel por um tempo curto.  Junto com isto na mente, figura 2 prática para entender a seqüência destas etapas. Para o momento, conseguiremos levantar um MIDlet simples e rodar, o qual ilustrará estas etapas.


         
                                                                                             Figura 2. Etapas para criação do MIDlet

        3.1. Passo 1: Design

                       MIDlets é diferente de outras aplicações que pode ter criado, simplesmente porque MIDlets funciona em um ambiente que seja muito diferente.  Há diversas edições, não apenas aquelas que são as mais visíveis (por exemplo, o interatividade de seu MIDlet com o usuário), mas outras que impactam sua usabilidade.

                       Para a aplicação do exemplo, nosso MIDlet Date-Time não necessita interatividade com o usuário.  Necessita indicar a data atual e a hora por alguns segundos em que o usuário executa o MIDlet.  Casos simples como este, é talvez suficiente para simular o projeto de MIDlet por desenhá-lo em um pedaço de papel.  Para projetos mais complexos como telas múltiplas, é melhor projetar as telas profissionalmente antes de começar o processo de codificar real.

       3.2. Passo 2: Code

                       Cada MIDlet deve estender a classe abstrata de MIDlet encontrada no pacote de javax.microedition.midlet, bem como criar um applet estendendo a classe de java.applet.Applet.  No mínimo, seu MIDlet deve cancelar três métodos desta classe abstrata, startApp(), pauseApp() e destroyApp(boolean incondicional). Aqui está a classe de DateTimeApp:

package com.jme.part1;

import java.util.Date;

import javax.microedition.lcdui.Alert;
import javax.microedition.lcdui.Display;
import javax.microedition.midlet.MIDlet;

public class DateTimeApp extends MIDlet {

 Alert timeAlert;

 public DateTimeApp() {
 timeAlert = new Alert("Alert!");
 timeAlert.setString(new Date().toString());
 }

 public void startApp() {
 Display.getDisplay(this).setCurrent(timeAlert);
 }

 public void pauseApp() {
 }

 public void destroyApp(boolean unconditional) {
 }
}

Neste exemplo, o construtor de DateTimeApp cria o elemento que é necessário para mostrar o tempo na tela de um dispositivo e o método do startApp faz a tarefa real de mostrar este elemento.  Não se preocupe se não compreender como o elemento Alert trabalha, ou quando o construtor ou os outros métodos são chamados.  Será tratado o antigo na próxima parte, quando olharmos os elementos de GUI do MIDP 2.0 e o ciclo de vida de MIDlet.

Copie este código em um arquivo chamado DateTimeApp.java e salve-o em uma pasta que simule sua estrutura do pacote (com\jme\part1).  Poderá conservá-lo em qualquer lugar que quiser na sua máquina;  até este artigo , poderá ser salvo na pasta C:\WTK22\article\com\jme\part1.

        3.3. Passo 3: Compile

                       Com este simples código no diretório, necessitará agora saber compilá-lo de modo que esteja pronto para dispositivos móveis.  Compilar MIDlets não é muito diferente de compilar aplicações normais de Java.  Deverá usar ainda o javac como compilador, a não ser que necessite mudar reiniciar o CLASSPATH ao compilar MIDlets.  Isto tem o efeito de mudar a base das classes de Java o qual o compilador de Java usa para compilar junto do seu MIDlet, assegurando-se desse modo que a compilação tenha um alvo para um pequeno conjunto de APIs de Java para a plataforma de JME.  Assim em vez de compilar novamente o java.lang.Date em Java "normal", necessitará da compilação feita para o java.lang.Date no JME.  Isto é feito para apontar para as classes CLDC e MIDP para javac - opção do bootclasspath ao compilar.  Isto é mostrado abaixo para a compilação de DateTimeApp MIDlet.  Para fazer esta compilação, certifique-se que entrará com o comando de navegação para o diretório C:\WTK22\article através do comando no terminal.

C:\WTK22\article>javac -bootclasspath ..\lib\cldcapi11.jar;..\lib\midpapi20.jar com\jme\part1\DateTimeApp.java

Observe que a compilação foi feita novamente para as versões de API's  CLDC 1.1 e MIDP 2.0, respectivamente, incluindo estas bibliotecas na opção do bootclasspath.  A compilação poderia ser feita novamente para  outras versões se isto requeresse apontar para suas respectivas bibliotecas.

          3.4. Passo 4: Preverify

Antes de distribuir (deploy) sua classe MIDlet, necessitará fazer sua pré-verificação (preverify).  A verificação do byte code é uma etapa executada pelo JVM antes que rode a classe do arquivo para se assegurar de que a mesma esteja estruturalmente e conceitualmente corretas como por especificação JVM.  Se a classe do arquivo falhar esta verificação, será rejeitada e o JVM se encerrará, indicando outra segurança ou a violação de integridade da classe do arquivo.  Esta verificação é feita por todo o JVM, mesmo o menor JVM contido em uma configuração CLDC para um dispositivo de JME.  Embora este não seja um problema para aplicações "normais", a verificação em dispositivos de JME é um recurso e memória confinada que simplesmente não possam tocar.  Conseqüentemente, a necessidade da pré-verificação.

Pré-verificação é uma parte de um processo de verificação especial two-step, especialmente projetada para dispositivos confinados, semelhante a rodar em JVMs CLDC-based.  A idéia é deixar um desenvolvedor preverify e suas classes, o qual limita a quantidade de trabalho necessitada para ser executado quando as classes são verificadas no dispositivo.  Este processo da pré-verificação adiciona a informação especial às classes que as identifica como preverified e faz o processo no dispositivo muito mais eficiente.

Mantenha isto em mente, preverify seu Date-Time MIDlet.  O Wireless Toolkit vem com uma ferramenta do pré-verificação na pasta bin de sua instalação (C:\WTK22\bin).  O seguinte comando, quando executado de C:\WTK22\article, este pré-verificará o DateTimeApp.class criado na etapa precedente.

C:\WTK22\article>..\bin\preverify.exe -classpath ..\lib\cldcapi11.jar;..\lib\midpapi20.jar com.jme.part1.DateTimeApp



Por default, a pré-verificação criará a versão pré-verificada de seu arquivo DateTimeApp.class em uma pasta chamada output no diretório corrente.  Preservará a estrutura do pacote, assim que sua classe pré-verificador estará agora uma pasta C:\WTK22\article\output\com\jme\part1 \. Poderá, naturalmente, apontar a saída a uma outra pasta, utilizando a opção -d para a ferramenta de pré-verificação, mas no momento, utilize-se da pasta de saída default.

    3.5. Passo 5: Package

Empacotando seu MIDlet de modo que fique pronto para testar e distribuir, que é um processo razoavelmente envolvido, com diversas etapas.  Embora cada etapa seja direta, devem ser seguidos na seqüência apropriada.

A primeira etapa é criar um arquivo Manifest.  Este arquivo Manifest descreve os índices do arquivo de Java Archive (JAR) que estaremos criando na etapa seguinte.  Existem diversos atributos que fazem parte neste arquivo, mas para seu Date-Time MIDlet, suportará somente  essas que são requeridas.  Os índices deste arquivo são mostrados aqui:

MIDlet-Name: DateTimeApp
MIDlet-Version: 1.0.0
MIDlet-Vendor: Vikram Goyal



Salve este arquivo como Manifest.mf na pasta C:\WTK22\article\output.  (Note a linha após o último atributo, MIDlet-Vendor.  Deve estar presente, se não este atributo não será reconhecido.)

Em seguida, crie um arquivo JAR que empacota acima do preverified do arquivo DateTimeApp.class e o arquivo Manifest.  Para criar este arquivo JAR, navegue ao diretório  C:\WTK22\article\output e digita o seguinte comando:

C:\WTK22\article\output>jar cvfm DateTimeApp.jar Manifest.mf .\com

Isto criará um arquivo DateTimeApp.jar na pasta corrente (C:\WTK22\article\output).

A etapa second-to-last é criar um arquivo que tenha uma extensão .jad.  Um arquivo Java Application Descriptor (JAD) aponta à posição do MIDlet que descreve de que modo um dispositivo de JME possa instalá-lo.  Outra vez, este arquivo pode conter diversos atributos para um único MIDlet (ou para diversos MIDlets), mas para seu Date-Time MIDlet, suportará com uns que são requeridos.

MIDlet-1: DateTimeApp, , com.jme.part1.DateTimeApp
MIDlet-Name: DateTimeApp
MIDlet-Version: 1.0.0
MIDlet-Vendor: Vikram Goyal
MIDlet-Jar-URL: DateTimeApp.jar
MIDlet-Jar-Size:
MicroEdition-Profile: MIDP-2.0
MicroEdition-Configuration: CLDC-1.1

Salve este arquivo como DateTimeApp.jad na mesma pasta que o arquivo JAR (C:\WTK22\article\output).  Os atributos neste arquivo serão explicados mais tarde, mas neste momento, note que o valor do atributo MIDlet-Jar-Size está perdido.  Este valor perdido tráz à última etapa do empacotando, onde determinará o tamanho do arquivo DateTimeApp.jar, e será colocado esse valor neste arquivo JAD, em bytes reais.  É muito importante conseguir fazê-lo certo, porque a instalação deste MIDlet falhará se este valor for diferente do tamanho real.  Os valores variam de computador, neste caso o valor é 1469 bytes, e conseqüentemente, este é o que este atributo pega nesta máquina:

MIDlet-Jar-Size: 1469

Isto termina a parte de empacotamento.  Existem outras etapas em empacotamento que poderia falar a respeito (por exemplo, assinatura e o obfuscation), mas para conservar as coisas simples, serão deixadas  aquelas etapas para uma discussão mais tarde.  Para agora, moverá sobre no teste de seu MIDlet.

        3.6 Passo 6: Test

Antes de distribuir seu MIDlets, devem ser testados usando uma base comum do emulador de dispositivo que simule a funcionalidade de um dispositivo real em seu computador.  Este emulador é parte do Wireless Toolkit e fornece a funcionalidade que é certa estar presente na maioria dos dispositivos para que o MIDlet seja alvejado.  Este emulador está presente nna pasta bin do Toolkit.

Do diretório output criado na etapa de pré-verificação anteriormente, onde temos agora um MIDlet empacotado no formulário de arquivos JAR e JAD, digite o comando seguinte para rodar o emulador com este arquivo  JAD como uma opção.

C:\WTK22\article\output>..\..\bin\emulator.exe -Xdescriptor DateTimeApp.jad


Deverá ver o emulador com um pop up em sua tela como mostrado na figura 3, com o DateTimeApp MIDlet selecionado.  Se não, o erro mais provável neste momento seria informação incorreta do tamanho do JAR.  Certifique-se que do tamanho exato listado no arquivo JAD.

                                                                        Figura 3. Testando o DateTimeApp

No canto inferior direito da tela do dispositivo emulado, poderá ver o Menu item listado "Launch".  O emulador instalou o MIDlet e está pronto para lançá-lo.  Clique sobre a tecla do telefone abaixo do menu item  "Launch" e o MIDlet deve indicar o momento da data corrente por alguns segundos e então desaparecer.  Note que o MIDlet está funcionando ainda mesmo após a data e o tempo desaparecer, porque no código, não foi destruído.

        3.7 Passo 7: Deploy

Estará neste momento num estágio onde poderá desdobrar o MIDlet diretamente em seu dispositivo móvel.  Existem duas maneiras de fazer isto.  O primeiro é através de uma conexão de rede entre seu computador e seu monofone.  Isto pode ser através de um cabo  USB ou de uma conexão wireless de Bluetooth, dependendo de seu dispositivo.  A maioria dos dispositivos Java-enabled permitirão que  instale aplicações de JME através desta conexão.

O segundo e esse que é mais interessante, porque abre seus MIDlet ao mundo exterior, é através do Internet.  Depois de tudo, que bom seria que seu MIDlet, fosse visto pelo resto do mundo?  Isto significa que seu dispositivo poderá  conectar-se à Internet usando seu browser interno.

Antes de prosseguir, lembre-se que quando foi criado um arquivo JAD, foram incorporados dois atributos em que especificada a versão de CLDC (1.1) e de MIDP (2.0) para que o MIDlet fosse criado.  Desde o DateTimeApp MIDlet não usa algumas das características destas versões, isso teoricamente rodará nos dispositivos que suportam as versões antigas destes atributos.  Conseqüentemente, o DateTimeApp MIDlet deverá funcionar em CLDC 1.0 e em MIDP 1.0, mas porque o arquivo JAD restringe estas versões mais novas, os dispositivos não instalarão este MIDlet se não suportarem estas novas versõess.  Se este for o caso com seu dispositivo, tema não!  Antes dito antes, porque não estamos usando nenhuma  características específicas de MIDP-2.0- ou de CLDC-1.1-, poderá simplesmente mudar estes números de versão no arquivo JAD, e isto será suficiente para instalar este dispositivo em todos os dispositivos Java-enabled.  Se este for o caso com seu dispndo sobre este MIDlet, mude simplesmente estes valores no arquivo JAD e como isto irá bem.

Para estar habilitando seu MIDlet através do Internet, necessitará ter o acesso a um web server com um IP ADDRESS real-world ou um Domain Name.  Necessitará também ter privilégios administrativos para estar modificando os arquivos de configuração de seu web server para adicionar alguns tipos de Multipurpose Internet Mail Exchange (MIME) para as extensões de JAD e de JAR.  Caso estiver usando Jakarta/Tomcat como seu web server, não necessitará fazer este, porque já tem estes tipos MIME.  Para o web server de Apache, modifique o arquivo mime.types e adicione a seguir tipos de extensão.

text/vnd.sun.jme.app-descriptor jad

application/java-archive jar

Adicionando estes tipos MIME, estará informando o browser, ou todo o cliente que acessa estes arquivos de usuário, como segurar estes arquivos quando eles são baixados no dispositivo.

Em seguida, crie um arquivo HTML que se transforme em ponto de referência.  Estritamente, isto não é necessário, porque um dispositivo que possa acessar uma página HTML pode também acessar um arquivo JAD.  Mas uma página HTML fornece um ponto de referência, e vamos conseqüentemente criar um para seu Date-Time MIDlet.  O HTML não necessita ser algo fantasia.  Não se esqueça de que os usuários estarão acessando esta página através de um dispositivo móvel, assim que é prudente manter o tamanho desta página ao mínimo.  Isto é mostrado na listagem 2.

	<HTML>
 Click <a href="DateTimeApp.jad">here</a> to download DateTimeApp MIDlet!
	</HTML>

                        Listagem 2. DateTimeApp.html página para acessar o DateTimeApp MIDlet

A página fornece um link a um arquivo JAD, e o mesmo fornece um link a um arquivo associado para arquivo JAR através do MIDlet-Jar-URL:  Atributo de DateTimeApp.jar.  Entretanto, dacessado através de um web server sobre o Internet, é aconselhável fazer este link absoluto em vez do relativo.  (o comportamento de URLs relativo é inconsistente tanto quanto o acesso MIDlet.)  Desde que estou indo me servir a este MIDlet através de um Web site (Craftbits.com) gerencio, modificando este link a uma URL absoluta, usando este Web site.

                MIDlet-Jar-URL: http://www.craftbits.com/jme/DateTimeApp.jar

Necessitará mudar esta URL para seu próprio domínio.

Finalmente, suba o arquivo JAR modificado, novamente o arquivo HTML criado, e o arquivo original JAR de seu web server a uma posição do diretório onde possa  navegar a página HTML através de seu browser de dispositivo móvel.  Agora, qualquer um com um dispositivo móvel que possa paginar na Internet poderá apontar o seu arquivo e um download de DateTimeApp.html, instalar, e rodar o DateTimeApp MIDlet.

Para aqueles que não têm o acesso a um web server, deverão subir os arquivos a web server próprio.  Simplesmente o ponto para http://www.craftbits.com/j2me/DateTimeApp.html através de seu dispositivo e poderá  ver este MIDlet em ação.

Terminada todas as etapas requeridas para se criar e distribuir manualmente um MIDlet.  Este processo ajudou-nos a compreender o que está atrás das cenas e dada a confiança em todas as etapas da criação de MIDlet.  Porque muitas destas etapas são repetitivas, no sentido de usarem uma ferramenta automatizada.  Este é o lugar aonde o Wireless Toolkit vem, e usará para criar o restante do MIDlets nesta série do artigo.  Neste momento, vamos recriar o mesmo MIDlet usando este Toolkit, de modo que possa conseguir familiarizar-se com sua interface.

        4. Entendendo o processo de criação do MIDlet - usando o kit de ferramentas

Na seção sobre Acquiring and Installing JME Development Kit, poderá ser baixado o Toolkit e instalado na pasta C:\WTK22 (tanto quanto esta série do artigo;  poderá ser baixado e instalado em uma pasta diferente).  Vamos explorar os índices desta pasta.  A figura 4 mostra estes índices como deveria estar em sua máquina.

                                                        Figura 4. Índice da pasta Wireless Toolkit 

Note que a instalação default do Toolkit não criaria a pasta article, e que foi criada na seção precedente.  Tanto quanto diz respeito a um desenvolvedor de MIDlet, as pastas mais importantes são os apps e bin, mas aqui está um sumário curto de cada um destes pastas.

Nome das Pastas	Descrição das Pastas
appdb	Diretório que age como uma simulação para o sistema de arquivo de dispositivo móvel
apps	MIDlets criados usando o Toolkit que reside nesses diretórios
bin	Contem executáveis para as várias ferramentas, incluindo o  próprio Toolkit, e várias outras ferramentas como o pré-verificador (preverifier) e o emulador
docs	A documentação Wireless Toolkit inclue documentação de API para MIDP 2.0 e MIDP 1.1
lib	Contem os arquivos JAR para MIDP (ambos 2.0 e 1.1), CLDC (ambos 1.1 e 1.0) e diversas outras bibliotecas opcionais
sessions	Diretório onde as sessões de rede e de perfil são mantidas
wtklib	Contem as bibliotecas próprias do Toolkit, incluindo as propriedades de vários emuladores de dispositivo

A pasta apps é o diretório onde todo o MIDlets que são criados usando o Toolkit que está instalado. Navegar estas pastas, observará diversos exemplos de MIDlets fornecido em seus próprias pastas. Estes têm sua própria estrutura do diretório que permite a separação limpa do código fonte, das bibliotecas, e do restante dos arquivos associados com um projeto MIDlet.

A pasta bin contem os executáveis para o Toolkit.  O mais importante é ktoolbar.exe (em Windows), que começa a janela de interface principal para o Toolkit.  Esta pasta contem outros executáveis como também, alguns dos quais venham através do tempo (por exemplo, o preverify.exe e o emulator.exe).   rodando o ktoolbar.exe da pasta bin.  O Toolkit será iniciado e abrirá a janela mostrada na figura 5.

                                                       Figura 5. Janela principal do Toolkit 

A mensagem na janela diz, criar um projeto novo ou abrir um projeto existente.  Quando clicar na opção "Open Project", será apresentado uma lista dos projetos.  Esta lista dos projetos é a lista do diretório da pasta apps.  Selecionar um projeto desta lista e abrí-lo, e isto permitirá que faça os ajustes necessários, construindo-os (que incluem a compilação, o pré-verificação e empacotamento) e rode-os.  As etapas do projeto e de sua codificação serão feitas ainda fora deste Toolkit.

Usaremos o Toolkit para criar o Date-Time MIDlet da seção precedente.  Clique em  "New Project", e entre com os dados na janela, como mostrado em figura 6.

                                                               Figura 6. Criando um novo projeto

A janela seguinte sobreposta permitirá que altere os ajustes que controlam a plataforma do alvo de seu MIDlet.  Neste caso, querer alvejar este MIDlet para o MIDP 2.0 e as plataformas de CLDC 1.1 e manter o Target Platform como JTWI, o qual pré-seleciona o MIDP 2.0 Profile.  Entretanto, necessitará mudar a Configuration para CLDC 1.1 e desmarcar a biblioteca Optional Mobile Media API, como mostrado na figura 7.

                                                            Figura 7. Alterando settings do projeto

Poderá rever o restante dos ajustes clicando nas abas constantes na janela de settings, mas no momento, seu projeto está pronto para ser criado.  Clique em "OK".  O projeto será criado com a informação sobre onde colocar os arquivos de projeto mostrados na tela, conforme mostra a figura 8.  Poderá verificar que o Toolkit criou uma pasta DateTimeApp abaixo da pasta dos apps para a navegação.

                                                       Figura 8. Projeto DateTimeApp criado

Tendo já criado um único arquivo src requerido para este MIDlet na seção precedente, copie este arquivo DateTimeApp.java, da pasta C:\WTK22\article\com\jme\part1\ para a pasta inteiramente qualificada do src (C:\WTK22\apps\DateTimeApp\src\com\jme\part1).  Note que o Toolkit criou o caminho inteiramente qualificado baseado no nome do pacote.  Uma vez a cópia feita, volte ao Toolkit e selecione a opção "Run".  O Toolkit compilará, pré-verificará e empacotará (compily, preverify e package), desde que tudo esteja OK, rodará o DateTimeApp no emulador.    Tudo que terá que fazer agora é criar um projeto novo, ajustar os atributos, escrever o código, o salvar no diretório certo e selecionar a opção "Run".  O restante fica por conta do Toolkit.

Examine o restante das pastas abaixo do projeto DateTimeApp, antes de mudar de seção.  A pasta bin abaixo da pasta DateTimeApp contem o JAD e os arquivos Manifest, enquanto a pasta classes contiver classes compiladas.  Mas onde está o arquivo JAR para este MIDlet?  Bem, o arquivo JAR não foi criado para rodar exato (ou construir) sua aplicação no Toolkit.  Para criar o arquivo JAR, necessitará selecionar o item do menu "Project", e então selecionar uma das opções abaixo do submenu "Package", como mostrado na figura 9.

                                                       Figura 9. Criando o arquivo MIDlet's JAR

Criando este pacote, o arquivo JAR será criado, com a informação Manifest correta no arquivo JAD.  Poderá mesmo criar o arquivo HTML que criamos previamente na seção Deploy, clicando "Run" através do menu OTA (Over The Air).  Isto permitirá não somente que simule seu emulador rodar este MIDlet através da Internet, mas cria também o arquivo HTML na pasta bin.  Antes de usar este arquivo HTML para distribuir em seu próprio server, junto com o JAD e os arquivos JAR, necessitará alterar o hostname, o qual o default para  "localhost."

Agora já saberá criar um MIDlet simples, ambos usando ou não o Toolkit.  Agora veremos o ciclo de vida do MIDlet para compreender o que acontece realmente quando seu MIDlet é distribuido e executado.

        5. Ciclo de vida do MIDlet

Dispositivos móveis, sendo emuladores ou real, interativo com um MIDlet usando seu próprio software, o qual é chamado Application Management Software (AMS).  O AMS é responsável por inicializar, startar, pausar, recomeçar, e destruir um MIDlet.  (além destes serviços, AMS pode ser responsável para instalar e remover um MIDlet, também.)  Para facilitar este gerenciamento, um MIDlet poderá estar em um de três estados que é controlado através dos métodos da classe de MIDlet, que cada MIDlet estende e reescreve.  Estes estados são ativos, pausados e destruídos.

                                                       Figura 10. Os possíveis estados do MIDlet e a transação entre eles

Na figura 11, um MIDlet instalado é posto em um estado pausado pelo AMS que cría um exemplo dele, chamando-o de construtor no-args (sem argumentos).  Esta não é a única maneira que o MIDlet pode estar em um estado pausado.  Pode incorporar este estado quando o AMS chama o método pauseApp() em um MIDlet ativo (e nos retornos do método com sucesso).  Pode também incorporar este estado quando o MIDlet tem uma pausa própria chamando o método  notifyPaused(), ao contrário do método pauseApp(), que é chamado pelo AMS.  Entretanto, o que exatamente está acontecendo com o MIDlet no estado pausado?

Em um estado pausado, o MIDlet está esperando uma possibilidade de conseguir um estado ativo.  Teoricamente, neste estado, não deve ser carregado ou usado alguns dos recursos do dispositivo e deve ser passivo na natureza.  Uma vez que o MIDlet é criado, este é o estado de ser antes de tornar-se ativo.  Também, incorporar o estado pausado é necessário quando o dispositivo requer consumir poucos recursos, porque estes recursos podem ser requeridos segurando outras funções do dispositivo, como a manipulação de uma chamada declarada.  Isto é quando o dispositivo invoca o método pauseApp() através do AMS.  Se o MIDlet informar o AMS que está pausado, deve invocar o método notifyPaused(), que diz ao AMS que o MIDlet certamente está pausado.

Uma maneira final em que um MIDlet pode conseguir um estado pausado é quando o método startApp() do MIDlet, que é chamado quando o AMS o invoca para começar o MIDlet (qualquer um a primeira vez ou de um estado pausado), mostra um MIDletStateChangeException.  Essencialmente, em caso de erro, o MIDlet assegura-se de permanecer em estado pausado.

O estado ativo é onde cada MIDlet quer estar!  Isto é quando o MIDlet pode fazer suas funções, carrega os recursos do dispositivo e geralmente, faz o que se supõe para fazer.  Como dito previamente, um MIDlet está em um estado ativo quando o AMS chama o método startApp() em um MIDlet pausado (realmente, o MIDlet incorpora o estado ativo imediatamente antes que este método é chamado pelo AMS).  Um MIDlet pausado pode pedir para entrar no estado ativo chamando o método resumeRequest(), que informa o AMS que o MIDlet deseja se tornar ativo.  O AMS pode naturalmente, escolher ignorar este pedido ou enfileirá-lo alternativamente se houver um outro MIDlets com o mesmo pedido.

O estado destruído é incorporado quando o método destroyApp(boolean incondicional) de um MIDlet é chamado e retorna com sucesso, de um estado ativo ou pausado.  Este método é chamado pelo AMS quando percebe que não há nenhuma necessidade para o MIDlet se manter rodando (ativo) e é o lugar que o MIDlet pode fazer a limpeza e outras últimas atividades minuciosas.  O MIDlet pode incorporar este estado próprio, chamando o método notifyDestroyed(), que informa o AMS que o MIDlet limpou seus recursos e é elegível para a destruição.  Naturalmente, desde que neste caso, o método destroyApp(boolean  incondicional) não seja chamado pelo AMS, em nenhuma das últimas atividades minuciosas devem ser feitas antes que este método seja invocado.

O que acontece se o AMS chamar o método  destroyApp(boolean incondicional) no meio de uma etapa importante que o MIDlet possa estar executando, e estar inclinado a ser destruído?  Este é o lugar onde o flag incondicional de Boolean vem dentro da figura.  Se este flag for atribuído true, o MIDlet será destruído, independente do que o MIDlet está fazendo.  Entretanto, se este flag é false, o AMS dirá ao MIDlet que quer o MIDlet seja destruído, mas se o MIDlet estiver fazendo algo importante, pode mostrar um MIDletStateChangeException, e o AMS não o destruirá neste momento ainda.  Entretanto, note que mesmo que, não exista nenhuma garantia que o MIDlet não será destruído, e fica a cargo de cada dispositivo decidir como devem segurar o pedido.  Se o dispositivo obedecer o pedido do MIDlet, poderá tentar  invocar o método destroyApp(boolean incondicional) em um estado mais tarde.

Note que um estado destruído significa que o MIDlet inbstanciado foi destruído, mas não desinstalado do dispositivo.  O MIDlet ficou instalado no dispositivo, e uma nova instancia dele podem ser criados mais tarde.

Para terminar esta seção e este artigo, vejamos o fluxo, mostrado na figura 11, de uma típica seqüência de eventos enquanto usamos o DateTimeApp MIDlet que criamos nas seções precedentes, e as correspondentes ações do AMS e os estados de MIDlet.  

                                                       Figura 11. Ações do AMS e estados de MIDlet através da sequência de eventos

Na parte seguinte desta série, começará criar MIDlets útil compreendendo User Interface API de MIDP 2.0.  Isto permitirá que crie as interfaces de usuário poderosas, uma exigência chave para todo MIDlet.  

Vikram Goyal é um amante sério de Java com mais de oito anos de experiência.