UTILIZAÇÃO DA TECNOLOGIA J2ME PARA ACESSO AO SERVIÇO DE ...siaibib01.univali.br/pdf/Rodrigo Luiz...

UNIVERSIDADE DO VALE DO ITAJAI CENTRO DE EDUCAÇÃO SÃO JOSÉ

CURSO DE CIÊNCIA DA COMPUTAÇÃO

TRABALHO DE CONCLUSÃO DE CURSO

UTILIZAÇÃO DA TECNOLOGIA J2ME PARA ACESSO AO SERVIÇO DE CORREIO

ELETRÔNICO

Rodrigo Luiz Duarte

São José 2005

RODRIGO LUIZ DUARTE

UTILIZAÇÃO DA TECNOLOGIA J2ME PARA ACESSO AO SERVIÇO DE CORREIO

ELETRÔNICO

Monografia apresentada à Banca Examinadora do Trabalho de Conclusão de Curso de Ciência da Computação da Universidade do Vale do Itajaí, Centro de Educação de São José, como requisito parcial para obtenção do título de Bacharel em Ciência da Computação.

Orientador: Alexandre Moraes Ramos

São José

2005

RODRIGO LUIZ DUARTE

UTILIZAÇÃO DA TECNOLOGIA J2ME PARA ACESSO AO SERVIÇO DE

CORREIO ELETRÔNICO

Este Trabalho de Conclusão de Curso foi julgado adequado como requisito parcial para a

obtenção do título de Bacharel em Ciência da Computação, tendo sido aprovado pelo Curso

de Ciência da Computação, Centro de Educação São José da Universidade do Vale do Itajaí

(SC).

São José, 19 de Dezembro de 2005.

_____________________________ ___________________________________

Prof. Esp. Alecir Pedro da Cunha Prof. M. Eng. Fernanda dos Santos Cunha

Responsável pela Coord. do TCC Coordenadora do Curso

Apresentada à Banca Examinadora formada pelos professores:

________________________________

Orientador Prof. Dr. Alexandre Moraes Ramos

___________________________________________________

Prof. M. Eng. José Francisco Salm Júnior, membro da banca examinadora

__________________________________________________

Prof. M. Eng. Paulo Henrique de Souza Bermejo, membro da banca examinadora

DEDICATÓRIA

Este trabalho de conclusão de curso é dedicado aos meus pais, pela educação e

ensinamentos a mim transmitidos. A minha amada Rubia Truppel, pela

paciência, amor, carinho e incentivo durante esses anos.

AGRADECIMENTOS

Aos meus amigos, pelo apoio, pelos momentos de descontração e alegria. Aos

meus colegas de classe e professores, pela troca de conhecimentos e pela

amizade conquistada.

Não se pode ensinar tudo a alguém, pode-se apenas ajudá-lo a encontrar por si

mesmo.

Galileu Galilei

RESUMO

Este trabalho apresenta o protótipo de uma implementação de serviço de correio eletrônico

para celulares utilizando a tecnologia J2ME, que permite o envio de mensagens contendo

além de texto, anexar arquivos a essas mensagens. A primeira parte do trabalho é composta de

uma revisão bibliográfica sobre a telefonia móvel no Brasil, total de usuários do serviço

móvel e como está distribuído o mercado entre as operadoras. É apresentada também uma

visão sobre as gerações das redes de telefonia móvel, desde a primeira geração representada

pelas tecnologias analógicas, passando para a segunda com a introdução de telefonia digital e

a terceira geração que tem como característica principal a transmissão de dados em alta

velocidade por meio das redes celulares. A segunda parte é aborda algumas tecnologias para o

desenvolvimento de aplicações para dispositivos móveis, entre elas o J2ME que é aplicada

este trabalho, o SUPERWABA que é uma tecnologia brasileira, o .NET da Microsoft, a

plataforma BREW da fabricante de equipamentos para redes celulares Qualcomm e o WAP,

que foi a primeira solução para o desenvolvimento de aplicações para redes celulares. A

terceira parte trata do serviço de correio eletrônico, os protocolos usados para envio e

recebimento de e-mails, o padrão MIME que permite o envio de mensagens em diferentes

formatos, inclusive anexar arquivos às mensagens de texto simples, mensagens HTML, entre

outras. A quarta refere-se ao desenvolvimento do protótipo, arquitetura, funcionamento e

modelagem da solução. Por último são apresentadas as conclusões obtidas, dificuldades

encontradas e algumas sugestões pra trabalhos futuros.

ABSTRACT

This work presents the archetype of an implementation of service of e-mail for cellular using

technology J2ME, that allows the sending of messages contends beyond text, to annex

archives to the these messages. The first part of the work is composed of a bibliographical

revision on the mobile telephony in Brazil, total of users of the mobile service and as the

market between the operators is distributed. A vision on the generations of the networks of

mobile telephony is also presented, since the first generation represented for the analogical

technologies, passing to second with the introduction of digital telephony and third generation

that the transmission of data in high speed by means of the cellular networks has as

characteristic main. The second part is approaches some technologies for the development of

applications for mobile devices, between them the J2ME that is applied this work, the

SUPERWABA that is a Brazilian technology, NET of the Microsoft, platform BREW of the

equipment manufacturer for cellular networks Qualcomm and the WAP, that was the first

solution for the development of applications for cellular networks. The third part deals with

the service of e-mail, the used protocols for sending and act of receiving of e-mails, standard

MIME that the sending of messages in different formats allows, also to annex archives to the

messages of simple text, messages HTML, among others. Fourth one mentions the

development of the archetype, architecture, functioning and modeling to it of the solution.

Finally the gotten conclusions, joined difficulties and some suggestions for future works are

presented.

SUMÁRIO

LISTA DE FIGURAS.............................................................................................................11

LISTA DE TABELAS............................................................................................................13

LISTA DE ABREVIAÇÕES .................................................................................................14

1 INTRODUÇÃO ..........................................................................................................17 1.1 APRESENTAÇÃO .........................................................................................................17 1.2 JUSTIFICATIVA ...........................................................................................................18 1.3 OBJETIVOS .................................................................................................................19 1.3.1 Objetivo geral ...................................................................................................19 1.3.2 Objetivos específicos ........................................................................................19 1.3.3 Escopo e delimitação........................................................................................19 1.4 RESULTADOS ESPERADOS...........................................................................................20 1.5 ASPECTOS METODOLÓGICOS ......................................................................................20 1.6 ESTRUTURA DO TRABALHO ........................................................................................20

2 REDES E TECNOLOGIAS MÓVEIS .....................................................................22 2.1 REDES MÓVEIS ...........................................................................................................22 2.2 REDE CELULAR ..........................................................................................................23 2.3 GERAÇÕES DA REDE CELULAR....................................................................................27 2.3.1 Primeira geração..............................................................................................28 2.3.2 Segunda geração ..............................................................................................30 2.3.3 Terceira geração ..............................................................................................41 2.4 TECNOLOGIAS MÓVEIS ...............................................................................................49 2.4.1 WAP..................................................................................................................50 2.4.2 BREW ...............................................................................................................53 2.4.3 SUPERWABA ...................................................................................................54 2.4.4 Visual Studio.....................................................................................................56 2.4.5 J2ME.................................................................................................................57 2.5 CONSIDERAÇÕES FINAIS .............................................................................................59

3 CORREIO ELETRÔNICO.......................................................................................60 3.1 ARQUITETURA E SERVIÇOS.........................................................................................61 3.2 ENVIO DE MENSAGENS DE CORREIO ELETRÔNICO....................................63 3.2.1 SMTP ................................................................................................................63 3.2.2 Formato de mensagens.....................................................................................65 3.3 RECEBIMENTO DE MENSAGENS DE CORREIO ELETRÔNICO ................................68 3.3.1 POP3 ................................................................................................................69 3.3.2 IMAP.................................................................................................................70

4 PROTÓTIPO DO SISTEMA ....................................................................................71 4.1 ARQUITETURA DO SISTEMA........................................................................................72 4.1.1 Formato das requisições e respostas HTTP.....................................................74 4.2 FUNCIONAMENTO DO SISTEMA...................................................................................77 4.3 MODELAGEM DO SISTEMA..........................................................................................81 4.3.1 Requisitos funcionais e não funcionais ............................................................81 4.3.2 Diagramas UML módulo servidor ...................................................................82 4.3.3 Diagramas UML módulo cliente ......................................................................88 4.4 MODELO DE CICLO DE VIDA........................................................................................94 4.5 CONSIDERAÇÕES FINAIS ............................................................................................94

5 CONCLUSÃO E TRABALHOS FUTUROS...........................................................96 5.1 CONCLUSÃO...............................................................................................................96 5.2 TRABALHOS FUTUROS................................................................................................98

6 REFERÊNCIAS BIBLIOGRÁFICAS .....................................................................99

ANEXOS ...............................................................................................................................102

ANEXO A – CÓDIGO FONTE MÓDULO SERVIDOR.................................................102

ANEXO A.1 – PACOTE BEAN ..........................................................................................102

ANEXO A.2 – PACOTE CONTROLE ..............................................................................104

ANEXO A.3 – PACOTE ENTIDADE ................................................................................110

ANEXO B – CÓDIGO FONTE MÓDULO CLIENTE ....................................................112

ANEXO B.1 – PACOTE BEAN ..........................................................................................112

ANEXO B.2 – PACOTE CONTROLE ..............................................................................114

ANEXO B.3 – PACOTE CONTROLE.ACAO..................................................................115

ANEXO B.4 – PACOTE ENTIDADE ................................................................................122

ANEXO B.5 – PACOTE VISÃO.........................................................................................123

ANEXO C – BIBLIOTECA MOBILELIB ........................................................................142

ANEXO C.1 – PACOTE IO ................................................................................................142

ANEXO C.2 - PACOTE NET..............................................................................................144

LISTA DE FIGURAS

FIGURA 1 - TOPOLOGIA BÁSICA DA REDE CELULAR ...................................................................25

FIGURA 2 - REPRESENTAÇÃO CIRCULAR E HEXAGONAL DE UMA CÉLULA ..................................25

FIGURA 3 - CLUSTER DE CÉLULAS DE TAMANHO 7.....................................................................26

FIGURA 4 – HANDOFF ENTRE AS TORRES A E B .........................................................................27

FIGURA 5 - QUANTIDADE DE CANAIS POR CÉLULA EM UMA REDE AMPS COM 395 CANAIS .......29

FIGURA 6 - UTILIZAÇÃO DO ESPECTRO NO FDMA.....................................................................29

FIGURA 7 - SLOT D-AMPS (IS-136), ESTRUTURA DE FRAME E MULTIFRAME ............................32

FIGURA 8 - SLOT GSM, ESTRUTURA DE FRAME E MULTIFRAME.................................................34

FIGURA 9 - HSCSD DE QUATRO SLOTS......................................................................................39

FIGURA 10 - PERCURSO DE ATUALIZAÇÃO PARA A TERCEIRA GERAÇÃO ....................................42

FIGURA 11 - PILHA DE PROTOCOLOS WAP ................................................................................51

FIGURA 12 - PROCESSO DE DESENVOLVIMENTO SUPERWABA ...................................................56

FIGURA 13 - COMPONENTES DE UM SISTEMA DE CORREIO ELETRÔNICO.....................................62

FIGURA 14 - ARQUITETURA DO SISTEMA ...................................................................................72

FIGURA 15 - DIAGRAMA DE IMPLANTAÇÃO ...............................................................................73

FIGURA 16 - TELA DE ABERTURA DO MÓDULO CLIENTE.............................................................78

FIGURA 17 - TELA PRINCIPAL DO MÓDULO CLIENTE ..................................................................78

FIGURA 18 - TELA DE LOGIN DO MÓDULO CLIENTE....................................................................79

FIGURA 19 - TELA DE ENVIO DE MENSAGENS.............................................................................80

FIGURA 20 - TELA DE PROGRESSO DE AÇÕES NO SERVIDOR .......................................................80

FIGURA 21 - LISTAGEM DO CONTEÚDO DE UM DIRETÓRIO .........................................................81

FIGURA 22 – DIAGRAMA DE CASO DE USO (USC 001 – VALIDA LOGIN) ....................................82

FIGURA 23 – DIAGRAMA DE CASO DE USO (USC 002 – LISTA DIRETÓRIO DO USUÁRIO) ............83

FIGURA 24 - DIAGRAMA DE CASO DE USO (USC 003 - ENVIA MENSAGEM DE CORREIO

ELETRÔNICO) .....................................................................................................................84

FIGURA 25 - DIAGRAMA DE CLASSES DO PACOTE CONTROLE.....................................................85

FIGURA 26 - DIAGRAMA DE CLASSE DO PACOTE BEAN...............................................................85

FIGURA 27 - DIAGRAMA DE CLASSES DO PACOTE ENTIDADE......................................................86

FIGURA 28 - DIAGRAMA DE SEQÜÊNCIA DA VALIDAÇÃO DE LOGIN............................................86

FIGURA 29 - DIAGRAMA DE SEQÜÊNCIA DA LISTAGEM DE DIRETÓRIOS DO USUÁRIO .................87

FIGURA 30 - DIAGRAMA DE SEQÜÊNCIA DO ENVIO DE MENSAGEM ............................................87

FIGURA 31 - DIAGRAMA DE CASOS DE USO MÓDULO CLIENTE ...................................................88

FIGURA 32- DIAGRAMA DE CLASSES DO PACOTE CONTROLE DO MÓDULO CLIENTE ...................91

FIGURA 33 - DIAGRAMA DE CLASSES DO PACOTE VISAO DO MÓDULO CLIENTE..........................91

FIGURA 34 - DIAGRAMA DE CLASSES DO PACOTE ENTIDADE DO MÓDULO CLIENTE....................92

FIGURA 35 - DIAGRAMA DE CLASSES DO PACOTE BEAN DO MÓDULO CLIENTE...........................92

FIGURA 36 - DIAGRAMA DE CLASSES DA BIBLIOTECA MOBILELIB .............................................92

FIGURA 37 - DIAGRAMA DE SEQÜÊNCIA PARA EFETUAR LOGIN DO MÓDULO CLIENTE ...............93

FIGURA 38 - DIAGRAMA DE SEQÜÊNCIA DA LISTAGEM E SELEÇÃO DE ARQUIVOS DO MÓDULO

CLIENTE .............................................................................................................................93

FIGURA 39 - DIAGRAMA DE SEQÜÊNCIA ENVIO DA MENSAGEM DE CORREIO ELETRÔNICO DO

MÓDULO CLIENTE ..............................................................................................................94

LISTA DE TABELAS

TABELA 1 - PARTICIPAÇÃO DO MERCADO NO SERVIÇO MÓVEL PESSOAL NO BRASIL..................23

TABELA 2 - SISTEMAS CELULARES ANALÓGICOS .......................................................................30

TABELA 3 - ALOCAÇÃO DE FREQÜÊNCIA DO GSM.....................................................................33

TABELA 4 - COMPARAÇÃO ENTRE PDC, D-AMPS E GSM........................................................35

TABELA 5 - TIPOS DE SERVIÇOS DISPONÍVEIS NO IMT-2000......................................................44

TABELA 6 - COMPARAÇÃO DE SISTEMAS CDMA.......................................................................47

TABELA 7 - AS NOVE MODULAÇÕES E ESQUEMAS DE CODIFICAÇÃO DO EDGE..........................49

TABELA 8 - TIPOS E SUBTIPOS MIME DEFINIDOS NA RFC 2045 ................................................68

TABELA 9 - FORMATO DA REQUISIÇÃO E RESPOSTA PARA A AÇÃO EFETUAR LOGIN ...................75

TABELA 10 - FORMATO DA REQUISIÇÃO E RESPOSTA PARA A AÇÃO NAVEGAR E LISTAR

DIRETÓRIOS / ARQUIVOS ....................................................................................................75

TABELA 11 - FORMATO DA REQUISIÇÃO E RESPOSTA PARA A AÇÃO ENVIAR MENSAGEM DE

CORREIO ELETRÔNICO........................................................................................................76

TABELA 12 - REQUISITOS FUNCIONAIS ......................................................................................81

TABELA 13 - REQUISITOS NÃO FUNCIONAIS...............................................................................82

TABELA 14 - DETALHAMENTO DO CASO DE USO USC 001.........................................................82

TABELA 15 - DETALHAMENTO DO CASO DE USO USC 0002.......................................................83

TABELA 16 - DETALHAMENTO DO CASO DE USO USC 003.........................................................84

TABELA 17- DETALHAMENTO DO CASO DE USO EFETUA LOGIN .................................................88

TABELA 18 - DETALHAMENTO DO CASO DE USO NAVEGA NO DIRETÓRIO E SELECIONA ARQUIVOS

..........................................................................................................................................89

TABELA 19 - DETALHAMENTO DO CASO DE USO ENVIA MENSAGEM ..........................................89

LISTA DE ABREVIAÇÕES

1G – Primeira geração 2G – Segunda geração 3G – Terceira geração 8-PSK – 8 Phase Shift Keying (Chaveamento por deslocamento de 8 fases) ASCII – American Standard Caracters II (Padrão Americano de caracteres versão II) AMPS - Advanced Mobile Phone System (Sistema de telefonia móvel avançado) API – Application Programmer Interface (Interface programadora de aplicação) AuC - Authentication Center (Centro de autenticação) BDS – BREW Distribuition System (Sistema de distribuição BREW) BSC – Base Station Controller (Controlador de estação base) BTS – Base Transceiver Station (Estação transceptora base) CCITT - Comité Consultatif International Télégraphique et Téléphonique CLI - Caller Line Identification (Identificador de chamadas) CDC - Connected Device Configuration (Configuração de dispositivo conectado) CDMA - Code Division Multiple Access (Acesso múltiplo por divisão de código) CLDC - Connected Limited Device Configuration (Configuração de dispositivo conectado limitado) C-HTML – Compact HTML (HTML compacto) D-AMPS – Digital Advanced Mobile Phone System (Sistema de telefonia móvel avançado digital) DCN - Digital Communications Network (Rede de comunicações digitais) DNS - Domain Name System (Systema de nome de domínio) DQPSK - Differential Quadrature Phase Shift Keying (Chaveamento de deslocamento de fase por diferencial de quadratura) EDGE - Enhanced Data Rates for GSM Evolution (Evolução GSM para taxas de dados aumentadas) EIR - Equipament Identity Register (Registro de identidade do equipamento) EM – Estação Móvel ESN - Electronic Serial Number (Número serial eletônico) ETSI - European Telecommunications Standards Institute (Instituto europeu de padrões em telecomunicações) FCC - Federal Communications Commission (Comissão federal de comunicações) FDM – Frequency Division Modulation (Modulação por divisão de freqüência) FDMA – Frequency Division Multiple Access (Acesso múltiplo por divisão de freqüência) FEC - Forward Error Correction (Correção antecipada de erro) FPLMTS - Future Public Land Mobile Telecommunications System (Sistema futuro público de telecomunicações móvel nacional) GMSK - Gaussian Minimum Shift Keying (Chaveamento de deslocamento Gaussiano mínimo) GPRS - General Packet Radio Service (Serviço geral de rádio por pacote) GPS - Global Positioning System (Sistema de posicionamento global) GSM - Global System for Mobile Communications (Sistema global de comunicações móveis) HDML - Handheld Device Markup Language (Linguagem de marcação de dispositivos de mão) HDR - High Data Rate (Alta taxa de dados) HLR – Home Location Register (Registro de localização de origem)

HSCSD - High Speed Circuit Switched Data (Circuito comutado de alta velocidade de dados) HTTP – Hypertext Transfer Protocol (Protocolo de transferência de hipertexto) IDE - Integrated Development Environment (Ambiente de desenvolvimento integrado) IMAP - Internet Message Access Protocol (Protocolo de acesso às mensagens de Internet) IMT - Internacional Mobile Telecommunications (Telecomunicações móveis Internacionais) ISDN - Integrated Services Digital Network (Rede digital de services integrados) ITU - Internacional Telecommunications Union (União internacional de telecomunicações) J2ME – Java 2 Micro Edition (Java 2 edição micro) J2SE – Java 2 Standard Edition (Java 2 edição padrão) JDC - Japanese Digital Cellular (Celular digital japonês) JSP – Java Server Page (Servidor de páginas Java) JVM – Java Virtual Machine (Máquina virtual Java) J-TACS – Japonese Total Access Communication System (Sistema de comunicação de acesso total japonês) KVM - K Virtual Machine (Máquina virtual K) MCS - Modulation and Coding Schemes (Esquemas de codificação e modulação) MIDP - Mobile Information Device Profile (Perfil de dispositivo móvel de informação) MIME - Multipurpose Internet Mail Extensions (Extensão Multipropósito de correio Internet) MIN - Mobile Identity Number (Número de identidade móvel) MSC – Mobile Switching Center (Centro de comutação móvel) MVC – Model-View-Controller (Modelo-Visão-Controle) NMT - Nordic Mobile Telephony (Telefonia móvel nórdica) OQPSK - Offset Quadrature Phase Shift Keying (Chaveamento de deslocamento de fase por compensação de quadratura) OSI - Open System Interconnection (Sistema aberto de interconexão) PDB – Palm DataBase file (Arquivo de base de dados para palm) PCS - Personal Communications Services (Serviços de comunicações pessoal) PCM - Pulse Code Modulation (Modulação por código de pulso) PDA – Personal Digital Assistant (Assistente digital pessoal) PDC - Personal Digital Cellular (Celular digital pessoal) PMR - Private Mobile Radio (Rádio móvel privado) POP3 - Post Office Protocol Version 3 (Protocolo de postagem de escritório versão 3) QPSK - Quadrature Phase Shift Keying (Chaveamento de deslocamento de quadratura de fase) RFC – Request For Comments (Requisição para comentário) SDK – Source Development Kit (Kit fonte para desenvolvimento) SMTP - Simple Mail Transfer Protocol (Protocolo de transferência de correio simples) TACS – Total Access Communication System (Sistema de Comunicação de acesso total) TCP/IP – Transport Control Protocol / Internet Protocol (Protocolo de controle de transporte / protocolo Internet) TDMA - Time Division Multiple Access (Acesso múltiplo por divisão de tempo) TIA - Telecommunications Industry Associations (Associação das indústrias de telecomunicações) UML – Unified Modeling Language (Linguagem de modelagem unificada) UMTS - Universal Mobile Telecommunications System (Sistema universal de telecomunicações móvel) USB – Universal Serial Bus (Barramento serial universal) UWCC - Universal Wireless Communications Consortium (Consórcio universal de comunicações sem fio) VLR – Visitor Location Register (Registro de localização visitante)

VM – Virtual Machine (Máquina virtual) VPN – Virtual Private Network (Rede virtual privada) WAP - Wireless Application Protocol (Protocolo de aplicação sem fio) WAE – Wireless Application Environment (Ambiente de aplicação sem fio) WBMP – Wireless Bitmap (Imagem bitmap sem fio) WDP - Wireless Datagram Protocol (Protocolo de datagrama sem fio) WML – Wireless Markup Language (Linguagem de marcação sem fio) WSP – Wireless Session Protocol (Protocolo de sessão sem fio) WTA – Wireless Telephony Application (Aplicação telefônica sem fio) WTLS - Wireless Transport Layer Security (Camada de transporte seguro sem fio) WTP – Wireless Transaction Protocol (Protocolo de transação sem fio) W-CMDA - Wideband CDMA (CDMA banda larga) XML – eXtensible Markup Language (Linguagem de marcação extensível)

17

1 INTRODUÇÃO

1.1 APRESENTAÇÃO

Com a evolução tecnológica das redes e também dos dispositivos móveis, a mobilidade é uma

forte tendência. Em conseqüência disso, surgem também novas oportunidades de serviços a

serem oferecidos pelas operadoras de serviço móvel e também para empresas que venham a

desenvolver aplicações que proporcionem aos usuários do serviço móvel pessoal, acesso às

informações que os mesmos necessitem independente de sua localização física. Com base nas

afirmações de Dornan (2001) e de Kalakota e Robinson (2002) apresentadas a seguir, torna-se

ainda mais evidente a tendência da mobilidade e do surgimento de novos negócios suportados

pelas redes sem fio.

Os evangelizadores da Internet falam de uma era da informação que promete nos

libertar da tirania do mundo físico. Perdendo nossa dependência de objetos

corpóreos e de viagens físicas. Utilizaremos a rede wireless para acessar dados onde

e quando for necessário. (DORNAN, 2001, p 217).

Uma revolução silenciosa está afetando inúmeros setores industriais na economia

mundial. O surgimento da Internet móvel, capaz de interligar numerosos aparelhos e

múltiplas redes de informações, representa uma megatendência global. Ela

representa uma nova fase na capacitação do trabalhador com conhecimento. Como

conseqüência, nos encontramos sob um novo ciclo criativo, suportado pelo

casamento da Internet com a tecnologia sem fio e o comércio eletrônico.

(KALAKOTA; ROBINSON, 2002, p 16).

Uma das tentativas iniciais de se oferecer serviços de dados na rede móvel foi feita através da

tecnologia WAP. Porém novas tecnologias estão surgindo com a finalidade de disponibilizar

aplicações para dispositivos móveis, visando explorar a mobilidade oferecida por esses

dispositivos. Tecnologias como J2ME, BREW e .NET oferecem recursos de programação

capazes de tornar um celular uma ferramenta de trabalho muito útil para as pessoas que

precisam obter dados, seja qual for o lugar onde elas estejam. A funcionalidade de transmitir

18

voz será apenas mais uma das funções desses aparelhos e não mais a função principal. “[...] os

telefones estão começando a incorporar mais características de computação, permitindo não

apenas substituir os laptops e PDAs, mas também aparelhos de som e televisão.” (DORNAN,

2001, p.217).

A necessidade de ferramentas corporativas e pessoais que permitam aos usuários da rede

celular o acesso a dados, independente da localização física desses usuários desde que estejam

em uma área coberta pela rede, pode ser uma nova oportunidade para os desenvolvedores de

software bem como para as operadoras, que podem faturar na distribuição dos softwares e

também no tráfego gerado por eles. Um exemplo prático de uma dessas ferramentas é uma

aplicação que permita aos usuários, em deslocamento ou sem um ponto de acesso a sua rede,

o envio de mensagens com a possibilidade de anexar arquivos e enviá-las por meio do serviço

de correio eletrônico, utilizando o seu celular para acessar seu servidor de arquivos, selecionar

o arquivo desejado, escolher o destinatário e disparar o envio do e-mail.

1.2 JUSTIFICATIVA

Com a grande competitividade presente nos diversos segmentos do mercado, estar bem

informado é um diferencial perante os concorrentes. Ter acesso às informações, independente

de onde se esteja, torna-se uma grande arma para sobreviver em um mercado tão competitivo.

Ter disponíveis em dispositivos móveis, recursos que permitam ter acesso a essas

informações, é a nova tendência do mercado, no que diz respeito aos serviços a serem

oferecidos pelas operadoras de telefonia móvel. A evolução dos dispositivos móveis também

tornará possível oferecer serviços ainda mais sofisticados, aliados a sua mobilidade.

Por tratar-se ainda de uma tendência, existe um grande nicho de mercado a ser explorado

pelos desenvolvedores de software, e aqueles que criarem serviços diferenciados poderão

levar muita vantagem. O uso de uma tecnologia como o J2ME torna o desenvolvimento de

aplicações para dispositivos móveis uma tarefa fácil para aqueles que já estão acostumados

com as outras edições do Java. Entretanto, a edição Micro Edition do Java apresenta

limitações quanto á suas APIs, pois é voltada para dispositivos com poucos recursos de

memória e processamento, e os recursos disponíveis nas APIs do J2ME devem ser observados

antes da elaboração de uma proposta de ferramenta a ser desenvolvida utilizando essa

tecnologia. Por ser uma linguagem orientada a objeto, a customização das aplicações aos

19

diversos tipos e modelos de dispositivos existentes no mercado é relativamente simples,

bastando fazer uso das classes que mais se adequarem ao equipamento em questão.

Atualmente os serviços de envio de e-mail por meio de telefones celulares oferecidos pelas

operadoras, não permitem anexar arquivos às mensagens enviadas. Por se tratar de algo

inovador, este trabalho se propõe a implementar o envio de mensagens de correio eletrônico,

incorporando a funcionalidade de anexar arquivos localizados em um servidor remoto, às

mensagens enviadas e assim fornecer às operadoras e seus usuários novos serviços aliados à

mobilidade oferecida pelas redes e pelos dispositivos móveis.

1.3 OBJETIVOS

1.3.1 Objetivo geral

Utilização da tecnologia J2ME para acesso ao serviço de correio eletrônico.

1.3.2 Objetivos específicos

• Explorar a mobilidade oferecida pelos celulares, fazendo uso dos recursos disponíveis

nesses dispositivos e na tecnologia J2ME.

• Buscar os conhecimentos necessários para fazer uso da maneira mais eficiente, dos

recursos do J2ME.

• Desenvolver uma aplicação Java ou Servlet/Java Server Pages para atender aos pedidos de

listagem de diretório, anexar arquivo e envio de e-mail.

• Desenvolver uma aplicação em J2ME para acessar um servidor e solicitar a listagem do

conteúdo de um diretório, selecionar um ou mais arquivos listados e encaminhá-los

através do serviço de correio eletrônico a um ou mais destinatários.

1.3.3 Escopo e delimitação

Este trabalho se propõe a desenvolver uma aplicação para celulares, que possibilite a conexão

com um servidor remoto, listar um diretório deste servidor, selecionar um ou mais arquivos e

enviá-los como anexos em uma mensagem de correio eletrônico utilizando a tecnologia

J2ME.

Este trabalho não se propõe a atingir outros dispositivos móveis além dos telefones celulares,

nem oferecer outros tipos de serviços de rede como FTP, TELNET, etc.

20

1.4 RESULTADOS ESPERADOS

Ao final deste trabalho espera-se ter um protótipo da aplicação proposta com suas

funcionalidades testadas e realizando envio de e-mails por meio de telefones celulares com

arquivos anexados, e desta forma comprovar a viabilidade do desenvolvimento de aplicações

para celulares que permitam oferecer serviços diferenciados aos seus usuários, fazendo uso da

rede de dados da telefonia móvel.

1.5 ASPECTOS METODOLÓGICOS

Este trabalho trata-se de uma pesquisa bibliográfica com abordagem qualitativa, onde será

desenvolvida uma aplicação que rode em telefones celulares com suporte a Java, e uma outra

aplicação que rodará em um servidor remoto. Primeiramente será realizada uma revisão

bibliográfica para obter as informações necessárias para a implementação da aplicação J2ME,

buscando a melhor forma de utilização dos recursos de interface com o usuário, bem como os

de conectividade.

Será usada a linguagem UML para modelagem das aplicações e como resultado desta, serão

gerados diagramas de classe, de casos de uso, robustez e seqüência. A ferramenta VISUAL

PARADIGM FOR UML 4.1 será utilizada para a confecção dos diagramas. Uma vez

modeladas as aplicações, elas serão implementadas utilizando-se a ferramenta NETBEANS

4.1.

1.6 ESTRUTURA DO TRABALHO

Para facilitar o entendimento deste trabalho, faz-se necessário uma apresentação e

compreensão do conceito de uma rede celular, suas gerações e diferentes tecnologias,

tecnologias de desenvolvimento de aplicações para dispositivos móveis, e serviço de correio

eletrônico.

