Empacotando aplicações no Eclipse: passo a passo

Como redistribuir as aplicações Java ME?
Geralmente criamos aplicações e compactamos dentro de um arquivo .jar (ver postagem sobre isso aqui). Mas e na IDE Eclipse, como gerar nosso produto para poder ser instalado no celular? Esse post demonstra como empacotar sua aplicação em quatro passos.

Obs. Assumindo que um projeto Java ME e seu MIDlet já foram criados.

Passo 1
No seu projeto Java ME aberto no Eclipse, edite o arquivo JAD (Java Application Descriptor), que está na raíz e clique para acessar a sua tela de edição (ver a Figura 1). Ele também pode ser editado como arquivo texto, sem a necessidade de usar o editor Wizard do plugin. No entanto, fica fácil (para novatos), editar como apresentado na tela da figura 1.

Figura 1: Wizard do Java Application Descriptor Editor do plugin eclipse me.

A primeira coisa a observar é escolher a Configuration (CLDC) e o Profile (MIDP) conforme as especificações do aparelho que se deseja instalar. Para saber mais sobre isso, leia a parte 1 da série de tutorias. Escolha a sua configuração e perfil e clique na aba "Midlets" para seguir o próximo passo.

Passo 2
Na tela da figura 2 devemos apontar as classes que herdam de MIDlet para que o sistema saiba por onde começar. Geralmente, isso será colocado automaticamente para você. No entanto, certifique-se que seu MIDlet foi adicionado, caso contrário, clique no botão "Add" e aponte no campo class, a sua classe. Assim, o celular terá condições de encontrar a sua classe principal.

Figura 2: Tela de configuração de MIDlets que compõe a suite de sua aplicação

Passo 3
Após fazer as configurações acima resta agora mandar gerar o pacote. Nesse momento o plugin Eclipse Me irá usar o compilador (javac) e pré-verificar usando o emulador associado. A figura 3 demonstra como gerar o pacote no eclipse:

• Clique com o botão direito do mouse no projeto;
• Selecione a opção J2ME/Create Package;

Figura 3: gerando um pacote no Eclipse com o plugin Eclipse ME

Passo 4
Um diretório chamado "deployed" será criado na raíz do projeto. Expandindo o mesmo, teremos a versão final da aplicação pronta para ser instalada no seu celular. Ver figura 4.

Figura 4: aplicação gerada (arquivo JAD/JAR)

Observe que foi gerado dois arquivos, o arquivo .JAD e o .JAR. Sendo que esses arquivos representam a aplicação. Note ainda, o arquivo JAD gerado deverá conter o seguinte valor internamente seguindo a especificação:

MIDlet-1: [Application name], [icon path] , [midlet class]

Resultando por exemplo:

MIDlet-1: MeuMIDlet, , com.mot.j2me.midlets.commandtest.CommandTest

Se esse valor não estiver configurado no JAD gerado, é provável que sua aplicação não irá executar corretamente, pois ela não saberá qual é a classe principal. É por isso que o passo 2 é importante. O icone é opcional os outros são obrigatórios.

Conclusão
Vimos como gerar um pacote usando a IDE Eclipse em 4 passos. Faça isso sempre que fizer alguma mudança na sua aplicação e desejar que ela seja colocada novamente no telefone celular real. Para testar somente no Eclipse não é obrigatório fazer isso , mas o próprio plugin Eclipse ME faz isso a cada execução (Run) da aplicação.

Até a próxima e mande suas dúvidas, críticas ou sugestões para que eu possa publicar coisas que te interessam.

Motorola lança ferramenta open source Java ME

Uma ferramenta para aumentar sua produtividade em Java ME

A Motorola lança a ferramenta MOTODEV Studio (versão atual v7.3 Beta), que basicamente é uma personalização da IDE Eclipse 3.2 com as ferramentas Java ME da Motorola integradas.

