“Uma Aplicação para Visualização de Dados Gráficos em Dispositivos Móveis”

Damázio Pereira Teixeira, Emerson Rodrigo Alves Tavares

Sistemas de Informação – Universidade Presidente Antônio Carlos (FATEC) Conselheiro Lafaiete – MG

damazioaw@oi.com.br, emersontavares@unipac.br

Abstract. The present article describes on the development of an application that integrates mobile devices into the technology Internet, and of its current interaction need to take advantage of all the existent facilities provided by the use of these devices, such as easiness for the access the wanted information, anytime and anywhere. It is presenting, in this, an application through which its user informs a next reference point from its origin position and another one as destiny place. The information is processed and return maps that indicate the way to be done.

Resumo. O presente artigo descreve sobre o desenvolvimento de uma aplicação que integra dispositivos móveis à tecnologia Internet, e de sua atual necessidade de interação para aproveitar todas as facilidades existentes oferecidas pelo uso destes dispositivos, tais como facilidade para o acesso as informações desejadas, onde quer que estejam, a qualquer momento. Neste aplicativo a informação é processada e retorna mapas que indicam o caminho a ser percorrido mediante a informação do usuário, de um ponto de referência próximo de seu lugar de origem e um outro como lugar de destino.

1. Introdução A popularidade e praticidade dos telefones celulares, aliados à grande capacidade de difusão de informações existentes na Internet, fazem com que cada dia novas pesquisas na integração destes dois mundos sejam realizadas. A aliança entre informação e mobilidade oferece uma solução bastante prática e desejada pelos usuários da informação.

Esta crescente necessidade de mobilidade faz com que cada vez mais o usuário procure uma forma prática de obter informações em qualquer lugar a qualquer momento que atenda às suas expectativas. As dificuldades de se estar todo o tempo em um local onde haja um meio fixo para acesso a informações remotas torna promissora a tecnologia que integra a mobilidade de um micro dispositivo com acesso a Internet e outras informações. Com o sucesso obtido pela tecnologia que utilizava Short Message Service (SMS) [WAP, 2003] - serviço de mensagens curtas, tecnologias que integram Internet, imagens coloridas e sons se tornam reais e próximas.

Este trabalho destaca a tecnologia J2ME que abrange e implementa formas de se disponibilizar informações através de dispositivos com baixa capacidade de processamento e armazenamento de informações, por intermédio de um visor de pequenas proporções. Torna acessíveis informações geograficamente distribuídas através de representações gráficas, ou seja, mapas que irão exibir um caminho entre dois pontos de referência informados pelo usuário.

O corpo deste trabalho está organizado da seguinte forma: na Seção 2 a arquitetura J2ME, na Seção 3 as ferramentas de estudos e desenvolvimentos, na Seção 4 a base de dados, na Seção 5 a conectividade, na Seção 6 a aplicação ShowMe.

Seção 2. Arquitetura J2ME A plataforma Java 2 Micro Edition (J2ME) implementa a linguagem Java para vários dispositivos que possuem restrições de processamento, aqui tratado como Sistema Operacional hospedeiro, sendo que neste cita-se principalmente telefones celulares, e alguns comentários sobre PDAs, pagers, Internet screenphones [MUCHOW, 2004].

Sua Arquitetura é dividida em 4 camadas, sendo estas: MIDP, CLDC, KVM, SO assim como mostra a Figura 1. Detalhes a seguir.

Figura 1. Arquitetura do Ambiente

A camada K Virtual Machine (KVM) que corresponde à máquina virtual Java, criada de forma a atender dispositivos de pequeno porte sem perder as características centrais do Java, mas rodando utilizando pouco recurso de memória. O K surgiu de Kilos, fazendo referencia a uma máquina que poderia processar utilizando apenas kilobytes de memória, no caso seria satisfatório para microprocessador RISC – 16 bit e CISC – 32 bits, com até 128 Kb não-volátil. Utiliza de 40 a 80 kb da memória volátil além dos 128 Kb da memória não volátil, dependendo da plataforma utilizada para rodar as suas próprias classes [SUN, 2000]. Os processadores Reduced Instruction Set Computer (RISC), ou computador com um conjunto de instruções reduzidas, são capazes de ler apenas um número reduzido de instruções, o que os torna mais rápidos. Os processadores Complex Instruction Set Computer (CISC), ou computador com um conjunto complexo de instruções, são capazes de executar várias centenas de instruções complexas diferentes, sendo extremamente versátil [MATTOS, 2005] [CORE J2ME, 2004] [J2ME POLISH, 2001].