Neste contexto, este trabalho está organizado em quatro capítulos:

• Capítulo 2: Redes e tecnologias móveis:

Apresenta uma visão geral sobre redes móveis, aprofundando-se um pouco mais em redes

celulares, informações sobre o mercado brasileiro nesse aspecto, topologia básica, gerações,

21

suas respectivas características, tecnologias e plataformas de desenvolvimento para

dispositivos móveis.

• Capítulo 3: Correio eletrônico:

Contém uma visão geral sobre o serviço de correio eletrônico, as RFCs (Request For

Comments) que possibilitaram a existência e evolução desse serviço, protocolo de envio e

recebimento de mensagens de correio eletrônico.

• Capítulo 4: Protótipo do sistema:

Apresenta o protótipo de um serviço de correio eletrônico acessado por celular e que além de

enviar mensagens de texto, pode anexar à essas mensagens arquivos localizados em um

servidor de arquivos. Como resultado dessa implementação temos duas aplicações: uma

servidora executada em algum servidor da rede fixa, e uma cliente executada num dispositivo

móvel.

• Capítulo 5: Conclusão:

Discute os resultados obtidos, dificuldades encontradas e sugestões para trabalhos futuros.

22

2 REDES E TECNOLOGIAS MÓVEIS

2.1 REDES MÓVEIS

“O sistema telefônico tradicional (ainda que ele algum dia chegue a vários gigabits entre uma

extremidade e outra da fibra) não será capaz de satisfazer a um grupo crescente de usuários:

as pessoas em trânsito.” (TANENBAUM, 2003, p 161).

O surgimento das redes sem fio como celular e WI-FI estão permitindo cada vez mais a

utilização de recursos antes disponíveis apenas em residências, escritórios e empresas. Os

usuários das redes móveis de onde quer que estejam, podem desfrutar da mobilidade e ainda

assim fazer uso dos mesmos recursos que os usuários das redes fixas, bastando haver

cobertura dessas redes onde eles se encontram.

Devido à sua grande cobertura e ao grande número de usuários, a rede de telefonia celular tem

um grande potencial de exploração, seja para as operadoras como para empresas de

desenvolvimento de software, oferecendo novos serviços por meio de aplicações voltadas

para os dispositivos móveis.

Só no Brasil, segundo a Agência Nacional de Telecomunicações (ANATEL, 2005a), o

número de clientes do serviço móvel pessoal (SMP) em abril de 2005 era de 70.790.305.

Diante deste número, pode-se se ter uma idéia do potencial de exploração deste mercado que

está dividido entre as operadoras existentes no país, conforme mostrado na tabela 1.

23

Tabela 1 - Participação do mercado no serviço móvel pessoal no Brasil

PARTICIPAÇÃO DO MERCADO NO SERVIÇO MÓVEL PESSOAL - SMP

POSIÇÃO HOLDING % DO MERCADO - BRASIL

1° VIVO 38,82

2° TIM 21,46

3° CLARO 21,06

4° OI 10,56

5° TELEMIG / AMAZÔNIA 5,83

6° BRASIL TELECOM GSM 1,67

7° CTBC CELULAR 0,48

8° SERCOMTEL CELULAR 0,12

TOTAL 100

TOTAL DE CLIENTES ATÉ O MÊS DE ABRIL/2005 – 70.790.305

Fonte: Agência Nacional de Telecomunicações (2005b) – Adaptada por Rodrigo L. Duarte.

2.2 REDE CELULAR

A primeira rede celular foi criada nos Estados Unidos pela empresa AT&T e foi

regulamentada para todo país. Como resultado dessa regulamentação, um celular comprado na

Califórnia funcionava perfeitamente em Nova York. Já na Europa, cada país desenvolveu seu

próprio sistema resultando num grande fiasco, onde o deslocamento de um país ao outro

resultava no não funcionamento dos telefones. (TANENBAUM, 2003).

Com o surgimento da tecnologia digital a Europa resolveu aprender com os erros cometidos

na implantação da sua rede analógica e as operadoras de telefonia móvel uniram-se e criaram

um sistema único (GSM), que permite o funcionamento de um telefone móvel europeu em

qualquer lugar da Europa. (TANENBAUM, 2003).

Uma rede de telefonia celular possui basicamente os seguintes elementos: estação móvel

(EM) , torre de rádio ou BTS (Base Transceiver Station), estação base ou BSC (Base Station

Controller), centro de comutação móvel ou MSC (Mobile Switching Center), HLR (Home

Location Register), VLR (Visitor Location Register), EIR (Equipament Identity Register) e o

AuC (Authentication Center). Todos esses elementos são descritos a seguir:

As estações móveis (EM) são os telefones celulares ou PDA’s que fazem acesso à rede pelas

torres de rádio. Conhecidas também como BTS (Base Transceiver Station), uma torre de rádio

24

ou celular “é o local de transmissão da telefonia celular.” (SHARMA, 2001, p 17). São elas

que estabelecem a conexão entre as EM’s e a rede celular.

A estação base, também chamada de BSC (Base Station Controller) “controla um

conglomerado de torres celulares.“ (SHARMA, 2001, p 17). Ela é responsável por gerenciar

as chamadas de voz ou de dados de uma EM e controlar quando as EM’s realizam a troca de

uma torre de rádio para outra sem a interromper o serviço (processo de handoff). Já o centro

de comutação móvel também conhecido como MSC (Mobile Switching Center) “conecta

todas as estações base para passar os sinais de comunicações de e para os assinantes que estão

operando na rede.” (SHARMA, 2001, p 19).

O HLR (Home Location Register) armazena informações pertinentes ao assinante, como por

exemplo, a última vez que a EM se registrou na rede. As EM periodicamente, em intervalos

de poucos segundos, registram-se na rede para agilizar a sua localização pelas BSC’s diante

de uma chamada destinada a elas. (SHARMA, 2001, p 19).

O VLR (Visitor Location Register) “registra as informações sobre unidades móveis que foram

introduzidas na rede, vindo de outras redes, ou seja, ele registra os visitantes.” (SHARMA,

2001, p 19). O EIR (Equipament Identity Register) “armazena e verifica os status dos MIN’s e

ESN’s.” (SHARMA, 2001, p 19). O MIN (Mobile Identity Number) assim como o ESN

(Electronic Serial Number) “são usados para verificação, autenticação e faturamento.”

(SHARMA, 2001, p 19). O AuC (Authentication Center) “é responsável pela autenticação e

validação dos serviços para cada dispositivo móvel que está tentando usar a rede.”

(SHARMA, 2001, p 19).

A figura 1 ilustra a topologia básica de uma rede celular e como seus componentes estão

interligados.

A denominação rede celular se deve ao fato da utilização do conceito de células. Segundo

Dornan (2001, p 43), célula é a área de cobertura de uma única estação-base. Os telefones

celulares têm acesso aos serviços da rede celular através das células em que se encontram.

Para se cobrir geograficamente uma grande área é necessário disponibilizar um grande

número de torres de maneira a atingir a cobertura desejada. A figura 2 mostra a representação

real de uma célula (célula circular) e a representação ideal (célula hexagonal).

25

Figura 1 - Topologia básica da rede celular

Fonte: Sharma (2001, p 20) – Adaptada por Rodrigo L. Duarte.

Figura 2 - Representação circular e hexagonal de uma célula

Fonte: Dornan (2001, p 44) – Adaptada por Rodrigo L. Duarte.

As células ainda podem ser divididas criando-se as microcélulas. Microcélulas são “pequenas

células que realizam a cobertura de determinada rua ou até de um prédio específico como um

centro de conferências.” (DORNAN, 2001, p 44). “Em uma área em que o número de

usuários cresce a ponto de o sistema ficar sobrecarregado, a potência é reduzida, e as células

sobrecarregadas são divididas em células menores chamadas microcélulas para permitir maior

reutilização de freqüências [...]” (TANENBAUM, 2003, p 164).

Estação móvel

Estação Base

Centro de Comutação Móvel

Telefonia Fixa

HLRVLR

AUC

EIR

Torre de Rádio

Estação Base

Circular Hexagonal

26

As células utilizam um conjunto de freqüências e devido as suas características físicas, uma

célula sempre acaba se sobrepondo a outra, tornando inviável a reutilização destas freqüências

em células adjacentes. Como essas freqüências são em número limitado e visando evitar a

interferência entre os canais de mesma freqüência em células adjacentes, criou-se a técnica de

clusterização. As freqüências disponíveis são distribuídas para um determinado número de

células, formando um conjunto denominado de cluster. No cluster vizinho a distribuição das

freqüências se repete, conforme mostrado na figura 3.

Figura 3 - Cluster de células de tamanho 7

Fonte: Tanenbaum (2003, p 165) – Adaptada por Rodrigo L. Duarte.

Com a utilização de clusters consegue-se um bom distanciamento entre células que utilizam

as mesmas freqüências, possibilitando uma boa reutilização de freqüências e uma boa

qualidade de comunicação. Existem vários padrões de tamanho de cluster, e esses tamanhos

irão depender da necessidade particular de cada rede e da existência de microcélulas.

Entretanto, os mais usados são os de tamanho 7 e 12, em função de fornecerem a melhor

relação distanciamento de células que utilizam as mesmas freqüências e a quantidade de

canais por células.

As redes móveis oferecem um recurso muito importante, que é permitir aos seus clientes o

deslocamento entre células. “O processo de comutação do usuário de uma célula para outra

enquanto a ligação está em andamento é chamado de handoff ou handover.” (DORNAN,

2001, p 45). São procedimentos complicados e que exigem da estação base cálculos precisos

para detectar quando o usuário está saindo de uma célula e entrando em outra. Este

procedimento leva em torno de 300 ms e pode ser feito de três modos conhecidos como soft

handoff, hard handoff e nenhum handoff.

27

No soft handoff “o sinal do telefone é adquirido pela nova estação base antes da anterior se

desconectar”. (TANENBAUM, 2003, p 165). O soft handoff também é chamado de ligar antes

de quebrar e é considerado um sistema muito confiável. (DORNAN, 2001, grifo do autor).

Com este tipo de handoff a queda de ligação durante o processo é pouco provável, exceto se a

troca de célula ocorrer em alta velocidade ou o usuário sair da área de cobertura da rede

celular.

Em um hard handoff “a estação base antiga libera o sinal do telefone antes de ele ser

adquirido pela nova estação base”. (TANENBAUM, 2003, p 166). Não havendo canais

disponíveis na nova célula, a ligação será interrompida de forma abrupta. Em redes que

utilizam esse tipo de handoff a conversação poderá sofrer interrupções, mesmo nas

tecnologias digitais mais avançadas.

Já no modo nenhum handoff o processo “é muito simples e sempre depende de o terminal

móvel realmente fazer uma nova ligação após sair da faixa de um transmissor.” (DORNAN,

2001, p 46). Este modo não é muito comum em redes celulares, mas é utilizado em alguns

sistemas empregados no mercado de redes PMR (Private Mobile Radio) e apresenta como

única vantagem, menor tempo de conexão para as chamadas novas e para as em andamento.

A figura 4 ilustra a ocorrência de um handoff onde a torre B assume o gerenciamento da

chamada do usuário anteriormente controlado pela torre A.

Figura 4 – Handoff entre as torres A e B

2.3 GERAÇÕES DA REDE CELULAR

Por se tratarem de sistemas de transmissão via rádio, as redes celulares necessitam fazer uso

de técnicas de divisão de freqüência, fracionando seu espectro disponível em bandas menores,

e podendo um ou mais usuários usufruir dessas frações de banda. (DORNAN, 2001). Com a

evolução tecnológica, novas técnicas de divisão de freqüência foram criadas e a possibilidade

Torre B

Torre A

28

de oferta de novos serviços na rede celular proporcionou o surgimento de novas gerações de

redes celulares.

Segundo Tanenbaum (2003) as redes celulares passaram por três gerações distintas e com

diferentes tecnologias:

• Primeira geração caracterizada pela transmissão analógica da voz.

• Segunda geração com transmissão de voz digital.

• Terceira geração com voz digital e transmissão de dados.

2.3.1 Primeira geração

Inventado pelo Bell Labs e instalado primeiramente nos Estados Unidos em 1982, o AMPS

(Advanced Mobile Phone System) é a tecnologia que representa as redes celulares de primeira

geração (1G). Foi utilizado posteriormente na Inglaterra e no Japão onde receberam os nomes

TACS e MCS-L1, respectivamente. (TANENBAUM, 2003).

Utilizando transmissão analógica, o AMPS utiliza 832 canais full-duplex, cada um consistindo

em um par de canais simplex. Existem 832 canais de transmissão simplex de 824 a 849 MHz,

e 832 canais de recepção simplex de 869 a 894 MHz. Cada um desses canais simplex tem 30

KHz de largura. Desse modo, o AMPS utiliza FDM para separar os canais. (TANENBAUM,

2003, p 166).

O FDMA (Frequency Division Multiple Access) é técnica de multiplexação empregada nas

redes AMPS, permitindo que cada canal de comunicação tenha sua própria freqüência

específica. (DORNAN, 2001).

Dos 832 canais disponíveis no espectro, 42 são utilizados para controle de informações. Os

790 canais restantes normalmente são divididos entre duas operadoras celulares concorrentes,

resultando em 395 canais para cada operadora e conseqüentemente um limite de 395 ligações

simultâneas. (DORNAN, 2001). Todavia, a grande vantagem das redes celulares é que as

freqüências podem ser reutilizadas por meio da criação de novas células, dessa forma temos o

limite de 395 ligações em uma célula isolada e não na rede inteira. (DORNAN, 2001). Em

virtude da interferência, uma célula não pode transmitir e receber em todos os 395 canais.

Para tornar mais eficaz a reutilização de freqüência, utiliza-se a técnica de clusterização de

células. A figura 5 mostra o número de canais por célula para alguns padrões de cluster.

29

Figura 5 - Quantidade de canais por célula em uma rede AMPS com 395 canais

Fonte: Dornan (2001, p 50).

Por se tratar de um sistema FDMA puro, o AMPS apresenta um problema de interferência

causado por freqüências próximas. Essas interferências são evitadas distanciando-se um canal

de seus adjacentes por um intervalo de freqüência, causando um grande desperdício de

espectro. O espectro alocado para cada canal é maior do que realmente é preciso, causando

perdas de freqüências que poderiam ser utilizadas para alocação de canais e reduzindo a

eficiência do sistema. A figura 6 ilustra a utilização do espectro em sistemas que fazem uso do

FDMA e o distanciamento entre os canais.

Figura 6 - Utilização do espectro no FDMA


A tabela 2 mostra alguns sistemas celulares analógicos e algumas de suas características,

como por exemplo, as freqüências para os links diretos e reversos, o espectro ocupado por

canal, o tamanho do canal, a taxa de transmissão de dados e os países ou regiões que utilizam

cada uma das tecnologias.

838,04 838,06 838,08 838,1 838,12 838,14 Freqüência (MHz)

Alcance

CH34 CH35 CH36 CH37

Intervalo de freqüência entre canais

020406080

100120140

Tamanho do cluster 3 4 7 12 21

30

Tabela 2 - Sistemas celulares analógicos

Sistema Freqüências

(MHz)

Espectro

por

canal

Tamanho

do canal

Capacidade

máxima de

dados

Utilizado em

Link

direto

Link

reverso

AMPS (Advanced Mobile

Phone System) 869-894 824-849 24 KHz 30 KHz 9,6 Kbps Américas

C-Netz 461-466 451-456 8 KHz 20 KHz 5,3 Kbps Europa central

J-TACS (TACS japonês) 925-940 870-885 10 KHz 25 KHz 0,3 Kbps Somente Japão

NMT (Nordic Mobile

Telephony)

463-

467,5

935-960

453-

457,5

890-915

9,4 KHz 25 KHz 1,2 Kbps Escandinávia, Europa

Oriental, Ásia

TACS (Total Access

Communications System)

935-950

917-933

890-905

872-888 19 KHz 25 KHz 8,0 Kbps

Europa ocidental,

Ásia


2.3.2 Segunda geração

A segunda geração (2G) de redes celulares é caracterizada pelo fato da transmissão de voz ser

realizada de forma digital. Assim como o sistema analógico, os sistemas digitais da segunda

geração não sofreram uma padronização mundial resultando em quatro sistemas: D-AMPS,

GSM, CDMA e PDC. A segunda geração é conhecida também como PCS (Personal

Communications Services). “Este termo foi utilizado foi utilizado originalmente pela FCC

(Federal Communications Commission) para descrever um grupo especial de licenças para a

banda de 1900 MHz, mas tem sido adotado pelo pessoal de marketing para incluir qualquer

sistema digital que forneça voz de alta qualidade e dados de banda estreita.” (DORNAN,

2001, p 63).

2.3.2.1 D-AMPS

O D-AMPS (Digital Advanced Mobile Phone System) é a segunda geração do sistema AMPS

e foi projetado para permitir a compatibilidade entre os dois sistemas, de modo a operar com

telefones de primeira e segunda geração possam operar simultaneamente em uma mesma

célula. “Ele é descrito pelo padrão internacional IS-54 em seu sucessor o IS-136.”

(TANENBAUM, 2003, p 168).

31

O D-AMPS faz uso dos mesmos canais de 30 KHz utilizados no AMPS e nas mesmas

freqüências, podendo um canal ser analógico e seus adjacentes serem digitais. A quantidade

de canais digitais e analógicos em uma célula é definida pela concentração de telefones

analógicos ou digitais nessa célula. A MSC então, define dinamicamente quais canais serão

analógicos e quais serão digitais, e conforme essa mistura de telefones analógicos e digitais se

altera na célula, a MSC redefine a quantidade de canais analógicos e digitais.

(TANENBAUM, 2003).

Prevendo um aumento de carga com o lançamento do D-AMPS, foi disponibilizada uma nova

banda de freqüências onde os canais de link direto1 estão na faixa de 1.930 a 1.990 MHz e os

canais de link reverso2 correspondente estão na faixa de 1.850 a 1.990 MHz. A fim de se obter

uma faixa mais ampla de canais o D-AMPS utiliza além dessa nova banda de freqüências, a

banda utilizada pelo AMPS conforme descrito na tabela 2.

Segundo Dornan (2001) a diferença entre o AMPS e o D-AMPS é que, em vez utilizar um

canal de 30 KHz para transmitir uma única conversação, o D-AMPS divide cada canal em três

slots TDMA (Time Division Multiple Access), permitindo que cada canal seja utilizado por

três conversações simultaneamente.

A voz é digitalizada já no telefone móvel e compactada com o uso de um modelo sofisticado.

A compactação leva em consideração detalhes do sistema vocal humano e reduz os 56 Kbps,

resultantes da codificação PCM (Pulse Code Modulation), para 8 Kbps ou menos, buscando

reduzir o número de bits a serem transmitidos pelo enlace aéreo. (TANENBAUM, 2003).

A técnica de modulação utilizada é chamada de DQPSK (Differential Quadrature Phase Shift

Keying) e para Dornan (2001), o D-AMPS é mais eficiente que o AMPS e também que o

GSM quanto à utilização do espectro.

1 Canal de transmissão no sentido rádio base para estação móvel. Também conhecido como downlink ou canal

de downstream.

2 Canal de transmissão no sentido estação móvel para rádio base. É conhecido também com uplink ou canal de

upstream.

32

O D-AMPS apresenta uma velocidade de dados de 48,6 Kbps, sendo compartilhada por três

usuários. Cada usuário utiliza o canal por um terço do tempo, resultando em um terço da

velocidade para cada usuário.

Cada time slot no D-AMPS dura 6,67 ms, e contêm informações de sinalização e controle,

serviços avançados como identificação de chamadas, mensagens de texto, além dos dados de

voz. A figura 7 ilustra a estrutura de um multiframe, frame e slot para o D-AMPS padrão IS-

136.

Figura 7 - Slot D-AMPS (IS-136), estrutura de frame e multiframe


2.3.2.2 GSM

Inicialmente conhecido como Groupe Spéciale Mobile, nome do comitê formado para

padronizá-lo, o GSM atualmente é conhecido por Global System for Mobile Communications

e é o sistema celular mais utilizado no mundo. Segundo Dornan (2001) em 1999, essa

tecnologia já utilizada por mais da metade de todos os telefones móveis, expandia-se com 1

milhão de novos usuários por semana. Por possuir uma ótima qualidade de voz, facilidade de

atualização para velocidades de dados superiores e principalmente pela padronização

realizada pelos governos europeus, este sistema tornou-se muito popular.

O GSM foi projetado originalmente para trabalhar em freqüências em torno de 900 MHz,

visando reaproveitar o espetro utilizado pelas redes analógicas européias TACS. O sistema

sofreu adaptações e hoje opera em quatro bandas de freqüências diferentes como mostra a

tabela 3. “Essas variantes de freqüência mais alta às vezes são chamadas de DCN (Digital

Frame: 972 bits ou 20 ms Slot: 324 bits ou 6,67 ms

Cabeçalho

do protocolo

Sinalização

Voz ou dados

122 bits de tráfego 16 bits de tráfego

A B C D E F G H I J K L M N O P

Multiframe D-AMPS padrão IS-136

1 2 3 1 2 3

12 bits finais 28 bits de treinamento

122 bits de tráfego

24 bits de controle

33

Communications Network), mas na verdade são apenas GSM. A variante mais recente usa

freqüências mais baixas de 450 MHz, para poder substituir redes analógicas anteriores,

baseadas no sistema escandinavo NMT (Nordic Mobile Telephony).” (DORNAN, 2001, p 66).

Tabela 3 - Alocação de freqüência do GSM

Tipo de GSM Freqüência de link

reverso Freqüência de link direto Tamanho da célula

GSM 450 450,4 – 457,6 MHz ou

478-486 MHz

460,4-467,6 MHz ou

488,8-496 MHz Maior possível

GSM 900 880-915 MHz 925-960 MHz Grande

DCN 1800 1710-1785 MHz 1805-1880 MHz Pequeno

PCS 1900 1850-1910 MHz 1930-1990 MHz Menor possível


Assim como o D-AMPS, o GSM utiliza tanto FDMA quanto o TDMA. A diferença está

basicamente na quantidade de time slots utilizada pelo GSM que passa a ser 8 contra 3 do D-

AMPS. Os canais GSM também possuem uma largura de banda de 200 KHz contra 30 KHz

do D-AMPS. A técnica de modulação utilizada no GSM é conhecida como GMSK (Gaussian

Minimum Shift Keying) “[...] uma forma de modulação de fase, um sistema que usa diferentes

partes da forma de onda para representar informações.” (DORNAN, 2001, p 67). Essa forma

de modulação permite velocidade de 270,8 Kbps para cada canal de 200 KHz. Entretanto,

essa velocidade é dividida por oito motivada pelo uso do TDMA, ou seja, compartilhamento

de canal por divisão de tempo, atingindo velocidades de até 33,9 Kbps.

Visando compensar o retardo da propagação do sinal da estação rádio base até o telefone

móvel, o GSM inutiliza uma parte da banda de cada canal, o que segundo Dornan (2001) está

na ordem de uns 27 por cento, uma vez que o tempo que um sinal de rádio gasta para

percorrer um quilômetro é de 3,3 microssegundos, o que resulta em um atraso de

aproximadamente 100 microssegundos em um telefone a 30 Km da estação rádio base. Cada

time slot tem a duração de 577 microssegundos e transmite exatos 156,25 bits como mostrado

na figura 8.

Um frame é um conjunto de oito time slots e para cada 24 frames Dornan (2001) diz que 22

deles são usados para tráfego de voz ou dados, enquanto um é utilizado para sinalização e

outro é reservado para outros tipos de tráfego, como por exemplo, mensagens de texto ou CLI

(Caller Line Identification) ou identificador de chamadas. Isso torna necessária a existência de

34

mais uma estrutura conhecida como multiframe, ou seja, um conjunto de 26 frames. A figura

8 ilustra a estrutura de um multiframe, um frame e um time slot GSM.

Figura 8 - Slot GSM, estrutura de frame e multiframe


Para a estrutura de slot apresentada na figura 8, Dornan (2001) diz que os cabeçalhos são

espaços vazios acrescentados no início e no fim de cada slot com a finalidade de separá-lo de

seus vizinhos e também evitar o tempo de retardo da propagação a uma distância de até 35

Km da estação rádio base. Dornan (2001) conceitua a seqüência de treinamento ou bits de

treinamento como sendo um padrão fixo de bits no meio dos slots, utilizados para auxiliar

receptores bloqueados no slot, não transmitindo informação útil e servindo de cabeçalho ou

rodapé quando o slot é submetido a novas divisões, por exemplo, quando é utilizado um codec

de meia velocidade.

Para Dornan (2001) os bits roubados são usados com o objetivo de identificar se o slot está

sendo utilizado para conduzir dados ou para controlar informações. Daí vem o nome

“roubado”, pois o slot está sendo roubado para enviar informações de sinalização ao invés de

conduzir voz ou dados. Já os bits de tráfego são destinados para transporte de dados, voz,

além de informações de controle e correção de erros.

Sinalização

Voz ou dados

Cabeçalho do

protocolo

11,25 bits finais26 bits de treinamento

57 bits de tráfego57 bits de tráfego

3 bits iniciais

Slot: 156,25 bits ou 0,577 ms

Frame: 1250 bits ou 4,6 ms

Multiframe: 32.500 bits ou 120 msA B C D E F G H I J K L M N O P Q R S T U V W X Y Z

1 2 3 4 5 6 7 8

2 bits roubados

35

2.3.2.3 PDC

Baseado no sistema D-AMPS, o PDC (Personal Digital Cellular) ou JDC (Japanese Digital

Cellular) foi desenvolvido pelo Japão visando a compatibilidade retroativa com seu sistema

de telefonia celular analógico J-TACS. “Apesar de ser utilizado em apenas um país, é o

segundo padrão móvel mais popular do mundo (o primeiro é o GSM), em parte por causa do

i-mode de serviço de Internet sem fio.” (DORNAN, 2001, p 79).

Pelo fato do J-TACS utilizar canais de 25 KHz, o D-AMPS sofreu alterações em virtude de

ter sido projetado para trabalhar com canais de 30 KHz. Todavia, foram utilizados os mesmo

tamanhos de time slots e a mesma forma de modulação, ocasionado velocidade de dados

inferiores ao D-AMPS. Mas se forem feitas algumas simplificações no cabeçalho e nas

informações de correção de erros, consegue-se obter os mesmos 9,6 Kbps do D-AMPS,

pagando-se o preço de fazer uso de um sistema menos confiável.

Para Dornan (2001) o sucesso do PDC é motivado pelo i-mode, um sistema de Internet móvel

desenvolvido pela NTT DoCoMo, a maior operadora japonesa, onde são utilizadas conexões

comuns de 9,6 Kbps ou até mais lentas e provê acesso a milhares de sites da web, adaptados

especialmente para serem exibidos nas pequenas telas dos telefones celulares. A tabela 4 faz

um comparativo entre o PDC, D-AMPS e GSM.

Tabela 4 - Comparação entre PDC, D-AMPS e GSM

Sistema Canal Slots Tamanho

do slot Bits/Slot Modulação

Taxa

bruta de

bits

Capacidade

de dados

GSM 200 KHz 8 0,577 ms 156,25 GMSK 33,9 Kbps 14,4 Kbps

D-AMPS 30 KHz 3 6,67 ms 324 DQPSK 16,2 Kbps 9,6 Kbps

PDC 25 KHz 3 6,67 ms 290 DQPSK 14 Kbps 9,6 Kbps


2.3.2.4 CDMA

Desenvolvido pela empresa Qualcomm, o CDMA (Code Division Multiple Access)

inicialmente não obteve uma boa aceitação. Tanenbaum (2003) diz que graças à persistência

da Qualcomm, o CDMA passou por um processo de amadurecimento e não só foi aceito

36

como se tornou a melhor solução técnica para os sistemas celulares de terceira geração.

Padronizado pela TIA (Telecommunications Industry Associations) e batizado como IS-95a e

também conhecido como cdmaOne, o CDMA é amplamente utilizado nos Estados Unidos.

No Brasil a VIVO, a maior operadora celular do país, também utiliza essa tecnologia.

“Os sistemas CDMA parecem superficialmente mais simples do que os baseados no TDMA.

Não envolvem slots nem estruturas de frames; cada telefone apenas transmite e recebe o

tempo todo, enviando muitas repetições das mesmas informações com o objetivo de assegurar

que pelo menos uma seja bem sucedida.” (DORNAN, 2001, p 81).

Segundo Tanenbaum (2003) o CDMA permite que cada estação transmita sobre todo o

espectro de freqüências e durante todo o tempo, diferente dos sistemas baseados em FDMA e

TDMA que dividiam o espectro em algumas centenas de canais estreitos. As varias

transmissões simultâneas são separadas com o uso da teoria de codificação. Uma outra

característica importante do CDMA relatada por Tanenbaum (2003) é a não preocupação com

a colisão de quadros, pois se pressupõe que os mesmo não são totalmente adulterados e sim

somados de modo linear.

A quantidade de repetições realizadas pelo CDMA é conhecida como ganho e para Dornan

(2001) ela depende da largura de banda e do comprimento do código utilizado. O cdmaOne

utiliza como código um conjunto de 64 números, cada qual com 64 bits. Esse conjunto de

números é conhecido como códigos Walsh e são calculados para um número cancelar o outro.

Para cada usuário é atribuído um código Walsh diferente, e antes dos dados serem

transmitidos, cada bit de dados é multiplicado por esse código resultando no envio de cada bit

dado 64 vezes.

No CDMA são utilizadas duas técnicas diferentes de modulação de fase, a QPSK

(Quadrature Phase Shift Keying) e a OQPSK (Offset Quadrature Phase Shift Keying). A

QPSK é utilizada no link direto e proporciona uma velocidade bruta por usuário de 19,2 Kbps,

porém o telefone recebe a 1228,8 Kbps, ou seja, 64 x 19,2. Já a OQPSK é utilizada no link

reverso e proporciona velocidade de 28,8 Kbps. O fato de a velocidade ser mais alta no link

reverso que no link direto, é motivado pelas correções de erro antecipadas que se tornam

necessárias pela incapacidade dos telefones em coordenarem suas transmissões da mesma

forma feita pelas estações rádio base.

37

Além das altas velocidades Dornan (2001) afirma que o CDMA apresenta uma outra grande

vantagem em relação aos sistemas que utilizam TDMA. O mesmo canal pode ser utilizado por

vários telefones diferentes e por todas as estações rádio base, e as freqüências utilizadas em

uma célula podem ser reutilizadas por suas células adjacentes, eliminando a necessidade de

utilização dos clusters de células existentes nos sistemas TDMA e FDMA.

De acordo com Dornan (2001) uma grande desvantagem dos sistemas CDMA é o alto

consumo de energia motivado pelas transmissões repetidas de dados, o que provocaria

também um aumento da exposição dos usuários às radiações microondas. Porém, realizando

um controle cuidadoso do poder transmissão, o cdmaOne solucionou os problemas de

consumo de bateria das estações móveis e a quantidade de radiação a qual são expostos seus

usuários. Esse controle do poder de transmissão requer que os telefones necessitem ficar

inativos o maior tempo possível, e sua potência de transmissão sendo aumentada à medida

que os telefones forem se afastando da estação rádio base.

Como todas as células utilizam todas as freqüências disponíveis no espectro, as estações rádio

base precisam sincronizar suas transmissões, visando impedir um excesso de interferência.

