Desenvolvimento de Aplicações Móveis com J2ME

Desenvolvimento de Aplicações Móveis com J2ME
Esta Série Especial de Tutoriais apresenta os trabalhos premiados no I Concurso Teleco de Trabalhos de
Conclusão de Curso (TCC) 2005.
O conteúdo deste tutorial foi obtido do artigo classificado em primeiro lugar no concurso, de autoria da
Andrea Rodrigues de Amorim.
Este tutorial descreve o projeto e a implementação de um protótipo de aplicação para telefone celular que
acessa um servidor corporativo usando a tecnologia JAVA para dispositivos móveis.
Andrea Rodrigues de Amorim
Bacharel em Sistemas de Informação (2005/2, ULBRA - Canoas, RS), atua desde 1996 na área de
Informática, trabalhando com Treinamento, Help-Desk, Desenvolvimento de Software, Web Design e
Administração de Rede Windows.
Atuou em treinamento de Sistemas Operacionais Windows a aplicativos Office e Internet em empresas de
Porto Alegre, RS, tais como InterOp, TBA Informática e SENAC, e na Administração da Rede Windows
2000, Manutenção de Website, Desenvolvimento e Manutenção de Software e Migração de sistemas e
novos projetos para a plataforma Java, na Comercial de Informática UltraService (Porto Alegre).
Atuou também no Desenvolvimento e manutenção de sistema web/mobile para pesquisa de mercado usando
a plataforma Java, na LCA Promoções(Porto Alegre).
Atualmente trabalha com o desenvolvimento de aplicações móveis integradas a sistemas web, tendo
participado como palestrante em eventos voltados ao desenvolvimento de aplicações em Java, além de ser
também membro-fundador da Confraria do Java: grupo de estudos em Java da ULBRA.
Foi também a primeira classificada no I Concurso Teleco de Trabalhos de Conclusão de Curso (TCC) 2005,
e recebeu o Prêmio Destaque Universitário em Informática 2006 do SEPRORGS/SBC.
Email: [email protected]
Categoria: Telefonia Celular
Nível: Introdutório
Enfoque: Técnico
Duração: 20 minutos
Publicado em: 15/05/2006
1
J2ME: Introdução
No mundo atual, a necessidade de integrar comunicação e mobilidade se torna cada vez maior. Com a
quebra da fronteira entre os mercados, as empresas buscam soluções que viabilizem seus negócios, tanto a
nível gerencial como operacional, dentro desta nova realidade que impõe a realização de comunicações e
operações de acesso a dados a qualquer hora, a partir de qualquer lugar do planeta.
A explosão da tecnologia móvel nos últimos anos abriu um universo de possibilidades para os
desenvolvedores de aplicativos. Entretanto, a diversidade de plataformas a serem integradas e a
preocupação com a performance são desafios a serem considerados.
O objetivo geral deste trabalho é o estudo da tecnologia Java para dispositivos móveis aplicado a uma
solução para integrar o ambiente empresarial com seus colaboradores, quando estiverem fora da sede.
Com os objetivos específicos de garantir portabilidade e desempenho a custos reduzidos, este artigo descreve
o projeto e a implementação do protótipo de uma aplicação para telefone celular que acessa um servidor
corporativo.
A seção O Mundo Sem Fio expõe uma visão geral da tecnologia sem fio.
A seguir, a seção Tecnologia J2ME introduz a edição J2ME da linguagem Java e descreve o processo de
desenvolvimento de aplicações com essa tecnologia.
A Seção Metodologia descreve, além da metodologia propriamente dita, os padrões de projeto, a análise do
problema, os requisitos do projeto e os recursos necessários para implementação do protótipo.
A Seção Projeto CelCorp apresenta a solução proposta detalhando a arquitetura e os módulos da aplicação,
apresentando o enfoque da definição dos dados e a padronização das interfaces.
A Seção Detalhamento dos Dados apresenta a definição e o detalhamento da estrutura de dados do projeto.
Finalmente, na Seção Considerações finais são apresentadas as conclusões obtidas a partir do
desenvolvimento do projeto Celcorp.
2
J2ME: O mundo sem fio
O principal objetivo da tecnologia sem fio é proporcionar mobilidade, ou seja, permitir que os usuários
obtenham qualquer tipo de informação, em movimento (LEAL, 2004).
Vantagens
Num cenário onde os colaboradores das empresas precisam enfrentar viagens, engarrafamentos e
deslocamentos constantes, a possibilidade de acesso às informações relevantes ao desempenho de suas
funções, a qualquer momento, é vital para o crescimento das organizações.
A tecnologia sem fio torna possível adicionar mobilidade às soluções convencionais, sem criar aplicações
totalmente novas (LEAL, 2004), inserindo módulos que irão agregar valor às ferramentas pré-existentes
evitando o descarte de tecnologia e contornando a resistência natural dos clientes a mudanças drásticas.
Problemas
O maior problema enfrentado no desenvolvimento de aplicações móveis é a escassez de recursos dos
equipamentos sem fio disponíveis atualmente no mercado. Considerando os aparelhos celulares, pode-se
destacar restrições como: disponibilidade da rede, tamanho da tela, quantidade limitada de memória, poder
de processamento reduzido.
Além disso, com a diversidade de arquiteturas existentes tanto entre os dispositivos móveis como entre os
ambientes de produção das organizações, a conectividade entre eles e a conseqüente portabilidade torna-se
um grande desafio das aplicações móveis.
Tecnologias Disponíveis
As principais tecnologias disponíveis atualmente para a implementação de soluções móveis são: SMS, MMS,
BREW, SuperWaba e Java 2 Micro Edition (J2ME).
É importante salientar que estas tecnologias não são excludentes podendo uma aplicação móvel utilizar-se
de mais de uma delas.
Segundo LEAL (2004) e SOARES (2004) a tecnologia J2ME proporciona o melhor custo/benefício na
medida que:
Profissionais da linguagem Java podem ser aproveitados;
Amplamente adotada pelos fabricantes e operadoras de telefonia móvel;
Uma vez que a aplicação estiver instalada poderá ser utilizada fora da área de cobertura ou sem sinal,
fazendo sincronização dos dados no retorno;
Compatibilidade de plataformas: aplicativos Java são escritos uma vez e rodam em diferentes
dispositivos com sistemas operacionais diferentes;
Permite implementar criptografia extra para aplicativos de acesso a bancos entre outros;
Fornece um cliente de rede sofisticado permitindo tirar proveito das vantagens e particularidades dos
aparelhos móveis.
Situação Atual
3
De acordo com ALMEIDA (2004), em 2002 já existiam 50 milhões de aparelhos celulares com a máquina
virtual Java em operação no mundo. Ele estima que até 2007, cem por cento dos celulares serão compatíveis
com J2ME.
Entre as empresas que atualmente oferecem algum tipo de solução móvel podemos destacar a Compera, a
Class Systems Solutions, e as gaúchas Trevisan Tecnologia, Human Mobile, Criterium e Mobisol.
Apesar de toda a tecnologia disponível, a oferta de aplicações móveis ainda é pequena deixando um enorme
mercado a ser explorado. Segundo SOUZA (2003), a parceria entre as operadoras de telefonia móvel e os
desenvolvedores poderá mudar este cenário.
4
J2ME: A tecnologia J2ME
A plataforma J2ME é a edição da linguagem Java que foi projetada para dispositivos com memória, vídeo e
poder de processamento limitados, variando desde máquinas ligadas à TV até telefones celulares.
Antes do surgimento da tecnologia J2ME as aplicações tinham que ser escritas na linguagem nativa de cada
dispositivo usando bibliotecas proprietárias, o que as tornavam incompatíveis com dispositivos diferentes.
Arquitetura J2ME
A arquitetura da plataforma J2ME permite ao desenvolvedor conhecer informações específicas sobre as
diferentes famílias de dispositivos e as Application Program Interfaces (APIs) disponíveis para cada uma
delas (ALMEIDA, 2004).
A máquina virtual J2ME foi projetada para ser menor e mais eficiente do que a máquina virtual J2SE, sendo
um subconjunto desta. Em função disso, ocupa aproximadamente 60 kilobytes de memória em tempo de
execução.
A máquina virtual J2ME é chamada KVM numa alusão à pequena quantidade de memória exigida, que está
na ordem dos kilobytes. É a base da arquitetura, localizada logo acima do sistema operacional hospedeiro,
seguida pelas Configurações que dão suporte aos Perfis.
Uma configuração define as características mínimas de uma família de dispositivos, bem como os recursos e
bibliotecas Java que a compõem (MUCHOW, 2004). Estão divididas em:
Connected Device Configuration (CDC): conjunto de APIs para dispositivos “fixos”, como um
computador ligado à televisão;
Connected Limited Device Configuration (CLDC): conjunto de APIs para dispositivos com poder
de processamento, vídeo e memória limitados, geralmente móveis.
Um perfil define um conjunto de APIs que fornece funcionalidade a uma configuração, sendo mais
específico que esta (ALMEIDA, 2004). Os perfis existentes são:
Foundation Profile: base para dispositivos em rede sem interface gráfica, usado com CDC;
Personal Basis e Personal Profile: base para dispositivos com suporte gráfico e alta capacidade,
usado com CDC;
Mobile Information Device Profile (MIDP): perfil compatível com CLCD implementa
componentes, entrada e tratamento de eventos de interface com usuário, armazenamento persistente,
interligação em rede, segurança, entre outros recursos.
Desenvolvimento de Aplicações
Aplicativos criados usando-se MIDP são chamados midlets. Uma aplicação móvel é composta por uma ou
mais midlets empacotadas em um arquivo Java Archive (JAR) e um arquivo descritor da aplicação (Java
Application Descriptor - JAD), formando um conjunto chamado MIDlet Suíte ou Conjunto de Midlets.
Uma midlet passa por várias fases e assume três estados diferentes durante o seu ciclo de vida.
Quando o usuário seleciona uma midlet para execução no dispositivo, o gerenciador de aplicativos chama o
5
método construtor da classe MIDlet e a aplicação inicia no estado de pausa. Em seguida, o próprio
gerenciador de aplicativos chama o método startApp() que altera o estado da midlet para ativo.
Enquanto a midlet estiver ativa, o gerenciador de aplicativos poderá suspender sua execução através da
chamada do método pauseApp() fazendo com que a midlet retorne ao estado de pausa. A própria midlet
também poderá colocar-se em pausa chamando o método notifyPaused().
Uma vez em pausa, o método resumeRequest() irá informar ao gerenciador de aplicativos que a midlet está
pronta para ser ativada novamente. O gerenciador fará uma nova chamada ao método startApp() para ativar
a midlet. Portanto, este método poderá ser executado várias vezes durante o ciclo de vida da aplicação.
Estando a midlet em pausa ou ativa, se o gerenciador de aplicativos chamar o método destroyApp(), a midlet
fica no estado destruída até que o coletor de lixo libere os recursos alocadas pela mesma, encerrando sua
execução. A própria midlet também pode encerrar sua execução através da chamada do método
notifyDestroyed() que deverá implementar a liberação dos recursos da aplicação.
O perfil MIDP fornece uma gama de componentes para o desenvolvedor construir as interfaces da sua
aplicação. A classe Display representa a tela do dispositivo e cada midlet terá apenas uma referência para
um objeto display que poderá exibir diferentes elementos.
Estes elementos são objetos das subclasses de Displayable e representam alguma coisa que pode ser vista na
tela do dispositivo. Segundo KNUDSEN (2003), o funcionamento básico de uma midlet pode ser resumido
nas seguintes etapas:
Mostrar um Displayable;
Esperar por ação do usuário;
Decidir qual Displayable mostrar em seguida;
Repetir a etapa 1.
A configuração CLDC define um framework de conexão genérica onde apenas uma classe, Connector, pode
criar qualquer tipo de conexão.
Em tempo de execução, esta classe recebe a solicitação de abertura de algum tipo de conexão e procura a
classe adequada para a conexão desejada, retornando um objeto que implementa uma das interfaces
Connection.
A implementação dos protocolos está definida em nível de perfil e no MIDP 1.0 a única implementação
exigida é a do protocolo HTTP versão 1.1.
A plataforma J2ME permite o armazenamento de informações nos dispositivos móveis através do Record
Management System (RMS).
Este sistema fornece classes e métodos para manipulação de arquivos de registros. Cada registro consiste em
um identificador de registro, gerado pelo RMS, e um array de bytes contendo os dados a serem
armazenados.
6
J2ME: Metodologia
A metodologia escolhida para o desenvolvimento do protótipo foi a Análise e Projeto Orientado a Objetos
por ser o paradigma mais atual em termos de criação de sistemas. Além disso, esta metodologia permite a
construção de aplicações a partir de duas características básicas: reutilização de código e modularidade.
Para implementar esta metodologia foi utilizada a Unified Modeling Language (UML) que é uma linguagem
para visualizar, especificar, construir e documentar projetos de sistemas orientados a objetos.
Padrões de Projeto
Segundo GAMMA, HELM, JOHNSON et al. (2005), os padrões de projeto são descrições de objetos e
classes que precisam ser personalizadas para resolver um problema de projeto num determinado contexto.
Os padrões utilizados no desenvolvimento do protótipo foram os seguintes:
Padrão Model-View-Controller (MVC): a abordagem MVC é um modelo do uso combinado de
padrões que permite a construção de aplicações em três camadas. A camada Model será responsável
pela persistência dos dados. A camada View é a apresentação na tela e permite a interação da
aplicação com o usuário. A camada Controller faz a ligação entre as outras camadas definindo como
o sistema reage às entradas do usuário. O objetivo deste modelo é fazer com que as camadas de
apresentação e de persistência sejam independentes uma da outra. A camada controladora impede que
o impacto produzido por alterações numa camada atinja a outra;
Padrão Singleton: este padrão de criação de objetos garante que uma classe tenha apenas uma
instância, fornecendo um ponto global de acesso a ela. A própria classe deve ser responsável por
controlar a criação de sua única instância;
Padrão State: este padrão comportamental permite a um objeto alterar seu comportamento conforme
seu estado interno muda. O objetivo deste padrão é definir uma classe abstrata para representar os
estados dos objetos onde as subclasses implementam os comportamentos específicos de cada estado.
Análise do Problema
A definição do problema foi feita a partir das seguintes premissas:
A globalização no mundo dos negócios resultou na queda da distinção entre os mercados interno e
externo;
A evolução das tecnologias de comunicação trouxe agilidade para o ambiente empresarial gerando a
necessidade de rapidez na tomada de decisões;
Os deslocamentos constantes dos colaboradores dificultam o exercício de suas funções;
A competição acirrada exige que as organizações possuam algum diferencial em relação aos seus
concorrentes;
Analisando o cenário atual, a possibilidade de acesso remoto ao ambiente empresarial pode ser
considerada como um fator crítico de sucesso para muitas organizações.
Descrição de Requisitos
Considerando a importância da mobilidade para o crescimento das organizações e levando em conta o
escopo do projeto, podemos destacar os seguintes requisitos do sistema:
7
Dar acesso à agenda corporativa de compromissos permitindo consulta, inclusão, alteração e exclusão
de itens da agenda quando o usuário estiver fora do ambiente empresarial;
Proporcionar este acesso remoto à agenda tanto através de um aparelho celular como via navegador
web;
Permitir a utilização da aplicação móvel fora da área de cobertura;
Possibilitar que os dados armazenados no aparelho celular sejam transferidos posteriormente para o
servidor web;
Fornecer meios para que o administrador do sistema mantenha o cadastro dos usuários, bem como
seus níveis de acesso;
Permitir que o usuário da aplicação móvel escolha se deseja conectar-se ao servidor web ou trabalhar
localmente;
Garantir que a aplicação seja compatível com sistemas pré-existentes;
Assegurar que a aplicação móvel possa ser instalada na maioria dos aparelhos celulares em operação.
Recursos de Hardware
Os requisitos de hardware para desenvolvimento, testes e operação do protótipo são:
Micro-computador Pentium III 800 MHz ou superior;
Memória 256 Mb ou mais;
Placa de vídeo SVGA 800x600, Hi-Color;
Disco rígido com 5 Mb livres ou mais;
Servidor Web para hospedagem do sítio;
Servidor de banco de dados;
Aparelho celular com suporte para CLCD 1.0 e MIDP 1.0.
Recursos de Software
Os requisitos de software para desenvolvimento, testes e operação do protótipo são:
NetBeans 4.1;
Tomcat 5.0;
Módulo de mobilidade para o NetBeans 4.1;
Banco de dados PostgreSQL 8.0;
Driver JDBC para o PostgreSQL 8.0;
Sítio com módulo servidor da aplicação;
Banco de dados;
Navegador web;
Aplicativo móvel instalado no aparelho celular.
8
J2ME: Projeto CelCorp
O projeto proposto refere-se a uma aplicação móvel para telefones celulares, o CelCorp, que visa oferecer
acesso à agenda de compromissos corporativa, suprindo a necessidade de mobilidade do ambiente
empresarial.
Por limitações de escopo, o projeto CelCorp foi implementado como um protótipo composto por dois
módulos móveis - Agenda e Preferências – e um módulo servidor que também pode ser acessado via
navegador de internet.
A fim de simular o servidor web de uma empresa foi utilizada a estrutura de um sítio que oferece
hospedagem para aplicações Java. O acesso à base de dados é feito através de uma conexão com este
servidor web.
O módulo servidor pode ser acessado em <http://javatest.confrariadojava.org/CelCorpWeb> usando a
identificação do usuário de testes: teste e senha 123.
O módulo servidor da aplicação será formado por um contêiner web onde estarão armazenadas as servlets
que farão a comunicação com as midlets (clientes da aplicação) e o banco de dados para armazenar as
informações da agenda de compromissos, cadastro de usuários e permissões de acesso.
As servlets farão o acesso aos dados a partir de dois arquivos de propriedades que poderão ser configurados
conforme o banco de dados utilizado pelo cliente. O primeiro arquivo contém os dados da conexão
propriamente dita: driver, nome da base de dados, usuário e senha de acesso.
O segundo arquivo possui os comandos da linguagem Structured Query Language (SQL) adaptados à
sintaxe do banco de dados desejado. O protótipo do CelCorp usará o banco de dados PostgreSQL 8.0.
A fim de manter a compatibilidade do sistema com a grande maioria dos celulares em operação, a aplicação
móvel está sendo desenvolvida usando a configuração CLCD 1.0 e o perfil MIDP 1.0 da tecnologia J2ME. A
comunicação com o servidor web será feita através de conexão genérica HiperText Transfer Protocol
(HTTP).
Arquitetura do Projeto
O CelCorp foi projetado em três camadas seguindo o padrão MVC (Model-View-Control). A Figura 1
apresenta os módulos da aplicação móvel e o relacionamento entre eles, permitindo identificar as camadas
do padrão.
9
Figura 1: Diagrama de Pacotes CelCorp.
A camada View é responsável pela interface com o usuário. A camada Control permite a ligação entre as
camadas view e database da aplicação. É nesta camada que são feitas as validações e o controle do fluxo de
entrada e saída de dados.
A camada Model corresponde aos pacotes database da aplicação e é responsável pelo armazenamento
persistente dos dados.
O padrão Singleton foi utilizado na criação de objetos pois segundo GAMMA, HELM, JOHNSON et al.
(2005, p.130), este padrão garante que somente uma instância de cada classe seja criada durante todo o ciclo
de vida da aplicação.
Este padrão é bastante útil nas aplicações móveis por economizar o poder de processamento do dispositivo
evitando a criação e destruição de objetos que serão reutilizados em seguida.
Módulos Móveis
O módulo Preferências apresenta opções de configuração do sistema que podem ser alteradas pelo usuário.
As configurações disponíveis são:
Solicitar senha: o padrão do sistema é solicitar os dados de identificação (login e senha) apenas uma
vez, armazenando-os no aparelho celular. Se desejar, o usuário poderá definir que o login e senha
sejam solicitados sempre que entrar na aplicação;
Confirmar conexão: o padrão do sistema é conectar-se automaticamente ao servidor web. Entretanto,
o usuário poderá configurar o sistema para solicitar sua confirmação antes de efetuar a conexão.
O módulo Agenda permite ao usuário incluir, editar, excluir, consultar e sincronizar compromissos da sua
agenda corporativa tanto localmente como de forma remota através do módulo servidor.
Quando a comunicação com o servidor web estiver disponível, todas as operações serão realizadas no
servidor e nenhum dado será armazenado no celular, configurando o estado online.
Quando a conexão não for possível ou desejável, os dados e operações serão gerenciados no próprio
aparelho celular, configurando o estado offline.
10
Para garantir que as operações sejam realizadas adequadamente conforme o estado da aplicação foi utilizado
o padrão State. De acordo com GAMMA, HELM, JOHNSON et al. (2005, p.284) este padrão permite que
um objeto mude seu comportamento em função de seu estado interno.
A Figura 2 apresenta o diagrama de estados do módulo Agenda, indicando as operações responsáveis pelas
mudanças de estado.
Figura 2: Diagrama de Estados da Agenda.
Ao entrar no módulo Agenda o estado InicialState verifica as preferências do usuário e poderá solicitar a
identificação do mesmo no sistema e/ou a confirmação para conectar-se ao servidor web. Conforme a
decisão do usuário o estado da aplicação é alterado e a tela inicial do módulo Agenda é carregada.
Caso a aplicação esteja no estado OnlineState, se ocorrer algum erro na conexão seu estado passará a ser
OfflineState e os dados em memória serão armazenados no celular. No estado OfflineState, se a operação
sincronizar for selecionada pelo usuário, o sistema passará para o estado OnlineState e os dados locais serão
transferidos para o servidor web.
A conexão com o servidor web é feita em uma linha de execução separada permitindo que o dispositivo
continue disponível durante a operação. Para implementar a execução de processos concorrentes foi usada
uma instância da classe Thread.
Módulo Servidor
O módulo servidor permite o acesso às mesmas funcionalidades do módulo Agenda, via navegador de
internet. Além disso, os usuários poderão fazer manutenção nos seus dados cadastrais. O administrador do
sistema poderá também cadastrar, alterar ou excluir usuários.
A arquitetura original em 3 camadas sofre alguma adaptação no ambiente web. A Figura 3 mostra a
arquitetura em 4 camadas do servidor web.
11
Figura 3: Arquitetura em camadas do servidor web.
A camada Web é composta pelas JavaServer Pages que enviam conteúdo dinâmico para o navegador do
usuário. A camada de aplicação é formada pelo conjunto de servlets que fazem a ligação entre as JSP’s e a
camada de persistência que por sua vez, contém as classes de acesso ao banco de dados e os arquivos de
propriedades.
O cliente móvel conecta-se diretamente com a camada de aplicação do servidor web através de uma servlet
que atua fazendo a ligação da aplicação móvel com a camada de dados do servidor. Esta servlet recebe,
interpreta e redireciona os dados conforme a operação solicitada, retornando o resultado.
Definição de Dados
Independente do banco de dados utilizado no servidor web, o protótipo necessita de uma tabela para
armazenar os dados dos usuários e outra para armazenar os compromissos da agenda corporativa.
Para permitir o armazenamento dos dados no dispositivo móvel foram usados três RMS diferentes.
O detalhamento da definição dos dados encontra-se na seção Detalhamento dos Dados.
Padronização das Interfaces
A padronização das interfaces é muito difícil no ambiente J2ME. O desenvolvedor pode e deve usar um
padrão, mas cada dispositivo irá implementá-lo à sua maneira.
A maioria das interfaces da aplicação móvel estende a classe Form por sua capacidade de conter outros
componentes aninhados. Foram adicionados elementos do tipo TextBox para entradas de texto, DateField
para entrada de data/hora, ChoiceGroup para escolha de opções e Gauche para mostrar o progresso da
conexão.
A interface inicial do módulo Agenda usa a classe List pela facilidade de seleção de item da lista com um
único comando que essa classe oferece. As interfaces usadas para exibir mensagens de erro e de sucesso
estendem a classe Alert e estão implementadas de forma que fiquem visíveis durante 5 e 2 segundos
12
respectivamente.
Para permitir aos usuários o acesso às operações do sistema, foram associados objetos da classe Command
às interfaces. Estes objetos possuem propriedades como prioridade e tipo de comando as quais poderão
influenciar a maneira como o dispositivo irá implementá-los.
A interface inicial de cada módulo deve apresentar o comando “Sair” com prioridade um e tipo “EXIT”
para permitir o encerramento daquele módulo. Os outros comandos, relacionados às operações do módulo,
devem ser do tipo “SCREEN” e ter prioridade dois.
As demais interfaces devem conter o comando “Voltar” com prioridade um e tipo “BACK” e apenas mais
um comando do tipo “SCREEN” para confirmar a operação relacionada com a interface. O comando
“Voltar” permite o retorno à interface inicial do módulo sem realizar a operação disparada por aquela
interface.
A Figura 4 mostra a interface inicial do módulo Agenda onde aparecem os compromissos do dia, em ordem
cronológica, e os comandos disponíveis.
Figura 4: Interface inicial do módulo Agenda.
Nesta implementação do simulador, o comando “Sair” aparece sozinho à esquerda e os demais comandos
foram agrupados sob o nome “Menu” do lado direto da tela.
Entretanto, esta apresentação não é uma regra, no celular Nokia 6820, o comando “Sair” aparece à direita, o
comando “Adicionar” ao centro e os demais comandos agrupados à esquerda sob o nome “Opções”.
As interfaces do módulo servidor são as JSP da camada web da aplicação. Devem ser compatíveis com o
padrão visual do sítio da organização e podem ser desenhadas através de folhas de estilos.
13
J2ME: Detalhamento dos Dados
Conforme foi apresentado na seção anterior, que detalhou o Projeto Celcorp, independente do banco de
dados utilizado no servidor web, o protótipo necessita de uma tabela para armazenar os dados dos usuários e
outra para armazenar os compromissos da agenda corporativa.
Para permitir o armazenamento dos dados no dispositivo móvel foram usados três RMS diferentes, os quais
são apresentados a seguir.
Tabela Usuário
A tabela Usuário armazena os dados cadastrais e o nível de acesso ao sistema de cada usuário.
O Quadro 1 mostra a estrutura da tabela Usuário onde o campo perfil indica que o usuário possui acesso de
administrador quando seu valor for igual a 1.
Campo
Tipo de Dado
Tamanho
Valor Padrão
Permitir Nulo
Chave
codusuario
Inteiro
4
-
Não
Primária
Login
Texto
20
-
Não
-
Senha
Texto
20
-
Não
-
Nome
Texto
60
-
Sim
-
Endereco
Texto
60
-
Sim
-
Cidade
Texto
60
-
Sim
-
Estado
Texto
2
-
Sim
-
Cep
Texto
8
-
Sim
-
Pais
Texto
40
-
Sim
-
Email
Texto
80
-
Sim
-
fone_com
Texto
15
-
Sim
-
fone_res
Texto
15
-
Sim
-
fone_cel
Texto
15
-
Sim
-
Fax
Texto
15
-
Sim
-
Perfil
Inteiro
2
0
Sim
-
Quadro 1: Tabela Usuário.
14
Tabela Agenda
A tabela Agenda armazena os dados dos itens de agenda dos usuários. Sua estrutura está descrita no Quadro
2.
Campo
Tipo de Dado
Tamanho
Valor Padrão
Permitir Nulo
Chave
Codagenda
Inteiro
4
-
Não
Primária
Codusuario
Inteiro
4
-
Não
Estrangeira
Data
Numérico
Indefinido
-
Não
-
Titulo
Texto
50
-
Sim
-
Descricao
Texto
100
-
Sim
-
Quadro 2: Tabela Agenda.
RMS CelCorpPrefs
O RMS CelCorpPrefs armazena as preferências do usuário. A estrutura do campo de dados deste RMS é
descrita no Quadro 3.
Tipo de Dado
Tamanho
Representa...
Boolean
1
Quando verdadeiro, indica que os dados de login devem ser
solicitados a cada entrada no sistema. Caso seja falso, este valor
indica que os dados de login devem ser solicitados apenas na primeira
vez que o usuário acessar o sistema e armazenados no celular.
Boolean
1
Quando verdadeiro, indica que a conexão com o servidor web deve
ser automática. Caso seja falso, o sistema irá solicitar confirmação do
usuário para conectar-se ao servidor.
Quadro 3: Estrutura do RMS CelCorpPrefs.
RMS CelCorpAgenda
O RMS CelCorpAgenda armazena os itens de agenda. O campo de dados deste RMS está descrito no
Quadro 4.
Tipo de Dado
Tamanho
Representa...
Inteiro
4
Código do item de agenda.
Longo
4
Data e hora do item da agenda em milisegundos.
Texto
Variável
Título do item da agenda em caracteres UTF.
Texto
Variável
Descrição do item da agenda em caracteres UTF.
Quadro 4: Estrutura do RMS CelCorpAgenda.
15
RMS CelCorpLogin
O RMS CelCorpLogin armazena o login e a senha do usuário no aparelho celular caso o sistema tenha sido
configurado desta forma. O Quadro 5 mostra a estrutura do campo de dados deste RMS.
Tipo de Dado
Tamanho
Representa...
Texto
Variável
Login do usuário para acessar o sistema.
Texto
Variável
Senha do usuário para acessar o sistema.
Quadro 5: Estrutura do RMS CelCorpLogin.
É importante que a leitura do campo de dados dos registros dos RMS’s seja feita na mesma ordem em que os
valores foram gravados.
Além disso, a leitura deve ser seqüencial, ou seja, se o registro foi gravado contendo um valor inteiro, um
texto e um booleano e quisermos recuperar apenas o valor booleano, temos que ler primeiro o inteiro e o
texto para chegar ao valor desejado.
16
J2ME: Considerações Finais
Este artigo apresentou um estudo sobre a tecnologia J2ME e o desenvolvimento do protótipo de uma
aplicação para atender à crescente demanda por mobilidade com disponibilidade no mercado corporativo
atual, o CelCorp. O protótipo possibilita a consulta e manutenção de compromissos de agenda corporativa
através de um aparelho celular via conexão com um servidor web.
O CelCorp foi planejado para ser totalmente compatível com a estrutura de tecnologia da informação já
existente nas empresas. Desta forma, a integração pode ser feita agregando-o como um módulo de
mobilidade aos sistemas pré-existentes.
Esta ferramenta usa tecnologia livre a fim de possuir custo/benefício atrativo para as empresas que
desejarem adotá-la. Além disso, é compatível com a maioria dos aparelhos celulares em operação,
facilitando sua penetração no mercado.
No decorrer do projeto CelCorp ficou evidente a importância do uso de padrões de projeto. Além de facilitar
a manutenção das aplicações, os padrões são fundamentais para o desenvolvedor entender e resolver
problemas na implementação de situações reais, variáveis e complexas.
Apesar da perda de recursos como criptografia nativa, o uso das versões iniciais do J2ME garante a
compatibilidade com a grande maioria dos aparelhos celulares em operação hoje. Além disso, a
modularidade do projeto permite que tais recursos sejam facilmente incorporados no futuro.
Referências
ALMEIDA, L. B. de. Introdução à J2ME e Programação MIDP. Mundo Java, Curitiba, n. 5, p. 20-27, maio
2004.
GAMMA, E.; HELM, R.; JOHNSON, R.; VLISSIDES, J. Padrões de Projeto: Soluções reutilizáveis de
software orientado a objetos. Porto Alegre: Bookman, 2005.
KNUDSEN, J. Wireless Java: Developing with J2ME. Berkeley: Apress, 2003.
LEAL, M. Começando com Java Wireless. Java Magazine, Rio de Janeiro, n. 18, p. 16-19, 2004.
MUCHOW, J. W. Core J2ME – Tecnologia & MIDP. São Paulo: Pearson Makron Books, 2004.
SOARES, M. A Tecnologia Java como Diferencial no Mundo dos Celulares. Mundo Java, Curitiba, n. 5, p.
53-54, maio 2004.
SOUZA, B. Fazendo Wireless Acontecer: J2ME e o Mercado Brasileiro. Java Magazine, Rio de Janeiro, n.
3, p. 12-15. 2003.
17
J2ME: Teste seu Entendimento
1. O uso da tecnologia J2ME proporciona o melhor custo/benefício na medida em que:
Profissionais da linguagem Java podem ser aproveitados.
A tecnologia é amplamente adotada pelos fabricantes e operadoras de telefonia móvel.
Uma vez que a aplicação estiver instalada poderá ser utilizada fora da área de cobertura ou sem sinal,
fazendo sincronização dos dados no retorno.
Fornece um cliente de rede sofisticado permitindo tirar proveito das vantagens e particularidades dos
aparelhos móveis.
Todos os anteriores.
2. Qual dos itens abaixo não representa uma etapa do funcionamento básico de uma midlet
(aplicativos criados usando-se Mobile Information Device Profile – MIDP)?
Iniciar o navegador WAP (etapa 0).
Mostrar um Displayable (etapa 1).
Esperar por ação do usuário (etapa 2).
Decidir qual Displayable mostrar em seguida (etapa 3).
Repetir a etapa 1 (etapa 4).
3. Qual das alternativa não representa uma camada da arquitetura do servidor web usado no projeto
CelCorp?
Camada de Apresentação.
Camada de Web.
Camada de Sessão.
Camada de Aplicação.
Camada de Dados.
18