A camada Connected Limited Device Configuration (CLDC), documentos de configuração para dispositivos limitados, contém Application Programming Interface ou simplesmente API, que é um conjunto de rotinas e padrões estabelecidos por um software para utilização de suas funcionalidades. De modo geral, a API é composta por uma série de funções acessíveis somente por programação, e que permitem utilizar características dos aplicativos menos evidentes ao usuário tradicional. Estas APIs são mínimas para poderem rodar aplicativos em dispositivos móveis com limites de processamento e memória. Dentre as características do CLDC cita-se o mínimo de 160KB de memória para Java, com um processador de no mínimo 16 bits com baixo consumo (adequado a baterias típicas de um celular) e conexão de rede wireless (9.6Kbps – WAP, 144Kbps - GPRS ou 2Mbps - WEP). Mais detalhes sobre os protocolos serão apresentados na Seção 5 [JAVA SUN, 2000].

A segurança, que a CLDC define, está baseada no chamado Sandbox Security Model – modelo de segurança ‘caixa de areia’, isto é, a máquina virtual terá um espaço de memória independente do restante das aplicações do celular (tais como agenda, tons, imagens, configuração, browser WAP, etc). Nesse modelo de segurança restringe-se as operações que podem ser executadas a um conjunto de funções da API tão somente. Nenhuma outra operação é permitida. Com isso, a aplicação não pode acessar a área de memória do calendário ou agenda de contatos do aparelho celular. Outro ponto importante no que tange ao Java é o fato que não é permitido carga de classes definidas pelo usuário de forma a garantir a segurança de qualquer aplicação desenvolvida com a API CLDC [CORE J2ME, 2004] [MUCHOW, 2004] [MATTOS, 2005]. A camada Profile Mobile Information Devices (MIDP), perfil de dispositivo de informação móvel, é a definição de uma arquitetura e APIs associadas, necessárias para prover um ambiente de desenvolvimento aberto. O MIDP foi feito para rodar sobre o CLDC. Para tanto, um MID deve possuir as seguintes características mínimas de hardware (além daquelas que são requeridas pelo CLDC): 128 Kb para os componentes MIDP; 8Kb para dados das aplicações; 32Kb para o JAVA runtime. Suas APIs

necessárias são relacionadas como: Aplicação; Interface do Usuário; Armazenamento Persistente; Rede; Temporizadores; O MIDP herda a conectividade do CLDC e suporta um subconjunto do HyperText Transfer Protocol (HTTP), que pode ser implementado com protocolos IP e não-IP (Wireless Application Protocol, WAP) [REDES, 2001]. O MIDP define um modelo de aplicação que permite que os recursos limitados dos MIDs sejam compartilhados por várias aplicações, as MIDlets. O MIDP também disponibiliza um mecanismo para que as MIDlets possam guardar dados e lê-los mais adiante, ou seja, o armazenamento persistente [FORUM NOKIA, 2000]. MIDlets são aplicativos Java projetados para serem executados em dispositivos móveis. Mais especificamente, uma MIDlet tem como classes Java básicas a CLDC e o MIDP. Um conjunto de MIDlets consiste em uma ou mais MIDlets empacotadas, usando um Java Archive (JAR) e Java Application Descriptor (JAD). Arquivos JAR contêm informações como nome, versão, perfil, configuração, autor, além de informar todas as MIDlets que estão contidas no projeto. Arquivos JAD devem estar disponíveis como parte do conjunto de MIDlets para fornecer informações sobre estas dentro do arquivo JAR, também parâmetros para tomada de decisões pelas APIs (CLDC) e informações ao gerenciador de aplicativos (KVM) que tem como função básica processar estes arquivos (JAR e JAD) [MUCHOW, 2004] [MATTOS, 2005]. Neste, as MIDlets estão estruturadas de forma a armazenar somente a camada de apresentação, ou seja, a parte executável. As informações que irão ser acessadas remotamente serão feitas utilizando os protocolos de conexão WAP, requeridas a um servidor Apache rodando PHP com acesso ao Banco MySQL. Mais detalhes sobre a conexão serão apresentados na Seção 5.