Conforme Dornan (2001) isso ocorre com a utilização de sinais de satélites GPS (Global

Positioning System), com capacidade de apontar qualquer localização na Terra em 5 m e de

calcular o tempo com maior precisão que rotação da Terra. Todas as estações rádio base são

equipadas com receptores GPS e a localização de cada telefone é calculada em função do

tempo que um sinal emitido por cada telefone chegue a várias estações rádio base e retorne.

Esse processo é semelhante ao utilizado por radares e é conhecido como triangulação.

O CDMA permite velocidades de dados muito altas e os telefones existentes já transmitem e

recebem simultaneamente nessas velocidades. Porém, muitos dos dados recebidos são

redundantes. Com a utilização de mais de um código Walsh, Dornan (2001) afirma que a

capacidade de 16 Kbps de cada telefone, pode ser multiplicada por qualquer fator até o

número de ligações por canal. Na teoria, este número máximo é 64, o que fornece velocidades

superiores a 1Mbps. Na prática, velocidades dessa grandeza talvez ainda não sejam possíveis,

mas com um máximo de 15 códigos o sistema pode proporcionar velocidades respeitáveis

chegando a 240 Kbps. Limitações de hardware dos telefones e a baixa capacidade das

operadoras, tornam essas velocidades inatingíveis.

38

A partir de uma atualização conhecida como IS-95b ou cdmaTwo, o CDMA pode fornecer

velocidades semelhantes às que GPRS e HSCSD fornecem para os sistemas GSM. As

operadoras podem implementar o cdmaTwo com uma simples atualização de software,

entretanto, seus clientes precisarão trocar seus telefones. O cdmaTwo serve como base para a

implementação de redes de terceira geração.

2.3.2.5 HSCSD

Segundo Dornan (2001) o HSCSD (High Speed Circuit Switched Data) é uma simples

atualização no sistema GSM, capaz de fornecer mais de um time slot para cada um dos seus

usuários na operação de multiplexação. Foi padronizado em 1997 pelo ETSI (European

Telecommunications Standards Institute) e teve seu lançamento comercial apenas em 2000.

Ele equivale a juntar duas ou mais linhas telefônicas e somar suas capacidades de transmissão.

As redes e telefones móveis com suporte a HSCSD utilizam codecs mais sofisticados,

permitindo uma velocidade de transferência de dados de 14,4 Kbps. O padrão HSCSD

permite a fusão de até quatro canais GSM, resultando em velocidades de 57,6 Kbps. Porém,

velocidades intermediárias de 28,8 e 43,2 Kbps são possíveis e mais comuns. Também é

possível realizar transferência de dados assimétrica, por exemplo, três time slots transmitidos

da estação rádio base para a estação móvel e um ou dois time slots no sentido contrário.

“O limite de quatro canais não foi escolhido de forma aleatória. Seria possível agregar todos

os oito canais em um time slot, mas isso dificultaria o projeto dos aparelhos de telefone e o

HSCSD pretendia ser uma simples atualização.” (DORNAN, 2001, p 71). Utilizando apenas

quatro canais os telefones não precisam transmitir e receber dados simultaneamente, e cada

time slot nos frames de link direto GSM é emparelhado com um time slot no link reverso

correspondente, conforme mostrado na figura 9.

Dornan (2001) explica que o HSCSD de transferência plena significa que cada cliente precisa

de quatro vezes mais largura de banda para chamadas regulares e oito vezes mais para

chamadas que utilizem codec de meia velocidade3. Todavia, muitos clientes não desejam

3 Codec de meia velocidade é um codec (codificador e decodificador responsável por converter a voz analógica

em sinal digital) que divide pela metade a largura de banda necessária por chamada, duplicando a capacidade de

transmissão com uma pequena perda na qualidade do sinal. (DORNAN, 2001).

39

pagar oito vezes mais por uma chamada regular, o que fez com que as operadoras GSM não

implementassem o HSCSD e aguardassem por outro sistema mais eficiente do ponto de vista

de utilização de largura de banda.

Figura 9 - HSCSD de quatro slots


Um outro problema apresentado por Dornan (2001, p 71) é:

O projeto de terminais HSCSD também oferece dificuldades. Quatro time slots

precisam transmitir por quatro vezes mais que um telefone GSM comum, com os

correspondentes aumento de consumo de bateria e de emissão de radiação. Além de

possíveis danos à saúde, existe um problema mais imediato: os primeiros terminais

com transferência plena simplesmente se incendiariam.

Uma solução para o superaquecimento foi a construção de dispositivos HSCSD assimétricos,

onde velocidades maiores são fornecidas para downloads e velocidades menores para

uploads. Essa solução vem de encontro com as características da navegação na web, onde

páginas de texto e imagens são transmitidas em um único sentido e poucos cliques do mouse

em sentido contrário. Mas por se tratar de uma tecnologia que utiliza comutação por circuito,

não há uma maneira de se aproveitar a largura de banda não utilizada resultando em time slots

vazios nas transmissões no sentido estação móvel para estação rádio base.

Apenas uma única aplicação simétrica utilizando HSCSD foi lançada até agora, é o vídeo

bidirecional. Conforme Dornan (2001) a operadora britânica Orange desenvolveu um

videofone com câmera embutida e um terminal HSCSD de 28,8 Kbps. Seu lançamento era

previsto para o início de 2000, mas foi adiado por pelo menos um ano.

Slots emparelhados Telefone recebe

Frame A

Link reverso

Link direto 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8

1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8

Frame B

Telefone transmite

40

2.3.2.6 GPRS

O GPRS (General Packet Radio Service) é o mais popular esquema de Internet sem fio entre

as operadoras, pois foi projetado para dados e prometendo fornecer a cada usuário uma

conexão permanente e de alta velocidade à Internet. Ele foi projetado para funcionar sistema

baseado no padrão, porém funciona apenas com GSM. (DORNAN, 2001).

Para Tanenbaum (2003, p 179) o GPRS é “uma rede de superposição de pacotes sobre o D-

AMPS ou o GSM. Ele permite que estações móveis transmitam e recebam pacotes IP em uma

célula que executa um sistema de voz.”

O grande aperfeiçoamento realizado no GPRS é a introdução de comutação de pacotes em

redes móveis, sendo mais eficiente que a comutação por circuito. Pelo fato de a comutação

por pacote ser o padrão para as redes de terceira geração, as redes GPRS também são

conhecidas como redes 2,5G.

Numa rede GSM ou HSCSD, que utilizam comutação por circuito, cada usuário ocupa por

inteiro um canal de 9,6 Kbps, mesmo não estando transmitindo ou recebendo nada, apenas

pelo fato de estarem conectados. Para Dornan (2001) isso resulta em um desperdício tanto

para os usuários como para as operadoras. O cliente por estar pagando por uma conexão

ociosa e a operadora comprometendo uma parte do espectro que poderia estar sem utilizada

de uma forma mais lucrativa.

O GPRS pode compartilhar um único time slot de 14,4 Kbps entre centenas de usuários, desde

que todos não tentem utilizá-lo ao mesmo tempo. (DORNAN, 2001). Desta forma, cada

usuário tem uma conexão permanente com velocidades bem baixas, na faixa de 0,1 Kbps ou

até menos, e que sobem de velocidade na medida em que haja necessidade de transmissão ou

recepção de dados.

O GPRS prevê uma velocidade máxima de dados de até 115,2 Kbps, mas para isso necessita

de estações móveis capazes de fazer uso dos oito time slots de forma simultânea. Contudo,

esse valor é puramente teórico, uma vez que o GPRS enfrenta o mesmo problema de

superaquecimento existente no HSCSD, ou seja, os sistemas GPRS também são assimétricos.

O GPRS deve coexistir com o GSM e talvez com o HSCSD, o que implica em telefones que

trabalhem tanto com comutação de circuitos como comutação por pacote. Mas a grande

41

tendência é que as redes GPRS conduzam voz nos pacotes, utilizando um codec de velocidade

variável para que os dados possam ser transmitidos durante os intervalos da conversação.

(DORNAN, 2001). Em virtude da necessidade de os telefones com suporte a GPRS terem que

trabalhar tanto com comutação por pacotes quanto com comutação por circuito, os aparelhos

estão classificados em 3 categorias: A, B, C.

Na categoria A os aparelhos “[...] são capazes de realizar conexões simultâneas de comutação

de circuito e de pacotes. O cliente pode conversar no telefone e surfar na Web ao mesmo

tempo.” (DORNAN, 2001, p 74). Os aparelhos da categoria B “[...] mantêm uma conexão de

pacotes, enquanto está em andamento uma chamada de circuito comutado, mas não são

capazes de enviar dados. O cliente pode ser notificado, por exemplo, da chegada de um e-mail

enquanto uma ligação está em andamento, mas será necessário desligar para recebê-la.”

(DORNAN, 2001, p 74). Já os da categoria C “[...] operam nos modos de comutação de

pacotes ou circuitos, mas não os dois ao mesmo tempo. Quando ocorre uma chamada de voz,

é necessário interromper a conexão de dados que, com essa exceção, é permanente.”

(DORNAN, 2001, p 74).

2.3.3 Terceira geração

Os sistemas de terceira geração (3G) são essenciais para os serviços de Internet sem

fio e, quase sempre, são considerados como o futuro da comunicação móvel.

Inicialmente, proporcionariam acesso permanente à Web, vídeo interativo e

qualidade de voz semelhante à de um CD-player e não de um telefone celular.

Muitas de suas futuras aplicações ainda são desconhecidas, mas os especialistas do

setor afirmam que serão descobertas com o passar do tempo. (DORNAN, 2001, p

94).

A principal característica das redes de terceira geração (3G) é a transmissão de dados em alta

velocidade, e o conceito original de um sistema 3G segundo Dornan (2001) é qualquer padrão

capaz de fornecer aos usuários móveis o desempenho das redes ISDN (Integrated Services

Digital Network) ou superior, mas pelo menos 144 Kbps. Mas o termo 3G acabou se tornando

bastante vago.

Padrões considerados como 2,5G oferecem velocidades equivalentes aos padrões 3G, por

exemplo, o GPRS e o cdmaTwo. Porém estes dois padrões só oferecem esse desempenho em

condições ideais, e os sistemas 3G precisam oferecer o desempenho proposto para todos os

seus usuários, independente da sua localização em relação à estação rádio base e do

42

equipamento utilizado por esses usuários. A figura 10 mostra o processo de atualização das

redes 1G e 2G para se tornarem redes 3G.

A compatibilidade retroativa deverá ser mantida entre os padrões 3G e seus predecessores,

para que os telefones possam manter a conexão enquanto se deslocam entre células baseadas

no antigo e no novo padrão. (DORNAN, 2001).

Segundo Dornan (2001) assim como aconteceu com as redes 1G e 2G, não existe uma única

solução para redes 3G. Por exemplo, a Europa definiu um tipo de CDMA que funcionará com

o GSM, que poderá ou não ser compatível com um sistema já existente no Japão. Já em

regiões onde as redes 2G são baseadas na tecnologia CDMA, surge uma solução conhecida

como cdma2000 e sem compatibilidade entre os sistemas europeu e japonês. Na América as

operadoras de redes D-AMPS e GSM, a solução desejada é baseada na tecnologia TDMA, o

que segundo Dornan (2001) resulta num padrão federal, que é mais precisamente descrito

como uma fraude, onde o roaming4 global só será possível com o uso de telefones multímodo

especiais.

Figura 10 - Percurso de atualização para a terceira geração


4 Processo no qual um usuário da rede celular faz uso de uma outra rede celular que não é a sua rede de origem.

América

Europa

Japão

Atualização com sistemas de rádio inteiramente

novos necessários

Atualização com nova modulação necessária

Atualização fácil sem adaptações

cdma2000

PDC

GSM

HSCSD

GPRS EDGE W-CDMA

AMPS / D-AMPS D-AMPS+

IS-95a IS-95b 1XMC

HDR 3XMC

1Xtreme

Sistemas 2G

Sistemas 3G

43

Em 1992 a ITU (Internacional Telecommunications Union) percebendo que as comunicações

móveis cada vez mais tornavam-se importantes, lançou um projeto originalmente chamado de

FPLMTS (Future Public Land Mobile Telecommunications System) e logo depois alterado

para IMT-2000, cujo objetivo é de unir o mundo sob um padrão único. De acordo com

Dornan (2001) a sigla IMT significava Internacional Mobile Telecommunications e o número

2000 tinha três significados:

• O ano 2000, ano em que o sistema deveria entrar em serviço.

• As transferências de dados de 2000 Kbps.

• As freqüências na faixa de 2000 MHz na qual ele deveria operar.

Segundo Tanenbaum (2003) nenhum dos três aspectos foram alcançados, pois em 2000 não

havia nada implementado. Com exceção da China, nenhum país atendeu à recomendação da

ITU com relação a parte do espectro na faixa de 2GHz. E por fim, reconheceu-se que uma

largura de banda de 2Mbps não era viável naquele momento para usuários com alta

mobilidade, em virtude da dificuldade de se realizar handoffs com a rapidez necessária.

Dornan (2001) também afirma que nenhuma das três aspirações se realizou totalmente, mas o

projeto se manteve com o nome IMT-2000, e que apesar de protótipos desenvolvidos em

1999, os telefones eram do tamanho de caminhões e esperava-se apenas para 2003 a

comercialização em larga escala do serviço.

Em função da dificuldade de realizar handoffs na velocidade necessária para suportar uma

largura de banda de 2Mbps, decidiu-se em uma escolha mais realista na qual se definiu três

velocidades diferentes, de acordo com Tanenbaum (2003):

• 144 Kbps para conexões em automóveis.

• 384 Kbps para pessoas se deslocando a pé.

• 2 Mbps para usuários estacionários em recintos fechados.

A tabela 5 mostra os tipos de serviços disponíveis no IMT-2000.

44

Tabela 5 - Tipos de serviços disponíveis no IMT-2000

Classificação

dos serviços

Velocidade de

dados de saída

Velocidade de

dados de

entrada

Fator de

assimetria Exemplo Comutação

Multimídia

interativa 256 Kbps 256 Kbps Simétrica Videoconferência Circuito

Multimídia de

alto nível 20 Kbps 2 Mbps 100 Televisão Pacote

Meio de

multimídia 19,2 Kbps 768 Kbps 40

Navegação na

Web Pacote

Comutação de

dados 43,2 Kbps 43,2 Kbps Simétrica Fax Circuito

Mensagens

simples 28,8 Kbps 28,8 Kbps Simétrica E-mail Pacote

Fala 28,8 Kbps 28,8 Kbps Simétrica Telefonia Circuito


Dornan (2001) acredita que para os serviços listados na tabela 5 onde o tipo de comutação

seja por circuito, que esta comutação deva ser realizada por circuitos virtuais ao invés de

circuitos reais. Tudo é compactado em pacotes incluindo voz, fax e vídeo, porém os pacotes

de voz recebem prioridade sobre os demais.

Para as redes 3G a ITU previu uma única tecnologia mundial para o IMT-2000, visando que

os fabricantes de telefones celulares construíssem de um único dispositivo que pudesse ser

comercializado e utilizado no mundo inteiro. Entretanto, Tanenbaum (2003) diz que várias

propostas foram feitas e dentre elas foram selecionadas duas. A primeira foi o W-CMDA

(Wideband CDMA), que foi proposta pela empresa Ericsson. Este sistema foi adotado pela

União Européia e batizado de UMTS (Universal Mobile Telecommunications System). A

segunda proposta foi o cdma2000, proposto pela empresa Qualcomm.

2.3.3.1 W-CDMA

Preferido pela maioria das operadoras para ser o sistema das redes 3G, o W-CDMA ou

CDMA banda larga foi projetado para permitir handoff para o GSM, porém, são sistemas bem

45

diferentes. Conforme Dornan (2001), as redes GSM não podem ser atualizadas para o W-

CDMA, podendo-se apenas aproveitar o backbone5 GPRS.

Utilizando uma largura de banda de 5 MHz por canal, por isso o nome banda larga, o W-

CDMA fornece uma capacidade quatros vezes maior que o cdmaOne e 25 vezes a do GSM,

afirma Dornan (2001). Tanenbaum (2003) diz que o W-CDMA funciona em uma largura de

banda de 5 MHz e que foi projetado para interoperar com redes GSM, mas sem

compatibilidade retroativa.

A utilização de uma banda maior se deve ao fato de permitir maiores velocidades de dados,

apesar de somente oferecer essas velocidades em ares de baixa densidade demográfica e com

uma boa intensidade de sinal. O W-CDMA sofreu algumas melhorias com relação ao envio

repetido de bits de dados, presente no cdmaOne. Ao invés de as informações serem enviadas

64 vezes, W-CDMA ajusta o número de repetições, conhecido como ganho, em função da

intensidade de sinal. Neste caso, cada bit pode ser enviado de 4 a 128 vezes, onde, quanto

mais fraco o sinal, mais vezes as informações são enviadas, reduzindo a largura de banda útil.

Dornan (2001) diz que uma outra grande diferença entre W-CDMA e o cdmaOne é a

necessidade de sincronização, pois foi projetado para trabalhar sem os sinais de clock6 GPS,

ele utiliza uma técnica de codificação conhecida como códigos Gold. A combinação destes

códigos com a modulação QPSK do cdmaOne, proporcionam velocidades de

aproximadamente 4 Mbps por canal em cada célula, o que supera os requisitos do IMT-2000.

O W-CDMA apresenta um aprimoramento da eficiência do espectro se comparado com os

sistemas TDMA, pois cada canal é reaproveitado em todas as células. Ele ainda permite a

realização de soft handoff, com exceção para as redes GSM onde os handoffs ainda são hard.

(DORNAN, 2001).

Na Europa o W-CDMA foi batizado de UMTS e foi planejado desde 1996 visando ser o

substituto do GSM, e tornando-o tão bem sucedido quanto. Em virtude de haver pouquíssima

capacidade nas redes 2G do Japão, as primeiras redes no padrão W-CDMA estão sendo

5 Suporte principal ou espinha dorsal da rede.

6 São sinais elétricos de cadência fixa, utilizados para sincronizar equipamentos de comunicação.

46

implantadas no Japão pelas operadoras NTT DoCoMo e JPhone. Segundo Dornan (2001) as

duas empresas iniciaram testes em 2000 e esperavam comercializar o serviço em 2002.

2.3.3.2 CDMA 2000

O cdmaOne já se baseia no CDMA, o que o coloca na frente dos demais sistemas 2G na

corrida para o 3G. Isso se deve ao fato de as operadoras poderem atualizar suas redes através

de atualizações de software ou de modulação, enquanto as demais necessitam de um novo

sistema de rádio. Essas atualizações são conhecidas como cdma2000 e possuem

compatibilidade retroativa com todas as redes IS-95 existentes. (DORNAN, 2001).

A atualização final para o cdmaOne é conhecida como cdma2000 3XMC, e combina três

canais o que aumenta a largura de banda. A especificação do cdma2000 3XMC é quase

idêntica ao do W-CDMA, mas apresentou problemas de compatibilidade com as redes W-

CDMA da Europa e do Japão, motivada pela velocidade dos chips7, ou seja, a freqüência de

ressonância do transceptor. Segundo Dornan (2001) a freqüência do cdma2000 precisa ser um

múltiplo do cdmaOne, enquanto a do W-CDMA precisa ser adequada a estrutura de frames do

GSM.

Em 2000 surge o 1Xtreme, um conjunto de sistemas lançados pela Nokia e Motorola. O

1Xtreme é capaz de alcançar velocidades semelhantes às do 3XMC, porém , utilizando apenas

um canal, ou seja, um terço do espectro. De acordo com Dornan (2001) as características do

1Xtreme não estão comprovadas e que para alguns analistas não passa de uma mera tentativa

de combater muitas das patentes do CDMA da concorrente Qualcomm.

Se as características do 1Xtreme forem comprovadas, ele proporcionará às operadoras de

cdmaOne um aumento de suas capacidades, muito além de qualquer sistema concorrente. A

tabela 6 mostra as atualizações concorrentes para o CDMA, porém, Dornan (2001) ressalta

que as capacidades reais são apenas estimativas dos fabricantes e que sua confiabilidade

deverá ser considerada apenas depois de serem testadas.

7 Componente eletrônico integrado em uma pastilha de silício.

47

Tabela 6 - Comparação de sistemas CDMA

Sistema CDMA Largura de banda

do canal Velocidade do chip

Capacidade

máxima Capacidade real

cdmaOne IS-95b 1,25 MHz 1,2288 MHz 115,2 Kbps 64 Kbps

cdma2000 1XMC 1,25 MHz 1,2288 MHz 384 Kbps 144 Kbps

cdma2000 1Xtreme 1,25 MHz 1,2288 MHz 5,2 Mbps 1200 Kbps

cdma2000 HDR 1,25 MHz 1,2288 MHz 2,4 Mbps 621 Kbps

cdma2000 3XMC 3,75 MHz 3,6864 MHz 4 Mbps 1117 Kbps

W-CDMA (UMTS) 5 MHz 4,096 MHz 4 Mbps 1126 Kbps


• O 1XMC segundo Dornan (2001) é a etapa seguinte para as redes IS-95b. As letras MC

significam Multi Carrier e este sistema exige novo hardware nos controladores da estação

rádio base. Promete o dobro da capacidade do cdmaOne, fazendo uso de duas vezes para

cada código Walsh. Devido à semelhança com o IS-95b, ele é chamado às vezes de IS-

95c.

• Para Dornan (2001), o 3XMC é a proposta de cdma2000 aceita pelo ITU como parte do

IMT-2000. Possui desempenho semelhante ao do W-CDMA, e utiliza menos banda que o

W-CDMA e herda algumas características do cdmaOne, por exemplo, a velocidade do

chip e a necessidade de temporização GPS.

• O HDR (High Data Rate) é uma atualização do 1XMC proposta pela Qualcomm. Seu

funcionamento se resume em transformar um único canal de 1,25 MHz em um canal para

dados e o ganho de velocidade é obtido através de diferentes tipos de modulação.

(DORNAN, 2001).

• Já o 1Xtreme é o concorrente do HDR e do 3XMC. Utiliza as mesmas técnicas de

modulação do HDR, porém, para voz e dados e podendo ser aplicadas para toda a rede e

não apenas a um único canal. (DORNAN, 2001).

2.3.3.3 EDGE

O EDGE (Enhanced Data Rates for GSM Evolution) foi planejado para ser uma atualização

da velocidade de dados para as redes GSM, sendo mais uma etapa para as operadoras que já

possuíam HSCSD ou GPRS.

48

A idéia original era que o EDGE fosse apenas um intermediário entre as redes GSM e o

UMTS, mas ele acabou sendo adotado como um padrão 3G para redes TDMA, e dessa forma

concorrendo com as tecnologias 3G baseadas em CDMA. (DORNAN, 2001). Para

Tanenbaum (2003) o EDGE não é classificado como um padrão 3G e sim como um padrão

2,5G, apesar de que para ele a identificação como 2,1G fosse a mais adequada. “Em 2000, a

ITU aceitou o EDGE como um modo de IMT-2000 e o padronizou como UWC-136.”

(DORNAN, 2001, p 112).

Segundo Dornan (2001) a UWCC (Universal Wireless Communications Consortium) foi

quem adotou o EDGE e em conjunto com a GSM Association, desenvolveram uma forma de

migrar o D-AMPS para o EDGE, motivada pelo esgotamento das redes D-AMPS tradicionais

e a migração para outras tecnologias 3G, necessitariam da construção de novas redes.

As características principais do GSM e do GPRS são herdadas pelo EDGE, desde a estrutura

TDMA de 8 time slots quanto o tamanho dos slots de 577 microssegundos. A diferença

basicamente está na forma de modulação, que deixa de ser GMSK e passa a ser 8-PSK, a

mesma utilizada no HDR, o que triplica a capacidade do EDGE em relação ao GSM.

“Como o 8-PSK é mais sujeito a ruído do que o GMSK, o EDGE possui nove MCSs

(Modulation and Coding Schemes) diferentes, cada um projetado para uma conexão de

qualidade diferente.” (DORNAN, 2001, p 112). A diferença entre os nove MCSs está apenas

na utilização ou não da modulação 8-PSK, em função do nível de ruído, e da quantidade de

correção antecipada de erro ou FEC8 (Forward Error Correction). Para conexões ruidosas o

EDGE automaticamente utiliza a modulação GMSK, deixando o 8-PSK apenas para as

conexões de melhor qualidade. A tabela 7 mostra os MCSs, o tipo de modulação e o FEC para

cada um deles.

Na prática a utilização do padrão EDGE em redes GSM, requer a utilização também do

GPRS, como mostrado na figura 10.

8 FEC é um recurso que prevê a ocorrência de erros e procura superá-los, enviando códigos de correção extras.

(DORNAN, 2001, p 70).

49

Uma versão simplificada do EDGE foi desenvolvida pelo consórcio UWCC, visando facilitar

a implementação do EDGE nas operadoras D-AMPS. Essa versão simplificada foi chamada

de EDGE Compact, podendo ser utilizada apenas para dados e não para voz, e omitindo

vários canais de controle que são encontrados num sistema completo. Por isso, o EDGE

Compact é considerado como etapa intermediária e não um sistema completo. (DORNAN,

2001).

Tabela 7 - As nove modulações e esquemas de codificação do EDGE

MCS Capacidade do slot FEC Modulação Capacidade do

canal

MCS-1 8,8 Kbps 143% GMSK 70,4 Kbps




MCS-5 22,4 Kbps 187% 8-PSK 179,2 Kbps

MCS-6 29,6 Kbps 117% 8-PSK 236,8 Kbps

MCS-7 44,8 Kbps 43% 8-PSK 358,4 Kbps

MCS-8 54,4 Kbps 18% 8-PSK 435,2 Kbps

MCS-9 59,2 Kbps 8% 8-PSK 473,6 Kbps


2.4 TECNOLOGIAS MÓVEIS

Com o advento das redes celulares, percebeu-se uma grande oportunidade de aproveitar essas

redes para trafegar também dados. Partiu-se então para o desenvolvimento de tecnologias que

proporcionassem aos telefones celulares e PDAs, o acesso à Internet. Uma das primeiras

tecnologias criadas para oferecer um serviço de web móvel foi a WAP. Atualmente existem

algumas outras tecnologias, por exemplo, J2ME, BREW e Visual Studio, que permitem não

só o acesso a Internet e transferência de dados, mas o desenvolvimento de aplicativos e jogos

para os dispositivos móveis.

Uma outra solução seria a utilização direta de aplicações web visualizadas em mini

navegadores, uma vez que, os aparelhos celulares estão ganhando cada vez mais recursos e as

50

aplicações web serem tratadas na sua grande maioria no lado servidor, pode ser uma solução

possível de ser implementada.

2.4.1 WAP

Segundo Dornan (2001), em 1997 a Omnipoint, operadora norte-americana, resolveu

implementar um serviço de web móvel. Sem saber como implementar o serviço e também

quais tecnologias seriam necessárias, a operadora optou por abrir um processo de

concorrência de proposta. As propostas poderiam ser enviadas por qualquer pessoa ou

empresa e deveriam ser explicadas à Omnipoint, como o serviço seria oferecido aos seus

usuários e também como a receita da operadora sofreria aumentos.

O desafio foi aceito por quatro empresas, entre elas três fornecedores de telefones celulares

que sugeriram como solução, uma variante dos seus serviços de mensagem. A quarta empresa

conhecida como Planet, enviou uma proposta chamada de HDML (Handheld Device Markup

Language). Apesar de todas as proposta oferecem vantagens, elas foram recusadas em função

de serem soluções proprietárias, o que tornaria obrigatório o uso de telefones e softwares de

um único fornecedor. A Omnipoint então solicitou a definição de um padrão, o que resultou

na criação do WAP Forum formado originalmente pelas quatro empresas. Após um ano o

Forum foi aberto a novos membros e anunciada a primeira versão do WAP (Wireless

Application Protocol).

Dornan (2001) diz que outras soluções não-proprietárias foram criadas, por exemplo, o C-

HTML (Compact HTML) que tem o apoio do consórcio W3C. Porém, o WAP se destaca em

relação à outros sistemas web sem fio por ser uma nova pilha de protocolos completa e não

apenas uma linguagem de marcação. Por isso o WAP é mais complexo que o C-HTML, no

entanto, mais confiável por ter sido projetado para superar problemas específicos das redes

sem fio, como alta latência e flutuação. A figura 11 mostra a pilha de protocolos WAP e como

eles se encaixam no modelo OSI (Open System Interconnection).

51

Figura 11 - Pilha de protocolos WAP


Os componentes da pilha de protocolos WAP são descritos a seguir:

• WDP (Wireless Datagram Protocol): “é a camada inferior da pilha WAP e é aquela dos

elementos que tornam o WAP, o protocolo extremamente portátil que é, possível de ser

usado em redes móveis extremamente diferentes.” (AREHART et al, 2001, p 27). É uma

alternativa ao uso do UDP/IP e cobre as camadas 3 e 4, resultando em transmissões mais

eficazes. (DORNAN, 2001).

• WTLS (Wireless Transport Layer Security): é uma camada opcional e tem como objetivo

resolver os problemas de segurança. É baseada na TLS (Transport Layer Security), que

por sua vez tem como base a SSL (Socket Security Layer) que são protocolos de Internet.

Opera por meio da camada WDP. (AREHART et al, 2001).

WML (Wireless Markup Language)

WTA (Wireless Telephony Application)

Wscript

WAE (Wireless Application Environment)

WSP (Wireless Session Protocol)

WTP (Wireless Transaction Protocol)

WTLS (Wireless Transport Layer Security)

UDP

IP

SMS USSD GRPS CDPD EDGE Bluetooth

WDP (Wireless Datagram Protocol)

GSM D-AMPS IS-95 UMTS

Camada 7

Camada 5

Camada 4

Camada 3

Camada 2

Protocolo WAP Outros protocolos

52

• WTP (Wireless Transaction Protocol): “[...] fornece serviços para realizar transações

confiáveis e não confiáveis e opera por meio da camada WDP ou por meio da camada de

segurança opcional, WTLS.” (AREHART et al, 2001, p 24).

• WSP (Wireless Session Protocol): “[...] protocolo de sessão sem fio, permite que serviços

troquem dados entre aplicativos de forma organizada.” (AREHART et al, 2001, p 23).

Oferece serviços orientados à conexão por meio do WTP e não orientados à conexão por

meio do WDP.

• WAE (Wireless Application Environment): “[...] permite ao desenvolvedor usar formatos

e serviços específicos, criados e otimizados para apresentar conteúdo e interagir com

dispositivos de capacidade limitada.” (AREHART et al, 2001, p 21). Permite a utilização

de três aplicações diferentes: WML, WMLscript e WTA.

• WML (Wireless Markup Language): linguagem de marcação projetada para apresentar

principalmente páginas baseadas em texto. É definida como um arquivo XML (eXtensible

Markup Language), e possui suporte a texto (formatação, negrito, itálico, etc), imagens

WBMP (Wireless Bitmap), entradas do usuário e variáveis. (AREHART et al, 2001).

• WMLscript ou Wscript: “[...] uma linguagem de script baseada em JavaScript.”

(DORNAN, 2001, p 134).

• WTA (Wireless Telephony Application): “[...] interface que permite ao WAP acessar

recursos do telefone, como catálogo de endereços, e até realizar ligações.” (DORNAN,

2001, p 134).