Os desenvolvedores poderão construir suas aplicações usando as vantagens da IDE Eclipse para codificação do código, execução/teste e empacotamento, podendo simular as aplicações do emulador da Motorola, usando o plugin popular Eclipse ME. Tudo isso sem custo e pré configurado para o desenvolvedor fazer suas aplicações.

Os requisitos do software são:

• 500MHz ou superior para processamento
• 512MB RAM
• Sistema Operacional Microsoft® Windows 2000, Windows XP
• Aproximadamente 200MB de espaço em disco
• Sun JDK v1.5 ou superior.

Retirado do manual que vem no produto:

Download MOTODEV Studio for Java ME

Download MOTODEV Studio for Java ME, Motorola tools fully integrated into the Eclipse platform, from this link (166MB) http://developer.motorola.com/ to your Desktop.

Download Motorola Java ME SDK, the standalone version of MOTODEV Studio for Java ME, designed for use with UEI-compliant IDEs, from this link http://developer.motorola.com/ to your desktop.

Instalando e configurando o plugin Eclipse ME

Caros amigos. Fiquei bastante tempo de "férias", mas agora estou retomando as dicas práticas para construção de conhecimento em Java ME.

Neste post demonstrarei como integrar o emulador WTK com a IDE Eclipse, tudo isso usando um plugin para Eclipse chamado eclipseme. Esse conjunto de ferramentas permitirão começar o desenvolvimento de forma produtiva.

Pré-requisitos

• Versão do Eclipse instalado (sugiro versão 3.2 ou superior)
• Wireless Tool Kit instalado (WTK, versão 2.5 ou superior)

Instalando o plugin

A maneira mais simples para instalar o plugin no eclipse é utilizar o próprio update manager do eclipse para baixar e instalar o plugin desejado. Será dessa maneira que faremos aqui. Com o eclipse em execução siga o passo a passo abaixo (resumo):

• Clique em "Help" / "Software updates..." / "Find and Install"
• A tela de "Install/Update" irá aparecer com duas opções, seleciona a opção "Search for new features to install" e clique no botão "next"
• Na tela de "Install", pressione no botão "New remote site";
• Agora aparece uma pequena tela onde você deverá informar o nome do software e a URL para download, assim colocaremos respectivamente: "Eclipse ME"; "http://www.eclipseme.org/updates", e clique "OK"
• Agora é só prosseguir clicando no botão "Finish".
• Após baixar o arquivo o eclipse pedirá para você confirmar a instalação, oinde deverá clicar no botão "Install All". Após instalação é sugerido reiniciar o Eclipse para ativar o plugin.
  

A seguir as principais screenshots para te orientar nos passos:

Figura 1: acessando o update manager do eclipse

Figura 2: acessando a opção do update manager para baixar novas features

Figura 3: colocando o endereço do novo repositório (nova feature)

Figura 4: tela de seleção de features a serem procurados para download

Figura 5: feature do plugin eclipseme encontrado, basta confirmar o seu download

Figura 6: confirmação de instalação do plugin (último passo)

Configurando o Eclipse para se comunicar com o WTK

Após instalar o plugin eclipseme você deve acessar a tela de preferência do eclipse para configurar o plugin. Basicamente é só apontar onde está o diretório de instalação do seu WTK. Então acesse com o Eclipse em execução: Windows / Preferences. Observe que a opção J2ME estará disponível (figura 7). Na tela de preferences, clique em: J2ME/Device Management. Então clique no botão "Import", no qual aparecerá a tela da figura 8.

Figura 7: tela de preferências do eclipse

Figura 8: tela de "import devices"

Figura 9: tela de import após clicar no botão Refresh.

Na tela de import (Figura 8 e 9) devemos apontar para o diretório de instalação do seu WTK e em seguida clicar no botão refresh para atualizar o número de devices disponíveis. Com isso realizado você já poderá criar seus projetos J2ME no eclipse. Façamos um único teste simples.

