>o até a instalação em um dispositivo real
Leitura Recomendada: WebMobile 5, artigo Desenvolvendo Aplicações J2ME para PDAs.
Leitura Recomendada: WebMobile 5, artigo Interface Gráfica para Aplicações J2ME: Uma Introdução à MIDP UI API.
Estamos de volta para darmos continuidade à segunda parte da nossa série sobre o desenvolvimento de aplicações em J2ME para PDAs iniciada na edição 5 da WebMobile. Buscaremos abordar mais alguns conceitos básicos do desenvolvimento de aplicações para PDAs, aumentando um pouco mais a complexidade do exemplo para que sejam utilizados mais alguns componentes gráficos da plataforma J2ME para esses dispositivos.
Para isso, seguiremos todo o processo de desenvolvimento de uma aplicação, desde a configuração do ambiente que utilizaremos para o desenvolvimento. Isso será descrito através da demonstração de como podemos salvar a sessão do simulador (não sei se alguns notaram, mas toda vez em que se fecha o simulador e o executamos novamente não temos mais a JVM instalada no simulador. Com isso, temos de fazer todo o processo de instalação da JVM no simulador, o que se torna cansativo e repetitivo). Isto somente vale para o desenvolvimento no simulador, pois uma vez instalada a JVM num dispositivo real não temos mais este problema.
Após a etapa de configuração, descreveremos a implementação de um estudo de caso bem simples (uma aplicação de cadastro de livros), que nos permita usar mais componentes gráficos do perfil MIDP.
Por fim, mostraremos os procedimentos para a instalação da JVM e do aplicativo de exemplo num dispositivo real.
Salvando uma sessão do simulador
O ambiente completo para desenvolvimento de uma aplicação para PDA foi descrito no primeiro artigo desta série (Desenvolvendo Aplicações J2ME para PDAs – publicado na edição 5). Nesta matéria iremos nos concentrar na tarefa de salvar a sessão do simulador, evitando o esforço da configuração sempre que iniciá-lo.
Bom, como alguns devem ter percebido ao seguir o primeiro artigo da série, no momento em que fecharam o simulador e o executaram novamente, nem a aplicação de teste nem a JVM da IBM estavam instaladas no simulador. Isto acontece pelo fato de num dispositivo real os aplicativos serem instalados na memória RAM. Se deixarmos de alimentar esta memória, seus dados se apagarão (ver Nota 1). O simulador funciona de forma semelhante. Ao fecharmos o simulador, é como se apagássemos sua memória RAM ou sua energia houvesse acabado. Assim, quando o iniciamos novamente, ele carrega somente os aplicativos básicos do sistema operacional.
Nota 1. Dispositivos evoluídos
Isto não é válido para os dispositivos Tungsten E2, LifeDrive e Treo 650, que utilizam um novo tipo de memória RAM que não necessita de energia para manter os dados gravados. Assim, mesmo que a carga da bateria acabe os dados não são perdidos, situação que ocorre nos demais dispositivos fabricados pela Palm.
Então, torna-se necessário que se repitam os passos para a instalação. Mas existe uma solução: salvar a sessão da memória RAM do simulador para que possa ser usada novamente.
A sessão do simulador consiste de uma cópia da memória do simulador, ou seja, todos os aplicativos instalados, incluindo o nosso arquivo exemplo descrito no primeiro artigo da série e a JVM da IBM, são copiados. Mas como usar isto? Ao se iniciar o simulador não se tem mais a necessidade de se instalar os aplicativos novamente, basta apenas que se carregue a sessão anteriormente salva que tudo fica como estava na última execução do simulador.
Para salvar uma sessão proceda assim:
1. execute o simulador e instale nele a JVM da IBM e o aplicativo de exemplo descrito no primeiro artigo da série (esses os passos estão detalhados no primeiro artigo da série);
2. tendo instalado, clique com o botão direito em cima do simulador e escolha a opção Storage ? Save (Figura 1);
Figura 1. Exportando a sessão de memória.
3. uma tela se abrirá solicitando um local do computador onde devemos salvar a sessão. Escolha de preferência o diretório onde está instalado o simulador (por exemplo, C:\PalmOS54\release) e mude o nome do arquivo para webmobile.ssf (Figura 2).
Figura 2. Escolhendo o local onde salvar o arquivo.
Pronto, já temos a sessão do simulador salva. Agora, para carregar a sessão temos duas opções:
1. A primeira é executando o simulador, e clicando com o botão direto escolhemos Storage ? Load (Figura 3). Uma tela do Windows se abrirá e procuramos o arquivo webmobile.ssf (Figura 4).
Figura 3. Carregando a sessão de memória salva.
Figura 4. Selecionando o arquivo.
2. Caso esta opção apresente algum erro, a outra solução é a de editar o arquivo palmsim.ini para que ele carregue automaticamente a sessão salva. Para isto, faça o seguinte:
· Se o simulador estiver em execução, feche-o. Depois vá até o diretório onde está instalado o simulador (no nosso caso C:\PalmOS54) e dentro do diretório release procure o arquivo palmsim.ini (Figura 5).
Figura 5. O arquivo palmsim.ini.
· Abra-o com qualquer editor de texto e procure a linha com StorageSnapshotFile= e depois do símbolo de “=” escreva, webmobile.ssf. A linha agora deve ficar assim: StorageSnapshotFile=webmobile.ssf (Figura 6).
Figura 6. Editando o arquivo palmsim.ini.
· Salve o arquivo e execute novamente o simulador.
Pronto. Agora já temos a sessão da memória do simulador podendo ser carregada manualmente ou automaticamente.
Estudo de caso: cadastro e consulta de livros
Antes de iniciar o desenvolvimento do estudo de caso, precisamos entendê-lo melhor. Como citado no início do artigo, desenvolveremos uma aplicação de cadastro de livros para explorarmos um pouco mais os componentes gráficos do perfil MIDP e como eles são visualizados no simulador.
Especificando a aplicação, desejamos que o usuário entre com os dados do livro até uma quantidade pré-determinada e que possa depois visualizar todos os livros cadastrados por ele, bem como as informações do cadastro do livro. Para isto, teremos uma tela inicial que serve para a entrada dos dados, uma segunda tela para mostrar todos os livros cadastrados e uma terceira tela que nos servirá para mostrar os detalhes do livro selecionado na segunda janela.
Os dados dos livros cadastrados serão armazenados em memória para facilidade de entendimento do artigo. Assim, resolvemos utilizar um simples array que armazenará todos os livros cadastrados. Por isso, nós limitamos o tamanho máximo do array no código do programa.
Hierarquia de classes do perfil MIDP
Antes de mostrarmos o desenvolvimento do software, vamos observar como estão relacionadas as classes gráficas do perfil MIDP. Na Figura 7 temos a hierarquia de classes da GUI do perfil MIDP. Todas elas se encontram no pacote javax.microedition.lcdui.
Figura 7. Hierarquia de classes GUI do perfil MIDP.
Uma descrição detalhada de cada uma dessas classes está disponível no artigo “Interface Gráfica para Aplicações J2ME: Uma Introdução à MIDP UI API”, escrito por Bruno Lima e Edgar Souza e publicado na edição 5 da WebMobile. Vale salientar que o funcionamento das classes tanto para celulares quanto para PDAs é o mesmo, mudando-se somente a disposição e formato dos componentes gráficos. Com isso, entraremos agora na parte de desenvolvimento da aplicação.
Desenvolvendo a aplicação
Para facilitar o desenvolvimento, criamos apenas três classes. Uma delas nada mais é do que a classe Livro (Listagem 1), que contém as informações que serão utilizadas pela aplicação sobre cada livro. A segunda classe é a CaixaMensagem, onde implementamos uma pequena tela de alerta (caixa de mensagem) configurável que será utilizada na aplicação e, por fim, a classe MBiblioteca, que é a classe que herdará de MIDlet e gerenciará todo o restante da nossa aplicação.
Antes de começarmos a escrever código, criemos um projeto no Sun Java Wireless Toolkit 2.3 Beta (ver Nota 2 e Nota 3) (SJWTK). Vá em Iniciar ? Sun Java Wireless Toolkit 2.3 Beta ? KToolbar. Clique no botão New Project para criar um novo projeto. Em Project Name escreva mBiblioteca e em MIDlet Class Name escreva MBiblioteca (definida anteriormente para o nosso estudo de caso). Para as configurações, pode-se seguir as apresentadas na Figura 8. Basta agora apenas apertar o botão OK.
Nota 2. Sun Java Wireless Toolkit 2.3 Beta
Se você tem acompanhado as notícias do mundo J2ME, já deve saber que a Sun liberou uma versão beta de seu novo Wireless Toolkit. Só que desta vez ela resolveu renomear a ferramenta, mas manteve a seqüência de numeração de versão. Assim, temos agora no lugar de Wireless Toolkit 2.2, o Sun Java Wireless Toolkit 2.3 Beta, que traz como novidades as APIs de Security and Trust Services API (JSR 177), Location API (JSR 179) e Content Handler API (JSR 211). Isso sem contar uma API da Nokia, a Scalable Network Application Package (SNAP), que é uma combinação de software cliente e uma infra-estrutura de servidor que suporta a criação de comunidades de games multiplayer. Caso o leitor precise de maiores informações a respeito desta API, pode consultar o site: http://snapmobile.nokia.com. Além disso, o próprio site da Sun já recomenda o download desta ferramenta, que se encontra em: http://java.sun.com/products/sjwtoolkit/download-2_3.html.
Figura 8. Configurações do projeto.
Nota 3. Criando um projeto
Para se criar um projeto, basta apenas que se sigam os passos descritos no artigo Desenvolvendo Aplicações J2ME para PDAs publicado na edição 5 da revista WebMobile. Apesar de neste artigo usarmos o Wireless Toolkit 2.2, nada mudou com o uso do Sun Java Wireless Toolkit 2.3 Beta. Assim, se você não instalou ou não quer instalar o SJWTK, não haverá nenhum problema com relação ao exemplo que apresentaremos.
...