Dornan (2001) diz que, embora o WAP possua seus próprios protocolos, ele foi projetado

para ser compatível com a Internet. Desta forma, as páginas escritas em WML podem ser

transportadas utilizando o HTTP comum sobre TCP/IP, sendo convertidas para WAP nos

gateways entre a Internet e as redes sem fio. Essa conversão enfraquece a segurança, pois a

criptografia realizada para a transmissão na Internet é diferente da criptografia utilizada na

transmissão das redes móveis, e no momento em que os dados vindos da Internet são

descriptografados para serem convertidos e criptografados pelo WTLS, os dados tornam-se

vulneráveis. Dornan (2001) comenta que o WAP também costuma ser descrito como um

protocolo centrado em redes, o que significa que a maior parte da inteligência está

concentrada na rede e não nos telefones. Isso provoca problemas de compatibilidade,

principalmente quando WMLScript é utilizado, pois os navegadores comuns de Internet

possuem interpretadores para a sua linguagem de script, enquanto o mesmo não ocorre com

os telefones celulares.

53

2.4.2 BREW

“A plataforma BREW é a única solução aberta e de ponta a ponta que fornece um caminho

para o lucro com aplicativos de dados para desenvolvedores de aplicativos, fabricantes de

dispositivos e operadoras de redes. Ela é uma tecnologia e um sistema de negócios flexível e

pronto para usar.” (QUALCOMM, 2002).

Segundo a Qualcomm (2002), o aprendizado para desenvolvedores de aplicativos é facilitado

em função de a plataforma ser baseada nas linguagens C e C++, linguagens essas que são

populares, e pelo download do kit de desenvolvimento BREW (SDK) ser gratuito. No que diz

respeitos aos fabricantes de telefones celulares, a Qualcomm (2002) afirma que é

extremamente simples incorporar o BREW nos aparelhos devido ao pouco consumo de

recursos que o BREW faz dos aparelhos, e por isso podendo ser suportado inclusive pelos

aparelhos de baixo recurso, que equivalem de 80 a 90 por cento dos aparelhos presentes no

mercado. Já as operadoras podem ter a garantia de aplicativos seguros através do TRUE

BREW, um serviço opcional oferecido pela Qualcomm, que assegura a confiabilidade dos

aplicativos. Diante dessas características a Qualcomm (2002), garante que o BREW

proporcionará uma grande oportunidade de receitas para todos os participantes da indústria de

comunicação móvel.

A plataforma BREW possui suporte a J2ME (Java 2 Micro Edition), o que significa que além

dos aplicativos desenvolvidos em C/C++, o dispositivo terá condições de executar também

aplicativos desenvolvidos em J2ME. O BREW proporciona ainda aos desenvolvedores de

aplicativos J2ME, valor agregado através de sua abordagem de sistema ponta a ponta.

(QUALCOMM, 2002). A seguir são listadas outras características e vantagens do BREW:

• Processamento em tempo real verdadeiro: possibilita o processamento no lado cliente,

proporcionado uma nova gama de aplicativos, por exemplo, jogos de ação. Isso se deve à

capacidade da plataforma BREW de realizar download e executar aplicativos no telefone.

(QUALCOMM, 2002).

• Interatividade rápida com a informação: permite ao usuário realizar o download de

informações para seu telefone e depois fazer uso dela localmente. Por exemplo, realizar

download do banco de dados de uma determinada viagem, e a partir daí poder realizar

uma pesquisa no banco de dados ou até mesmo interagir com mapas rapidamente e

quantas vezes forem necessárias. (QUALCOMM, 2002).

54

• Telefonia móvel mais personalizada: “Usuários finais podem literalmente personalizar

seus telefones com aplicativos e informações adequados a suas vidas - e trocar os

aplicativos sempre que quiserem.” (QUALCOMM, 2002). Um usuário pode realizar o

download de aplicativos de produtividade comercial, entretenimento e toques de

companhia personalizados. (QUALCOMM, 2002). Permite que as operadoras distribuam,

atualizem e recolham aplicativos, até mesmo os de uso específico de telefonia, sem que

haja a necessidade de levar o telefone à uma loja ou assistência técnica. (QUALCOMM,

2002). Esse gerenciamento de distribuição de aplicativos é feito por meio da ferramenta

BDS (BREW Distribuition System) que “[...] permite que uma operadora implante

rapidamente um negócio de aplicativos de comunicação móvel, sobre o serviço de

telefonia móvel que ela já oferece.” (QUALCOMM, 2005a).

• Requisitos de hardware mínimos: “A plataforma BREW é magra - exige cerca de 150

KB, eficiente e poderosa, sem exigir uma máquina virtual (VM,Virtual Machine) diferente

para cada modelo de telefone.” (QUALCOMM, 2002).

• Desde o seu lançamento em janeiro de 2001, a Qualcomm (jun. 2005) afirma que o

BREW está presente em 24 países e implantado serviços BREW por 45 operadoras. No

Brasil, a operadora VIVO implantou o serviço VIVODOWNLOADS que permite aos

clientes VIVO realizarem downloads de aplicativos diretamente para o seu celular.

(VIVO, 2005).

“[...] o BREW é independente da tecnologia de comunicação móvel usada por um aparelho

telefônico ou rede em particular, podendo facilmente suportar outras tecnologias de

comunicação móvel.” (QUALCOMM, 2005b). Ou seja, a plataforma BREW é independente

da interface aérea, podendo ser utilizada por aparelhos telefônicos baseados em outras

tecnologias de comunicação móvel, tais como GSM e D-AMPS, e não apenas em aparelhos e

redes CDMA. (QUALCOMM, 2005b).

2.4.3 SUPERWABA

Derivado de um outro projeto de software livre, o Waba da WabaSoft, e criado em 2000 por

Guilherme Campos Hazan, o SuperWaba é uma plataforma de desenvolvimento de software

voltada para aplicações para PDAs e Smartphones que possuam os sistemas operacionais

Windows Móbile ou Simbian 7. (SUPERWABA, 2005a). O kit de desenvolvimento do

SuperWaba define uma linguagem, uma máquina virtual e formato de arquivo para

armazenamento das classes e um conjunto de classes padrão. (SUPERWABA, 2005a).

55

As aplicações SuperWaba podem ser desenvolvidas utilizando-se as ferramentas de

desenvolvimento para Java em virtude do modo como o SuperWaba foi projetado. Entretanto,

o SuperWaba não implementa nenhuma parte das especificações Java e também não possui

nenhum vínculo com a Sun Microsystems. (SUPERWABA, 2005a).

A seguir, são listadas algumas características da plataforma SuperWaba:

• Máquina virtual:

o Suporte a diversas plataformas.

o Possibilidade de criação de bibliotecas nativas em C.

o Suporte a PDAs monocromáticos, coloridos e também de alta resolução.

o Suporte a exceções (exceptions), números de ponto flutuante de alta precisão

(double) e número inteiros de grande capacidade (long).

o Utilização de toda memória disponível no PDA para as suas aplicações.

• Biblioteca de extensão:

o Container de HTML robusto.

o Tokenizador de XML.

o Classes com suporte a exibição de informações de GPS, baseados no protocolo

Garmin.

o Suporte para scanners da Symbol para Pocket PC e Palm OS.

o Suporte a leitura de arquivos PalmDoc e aos formatos de arquivo PalmZip.

o Suporte a algoritmos de criptografia: Blowfish, MD5, SHA1, TEA.

o Personal Information Abstract Layer : permite acessar dados pessoais nas

plataformas Pocket PC e Palm OS.

o API de Jogos, suportando sprites, botões animados, etc.

• Entrada e saída:

o Suporte a TCP/IP, porta serial, USB, Infravermelho, Bluetooth.

o Manipulação de arquivos em cartões Secure Digital e Memory Stick.

o Utiliza arquivos PDBs também no Pocket PC, tornando o banco de dados

específico da Palm multi-plataforma.

o Especificação de Conectividade para Banco de Dados (WDBC): com drivers para

IBM Db2 e o PDB SQL Driver.

o Capacidade de impressão.

• Interface com o usuário:

56

o Dois estilos diferentes para todos os controles: Palm OS e Windows CE.

o Em ambos os estilos, todos os controles têm um estado desabilitado visível.

o Janelas popup arrastáveis.

o Posicionamento relativo faz com que o programa se adapte a qualquer resolução.

• Requisitos mínimos de hardware: Necessários apenas 340 KB.

Segundo SuperWaba (2005b), o processo de desenvolvimento de aplicativos em SuperWaba:

• Criação da aplicação usando qualquer IDE (Integrated Development Environment) Java e

o kit desenvolvimento SuperWaba.

• Compilação da aplicação utilizando o compilador Java.

• Executar as ferramentas de deployment para empacotar as classes em arquivos PDB (Palm

Database file) e gerar o instalador.

• Executar o instalador ou simplesmente sincronizar os dispositivos.

A figura 12 ilustra o processo de desenvolvimento em SuperWaba.

Figura 12 - Processo de desenvolvimento SuperWaba

Fonte: SuperWaba (2005b)

2.4.4 Visual Studio

É um ambiente de desenvolvimento que permite a elaboração de diversos tipos de aplicações

voltados para a plataforma .NET da Microsoft, como o ASP.NET, web services ou mesmo

aplicações Windows. Segundo Haddad (2005), o Visual Studio .NET 2003 incorpora

ferramentas para o desenvolvimento de aplicações para Pocket PC e PDAs. Para aplicações

57

de telefones celulares, é necessário a instalação de emuladores que podem ser encontrado nos

sites dos fabricantes como a Nokia, Openwave, etc.

Haddad (2005) afirma que um ponto forte da plataforma .NET é o suporte a Visual Basic, e

Visual C#, podendo o desenvolvedor utilizar o conhecimento em uma dessas linguagens para

o desenvolvimento de suas aplicações para dispositivos móveis, com as limitações das classes

disponíveis para esse tipo de aplicação. Outra vantagem do Visual Studio é a de não se

preocupar com o tipo de telefone celular a aplicação irá rodar, tornando a produtividade e a

facilidade de desenvolvimento ainda maior. “O processo é semelhante ao processamento de

uma página ASP.NET, quando o Web Server recebe a solicitação do celular (via operadora, é

claro), o Framework identifica qual é o Device que fez tal solicitação e monta o WML

(Wireless Markup Language) que ele suporta.” (HADDAD, 2005). O .NET suporta mais de

200 dispositivos de fabricantes diferentes.

2.4.5 J2ME

O J2ME foi desenvolvido especialmente para dispositivos com baixo poder de

processamento, por exemplo, pagers e celulares. “Com a introdução do J2ME, os dispositivos

micros não precisam mais ter natureza estática.” (MUCHOW, 2004, p 3). O J2ME permite a

um dispositivo móvel a opção de navegar na Internet, realizar downloads e instalar aplicativos

Java e conteúdo. (MUCHOW, 2004). O J2ME possibilita acesso aos recursos inerentes da

linguagem e da plataforma Java, ou seja, uma linguagem de fácil aprendizado, um ambiente

em tempo de execução que oferece uma plataforma portável e segura, e acesso a conteúdos

dinâmicos.

Por ser destinada a dispositivos com poucos recursos de processamento e memória, a API

(Application Program Interface) do J2ME não oferece todos os recursos disponíveis na

versão J2SE do Java. Em função da diversidade de dispositivos móveis existentes e das

diferentes características que cada tipo de dispositivo apresenta, os recursos dentro do J2ME

podem variar bastante. (MUCHOW, 2004). Segundo Muchow (2004), uma única plataforma

Java não seria capaz de suportar a grande variedade de dispositivos existentes, e para poder

suportar esses dispositivos o J2ME introduz dois novos conceitos: configurações e perfis.

58

2.4.5.1 Configuração

É responsável por definir uma plataforma Java para uma ampla variedade de dispositivos,

estando intimamente vinculada a uma máquina virtual Java (JVM), e também define os

recursos da linguagem Java e as bibliotecas básicas suportadas pela JVM para um tipo de

configuração em particular. (MUCHOW, 2004). Atualmente existem duas configurações no

J2ME, a CDC (Connected Device Configuration) e a CLDC (Connected Limited Device

Configuration), e o que define o uso de uma ou de outra são os recursos disponíveis nos

dispositivos, por exemplo, memória, vídeo, conectividade de rede e poder de processamento.

A máquina virtual para o CLDC foi desenvolvida pela Sun como sendo uma implementação

de referência de uma máquina virtual e foi batizada de KVM (K Virtual Machine), e foi

projetada para manipular considerações especiais dos dispositivos de recurso restrito. Já a

máquina virtual definida para o CDC tem a mesma especificação da JVM da versão J2SE.

(MUCHOW, 2004).

A seguir são listadas as características típicas dos dispositivos suportados por cada uma das

configurações:

• Configuração de dispositivo conectado (CDC):

o Mínimo de 512 KB de memória para execução do Java.

o Mínimo de 256 KB de memória para alocação de memória em tempo de execução.

o Conectividade de rede, largura de banda possivelmente persistente e alta.

• Configuração de dispositivo conectado limitado (CLDC):

o Mínimo de 128 KB de memória para executar o Java.

o Mínimo de 32 KB de memória para alocação de memória em tempo de execução.

o Interface restrita com o usuário.

o Baixo poder, normalmente alimentado por bateria.

o Conectividade de rede, normalmente dispositivos sem fio com largura de banda

baixa e acesso intermitente.

2.4.5.2 Perfil

De acordo com Muchow (2004), um perfil pode ser considerado uma extensão de uma

configuração, fornecendo as bibliotecas necessárias para o desenvolvimento de aplicativos

59

para um tipo em particular de dispositivo. O MIDP (Mobile Information Device Profile) é um

exemplo de perfil que define APIs que suportam componentes de entrada, tratamento de

eventos de interface com o usuário, armazenamento persistente, interligação em rede e

cronômetros, de acordo com as limitações de memória e vídeo dos dispositivos móveis.

(MUCHOW, 2004).

2.5 CONSIDERAÇÕES FINAIS

Vistos os conceitos básicos sobre as redes celulares, sua topologia básica, as gerações, as

tecnologias para desenvolvimento de aplicações para dispositivos móveis e a quantidade de

usuários dessas redes, pode-se visualizar uma grande oportunidade de negócios tanto para os

desenvolvedores de software, fabricantes e operadoras. A evolução tecnológica tende a

fornecer ainda mais recursos a esses dispositivos que hoje já possuem algum poder de

processamento. As redes 3G e suas sucessoras devem estar ainda mais voltadas para o

fornecimento de serviços de alta velocidade de dados, possibilitando o desenvolvimento de

novos serviços móveis.

A evolução das tecnologias existentes para o desenvolvimento de aplicações móveis, assim

como o surgimento de novas tecnologias, serão conseqüências da evolução das redes e dos

dispositivos móveis. O aprendizado de tecnologias que facilitem o desenvolvimento de

soluções móveis pode ser um diferencial para os desenvolvedores. Tecnologias como J2ME,

que possuam independência de plataforma, que ofereçam robustez, segurança, facilidade de

adaptação aos diferentes tipos de dispositivos, e ainda todas as vantagens oferecidas pelo

paradigma da orientação a objetos, são consideradas boas opções de ferramentas de

desenvolvimento.

Por essas razões, este trabalho se propõe a desenvolver uma solução de correio eletrônico para

celulares, utilizando a tecnologia J2ME, que possibilite não apenas e-mails com texto, mas

agregando a funcionalidade de através do acesso a um servidor de arquivos, anexar

documentos ao e-mail e enviá-lo a partir de um servidor de correio eletrônico.

60

3 CORREIO ELETRÔNICO

Segundo Tanenbaum (2003), o serviço de correio eletrônico existe a mais de duas décadas e

antes de 1990 era utilizado principalmente nos meio acadêmicos. Porém, depois do

lançamento da Internet de uso comercial durante a década de 90, esse serviço ganhou

popularidade e o número de usuários cresceu exponencialmente. Atualmente o serviço de

correio eletrônico em algumas organizações é uma ferramenta de trabalho, mas é largamente

utilizado de maneira informal. O correio eletrônico permite aos seus usuários o envio de

arquivos em anexos e Gasparini e Barrella (1993, p 257) afirmam que “[...] é mais comum

encontrar usuários que transmitem arquivos via Correio Eletrônico do que os que utilizam

softwares de Transferência de Arquivos.”

Tanenbaum (2003, p 626) diz, “Os primeiros sistemas de correio eletrônico consistiam

simplesmente em protocolos de transferência de arquivos, com a convenção de que a primeira

linha da mensagem (isto é, o arquivo) deveria conter o endereço do destinatário.”. Essa

estratégia apresentava algumas limitações citadas por Tanenbaum (2003):

• Impossibilidade de envio a um grupo de pessoas.

• Falta de estrutura interna nas mensagens dificultava o seu processamento pelo

computador.

• O remetente nunca sabia se a mensagem havia chegado ou não.

• Falta de integração entre a interface do usuário e o sistema de transmissão, onde usuário

confeccionava a mensagem num editor, saía, executava o programa de transferência de

arquivos e enviava a mensagem.

• Impossibilidade de criar mensagens contendo texto, imagem e voz.

Tanenbaum (2003) diz que, com a experiência adquirida pelos usuários do serviço de correio

eletrônico, foram sendo propostos sistemas de correio eletrônico cada vez mais elaborados.

Essas propostas foram publicadas como RFC (Request For Comments) e em 1982 foram

61

publicadas as RFCs 821 e 822, relativas ao serviço de correio eletrônico da ARPANET. Essas

RFCs sofreram revisões e tiveram suas publicações nas RFCs 2821 e 2822.

Em 1984 o CCITT (Comité Consultatif International Télégraphique et Téléphonique)

elaborou a sua recomendação para serviço de correio eletrônico, chamada de X.400. E depois

de duas décadas de concorrência, os sistemas de correio eletrônico baseados na RFC 822

tornaram-se o padrão mais utilizado, enquanto o os baseados no X.400 desapareceram.

(TANENBAUM, 2003). “O sucesso da RFC 822 não se deve apenas à sua qualidade, mas

também ao projeto ruim da X.400, cuja complexidade impedia sua implementação adequada.”


3.1 ARQUITETURA E SERVIÇOS

Conforme Tanenbaum (2003), os sistemas de correio eletrônico consistem em dois

subsistemas: os agentes do usuário, que permitem que as pessoas leiam e enviem mensagens,

e os agentes de transferência de mensagens, que transportam as mensagens da origem até o

destino. “Os agentes do usuário são programas locais que oferecem um método baseado em

comandos, em menus ou gráfico para interagir com o sistema de correio eletrônico.”

(TANENBAUM, 2003, p 628). “Normalmente, os agentes de transferência de mensagens são

daemons do sistema, ou seja, processos executados no segundo plano. Sua tarefa é mover as

mensagens de correio eletrônico pelo sistema.” (TANENBAUM, 2003, p 628). Geralmente os

sistemas de correio eletrônico suportam cinco funções básicas (TANENBAUM, 2003):

• Composição: “[...] se refere ao processo de criar mensagens e respostas.”


• Transferência: “[...] se refere ao deslocamento de uma mensagem entre o remetente e o

destinatário.” (TANENBAUM, 2003, p 628).

• Geração de relatórios: “[...] está relacionada ao fato de informar o remetente sobre o que

aconteceu com a mensagem. Ela foi entregue? Foi rejeitada? Perdeu-se?”


• Exibição: visualização das mensagens recebidas. Em algumas situações, torna-se

necessária a realização de conversões ou a utilização de um visualizador especial.

(TANENBAUM, 2003).

62

• Disposição: “[...] é a ultima etapa e se refere ao que o destinatário faz com a mensagem

depois de recebê-la. Dentre as possibilidades estão jogá-la fora, gravá-la, etc.”


Tanenbaum (2003) diz que na sua maioria, os serviços de correio eletrônico permitem a

criação de caixas de correio para armazenar as correspondências recebidas, e que são

necessários comandos para criar e destruir caixas de correio, verificar seus conteúdos, inserir

e excluir mensagens de correio. A figura 13 ilustra os componentes de um sistema de correio

eletrônico.

Figura 13 - Componentes de um sistema de correio eletrônico Fonte: Feit (1993, p 287) – Adaptada por Rodrigo L. Duarte.

A necessidade de enviar uma mesma mensagem a mais de um destinatário originou as listas

de distribuição (mailing list). Outros recursos avançados como o envio de mensagem com

cópia carbono (cc), a cópia carbono oculta (bcc), mensagens de alta prioridade, mensagens

criptografadas, destinatários alternativos caso o destinatário principal não esteja disponível, e

a possibilidade de secretárias lerem e responderem as correspondências de seus chefes, são

recursos suportados por muitos serviços de correio. (TANENBAUM, 2003).

SMTP SMTP

Computador do destinatário

Fila de mensagens

Computador do remetente

Fila de mensagens

Servidor de

retransmissão Agente

de

usuário

Área de

caixa de

correio

Agente de

transferência

de

mensagens

Agente de

transferência

de

mensagens

Área de

caixa de

correio

Agente

de

usuário

Agente de

transferência

de

mensagens

63

3.2 ENVIO DE MENSAGENS DE CORREIO ELETRÔNICO

O envio de mensagens por meio do serviço de correio eletrônico requer que o usuário

remetente inclua na mensagem o endereço de destino e muitas vezes alguns outros

parâmetros. A edição das mensagens pode ser feita em qualquer editor de texto, mas já

existem ferramentas especializadas que tem integrado o editor das mensagens e o agente de

usuário. (TANENBAUM, 2003). O endereço de destino na sua maioria obedecem ao formato

local-part@domain-name, onde local-part identifica a caixa de correio do destinatário e

domain-name identifica o domínio ao qual a máquina destino pertence. (GASPARINI;

BARRELA, 1993). Entretanto, Tanenbaum (2003) ressalta que existem outras formas de

endereçamento e em particular os endereços X.400 têm aspecto radicalmente diferente dos

endereços DNS (Domain Name System).

3.2.1 SMTP

O SMTP (Simple Mail Transfer Protocol) teve sua proposta publicada por meio da RFC 821 e

teve como autor Jonathan B. Postel em 1982. O objetivo do protocolo de transferência de

correio simples (SMTP) é transferir correio confiavelmente e eficientemente. (POSTEL,

1982).

Segundo Tanenbaum (2003), o SMTP é um protocolo ASCII simples, onde a máquina

transmissora estabelece uma conexão TCP na porta 25 com a máquina receptora. A máquina

receptora então inicia a comunicação informando sua identificação e se está apta a receber

mensagens. Caso a máquina receptora não esteja apta para receber mensagens, a máquina

transmissora encerra a conexão e tenta mais tarde. Se a máquina receptora estiver apta a

receber as mensagens, a máquina transmissora anuncia de quem veio a mensagem e para

quem está indo. Se o destinatário existir na máquina receptora, ela informa à máquina

transmissora o sinal para o envio da mensagem. A máquina transmissora então envia a

mensagem e ao término do envio, a máquina receptora confirma o recebimento. Havendo

mais de uma mensagem a ser enviada, a máquina transmissora envia todas, e quando toas as

mensagens em ambos os sentidos tiverem sido trocadas, a conexão é desfeita.

A seguir são listadas algumas RFCs relacionadas ao envio mensagens de correio eletrônico:

64

• RFC 821: Criada por Jonathan B. Postel em 1982, é a especificação original do SMTP.

Nela estão definidos os comandos suportados pelo SMTP, bem como a seqüência de

execução dos mesmos. Os comandos definidos na RFC 821 são:

o HELO: É usado para identificar a máquina transmissora para o servidor. O

argumento deste comando é o nome da máquina transmissora. (POSTEL, 1982).

o MAIL: Este comando é usado para iniciar a transação de correio eletrônico, na

qual cada dado de correio é entregue a uma ou mais caixas de correio. O campo de

argumento contém o caminho reverso. (POSTEL, 1982).

o RCPT: Este comando é usado para identificar um destinatário de correio.

Múltiplos destinatários são definidos através do uso desse comando múltiplas

vezes. (POSTEL, 1982).

o DATA: Indica o inicio do envio da mensagem de correio e requer que o servidor

armazene as informações que serão transmitidas após esse comando. Os dados são

finalizados por uma linha que contém a seguinte seqüência de caracteres: <CR +

LF + . +CR + LF>. (POSTEL, 1982).

o SEND: Este comando é usado para iniciar uma transação de correio na qual os

dados de correio são entregues a um ou mais terminais. O campo argumento

contém o caminho reverso. (POSTEL, 1982).

o SOML: Este comando é usado para iniciar uma transação de correio na qual os

dados de correio são entregues a um ou mais terminais, ou caixas de correio. O

campo argumento contém o caminho reverso. (POSTEL, 1982).

o SAML: Este comando é usado para iniciar uma transação de correio na qual os

dados de correio são entregues a um ou mais terminais, e caixas de correio. O

campo argumento contém o caminho reverso. (POSTEL, 1982).

o RSET: Este comando especifica que a transação de correio atual será abortada.

Todos os dados armazenados serão descartados e os buffers e tabelas de estados

serão limpas. (POSTEL, 1982).

o VRFY: Este comando interroga o receptor para confirmar que um argumento

identifica um usuário. Se o argumento for o nome de um usuário e seu nome

completo for conhecido e estiver definido na caixa de correio, o nome completo é

retornado. (POSTEL, 1982).

o EXPN: Este comando interroga o receptor para confirmar se o argumento é uma

lista de distribuição. Se for, retorna os membros da lista de distribuição. (POSTEL,

1982).

65

o HELP: Este comando solicita ao receptor que envie informações completas de

ajuda para o transmissor do comando HELP. O comando pode ter argumentos, por

exemplo, o nome de um comando e trará informações mais específicas. (POSTEL,

1982).

o NOOP: Este comando não especifica nenhuma ação, a não ser o envio de OK

como resposta do receptor. (POSTEL, 1982).

o QUIT: Este comando especifica que o receptor deve enviar um OK como resposta

e fechar o canal de transmissão. (POSTEL, 1982).

• RFC 974: Elaborada por Craig Partridge em 1986, ela descreve como os sistemas de

correio na Internet esperam rotear as mensagens, baseados nas informações de sistema de

domínio descritos nas RFCs 821, 883 e 973. (PARTRIDGE, 1986).

• RFC 1869: Elaborada por um grupo liderado por J. Klensin em 1995, ela define um

framework para estender os serviços SMTP definindo um meio de o servidor SMTP

informar à um cliente, como os serviços de extensão são suportados . (KLENSIN et al,

1995).

• RFC 2821: Elaborada por J. Klensin em 2001, ela contém a especificação básica do

SMTP (RFC 821), consolidando atualizações e esclarecendo que não foram adicionadas

novas funcionalidades e também não foram alteradas as funcionalidades existentes.

3.2.2 Formato de mensagens

“A RFC 822 é um padrão antigo e não distingue claramente os campos do envelope dos

campos do cabeçalho. Embora ela tenha sido revista na RFC 2822, não foi possível refazê-la

completamente, devido a sua utilização difundida.” (TANENBAUM, 2003, p 633). O formato

de mensagem previsto na RFC 822 é baseado em textos simples. As mensagens possuem um

envelope primitivo, definido na RFC 821, alguns campos de cabeçalho, uma linha em branco

e o corpo da mensagem. (TANENBAUM, 2003).

Normalmente o agente de usuário cria uma mensagem e a repassa para o agente de

transferência de mensagens, que por sua vez utiliza alguns campos do cabeçalho para criar um

envelope. Este envelope na verdade é uma mistura obsoleta de mensagem e envelope.

(TANENBAUM, 2003). Segundo Tanenbaum (2003), os principais campos de cabeçalho

relacionados ao envio das mensagens e seus significados são listados abaixo:

• To: O(s) endereço(s) de correio eletrônico do(s) destinatário(s) principal (is).

66

• Cc: O(s) endereço(s) de correio eletrônico do(s) destinatário(s) secundário(s).

• Bcc: O(s) endereço(s) de correio eletrônico para cópias carbono ocultas.

• From: A(s) pessoa(s) que criou (aram) a mensagem.

• Sender: O endereço de correio eletrônico do remetente.

• Received: A linha incluída por cada agente de transferência de mensagem ao longo da

rota.

• Return-Path: Poder ser usado para identificar um caminho de volta ao remetente.

Tanenbaum (2003) afirma que as mensagens da RFC 822 podem conter uma variedade de

campos de cabeçalho que são utilizados pelos agentes de usuário ou pelos destinatários.

Sendo que os mais comuns são listados a seguir:

• Date: A data e hora que a mensagem foi enviada.

• Reply-To: O endereço de correio eletrônico para onde as respostas devem ser enviadas.

• Message-Id: O número exclusivo que será usado para fazer referência a essa mensagem

posteriormente.

• In-Reply-To: Message-Id da mensagem original correspondente a essa resposta.

• References: Outras Message-Ids relevantes.

• Keywords: Palavras-chaves do usuário.

• Subject: Pequeno resumo da mensagem apresentado apenas em uma linha.

A RFC 822 deixa claro que os usuários têm permissão de criar novos cabeçalhos para uso

próprio. A única restrição é que esses cabeçalhos comecem com o sufixo “X-“.

(TANENBAUM, 2003).

Depois dos cabeçalhos localiza-se o corpo da mensagem. Neste campo é permitido incluir o

que os usuários desejarem, desde textos desenhos elaborados a partir de caracteres ASCII

simples. A seguir são listadas algumas RFCs relacionadas ao formato das mensagens:

• RFC 822: Elaborada por David H. Crocker em 1982, ela especifica a sintax para as

mensagens de texto que são enviadas entre usuários de computadores, utilizando o

framework de correio eletrônico. (CROCKER, 1982).

• RFC 1341: Elaborada por N. Borenstein e N. Freed em 1992, ela foi elaborada para prover

facilidade para incluir múltiplos objetos em uma única mensagem e também representar

textos que possuem caracteres além do conjunto ASCII americano. A solução proposta

67

por essa RFC ficou conhecida como MIME (Multipurpose Internet Mail Extensions).

(BORENSTEIN; FREED, 1992).

• RFC 1521: Elaborada por N. Borenstein e N. Freed em 1993, ela é uma revisão da RFC

1341 e foram sugeridas 13 alterações na 1521 em relação a 1341. Entre elas está a

obrigatoriedade do campo Content-ID para mensagens ou partes externas do corpo da

mensagem. (BORENSTEIN; FREED, 1993).

• RFC 1522: Elaborada por K. Moore em 1993, ela descreve uma extensão para o formato

de mensagem definido na RFC 1521, para representar conjuntos de caracteres que além do

US-ASCII. (MOORE, 1993).

• RFC 1590: Elaborada por J. Postel em 1994, ela se refere a um procedimento de registro

de novos tipos de mídia, além dos previstos pelo MIME. (POSTEL, 1994).

• RFC 2045: Elaborada por N. Borenstein e N. Freed em 1996, ela especifica vários

cabeçalhos usados para descreve a estrutura de mensagens MIME. (BORENSTEIN;

FREED, 1996).

• RFC 2822: Elaborada por P. Resnick em 2001, ela especifica a sintax para as mensagens

de texto que são enviadas entre usuários de computadores, utilizando o framework de

correio eletrônico. Esta RFC substitui a RFC 822, atualizando-a para as práticas atuais e

incorporando as alterações especificadas em outras RFCs. (RESNICK, 2001).

3.2.2.1 MIME