Fazendo um teste: criando um projeto J2ME no eclipse

Crie um novo projeto no eclipse do tipo J2ME. Clique em New / Project / J2ME / J2ME MIDlet Suite, em seguida preencha um nome para o projeto. (tela da figura 9)

Figura 9: criando no projeto J2me no eclipse

Figura 10: configurando o emulador para seu projeto

A tela da figura 10 aparece após a escolha do nome do projeto. Caso não apareça opções nesta tela, então é preciso configurar o plugin Eclipse ME instalado no seu eclipse conforme instruções neste blog. Se aparecer, basta agora selecionar e associar o WTK para seu projeto. Os próximos passos você precisaria criar a classe MIDlet e para rodar sua aplicação (clicando no RUN do eclipse e configurando uma execução para Wireless Tool Kit Emulator).

Neste post vimos como baixar o plugin Eclipse ME e como podemos instalar na IDE Eclipse, assim poderemos criar nossas classes (codificação) e executar nossas aplicações (testes) nesta IDE.

No próximo post continuaremos com as dicas - espero não demorar tanto para postar outro post. :) Obrigado pela visita e deixe seu recado se quiser.

Introdução a programação para celulares com suporte a Java ME – parte 4

Este post faz parte de uma série de artigos técnicos sobre o desenvolvimento de software para celulares. No primeiro artigo, abordamos os conceitos básicos da tecnologia com ênfase na arquitetura de Java ME. No segundo artigo, analisamos um exemplo de código Java que ilustra o ciclo de vida da aplicação. No terceiro artigo, verificamos como são empacotadas as aplicações – conhecidas como MIDlet Suíte. Neste quarto artigo, 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.

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:

1. vá para o prompt de comando (Command Prompt);
2. para testar a instalação do CLDC digite o comando “preverify”, você deverá ver os comandos conforme a figura 1 abaixo;
3. agora digite o comando “emulator -version” para testar as configurações disponíveis do WTK.

Figura 1: testando a ferramenta pré-verificador e emulator

Os 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

1. Clique no menu Project;
2. Clique na opção Build
3. Clique na opção Run
4. Com o emulador rodando clique no botão direito abaixo da opção “Launch”
5. Clique no botão esquerdo “Sair”

Figura 2: Compilando o primeiro projeto com WTK

Figura 3: rodando o emulador padrão

Analisando 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á!

Introdução a programação para celulares com suporte a Java ME – parte 3

Este post faz parte de uma série de artigos técnicos sobre o desenvolvimento de software para celulares. No primeiro artigo, abordamos os conceitos básicos da tecnologia Java ME, enfatizando os fundamentos de sua arquitetura. No segundo artigo, analisamos um exemplo de código Java que ilustra o ciclo de vida da aplicação. Neste terceiro post, estudaremos o tipo de empacotamento de nossas aplicações, que serão representadas por uma suite MIDlets (MIDlet Suite).


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.

Em teoria, podemos compartilhar recursos entre MIDlets diferentes, a memória de armazenamento do celular por exemplo, poderá ser acessada por dois MIDlets completamente diferentes. Essa memória pode ser tratada através do pacote RMS de MIDP2. No entanto, a maioria dos celulares suporta apenas a execução de uma aplicação por vez. Teríamos que fechar a execução do MIDlet corrente, e executar o próximo MIDlet. No futuro, a especificação de MIDP 3 promete resolver essa limitaçã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.

Figura 1: Propriedades do arquivo MANIFEST

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.

Introdução a programação para celulares com suporte a Java ME - parte 2

Este post faz parte de uma série de artigos técnicos sobre o desenvolvimento de software para celulares. No primeiro artigo, abordamos os conceitos básicos da tecnologia Java ME, enfatizando os fundamentos de sua arquitetura. Neste segundo artigo, demonstrarei um exemplo de código Java que ilustra o ciclo de vida de um aplicativo com Java ME.

