Desenvolvimento de Aplicações Móveis com J2ME. Andrea foi a primeira colocada no I Concurso Teleco de Trabalhos de Conclusão de Curso (TCC) 2005.

Transcrição

1 Desenvolvimento de Aplicações Móveis com J2ME Andrea Rodrigues de Amorim 1º Colocado I Concurso Teleco de TCC's 2005 Andrea foi a primeira colocada no I Concurso Teleco de Trabalhos de Conclusão de Curso (TCC) 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. 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. Além do prêmio recebido no Concurso do Teleco, recebeu também o Prêmio Destaque Universitário em Informática 2006 do SEPRORGS/SBC. aramorim@gmail.com Série Especial de Tutoriais Este é o primeiro tutorial da Série Especial de Tutoriais do Concurso Teleco de TCC's Seu conteúdo foi obtido do artigo elaborado pela Andrea para a etapa de classificação do concurso. 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. Duração estimada: 20 minutos Publicado em: 15/05/

2 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

3 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. 3

4 Situação Atual 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

5 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. 5

6 Quando o usuário seleciona uma midlet para execução no dispositivo, o gerenciador de aplicativos chama o 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

7 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. 7

8 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: 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

9 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 < 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

10 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. 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. 10

11 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

12 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 respectivamente. 12

13 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

14 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 - 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

15 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 Sim - RMS CelCorpPrefs Quadro 2: Tabela Agenda. 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. RMS CelCorpAgenda Quadro 3: Estrutura do RMS CelCorpPrefs. 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

16 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

17 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 , maio GAMMA, E.; HELM, R.; JOHNSON, R.; VLISSIDES, J. Padrões de Projeto: Soluções reutilizáveis de software orientado a objetos. Porto Alegre: Bookman, KNUDSEN, J. Wireless Java: Developing with J2ME. Berkeley: Apress, LEAL, M. Começando com Java Wireless. Java Magazine, Rio de Janeiro, n. 18, p , MUCHOW, J. W. Core J2ME Tecnologia & MIDP. São Paulo: Pearson Makron Books, SOARES, M. A Tecnologia Java como Diferencial no Mundo dos Celulares. Mundo Java, Curitiba, n. 5, p , maio SOUZA, B. Fazendo Wireless Acontecer: J2ME e o Mercado Brasileiro. Java Magazine, Rio de Janeiro, n. 3, p

18 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