Em 1992, N. Borenstein e N. Freed elaboram a RFC 1341 visando prover facilidade para

incluir múltiplos objetos em uma única mensagem e também representar textos que possuem

caracteres além do conjunto ASCII americano. A solução proposta por essa RFC ficou

conhecida como MIME (Multipurpose Internet Mail Extensions). (BORENSTEIN; FREED,

1992). A RFC 1341 foi atualizada nas RFCs 2045 e 2049 e sua idéia básica é continuar

utilizando o formato RFC 822, mas incluir uma estrutura para o corpo da mensagem que não

utilizam o código ASCII. (TANENBAUM, 2003). O padrão MIME pode ser enviado por

qualquer protocolo e programa de correio eletrônico existente, pois é compatível com o

padrão 822. (TANENBAUM, 2003).

Segundo Tanenbaum (2003), no MIME são definidos cinco novos cabeçalhos de mensagens.

São eles:

68

• MIME-Version: Informa ao agente do usuário receptor, não apenas que ele está lidando

com uma mensagem MIME, mas também a versão do padrão MIME que está sendo

utilizada.

• Content-Description: É um string ASCII que informa o conteúdo da mensagem.

• Content-Id: Identifica o conteúdo. Ele utiliza o mesmo formato do cabeçalho Message-Id

padrão.

• Content-Transfer-Encoding: Informa como o corpo da mensagem está codificado para a

transmissão de uma rede que possa fazer alguma objeção a caracteres que não sejam

letras, número e outros sinais de pontuação. Este é o cabeçalho mais interessante, pois ele

especifica a natureza do corpo da mensagem. Na RFC 2045 são definidos 7 tipos e cada

um deles possui um ou mais subtipos. Os tipos e seus respectivos subtipos são ilustrados

na tabela 8.

Tabela 8 - Tipos e subtipos MIME definidos na RFC 2045

Tipo Subtipo Descrição

Plain Texto sem formatação Text

Enriched Texto incluindo comandos simples de formatação

Gif Fotografia no formato GIF Image

Jpeg Fotografia no formato JPEG

Audio Basic Som audível

Vídeo Mpeg Filme no formato MPEG

Octet-stream Uma seqüência de bytes não-interpretada Application

PostScript Um documento que pode ser impresso em PostScript

Rfc822 Uma mensagem no formato MIME RFC822

Partial A mensagem foi dividida para transmissão Message

External-body A mensagem deve ser obtida através da rede

Mixed Partes independentes na ordem especificada

Alternative A mesma mensagem em diferentes formatos

Parallel As partes devem ser vistas simultaneamente Multipart

Digest Cada parte é uma mensagem RFC822 completa

Fonte: Tanenbaum (2003, p 638).

3.3 RECEBIMENTO DE MENSAGENS DE CORREIO ELETRÔNICO

“Normalmente, quando é acionado, um agente do usuário verifica a caixa de correio do

usuário em busca de mensagens recebidas antes de exibir algo na tela. Em seguida, ele pode

69

anunciar o número de mensagens contidas na caixa de correio ou exibir um resumo de uma

linha de cada uma delas e aguardar um comando.” (TANENBAUM, 2003, p 631).

Este modelo funcionou bem durante décadas, quando todos os hosts da antiga ARPANET

(atualmente Internet) estavam on-line todo o tempo podendo aceitar conexões.

(TANENBAUM, 2003). Com o crescimento do número de pessoas que acessam a Internet por

meio de um provedor, este modelo não é válido. Para solucionar o problema de entrega de

mensagens de correio eletrônico aos usuários off-line, os provedores de Internet devem

possuir máquinas capazes de aceitar mensagens de correio eletrônico para seus clientes, e

armazená-las em suas respectivas caixas de correio na própria máquina do provedor. Desta

forma as mensagens de correio eletrônico podem ser enviadas 24 horas por dia.

(TANENBAUM, 2003).

Esta solução provocou um novo problema: como o usuário conseguirá acessar sua caixa de

correio no servidor do provedor? A solução para este problema foi a criação de dois

protocolos que permitem aos usuários acesso às suas caixas de correio. O primeiro é o POP3 e

o segundo é o IMAP.

3.3.1 POP3

Segundo Tanenbaum (2003), o protocolo POP3 (Post Office Protocol Version 3) é descrito na

RFC 1939. Ele é inicializado quando o usuário inicia o leitor de correio. O leitor de correio

por sua vez, verifica se já há uma conexão TCP estabelecida com o servidor POP3 do

servidor. Caso não haja, ele estabelece esta conexão através da porta 110. Depois da conexão

estabelecida o protocolo executa três passos em seqüência:

1. Autorização: efetua o login do usuário.

2. Transações: coleta as mensagens de correio eletrônico do usuário e marca as mensagens

para exclusão da caixa de correio do servidor.

3. Atualização: exclui as mensagens do servidor.

O protocolo POP3 admite deixar as mensagens na caixa de correio do servidor, porém a

maioria dos programas de correio eletrônico acabam removendo todas as mensagens,

deixando apenas uma cópia no disco rígido do usuário. Isto provoca um problema de

segurança, pois se o disco rígido do usuário der pane todas as suas mensagens serão perdidas.

Outro inconveniente do POP3 é o fato do usuário poder acessar sua conta de correio de vários

70

micros diferentes, o que provocará o espalhamento de suas mensagens pelos diversos micros

utilizados. (TANENBAUM, 2003).

3.3.2 IMAP

O IMAP (Internet Message Access Protocol) definido na RFC 2060, pressupõe que todas as

mensagens de correio eletrônico permanecerão no servidor indefinidamente em várias caixas

de correio. Diferente do POP3 que supõe que o usuário limpará a caixa de correio há cada

contato, e trabalhará off-line depois disso. (TANENBAU, 2003). Tanenbaum (2003) também

diz que, o IMAP oferece vários recursos entre eles estão:

• Mecanismos extensos para leitura de mensagens ou parte de mensagens: útil quando está

se utilizando um modem lento para ler uma parte de uma mensagem de várias partes com

grandes anexos de áudio e vídeo.

• Mecanismos de criação, destruição e manipulação de caixas de correio no servidor: um

usuário pode manter uma caixa de correio para cada correspondente, e mover as

mensagens da caixa de entrada para estas caixas depois que as mensagens forem lidas.

• Mecanismos de endereçamento de correspondência por qualquer atributo da mensagem.

Exceto pela existência de dezenas de comandos e de se estabelecer TCP na porta 143, o

IMAP de modo geral é semelhante ao POP3. Todavia, nem todos os provedores e

programas de correio eletrônico aceitam os dois protocolos. Deste modo o usuário deverá

escolher o programa de correio eletrônico que tenha suporte ao protocolo usado pelo seu

provedor. (TANENBAU, 2003).

71

4 PROTÓTIPO DO SISTEMA

A partir da revisão bibliográfica realizada neste trabalho, percebe-se um grande mercado com

usuários em potencial de aplicações destinadas aos dispositivos móveis e as diversas

tecnologias existentes para o desenvolvimento dessas soluções. O protótipo desenvolvido

neste trabalho é um exemplo de solução que permite explorar a mobilidade oferecida pelos

telefones celulares e ao mesmo tempo permitir um uso mais profissional e sofisticado desses

dispositivos.

Este protótipo é um sistema composto por dois módulos, um módulo cliente desenvolvido

usando a tecnologia J2ME e construído para ser executado em um telefone celular utilizando

a configuração CLDC (Connected Limited Device Configuration) e o perfil MIDP (Mobile

Information Device Profile), e um módulo servidor desenvolvido utilizando Servlets. O

módulo cliente realiza requisições utilizando protocolo HTTP e estas são recebidas pelo

módulo servidor por meio de uma Servlet principal que direciona as requisições para as

Servlets de ação específica, as quais atendem as requisições. Os tipos de requisições feitas

pela aplicação cliente estão: efetuar login, listar e navegar em diretórios e enviar mensagem

de correio eletrônico.

No desenvolvimento do sistema foi utilizada a ferramenta NetBeans 4.1, uma IDE Java

freeware, e seu pacote adicional NetBeans Mobility Pack 4.1 que permite o desenvolvimento

de aplicações J2ME de forma integrada e fácil construção de interfaces gráficas. Pelo fato do

sistema estar divido em dois módulos, adotou-se como estratégia para o desenvolvimento do

sistema a modelagem, implementação e testes isolados do módulo servidor e após o seu

término foi realizada a modelagem, implementação e testes integrados do módulo cliente.

A seguir é apresentada a arquitetura, modelagem, modelo de ciclo de vida utilizado no

desenvolvimento e utilização do sistema.

72

4.1 ARQUITETURA DO SISTEMA

A arquitetura do sistema é composta pelo dispositivo móvel, a estação rádio base (BTS), a

rede de dados móvel (GPRS), um servidor de aplicação e arquivos, um servidor SMTP e a

rede Internet, como mostrado na figura 14.

Figura 14 - Arquitetura do sistema

No dispositivo móvel é executado o módulo cliente do sistema, onde o usuário efetua seu

login e pode realizar o envio de e-mails e anexar aos e-mails os arquivos disponíveis no

servidor de arquivos. A BTS recebe os dados do dispositivo móvel e encaminha para a rede

GPRS. O primeiro gateway GPRS, converte os dados enviados pelo dispositivo móvel na

forma de comutação de circuito para comutação por pacotes e encaminha os dados para a rede

GPRS. O segundo gateway GPRS, realiza a conversão dos pacotes GPRS para pacotes IP e os

envia para a Internet. Se o servidor de aplicação estiver acessível pela Internet, o módulo

servidor poderá atender diretamente as requisições feitas pelo módulo cliente. Caso o servidor

de aplicação esteja acessível apenas na Intranet, o acesso pela Internet poderá ser feito por

meio de uma VPN, e assim acessar a Intranet. O servidor de aplicação então executa o

módulo servidor que por sua vez atende as requisições do módulo cliente e serve de

repositório de arquivos. O servidor SMTP é responsável por realizar o envio das mensagens

de correio eletrônico solicitado pelo módulo cliente. O protocolo de comunicação utilizado

entre os módulos do sistema foi o HTTP.

73

O sistema foi projetado e desenvolvido utilizando o padrão MVC (Model-View-Controller), e

é composto pelos módulos cliente executado no dispositivo móvel e pelo módulo servidor

sendo executado em um servidor. Toda camada de visão (view) e uma parte da camada de

controle (controller) e modelo (model) estão no módulo cliente. O restante da camada de

controle e de modelo estão no módulo servidor. No módulo cliente a persistência foi

implementada utilizando o RMS (Record Management System), sistema de gerenciamento de

registros que permite implementar persistência dentro do perfil MIDP. Foi criado um

JavaBean especializado em manipular os registros RMS, visando abstrair essa complexidade.

Com o intuito simplificar o protótipo, o módulo servidor teve sua persistência implementada

por meio de arquivos de perfil, onde para cada usuário é criado um arquivo de perfil contendo

as informações pertinentes a cada um deles, dispensando assim a instalação e configuração de

um sistema de gerência de banco de dados para o armazenamento dessas informações no

servidor. Entretanto, prevendo uma possível alteração na forma de armazenamento desses

dados, foi criado um JavaBean que manipula os arquivos de perfil, e que com simples

alterações em sua implementação ele poderá manipular essas informações seja qual for a

forma de armazenamento e sem implicar em alterações na aplicação. A arquitetura do sistema

também está ilustrada na figura 15 sob a forma de um diagrama UML de implantação.

Figura 15 - Diagrama de implantação

74

No diagrama de implantação fica clara a dependência que o módulo cliente tem da máquina

virtual Java (KVM), ou seja, esse módulo só poderá ser executado em dispositivos com

suporte a aplicações Java. Já o módulo servidor é dependente de um container Servlet,

exemplificado nesse caso com TOMCAT9 Servlet Container. A interface entre os módulos

cliente e servidor é feita por meio do protocolo HTTP e entre o módulo servidor e o servidor

SMTP é utilizado o protocolo SMTP.

4.1.1 Formato das requisições e respostas HTTP

O protótipo foi modelado e implementado utilizando como protocolo de comunicação o

HTTP, pois segundo Muchow (2004) o HTTP é o único protocolo que é exigido no perfil

MIDP 2.0, garantindo assim a portabilidade da aplicação para todos os dispositivos que

suportam esse perfil. Para protocolos como UDP e TCP não há garantia de que estejam

disponíveis em todos os dispositivos pertencentes ao perfil MIDP.

As requisições podem ser realizadas utilizando o método POST10 ou método GET11. As

resposta enviadas pela aplicação servidora são textuais compostas por vários campos tem

como caracter delimitador de campo, o caracter pipe ‘ | ‘. Todas as requisições são feitas à

aplicação servidora por meio de um controlador de requisições HTTP, que implementa a

interface Runnable12 e que possui um método execute que recebe como parâmetro um atributo

acao que é do tipo Acao. A classe Acao por sua vez é abstrata, devendo ser especializada de

acordo com a ação que se deseja executar na aplicação servidora. Maiores detalhes dessas

classes serão encontrados na seção 4.3. As tabelas 9, 10 e 11 ilustram o formato de requisição

e resposta das ações efetuar login, listar diretórios e arquivos e enviar mensagem de correio

eletrônico respectivamente.

9 Integrante do projeto Jakarta da fundação Apache.

10 O método POST é o inverso do GET, que ao invés de ler grava a página, anexando os novos dados aos dados

existentes. (TANENBAUM, 2003).

11 O método GET solicita ao servidor que envie a página, e esta é codificada em MIME de forma adequada.

(TANENBAUM, 2003).

12 Interface JAVA utilizada para implementação de threads, por meio da implementação do método run.

(DEITEL, DEITEL, 2005).

75

Tabela 9 - Formato da requisição e resposta para a ação efetuar login

Nome da requisição

Efetuar login

Métodos

GET / POST

Parâmetro Valor

acao login

usuario <id do usuário>

senha <senha do usuário>

Resposta

Campo Valor

status OK / ERRO

caracter delimitador de campo pipe “ | ”

mensagem <mensagem de sucesso ou erro>

Tabela 10 - Formato da requisição e resposta para a ação navegar e listar diretórios / arquivos


Navegar e listar diretórios / arquivos

Métodos

GET / POST

Parâmetro Valor

acao listFolder

diretorio (opcional) <diretório a ser acessado e listado>

Resposta

Campo Valor

status OK / ERRO


mensagem <mensagem de erro / lista de arquivos e diretórios >

76

O parâmetro diretório é opcional e caso ele não seja enviado, a aplicação servidora acessará o

diretório que está configurado no arquivo de perfil como diretório raiz do usuário em questão.

Já o campo mensagem nesse caso poderá conter uma mensagem de erro ou a listagem dos

arquivos e diretórios. Quando for a listagem de diretório, o campo status irá conter a string

“OK” e o campo mensagem terá diversos campos separados pelo caracter pipe, que por sua

vez terão subcampos separados pelo caracter sustenido ‘ # ‘. Estes subcampos referem-se a

alguns atributos dos arquivos, como por exemplo, se é um arquivo ou diretório, data da última

modificação e tamanho em bytes.

Tabela 11 - Formato da requisição e resposta para a ação enviar mensagem de correio eletrônico


Enviar mensagem de correio eletrônico

Métodos

GET / POST

Parâmetro Valor

acao sendMsg

remetente <endereço de correio eletrônico do remetente>

assunto <assunto da mensagem de correio eletrônico>

destinatarios <endereço de correio eletrônico dos destinatários>

destinatariosCC <endereço de correio eletrônico dos destinatários cópia carbono>

destinatariosBCC <endereço de correio eletrônico dos destinatários cópia oculta>

corpoMensagem <Conteúdo da mensagem de correio>

anexo <nome do arquivo a ser anexado>

Resposta

Campo Valor

status OK / ERRO


mensagem <mensagem de sucesso ou de erro>

77

O parâmetro remetente é enviado como sendo a identificação do usuário utilizada para

estabelecer o login, acrescida do domínio mobilemail.com.br. Se o parâmetro assunto não for

preenchido na interface de envio de mensagem, o sistema colocará a string “No subject” como

valor deste parâmetro. Os parâmetros destinatarios, destinatariosCC e destinatariosBCC

podem ser um único endereço de e-mail ou uma lista de vários endereços separados por

vírgula ou ponto e vírgula. A mensagem deve ser destinada a pelo menos um destinatário,

caso contrário a aplicação servidora não realizará o envio da mensagem e será gerada uma

exceção. O parâmetro corpoMensagem é opcional assim como o parâmetro anexo. Entretanto,

caso seja selecionado mais de um arquivo para ser anexado à mensagem de correio, existirão

vários parâmetros anexo, cada um contendo o nome de um dos arquivos a ser anexado.

4.2 FUNCIONAMENTO DO SISTEMA

Nessa sessão serão apresentados os passos para a utilização do sistema. Primeiramente, o

módulo servidor deverá estar instalado em um servidor de arquivos ou até mesmo na estação

de trabalho do usuário, facilitando assim o acesso aos seus documentos pessoais. O módulo

servidor deverá estar acessível pela Internet ou até mesmo numa Intranet que possa ser

acessada via Internet por meio de uma VPN (Virtual Private Network). Estando instalado o

módulo servidor, o usuário deve possuir um telefone celular com suporte a aplicativos Java e

realizar a instalação do módulo cliente. Para realizar a instalação deste módulo, o usuário

deverá consultar o manual do seu dispositivo móvel e executar os procedimentos de instalação

de novos aplicativos.

Depois de instalado, o módulo cliente deverá estar acessível no menu aplicativos do

dispositivo móvel. Localizado o módulo cliente, ele deve ser selecionado para que seja

executado. A figura 16 ilustra a tela de entrada do módulo cliente.

Os usuários deverão estar devidamente configurados para que possam utilizar o serviço, pois

eles necessitam se autenticar no serviço para que possam utilizá-lo. O próximo passo é efetuar

seu login acessando a opção efetuar login disponível na tela principal, como mostra a figura

17.

78

Figura 16 - Tela de abertura do módulo cliente

Figura 17 - Tela principal do módulo cliente

79

Figura 18 - Tela de login do módulo cliente

Tendo efetuado o login com sucesso, o sistema exibirá uma mensagem de login efetuado com

sucesso e retornará para a tela principal. O usuário então deverá acessar a opção enviar

mensagem para que ele possa informar os endereços de destino, assunto, editar a mensagem e

caso seja de seu desejo, selecionar os arquivos a serem anexados à mensagem. A figura 19

mostra a tela de envio de mensagens e as opções de menu disponíveis para enviar, editar e

anexar arquivo à mensagem.

Se selecionada a opção anexar arquivos, o servidor então listará primeiramente o diretório

configurado como diretório raiz do usuário, e a partir daí ele poderá navegar por todos os seus

subdiretórios. A figura 20 mostra o indicador de progresso do processo de listagem de

diretórios.

Ao finalizar a consulta ao conteúdo do diretório do usuário, seu conteúdo é exibido como

mostra a figura 21, onde os diretórios são representados por seus nomes e a figura de uma

pasta. Já os arquivos são representados por seus nomes, data da última modificação e o

tamanho em bytes. Após a seleção dos arquivos o usuário deve selecionar o comando voltar

para retornar a tela de envio de mensagens e por fim realizar o envio da mensagem, acessando

o comando menu, opção enviar mensagem.

80

Figura 19 - Tela de envio de mensagens

Figura 20 - Tela de progresso de ações no servidor

81

Figura 21 - Listagem do conteúdo de um diretório

4.3 MODELAGEM DO SISTEMA

O sistema foi modelado usando UML com o apoio da ferramenta Visual Paradigm for UML

5.0 e foram gerados os diagramas de caso de uso, diagramas de classe e diagramas de

seqüência.

4.3.1 Requisitos funcionais e não funcionais

A tabela 12 apresenta os requisitos funcionais do sistema.

Tabela 12 - Requisitos funcionais

Identificador Função Descrição Casos de uso

RF 001 Autenticação de usuários

Realizar login do usuário no sistema

permitindo assim acesso apenas às suas

configurações, oferecendo segurança e

privacidade aos usuários.

USC 001

RF 002 Listar e acessar diretórios Listar o diretório raiz do usuário e

permitir acessar e listar seus subdiretórios USC 002

82

RF 003 Envio de e-mail

Compor e enviar mensagens de correio

eletrônico, permitindo a multiseleção de

arquivos para serem anexados às

mensagens.

USC 002

USC 003

A tabela 13 apresenta os requisitos não funcionais do sistema.

Tabela 13 - Requisitos não funcionais

Identificação Descrição

RNF 001 Módulo cliente deverá ser executado em um telefone celular

RNF 002 Módulo cliente deverá ser implementado utilizando tecnologia J2ME

4.3.2 Diagramas UML módulo servidor

4.3.2.1 Diagramas de casos de uso

A seguir são apresentados os diagramas de caso de uso do módulo servidor e seus respectivos

detalhamentos.

Figura 22 – Diagrama de caso de uso (USC 001 – Valida login)

Tabela 14 - Detalhamento do caso de uso USC 001

Nome do caso de

uso Valida login

Caso de uso geral

Ator principal Aplicação cliente

Atores secundários

Resumo Autentica o usuário por meio do recebimento do ID do usuário e sua respectiva senha.

83

(RF 001).

Pré-condições

Pós-condições Usuário logado

Ações do ator Ações do sistema

1. Envia usuário e senha

2. Valida usuário e senha

3. Registra usuário na sessão Fluxo base

4. Envia para a aplicação cliente a

mensagem de login efetuado com sucesso

Fluxo de exceção 1. Se ocorrer uma exceção, enviar

mensagem de erro.

Figura 23 – Diagrama de caso de uso (USC 002 – Lista diretório do usuário)


Nome do caso de

uso Lista diretório do usuário

Caso de uso geral


Atores secundários

Resumo

Lista os diretórios pertencentes ao usuário logado, para que o mesmo possa selecionar

os arquivos que deseja enviar anexados à mensagem de correio eletrônico. (RF 002,

RF 003).

Pré-condições Usuário logado

Pós-condições Anexos selecionados para envio


1. Solicita a listagem do diretório

desejado

2. Verifica se o usuário está logado

Fluxo base

3. lista o diretório desejado


84

mensagem de erro.

Figura 24 - Diagrama de caso de uso (USC 003 - Envia mensagem de correio eletrônico)


Nome do caso de

uso Envia mensagem de correio eletrônico

Caso de uso geral


Atores secundários

Resumo Envia mensagem de correio eletrônico contendo ou não anexos.


Pós-condições Mensagem de correio eletrônico enviada


1. Solicita o envio da mensagem de

correio eletrônico passando os

endereços dos destinatários, assunto,

corpo da mensagem e anexos caso

tenha.

2. Se for solicitado o envio com anexo,

anexa os arquivos selecionados

3. Envia mensagem de correio eletrônico

Fluxo base


mensagem de e-mail enviado com sucesso


mensagem de erro.

85

4.3.2.2 Diagramas de classes

Os diagramas de classe foram divididos por pacote de acordo com as funcionalidades das

classes e são mostrados a seguir.

Figura 25 - Diagrama de classes do pacote controle

Figura 26 - Diagrama de classe do pacote bean

86

Figura 27 - Diagrama de classes do pacote entidade

4.3.2.3 Diagramas de seqüência

Figura 28 - Diagrama de seqüência da validação de login

87

Figura 29 - Diagrama de seqüência da listagem de diretórios do usuário

Figura 30 - Diagrama de seqüência do envio de mensagem

88

4.3.3 Diagramas UML módulo cliente

4.3.3.1 Diagrama de casos de uso

Figura 31 - Diagrama de casos de uso módulo cliente

Tabela 17- Detalhamento do caso de uso efetua login

Nome do caso de

uso Efetua login

Caso de uso geral

Ator principal Usuário

Atores secundários Aplicação servidora

Resumo Efetua o login do usuário no sistema.

Pré-condições

Pós-condições Usuário logado


1. Usuário informa ID e a senha e

solicita a realização de login

2. Se conecta na aplicação servidora e envia

o pedido de login, usuário e senha.

3. Aplicação servidora valida o login

4. Aplicação servidora envia para a

aplicação cliente a mensagem de login

bem sucedido.

Fluxo base

5. Exibe mensagem de login bem sucedido

Fluxo de exceção 1. Envia para a aplicação cliente a

mensagem do erro ocorrido

89

2. Se ocorrer interrupção da conexão com a

rede, exibe mensagem de erro.

Tabela 18 - Detalhamento do caso de uso navega no diretório e seleciona arquivos

Nome do caso de

uso Navega no diretório e seleciona arquivos

Caso de uso geral



Resumo Lista o conteúdo do diretório remoto do usuário e permite a seleção dos arquivos a

serem anexados às mensagens de correio eletrônico


Pós-condições Anexos selecionados


1. Envia para a aplicação servidora o

comando para listar o diretório raiz do

usuário.

2. Aplicação servidora lista o diretório

desejado.

3. Exibe o conteúdo do diretório escolhido

4. Usuário escolhe o arquivo ou

diretório desejado

5. Se for selecionado um diretório repete-se

o passo de 1 só que para o diretório

selecionado e depois os passos 2 a 4. Se for

um arquivo, seu nome é armazenado na

hashtable de anexos.

Fluxo base

6. Usuário seleciona o comando voltar



Fluxo de exceção



Tabela 19 - Detalhamento do caso de uso envia mensagem

Nome do caso de

uso Envia mensagem

90

Caso de uso geral



Resumo Envia mensagem de correio eletrônico com ou sem anexos.


Pós-condições Mensagem enviada


1. Usuário solicita o envio da

mensagem

2. Envia para a aplicação servidora o

comando e os parâmetros para o envio da

mensagem de correio eletrônico

Fluxo base

3. Envia a mensagem de correio

eletrônico.



Fluxo exceção



4.3.3.2 Diagramas de classes

Da mesma forma que no módulo servidor, os diagramas de classes foram organizados em

pacotes de acordo com a funcionalidade das classes. A implementação dos listeners de

comando foi modelada utilizando o conceito de classe interna, uma vez que suas

implementações são de uso específico para a captura e execução de um evento. A classe

principal e o controlador de conexão HTTP implementam a interface Runnable.

91

Figura 32- Diagrama de classes do pacote controle do módulo cliente

Figura 33 - Diagrama de classes do pacote visao do módulo cliente

92

Figura 34 - Diagrama de classes do pacote entidade do módulo cliente

Figura 35 - Diagrama de classes do pacote bean do módulo cliente

Foi desenvolvida para uso nesse protótipo uma biblioteca de classes especializadas em

conexões HTTP e manipulação de registro RMS, as quais poderão ser reutilizadas em quais

desenvolvimentos em J2ME que necessitem de tais funcionalidades. O diagrama de classes

dessa biblioteca é apresentado a seguir.

Figura 36 - Diagrama de classes da biblioteca mobileLib

93

4.3.3.3 Diagramas de seqüência

Figura 37 - Diagrama de seqüência para efetuar login do módulo cliente

Figura 38 - Diagrama de seqüência da listagem e seleção de arquivos do módulo cliente

94

Figura 39 - Diagrama de seqüência envio da mensagem de correio eletrônico do módulo cliente

4.4 MODELO DE CICLO DE VIDA

Foi utilizado o modelo de ciclo de vida incremental em função das vantagens oferecidas por

esse modelo, como por exemplo:

• Identificação de risco é adiantada (MASSONI, 1999);

• Integração contínua facilitando os testes e aprendizado (MASSONI, 1999);

• Preparação do sistema para os requisitos que mudam; (MASSONI, 1999).

4.5 CONSIDERAÇÕES FINAIS

Neste capítulo foi possível apresentar o protótipo de um serviço de e-mail para telefones

celulares, que permite além do envio de mensagens de texto, anexar às mensagens quaisquer

tipos de arquivos que estejam em um servidor de arquivos ou numa estação de trabalho em

uma rede fixa. Este tipo de serviço pode proporcionar aos usuários da telefonia móvel um

serviço diferenciado de correio eletrônico, que até o momento ainda não é oferecido pelas

operadoras de telefonia móvel. No Brasil, a operadora VIVO possui um serviço também

chamado de mobile mail, porém apenas é permitido acessar contas de e-mail pelo celular.

95

Isso comprova que muitos outros tipos de serviços ainda podem ser oferecidos a esse grande

mercado, gerando assim negócios lucrativos para os usuários, desenvolvedores e operadoras

de telefonia móvel. É preciso apenas um pouco de criatividade para lidar com as limitações

dos dispositivos e oferecer soluções que tornem os telefones celulares ferramentas para

soluções de voz e dados.

96

5 CONCLUSÃO E TRABALHOS FUTUROS

5.1 CONCLUSÃO

Este trabalho apresentou como objetivo geral a utilização da tecnologia J2ME para acesso ao

serviço de correio eletrônico. Este objetivo foi atingido com a construção de um sistema

composto por dois módulos, um módulo cliente usando realmente J2ME, mas necessitou da

criação de um módulo servidor implementado usando a tecnologia J2EE para poder prover

acesso aos arquivos remotos dos usuários e enviar as mensagens de correio eletrônico

anexando esses arquivos.

Com esse sistema, os usuários podem fazer uso de um serviço de e-mail que lhe permite

enviar mensagens de texto, acrescentar quaisquer tipos de anexos suportados pelo padrão

MIME e desfrutar da mobilidade oferecida pela rede celular. Com isso consegui-se alcançar o

primeiro objetivo específico, que era explorar a mobilidade oferecida pelos celulares, fazendo

uso dos recursos disponíveis nesses dispositivos e na tecnologia J2ME.

Para a construção do módulo cliente, foi necessário um aprendizado da API do J2ME. Isto foi

feito por meio de uma revisão bibliográfica, cuja parte dela foi apresentada no capítulo 2

desse trabalho. Além do que foi apresentado no capítulo 2, fez-se necessário o estudo de

alguns exemplos de implementações em J2ME, para entender como são construídas as

aplicações Midlets e as interfaces gráficas.

O desenvolvimento de uma aplicação J2ME que permitisse acessar um servidor e solicitar a

listagem do conteúdo de um diretório, selecionar um ou mais arquivos para serem anexados à

mensagem de correio eletrônico e de uma aplicação Java ou Servlet/ JSP para atender as

requisições da aplicação J2ME foram alcançados conforme o que foi exposto no capítulo 4.

Portanto, conclui-se que este trabalho teve seus objetivos alcançados.

97

O protótipo desenvolvido neste trabalho mostrou-se com potencial comercial, porém é

necessário acrescentar outras funcionalidades ao sistema, como por exemplo, poder não

apenas enviar mensagens, mas acessar sua caixa de entrada de correio, utilizar o protocolo

HTTPS para torná-lo mais seguro, criação de catálogos de endereço, busca de contatos no

catálogo, etc. Outro passo importante é disponibilizar o acesso ao módulo servidor na

Internet. Esse acesso pode ser oferecido pela própria operadora de telefonia móvel, destinando

um servidor na sua rede de dados para servir a aplicação e os arquivos, ou por uma empresa

que deseja ter um serviço de correio eletrônico móvel (m-mail) na sua empresa e disponibiliza

acesso ao servidor de aplicação e arquivos na Internet ou na Intranet utilizando VPN. A

solução partindo da operadora, poderá ter uma abrangência maior, pois todos os clientes que

desejarem ter acesso a esse serviço poderão tê-lo, desde que seus telefones celulares suportem

aplicações Java.