Introdução
O objetivo é demonstrar um exemplo ilustrativo de uma aplicação Java ME para situar o leitor no que se refere ao processo de execução da aplicação na memória, da organização e estrutura do programa, tais como: o começo, o meio e o fim do ciclo de vida do software.

Uma aplicação Java ME precisa obedecer algumas regras para que funcione corretamente, entre elas, destacarei inicialmente o ponto de entrada, ou seja, por onde o programa começa a ser executado. Na tecnologia Java SE, por exemplo, os programas começam a execução através do método public static void main(String[] args). No entanto, em Java ME isso é diferente e não precisamos codificar esse método, pois uma aplicação que roda em conjunto com a Máquina Virtual Java (JVM do inglês), chamada de Gerenciador da Aplicação (do inglês Application Management Software - AMS), gerencia o ciclo de vida do software através de estados. A figura 1 ilustra esse processo:

Figure 1: Os possíveis estados de um MIDlet e a transição entre ele

Em outras palavras, quando minha aplicação for iniciada ela assumirá um estado Active (algo como iniciado ou rodando). O nome do método é “protected abstract void startApp()”. Quando for fechada, seja pelo usuário ou pelo Sistema Operacional (SO), nossa aplicação será finalizada – neste caso o estado que será tratado chama-se Destroyed. Isso através do método “protected abstract void destroyApp(boolean unconditional)”. Se ocorrer alguma interrupção na execução corrente de nossa aplicação, ela assumirá o estado parado – Paused. Podendo ser tratada pelo método “protected abstract void pauseApp()”. Neste último, posso citar alguns exemplos: o celular recebendo uma ligação ou recebendo uma mensagem SMS; ou ainda, descarregando a bateria do celular; algum evento sendo priorizado pelo SO do celular, tal como um aviso do despertador ou aviso programado. Em todos os estados utilizam-se os métodos citados para tratar as especificidades de nossa aplicação.

Dito isso, vejamos agora outras regras e definições de Java ME. Os métodos comentados acima referem-se as especificações das JSR-37 (MIDP 1.1) e JSR-118 (MIDP-2.0), ou seja, a biblioteca básica a ser implementada para rodar aplicações. Se um celular suporta MIDP então poderá rodar desde que nossa aplicação estenda ou herde da classe chamada MIDlet, provinda de javax.microedition.midlet.MIDlet. O ponto inicial então poderá ser codificado. A figura 2 ilustra um exemplo de código modelo (ou template) que sempre utilizaremos em nossas aplicações.

Figura 2: template da classe MIDlet com os métodos p/ tratamento dos estados

Nossas aplicações serão chamadas de MIDlets, assim como existem os Applet Java.Esse exemplo ainda não possui códigos úteis, mas seve como base para os próximos MIDlets que serão codificados no futuro. Outras definições de MIDlet segundo Wikipédia:

MIDlet É um aplicativo em Java para dispositivos móveis, mais especificamente para a máquina virtual J2ME. Em geral são aplicações para serem executadas em celulares, como jogos entre outros. MIDlets irão (deverão) rodar em qualquer dispositivo que implemente J2ME Mobile Information Device Profile. Como todos os programas em Java, MIDlets são totalmente portáveis sendo feitos para serem executados em qualquer plataforma. Para escrever um MIDlet, pode-se obter o Sun's Wireless Toolkit do site do Java, o qual é disponível para diversas plataformas e é gratuito.

Um MIDlet possui os seguintes requerimentos para ser executado em um telefone celular: Um MIDlet precisa ser empacotado em um arquivo.jar (ex: usando a jar-tool); O arquivo .jar precisa ser pré-verificado.

Fonte: WIKIPÉDIA. Desenvolvido pela Wikimedia Foundation. Apresenta conteúdo enciclopédico. Disponível em: <http://pt.wikipedia.org/w/index.php?title=MIDlet&oldid=1770115>. Acesso em: 5 Mar 2007