Seção 3. Ferramentas de Estudos e Desenvolvimento O projeto busca tecnologias capazes de atender de forma rápida e segura, sendo planejado e projetado usando tecnologias gratuitas que garantem todas as necessidades para a conclusão bem sucedida deste.

Utilizou-se um computador com o sistema operacional Linux usado para simular servidor de Internet local Apache [APACHE, 2000], a tecnologia J2ME [MUCHOW, 2004] para implementar uma aplicação que interage com a base de dados, um SGDB MySQL versão 4.1 ( padrão ANSI SQL 99 ) [MYSQL, 2001].

Para a modelagem do Diagrama de Entidade e Relacionamento, DER utilizou-se o editor DBDesigner [DBDESIGNER, 2005], que permite desde a elaboração e criação das entidades e seus respectivos relacionamentos, até a conversão direta de script Structured Query Language (SQL) compatíveis com o SGBD MySQL acessado via HyperText Processor (PHP) [PHP, 2000] que é o responsável por fazer a interface com as MIDlets.

Dentre os aplicativos para implementações e testes cita-se o Java 2 Micro Edition Wireless Toolkit 1.0.4_02 (WTK 104) [SUN, 2000] rodando em um conjunto de bibliotecas instalado no sistema Java 2 Standard Edition 1.4.2_02 (J2SDK 1.4). Além de pacotes de APIs CLDC, MIDP específicos para aplicações J2ME [CORE J2ME, 2004] [PORTAL JAVA, 2000].

Seção 4. Base de Dados A Base de Dados está estruturada de forma simplificada conforme a Figura 2, somente com as necessidades de implementação de um protótipo do projeto.

O modelo aqui tratado permite armazenar o necessário de informações para que o aplicativo ao acessar o Servidor Web, tenha um resultado satisfatório a sua requisição. O modelo trata como Referência, o ponto antes mencionado como Origem e Destino informados pelo usuário. Nesta tabela de Referência, além do código tratado como chave única, temos também os atributos localizaçãoX que informa a latitude do ponto, localizaçãoY que informa a longitude do ponto, Nome que guarda a descrição do ponto ou comércio e o Tipo que informa qual o grupo aquela referência pertence: Farmácias, Hotéis, Hospitais, Órgãos Municipais, Pontos Turísticos e Restaurantes. Estas informações de localização X e Y, não adotam o conceito padrão de coordenadas geográficas neste projeto. A adoção deste padrão requeria aparelhos de medição GPS, que daria o Posicionamento Global por Satélites não só dos pontos de referência, mas também de vários pontos no mapa para a diagramação exata dos pontos.

O modelo trata ainda o Caminho como a referência à imagem utilizada no projeto para mostrar o caminho a ser percorrido entre os dois pontos selecionados pelo usuário. Como chave única, o grupo de dois códigos de referência são adotados, além dos atributos de Direção que informa a direção do caminho em forma de direções cartesianas: Norte, Nordeste, Leste, Sudeste, Sul, Sudoeste, Oeste, Noroeste. O atributo Imagem informa a imagem que está salva no servidor e que faz referência aos pontos escolhidos, e que terá que ser carregada para o dispositivo do usuário para a vizualização da requisição.

A Base de Dados foi desenvolvida utiliando o DBDesigner para a modelagem e executado seu script de criação no banco de dados MySQL. Existe para este protótipo um total de 22 registros de pontos de referência, que formam um total de 462 caminhos distintos de orgiem/destino.

Figura 2. Banco de Dados do aplicativo ShowMe

A cidade adotada para o protótipo foi Conselheiro Lafaiete – MG. Somente a parte central da cidade foi utilizada para estruturar informações, mapas e pontos. Como mostra a Figura 3, a partir de um ponto central ( 0,0 ) dá-se origem aos demais pontos.