Pode-se concluir também a partir dos dados apresentados neste trabalho, que o mercado de

telefonia móvel é muito promissor por seu tamanho e também pela forte tendência da

mobilidade. Novos serviços podem ser oferecidos a esse mercado, sejam soluções

corporativas ou pessoais, podendo gerar bons negócios para os desenvolvedores, usuários e

operadoras de telefonia móvel. Os desenvolvedores precisam avaliar as tecnologias existentes

para desenvolvimento de aplicações móveis e escolher a que lhe parecer mais adequada. A

criatividade também será de grande importância para os desenvolvedores poderem oferecer

serviços atrativos aos usuários e às operadoras.

Com a evolução tecnológica das redes móveis, dos dispositivos e das plataformas de

desenvolvimento de software para dispositivos móveis, a tendência é que haja mais recursos

disponíveis em todas essas áreas de forma a proporcionar soluções ainda mais sofisticadas e

com alto valor agregado para os usuários dessas soluções.

As principais dificuldades encontradas no desenvolvimento do protótipo foram o aprendizado

do J2ME, as limitações de interface gráfica apresentada pelos dispositivos e falta de alguns

recursos que não estão presentes na API do J2ME e que tiveram que ser implementados no

protótipo, como por exemplo, a classe StringTokenizer e o método replace da classe String.

Mas essas dificuldades foram facilmente contornadas com o estudo da linguagem, utilização

de ferramentas integradas para o desenvolvimento de aplicações J2ME, criatividade para lidar

com a limitação da interface gráfica e com a construção de algoritmos para suprir a ausência

de funcionalidades na API do J2ME, que apesar de reduzida se comparada com a API da

98

versão J2SE, mostra-se muito poderosa se comparada com outras tecnologias para

desenvolvimento de aplicações para dispositivos móveis.

5.2 TRABALHOS FUTUROS

A partir do que foi desenvolvido neste trabalho, pode-se sugerir como trabalhos futuros as

seguintes idéias:

• Tornar a aplicação um serviço de correio eletrônico completo, com envio e

recebimento de mensagens, catálogos de endereços, modelos de mensagens, etc;

• Outros serviços de rede para celulares, como por exemplo, gerenciadores de arquivos,

clientes FTP, telnet, mensagens instantâneas;

• Visualizadores de arquivos remotos (.doc, .xls, .pdf, .zip);

• Serviços bancários, controles de estoque, controle de pedidos, jogos multi player,

agendas sofisticadas.

99

6 REFERÊNCIAS BIBLIOGRÁFICAS

AGÊNCIA NACIONAL DE TELECOMUNICAÇÕES, Anatel. Dados de acessos móveis em operação e densidade, por unidade da federação, do serviço móvel pessoal. Distrito Federal, 2005a. Disponível em: <http://www.anatel.gov.br/Tools/frame.asp?link=/comunicacao_movel/smc/smc_smp_dados_por_uf.pdf> Acesso em: 26 maio 2005.

______. Participação do mercado no serviço móvel pessoal. Distrito Federal, 2005b. Disponível em: <http://www.anatel.gov.br/Tools/frame.asp?link=/comunicacao_movel/smp/participacao_smp_mercado.pdf> Acesso em: 26 maio 2005.

AREHART, Charles et al. Professional WAP. Tradutor: João Eduardo Nóbrega Tortello. São Paulo: Makron Books, 2001. 774p. ISBN 85-346-1313-3.

BORENSTEIN, N.; FREED, N. RFC 1341: MIME - multipurpose internet mail extensions. [S.I], 1992. Disponível em: <http://www.ietf.org/rfc/rfc1341.txt> Acesso em: 10 junho 2005.

______. RFC 1521: MIME - multipurpose internet mail extensions - part one. [S.I], 1993. Disponível em: <http://www.ietf.org/rfc/rfc1521.txt> Acesso em: 10 junho 2005.

______. RFC 2045: MIME - multipurpose internet mail extensions - part one. [S.I], 1996. Disponível em: <http://www.ietf.org/rfc/rfc2045.txt> Acesso em: 10 junho 2005.

CROCKER, David H. RFC 822: standard for the format of ARPA internet text messages. [S.I], 1982. Disponível em: <http://www.ietf.org/rfc/rfc0822.txt> Acesso em: 10 junho 2005.

DEITEL, Harvey M; DEITEL, Paul J. JAVA: Como programar. 6º ed. Tradutor: Edson Furmankiewicz. São Paulo: Person Education do Brasil, 2005. 1110p. ISBN 85-7605-019-6.

DORNAN, Andy. Wireless communication: o guia essencial de comunicação sem fio. Tradutor: Fábio Freitas. Rio de Janeiro: Campus, 2001. 304p. ISBN 85-352-0749-X.

FEIT, Sidnie. TCP/IP: architecture, protocols, and implementation. Singapura: McGraw-Hill Inc., 1993. 466p. ISBN 0-07-020346-6.

GASPARINI, Anteu F. L.; BARRELA, Francisco E. TCP/IP: solução para conectividade. 3.ed. São Paulo: Érica, 1993. 309p. ISBN 85-7194-183-1.

100

HADDAD, Renato. Entendendo aplicações móveis no .NET. [S.I], 2005. Disponível em: <http://www.microsoft.com/brasil/msdn/tecnologias/movel/mobilidade_entendendo.aspx> Acesso em: 05 junho 2005.

KALAKOTA, Ravi; ROBINSON, Marcia. M-business: tecnologia móvel e estratégia de negócios. Tradutor:Maria Adelaide Carpigiani. Porto Alegre: Bookman, 2002. 249p. ISBN 85-7307-975-4.

KLENSIN, J. RFC 2821: simple mail transfer protocol. [S.I], 2001. Disponível em: <http://www.ietf.org/rfc/rfc2821.txt> Acesso em: 10 junho 2005.

KLENSIN, J. et al. RFC 1869: SMTP Service Extensions. [S.I], 1995. Disponível em: <http://www.ietf.org/rfc/rfc1869.txt> Acesso em: 10 junho 2005.

MASSONI, Tiago L. Introdução ao processo unificado de desenvolvimento de software. [S.I], 1999. Disponível em <http://www.cin.ufpe.br/~phmb/RUP/MaterialDeEnsino/VisaoGeralDoCurso.ppt> Acesso em: 29/10/2005.

MOORE, K. RFC 1522: MIME - multipurpose internet mail extensions - part two. [S.I], 1993. Disponível em: <http://www.ietf.org/rfc/rfc1522.txt> Acesso em: 10 junho 2005.

MUCHOW, John W. Core J2ME: Tecnologia & MIDP. Tradutor: João Eduardo Nóbrega Tortello. São Paulo: Pearson Makron Books, 2004. 588p. ISBN 85-346-1522-5.

PARTRIDGE, Craig. RFC 974: mail routing and the domain system. [S.I], 1986. Disponível em: <http://www.ietf.org/rfc/rfc0974.txt> Acesso em: 10 junho 2005.

POSTEL, Jonathan B. RFC 821: simple mail transfer protocol. [S.I], 1982. Disponível em: <http://www.ietf.org/rfc/rfc0821.txt> Acesso em: 10 junho 2005.

______. RFC 1590: media type registration procedure. [S.I], 1994. Disponível em: <http://www.ietf.org/rfc/rfc1590.txt> Acesso em: 10 junho 2005.

QUALCOMM. A solução BREW. [S.I], 2005a. Disponível em: <http://brew.qualcomm.com/brew/pt/about/brew_solution.html> Acesso em: 05 junho 2005.

______. Ficção ou realidade?. [S.I], 2005b. Disponível em: <http://brew.qualcomm.com/brew/pt/about/fact_fiction.html> Acesso em: 05 junho 2005.

______. Maiores lucros na movimentação de dados sem fio. [S.I], 2002. Disponível em: <http://brew.qualcomm.com/brew/pt/img/about/pdf/brew_white_paper.pdf> Acesso em: 04 junho 2005.

______. O BREW hoje. [S.I], jun. 2005. Disponível em: <http://brew.qualcomm.com/brew/pt/about/brew_today.html> Acesso em: 05 junho 2005.

RESNICK, P. RFC 2822: internet message format. [S.I], 2001. Disponível em: <http://www.ietf.org/rfc/rfc2822.txt> Acesso em: 10 junho 2005.

101

SHARMA, Chetan. Aplicações comerciais da Internet sem fio. Tradutor: Mário Moro Fecchio. São Paulo: Makron Books, 2001. 285p. ISBN 85-346-1342-7

SUPERWABA. O que é o SuperWaba?. [S.I], 2005a. Disponível em: <http://www.superwaba.com.br/pt/overview.asp> Acesso em: 05 junho 2005.

SUPERWABA. Prospecto do SuperWaba. [S.I], 2005b. Disponível em: <http://www.superwaba.com.br/etc/SuperWabaFolderEnV2.pdf> Acesso em: 05 junho 2005.

TANENBAUM, Andrew S. Rede de computadores. 4.ed. Tradutor: Vandenberg D. de Souza. Rio de Janeiro: Campus, 2003. 945p. ISBN 85-352-1185-3.

VIVO. O que é o VIVODOWNLOADS?. [S.I], 2005. Disponível em: <http://www.vivo.com.br/vivodownloads/oque.html> Acesso em: 05 junho 2005.

102

ANEXOS

Anexo A – Código fonte módulo servidor

Anexo A.1 – Pacote bean

package bean; import java.io.File; /** * Java Bean para acessar diretórios e arquivos do usuário. */ public class BeanAcessoArquivo extends java.lang.Object { /** * Diretorio home do usuário */ private String homeDir = null; /** * Diretório atual. */ private String dirAtual = null; public BeanAcessoArquivo(String homeDir) { this.setDirAtual(homeDir); this.setHomeDir(homeDir); } public String getDirAtual() { return this.dirAtual; } public void setDirAtual(final String dirAtual) { this.dirAtual = dirAtual; } public String getHomeDir() { return this.homeDir; } public void setHomeDir(final String homeDir) { this.homeDir = homeDir; } public File[] listaDiretorio() throws Exception { File[] res = null; File f = new File(this.getDirAtual()); res = f.listFiles();

103

return res; } public boolean acessaDiretorio(String diretorio) throws Exception { boolean res = false; File f = new File(diretorio); res = f.exists(); if(res) this.setDirAtual(diretorio); return res; } } package bean; import entidade.MensagemCorreio; import java.io.IOException; import netutility.mail.Email; /** * Java Bean responsável pelo envio da mensagem de correio eletrônico. */ public class BeanEmail extends java.lang.Object { /** * Atributo é um objeto da classe especializada pelo envio da mensagem de correio. */ private Email email = new Email(); private String servidorSMTP = null; private String usuarioSMTP = null; private String senhaSMTP = null; public BeanEmail(String servidorSMTP) { } public BeanEmail() { } /** * Envia mensagem de correio eletrônico. */ public String enviaEmail(MensagemCorreio mensagem) throws Exception { String res = null; this.email.setSenha(this.getSenhaSMTP()); this.email.setUsuario(this.getUsuarioSMTP()); this.email.setServidorSMTP(this.getServidorSMTP()); if(email.sendMail(mensagem.getRemetente(), mensagem.getDestinatarios(), mensagem.getDestinatariosCC(), mensagem.getDestinatariosBCC(), mensagem.getAssunto(), mensagem.getCorpoMensagem(), mensagem.getAnexos())) res = new String("Envio realizado com sucesso!"); else throw new IOException(); return res; } public String getServidorSMTP() { return this.servidorSMTP; } public void setServidorSMTP(final String servidorSMTP) { this.servidorSMTP = servidorSMTP;

104

} public String getSenhaSMTP() { return this.senhaSMTP; } public void setSenhaSMTP(final String senhaSMTP) { this.senhaSMTP = senhaSMTP; } public String getUsuarioSMTP() { return this.usuarioSMTP; } public void setUsuarioSMTP(final String usuarioSMTP) { this.usuarioSMTP = usuarioSMTP; } } package bean; import entidade.Usuario; import java.io.File; import java.io.FileInputStream; import java.util.Properties; /** * Java Bean responsável pela validação de login. */ public class BeanLogin extends java.lang.Object { private String arquivoProfile = null; public BeanLogin(String arquivo){ this.arquivoProfile = arquivo; } public Usuario validaLogin(String usuario, String senha) throws Exception{ Usuario res = null; File f = new File(arquivoProfile); FileInputStream in = new FileInputStream(f); Properties profile = new Properties(); profile.load(in); if(profile.getProperty("senha").equals(senha)) { res = new Usuario(); res.setDiretorioRaiz(profile.getProperty("home_dir", System.getProperty("user.dir"))); res.setId(usuario); res.setSenha(senha); res.setEnderecoEmail(profile.getProperty("endereco_email", "[email protected]")); } return res; } }

Anexo A.2 – Pacote controle

/* * Controlador.java * * Created on 24 de Setembro de 2005, 02:09 */

105

package controle; import java.io.*; import javax.servlet.*; import javax.servlet.http.*; /** * * @author Rodrigo * @version */ public abstract class Controlador extends HttpServlet implements ControladorMobileEmail { // <editor-fold defaultstate="collapsed" desc="HttpServlet methods. Click on the + sign on the left to edit the code."> /** Handles the HTTP <code>GET</code> method. * @param request servlet request * @param response servlet response */ protected abstract void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException; /** Handles the HTTP <code>POST</code> method. * @param request servlet request * @param response servlet response */ protected abstract void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException; // </editor-fold> public abstract void processaRequisicao(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException; protected void enviaResposta(HttpServletRequest req, HttpServletResponse resp,String resposta) throws ServletException, IOException { resp.setContentType("text/plain"); PrintWriter out = resp.getWriter(); try { out.print(resposta); } finally { out.close(); } } } package controle; import bean.BeanAcessoArquivo; import controle.ControladorMobileEmail; import entidade.Usuario; import java.io.File; import java.io.IOException; import java.text.SimpleDateFormat; import javax.servlet.*; import javax.servlet.http.*; public class ControladorArquivo extends Controlador { /** Processa requisições do método POST*/ protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, java.io.IOException { this.processaRequisicao(req, resp); } /** Processa requisições do método GET */ protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, java.io.IOException {

106

this.processaRequisicao(req, resp); } /** Processa requisições */ public void processaRequisicao(HttpServletRequest req, HttpServletResponse resp) throws ServletException, java.io.IOException { String diretorio = req.getParameter("diretorio"); Usuario usuario = (Usuario)req.getSession().getAttribute("usuario"); String res = null; if(usuario == null) res = new String("ERRO|Usuario não está logado!"); else { if(diretorio == null) diretorio = usuario.getDiretorioRaiz(); try { res = new String("OK|" +System.getProperty("file.separator", "\\") + "|" + diretorio + "|" +this.navegaDiretorio(req,resp,diretorio)); } catch(Exception e) { this.log("Erro ao processar requisição no controlador de arquivo: " + e.getMessage(),e); res = new String("ERRO|Erro ao navegar no diretório do usuário: " + e.getMessage()); } } this.enviaResposta(req, resp, res); } private String navegaDiretorio(HttpServletRequest req, HttpServletResponse resp,String diretorio) throws Exception { BeanAcessoArquivo bean = new BeanAcessoArquivo(diretorio); Usuario usuario = (Usuario)req.getSession().getAttribute("usuario"); if(usuario != null) bean.setHomeDir(usuario.getDiretorioRaiz()); String res = null; if(bean.acessaDiretorio(diretorio)) { File[] listaDeArquivos = bean.listaDiretorio(); if(listaDeArquivos == null) throw new IOException(); else if(usuario.getDiretorioRaiz().equals(bean.getDirAtual())) res = new String(""); else res = new String(".#..#|"); res += this.formataVisualizacaoArquivos(listaDeArquivos); } else throw new IOException(); return res; } private void selecionaArquivos(java.lang.String[] arquivos) throws Exception { } private String formataVisualizacaoArquivos(java.io.File[] arquivos) { StringBuffer res = new StringBuffer(); for(int i=0; i < arquivos.length; i++) { if(arquivos[i].isDirectory()) res.append(".#"); else res.append("a#"); res.append(arquivos[i].getName() + "#"); if(arquivos[i].isFile()) { res.append(new SimpleDateFormat("dd/MM/yyyy HH:mm:ss").format(new java.util.Date(arquivos[i].lastModified())) + "#"); res.append(arquivos[i].length() + " bytes#"); } if(i < arquivos.length - 1) res.append("|"); } return res.toString();

107

} } package controle; import bean.BeanLogin; import controle.ControladorMobileEmail; import entidade.Usuario; import javax.servlet.*; import javax.servlet.http.*; import javax.servlet.http.HttpServlet; /** * Controlador responsável pela validação do login e registro do usuário na sessão. */ public class ControladorLogin extends Controlador { /** Processa requisições do método POST*/ protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, java.io.IOException { this.processaRequisicao(req, resp); } /** Processa requisições do método GET */ protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, java.io.IOException { this.processaRequisicao(req, resp); } /** Processa requisições */ public void processaRequisicao(HttpServletRequest req, HttpServletResponse resp) throws ServletException, java.io.IOException { String usuario = req.getParameter("usuario"); String senha = req.getParameter("senha"); String resposta = null; if(usuario == null || senha == null) resposta = new String("ERRO|Usuário e/ou senha nulos!"); else { Usuario u = this.validaLogin(usuario, senha); if(u == null) resposta = new String("ERRO|Usuário e/ou senha inválidos!"); else { if(req.getSession().isNew()) { String idSession = req.getSession().getId(); resp.setHeader("ID-Session", idSession); } req.getSession().setAttribute("usuario", u); resposta = new String("OK|Login efetuado com sucesso!"); } } this.enviaResposta(req, resp, resposta); } private synchronized Usuario validaLogin(String usuario, String senha) { Usuario res = null; String url = null; try { String arquivo = new String(this.getServletConfig().getInitParameter("profile_dir") + usuario + ".properties"); BeanLogin beanLogin = new BeanLogin(arquivo); res = beanLogin.validaLogin(usuario, senha); } catch(Exception e) { this.log("Erro ao validar login do usuário: " + e.getMessage(),e); res = null; } return res; } }

108

package controle; import bean.BeanEmail; import entidade.MensagemCorreio; import entidade.Usuario; import javax.servlet.*; import javax.servlet.http.*; public class ControladorMensagem extends Controlador { private String servidorSMTP = null; /** Processa requisições do método POST*/ protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, java.io.IOException { this.processaRequisicao(req, resp); } /** Processa requisições do método GET */ protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, java.io.IOException { this.processaRequisicao(req, resp); } /** Processa requisições */ public void processaRequisicao(HttpServletRequest req, HttpServletResponse resp) throws ServletException, java.io.IOException { Usuario usuario = (Usuario)req.getSession().getAttribute("usuario"); String res = null; this.servidorSMTP = this.getInitParameter("servidor_SMTP"); if(usuario == null) res = new String("ERRO|Usuario não está logado!"); else { try { res = "OK|" + this.enviaMensagem(usuario, this.montaMensagem(req,resp)); } catch(Exception e) { res = new String("ERRO|Erro ao enviar a mensagem de correio: " + e.getMessage()); } } this.enviaResposta(req, resp, res); } /** Recupera os parametros enviados pela aplicação cliente e monta a mensagem a ser enviada. * Se for solicitada pela aplicação cliente o envio de mensagem com anexo, acrescenta a mensagem * o caminho dos arquivos a serem anexados no momento do envio. */ private MensagemCorreio montaMensagem(HttpServletRequest req, HttpServletResponse resp) { MensagemCorreio res = new MensagemCorreio(); try { String remetente = req.getParameter("remetente"); String destinatarios = req.getParameter("destinatarios"); String assunto = req.getParameter("assunto"); String corpoMensagem = req.getParameter("corpoMensagem"); String destinatariosCC = req.getParameter("destinatariosCC"); String destinatariosBCC = req.getParameter("destinatariosBCC"); String[] anexos = req.getParameterValues("anexo"); res.setAnexos(anexos); res.setAssunto(assunto); res.setCorpoMensagem(corpoMensagem); res.setDestinatarios(destinatarios); res.setDestinatariosBCC(destinatariosBCC); res.setDestinatariosCC(destinatariosCC); res.setRemetente(remetente); } catch(Exception e) { this.log("Erro ao montar mensagem: " + e.getMessage(), e); res = null;

109

} return res; } /** Solicita o envio da mensagem ao JavaBean especilizado em envio de emails. */ private String enviaMensagem(Usuario usuario, MensagemCorreio mensagem) throws Exception{ String res = null; BeanEmail bean = new BeanEmail(); bean.setSenhaSMTP(usuario.getSenha()); bean.setUsuarioSMTP(usuario.getId()); bean.setServidorSMTP(this.servidorSMTP); res = bean.enviaEmail(mensagem); return res; } } package controle; import javax.servlet.*; import javax.servlet.http.*; public interface ControladorMobileEmail { /** * Interface para processamento das requisições feitas ao serviço de correio eletrônico móvel. */ public void processaRequisicao(HttpServletRequest req, HttpServletResponse resp) throws ServletException, java.io.IOException; } package controle; import controle.ControladorMobileEmail; import javax.servlet.*; import javax.servlet.http.*; import javax.servlet.http.HttpServlet; /** * Atende a todas requisições e despacha para os controladores responsáveis pela execução da ação. */ public class ControladorPrincipal extends Controlador { /** Processa requisições do método POST*/ protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, java.io.IOException { this.processaRequisicao(req, resp); } /** Processa requisições do método GET */ protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, java.io.IOException { this.processaRequisicao(req, resp); } /** Processa requisições */ public void processaRequisicao(HttpServletRequest req, HttpServletResponse resp) throws ServletException, java.io.IOException { String acao = req.getParameter("acao"); String url = null; if(acao == null) { url = new String("ERRO|Ação não definida!"); this.enviaResposta(req, resp, url); } else { if(acao.equals("login")) url = resp.encodeURL("/controladorLogin"); else if(acao.equals("listFolder"))

110

url = resp.encodeURL("/controladorArquivo"); else if(acao.equals("sendMsg")) url = resp.encodeURL("/controladorMensagem"); RequestDispatcher rd = this.getServletContext().getRequestDispatcher(url); rd.forward(req, resp); } } }

Anexo A.3 – Pacote entidade

package entidade; /** * Classe que representa uma mensagem de correio eletrônico. */ public class MensagemCorreio extends java.lang.Object { /** * Assunto da mensagem. */ private String assunto = null; /** * Lista de destinatários. */ private String destinatarios = null; /** * Lista de destinatários cópia carbono. */ private String destinatariosCC = null; /** * Lista de destinatários cópia carbono oculta. */ private String destinatariosBCC = null; /** * Corpo da mensagem. */ private String corpoMensagem = null; /** * Lista de arquivos a serem anexados a mensagem. */ private String[] anexos = null; private String remetente = null; public String[] getAnexos() { return this.anexos; } public void setAnexos(final String[] anexos) { this.anexos = anexos; } public String getAssunto() { return this.assunto; } public void setAssunto(final String assunto) {

111

this.assunto = assunto; } public String getCorpoMensagem() { return this.corpoMensagem; } public void setCorpoMensagem(final String corpoMensagem) { this.corpoMensagem = corpoMensagem; } public String getDestinatarios() { return this.destinatarios; } public void setDestinatarios(final String destinatarios) { this.destinatarios = destinatarios; } public String getDestinatariosBCC() { return this.destinatariosBCC; } public void setDestinatariosBCC(final String destinatariosBCC) { this.destinatariosBCC = destinatariosBCC; } public String getDestinatariosCC() { return this.destinatariosCC; } public void setDestinatariosCC(final String destinatariosCC) { this.destinatariosCC = destinatariosCC; } public String getRemetente() { return this.remetente; } public void setRemetente(final String remetente) { this.remetente = remetente; } } package entidade; /** * Classe que representa a entidade usuário. */ public class Usuario extends java.lang.Object { /** * Atributo que representa o ID do usuário */ private String id = null; /** * Senha do usuário. */ private String senha = null; /** * Diretorio raiz do usuário. */ private String diretorioRaiz = null; private String enderecoEmail = null;

112

public String getDiretorioRaiz() { return this.diretorioRaiz; } public void setDiretorioRaiz(final String diretorioRaiz) { this.diretorioRaiz = diretorioRaiz; } public String getId() { return this.id; } public void setId(final String id) { this.id = id; } public String getSenha() { return this.senha; } public void setSenha(final String senha) { this.senha = senha; } public String getEnderecoEmail() { return enderecoEmail; } public void setEnderecoEmail(String enderecoEmail) { this.enderecoEmail = enderecoEmail; } }

Anexo B – Código fonte módulo cliente

Anexo B.1 – Pacote bean

/* * BeanConfiguracao.java * * Created on 23 de Setembro de 2005, 00:59 * * To change this template, choose Tools | Options and locate the template under * the Source Creation and Management node. Right-click the template and choose * Open. You can then make changes to the template in the Source Editor. */ package bean; import io.ReaderWriter; /** * * @author Rodrigo */ public abstract class BeanConfiguracao { /** Creates a new instance of BeanConfiguracao */ public BeanConfiguracao() {

113

} public abstract void salvaConfiguracao(Object value) throws Exception; public abstract Object carregaConfiguracao() throws Exception; public void limpaConfiguracao(ReaderWriter rw) { try { rw.deleteRecordStore(); } catch(Exception e) { } } } /* * BeanConfiguracaoLogin.java * * Created on 23 de Setembro de 2005, 01:04 * * To change this template, choose Tools | Options and locate the template under * the Source Creation and Management node. Right-click the template and choose * Open. You can then make changes to the template in the Source Editor. */ package bean; import entidade.ConfiguracaoLogin; import io.ReaderWriter; /** * * @author Rodrigo */ public class BeanConfiguracaoLogin extends BeanConfiguracao { /** Creates a new instance of BeanConfiguracaoLogin */ public BeanConfiguracaoLogin() { } public void salvaConfiguracao(Object value) throws Exception { ReaderWriter rw = new ReaderWriter("configLogin"); this.limpaConfiguracao(rw); rw.openRecordStore(); try { rw.addRecord(((ConfiguracaoLogin)value).getServidor()); rw.addRecord(((ConfiguracaoLogin)value).getUsuario()); if(((ConfiguracaoLogin)value).isLembrarSenha()) { rw.addRecord("1"); rw.addRecord(((ConfiguracaoLogin)value).getSenha()); } } finally { rw.closeRecordStore(); } } public Object carregaConfiguracao() throws Exception { ConfiguracaoLogin res = new ConfiguracaoLogin(); ReaderWriter rw = new ReaderWriter("configLogin"); rw.openRecordStore(); try { String[] config = rw.readRecords(); if(config != null) { for(int i=0; i < config.length; i++) { switch(i) { case 0: res.setServidor(config[i]);break;

114

case 1: res.setUsuario(config[i]);break; case 2: res.setLembrarSenha(true); break; case 3: res.setSenha(config[i]);break; } } } } finally { rw.closeRecordStore(); } return res; } }

Anexo B.2 – Pacote controle

/* * ControladorConfiguracao.java * * Created on 17 de Setembro de 2005, 16:23 * * To change this template, choose Tools | Options and locate the template under * the Source Creation and Management node. Right-click the template and choose * Open. You can then make changes to the template in the Source Editor. */ package controle; import bean.BeanConfiguracaoLogin; import entidade.ConfiguracaoLogin; /** * * @author Rodrigo */ public class ControladorConfiguracao { /** Creates a new instance of ControladorConfiguracao */ public ControladorConfiguracao() { } public static ConfiguracaoLogin carregaConfigLogin() throws Exception { BeanConfiguracaoLogin bean = new BeanConfiguracaoLogin(); return (ConfiguracaoLogin)bean.carregaConfiguracao(); } public static void salvaConfigLogin(ConfiguracaoLogin config) throws Exception{ BeanConfiguracaoLogin bean = new BeanConfiguracaoLogin(); bean.salvaConfiguracao(config); } } /* * ControladorServico.java * * Created on 24 de Setembro de 2005, 01:24 * * To change this template, choose Tools | Options and locate the template under * the Source Creation and Management node. Right-click the template and choose * Open. You can then make changes to the template in the Source Editor. */

115

package controle; import controle.acao.Acao; import javax.microedition.lcdui.AlertType; import javax.microedition.lcdui.Displayable; import visao.MobileMail; /** * * @author Rodrigo */ public class ControladorHTTP implements Runnable { private Acao acao = null; private Displayable display; private Displayable displayErro; /** Creates a new instance of ControladorServico */ public ControladorHTTP(Displayable display, Displayable displayErro) { this.display = display; this.displayErro = displayErro; } public void execute(Acao acao) throws Exception{ this.acao = acao; new Thread(this).start(); } public void run() { try { this.acao.execute(display, displayErro); }catch(Exception e) { MobileMail.getInstance().exibeMsg(AlertType.ERROR, displayErro,"MobileMail 1.0 - Erro", "Erro ao " + this.acao.getAcao() + ": " + e.getMessage()); } } }

Anexo B.3 – Pacote controle.acao

/* * Acao.java * * Created on 26 de Setembro de 2005, 23:26 * * To change this template, choose Tools | Options and locate the template under * the Source Creation and Management node. Right-click the template and choose * Open. You can then make changes to the template in the Source Editor. */ package controle.acao; import javax.microedition.lcdui.Displayable; /** * * @author Rodrigo */

116