Para compilar esses códigos, podemos baixar algum emulador disponível da internet. Esses ambientes facilitarão o processo de compilar, rodar e empacotar nossa aplicação. Como sugestão, baixe o emulador indicado pelo Wikipédia, pois no próximo post iremos precisar de algumas de suas ferramentas. Também sugiro a IDE Eclipse (atual versão 3.2.1 até está data), que poderá ser muito útil para aumentar nossa capacidade de produção.

No próximo post iremos criar alguns programas e testar nos ambientes disponíveis, analisando o código fonte linha a linha, ampliando progressivamente os conhecimentos de Java ME.

Os brasileiros estão lendo mais?

O que os livros The Servant (O Servidor, em português) e O Monge e o Executivo tem em comum?
Quase tudo, menos o título. Parece incrível mesmo, mas o livro O Monge e o Executivo, do autor James Hunter, que está fazendo o maior sucesso de vendas aqui no Brasil, foi traduzido com um nome diferente do original The Servant. O engraçado é que nem o próprio autor sabia disso, e quando ficou sabendo do sucesso, quase não acreditou que seu livro tinha esse nome por aqui. A revista Época entrevistou Hunter que se diz satisfeito com o sucesso. Veja a reportagem da revista Época. Até ai tudo bem, mas o que me chamou a atenção vem agora.

O livro é acessível economicamente?
O livro custa em média 15,00 R$ e tudo indica que será o campeão de vendas aqui em nosso pais, pois já vendeu mais de 1.3 milhões de exemplares podendo bater o recorde atual, que segundo a revista época, ao consultar especialistas, pertencem ao clássico de Jorge Amado (Capitães da Areia), bem como O Alquimista de Paulo Coelho, ambos com mais de 2 milhões.

Um título criativo pode fazer a diferença nas vendas? Jogada de Markting? Os brasileiros estão lendo mais?

Setenta e cinco por cento dos brasileiros não dominam o exercício da leitura, e mais de 60% não sabem interpretar textos. Especialistas alertam que o hábito tem de começar cedo, ainda na infância.

Educação Os "sem-livro" Fonte: Correio Braziliense, Brasilia, 11 de junho de 2006.

Pesquisa nacional feita com pessoas de 15 a 64 anos, pelo Instituto Ação Educativa/Ibope, aponta que apenas 25% dos brasileiros têm “habilidades mais refinadas” para ler um texto e compreendê-lo. Fonte: Jornal da Unicamp

Somos 180 milhões de pessoas, dessas, tiramos 25% (45 milhões) que segundo pesquisa são as que teriam condições de ler e entender o que foi lido. O problema é que desses 45 milhões de leitores em potencial somente 4.4% é que talvez comprem o livro citado, na melhor das hipóteses, pois assim alcançaríamos a marca dos 2 milhões batendo o recorde novamente. Onde está o restante dos leitores? Talvez comprem outro livro? Há grana para investir em livros? Será que no Brasil é uma questão de cultura e por isso lemos pouco?

Introdução a programação para celulares com suporte a Java ME - parte 1

Já tive oportunidades de ministrar cursos sobre a tecnologia Java ME, e desde então, venho querendo publicar dicas sobre o assunto. Pois bem! Apresentarei uma série de recursos que demonstram como desenvolver alguns programas simples e que podem ser potencialmente interessantes para seu aprendizado. No primeiro post do blog farei uma introdução sobre o assunto indicando algumas referências para leituras complementares, nada muito complicado, mas que servem de apóio para entender a tecnologia escolhida: Java ME. Os próximos posts trataremos de exemplos práticos e a sua utilização usando as APIs de Java ME, passando pela codificação dos exemplos e sua configuração nos ambientes apropriados. Depois gradativamente veremos como usar bibliotecas específicas como PIM, Bluetooth, etc., de forma que podemos entender, experimentar e testar tais recursos para usá-los de forma prática, criativa e quem sabe, lucrativa.

