Introdução
Os desenvolvedores de aplicações Java ME podem construir e testar seus programas sem a necessidade de um telefone celular real, através dos programas emuladores. No entanto, essas ferramentas não reproduzem fielmente o comportamento dos diversos modelos de celulares existentes no mercado, por isso, acredito que deveriam denominar-se de simuladores e não emuladores. É preciso então estar ciente desse fato.
De fato, existem softwares especialmente desenvolvidos para simular o comportamento dos celulares reais. Os principais fornecedores desses programas são os próprios fabricantes de celulares, tais como Nokia e Motorola. A Sun Microsystems também oferece recursos para os desenvolvedores através do seu software WTK (Wireless Tool Kit). Nesta primeira experiência usaremos a ferramenta da SUN – WTK, por ser uma ferramenta bastante didática e de propósito geral. Se suas intenções for desenvolver software para um aparelho específico, então seria interessante utilizar um simulador do respectivo aparelho, se existir.
Ambiente de Desenvolvimento WTK
Conforme citado, usaremos o WTK 2.5 (versão mais estável e atual na data deste post). A ferramenta do Toolkit inclui ambientes de emulação, ferramentas para otimização e desempenho, documentação e exemplos que os desenvolvedores necessitam para construir de forma rápida aplicações simples ou avançadas. O WTK facilita o entendimento do ciclo de vida do desenvolvimento: codificar; compilar (pré-verificar), e rodar (testar). Veremos também alguns exemplos usando linha de comando para demonstrar esse ciclo.
O download do WTK bem como os seus pré-requisitos:
http://java.sun.com/products/sjwtoolkit/download-2_5.html
dica: após instalar, coloque no PATH do sistema o diretório de instalação: (ex. C:\WTK25\bin), e crie uma variável CLASSPATH e coloque (C:\WTK25\lib). Isso permitirá trabalhar através da linha de comando.
Testando sua instalação
Iremos testar se tudo foi instalado corretamente:
- vá para o prompt de comando (Command Prompt);
- para testar a instalação do CLDC digite o comando “preverify”, você deverá ver os comandos conforme a figura 1 abaixo;
- agora digite o comando “emulator -version” para testar as configurações disponíveis do WTK.
Figura 1: testando a ferramenta pré-verificador e emulatorOs emuladores atuais suportam uma especificação chamada UEI (Unified Emulator Interface), que é um padrão para interação entre ambientes IDE (Integrated Development Environments) e os dispositivos emuladores. Sendo assim, fica fácil testar todos os programas simplesmente através da ferramenta “emulator”. Experimente digitar no prompt de comando “emulator -help”. São através desses comandos que o Eclipse IDE por exemplo, através de plugins, se comunica com os emuladores do WTK.
Escrevendo um exemplo e testando através do emulator WTK
A maneira mais fácil de criar e testar um programa é utilizando a ferramenta “ktoolbar”. Abra esse programa digitando no prompt de comando “ktoolbar” ou clique no atalho do menu “Iniciar”. Então clique no botão “New Project”, dois campos são necessários, o nome do projeto (coloque PrimeiroProjeto), e o nome do MIDlet (coloque PrimeiroProgramaMIDlet). Agora vá para o diretório C:\WTK25\apps\PrimeiroProjeto\src e crie o arquivo com o código abaixo:
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.*;
/**
* Esta classe desenha uma mensagem na tela e implementa um botão para sair.
*
* @author Douglas D. Del Frari
*/
public class PrimeiroProgramaMIDlet extends MIDlet implements CommandListener {
// representa o display da aplicacao
private Display display;
// representa o comando de sair
private Command cmdQuit;
// representa uma interface de formulario
private Form form;
/** Construtor */
public PrimeiroProgramaMIDlet() {
display = Display.getDisplay(this);
cmdQuit = new Command("Sair",Command.EXIT,1);
form = new Form("Titulo do Programa");
// adicionando um texto no formulario e tambem o botao "sair"
form.append("Testando meu primeiro exemplo...");
form.addCommand(cmdQuit);
// registrando o tratamento dos eventos do formulario (botao sair) nesta classe
form.setCommandListener(this);
}
/* (non-Javadoc)
* @see javax.microedition.midlet.MIDlet#destroyApp(boolean)
*/
protected void destroyApp(boolean b) throws MIDletStateChangeException {
// chamado quando nossa aplicação será finalizada
this.notifyDestroyed();
}
/* (non-Javadoc)
* @see javax.microedition.midlet.MIDlet#pauseApp()
*/
protected void pauseApp() {
// somente será chamado quando houver uma interrupção do SO
}
/* (non-Javadoc)
* @see javax.microedition.midlet.MIDlet#startApp()
*/
protected void startApp() throws MIDletStateChangeException {
// Ponto Inicial de nossa aplicação
display.setCurrent(form);
}
/* (non-Javadoc)
* @see javax.microedition.lcdui.CommandListener#commandAction(javax.microedition.lcdui.Command, javax.microedition.lcdui.Displayable)
*/
public void commandAction(Command c, Displayable d) {
if (c == cmdQuit) {
try {
destroyApp(true);
} catch (MIDletStateChangeException e) {
e.printStackTrace();
}
}
}
}
Próximos passos: Compilando o programa e rodando o MIDlet
- Clique no menu Project;
- Clique na opção Build
- Clique na opção Run
- Com o emulador rodando clique no botão direito abaixo da opção “Launch”
- Clique no botão esquerdo “Sair”
Figura 2: Compilando o primeiro projeto com WTK
Figura 3: rodando o emulador padrãoAnalisando o código fonte
Toda aplicação precisa herdar de MIDlet para poder implementar o ciclo de vida, representado através dos métodos:
- destroyApp() apenas chamou o comando para finalizar a aplicação;
- pauseApp() nada foi feito ainda;
- startApp() direcionou o componente do formulário (form) para ser exibido;
Foram definidos atributos para representar um comando (cmdQuit), um formulário para colocar as coisas gráficas (form). Note que precisamos SEMPRE definir ou capturar o display do aparelho, isso foi feito através da classe Display.
No construtor desta classe os objetos foram instanciados. Detalhe é que neste caso precisamos capturar os eventos que o usuário poderá fazer, por isso implementamos a interface CommandListener, que nos obriga implementar o método CommandAction, que receberá os eventos dos componentes registrados. O comando foi registrado no próprio MIDlet, pois foi nesta classe que desejamos neste exemplo tratar os eventos. Normalmente, escolhemos outra classe para tratar eventos.
No próximo artigo veremos alguns exemplos usando a API de MIDP, visando explorar os seus recursos gráficos de alto nível que são "bem fáceis" de utilizar, até lá!