public abstract class Acao { private String acao = null; private String url = null; private String metodo = null; /** Creates a new instance of Acao */ public Acao() { } public abstract void execute(Displayable display, Displayable displayErro) throws Exception; public String getAcao() { return this.acao; } public void setAcao(final String acao) { this.acao = acao; } public String getMetodo() { return this.metodo; } public void setMetodo(final String metodo) { this.metodo = metodo; } public String getUrl() { return this.url; } public void setUrl(final String url) { this.url = url; } } /* * AcaoEnvioMensagem.java * * Created on 21 de Outubro de 2005, 22:14 * * To change this template, choose Tools | Options and locate the template under * the Source Creation and Management node. Right-click the template and choose * Open. You can then make changes to the template in the Source Editor. */ package controle.acao; import javax.microedition.lcdui.AlertType; import javax.microedition.lcdui.Displayable; import javax.microedition.lcdui.Gauge; import net.HttpConn; import visao.MobileMail; /** * * @author Rodrigo */ public class AcaoEnvioMensagem extends Acao{ private Displayable display = null; private Displayable displayErro = null;

117

private Gauge gauge = null; /** Creates a new instance of AcaoEnvioMensagem */ public AcaoEnvioMensagem(String url, String metodo) { this.setMetodo(metodo); this.setUrl(url); this.setAcao("enviar mensagem"); } public void execute(javax.microedition.lcdui.Displayable display, javax.microedition.lcdui.Displayable displayErro) throws Exception { this.display = display; this.displayErro = displayErro; HttpConn http = new HttpConn(); String res = null; http.connect(this.getUrl()); try { MobileMail.getInstance().setFormAtual(MobileMail.getInstance().getFrmGauge()); MobileMail.getInstance().getFrmGauge().deleteAll(); gauge = new Gauge("Enviando mensagem ...", false, 100, 0); gauge.setLayout(Gauge.LAYOUT_CENTER | Gauge.LAYOUT_NEWLINE_AFTER); MobileMail.getInstance().getFrmGauge().append(gauge); gauge.setValue(20); Thread.sleep(100); gauge.setValue(40); Thread.sleep(100); gauge.setValue(60); Thread.sleep(100); res = http.send(this.getUrl(), this.getMetodo()); gauge.setValue(80); Thread.sleep(100); gauge.setValue(100); Thread.sleep(100); boolean sucesso = res.substring(0,res.indexOf("|")).equals("OK"); if(sucesso) MobileMail.getInstance().exibeMsg(AlertType.CONFIRMATION, display,"MobileMail 1.0 - Envio de mensagem", res.substring(res.indexOf("|") + 1)); else MobileMail.getInstance().exibeMsg(AlertType.ERROR, displayErro,"MobileMail 1.0 - Erro", "Erro ao " + this.getAcao() + ": " + res.substring(res.indexOf("|") + 1)); } finally { http.disconnect(); } } } /* * AcaoLogin.java * * Created on 26 de Setembro de 2005, 23:29 * * To change this template, choose Tools | Options and locate the template under * the Source Creation and Management node. Right-click the template and choose * Open. You can then make changes to the template in the Source Editor. */ package controle.acao; import javax.microedition.lcdui.AlertType; import javax.microedition.lcdui.Displayable; import javax.microedition.lcdui.Gauge; import net.HttpConn; import visao.MobileMail; /** *

118

* @author Rodrigo */ public class AcaoLogin extends Acao{ /** Creates a new instance of AcaoLogin */ public AcaoLogin(String url, String metodo) { this.setMetodo(metodo); this.setUrl(url); this.setAcao("efetuar login"); } public void execute(Displayable display, Displayable displayErro) throws Exception { Gauge gauge = new Gauge("Efetuando login ...", false, 100, 0); gauge.setLayout(Gauge.LAYOUT_CENTER | Gauge.LAYOUT_NEWLINE_AFTER); MobileMail.getInstance().getFrmLogin().append(gauge); gauge.setValue(20); Thread.sleep(100); HttpConn http = new HttpConn(); gauge.setValue(50); Thread.sleep(100); String res = null; http.connect(this.getUrl()); gauge.setValue(80); Thread.sleep(100); try { res = http.send(this.getUrl(), this.getMetodo()); gauge.setValue(100); Thread.sleep(100); boolean sucesso = res.substring(0,res.indexOf("|")).equals("OK"); if(sucesso) { String idSession = ";jsessionid=" + http.getHeaderField("ID-Session"); MobileMail.getInstance().setIdSession(idSession); MobileMail.getInstance().exibeMsg(AlertType.CONFIRMATION, display,"MobileMail 1.0 - Login", res.substring(res.indexOf("|") + 1)); } else MobileMail.getInstance().exibeMsg(AlertType.ERROR, displayErro,"MobileMail 1.0 - Erro", "Erro ao " + this.getAcao() + ": " + res.substring(res.indexOf("|") + 1)); } finally { http.disconnect(); MobileMail.getInstance().getFrmLogin().delete(5); } } } /* * AcaoNavegacao.java * * Created on 29 de Setembro de 2005, 21:42 * * To change this template, choose Tools | Options and locate the template under * the Source Creation and Management node. Right-click the template and choose * Open. You can then make changes to the template in the Source Editor. */ package controle.acao; import java.util.Hashtable; import javax.microedition.lcdui.AlertType; import javax.microedition.lcdui.Command; import javax.microedition.lcdui.CommandListener; import javax.microedition.lcdui.Displayable; import javax.microedition.lcdui.Gauge; import javax.microedition.lcdui.Image; import javax.microedition.lcdui.ImageItem; import javax.microedition.lcdui.Item; import javax.microedition.lcdui.ItemCommandListener;

119

import javax.microedition.lcdui.List; import javax.microedition.lcdui.StringItem; import javax.microedition.lcdui.Ticker; import net.HttpConn; import visao.MobileMail; /** * * @author Rodrigo */ public class AcaoNavegacao extends Acao { private Command comando = new Command("Selecionar",Command.OK, 1); private Gauge gauge = null; private Displayable display = null; private Displayable displayErro = null; private String fileSeparator = null; /** Creates a new instance of AcaoNavegacao */ public AcaoNavegacao(String url, String metodo) { this.setUrl(url); this.setMetodo(metodo); this.setAcao("navegar em diretorio"); } public void execute(Displayable display, Displayable displayErro) throws Exception { this.display = display; this.displayErro = displayErro; MobileMail.getInstance().getFrmNavegacao().deleteAll(); HttpConn http = new HttpConn(); String res = null; http.connect(this.getUrl()); try { MobileMail.getInstance().setFormAtual(MobileMail.getInstance().getFrmGauge()); MobileMail.getInstance().getFrmGauge().deleteAll(); gauge = new Gauge("Obtendo lista de arquivos e diretórios ...", false, 100, 0); gauge.setLayout(Gauge.LAYOUT_CENTER | Gauge.LAYOUT_NEWLINE_AFTER); MobileMail.getInstance().getFrmGauge().append(gauge); gauge.setValue(20); Thread.sleep(100); res = http.send(this.getUrl(), this.getMetodo()); boolean sucesso = res.substring(0,res.indexOf("|")).equals("OK"); if(sucesso) { gauge.setValue(40); Thread.sleep(100); res = res.substring(res.indexOf("|") + 1); fileSeparator = res.substring(0,res.indexOf("|")); res = res.substring(res.indexOf("|") + 1); this.getArquivosListados(res); MobileMail.getInstance().setDiretorioAtual(res.substring(0, res.indexOf("|"))); res = res.substring(res.indexOf("|") + 1); Arquivo[] arquivos = this.getArquivosListados(res); gauge.setValue(100); Thread.sleep(100); MobileMail.getInstance().getFrmNavegacao().deleteAll(); MobileMail.getInstance().setFrmNavegacao(new List("MobileMail 1.0 - Anexar arquivos",List.IMPLICIT)); MobileMail.getInstance().getFrmNavegacao().setCommandListener(new ArquivoCommandListener()); MobileMail.getInstance().getFrmNavegacao().setTicker(new Ticker("Diretório atual: " + MobileMail.getInstance().getDiretorioAtual())); if(arquivos != null) for(int i=0; i < arquivos.length; i++) MobileMail.getInstance().getFrmNavegacao().append(arquivos[i].getNome(), arquivos[i].getIcone());

120

MobileMail.getInstance().getFrmNavegacao().addCommand(MobileMail.getInstance().getComandoVoltarAnexar()); MobileMail.getInstance().getFrmNavegacao().addCommand(MobileMail.getInstance().getComandoListarAnexos()); MobileMail.getInstance().setFormAtual(MobileMail.getInstance().getFrmNavegacao()); } else MobileMail.getInstance().exibeMsg(AlertType.ERROR, displayErro,"MobileMail 1.0 - Erro", "Erro ao " + this.getAcao() + ": " + res.substring(res.indexOf("|") + 1)); } finally { http.disconnect(); } } private Arquivo[] getArquivosListados(String listagem) throws Exception { Arquivo[] res = null; Image img = Image.createImage("/imagens/folder.png"); Hashtable aux = new Hashtable(); long itemID = 0; while(listagem.indexOf("|") > -1) { String strItem = listagem.substring(0, listagem.indexOf("|")); boolean isDiretorio = false; Arquivo item = new Arquivo(); byte idAtributo = 1; while(strItem.indexOf("#") > -1) { String atributo = strItem.substring(0, strItem.indexOf("#")); strItem = strItem.substring(strItem.indexOf("#") + 1); switch(idAtributo) { case 1: { isDiretorio = atributo.equals("."); if(isDiretorio) item.setIcone(img); }break; case 2: item.setNome(atributo);break; default: item.setNome(item.getNome() + " - " + atributo);break; } idAtributo++; } listagem = listagem.substring(listagem.indexOf("|") + 1); aux.put(String.valueOf(itemID), item); itemID++; } res = new Arquivo[aux.size()]; gauge.setValue(60); Thread.sleep(100); for(int i=0; i < aux.size(); i++) res[i] = (Arquivo)aux.get(String.valueOf(i)); return res; } /** Classe interna que irá representar um arquivo ou diretório */ private class Arquivo { private String nome = null; private Image icone = null; public Arquivo() { } public Arquivo(String nome, Image icone) { this.icone = icone; this.nome = nome; } public Image getIcone() { return this.icone; }

121

public void setIcone(final Image icone) { this.icone = icone; } public String getNome() { return this.nome; } public void setNome(final String nome) { this.nome = nome; } } /** Implementação do listener de evento utilizando inner class */ private class ArquivoCommandListener implements CommandListener { public ArquivoCommandListener() { } public void commandAction(Command command, Displayable displayable) { if(command == MobileMail.getInstance().getComandoVoltarAnexar()) MobileMail.getInstance().setFormAtual(MobileMail.getInstance().getFrmEnviaMsg()); else if(command == MobileMail.getInstance().getComandoListarAnexos()){ MobileMail.getInstance().setFormAtual(MobileMail.getInstance().getFrmAnexos()); MobileMail.getInstance().listaAnexos(MobileMail.getInstance().getFrmNavegacao()); } else { int id = MobileMail.getInstance().getFrmNavegacao().getSelectedIndex(); if(MobileMail.getInstance().getFrmNavegacao().getImage(id) == null || MobileMail.getInstance().getFrmNavegacao().getImage(id) == MobileMail.getInstance().getSmallConfirmIcon()) { String arquivo = MobileMail.getInstance().getDiretorioAtual() + MobileMail.getInstance().getFrmNavegacao().getString(id); int pos = arquivo.lastIndexOf('.'); pos = arquivo.indexOf("-", pos); arquivo = arquivo.substring(0, pos).trim(); if(MobileMail.getInstance().getFrmNavegacao().getImage(id) == null) { MobileMail.getInstance().addAnexo(arquivo); MobileMail.getInstance().getFrmNavegacao().set(id, MobileMail.getInstance().getFrmNavegacao().getString(id), MobileMail.getInstance().getSmallConfirmIcon()); } else { MobileMail.getInstance().removeAnexo(arquivo); MobileMail.getInstance().getFrmNavegacao().set(id, MobileMail.getInstance().getFrmNavegacao().getString(id), null); } } else { String diretorio = MobileMail.getInstance().getDiretorioAtual(); if(MobileMail.getInstance().getFrmNavegacao().getString(id).equals("..")) { int pos =0, posAnterior = 0; while(diretorio.indexOf(fileSeparator,pos) > -1 && pos < diretorio.lastIndexOf(fileSeparator.charAt(0))) { pos = diretorio.indexOf(fileSeparator, pos + 1); if(pos < diretorio.lastIndexOf(fileSeparator.charAt(0))) posAnterior = pos; } pos = posAnterior; diretorio = diretorio.substring(0, pos + 1); } else diretorio += MobileMail.getInstance().getFrmNavegacao().getString(id); if(diretorio.charAt(diretorio.length()-1) != fileSeparator.charAt(0)) diretorio += fileSeparator; MobileMail.getInstance().setDiretorioAtual(diretorio); MobileMail.getInstance().navegaDiretorio(); } } } }

122

}

Anexo B.4 – Pacote entidade

/* * ConfiguracaoLogin.java * * Created on 23 de Setembro de 2005, 00:43 * * To change this template, choose Tools | Options and locate the template under * the Source Creation and Management node. Right-click the template and choose * Open. You can then make changes to the template in the Source Editor. */ package entidade; /** * * @author Rodrigo */ public class ConfiguracaoLogin { /** Servidor ao qual a aplicação cliente se conectará * para utilizar o serviço mobilemail */ private String servidor = null; /** ID do usuário */ private String usuario = null; /** Senha de autenticação no servidor */ private String senha = null; /** Flag para gravar ou não a senha do usuário */ private boolean lembrarSenha = false; /** Creates a new instance of ConfiguracaoLogin */ public ConfiguracaoLogin() { } public String getSenha() { return this.senha; } public void setSenha(final String senha) { this.senha = senha; } public String getServidor() { return this.servidor; } public void setServidor(final String servidor) { this.servidor = servidor; } public String getUsuario() { return this.usuario; } public void setUsuario(final String usuario) { this.usuario = usuario; }

123

public boolean isLembrarSenha() { return this.lembrarSenha; } public void setLembrarSenha(final boolean lembrarSenha) { this.lembrarSenha = lembrarSenha; } }

Anexo B.5 – Pacote visão