Este post faz parte de uma série de artigos técnicos sobre o desenvolvimento de software para celulares. O segundo artigo já foi publicado, confira!

Breve introdução sobre a tecnologia Java ME
É importante observarmos que aplicações Java ME (voltadas para celulares), são bastante limitada com relação ao seus recursos computacionais. A velocidade do processador, a memória e dispositivos de armazenamento são em média baixas. Isso nos leva muitas vezes a re-aprender os paradigmas de desenvolvimento atuais. Por outro lado, existe a tendência natural da evolução do hardware, e consequentemente os recursos computacionais poderão ser melhor aproveitados. Não se pode comparar um PC com um celular, pelo menos ainda não. Num celular tradicional, não dispomos de mouse, nem tão pouco de uma resolução de tela de 1024x768 pixel. Neste sentido, devemos repensar a forma como projetamos esses sistemas. Retomarei esse assunto no próximo post. Veremos agora o que é Java ME.

Java Micro Edition é uma coleção de recursos da plataforma Java que possibilita desenvolver softwares que podem rodar em dispositivos específicos, tais como celulares. Autores da comunidade da Wikipédia, a Enciclopédia Livre, descreveram uma visão interessante e simplificada sobre Java ME, vejamos:

Java Plataform, Micro Edition (Java ME) ou J2ME É uma tecnologia que nos possibilita o desenvolvimento de software para sistemas e aplicações embarcadas, ou seja, toda aquela que roda em um dispositivo de propósito específico, desempenhando alguma tarefa que seja útil para o dispositivo. É a plataforma Java para dispositivos compactos, como celulares, PDAs, controles remotos, e uma outra gama de dispositivos. Java ME é uma coleção de APIs do Java definidas através da JCP (Java Community Proccess). A comunidade JCP adotou duas abordagens para especificar as necessidades dos pequenos dispositivos - a sua arquitetura computacional. Primeiro eles definiram o ambiente de execução Java (do inglês Java run-time environment), e um conjunto de classes básicas, chamadas de core, que operam sobre cada dispositivo. Isso foi denominado Configurações (do inglês Configurations). Uma configuração define a JVM (Java Virtual Machine) para um pequeno e específico dispositivo computacional. Há duas configurações para um dispositivo embarcado, uma para dispositivos com maior capacidade computacional (do inglês High-end consumer devices), denominado CDC (Connected Device Configuration). A outra com menor capacidade computacional (do inglês Low-end consumer devices), denominado CLDC (Connected Limited Device Configuration). A segunda abordagem foi definida como um perfil (do inglês profile). Um perfil consiste em um conjunto de classes que possibilita os desenvolvedores de software implementarem as aplicações de acordo com as características das aplicações dos pequenos dispositivos computacionais. Foi denominado o MIDP (Mobile Information Device Profile), oferecendo recursos como rede, componentes de interface, armazenamento local, etc. Fonte: WIKIPÉDIA. Desenvolvido pela Wikimedia Foundation. Apresenta conteúdo enciclopédico. Disponível em: <http://pt.wikipedia.org/w/index.php?title=J2ME&oldid=4961778>. Acesso em: 20 Fev 2007

Foram criadas especificações que definiram a arquitetura da tecnologia Java ME, como divisões lógicas, assim como arquitetura de camadas. Para entender melhor essas divisões vamos olhar a figura 1, que representa o esquema citado.

Figura 1: Organização da plataforma Java ME