Figura 3. Diagramação do Mapa em referências X e Y

Seção 5. Conectividade É imprescindível, que o dispositivo móvel que hospeda o aplicativo, consiga fazer conexão sem fio MMS ou WAP, tendo estes serviços configurados, utilizando um canal de suporte ao trafego de dados CSD/ISDN/GPRS oferecidos por operadoras de serviços WAP como OI, TIM, Telemig Celular, etc através de um endereço IP por eles fornecidos.

O Wireless Application Protocol (WAP), ou protocolo de aplicações sem fio tem como função codificar e decodificar, sendo que todo dispositivo móvel com acesso à Internet já o possui integrado. O codificador de conteúdo traduz o WAP para um formato de código compactado (bytecode), com a intenção de reduzir o tamanho e o número de pacotes que trafegam na rede. A comunicação entre dispositivos sem fio é

lenta (por volta de 9.6 Kbps). Por esta razão, os desenvolvedores WAP concentram-se em otimizar os protocolos existentes, tais como HTTP e o TCP [WAP, 2003] para maximizar a transferência de dados e tomando pouca banda em conta [ALVES TAVARES, 2005].

O WAP foi criado para garantir de forma coesa o acesso remoto de informações via dispositivos móveis. Como mostra a Figura 4, existem 4 elementos funcionais que se interagem, sendo um dispositivo móvel, um servidor web, um servidor de conteúdo e um Gateway. O Gateway tem por finalidade fazer a conversão e interface entre os protocolos WAP da rede celular e os protocolos utilizados na Internet pelo Servidor WEB com acesso ao servidor de conteúdo [TELECO, 1999]

Figura 4. Modelo de acesso WAP

Dentre as funcionalidades do Gateway cita-se o armazenamento do "caching" de cabeçalho dos protocolos. Dentre as funcionalidades do proxy cita-se fazer a codificação de conteúdo para o formato binário e a compilação do J2ME, os quais são enviados como arquivos texto pelo protocolo HTTP [TELECO, 1999], e como arquivos binários pelos protocolos através da rede celular. Fazer "caching" de conteúdo de forma a diminuir o volume de acessos aos servidores. Realizar a função de Domain Name Server (DNS) [JUNIOR, 2000] para converter URL's para endereços IP [WAP, 2003]. Fazer a autenticação de usuários, de forma a garantir que apenas os serviços WAP contratados estejam sendo acessados [STALLINGS, 2002].

Citar aqui sobre a tecnologia WiFi, WiMax, 3G e 4G quer prometem reduzir o custo de download em dispositivos móveis [3G AMÉRICAS, 2003].

O acesso remoto ao servidor que possui a base de dados implementada para o aplicativo terá que receber uma requisição padrão, e é com esta função que o Gateway participa da comunicação. Um objeto de conexão, após ser criado, enviará um pedido ao servidor de consulta SQL e esperará por uma resposta.

Seção 6. ShowMe

O Projeto ShowMe foi desenvolvido para possibilitar ao usuário a visualização de um caminho geográfico baseado em um ponto de origem, onde a informação é resultante de um ponto de referência próximo ao seu local atual, e um ponto de destino, onde a informação é resultante de um ponto de referência ou local próximo a este, ou onde este se localiza.

A MIDlet resultante do projeto foi criada para ser hospedada pelo dispositivo móvel que tem características de processamento e armazenamentos baixos, já citados na Seção 2. Com essas características, optou-se por implementar a MIDlet somente com as telas que permitem ao usuário a escolhas das informações de origem e destino, além da opção de requisição do mapa com a informação gráfica. Esta opção foi tomada levando-se em consideração que uma imagem bitmap com qualidade, tomaria muito espaço físico dentro do dispositivo, e que qualquer alteração deste mapa, o usuário teria que fazer um novo download do aplicativo para atualização.

A opção por utilizar apenas imagens bitmap está na popularidade recente de aparelhos que possibilitam desenhos em tela de forma vetorial, que utilizam as bibliotecas MIDP 2.0, que implementam a opção Canvas [FORUM NOKIA, 2000].