/* * MobileMail.java * * Created on 15 de Setembro de 2005, 23:50 */ package visao; import controle.ControladorConfiguracao; import controle.ControladorHTTP; import controle.acao.AcaoEnvioMensagem; import controle.acao.AcaoLogin; import controle.acao.AcaoNavegacao; import entidade.ConfiguracaoLogin; import java.util.Enumeration; import java.util.Hashtable; import javax.microedition.lcdui.Alert; import javax.microedition.lcdui.AlertType; import javax.microedition.lcdui.Command; import javax.microedition.lcdui.Displayable; import javax.microedition.lcdui.Form; import javax.microedition.lcdui.Image; import javax.microedition.lcdui.ItemCommandListener; import javax.microedition.lcdui.List; import javax.microedition.lcdui.StringItem; import javax.microedition.midlet.*; /** * * @author Rodrigo */ public class MobileMail extends MIDlet implements javax.microedition.lcdui.CommandListener, java.lang.Runnable { private static MobileMail instancia = null; private String idSession = null; private Hashtable anexos = new Hashtable(); private String diretorioAtual = null; /** Creates a new instance of MobileMail */ public MobileMail() { instancia = this; } // --- This section is auto-generated by NetBeans IDE. Do not modify or you may lose your changes.//<editor-fold id="MVDMethods" defaultstate="collapsed" desc="This section is auto-generated by NetBeans IDE.">//GEN-BEGIN:MVDMethods /**

124

* This method initializes UI of the application. */ private void initialize() { new java.lang.Thread(this).start(); // For adding user code into this block, select "Design" item in the inspector and invoke property editor on Action property in Properties window. javax.microedition.lcdui.Display.getDisplay(this).setCurrent(get_msgSplash(), get_menuPrincipal()); } private static final int _ASYNC_NOTHING = 0; private static final int _ASYNC_CA = 1; private int _asyncMethod = _ASYNC_NOTHING; private Object[] _asyncParameters = new Object[2]; /** * This method is run in another thread and communicates with event handlers and provides ability for event processing in different thread. **/ public void run() { int asyncMethod; Object firstParameter; Object secondParameter; for (;;) { // wait and get request for event processing synchronized (_asyncParameters) { _asyncMethod = _ASYNC_NOTHING; _asyncParameters[0] = null; _asyncParameters[1] = null; try { _asyncParameters.wait(); } catch (Exception e) { e.printStackTrace(); } asyncMethod = _asyncMethod; firstParameter = _asyncParameters[0]; secondParameter = _asyncParameters[1]; } // forward request to appropriate event handler if (_asyncMethod == _ASYNC_CA) _commandAction((javax.microedition.lcdui.Command) firstParameter, (javax.microedition.lcdui.Displayable) secondParameter); } } /** * Called by the system to indicate that a command has been invoked on a particular displayable. * @param command the Command that ws invoked * @param displayable the Displayable on which the command was invoked **/ public void commandAction(javax.microedition.lcdui.Command command, javax.microedition.lcdui.Displayable displayable) { synchronized (_asyncParameters) { _asyncMethod = _ASYNC_CA; _asyncParameters[0] = command; _asyncParameters[1] = displayable; _asyncParameters.notifyAll(); } } /** * Called by run method for processing the event from the system that a command has been invoked on a particular displayable. * @param command the Command that ws invoked * @param displayable the Displayable on which the command was invoked

125

**/ public void _commandAction(javax.microedition.lcdui.Command command, javax.microedition.lcdui.Displayable displayable) { if (displayable == frmAnexos) { if (command == comandoVoltarAnexo) { // For adding user code into this block, select "Design | Screens | frmAnexos [Form] | Assigned Commands | comandoVoltarAnexo" item in the inspector and invoke property editor on Action property in Properties window. javax.microedition.lcdui.Display.getDisplay(this).setCurrent(get_frmEnviaMsg()); } } else if (displayable == frmEditor) { if (command == comandoCancelMsg) { // For adding user code into this block, select "Design | Screens | frmEditor [TextBox] | Assigned Commands | comandoCancelMsg" item in the inspector and invoke property editor on Action property in Properties window. javax.microedition.lcdui.Display.getDisplay(this).setCurrent(get_frmEnviaMsg()); } else if (command == comandoOkMsg) { // For adding user code into this block, select "Design | Screens | frmEditor [TextBox] | Assigned Commands | comandoOkMsg" item in the inspector and invoke property editor on Action property in Properties window. javax.microedition.lcdui.Display.getDisplay(this).setCurrent(get_frmEnviaMsg()); } } else if (displayable == frmEnviaMsg) { if (command == comandoAnexar) { // For adding user code into this block, select "Design | Screens | frmEnviaMsg [Form] | Assigned Commands | comandoAnexar" item in the inspector and invoke property editor on Action property in Properties window. javax.microedition.lcdui.Display.getDisplay(this).setCurrent(get_frmNavegacaoSelecao()); } else if (command == comandoCancelaMsg) { // For adding user code into this block, select "Design | Screens | frmEnviaMsg [Form] | Assigned Commands | comandoCancelaMsg" item in the inspector and invoke property editor on Action property in Properties window. javax.microedition.lcdui.Display.getDisplay(this).setCurrent(get_menuPrincipal()); } else if (command == comandoEditarMag) { // For adding user code into this block, select "Design | Screens | frmEnviaMsg [Form] | Assigned Commands | comandoEditarMag" item in the inspector and invoke property editor on Action property in Properties window. javax.microedition.lcdui.Display.getDisplay(this).setCurrent(get_frmEditor()); } else if (command == comandoEnviarMsg) { // For adding user code into this block, select "Design | Screens | frmEnviaMsg [Form] | Assigned Commands | comandoEnviarMsg" item in the inspector and invoke property editor on Action property in Properties window. this.enviaMensagem(); } else if (command == comandoListaAnexos) { // For adding user code into this block, select "Design | Screens | frmEnviaMsg [Form] | Assigned Commands | comandoListaAnexos" item in the inspector and invoke property editor on Action property in Properties window. javax.microedition.lcdui.Display.getDisplay(this).setCurrent(get_frmAnexos()); this.listaAnexos(this.getFrmEnviaMsg()); } } else if (displayable == frmLogin) { if (command == comandoCancelar) { // For adding user code into this block, select "Design | Screens | frmLogin [Form] | Assigned Commands | comandoCancelar" item in the inspector and invoke property editor on Action property in Properties window. javax.microedition.lcdui.Display.getDisplay(this).setCurrent(get_menuPrincipal()); } else if (command == comandoLogin) { // For adding user code into this block, select "Design | Screens | frmLogin [Form] | Assigned Commands | comandoLogin" item in the inspector and invoke property editor on Action property in Properties window. this.salvaConfigLogin(); this.efetuaLogin(); } } else if (displayable == frmNavegacaoSelecao) { if (command == comandoListaAnexos) { // For adding user code into this block, select "Design | Screens | frmNavegacaoSelecao [List] | Assigned Commands | comandoListaAnexos" item in the inspector and invoke property editor on Action property in Properties window. javax.microedition.lcdui.Display.getDisplay(this).setCurrent(get_frmAnexos()); this.listaAnexos(this.getFrmNavegacao()); } else if (command == comandoVoltarAnexar) { // For adding user code into this block, select "Design | Screens | frmNavegacaoSelecao [List] | Assigned Commands | comandoVoltarAnexar" item in the inspector and invoke property editor on Action property in Properties window. javax.microedition.lcdui.Display.getDisplay(this).setCurrent(get_frmEnviaMsg()); } } else if (displayable == menuConfig) { if (command == comandoVoltar) {

126

// For adding user code into this block, select "Design | Screens | menuConfig [List] | Assigned Commands | comandoVoltar" item in the inspector and invoke property editor on Action property in Properties window. javax.microedition.lcdui.Display.getDisplay(this).setCurrent(get_menuPrincipal()); } else if (command == menuConfig.SELECT_COMMAND) { } } else if (displayable == menuPrincipal) { if (command == comandoSair) { // For adding user code into this block, select "Design | Screens | menuPrincipal [List] | Assigned Commands | comandoSair" item in the inspector and invoke property editor on Action property in Properties window. javax.microedition.lcdui.Display.getDisplay(this).setCurrent(null); destroyApp(true); notifyDestroyed(); } else if (command == menuPrincipal.SELECT_COMMAND) { switch (get_menuPrincipal().getSelectedIndex()) { case 0: // For adding user code into this block, select "Design | Screens | menuPrincipal [List] | Elements | Efetuar login" item in the inspector and invoke property editor on Action property in Properties window. javax.microedition.lcdui.Display.getDisplay(this).setCurrent(get_frmLogin()); break; case 1: // For adding user code into this block, select "Design | Screens | menuPrincipal [List] | Elements | Configuração" item in the inspector and invoke property editor on Action property in Properties window. javax.microedition.lcdui.Display.getDisplay(this).setCurrent(get_menuConfig()); break; case 2: // For adding user code into this block, select "Design | Screens | menuPrincipal [List] | Elements | Enviar mensagem" item in the inspector and invoke property editor on Action property in Properties window. javax.microedition.lcdui.Display.getDisplay(this).setCurrent(get_frmEnviaMsg()); break; } } } } /** * This method returns instance for menuPrincipal component and should be called instead of accessing menuPrincipal field directly. * @return Instance for menuPrincipal component **/ private javax.microedition.lcdui.List get_menuPrincipal() { if (menuPrincipal == null) { menuPrincipal = new javax.microedition.lcdui.List(" MobileMail - Menu", javax.microedition.lcdui.Choice.IMPLICIT, new java.lang.String[] { "Efetuar login", "Configura\u00E7\u00E3o", "Enviar mensagem" }, new javax.microedition.lcdui.Image[] { get_imgLogin(), get_imgConfig(), get_imgEnviaMsg() }); menuPrincipal.addCommand(get_comandoSair()); menuPrincipal.setCommandListener(this); menuPrincipal.setSelectedFlags(new boolean[] { false, false, false }); } return menuPrincipal; } /** * This method returns instance for menuConfig component and should be called instead of accessing menuConfig field directly. * @return Instance for menuConfig component **/

127

private javax.microedition.lcdui.List get_menuConfig() { if (menuConfig == null) { menuConfig = new javax.microedition.lcdui.List("Mobile - Configura\u00E7\u00E3o", javax.microedition.lcdui.Choice.IMPLICIT, new java.lang.String[] { "Configurar Cliente", "Configurar conta no servidor" }, new javax.microedition.lcdui.Image[] { get_imgConfigCliente(), get_imgConfigServer() }); menuConfig.addCommand(get_comandoVoltar()); menuConfig.setCommandListener(this); menuConfig.setSelectedFlags(new boolean[] { false, false }); } return menuConfig; } /** * This method returns instance for frmLogin component and should be called instead of accessing frmLogin field directly. * @return Instance for frmLogin component **/ private javax.microedition.lcdui.Form get_frmLogin() { if (frmLogin == null) { frmLogin = new javax.microedition.lcdui.Form("MobileMail - Login", new javax.microedition.lcdui.Item[] { get_tfServidor(), get_tfUsuario(), get_tfSenha(), get_cgSalvaSenha(), get_spacer1() }); frmLogin.addCommand(get_comandoCancelar()); frmLogin.addCommand(get_comandoLogin()); frmLogin.setCommandListener(this); this.carregaConfigLogin(); } return frmLogin; } /** * This method returns instance for tfServidor component and should be called instead of accessing tfServidor field directly. * @return Instance for tfServidor component **/ private javax.microedition.lcdui.TextField get_tfServidor() { if (tfServidor == null) { tfServidor = new javax.microedition.lcdui.TextField("Servidor:", null, 120, 0x4); } return tfServidor; } /** * This method returns instance for tfUsuario component and should be called instead of accessing tfUsuario field directly. * @return Instance for tfUsuario component **/ private javax.microedition.lcdui.TextField get_tfUsuario() { if (tfUsuario == null) { tfUsuario = new javax.microedition.lcdui.TextField("Usu\u00E1rio:", "", 120, 0x0); } return tfUsuario; } /** * This method returns instance for tfSenha component and should be called instead of accessing tfSenha field directly. * @return Instance for tfSenha component

128

**/ private javax.microedition.lcdui.TextField get_tfSenha() { if (tfSenha == null) { tfSenha = new javax.microedition.lcdui.TextField("Senha:", "", 120, 0x10000); } return tfSenha; } /** * This method returns instance for cgSalvaSenha component and should be called instead of accessing cgSalvaSenha field directly. * @return Instance for cgSalvaSenha component **/ private javax.microedition.lcdui.ChoiceGroup get_cgSalvaSenha() { if (cgSalvaSenha == null) { cgSalvaSenha = new javax.microedition.lcdui.ChoiceGroup("", javax.microedition.lcdui.Choice.MULTIPLE, new java.lang.String[] {"Salvar senha"}, new javax.microedition.lcdui.Image[] {null}); cgSalvaSenha.setSelectedFlags(new boolean[] {false}); } return cgSalvaSenha; } /** * This method returns instance for comandoSair component and should be called instead of accessing comandoSair field directly. * @return Instance for comandoSair component **/ private javax.microedition.lcdui.Command get_comandoSair() { if (comandoSair == null) { comandoSair = new javax.microedition.lcdui.Command("Sair", "Sair", javax.microedition.lcdui.Command.EXIT, 1); } return comandoSair; } /** * This method returns instance for comandoVoltar component and should be called instead of accessing comandoVoltar field directly. * @return Instance for comandoVoltar component **/ private javax.microedition.lcdui.Command get_comandoVoltar() { if (comandoVoltar == null) { comandoVoltar = new javax.microedition.lcdui.Command("Voltar", "Voltar", javax.microedition.lcdui.Command.BACK, 1); } return comandoVoltar; } /** * This method returns instance for comandoCancelar component and should be called instead of accessing comandoCancelar field directly. * @return Instance for comandoCancelar component **/ private javax.microedition.lcdui.Command get_comandoCancelar() { if (comandoCancelar == null) { comandoCancelar = new javax.microedition.lcdui.Command("Cancelar", "Cancelar", javax.microedition.lcdui.Command.CANCEL, 1); } return comandoCancelar; } /** * This method returns instance for comandoLogin component and should be called instead of accessing comandoLogin field directly. * @return Instance for comandoLogin component **/ private javax.microedition.lcdui.Command get_comandoLogin() { if (comandoLogin == null) {

129

comandoLogin = new javax.microedition.lcdui.Command("Login", "Login", javax.microedition.lcdui.Command.OK, 1); } return comandoLogin; } /** * This method returns instance for imgConfigCliente component and should be called instead of accessing imgConfigCliente field directly. * @return Instance for imgConfigCliente component **/ private javax.microedition.lcdui.Image get_imgConfigCliente() { if (imgConfigCliente == null) { try { imgConfigCliente = javax.microedition.lcdui.Image.createImage("/imagens/cliente.png"); } catch (java.io.IOException exception) { } } return imgConfigCliente; } /** * This method returns instance for imgConfigServer component and should be called instead of accessing imgConfigServer field directly. * @return Instance for imgConfigServer component **/ private javax.microedition.lcdui.Image get_imgConfigServer() { if (imgConfigServer == null) { try { imgConfigServer = javax.microedition.lcdui.Image.createImage("/imagens/servidor2.png"); } catch (java.io.IOException exception) { } } return imgConfigServer; } /** * This method returns instance for imgOk component and should be called instead of accessing imgOk field directly. * @return Instance for imgOk component **/ private javax.microedition.lcdui.Image get_imgOk() { if (imgOk == null) { try { imgOk = javax.microedition.lcdui.Image.createImage("/imagens/confirmIcon.png"); } catch (java.io.IOException exception) { } } return imgOk; } /** * This method returns instance for imgDisk component and should be called instead of accessing imgDisk field directly. * @return Instance for imgDisk component **/ private javax.microedition.lcdui.Image get_imgDisk() { if (imgDisk == null) { try { imgDisk = javax.microedition.lcdui.Image.createImage("/imagens/Disk2.png"); } catch (java.io.IOException exception) { } } return imgDisk; } /** * This method returns instance for msgForm component and should be called instead of accessing msgForm field directly. * @return Instance for msgForm component

130

**/ private javax.microedition.lcdui.Alert get_msgForm() { if (msgForm == null) { msgForm = new javax.microedition.lcdui.Alert("", "<Enter Text>", null, javax.microedition.lcdui.AlertType.ERROR); msgForm.setTimeout(5000); } return msgForm; } /** * This method returns instance for msgSplash component and should be called instead of accessing msgSplash field directly. * @return Instance for msgSplash component **/ private javax.microedition.lcdui.Alert get_msgSplash() { if (msgSplash == null) { msgSplash = new javax.microedition.lcdui.Alert("MobileMail - 1.0", " Bem-vindo ao MobileMail 1.0", get_imgSplash(), javax.microedition.lcdui.AlertType.INFO); msgSplash.setTimeout(5000); } return msgSplash; } /** * This method returns instance for imgSplash component and should be called instead of accessing imgSplash field directly. * @return Instance for imgSplash component **/ private javax.microedition.lcdui.Image get_imgSplash() { if (imgSplash == null) { try { imgSplash = javax.microedition.lcdui.Image.createImage("/imagens/envelope_Splash.png"); } catch (java.io.IOException exception) { } } return imgSplash; } /** * This method returns instance for imgLogin component and should be called instead of accessing imgLogin field directly. * @return Instance for imgLogin component **/ private javax.microedition.lcdui.Image get_imgLogin() { if (imgLogin == null) { try { imgLogin = javax.microedition.lcdui.Image.createImage("/imagens/login.png"); } catch (java.io.IOException exception) { } } return imgLogin; } /** * This method returns instance for spacer1 component and should be called instead of accessing spacer1 field directly. * @return Instance for spacer1 component **/ private javax.microedition.lcdui.Spacer get_spacer1() { if (spacer1 == null) { spacer1 = new javax.microedition.lcdui.Spacer(1000, 1); } return spacer1; } /**

131

* This method returns instance for frmEnviaMsg component and should be called instead of accessing frmEnviaMsg field directly. * @return Instance for frmEnviaMsg component **/ private javax.microedition.lcdui.Form get_frmEnviaMsg() { if (frmEnviaMsg == null) { frmEnviaMsg = new javax.microedition.lcdui.Form("MobileMIal 1.0 - Editor de mensagem", new javax.microedition.lcdui.Item[] { get_spacer2(), get_tfPara(), get_tfCC(), get_tfBCC(), get_tfAssunto() }); frmEnviaMsg.addCommand(get_comandoEditarMag()); frmEnviaMsg.addCommand(get_comandoCancelaMsg()); frmEnviaMsg.addCommand(get_comandoAnexar()); frmEnviaMsg.addCommand(get_comandoEnviarMsg()); frmEnviaMsg.addCommand(get_comandoListaAnexos()); frmEnviaMsg.setCommandListener(this); } return frmEnviaMsg; } /** * This method returns instance for tfBCC component and should be called instead of accessing tfBCC field directly. * @return Instance for tfBCC component **/ private javax.microedition.lcdui.TextField get_tfBCC() { if (tfBCC == null) { tfBCC = new javax.microedition.lcdui.TextField("Bcc:", "", 120, 0x1); } return tfBCC; } /** * This method returns instance for tfAssunto component and should be called instead of accessing tfAssunto field directly. * @return Instance for tfAssunto component **/ private javax.microedition.lcdui.TextField get_tfAssunto() { if (tfAssunto == null) { tfAssunto = new javax.microedition.lcdui.TextField("Assunto:", "", 120, 0x0); } return tfAssunto; } /** * This method returns instance for comandoEditarMag component and should be called instead of accessing comandoEditarMag field directly. * @return Instance for comandoEditarMag component **/ private javax.microedition.lcdui.Command get_comandoEditarMag() { if (comandoEditarMag == null) { comandoEditarMag = new javax.microedition.lcdui.Command("Editar mensagem", "Editar mensagem", javax.microedition.lcdui.Command.SCREEN, 1); } return comandoEditarMag; } /** * This method returns instance for comandoCancelaMsg component and should be called instead of accessing comandoCancelaMsg field directly. * @return Instance for comandoCancelaMsg component **/ private javax.microedition.lcdui.Command get_comandoCancelaMsg() { if (comandoCancelaMsg == null) {

132

comandoCancelaMsg = new javax.microedition.lcdui.Command("Cancelar", "Cancelar", javax.microedition.lcdui.Command.CANCEL, 1); } return comandoCancelaMsg; } /** * This method returns instance for comandoAnexar component and should be called instead of accessing comandoAnexar field directly. * @return Instance for comandoAnexar component **/ private javax.microedition.lcdui.Command get_comandoAnexar() { if (comandoAnexar == null) { comandoAnexar = new javax.microedition.lcdui.Command("Anexar arquivos", "Anexar arquivos", javax.microedition.lcdui.Command.SCREEN, 1); } return comandoAnexar; } /** * This method returns instance for imgEnviaMsg component and should be called instead of accessing imgEnviaMsg field directly. * @return Instance for imgEnviaMsg component **/ private javax.microedition.lcdui.Image get_imgEnviaMsg() { if (imgEnviaMsg == null) { try { imgEnviaMsg = javax.microedition.lcdui.Image.createImage("/imagens/icone.png"); } catch (java.io.IOException exception) { } } return imgEnviaMsg; } /** * This method returns instance for imgConfig component and should be called instead of accessing imgConfig field directly. * @return Instance for imgConfig component **/ private javax.microedition.lcdui.Image get_imgConfig() { if (imgConfig == null) { try { imgConfig = javax.microedition.lcdui.Image.createImage("/imagens/config.png"); } catch (java.io.IOException exception) { } } return imgConfig; } /** * This method returns instance for frmEditor component and should be called instead of accessing frmEditor field directly. * @return Instance for frmEditor component **/ private javax.microedition.lcdui.TextBox get_frmEditor() { if (frmEditor == null) { frmEditor = new javax.microedition.lcdui.TextBox("MobileMail - Editor de mensagem", "", 500, 0x0); frmEditor.addCommand(get_comandoOkMsg()); frmEditor.addCommand(get_comandoCancelMsg()); frmEditor.setCommandListener(this); } return frmEditor; } /** * This method returns instance for comandoOkMsg component and should be called instead of accessing comandoOkMsg field directly.

133

* @return Instance for comandoOkMsg component **/ private javax.microedition.lcdui.Command get_comandoOkMsg() { if (comandoOkMsg == null) { comandoOkMsg = new javax.microedition.lcdui.Command("Ok", "Ok", javax.microedition.lcdui.Command.OK, 1); } return comandoOkMsg; } /** * This method returns instance for comandoCancelMsg component and should be called instead of accessing comandoCancelMsg field directly. * @return Instance for comandoCancelMsg component **/ private javax.microedition.lcdui.Command get_comandoCancelMsg() { if (comandoCancelMsg == null) { comandoCancelMsg = new javax.microedition.lcdui.Command("Cancelar", "Cancelar", javax.microedition.lcdui.Command.CANCEL, 1); } return comandoCancelMsg; } /** * This method returns instance for comandoEnviarMsg component and should be called instead of accessing comandoEnviarMsg field directly. * @return Instance for comandoEnviarMsg component **/ private javax.microedition.lcdui.Command get_comandoEnviarMsg() { if (comandoEnviarMsg == null) { comandoEnviarMsg = new javax.microedition.lcdui.Command("Enviar", javax.microedition.lcdui.Command.SCREEN, 1); } return comandoEnviarMsg; } /** * This method returns instance for tfPara component and should be called instead of accessing tfPara field directly. * @return Instance for tfPara component **/ private javax.microedition.lcdui.TextField get_tfPara() { if (tfPara == null) { tfPara = new javax.microedition.lcdui.TextField("Para:", null, 120, 0x0); } return tfPara; } /** * This method returns instance for tfCC component and should be called instead of accessing tfCC field directly. * @return Instance for tfCC component **/ private javax.microedition.lcdui.TextField get_tfCC() { if (tfCC == null) { tfCC = new javax.microedition.lcdui.TextField("Cc:", null, 120, 0x0); } return tfCC; } /** * This method returns instance for spacer2 component and should be called instead of accessing spacer2 field directly. * @return Instance for spacer2 component **/ private javax.microedition.lcdui.Spacer get_spacer2() { if (spacer2 == null) { spacer2 = new javax.microedition.lcdui.Spacer(1000, 1); } return spacer2; }

134

/** * This method returns instance for imgOkPequeno component and should be called instead of accessing imgOkPequeno field directly. * @return Instance for imgOkPequeno component **/ private javax.microedition.lcdui.Image get_imgOkPequeno() { if (imgOkPequeno == null) { try { imgOkPequeno = javax.microedition.lcdui.Image.createImage("/imagens/ok_pequeno.png"); } catch (java.io.IOException exception) { } } return imgOkPequeno; } /** * This method returns instance for comandoOkNavegacao component and should be called instead of accessing comandoOkNavegacao field directly. * @return Instance for comandoOkNavegacao component **/ private javax.microedition.lcdui.Command get_comandoOkNavegacao() { if (comandoOkNavegacao == null) { comandoOkNavegacao = new javax.microedition.lcdui.Command("", "Ok", javax.microedition.lcdui.Command.OK, 1); } return comandoOkNavegacao; } /** * This method returns instance for comandoCancelNavegacao component and should be called instead of accessing comandoCancelNavegacao field directly. * @return Instance for comandoCancelNavegacao component **/ private javax.microedition.lcdui.Command get_comandoCancelNavegacao() { if (comandoCancelNavegacao == null) { comandoCancelNavegacao = new javax.microedition.lcdui.Command("Voltar", "Voltar", javax.microedition.lcdui.Command.CANCEL, 1); } return comandoCancelNavegacao; } /** * This method returns instance for frmAnexos component and should be called instead of accessing frmAnexos field directly. * @return Instance for frmAnexos component **/ private javax.microedition.lcdui.Form get_frmAnexos() { if (frmAnexos == null) { frmAnexos = new javax.microedition.lcdui.Form("MobileMail - Anexos", new javax.microedition.lcdui.Item[0]); frmAnexos.addCommand(get_comandoVoltarAnexo()); frmAnexos.setCommandListener(this); this.listaAnexos(this.getFrmAnexos()); } return frmAnexos; } /** * This method returns instance for comandoVoltarAnexo component and should be called instead of accessing comandoVoltarAnexo field directly. * @return Instance for comandoVoltarAnexo component **/ private javax.microedition.lcdui.Command get_comandoVoltarAnexo() { if (comandoVoltarAnexo == null) { comandoVoltarAnexo = new javax.microedition.lcdui.Command("Voltar", "Voltar", javax.microedition.lcdui.Command.BACK, 1); }

135

return comandoVoltarAnexo; } /** * This method returns instance for comandoListaAnexos component and should be called instead of accessing comandoListaAnexos field directly. * @return Instance for comandoListaAnexos component **/ private javax.microedition.lcdui.Command get_comandoListaAnexos() { if (comandoListaAnexos == null) { comandoListaAnexos = new javax.microedition.lcdui.Command("Listar anexos", "Listar anexos", javax.microedition.lcdui.Command.SCREEN, 1); } return comandoListaAnexos; } /** * This method returns instance for comandoListaAnexoNavegacao component and should be called instead of accessing comandoListaAnexoNavegacao field directly. * @return Instance for comandoListaAnexoNavegacao component **/ private javax.microedition.lcdui.Command get_comandoListaAnexoNavegacao() { if (comandoListaAnexoNavegacao == null) { comandoListaAnexoNavegacao = new javax.microedition.lcdui.Command("Listar anexos", "Listar anexos", javax.microedition.lcdui.Command.SCREEN, 1); } return comandoListaAnexoNavegacao; } /** * This method returns instance for imgErro component and should be called instead of accessing imgErro field directly. * @return Instance for imgErro component **/ private javax.microedition.lcdui.Image get_imgErro() { if (imgErro == null) { try { imgErro = javax.microedition.lcdui.Image.createImage("/imagens/errorIcon.png"); } catch (java.io.IOException exception) { } } return imgErro; } /** * This method returns instance for imgInfo component and should be called instead of accessing imgInfo field directly. * @return Instance for imgInfo component **/ private javax.microedition.lcdui.Image get_imgInfo() { if (imgInfo == null) { try { imgInfo = javax.microedition.lcdui.Image.createImage("/imagens/infoIcon.png"); } catch (java.io.IOException exception) { } } return imgInfo; } /** * This method returns instance for imgWarning component and should be called instead of accessing imgWarning field directly. * @return Instance for imgWarning component **/ private javax.microedition.lcdui.Image get_imgWarning() { if (imgWarning == null) { try { imgWarning = javax.microedition.lcdui.Image.createImage("/imagens/warningIcon.png"); } catch (java.io.IOException exception) {

136

} } return imgWarning; } /** * This method returns instance for frmNavegacaoSelecao component and should be called instead of accessing frmNavegacaoSelecao field directly. * @return Instance for frmNavegacaoSelecao component **/ private javax.microedition.lcdui.List get_frmNavegacaoSelecao() { if (frmNavegacaoSelecao == null) { frmNavegacaoSelecao = new javax.microedition.lcdui.List("MobileMail - Anexar arquivos", javax.microedition.lcdui.Choice.IMPLICIT, new java.lang.String[0], new javax.microedition.lcdui.Image[0]); frmNavegacaoSelecao.addCommand(get_comandoVoltarAnexar()); frmNavegacaoSelecao.addCommand(get_comandoListaAnexos()); frmNavegacaoSelecao.setCommandListener(this); frmNavegacaoSelecao.setSelectedFlags(new boolean[0]); frmNavegacaoSelecao.setFitPolicy(javax.microedition.lcdui.Choice.TEXT_WRAP_ON); this.navegaDiretorio(); } return frmNavegacaoSelecao; } /** * This method returns instance for comandoVoltarAnexar component and should be called instead of accessing comandoVoltarAnexar field directly. * @return Instance for comandoVoltarAnexar component **/ private javax.microedition.lcdui.Command get_comandoVoltarAnexar() { if (comandoVoltarAnexar == null) { comandoVoltarAnexar = new javax.microedition.lcdui.Command("Voltar", "Voltar", javax.microedition.lcdui.Command.CANCEL, 1); } return comandoVoltarAnexar; } /** * This method returns instance for frmGauge component and should be called instead of accessing frmGauge field directly. * @return Instance for frmGauge component **/ private javax.microedition.lcdui.Form get_frmGauge() { if (frmGauge == null) { frmGauge = new javax.microedition.lcdui.Form("MobileMail v1.0", new javax.microedition.lcdui.Item[0]); } return frmGauge; } /** * This method returns instance for comandoListarAnexos component and should be called instead of accessing comandoListarAnexos field directly. * @return Instance for comandoListarAnexos component **/ private javax.microedition.lcdui.Command get_comandoListarAnexos() { if (comandoListarAnexos == null) { comandoListarAnexos = new javax.microedition.lcdui.Command("Listar anexos", "Listar anexos", javax.microedition.lcdui.Command.SCREEN, 1); } return comandoListarAnexos; } javax.microedition.lcdui.List menuPrincipal; javax.microedition.lcdui.List menuConfig; javax.microedition.lcdui.Form frmLogin; javax.microedition.lcdui.TextField tfServidor; javax.microedition.lcdui.TextField tfUsuario;

137

javax.microedition.lcdui.TextField tfSenha; javax.microedition.lcdui.ChoiceGroup cgSalvaSenha; javax.microedition.lcdui.Command comandoSair; javax.microedition.lcdui.Command comandoVoltar; javax.microedition.lcdui.Command comandoCancelar; javax.microedition.lcdui.Command comandoLogin; javax.microedition.lcdui.Image imgConfigCliente; javax.microedition.lcdui.Image imgConfigServer; javax.microedition.lcdui.Image imgOk; javax.microedition.lcdui.Image imgDisk; javax.microedition.lcdui.Alert msgForm; javax.microedition.lcdui.Alert msgSplash; javax.microedition.lcdui.Image imgSplash; javax.microedition.lcdui.Image imgLogin; javax.microedition.lcdui.Spacer spacer1; javax.microedition.lcdui.Form frmEnviaMsg; javax.microedition.lcdui.TextField tfBCC; javax.microedition.lcdui.TextField tfAssunto; javax.microedition.lcdui.Command comandoEditarMag; javax.microedition.lcdui.Command comandoCancelaMsg; javax.microedition.lcdui.Command comandoAnexar; javax.microedition.lcdui.Image imgEnviaMsg; javax.microedition.lcdui.Image imgConfig; javax.microedition.lcdui.TextBox frmEditor; javax.microedition.lcdui.Command comandoOkMsg; javax.microedition.lcdui.Command comandoCancelMsg; javax.microedition.lcdui.Command comandoEnviarMsg; javax.microedition.lcdui.TextField tfPara; javax.microedition.lcdui.TextField tfCC; javax.microedition.lcdui.Spacer spacer2; javax.microedition.lcdui.Image imgOkPequeno; javax.microedition.lcdui.Command comandoOkNavegacao; javax.microedition.lcdui.Command comandoCancelNavegacao; javax.microedition.lcdui.Form frmAnexos; javax.microedition.lcdui.Command comandoVoltarAnexo; javax.microedition.lcdui.Command comandoListaAnexos; javax.microedition.lcdui.Command comandoListaAnexoNavegacao; javax.microedition.lcdui.Image imgErro; javax.microedition.lcdui.Image imgInfo; javax.microedition.lcdui.Image imgWarning; javax.microedition.lcdui.List frmNavegacaoSelecao; javax.microedition.lcdui.Command comandoVoltarAnexar; javax.microedition.lcdui.Form frmGauge; javax.microedition.lcdui.Command comandoListarAnexos; // --- This is the end of auto-generated section.//</editor-fold>//GEN-END:MVDMethods public void startApp() { initialize(); } public void pauseApp() { } public void destroyApp(boolean unconditional) { } private void salvaConfigLogin() { try { ConfiguracaoLogin config = new ConfiguracaoLogin(); config.setServidor(tfServidor.getString()); config.setUsuario(tfUsuario.getString()); boolean[] itens = new boolean[cgSalvaSenha.size()]; if(cgSalvaSenha.getSelectedFlags(itens) > 0) { config.setLembrarSenha(true); config.setSenha(tfSenha.getString()); } ControladorConfiguracao.salvaConfigLogin(config);

138

} catch(Exception e) { this.exibeMsg(AlertType.ERROR,this.get_frmLogin(), "MobileMail 1.0 - Erro", "Erro ao salvar configurações de login : " + e.getMessage()); } } private void carregaConfigLogin() { try { ConfiguracaoLogin config = ControladorConfiguracao.carregaConfigLogin(); tfServidor.setString(config.getServidor()); tfUsuario.setString(config.getUsuario()); if(config.isLembrarSenha()) { cgSalvaSenha.setSelectedIndex(0, true); tfSenha.setString(config.getSenha()); } else cgSalvaSenha.setSelectedIndex(0, false); } catch (Exception e) { this.exibeMsg(AlertType.ERROR, this.get_frmLogin(), "MobileMail 1.0 - Erro","Erro ao carregar configurações de login : " + e.getMessage()); } } /** Exibe mensagens (Erro, informação, confirmação, etc...) */ public void exibeMsg(AlertType tipo, Displayable proximoDisplay, String titulo, String msg) { this.exibeMsg(tipo, proximoDisplay, titulo, msg, 5000); } /** Exibe mensagens (Erro, informação, confirmação, etc...) */ public void exibeMsg(AlertType tipo, Displayable proximoDisplay, String titulo, String msg, int timeout) { Alert msgFrm = this.get_msgForm(); msgFrm.setType(tipo); msgFrm.setTitle(titulo); msgFrm.setString(msg); msgFrm.setTimeout(timeout); for(int i=0; i < (msgFrm.getWidth()/msg.length()) * 2; i++) msgFrm.setString(" " + msgFrm.getString()); if(tipo.equals(AlertType.CONFIRMATION)) msgFrm.setImage(this.get_imgOk()); else if(tipo.equals(AlertType.ERROR)) msgFrm.setImage(this.get_imgErro()); else if(tipo.equals(AlertType.INFO)) msgFrm.setImage(this.get_imgInfo()); else if(tipo.equals(AlertType.WARNING)) msgFrm.setImage(this.get_imgWarning()); else msgFrm.setImage(null); javax.microedition.lcdui.Display.getDisplay(this).setCurrent(msgFrm, proximoDisplay); } /** Efetua o login do usuário */ private void efetuaLogin() { try { String url = this.get_tfServidor().getString() + "?acao=login&usuario=" + this.get_tfUsuario().getString() + "&senha=" + this.get_tfSenha().getString(); ControladorHTTP ctrlHTTP = new ControladorHTTP(this.get_menuPrincipal(), this.get_frmLogin()); ctrlHTTP.execute(new AcaoLogin(url, "POST")); } catch(Exception e) { this.exibeMsg(AlertType.ERROR,this.get_frmLogin(), "MobileMail 1.0 - Erro", "Erro ao efetuar de login : " + e.getMessage()); } } /** Navega pelos diretórios e seleciona os arquivos a serem anexados */ public void navegaDiretorio() { try {

139

String url = this.get_tfServidor().getString(); url += this.getIdSession(); url += "?acao=listFolder"; if(this.diretorioAtual != null && this.diretorioAtual.length() > 0) { String diretorio = this.diretorioAtual; diretorio = this.stringReplace(diretorio, " ", "%20"); url += "&diretorio=" + diretorio; } ControladorHTTP ctrlHTTP = new ControladorHTTP(this.get_frmNavegacaoSelecao(), this.get_frmNavegacaoSelecao()); ctrlHTTP.execute(new AcaoNavegacao(url, "POST")); } catch(Exception e) { this.exibeMsg(AlertType.ERROR,this.get_frmLogin(), "MobileMail 1.0 - Erro", "Erro ao listar diretório : " + e.getMessage()); } } public static MobileMail getInstance() { return instancia; } public Form getFrmLogin() { return this.get_frmLogin(); } public void setFormAtual(Displayable display) { javax.microedition.lcdui.Display.getDisplay(this).setCurrent(display); } public List getFrmNavegacao() { return this.get_frmNavegacaoSelecao(); } public void setFrmNavegacao(List lista) { this.frmNavegacaoSelecao = lista; } public String getIdSession() { return this.idSession; } public void setIdSession(final String idSession) { this.idSession = idSession; } public void clearAnexos() { this.anexos.clear(); } public void addAnexo(String anexo) { this.anexos.put(anexo,anexo); } public String[] getAnexos() { String[] res = new String[this.anexos.size()]; int i=0; for(Enumeration e = this.anexos.elements(); e.hasMoreElements();) { res[i]=(String)e.nextElement(); i++; } return res; } public void removeAnexo(String anexo) { this.anexos.remove(anexo); }

140

public void listaAnexos(Displayable display) { Command comando = new Command("Excluir",Command.OK, 1); this.get_frmAnexos().deleteAll(); if(this.anexos.size() == 0) this.exibeMsg(AlertType.INFO, display, "MobileMail - Aviso", "Não há anexos!"); else { String[] anexos = this.getAnexos(); for(int i=0; i < anexos.length; i++) { StringItem item = new StringItem(anexos[i], null, StringItem.PLAIN); item.setDefaultCommand(comando); item.setItemCommandListener(new AnexoCommandListener(display)); this.get_frmAnexos().append(item); } } } /** Listener para tratamento do evento para exclusão de anexos */ private class AnexoCommandListener implements ItemCommandListener { private Displayable display = null; public AnexoCommandListener(Displayable display) { this.display = display; } public void commandAction(javax.microedition.lcdui.Command command, javax.microedition.lcdui.Item item) { StringItem strItem = (StringItem)item; removeAnexo(strItem.getLabel()); listaAnexos(this.display); int i =0; boolean flag = false; while(i < MobileMail.getInstance().getFrmNavegacao().size() && !flag) { String arquivo = MobileMail.getInstance().getDiretorioAtual(); arquivo += MobileMail.getInstance().getFrmNavegacao().getString(i); if(MobileMail.getInstance().getFrmNavegacao().getImage(i) != null && MobileMail.getInstance().getFrmNavegacao().getImage(i) == MobileMail.getInstance().getSmallConfirmIcon()) { int pos = arquivo.lastIndexOf('.'); pos = arquivo.indexOf("-", pos); arquivo = arquivo.substring(0, pos).trim(); flag = arquivo.equals(strItem.getLabel()); if(flag) MobileMail.getInstance().getFrmNavegacao().set(i, MobileMail.getInstance().getFrmNavegacao().getString(i), null); } i++; } } } public Image getSmallConfirmIcon() { return this.get_imgOkPequeno(); } /** Susbtitui uma substring em uma string * @param value - String original * @param oldValue - Substring a ser substituída * @param newValor - Valor pelo qual a substring oldValue será substituída */ private String stringReplace(String value, String oldValue, String newValue) { String res = new String(""); int pos = 0; if(value.indexOf(oldValue) > -1) { while(pos < value.length()) { if(value.substring(pos, pos + oldValue.length()).equals(oldValue)) { res += newValue; pos += oldValue.length();

141

} else { res += value.charAt(pos); pos++; } } } else res = value; return res; } public String getDiretorioAtual() { return this.diretorioAtual; } public void setDiretorioAtual(final String diretorioAtual) { this.diretorioAtual = diretorioAtual; } public Form getFrmGauge() { return this.get_frmGauge(); } public Command getComandoVoltarAnexar() { return this.get_comandoVoltarAnexar(); } public Form getFrmEnviaMsg() { return this.get_frmEnviaMsg(); } public Command getComandoListarAnexos() { return this.get_comandoListaAnexos(); } public Form getFrmAnexos() { return this.get_frmAnexos(); } public void enviaMensagem() { try { String url = this.get_tfServidor().getString(); url += this.getIdSession(); url += "?acao=sendMsg"; url += this.getDadosMensagem(); System.out.println(url); ControladorHTTP ctrlHTTP = new ControladorHTTP(this.get_frmEnviaMsg(), this.get_frmEnviaMsg()); ctrlHTTP.execute(new AcaoEnvioMensagem(url, "POST")); } catch(Exception e) { this.exibeMsg(AlertType.ERROR,this.get_frmLogin(), "MobileMail 1.0 - Erro", "Erro ao enviar mensagem de correio : " + e.getMessage()); } } private String getDadosMensagem() { String res = new String(""); res +="&remetente=" + this.get_tfUsuario().getString() + "@mobilemail.com.br"; if(this.get_tfAssunto() == null || this.get_tfAssunto().getString() == null || this.get_tfAssunto().getString().length() == 0) res +="&assunto=No subject"; else res += "&assunto=" + this.stringReplace(this.get_tfAssunto().getString(), " ", "%20"); if(this.get_tfPara() != null && this.get_tfPara().getString() != null && this.get_tfPara().getString().length() > 0) res += "&destinatarios=" + this.stringReplace(this.get_tfPara().getString(), " ", "%20"); if(this.get_tfCC() != null && this.get_tfCC().getString() != null && this.get_tfCC().getString().length() > 0)

142

res += "&destinatariosCC=" + this.stringReplace(this.get_tfCC().getString(), " ", "%20"); if(this.get_tfBCC() != null && this.get_tfBCC().getString() != null && this.get_tfBCC().getString().length() > 0) res += "&destinatariosBCC=" + this.stringReplace(this.get_tfBCC().getString(), " ", "%20"); if(this.get_frmEditor() != null && this.get_frmEditor().getString() != null && this.get_frmEditor().getString().length() > 0) res += "&corpoMensagem=" + this.stringReplace(this.get_frmEditor().getString(), " ", "%20"); else res += "&corpoMensagem=%20"; String[] anexo = this.getAnexos(); for(int i=0; i < anexo.length; i++) res += "&anexo=" + this.stringReplace(anexo[i], " ", "%20"); return res; } }

Anexo C – biblioteca mobileLib

Anexo C.1 – Pacote io

/* * ReaderWriter.java * * Created on 17 de Setembro de 2005, 16:35 * * To change this template, choose Tools | Options and locate the template under * the Source Creation and Management node. Right-click the template and choose * Open. You can then make changes to the template in the Source Editor. */ package io; import javax.microedition.rms.RecordStore; /** * * @author Rodrigo */ public class ReaderWriter { private RecordStore rs = null; private String recordStoreName; /** Creates a new instance of ReaderWriter */ public ReaderWriter() { } public ReaderWriter(String recordStoreName) { this.setRecordStoreName(recordStoreName); } /** Cria se necessário e abre um RecordStore com nome passado no parâmetro * recordStoreName. */ public void openRecordStore(String recordStoreName) throws Exception { rs = RecordStore.openRecordStore(recordStoreName,true); } /** Cria se necessário e abre um RecordStore com o nome contido no atributo

143

* recordStoreName */ public void openRecordStore() throws Exception { if(this.getRecordStoreName() != null) this.openRecordStore(this.getRecordStoreName()); } /** Exclui o RecordStore de nome igual ao parametro recordStoreName */ public void deleteRecordStore(String recordStoreName) throws Exception { if(RecordStore.listRecordStores() != null) { RecordStore.deleteRecordStore(recordStoreName); } } /** Exclui o RecordStore de nome igual ao atributo recordStoreName */ public void deleteRecordStore() throws Exception { if(this.getRecordStoreName() != null) this.deleteRecordStore(this.getRecordStoreName()); } /** Grava os dados contidos no parâmetro value num novo registro do RecordStore. */ public void addRecord(String value) throws Exception { byte[] rec = value.getBytes(); rs.addRecord(rec, 0, rec.length); } public void updateRecord(String value, int recordPos) throws Exception { byte[] rec = value.getBytes(); rs.setRecord(recordPos, rec, 0, rec.length); } /** Lê o conteudo do registro localizado na posicao passada no parâmetro recordPos. */ public String readRecord(int recordPos) throws Exception { byte[] rec = rs.getRecord(recordPos); String res = new String(rec,0,rec.length); return res; } /** Lê todos os registros contidos no RecordStore. */ public String[] readRecords() throws Exception { String[] res = new String[this.rs.getNumRecords()]; for(int i=1; i <= this.rs.getNumRecords(); i++) res[i-1] = this.readRecord(i); return res; } /** Exclui o registro da posição passada no parâmetro recordPos. */ public void deleteRecord(int recordPos) throws Exception { this.rs.deleteRecord(recordPos); } /** Exclui todos os registros contidos no RecordStore. */ public void deleteRecords() throws Exception { for(int i=1; i <= this.rs.getNumRecords(); i++) this.deleteRecord(i); } /** Fecha o RecordStore. */ public void closeRecordStore() throws Exception { this.rs.closeRecordStore(); } public String getRecordStoreName() { return this.recordStoreName; } public void setRecordStoreName(final String recordStoreName) { this.recordStoreName = recordStoreName; } }

144

Anexo C.2 - Pacote net

/* * HttpConection.java * * Created on 23 de Setembro de 2005, 02:06 * * To change this template, choose Tools | Options and locate the template under * the Source Creation and Management node. Right-click the template and choose * Open. You can then make changes to the template in the Source Editor. */ package net; import java.io.ByteArrayOutputStream; import java.io.InputStream; import java.io.OutputStream; import javax.microedition.io.Connector; import javax.microedition.io.HttpConnection; /** * * @author Rodrigo */ public class HttpConn { private javax.microedition.io.HttpConnection http = null; public static final byte POST = 0; public static final byte GET = 1; public static final byte HEAD = 2; /** Creates a new instance of HttpConection */ public HttpConn() { } /** Estabelece conexão HTTP com a URL especificada no parâmetro. */ public void connect(String url) throws Exception { http = (HttpConnection)Connector.open(url); } /** Desfaz a conexão. */ public void disconnect() throws Exception { if(http != null) http.close(); } /** Envia os dados utilizando o método GET. */ private String sendWithGET(String url) throws Exception { InputStream in = null; String res = null; try { http.setRequestMethod(HttpConnection.GET); in = http.openInputStream(); res = this.processServerResponse(http, in); } finally { if(in != null) in.close(); }

145

return res; } /** Processa as resposta do servidor. */ private String processServerResponse(HttpConnection http, InputStream in) throws Exception { String res = null; if(http.getResponseCode() == http.HTTP_OK) { int len = (int)http.getLength(); if(len == -1) { // Tamanho não disponível ByteArrayOutputStream buffer = new ByteArrayOutputStream(); try { int ch; while((ch = in.read()) != -1) buffer.write(ch); res = new String(buffer.toByteArray()); } finally { buffer.close(); } } else { // Tamenho disponível byte[] buffer = new byte[len]; in.read(buffer); res = new String(buffer); } } return res; } private String sendWithPOST(String url) throws Exception { InputStream in = null; OutputStream out = null; String res = null; try { out = http.openOutputStream(); http.setRequestMethod(HttpConnection.POST); http.setRequestProperty("Content-Type", "application/x-www-form-urlencoded"); if(url.indexOf("?") > -1) { String aux = url.substring(url.indexOf("?") + 1); while(aux.indexOf("=") > -1) { String param = aux.substring(0, aux.indexOf("=")); String valor; if(aux.indexOf("&") > -1) { valor = aux.substring(aux.indexOf("=") + 1, aux.indexOf("&")); aux = aux.substring(aux.indexOf("&") + 1); } else { if(aux.indexOf(";") > -1) { valor = aux.substring(aux.indexOf("=") + 1, aux.indexOf(";")); aux = aux.substring(aux.indexOf("=") + 1, aux.indexOf(";")); } else { valor = aux.substring(aux.indexOf("=") + 1); aux = aux.substring(aux.indexOf("=") + 1); } } byte[] dados = (param + "=" + valor).getBytes(); out.write(dados); } out.flush(); } in = http.openInputStream(); res = this.processServerResponse(http, in); } finally { if(in != null) in.close(); if(out != null) out.close(); } return res; }

146

public String send(String url, String metodo) throws Exception { if(metodo.equals(HttpConnection.GET)) return this.sendWithGET(url); else return this.sendWithPOST(url); } public String getHeaderField(String headerFieldName) throws Exception { return http.getHeaderField(headerFieldName); } }

UTILIZAÇÃO DA TECNOLOGIA J2ME PARA ACESSO AO SERVIÇO DE ...siaibib01.univali.br/pdf/Rodrigo Luiz...

Documents

Transcript of UTILIZAÇÃO DA TECNOLOGIA J2ME PARA ACESSO AO SERVIÇO DE ...siaibib01.univali.br/pdf/Rodrigo Luiz...