Device/Hardware: a camada mais abaixo representa o hardware do dispositivo específico que nossa aplicação pode rodar, existem vários fabricantes espalhados pelo mundo que mantém suas próprias tecnologias ou fornecedores desses equipamentos e seus hardwares, entre eles: Motorola, Nokia, Sansumg, Sony Ericson etc. A maioria dessas tecnologias são proprietárias e suas comercializações são garantidas através de patentes.
Native Operating System: a maioria dos dispositivos possui um Sistema Operacional (SO) que habilita nossas aplicações a funcionarem no hardware do dispositivo, no entanto, a maioria não pode ser considerada como um SO completo, assim como Windows ou Linux, pois são limitados e adequados a capacidade computacional do aparelho (P2K da Motorola é um exemplo). Já o SO Symbian ou Linux são mais avançados e são habilitados para executarem várias tarefas e processos simultaneamente (não confundir com paralelamente, o que não é o caso). É nessa camada que as JVMs do Java reproduzem a sua funcionalidade se comunicando com as configurações.
Configurations: conforme podemos observar no texto citado do Wikipédia (leia novamente se não lembrar), as configurações definem o core, ou seja, a essência das implementações que rodam uma JVM que permite interpretar nossa aplicação. A maioria dos dispositivos atuais suporta CLDC 1.0 e CLDC 1.1. A versão 1.0 foi baseada na especificação da versão Java SE 1.3, e a versão CLDC 1.1 foi baseado na versão Java SE 1.4. Logo, podemos concluir que CLDC 1.1 possui melhorias e mais recursos. Por exemplo, um celular que suporta CLDC 1.1, poderia utilizar a funcionalidade de ponto flutuante (uso do tipo primitivo float). Em resumo, as configurações fazem a ponte entre o SO do dispositivo e a JVM que irá rodar nossa aplicação.
Profile: são os recursos que os programadores dispõem para utilizar as funções básicas disponíveis da linguagem Java, especificamente voltados para plataforma Java ME. São as APIs de MIDP. Por exemplo, métodos para manipular Strings, desenhar gráficos, etc. Quando uma aplicação utiliza um recurso do profile, ocorre uma comunicação com a configuração (CLDC), e que permitirá gerar um bytecode (arquivo com extensão .class), voltada para o alvo de compilação específica (por exemplo, uma aplicacao MIDP 2.0 com CLDC1.0). Essa aplicação rodará num aparelho celular que dê suporte a tal configuração. Os profiles são divididos em duas versões, MIDP 1.0 e MIDP 2.0, sendo que o MIDP 3.0 está sendo definido através da JSR-271 (Mobile Information Device Profile 3). Em outro post falarei sobre este profile e as revoluções prometidas.
Optional Packages: são as bibliotecas com recursos específicos. Na prática são aquelas implementações provindas das especificações da JCP. As bibliotecas são conhecidas como JSRs. Alguns exemplos são: JSR-82 (Java APIs for Bluetooth Wireless Technology), para utilizar bluetooth na aplicação; JSR-135 (Mobile Media API), que serve para tocar sons, músicas e videos com formatos diferentes; etc.
Classes OEM: geralmente são outras APIs que oferecem recursos mais avançados ou específicos para determinados clientes ou grupos. Imagine um determinado fabricante de celular que oferece para determinada operadora de telefonia móvel, o acesso a bibliotecas exclusivas, geralmente com mais recursos. Esses acordos são viabilizados através do chamado OEM (Original Equipment Manufacturer).
Applications: a sua parte da coisa, ou seja, onde codificamos a lógica da aplicação que pretendemos fazer. Na prática, serão todo o código que empacotaremos e que se transformará num arquivo (.jar), que tem várias arquivos (.class). Nossa aplicação é representada como um software.

Esses conceitos são importantes, pois servem de embasamento para aprender a fazer softwares para celulares usando a tecnologia Java ME. No próximo post do blog: parte 2, começaremos a fazer alguns exemplos práticos, onde discutiremos o que um programador precisa para começar a dar os primeiros passos, como ferramentas e ambientes que podem ser usados para fazer os programas.

Foi dado ênfase para as configurações de CLDC, explicado acima, no entanto, para outras informações veja esse link.