Com essa limitação de uso da biblioteca MIDP 1.0, e também por opção de baixo consumo de espaço e processamento pelo dispositivo, todas as imagens foram hospedadas pelo Servidor Web, ficando restrito a MIDlet somente a requisição de uma imagem específica a cada consulta. Essa requisição ocorre no momento em que o usuário, já tendo selecionado os pontos de origem e destino solicita no menu, a opção Caminho. A partir daí, uma requisição que passa pelo Gateway, citado na Seção 5, é convertida e enviada ao Servidor Web. Esta requisição chega no formato numérico, onde o primeiro parâmetro se refere ao ponto de origem e o segundo parâmetro se refere ao ponto de destino. O Servidor Web, ao receber essa requisição, dispara uma rotina de consulta ao banco, onde monta um Select esperando uma reposta do nome de imagem no formato “nomedaimagem.png” o qual contem o caminho entre os dois pontos passados. Com essa informação, o servidor devolve uma resposta que está sendo aguardada pelo Gateway e que será transmitia ao MIDlet hospedado pelo dispositivo móvel.

De posse dessa informação o MIDlet dispara outro evento, agora sendo uma requisição de download ao mesmo Servidor Web. O MIDlet, já conhecendo o endereço IP do servidor, e o caminho da pasta onde estão armazenadas as imagens, concatena essas informações com a resposta a sua solicitação e solicita uma transferência do arquivo de imagem ao dispositivo. A conclusão do download da imagem é razoavelmente lenta, visto que o tamanho da imagem em bits chega a ser 10 vezes maior que a previsão da taxa de transferência de dados ( 9.6Kbps – WAP ). Dependendo do local, essa conexão sofre variações na taxa de transferência reduzindo-a, gastando-se maior tempo de conclusão. O custo médio do serviço wap pelas operadoras é de

R$0,30/min, sendo que para uma consulta ao aplicativo ShowMe o usuário gasta pouco menos de 1 minuto.

A seguir, uma demonstração mais detalhada da navegação no aplicativo utilizando-se um simulador de dispositivo móvel. A Figura 5 mostra a opção que será escolhida pelo usuário onde poderá ter em seu dispositivo móvel vários outros aplicativos. Para este aplicativo “ShowMe”, depois de selecionado, exibirá uma tela solicitando a escolha da opção menu do dispositivo para seleção das opções. Estas telas são formulários montados por um conjunto de objetos, sendo então denominados MIDlets.

Figura 5. Telas de Seleção de Objetivo

Selecionado o menu por parte do usuário, o aplicativo exibirá uma lista de opções em grupos homogêneos dos pontos de referência nele contidos. Na Figura 6, pode-se observar um procedimento tomado para a seleção do ponto de origem. Os grupos foram divididos em Farmácias, Hotéis, Hospitais, Órgãos Municipais, Pontos Turísticos e Restaurantes, onde depois de selecionado, retornará somente resultados condizentes a seu grupo. É possível criar objetos que serão responsáveis por setar, através de seus métodos, os valores referentes à origem e destino. Estes valores servirão como parâmetros de consulta no instante em que o usuário solicitar o caminho.

Figura 6. Telas de Seleção de Referencia de Origem e ou Destino

Assim que escolhido, o aplicativo retorna na tela inicial, onde possibilita a escolha da opção menu do dispositivo móvel. Após a escolha da origem e destino, o usuário solicita a informação do trajeto através da opção Caminho contida no menu principal, como mostra a Figura 7. Ao selecionar esta opção, o aplicativo fará um pedido de conexão, e passa a essa requisição os parâmetros selecionados, resultantes da origem e destino.

O Usuário, após esperar pela conclusão do download, poderá navegar pela imagem para localizar o ponto de origem informado e o caminho desenhado até o ponto de referência de destino, como mostra a Figura 7. Para realizar uma nova consulta, o usuário solicita a opção sair e refaz toda a escolha do ponto de origem e destino, seguido do pedido de visualização do caminho. Caso o usuário não informe novamente as duas referências, as referências antigas estarão armazenadas no objeto e serão utilizadas como parâmetros para a nova consulta do caminho.

Figura 7. Telas de Exibição do Resultado da Busca

Para que estas informações sejam extraídas dos recursos de memória do dispositivo móvel, basta o usuário solicitar o encerramento do aplicativo escolhendo a opção Sair no menu principal.

A implementação do projeto encontrou algumas dificuldades na estruturação da MIDlet por falta de exemplos mais amplos e comentados nas bibliografias encontradas durante a pesquisa. Por se tratar de uma tecnologia ainda recente, em especial no Brasil, fórum de discussões [CODE BLOOD, 2004][IBM WT,2003] ainda tratam muito da limitação dos dispositivos, bem como das bibliotecas a estes associadas que não permitem hoje o desenvolvimento de uma aplicação mais robusta. Dentre outras dificuldades, destaca-se também a falta de padrão tomada pelos fabricantes de dispositivos, que lança ao mercado diversas opções de aparelhos com implementações de MIDP e CLDC diferentes, citados na Seção 2, de tamanhos e resolução de telas, de capacidade de armazenamento e processamento. Estas diferenças inviabilizam os projetos desenvolvidos que visam aplicativos genéricos capazes de atender a uma grande parte de aparelhos, acarretando na maioria das vezes, implementações diferentes para cada tipo de aparelho para obter o mesmo resultado.

.

Conclusão O principal objetivo deste trabalho foi desenvolver um projeto de integração de tecnologias sem fio em um ambiente móvel e fazer a sua implementação utilizando a tecnologia J2ME para a construção de telas que possibilitam a visualização de um

caminho a ser percorrido entre dois pontos, através de imagens armazenadas em um Servidor Web com auxílio de um Banco de Dados hospedados remotamente.

A tecnologia de desenvolvimento de sistemas para equipamentos móveis não pára de evoluir. O retrospecto que mostra os modernos aparelhos integrando a facilidade de acesso a informações, o transforma em um potencial mercado de trabalho para desenvolvedores de sistemas para dispositivos móveis. Devido às limitações, citadas durante o artigo, o acesso remoto de informações da Internet via dispositivo móvel não teve um ápice assim como a Internet, por tê-la como meio comparativo ao volume de informações e imagens disponibilizadas de uma só vez.

Mesmo com essas restrições, a tecnologia é portadora de um meio contínuo de possibilidades e tendências inovadoras que estão chamando a atenção de investidores e pesquisadores que acreditam que após a quebra dos paradigmas de processamento, armazenamento e visualização, o sucesso da integração de redes sem fio utilizados por dispositivos móveis à Internet será exponencial. Para a conexão remota, o investimento nas tecnologias que integram a 3ª e 4ª geração, além da rede sem fio WiMax que está entrando forte no mercado, poderão mitigar significativamente o custo de informações trafegadas pela rede sem fio entre um dispositivo móvel e um Servidor Web.

O aplicativo aqui citado é uma das infinitas possibilidades que a tecnologia permite criar. Este projeto demonstra na prática uma possibilidade da integração destas ferramentas que permitem desde o armazenamento de informações, até o seu acesso remoto através de dispositivos não necessariamente conectados fisicamente. Vale ressaltar que o objetivo maior deste projeto teve como diretriz, mostrar que mesmo utilizando recursos escassos de programação, é possível obter com sucesso uma comunicação entre dispositivos móveis e serviços oferecidos por Servidores Web, além de abrir um leque para as informações Geograficamente referenciadas que estão ganhando cada vez mais a atenção no mercado competitivo.

Não foram avaliadas técnicas de Qualidade de Serviço, algorítimos de análise para melhor rota entre dois pontos, e também implementações dinamicamente ajustáveis. Ficando como adaptações e trabalhos futuros a análise destas diretrizes. Sugere-se incluir funcionalidades no aplicativo para permitir o acesso a estatísticas e gráficos coloridos gerados no momento de sua requisição, permitir a construção das telas dinamicamente para que evite versões do aplicativo para o acréscimo de pontos de referência e também implementar uma forma segura do acesso às informações contidas no banco de dados hospedados em um servidor WEB.

.Referências

[ 3G AMERICAS, 2003 ] 3G americas - Unificando as Américas das Tecnologias de Comunicações sem Fio, In http://www.3gamericas.org, acessado em Maio/2005.

[ APACHE, 2000 ] HTTP Apache Server, In http://www.apache.org, acessado em Abril/2005.

[ ALVES TAVARES, 2005 ] Alves Tavares, Emerson Rodrigo, Simulação e análise do tráfego de dados em redes móveis sem fio utilizando WAP, Dissertação de Mestrado, UFMG, 2003.

[ CODE BLOOD, 2004] Code Blood - Tutoriais, In http://www.code-blood.com.br, acessado em Maio/2005.

[ DA SILVA, BARBOSA, ANDRADE, DE CASTRO, 2005 ] da Silva, Leandro Fernandes; Barbosa, Carlos Henrique Nogueira R.; Andrade, Alessandro Vivas; de Castro, Cristiano Leite. "Uma Ferramenta Didádita para Aprendizagem de Redes Sem Fio" . Belo Horizonte . DCET .

[ DBDESIGNER, 2005 ] DBdesigner 4 – fabFORCE.net – In http://www.fabforce.net/, acessado em Setembro/2005.

[ IBM WT, 2003 ] IBM Wireless Technology – tutorial “Gerenciamento de Sessão com J2ME e PHP“ – In http://www.ibm.com/developer/wireless, acessado em Agosto/2005.

[ CORE J2ME , 2004 ] Core J2ME - Tutoriais / Source Code, In http://www.corej2me.com, acessado em Abril/2005.

[ JAVA SUN, 2002 ] Java – J2ME, In http://java.sun.com/j2me/, acessado em Abril/2005.

[ J2ME POLISH, 2001 ] J2ME Polish – MC60, In http://www.j2mepolish.org, acessado em Abril/2005.

[ PORTAL JAVA, 2000 ] PortalJava.com, In http://www.portaljava.com.br, acessado em Março/2005.

[ JUNIOR, 2000 ] Junior, Givanildo Francisco da Silva. Wireless Application Protocol, Monografia WAP, 2000.

[ MYSQL, 2001 ] MySql System of Database Management, In http://www.mysql.com, acessado em Maio/2005.

[ FORUM NOKIA, 2000 ] MIDP 1.0, In http://www.forum.nokia.com, acessado em Abril/2005.

[ MUCHOW, 2004 ] Muchow, John W.. Core J2ME Tecnologia & MIDP. 1a edição: Pearson Makron Books, 2004.

[ MATTOS, 2005 ] Mattos, Érico Tavares de. Programação Java para Wireless / Érico Tavares de Mattos. São Paulo: Digerati Books, 2005.

[ PHP, 2000 ] PHP Dynamic Language, In http://www.php.net, acessado em Abril/2005.

[ SOARES, 2002 ] Soares, Wallace - Programando em PHP - Conceitos e Aplicações, 2002.

[ STALLINGS, 2002 ] Stallings, W. “Wireless Communications and Networking”, Prentice Hall PTR, New Jersey, 2002, 1a edição.

[ TELECO, 1999 ] Teleco – Informação para o aprendizado contínuo em telecomunicações, In http://www.teleco.com.br/, acessado em Maio/2005.

[ TEIXEIRA,DIAS,BARBOSA,TAVARES, 2004 ] Teixeira, Damázio Pereira; Dias, Clenerson Domiciano; Barbosa, Felipe Neiva; Tavares, Emerson Rodrigo Alves. "Uma Aplicação para Controle Acadêmico em Redes Móveis sem Fio, utilizando WAP" . Anais do WorkCompSul, Florianópolis, SC, 2004 - ISBN 85-86870-25-0.

[ WAP, 2003 ] WAP Forum, 2003, In http://www.wapforum.org, acessado em Junho/2005.

[ WELLING, THOMSON, 2003 ] Welling, Luke. Thopmson, Laura – PHP e MYSQL Desenvolvimento Web, Editora Campos – 2ª Edição, 2003.

[ W3.ORG, 1999 ] W3 ORGANIZATION, In http://www.w3.org, acessado em Outubro/2005.

[ W3 SHOOLS, 1999 ] W3 Shools, In http://www.w3schools.com, acessado em Outubro/2005.