Embed Size (px)
Citation preview
UNIVERSIDADE DO VALE DO ITAJAÍ
SÉRGIO NICOLAU DA SILVA
ESTUDO DA PLATAFORMA BREW COM ÊNFASE NO DESENVOLVIMENTO DE UM PROTÓTIPO PARA CELULAR
São José 2005.
SÉRGIO NICOLAU DA SILVA
ESTUDO DA PLATAFORMA BREW COM ÊNFASE NO
DESENVOLVIMENTO DE UM PROTÓTIPO PARA
CELULAR
Trabalho de Conclusão de Curso apresentado à
banca examinadora do Curso de Ciência da
Computação na Universidade do Vale do Itajaí -
UNIVALI, Centro de Educação São José, como
requisito parcial para obtenção do título de
Bacharel em Ciência da Computação.
Orientador: Prof. Dr. Alexandre Moraes Ramos.
São José 2005.
SÉRGIO NICOLAU DA SILVA
SÉRGIO NICOLAU DA SILVA
ESTUDO DA PLATAFORMA BREW COM ÊNFASE NO
DESENVOLVIMENTO DE UM PROTÓTIPO PARA CELULAR
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é, 14 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. Dr. Paulo Roberto O. Valim, membro da banca examinadora
__________________________________________________
Prof. Dr. Paulo Roberto Riccioni, membro da banca examinadora
DEDICATÓRIA
Dedico este trabalho de conclusão de curso aos meus Pais, Juracy da Silva e
Nicolau Adolfo da Silva, pelo apoio, por me ensinar a ser a pessoa que sou hoje
e por sonhar junto comigo o que se torna agora uma realidade. À Luciana da
Rosa Ferreira e Silva que nestes cinco anos foi minha namorada, noiva e é minha
amável esposa, companheira, paciente e compreensiva.
AGRADECIMENTOS
Agradeço a Deus por ter me dado forças para superar mais esta fase de minha vida.
Aos meus familiares pela paciência e apoio prestado ao longo desta caminhada.
Aos amigos que compartilharam comigo os sofrimentos e alegrias nestes cinco anos de
estudos.
A coordenação do curso de Ciência da Computação pelo belo trabalho que realiza.
A todos os professores do curso de Ciência da Computação pela dedicação e apoio.
O conformismo é o carcereiro da liberdade e o inimigo do crescimento.
(Jonh Kennedy)
RESUMO
Este trabalho apresenta um estudo sobre a plataforma BREW para desenvolvimento de
aplicativos para celulares, disponibilizando as informações necessárias para os interessados
em desenvolver trabalhos na área por meio do desenvolvimento de um protótipo. Será
apresentada inicialmente uma revisão sobre tecnologias celulares identificando as partes que a
compõe e as diversas tecnologias disponíveis no mercado brasileiro tanto para serviços de voz
quanto para serviços de dados, além de algumas tendências do mercado mundial. Em nível de
desenvolvimento de software são apresentadas algumas das tecnologias de desenvolvimento
de soluções para celulares que estão disponíveis no mercado. Na segunda parte é realizado o
detalhamento da plataforma BREW, apresentando as partes que a compõe, focando
principalmente na preparação do ambiente de desenvolvimento Visual Studio .NET
integrando-o ao BREW SDK (BREW Software Development Kit). Em seguida é apresentada a
utilização prática dos componentes do SDK e, por meio de um código fonte comentado, a
forma de implementação de aplicações na plataforma BREW. Visando avaliar melhor a
plataforma será desenvolvido um protótipo que é um controle remoto total para residências
onde permitirá ao usuário acionar ou desligar qualquer ponto elétrico na residência como ligar
u desligar um ar-condicionado, alarme residencial, luz externa etc. Neste protótipo serão
utilizados os recursos de acesso a arquivos, conexão socket, tratamento de eventos e utilização
dos recursos de tela. Ao final serão apresentadas as considerações finais sobre a plataforma,
dificuldades encontradas e conclusão sobre os estudos realizados.
ABSTRACT
This work presents a study on platform BREW for development of applicatory for cellular,
provide the necessary information for the interested in developing works in the area by means
of the development of an archetype. A revision on cellular technologies will be presented
initially identifying the parts that in such a way compose it and the diverse available
technologies in the Brazilian market for services of voice how much for services of data,
beyond some trends of the world-wide market. In level of software development some of the
technologies of development of solutions for cellular are presented that they are available in
the market. In the second part detailing of platform BREW is carried through, presenting
parts that compose it, mainly focused in the preparation of the environment of Visual
development Studio NET integrating it it BREW SDK (BREW Software Development Kit).
After that it is presented the practical use the components of the SDK and, by means of a
commented code source, the form of implementation of applications in platform BREW.
Aiming at to evaluate the platform better it will be developed an archetype that are a total
remote control for residences where it will allow the user to set in on or off any electric point
in the residence as to on or off a air conditioning, residential alarm, external light etc. In this
archetype the archives will be used the file resources, connection socket, treatment of events
and use of the screen resources. To the end the final consideration on the platform will be
presented, joined difficulties and conclusion on the carried through studies.
SUMÁRIO
1 INTRODUÇÃO .............................................................................................................................................13
1.1 CONTEXTUALIZAÇÃO .....................................................................................................................13
1.2 PROBLEMA ..............................................................................................................................................14
1.3 OBJETIVOS ..............................................................................................................................................15
1.3.1 Geral ..................................................................................................................................................15
1.3.2 Específicos ........................................................................................................................................15
1.3.3 Escopo e Delimitação .......................................................................................................................15
1.4 RESULTADOS ESPERADOS .......................................................................................................................16
1.5 JUSTIFICATIVA ........................................................................................................................................16
1.6 ASPECTOS METODOLÓGICOS...................................................................................................................17
1.7 ORGANIZAÇÃO DO TRABALHO ................................................................................................................17
2 DESENVOLVIMENTO ...............................................................................................................................19
2.1 CONTEXTO ..............................................................................................................................................19
2.2 REDE CELULAR........................................................................................................................................20
2.2.1 Conceitos Básicos .............................................................................................................................20
2.2.2 Primeira Geração (1G)......................................................................................................................25
2.2.3 Segunda Geração (2G)......................................................................................................................27
2.2.4 Segunda Geração e Meia (2,5G) ......................................................................................................32
2.2.5 Terceira Geração (3G) ......................................................................................................................36
2.2.6 Quarta Geração (4G).........................................................................................................................41
2.3 TECNOLOGIAS PARA DESENVOLVIMENTO DE SOFTWARE.......................................................................42
2.3.1 Superwaba.........................................................................................................................................42
2.3.2 J2ME .................................................................................................................................................43
2.3.3 Visual Studio .NET...........................................................................................................................44
3 BREW .............................................................................................................................................................46
3.1 VISÃO GERAL..........................................................................................................................................46
3.2 BREW DISTIBUTION SYSTEM ......................................................................................................................47
3.3 BREW SDK (SOFTWARE DEVELOPMENT KIT) ........................................................................................49
3.3.1 Relação entre classes, módulos e aplicação .....................................................................................50
3.3.2 MIF(Module Information File) e o BAR(BREW Applet Resourse) ................................................51
3.3.3 SDK disponíveis ...............................................................................................................................51
3.4 PREPARANDO O AMBIENTE PARA DESENVOLVIMENTO ..........................................................................52
3.4.1 Requisitos mínimos...........................................................................................................................52
3.4.2 Instalando o SDK..............................................................................................................................52
3.4.3 Preparando o Visual Studio .NET ....................................................................................................55
3.5 CRIANDO UMA APLICAÇÃO BREW ........................................................................................................57
3.5.1 MIF Editor Configurando a aplicação ..........................................................................................58
3.5.2 Univali.c comentado .........................................................................................................................62
3.6 PROTÓTIPO: CONTROLE REMOTO PARA RESIDÊNCIA ..............................................................................66
3.6.1 Modelagem do protótipo...................................................................................................................68
3.6.2 Diagrama de classes de domínio ......................................................................................................73
3.6.3 Diagramas de seqüência ...................................................................................................................74
3.6.4 Implementando o protótipo ..............................................................................................................76
3.6.5 Arquitetura do ambiente ...................................................................................................................78
3.6.6 Interface IShell: Controlando a aplicação ........................................................................................78
3.6.7 Interface IDisplay: Manipulado a tela do celular.............................................................................79
3.6.8 Interfaces INetMgr e ISocket: Criando uma conexão Socket Stream (TCP) ..................................79
3.6.9 Interfaces IFileMgr e IFile: Manipulando arquivos.........................................................................83
3.6.10 Recursos visuais criados por meio do BREW Resource Editor .......................................................84
3.6.11 Criando e manipulando menus (IMenuCtl)......................................................................................86
3.6.12 Funcionamento do protótipo.............................................................................................................89
3.7 COMPARANDO FERRAMENTAS DE DESENVOLVIMENTO .........................................................................91
4 CONSIDERAÇÕES FINAIS .......................................................................................................................93
5 CONCLUSÃO E TRABALHOS FUTUROS.............................................................................................95
5.1 CONCLUSÃO ............................................................................................................................................95
5.2 TRABALHOS FUTUROS ............................................................................................................................97
ANEXO 1: UNIVALI.C..........................................................................................................................................98
ANEXO 2: MODELAGEM DO SERVIDOR....................................................................................................116
ANEXO 3: FONTE DO SERVIDOR (UNSERVIDOR.PAS)..........................................................................126
6 REFERÊNCIAS BIBLIOGRÁFICAS......................................................................................................133
LISTA DE FIGURAS
Figura 1: Topologia básica da rede celular. ......................................................................................20
Figura 2: Representação da célula em uma rede celular...................................................................22
Figura 3: Cluster de células. .............................................................................................................24
Figura 4: Representação da divisão do espectro de freqüência em canais (FDMA). .......................26
Figura 5: Estrutura dos timeslots TDMA..........................................................................................27
Figura 6: Espalhamento dos dados nas portadoras disponíveis. .......................................................29
Figura 7: Estrutura de frames e timeslots da GSM. ..........................................................................31
Figura 8: Evolução para redes 3G.....................................................................................................38
Figura 9: Modelo de negócio integrado do BDS. .............................................................................48
Figura 10: Tela de configuração do sistema. ....................................................................................54
Figura 11: Tela de configuração de variáveis de ambiente...............................................................55
Figura 12 : Ambiente configurado e com o BREWAppWizard disponível .....................................56
Figura 13: Recursos que a aplicação fará uso...................................................................................57
Figura 14: Tela Options ....................................................................................................................58
Figura 15: BREW MIF Editor ..........................................................................................................59
Figura 16: Informando um Class ID local ........................................................................................60
Figura 17: MIF Editor - Configuração da aplicação.........................................................................61
Figura 18: Configurando o modo Debug no Visual Studio ..............................................................65
Figura 19: Configuração do simulador .............................................................................................66
Figura 20: Controle remoto via celular.............................................................................................67
Figura 21: Casos de uso ....................................................................................................................68
Figura 22: Diagrama de classes de domínio .....................................................................................73
Figura 23: Diagrama de seqüência: Configurar Sistema ..................................................................74
Figura 24: Diagrama de seqüência: Conectar ao servidor ................................................................75
Figura 25: Diagrama de seqüência: Ligar / desligar ponto de controle ............................................76
Figura 26: Arquitetura do ambiente de simulação............................................................................78
Figura 27: BREW Resource Editor ...................................................................................................85
Figura 28: Criando um recurso .........................................................................................................86
Figura 29: Tela principal...................................................................................................................89
Figura 30: Tela de configuração .......................................................................................................90
Figura 31: Controle dos pontos.........................................................................................................91
LISTA DE TABELAS
Tabela 1: Faixas de freqüência disponíveis no mundo para GSM. ..................................................30
Tabela 2 Capacidade de dados das classes de terminais GPRS........................................................34
Tabela 3: Sistemas cdmaOne disponíveis.........................................................................................35
Tabela 4: Comparação dos sistemas CDMA. ...................................................................................40
Tabela 5: Modulações e esquemas de codificação EDGE................................................................41
Tabela 6: Caso de uso: Configurar sistema ......................................................................................69
Tabela 7: Caso de uso: Conectar no servidor ...................................................................................70
Tabela 8: Caso de uso: Verificar estados dos pontos de controle.....................................................71
Tabela 9: Caso de uso: Alterar estado de um ponto de controle.......................................................72
13
1 INTRODUÇÃO
1.1 CONTEXTUALIZAÇÃO
A evolução tecnológica nos últimos anos possibilitou ao mercado prover novos produtos e
serviços, atendendo as necessidades dos usuários. Uma das áreas cuja evolução tecnológica
promove um grande avanço é a telefonia, que permitiu ao usuário ter o acesso a este serviço
levando o terminal de acesso sempre com ele: o telefone celular.
A telefonia celular, que inicialmente veio atender a necessidade do mercado e dar mobilidade
ao serviço de voz, hoje é mais que isso: é acesso à Internet, contas de e-mail, conexão de
dados sem fio a qualquer instante, multimídia, além do serviço se voz. Isto se deve ao avanço
das redes, que têm capacidade para trafegar tais dados com a eficiência necessária, e a
evolução dos equipamentos, principalmente dos aparelhos celulares e similares onde por meio
destes os usuários usufruem dos serviços disponíveis.
Segundo a Anatel 1(2005b) em janeiro de 2005 eram 68,6 milhões de aparelhos celulares
habilitados. Além deste crescimento, os fabricantes de aparelhos celulares e similares
disponibilizam cada vez mais recursos tecnológicos nestes, tornando-os capazes de realizar
tarefas complexas, antes somente vistas em computadores, além da comunicação de voz. A
união do mercado em constante expansão com os aparelhos high tech nos dá a visão do
tamanho do mercado disponível para os envolvidos e interessados em atuar na telefonia
celular, principalmente no desenvolvimento de aplicativos que atendam as necessidades dos
usuários.
Nos dias de hoje, discute-se quais tecnologias dominarão o mercado, tanto em nível de acesso
ao serviço quanto para desenvolvimento de aplicações que satisfaça as necessidades dos
1 Agência Nacional de Telecomunicações é o órgão do governo brasileiro responsável pela regulamentação das
telecomunicações no Brasil.
14
usuários comuns e corporativos. O fato é que a concorrência é acirrada, empresas de
tecnologia apostam em seus padrões. Na área de desenvolvimento de software, novas
ferramentas e novos recursos são colocados no mercado a fim de conquistar a maior fatia
possível deste.
1.2 PROBLEMA
Uma das dificuldades das operadoras de telefonia celular era, inicialmente, identificar qual
tecnologia mais apropriada para o mercado em termos de evolução. Principalmente na
segunda geração (2G), muitas foram as tecnologias disponíveis e utilizadas pelas operadoras
de telefonia celular e, desta gama de tecnologia, destaca-se hoje duas delas: GSM (Global
System Mobile for Communitation) e CDMA (Code Division Multiple Acess). Segundo
Taurion (2002, p.18), em 2000 63% do mercado mundial eram baseados em GSM e 13% em
CDMA. O CDMA, um padrão que foi criado na época da segunda guerra mundial para evitar
que as mensagens fossem interceptadas pelos inimigos e o GSM, criado na década de 90 na
Europa, foi o padrão que conquistou mais mercado até hoje. Estas tecnologias serão vistas
com mais detalhes no capítulo 2.
O fato é que, pelos estudos efetuados pelo ITU (International Telecommunication Union) e
pelos serviços que serão prestados em médio prazo, a evolução baseada na CDMA se mostra
muito mais atraente e viável quando se fala em comunicação de dados a altas taxas de
transmissão (TAURION, 2002).
Existe ainda o problema de como prover os serviços em nível de aplicação, de uma forma
mais integrada e padronizada possível, ou seja, os softwares envolvidos no desenvolvimento,
distribuição e integração. Existem hoje algumas tecnologias que se destacam no mercado,
como a J2ME da Sun, Visual Studio .NET da Microsoft, Superwaba e a BREW da
Qualcomm.
Diante do exposto acima, as operadoras devem escolher as tecnologias buscando a melhor
solução para atender a demanda de mercado com o melhor custo benefício possível. Para a
tecnologia de acesso ao meio, a ITU já aponta a solução CDMA como a mais adequada,
tendência essa que deve ser seguida. A dificuldade está na plataforma de software para os
aplicativos fornecidos aos usuários.
15
É este problema, a escolha da melhor plataforma de software para prover serviços, que será
abordado neste trabalho, realizando os estudos sobre uma das plataformas: a Plataforma
BREW da Qualcomm, empresa detentora da tecnologia CDMA, apontada pela ITU como a
melhor opção para o futuro.
1.3 OBJETIVOS
1.3.1 Geral
Estudo da plataforma BREW com ênfase no desenvolvimento de um protótipo para celular.
1.3.2 Específicos
Conhecer as estruturas em nível de software do BREW SDK (BREW Software
Development Kit) para desenvolvimento de aplicativos para a plataforma BREW.
Abordar de forma geral o BDS (BREW Distribution System) que, junto com o BREW
SDK, compõe a solução BREW da Qualcomm.
Criar um protótipo que rode sobre a plataforma BREW, através do uso de um simulador
de telefone celular em um microcomputador.
Comparar de forma geral a plataforma BREW com outras disponíveis no mercado.
1.3.3 Escopo e Delimitação
Este trabalho vai focar seus estudos em uma breve explanação das tecnologias móveis,
apresentando sua evolução e conceitos gerais de algumas destas tecnologias, e na plataforma
BREW, realizando uma suscinta comparação com as demais plataformas que se destacam no
mercado: J2ME, Superwaba e Visual Studio .NET.
Para a BREW, serão apresentadas suas características, recursos disponíveis e, baseado em um
protótipo, a utilização de alguns recursos desta plataforma para o desenvolvimento de
software.
16
1.4 RESULTADOS ESPERADOS
Conhecer a BREW no que diz respeito à integração ponta-a-ponta proposta pela plataforma e
ter domínio sobre o ambiente de desenvolvimento de software para dispositivos móveis com
suporte a BREW.
Mapear as diferenças gerais entre a BREW e as demais soluções de mercado que serão
avaliadas no decorrer da pesquisa.
Demonstrar o funcionamento da plataforma relacionado ao módulo de suporte às tecnologias
disponíveis para desenvolvimento, através do protótipo implementado.
Vale ressaltar que os resultados esperados são em relação à plataforma BREW e não ao
protótipo desenvolvido para estudos da mesma.
1.5 JUSTIFICATIVA
Como está sendo vivenciada já há algum tempo no mundo do desenvolvimento de software,
principalmente nas empresas especializadas em fornecer soluções seguindo normas como ISO
e CMMI, um padrão se faz necessário para se projetar, implementar e implantar softwares de
forma eficiente e adequado ao mercado. E é este fator que está levando os fabricantes,
operadoras e desenvolvedores de soluções para celulares a buscar e adotar uma plataforma
para sistemas em serviço móvel celular, agregando valor a este segmento do mercado de
telefonia celular.
Existe hoje a tendência de alguns padrões serem adotados para o desenvolvimento de soluções
para celulares nas quais se destacam o J2ME (Java 2 Micro Edition) da Sun, Visual Studio
.NET da Microsoft e a BREW (Binary Runtime Environment for Wireless) da Qualcomm.
Adotar uma destas tecnologias no mercado da telefonia celular onde os usuários cada vez
mais buscam por soluções que atendam suas necessidades, pode fazer a diferença para colocar
a empresa em uma posição confortável no mercado. Uma plataforma integrada que permita
aos fabricantes disponibilizarem dispositivos compatíveis entre si, aos desenvolvedores
produzir aplicações sem preocupação com os dispositivos e às prestadoras o fornecimento
das aplicações e ter o controle tanto da distribuição como da cobrança dos serviços.
17
Devido ao ITU ter apontado as tecnologias baseadas no CDMA como a melhor escolha para o
futuro conforme Taurion (2002), ter no mercado brasileiro a operadora Vivo (que atua com
CDMA e a plataforma BREW) que em abril de 2005 ocupava o primeiro lugar em
participação de mercado com 38,82% dos celulares (ANATEL, 2005d), além dos estudos na
área de telefonia celular realizados por graduandos na UNIVALI normalmente serem
direcionados as tecnologias J2ME ou WAP (Wireless Application Protocol), será objeto de
estudo a plataforma BREW da Qualcomm, empresa detentora também da tecnologia de
acesso a rede CDMA. É importante salientar que esta plataforma pode ser aplicada
comercialmente independente da interface aérea que define a tecnologia de acesso.
1.6 ASPECTOS METODOLÓGICOS
Para realização do projeto será efetuada uma pesquisa bibliográfica baseadas em materiais
disponíveis no site da Qualcomm, além de livros e publicações relacionados a serviços na
telefonia móvel celular e a plataforma BREW, além do ambiente de desenvolvimento de
software para celulares.
Para o protótipo será utilizada a UML para modelagem, através da ferramenta de suporte e
uma ferramenta para desenvolvimento de software para telefones celulares, além de uma
ambiente de simulação em microcomputador.
Serão definidos os diagramas de caso de uso, classe de domínio e diagramas de seqüência
para o protótipo.
1.7 ORGANIZAÇÃO DO TRABALHO
Este trabalho abordará as tecnologias de acesso ao sistema celular e desenvolvimento de
software com ênfase na plataforma BREW da Qualcomm.
O capítulo 2 abordará inicialmente de uma forma geral as tecnologias celulares, desde a sua
criação até os dias atuais com uma breve previsão para o futuro, baseado em publicações. A
segunda e última parte abordará algumas das tecnologias para desenvolvimento de software
para dispositivos móveis
O capítulo 3 aborda mais profundamente a plataforma BREW da Qualcomm, que faz parte do
objetivo deste trabalho, explanando as partes que a compõe, focando no ambiente de
18
desenvolvimento de aplicações para celulares. Também será apresentado o protótipo para
estudos da plataforma, sua modelagem e descrição da utilização de alguns recursos da BREW.
No capítulo 4 serão apresentadas as considerações finais sobre os estudos realizados.
Ao final, no capítulo 5, será apresentada a conclusão dos estudos realizados, seguido das
fontes bibliográficas referenciadas no capítulo 6.
19
2 DESENVOLVIMENTO
2.1 CONTEXTO
A telefonia celular hoje é extremamente disseminada no mundo inteiro. Segundo a
Universidade Estadual de Londrina (1998) esta tecnologia surgiu em 1946 pela Bell
Telephone Company com uma única estação de rádio base
no próximo tópico será visto o
que é uma estação rádio base
atendendo a todos os terminais de telefone celular. Desde
então, foi aprimorada e expandida. Nos dias atuais, é muito comum ver um terminal celular.
No Brasil a telefonia fixa possui 42 milhões de acessos (ANATEL, 2005a) enquanto que a
móvel já ultrapassa a casa dos 68 milhões de acessos (ANATEL, 2005b). Estes números são
expressivos para o mercado e devem ser bem maiores no futuro, com as chamadas redes
convergentes, ou seja, um único número de acesso ao serviço tanto na fixa quanto na móvel.
O mercado brasileiro é atendido por várias operadoras de telefonia. Oficialmente, segundo a
Anatel (2005c), são 40 operadoras que se reúnem em grupos e formam outros 8 grandes
grupos: TIM, Claro, Vivo, Oi, Brasil Telecom Celular, Opportunity, Sercontel e Algar. Cada
uma destas 40 operadoras utiliza uma das tecnologias disponíveis que são: AMPS, TDMA,
CDMA e GSM.
Será apresentada a evolução tecnológica, o funcionamento de cada uma destas tecnologias,
quais são as tecnologias atuais que dominam o mercado brasileiro e o que o mercado mundial
aponta para o futuro da telefonia celular.
20
2.2 REDE CELULAR
O telefone fixo, ou seja, um aparelho telefônico com um par de fios metálicos que vão desde a
sua casa até uma central telefônica impede o aparelho de ser móvel pela dependência do par
de fios. Foi esta necessidade de mercado, a mobilidade, que deu início a uma revolução, ou
seja, substituir o par metálico pelo acesso por meio de ondas eletromagnéticas.
2.2.1 Conceitos Básicos
Um telefone celular é basicamente um rádio transmissor que se comunica com uma torre e
esta o conecta a uma rede de telecomunicação.
A figura 1 mostra a topologia básica de uma rede celular:
Figura 1: Topologia básica da rede celular. (adaptada por Sérgio N. da Silva) Fonte: Sharma (2001, p.18).
BSC
Torre de
Rádio
BSC
MSC
Estação móvel
Telefonia Fixa
HRL VRL
AUC
EIR
21
Com base na figura acima, descreve-se de forma geral os componentes da rede e seu papel na
composição desta topologia, conforme Sharma (2001).
Estação móvel: são os aparelhos celulares. Pode ser também outros dispositivos móveis com
capacidade de se comunicar com a rede celular como os PDA (Personal Digital Assistent).
Torre de Rádio: é por meio deste componente que a comunicação do celular se dá com a rede
de telecomunicações, também chamadas de ERB (Estação Rádio Base). Basicamente é a
forma de acesso que define a tecnologia celular adotada por cada operadora. Será visto mais à
frente os tipos e diferenças entre elas.
BSC (Base Station Controler): este componente é responsável por controlar uma ou mais
torres de rádio base, tanto em nível de efetuar uma conexão do móvel na rede para uma
ligação de voz ou dados quanto na execução do handoff que será estudado mais a frente.
MSC (Mobile Switch Center): é o componente responsável pelo controle de todas as BSC que
estão conectadas em qualquer uma das torres do sistema e, principalmente, pela comutação
dos terminais dentro da rede de celular e com a rede de telefonia fixa. Ela faz uso direto de
outros quatro elementos da rede: HLR, VLR, AuC e EIR.
HLR (home location register): é o componente responsável por fornece a MSC todas as
informações referentes aos terminais válidos da operadora, como status do terminal e
localização atual (em que torre de rádio ela está). A informação da localização do terminal é
atualizada pelas unidades móveis periodicamente, facilitando a comutação sempre que uma
chamada é encaminhada ou originada do móvel.
VLR (visitor location register): é o componente responsável por manter o cadastro dos
telefones visitantes para a operadora que atua na área onde está o terminal. Exemplificando,
quando um terminal da operadora A está ligado e operando na área de atuação da operadora
B, esta faz a identificação deste terminal, valida com a operadora A e configura-o como
visitante em sua rede.
AuC (authentication center): é o componente que fornece a MSC as informações necessárias
para validar um terminal em nível de serviço, ou seja, se o terminal que está solicitando a
utilização de um serviço da rede tem realmente permissão para tal. Podemos ainda citar
como exemplo um dispositivo móvel que foi configurado na rede sem permissão de efetuar
22
ligações DDI (Discagem Direta Internacional). Ao tentar efetuar uma ligação desta categoria,
a MSC verifica na AuC que este terminal não tem acesso, não permitindo assim a utilização
deste serviço.
EIR (Equipament Identify Register): é o componente que mantêm o registro dos terminais,
números de identificação na rede, número de série do aparelho, identidade na rede entre
outros.
O que deu nome à telefonia celular, basicamente, foi à forma como ela é constituída em nível
de acesso ao sistema, ou seja, a comunicação entre o terminal móvel e a torre de rádio.
Dornan (2001, p.42) reforça que
o termo celular costuma ser considerado pejorativo, representando os antigos
telefones analógicos ainda bastante populares em muitas regiões do mundo [...]
Entretanto, na verdade, quase todos os sistemas móveis são celulares: dependem de
uma rede de células[...]
Uma torre de rádio, em termos gerais, é um transmissor e receptor de ondas eletromagnéticas
que se comunica com a estação móvel. Cada torre de rádio tem um determinado alcance que
depende basicamente da sua potência para transmissão e da geografia ao seu redor. À área
atendida por uma torre de rádio recebe o nome de célula.
Figura 2: Representação da célula em uma rede celular.
Conforme podemos observar na figura 2, existem duas representações para a célula: a circular
e a hexagonal. A mais adotada é a hexagonal pois possibilita uma melhor visão do sistema,
Circular Hexagonal
Cobertura de uma área geográfica
23
auxiliando no entendimento da rede celular, como pode ser visto na figura 2. Então, quando
um terminal está na célula de uma torre ele faz a comunicação com esta para acessar o
sistema. No entanto, quando temos várias torres, existe uma fronteira entre elas. É nesta
fronteira que ocorrem dois fenômenos que são considerados crítico para um sistema de
telefonia móvel: o handoff e a interferência entre células.
O handoff ocorre quando um terminal em movimento sai da área de cobertura de uma torre e
se dirige para outra, então ela deve passar a se comunicar com a torre mais próxima. Segundo
Dornan (2001, p.44) são procedimentos muito complexos, por que a estação-base precisa
calcular com exatidão quando o usuário está atravessando a fronteira da célula .
Existem dois tipos de handoff: o hard handoff e o soft handoff.
O hard handoff é quando o terminal móvel não tem capacidade para estar conectado a mais de
uma torre de rádio ao mesmo tempo. Isso significa que a rede deve ser rápida o suficiente para
perceber que o terminal está numa área de fronteira entre torres e decidi o momento certo para
a transição, sem que a conexão entre a estação móvel e o sistema seja interrompido. Com isso,
uma transição entre torre pode não ocorrer quando: a estação móvel está se deslocando a uma
velocidade acima do limite suportado pela rede (100 Km/h para sistemas analógicos e 300
Km/h para digitais), quando não existir uma torre mais próxima para a conexão ou quando a
torre que deveria atender a estação móvel não possuir canais livres para a comunicação.
No caso do soft handoff a diferença básica é que a estação móvel consegue estar conectada a
mais de uma torre de rádio ao mesmo tempo durante a transição. Assim, uma torre só libera a
conexão com a estação móvel após a outra torre ter feito a conexão com sucesso. O soft
handoff é mais eficiente porém é bem mais complexo para ser implementado.
O outro fenômeno crítico, a interferência, ocorre sempre que torres vizinhas estão atuando nas
mesmas faixas de freqüência ou canais. Neste caso, se uma estação móvel está nesta área
simplesmente pára de funcionar pois ela não sabe identificar o sinal. Para que isso não ocorra,
o espectro de freqüência disponível deverá ser quebrado de tal forma que, cada torre utiliza
uma faixa de freqüência diferente das torres vizinhas. Esta técnica é chamada de cluster. A
figura 3 mostra uma rede onde os canais disponíveis foram divididos em 3 grupos, onde se diz
que para esta rede o tamanho do cluster é igual a 3 (DORNAN, 2001).
24
Figura 3: Cluster de células. Fonte: Dornan (2001, p.50).
Assim, quanto maior o tamanho do cluster de uma rede, menos canais estarão disponíveis
por estação de rádio. Dornan (2001, p.50) explica que
cluster com tamanho igual a três são pouco comuns em redes reais pois as células
não são exatamente hexagonais e nem todas tem o mesmo tamanho.[...] os sistemas
mais comuns usam tamanho de clusters iguais a sete ou doze [...]
A partir da utilização de tecnologias digitais nas redes de telefonia celular, um novo e
importante componente começou a fazer parte desta evolução: a codificação e decodificação
de voz em dados digitais, também conhecida por codec. Ele é o responsável por converter a
voz humana em sinal digital que será transmitido pelo móvel de origem e reconstroi o sinal
original na recepção deste no móvel de destino, sem que haja degradação do sinal, ou seja,
perda de informação.
Dornan (2001,p.58) diz que a maneira mais simples de digitalizar sinais sonoros é extrair
amostragens da forma de onda em intervalos regulares . Este é basicamente o funcionamento
do codec, retirando amostras da onda referente a voz a ser transmitida, convertendo-a em
dados digitais (bits) para a transferência e recuperação. Além da conversão para bits, também
faz uso de algoritmos de compressão dos dados, visando a otimização da utilização dos
recursos de rede, particularmente a banda disponível. No entanto, tornou-se um outro fator
preocupante para a rede celular, pois, para uma melhor qualidade de voz, um número maior
de amostras devem ser coletadas, mais dados digitais são gerados necessitando transmitir no
mesmo espaço de tempo fazendo uso de algoritmos mais eficientes para compactação,
controle de erros devem ser aplicados e conseqüentemente mais rápidos devem ser os codecs
e mais energia eles consumirão.
Canais 1, 4, 7, 10...
Canais 2, 5, 8, 11...
Canais 3, 6, 9, 12...
25
Esta é a base de um sistema móvel celular. O ponto que difere as tecnologias mais antigas das
atuais e futuras é a forma de acesso ao serviço, ou seja, como se dá a comunicação entre a
estação móvel e a torre de rádio. A seguir, serão apresentadas algumas tecnologias de acordo
com as gerações e os aspectos técnicos que as diferem.
2.2.2 Primeira Geração (1G)
As tecnologias de primeira geração ou 1G como são chamadas, são caracterizadas pela
comunicação analógica entre a estação móvel e a torre de rádio. Destaca-se o AMPS
(Advanced Mobile Phone System) que foi utilizada nas Américas, NMT (Nordic Mobile
Telephone) utilizada no Japão e a TACS (Total Access Communication System) na Europa
(SHARMA, 2001). No Brasil, a tecnologia analógica adotada para implantar o sistema de
telefonia celular foi a AMPS.
No AMPS aplica o FDMA (Frequency Division Multiple Access) em seu espectro de
freqüência disponível. O FDMA faz a multiplexação de acesso por divisão de freqüência. Na
verdade, é o mesmo sistema utilizado para transmissão de TV e rádio, onde para cada
portadora sintonizada no receptor um canal de TV ou rádio é captado. No caso da AMPS,
possui dois espectros disponíveis de freqüência de 25MHz, uma para transmissão da torre
para a estação móvel (conhecido como downlink) e outros para o sentido inverso (uplink)
onde, aplicando a FDMA, são criados vários canais de acesso de 30KHz no espectro de
freqüência disponível para o sistema (figura 3), onde efetivamente apenas 24KHz de cada
canal são utilizados para comunicação. Os outros 6KHz são desprezados para sanar o maior
problema existentes em sistemas FDMA que são as interferências entre canais vizinhos
(Dornan, 2001, p.50). Sobre cada canal de acesso é aplicada a técnica FM (Frequency
Modulation) onde existe uma freqüência portadora e sobre esta é feita a transmissão dos
dados modulados a freqüência, ou seja, uma variação no comprimento de onda.
Criando uma relação entre banda disponível (25 MHz) e tamanho dos canais criados pela
FDMA (30 KHz), verifica-se que o AMPS possui a capacidade máxima de 832 canais ou
comunicações simultâneas, porém, 42 são utilizados para controle (Dornan, 2001, p.49). Estes
canais de controle também são chamados de setup (ALENCAR, 2001, p.193).
26
Figura 4: Representação da divisão do espectro de freqüência em canais (FDMA).
Para o AMPS utilizado nas Américas, possui as seguintes características (Dornan, 2001,
p.51):
Espectro de freqüência para downlink: 869 a 894 MHz
Espectro de freqüência para uplink: 824 a 849 MHz
Espectro total do canal: 30KHz
Espectro útil: 24 KHz
Capacidade máxima de transmissão de dados: 9,6 kbps
Para que haja uma comunicação entre estação móvel (ES) e torre de rádio (TR), a ES aloca
junto a TR dois canais de controle e negocia através destes quais canais de voz serão
utilizados para a comunicação. Com isso, para cada chamada telefônica em andamento na
rede, existe entre móvel e torre a ocupação de 4 canais.
Esta é uma das tecnologias que compões a 1G e que possibilitaram disponibilizar o serviço de
voz com mobilidade, porém, algumas deficiências destas tecnologias não permitiam que
novos serviços pudessem ser oferecidos ao mercado, como comunicação de dados mais
rápida. Além disso é de fácil quebra de sigilo do sinal pois não existe nenhuma preocupação
de segurança.
Para sanar estas deficiências, foram concebidos os sistemas de segunda geração (2G)
apresentados a seguir.
27
2.2.3 Segunda Geração (2G)
Nesta geração, novos conceitos foram definidos e a utilização de tecnologia digital foi
aplicada, visando prover serviços com melhor qualidade e segurança aos usuários. Vários
padrões foram oferecidos ao mercado e cada operadora de telefonia celular acabou adotando o
que entendia como a melhor opção para a evolução de suas redes.
No Brasil, os padrões adotados pelas operadoras foram o TDMA (Time Division Multiple
Acess), CDMA (Code Division Multiple Acess) e o GSM (Global System for Mobile
Communication).
O TDMA é baseado na tecnologia AMPS, ou seja, possui um espectro de freqüência
disponível, realizando o FDMA nestes criando canais com banda de 30KHz cada. As
diferenças são basicamente duas: transmissão digital dos dados e aplicação do conceito de
timestlots nos canais. O timeslots é a divisão do canal em intervalos de tempo (Alencar, 2001,
p. 176). No caso do TDMA, cada canal é dividido em três intervalos de tempo, ou seja, cada
canal, também conhecido como frame, é compartilhado (multiplexado) entre três usuários. Na
comunicação entre estação móvel e torre de rádio, são utilizados dois timeslots, um para
uplink e outro para downlink que possuem estruturas diferentes A figura 5 mostra a estrutura
dos frames e seus timeslots, além do tamanho em bits e tempo de duração de cada estrutura.
Figura 5: Estrutura dos timeslots TDMA. (adaptado por: Sérgio N. da Silva) Fonte: Dornan (2001, p. 78).
28
Analisando a figura 5, percebe-se que o frame E está destacado no multiframe. Este é
utilizado para sinalização do sistema.
Com isso, uma estação móvel inicia sua comunicação com a torre de rádio através de um
timeslot de controle pré-definido na configuração da rede, recebendo a identificação de qual
canal e timeslot deve ocupar para a transferência dos dados. Quando está em comunicação, o
aparelho só transmite no seu timeslot, ficando em silêncio durante todo o tempo restante dos
demais timeslots do mesmo canal.
Segundo Alencar (2001), a capacidade de transmissão de um canal é de 48,6 kbps ou seja,
16,2 kbps por timeslot e, conseqüentemente, por usuário conectado. Destes 16,2 kbps, 7,95
kbps (49%) é referente a voz codificada (saída do codec), 5,05 kbps (31%) para controle de
erro e 3,2 kbps (20%) para controle do sistema de telefonia celular.
Com essa digitalização foi possível aumentar a segurança das redes, além de fornecer novos
serviços como o SMS (Short Message Service) para troca de mensagens de texto curtas (até
160 caracteres) e identificador de chamadas. Além disso, a realização do handoff foi
aperfeiçoada. Nesta tecnologia, a estação móvel faz uso da técnica chamada MAHO (Mobile
Assisted Handoff) que realiza uma verificação das torres de rádio as quais ela consegue
contato via canais de controle e encaminha estas informações a torre a qual ela está
efetivamente conectada no momento. De posse destas informações, a torre atual define qual a
melhor opção de torre destino para realizar handoff com a maior segurança possível (Alencar,
2001, p. 176).
Outra tecnologia de segunda geração é a CDMA (Code Division Multiple Access) da empresa
Qualcomm, cujo desenvolvimento no setor de tecnologias celulares teve a mesma
repercussão que a Microsoft em software para PC e da Cisco em hardware para redes
(DORNAN, 2001, p.53).
O CDMA, também conhecido por IS-95, é baseado no DSSS (Direct Sequence Spread
Spectrum), onde exige uma largura de banda de canal de 1,25MHz, bem maior que os 30KHz
do TDMA. No entanto, apesar das exigências aparentemente grandes, o espectro realmente é
aproveitado de maneira mais eficaz do que em outros sistemas, por causa da possibilidade de
ser compartilhado por transmissões diferentes (DORNAN, 2001, p. 53).
29
Figura 6: Espalhamento dos dados nas portadoras disponíveis. Fonte: Oliveira e Filho (2003).
O DSSS é uma forma de utilização de toda a faixa de freqüência disponível através do
espalhamento de espectro. Basicamente, a transmissão é feita de forma pseudo-aleatória em
todas as portadoras disponíveis conforme figura 6. A forma é considerada pseudo-aleatória
pois, na prática, esta seqüência deve ser conhecida tanto pelo transmissor quanto pelo receptor
do sinal.
Ao transmitir, a estação móvel gera a seqüência pseudo-aleatória de canais e realiza a
transmissão dos dados em todas as portadoras do sistema. Para que o receptor identifique a
que estação móvel pertence o sinal, cada conexão transmissor-receptor é provida com um
código particular, de tal forma que as conexões simultâneas são diferenciadas por códigos
distintos e com baixa correlação entre si . (Waldman e Yacoub, 1999, p. 56). Segundo Dodd
(2000, p. 378), este código tem tamanho de 40 bits e é chamado de walesh code.
Com esta tecnologia, todas as estações móveis são capazes de utilizar todo o espectro de
freqüência disponível, ou seja, mais de uma estação móvel utilizando a mesma banda ao
mesmo tempo. Se isso é possível, mais de uma torre de rádio também pode utilizar as mesmas
freqüências, o que não acontecia com o TDMA e AMPS que necessitam de configuração de
clusters na rede. Esta característica permite aos sistemas que utilizam CDMA realizar o soft
handoff, isto é, estar conectado a mais de uma célula ao mesmo tempo. Neste sistema, o que
difere então uma célula de outra é a defasagem entre os códigos (walesh code), onde após a
estação móvel realizar o procedimento com segurança, libera código da célula de origem,
ficando apenas conectada a célula de destino.
30
O CDMA possibilita então taxas de transferência de 9,6 kbps e / ou 14,4 kpbs (configurável
pela operadora de telefonia), com uma taxa de espalhamento de até 1,22 Mbps para
portadoras de 1,25 MHz (Waldman e Yacoub, 1997, p. 58).
Mesmo a CDMA sendo a mais indicada para a evolução das redes para as próximas gerações,
a tecnologia de 2G que mais conquistou mercado foi a GSM, que teve seu início em 1982
através de um grupo de trabalho chamado Groupe Spéciale Mobile que, inicialmente, batizou
a tecnologia como GSM. Em 1988 o grupo GSM começou a fazer parte do ETSI (European
Telecommunications Standards Institute) que testou e disponibilizou comercialmente a
tecnologia GSM em 1992, onde o significado da sigla GSM passou a ser Global System for
Mobile Communication (ALENCAR, 2001, p.175).
A GSM é baseada na TDMA, ou seja, divisão de cada canal em timeslots. No caso da GSM, a
banda disponível para cada canal é de 200KHz e para cada canal são criados 8 timeslots (na
TDMA eram 30KHz com 3 timeslots). Esta tecnologia foi projetada para atender o mercado
utilizando a faixa de freqüência de 900MHz na Europa, no entanto foi licenciada para novas
bandas conforme tabela abaixo:
Tabela 1: Faixas de freqüência disponíveis no mundo para GSM.
Tipo de GSM Freqüência uplink Freqüência downlink 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
Fonte: Dornan (2001, p.67)
A GSM 450 é a mais recente e foi disponibilizada para substituir as redes analógicas baseadas
na tecnologia NMT (Nordic Mobile Telephony). A GSM 900 foi a primeira e também com o
objetivo de reaproveitar a faixa disponível para telefonia analógica na Europa. No caso da
DCN 1800, foi licenciada também para a Europa, sendo a faixa de 1800 MHz exclusiva para
uso do GSM e a PCS 1900 para a faixa dos 1900 MHz porém disponibilizada nas Américas.
(DORNAN, 2001, p.66).
31
A capacidade máxima de transmissão de um canal na tecnologia GSM é de 270,8 kbps, taxa
essa possibilitada pela utilização de um sistema de modulação de canais chamado de GMSK
(Gaussian Minimum Shift Keying). Como cada canal possui oito timeslots, a capacidade
máxima por timeslot é de 33,9 kbps. A figura a seguir mostra a estrutura de frames e seus
timeslots.
Figura 7: Estrutura de frames e timeslots da GSM. (adaptado por: Sérgio N. da Silva) Fonte: Dornan (2001, p.69).
A GSM utiliza dois frames - no caso da figura 7 são o E e R - do conjunto multiframe: um
para controle do sistema e outro para utilização em serviços como SMS e identificador de
chamadas. Quando um timeslot é utilizado para comunicação, este transporta todas as
informações que se deseja transmitir, também possibilita ao sistema identificar se o timeslot
está transportando dados ou voz, ou ainda se são dados do próprio sistema para controle deste,
além dos dados propriamente ditos com seu controle de erro, criptografias e outros.
Com todas estas informações sendo transmitidas dentro de um timeslot, sua capacidade de
dados de usuários efetivamente transmitidas cai a aproximadamente um terço do total,
dependendo principalmente do codec utilizado pela rede e estação móvel para codificar voz e
dados (DORNAN, 2001, p.69).
Tecnologias de segunda geração então disponibilizaram ao mercado uma telefonia celular
digital, de melhor qualidade que a 1G, mais segurança das informações transmitidas via
interface aérea, além de serviços como troca de mensagens e identificador de chamadas.
32
O mercado de transmissão de voz alcançou então um grau de qualidade satisfatório, mas a
transmissão de dados ainda era relativamente lenta para nas necessidades multimídias. Estas
sim necessitam de altas taxas de transferência, possibilitando várias novas facilidades aos
usuários como vídeo conferência, assistir a filmes e acesso a Internet sem fio. Para atender
estas necessidades, foram concebidas as tecnologias consideradas 2,5 G e 3G, que serão vistas
a seguir.
2.2.4 Segunda Geração e Meia (2,5G)
Esta geração é, na verdade, um aprimoramento das tecnologias de segunda geração, porém,
dando a elas uma maior capacidade para comunicação de dados. Algumas das tecnologias
existentes, e que serão abordadas neste tópico, são: HSCSD, GPRS e cdmaOne.
O padrão HSCSD (High Speed Circuit Switched Data) é uma atualização muito simples para
o GSM, fornecendo a cada usuário mais de um timeslot na operação de multiplexação
(DORNAN, 2001, p.70). Entre as características deste padrão, estão:
Utilização de codec específico para comunicação de dados permitindo uma
taxa de transferência de 14,4 kbps;
Permite agrupar até 4 timeslots subseqüentes para a transmissão de dados,
elevando a taxa para 57,6 kbps;
Permite transferência dos dados entre estação móvel e torre de forma
assimétrica, ou seja, taxa de download diferente da taxa de upload;
No entanto, este padrão possui alguns problemas. Na maioria das regiões onde o GSM é
utilizado as redes já estão chegando ao seu limite, o que dificultaria a implantação já que seria
necessário investimento para ampliação da rede, já que um cliente que utiliza o HSCSD
necessitaria de, teoricamente, quatro vezes mais de banda disponível. Além disso, o fato de
um terminal móvel ter que transmitir quatro timeslots subseqüentes provoca um aumento no
consumo de energia e de emissão de radiação, sem mencionar que as primeiras estações
móveis com suporte a transferência plena no HSCSD literalmente incendiaram (Dornan,
2001, p.71). Neste caso, a melhor opção para o HSCSD era o sistema assimétrico, com
velocidades maiores de download do que uploads, o que atende perfeitamente a navegação na
Internet que tem justamente esta característica.
33
Já o GPRS (General Packet Radio Service) foi o padrão que melhor se adaptou as redes GSM
no mundo. Nesta tecnologia foi aplicada a técnica de comutação de pacote, muito utilizada
nas redes de computadores, ao invés da comutação de circuito como é feito na GSM e
HSCSD. Segundo Dornan (2001, p.73) a comutação de pacotes usa a largura de banda
apenas quando necessário, liberando intervalos de fluxo de dados para outros usuários . Isso
significa que um único timeslot com taxa de 14,4 kbps pode ser compartilhado entre vários
usuários, no entanto, a transmissão neste é permitida apenas um usuário por vez.
Desconsiderando o problema de consumo de energia que acabava levando as estações móveis
a se incendiarem e que também é enfrentado pela tecnologia GPRS, o limite teórico da taxa de
transferência neste sistema é de 115,2 kbps, ou seja, a utilização de oito timeslots
subseqüentes.
Ainda segundo Dornan (2001, p.73) existe no mercado a tendência de realizar todo o tipo de
transferência de informação, seja ela voz ou dados, através de GPRS. No caso específico de
voz, o sinal analógico seria tratado por um codec de velocidade variável para satisfazer as
necessidades. Esta é uma visão de futuro, pois, hoje o GPRS depende o GSM para existir, ou
seja, os telefones celulares necessitam suportar os dois tipos de comutação: pacotes e
circuitos.
Para padronizar os projetos de telefones celulares com suporte a GPRS, foram definidos três
modos distintos chamados de graus A, B e C. Telefones de grau A são capazes de transmitir
simultaneamente dados por comutação de pacote e circuito, ou seja, ele permite que o usuário
realize uma chamada de voz enquanto está no processo de envio de um e-mail. Os aparelhos
classificados como grau B permitem ao usuário possuir as duas conexões simultâneas, porém,
na de dados (comutação por pacote) ele somente recebe pacotes. Exemplificando ele pode
estar falando ao telefone e receber uma notificação que tem um novo e-mail em sua conta de
correio eletrônico. Já o grau C é literalmente ou um ou outro, ou seja, caso o usuário esteja
navegando na Internet e uma chamada de voz é solicitada, o aparelho suspende a comutação
por pacote
não há a desconexão
inicia a comutação de circuito para a chamada de voz,
retomando a de pacotes assim que finalizada a ligação.
Além do grau do GPRS, também foram definidas classes, onde em cada uma das 29 existentes
(ver tabela 2) são especificadas as quantidades máximas de timeslots que serão alocados tanto
no uplink quanto downlik, definindo ainda se é possível realiza comunicação no modo full
duplex. Como exemplo, para atingir a taxa máxima de transferência que é de 115,2 kbps, um
34
aparelho celular deve ser da classe 18. Nesta está definido que o sistema fará uso de 8
timeslots para cada link com comunicação full duplex em uma rede GPRS.
Tabela 2 Capacidade de dados das classes de terminais GPRS
Timeslots utilizados (máximo) Capacidade (kbps) Classe
Downlink Uplink Total
Lacuna
entre slot Downlink Uplink
Full
duplex Redes
01 1 1 2 3 14,4 14,4 Sim GMS,GPRS
02 2 1 3 3 28,8 14,4 Sim HSCSD, GPRS
03 2 2 3 3 28,8 28,8 Não HSCSD, GPRS
04 3 1 4 3 43,2 14,4 Sim HSCSD, GPRS
05 2 2 4 3 28,8 28,8 Sim HSCSD, GPRS
06 3 2 4 3 43,2 28,8 Não HSCSD, GPRS
07 3 3 4 3 43,2 43,2 Não HSCSD, GPRS
08 4 1 5 3 57,6 14,4 Sim HSCSD, GPRS
09 3 2 5 3 43,2 28,8 Sim HSCSD, GPRS
10 4 2 5 3 57,6 28,8 Não HSCSD, GPRS
11 4 3 5 3 57,6 43,2 Não HSCSD, GPRS
12 4 4 5 2 57,6 57,6 Não HSCSD, GPRS
13 3 3 6 1 43,2 43,2 Sim HSCSD, GPRS
14 4 4 8 1 57,6 57,6 Sim HSCSD, GPRS
15 5 5 10 1 72,0 72,0 Sim GPRS
16 6 6 12 1 86,4 86,4 Sim GPRS
17 7 7 14 1 100,8 100,8 Sim GPRS
18 8 8 16 0 115,2 115,2 Sim GPRS
19 6 2 8 3 86,4 28,8 Sim GPRS
20 6 3 8 3 86,4 43,2 Não GPRS
21 6 4 8 3 86,4 57,6 Não GPRS
22 6 4 8 2 86,4 57,6 Não GPRS
23 6 6 8 2 86,4 86,4 Não GPRS
24 8 2 8 3 115,2 28,8 Não GPRS
25 8 3 8 3 115,2 43,2 Não GPRS
26 8 4 8 3 115,2 57,6 Não GPRS
27 8 4 8 2 115,2 57,6 Não GPRS
28 8 6 8 2 115,2 86,4 Não GPRS
29 8 8 8 2 115,2 115,2 Não GPRS
Fonte: Dornan (2001). Adaptado por: Sérgio N. da Silva.
35
O cdmaOne é um padrão desenvolvido pela Qualcomm para as redes que utilizam o CDMA.
Basicamente faz a transferência de dados da mesma forma que o CDMA realiza para voz.
Este padrão utiliza código walesh code (ver página 23) de 64 números, onde cada número é de
64 bits, calculados de tal forma que um número acabe cancelando o outro. Além disso, cada
bit a ser enviado é multiplicado pelo código, que é individual por usuário, ou seja, cada bit de
dado é enviado 64 vezes, viabilizando uma velocidade total de 19,2 kbps no downlink mas o
aparelho ouve os vários canais a uma taxa 64 vezes maior, ou seja 1228,8 kbps (Dornan,
2001, p.81).
Em teoria, com esta técnica poderia haver até 64 usuários transmitindo ao mesmo tempo por
canal disponíveis. Na prática foi constatado um limite de 10 a 20 usuários para um bom
desempenho do sistema. Além desta limitação prática, não são somente os bits que são
transmitidos 64 vezes. Este fator de multiplicação também se aplica à energia utilizada para
transferir um bit e a quantidade de irradiação a qual o usuário é exposto. Para solucionar este
problema, um rigoroso controle é realizado pelo aparelho na transmissão, visando deixar o
aparelho com o mínimo de atividade possível e garantir que o nível dos sinais seja
praticamente o mesmo para todos na torre de rádio, garantindo assim que todos os aparelhos
sejam ouvidos pela torre com igualdade de intensidade de sinal. As duas versões
disponíveis de cdmaOne são apresentadas na tabela a seguir.
Tabela 3: Sistemas cdmaOne disponíveis.
Nome da versão Freqüência uplink
Freqüência downlink
Tamanho da célula Concorre com
TIA/EIA/IS-95A 824 849 MHz 869 894 MHz Maior possível TDMA / D-AMPS
ANSI
J-STD-008
1850
1910 MHz
1930
1990 MHz
Menor possível
GSM
Fonte: Dornan (2001, p.83).
36
2.2.5 Terceira Geração (3G)
Segundo Dornan (2001), para identificar uma tecnologia de terceira geração, foi estipulado
um parâmetro básico que deve ser atendido: ser capaz de transmitir informações a uma taxa
mínima de 144 kbps em condições normais de operação e não limites máximos, como o que
acontecia com algumas tecnologias da 2,5G.
A ITU (International Telecommunication Union) em 1992 percebeu a importância que a
telefonia celular teria no futuro, concorrendo com a telefonia fixa. Então foi criado um projeto
que disponibilizou hoje o que conhecemos como o conjunto de normas para a terceira geração
de celular chamado de IMT-2000 (International Mobile Telecommunications 2000). Na
época, a visão da ITU era a convergência dos serviços de telefonia convencional, Internet e
aplicações multimídias e definiu seis classes de serviços que devem ser suportados pela 3G
(DORNAN, 2001):
Voz: além do serviço de voz que conhecemos, sempre prezando a qualidade destes, inclui-se
nesta definição o correio de voz integrado com o e-mail através da síntese e reconhecimento
da voz. Necessita de uma taxa simétrica 28,8 kbps utilizando circuitos virtuais (circuitos
criados sobre comutação de pacote).
Mensagens: mensagens incluem e-mail com anexos e troca de mensagens para efetuar
transações financeiras. Possui as mesmas taxas do serviço de voz, porém, utiliza comutação
de pacote.
Comutação de dados: possibilitar a conexão de dados para redes corporativas ou Internet,
via acesso discado ou conexão sempre ativa, além de serviços de fax. A conexão através de
discagem deve ser mantida para atender equipamentos mais antigos que ainda utilizam esta
forma de conexão. Taxa de 43,2 kbps simétrica sobre circuito virtual.
Meio de multimídia: permitir o acesso a Web, trabalhos de colaboração, jogos e mapas para
localização. Utiliza 19,2 kbps para upload e 768 kbps de download com comutação de
pacote.
Multimídia de alto nível: neste nível, será possível acesso a Web a alta velocidade, com
qualidade de imagem em alta definição e som com qualidade de CD, além de comércio
37
eletrônico de músicas, vídeos, softwares, entre outros. Dados com taxa de 2Mbps para
download e 20 kbps para upload com comutação de pacote.
Multimídia interativa de alto nível: realizar vídeo conferência e vídeo fones com qualidade
suficiente para proporcionar a telepresença . Taxas de 256 kbps simétrica sobre circuito
virtual.
Para se conseguir um aumento na taxa de transmissão, basicamente se utiliza duas técnicas:
utilização de banda extra de espectro e modulação utilizando sistema octal ao invés do
binário. Um outro fator é que a tendência é utilizar como base o CDMA, devido a sua
capacidade para lidar com novos usuários (DORNAN, 2001).
O fato é que deve existir um plano para migrar as redes atuais de 2G e 2,5G para as de 3G.
Conforme Dornan (2001, p.105), originalmente a ITU desejava um padrão global único, mas
isso não foi conseguido . O principal problema enfrentado para tal migração é a
compatibilidade entre sistemas. Dornan (2001) apresenta três compatibilidades necessárias
apontadas pela ITU:
Atualizações diretas: é o aperfeiçoamento do sistema atual das operadoras, adicionando a
comutação por pacote e um melhor sistema de modulação do sinal sem alterar o tamanho das
células e a estrutura de canais existentes.
Roaming: para o ITU, está relacionado a um telefone móvel que suporte vários sistemas
diferentes possibilitando que seja utilizado em todo o mundo. Alguns aparelhos poderão
suportar todos os sistemas, mas inicialmente, suportarão apenas um.
Handoff: possibilitar o handoff entre redes de tecnologias diferentes sem que o usuário
perceba. A única situação em que se admite que o usuário identifique a mudança é quando,
por exemplo, está usando um serviço disponível somente para 3G, como uma vídeo
conferência, e faz um handoff para uma rede de 2G. Neste caso a vídeo conferência será
interrompida pois a rede 2G não suporta.
Para ITU, a escolha para migrar as redes para a 3G é a utilização de dois padrões que possuem
características técnicas que permitem a existência destes com os anteriores, sem prejuízos aos
usuários: cdma2000 e W-CDMA. Dornan (2001, p.95) mostra uma espécie de gráfico que
38
traça os caminhos para a migração das tecnologias mais utilizadas no mundo para redes para a
3G com a maior compatibilidade possível.
Figura 8: Evolução para redes 3G. (adaptado por: Sérgio N. da Silva) Fonte: Dornan (2001, p.95).
Além da W-CDMA e a cdma2000, existe ainda o padrão EDGE que surgiu e posteriormente
foi considerado um sistema padrão IMT-2000.
O W-CDMA (Wide CDMA) foi projetado para permitir o handoff entre ela e uma rede GSM
no modo hard handoff já que o GSM não faz soft handoff, porém, uma rede GSM não pode
ser atualizada para W-CDMA. Para permitir uma maior velocidade na transferência de dados,
esta tecnologia adotou uma banda de 5MHz
o CDMA utiliza 1,25MHz
fato que batizou a
tecnologia com o nome atual.
Uma outra característica desta tecnologia é o ajuste do ganho conforme a intensidade do sinal,
onde cada bit é enviado de 4 a 128 vezes, ao contrário do cdmaOne que sempre envia os bits
64 vezes (DORNAN, 2001). Com esta técnica utilizando códigos variáveis, chamados de
código Gold, e a modulação do cdmaOne, esta tecnologia chega a taxas de 4Mbps por canal
em cada célula. Após 1996, o W-CDMA passou a ser conhecida na Europa como UMTS.
Para as redes cdmaOne, um conjunto atualizações da rede em nível de software e modulação
foi disponibilizado denominado de CDMA 2000. Segundo Dornan (2001, p.109) até a
metade de 2000, parecia claro o percurso para atualização do cdmaOne. O produto final era
considerado como um sistema chamado cdma2000 3XMC por combinar 3 canais, resultando
cdma2000
PDC
GSM
AMPS / TDMA
cdmaOn
HSCSD
GPRS
D-AMPS+
cdmaTwo
EDGE
W-CDMA
1XMC
HDR
1Xtreme
3XMC
Sistema 2G
Sistema 3G
Fácil adaptação Necessidade de nova modulação Troca dos sistemas de rádio
Atualizações previstas para migração Gerações
39
em uma banda mais larga . O problema era que este sistema não possuía compatibilidade com
o W-CDMA utilizado na Europa e Japão.
Existem muitas características equivalentes entre as duas tecnologias. Basicamente o que
diferencia uma da outra é a freqüência de ressonância do transceptor, onde a do cdma2000
necessita ser múltiplo da cdmaOne, mas a do W-CDMA precisa ser adequada à estrutura do
GSM para possibilitar a compatibilidade de handoff. Procurando buscar uma solução para este
problema, a Motorola e Nokia lançaram o 1Xtreme, prometendo bem próximas às do 3XMC
só que utilizando um canal ao invés de três, proporcionando as operadoras que utilizam
cdmaOne evoluir as redes para capacidades superiores as demais tecnologias concorrentes. Na
figura 8, é apresentada a cdma2000 como um conjunto de 4 tecnologias, com a seqüência de
evolução entre elas para se chegar a velocidades de 3G: 1XMC, HDR, 3XMC e 1Xtreme.
A 1XMC faz uso de multiportadoras e é a evolução inicial para as operadoras que utilizam a
cdmaOne. Para isso, elas devem realizar um upgrade no hardware das estações bases sem
alterar as interfaces de rádio (antenas). Além disso, esta evolução utiliza duas vezes cada
código Walsh, prometendo o dobro de velocidade do cdmaOne. 3XMC é o que a ITU
considera como a que atende as especificações IMT-2000, com desempenho idêntico ao W-
CDMA. O que o ITU ainda está aguardando são telefones celulares capazes de suportar
freqüências de ressonância variáveis, permitindo assim a utilização destes tanto com W-
CDMA quanto 3XMC.
O HDR é uma proposta da Qualcomm para aumentar a capacidade de transferência de um
canal de 1,25 MHz do 1XMCD, chegando a taxas de 2,4 Mpbs para downlink e 307,2 kbps
para uplink. Estas velocidades são compartilhadas por todos os de uma célula, sendo que
apenas 29 telefones conectados ao mesmo tempo. A baixa velocidade de uplink é motivado
pela aplicação de TDMA, além do CDMA, nos canais que são divididos em 240 timeslots.
Uma outra característica que limita esta tecnologia é que o HDR é somente aplicado a
comunicação de dados e não de voz.
1Xtreme é o padrão especificado pela Nokia e Motorola para concorrer com o HDR. A
diferença básica é que ele pode ser aplicado tanto para dados como para voz. Na tabela a
seguir pode se verificar as velocidades disponíveis para cada sistema.
40
Tabela 4: Comparação dos sistemas CDMA.
Sistema CDMA Banda do Canal Ressonância Taxa máxima Taxa Real
cdmaOne 1,25 MHz 1,2288MHz 115,2 kbps 64 kbps
cdma2000 1XMC 1,25 MHz 1,2288MHz 384 kbps 144 kbps
cdma2000 1Xtreme 1,25 MHz 1,2288MHz 5,2 Mpbs 1200 kbps
cdma2000 HDR 1,25 MHz 1,2288MHz 2,4 Mpbs 621 kbps
cdma2000 3XMC 3,75 MHz 3,6864 Mhz 4 Mpbs 1117 kbps
W-CDMA (UMTS) 5 MHz 4,096 MHz 4 Mbps 1126 kbps
Fonte: Dornan (2001).
Um padrão então surgiu contrariando a tendência apontada pelo ITU em sistemas de 3G
somente baseados em CDMA: o EDGE (Enhanced Data Rates for GSM Evolution). Este
padrão só foi aceito como IMT-2000 no ano de 2000, apesar da intenção de criar o EDGE não
ser de colocar uma tecnologia baseada em TDMA para concorrer com as demais que são
oriundas do CDMA e sim para aproveitar a banda disponível, enquanto uma operadora migra
para a W-CDMA, para ampliar a capacidade de dados das redes que possuíam HSCSD e
GRPS (DORNA,2001).
O EDGE é uma tecnologia que utiliza a modulação 8-PSK substituindo o GMSK utilizado na
GSM. Com esta modulação, a taxa de transferência sobe para 64,2 kbps contra os originais
21,2 kbps do GSM. O EDGE, ao ser implantando em uma rede, conseqüentemente teria
disponível o GPRS e , em alguns casos, o HSCSD. Assim, caso um telefone celular esteja
conectado a rede que disponibiliza EDGE mas este possui somente suporte a GPRS, ele
poderia fazer uso do GPRS puro sem nenhum problema. Por este motivo, esta tecnologia
também é conhecida como EGPRS (Enhanced GPRS) ou EHSCSD (Enhanced HSCSD).
Um dos problemas da tecnologia é o fato de utilizar o 8-PSK para aumentar a velocidade,
pois, esta técnica de modulação é mais sujeita a erros que a GMSK. Para tal, de acordo com a
qualidade da conexão, o EDGE especifica nove MCVs (Modulation and Configuration
Schemes), conforme tabela abaixo:
41
Tabela 5: Modulações e esquemas de codificação EDGE.
MCS Capacidade do slot Modulação Capacidade do canal
MCS-1 8,8 kbps GMSK 70,4 kbps
MCS-2 11,2 kbps GMSK 89,6 kbps
MCS-3 14,8 kbps GMSK 118,4 kbps
MCS-4 17,6 kbps GMSK 140,8 kbps
MCS-5 22,4 kbps 8PSK 179,2 kbps
MCS-6 29,6 kbps 8PSK 236,8 kbps
MCS-7 44,8 kbps 8PSK 358,4 kbps
MCS-8 54,4 kbps 8PSK 435,2 kbps
MCS-9 59,2 kbps 8PSK 473,6 kbps
Fonte: Dornan (2001).
Estas são as tecnologias que são reconhecidas pelo ITU como as que atendem as
especificações do IMT-2000. Como toda tecnologia, as evoluções não param por ai. Novos
padrões estão sendo concebidos, a fim de disponibilizar para o mercado de telefonia celular a
quarta geração.
2.2.6 Quarta Geração (4G)
A 4G ainda está praticamente em fase de especificação e desenvolvimento. Ela promete
fornecer ao mercado de telefonia celular taxas de transmissão da ordem dos 100Mbps
(DORNAN,2001).
No entanto, em uma conferência chamada Conferência Internacional Para Além da Terceira
Geração (ICB3G-2004) a operadora NTT DoCoMo do Japão, para surpresa de muitos,
apresentou os resultados dos testes realizados em uma cidade do Japão. Nos testes, a
operadora chegou a uma taxa de transferência máxima de 300 Mbps e de 135 Mbps para um
móvel de deslocando a uma velocidade de 30 Km/h. Nos planos a operadora está a utilização
da tecnologia MIMO (Multiple Input & Multiple Output), que permite chegar a taxas de até
1Gbps em movimento (JB ONLINE, 2004).
Após esta apresentação geral das tecnologias que possibilitam disponibilizar os serviços de
voz e dados aos usuários da telefonia celular e suas respectivas gerações, ficam claro o poder
42
que estas redes tem e terão em médio prazo para a comunicação de dados. Este fator é uns dos
maiores atraentes para os desenvolvedores de soluções para a comunicação móvel. Para tal,
será abordado algumas das plataformas de desenvolvimento de software, em especial a
plataforma BREW da Qualcomm.
2.3 TECNOLOGIAS PARA DESENVOLVIMENTO DE SOFTWARE
2.3.1 Superwaba
Esta plataforma de desenvolvimento de software, criada em 2000, é uma evolução do projeto
de software livre Waba, da empresa Waba Software, voltada ao desenvolvimento de software
para PDA (Digital Personal Assistent). Baseada em um SuperWaba SDK que define uma
linguagem, uma máquina virtual, um conjunto de classes padrões e um padrão de
armazenagem de classes, os desenvolvedores podem fazer uso das mesmas ferramentas
disponíveis para Java, mesmo o SuperWaba não tendo nenhuma relação com o Java em
termos de especificação (SUPERWABA, 2005a).
Dentre suas características, destaca-se o suporte a criação de bibliotecas nativas em C/C++,
tokenizador de XML, máquina virtual com suporte a diversas plataformas, leitura de
arquivos PalmDoc, algoritmos de criptografia Blowfish, MD5, SHA1 e TEA, suporte a
TCP/IP, USB, serial, Bluetooth e infra-vermelho.
Além destas características técnicas, o Superwaba está disponível em duas formas de licença
que são a GPL (GNU General Public License) e a LGPL (GNU Lesser General Public
License). A GPL é aberta e livre para qualquer pessoa que queira desenvolver um software
baseado nesta tecnologia, desde que seu software também seja livre, ou seja, herda a licença
GPU. Já a LGPL necessita que seja realizada uma subscrição anual que, mesmo o Superwaba
continuar sendo um software livre, permite criar aplicações proprietárias.
Esta tecnologia foi utilizada na COPEL, Companhia Paranaense de Energia, para
disponibilizar às suas equipes de campo uma extensão da rede através do uso de handheld
conectado à rede via celular, dando agilidade à execução de atividades, aumentando em 20%
a produtividade (SUPERWABA, 2005b).
43
2.3.2 J2ME
A Java 2 Micro Edition é uma edição do Java criada para atender dispositivos com pouca
capacidade de processamento e armazenamento, como os celulares e PDA (Personal Digital
Assistant). Como estes dispositivos não tem capacidade para implementar todas as
funcionalidades disponíveis na J2SE (Java 2 Standard Edition), fez se necessário a
especificação de uma versão mais leve que é o caso da J2ME (MUCHOW, 2002).
Ela foi concebida e baseada em dois novos conceitos: configurações e perfis. Chama-se de
configurações a parte que contemplas a JVM (Java Virtual Machine) e as APIs que podem ser
utilizadas. Existem várias configurações disponíveis, mas as mais comuns são as CDC
(Conected Device Configuration), que utiliza uma JVM, e a CLDC (Conected Limited Device
Configuration) que é baseada em uma máquina virtual reduzida chamada de KVM.
(ALMEIDA, 2004).
As características básicas de cada uma delas, segundo Almeida (2004) são:
CDC
o Com no mínimo 512 KB de memória para execução da JVM.
o Com no mínimo 256 KB para alocação de memória em tempo de execução.
o Conectividade de rede, largura de banda alta e acesso permanente.
CLDC
o Com 128 KB para executar a KVM.
o 32 KB para alocação de memória em tempo de execução.
o Interface restrita com o usuário.
o Baixo consumo, normalmente alimentado por bateria.
o Conectividade de rede, normalmente dispositivos sem fio com largura de banda baixa
e acesso intermitente.
Já os perfis são recursos adicionais para determinadas linhas de dispositivos móveis, como
interfaces com usuários e modelos de persistências de dados. Segundo Muchow (2002, p.5),
podem ser vistos como uma extensão de uma configuração fornecendo ao desenvolvedor
bibliotecas para escrever aplicativos para um tipo particular de dispositivo.
44
Alguns perfis disponíveis pela Sun Microsystems (2001) são:
MIDP (Mobile Information Device Profile): utilizado em celulares;
Foundation Profile: para dispositivos sem interface gráfica;
Personal Basis e Personal Profile: para dispositivos que tem capacidade de
processamento suficiente para rodar uma JVM (CDC).
Pelo fato do J2ME estar se popularizando por meio dos celulares, a MIDP é o perfil mais
difundido no mercado. Para que se possa utilizar este o dispositivo tem que ter recursos
mínimos como 128Kb de memória não volátil para o perfil propriamente dito, 32Kb para a
heap (volátil) e 8Kb para persistência (não volátil). Para aplicações gráficas ele exige um
mínimo de resuloção (96 x 54 pixels). Além disso, possibilita interface com dispositivos para
entrada de dados como o teclado e conexão de rede.
Em nível de segurança, este perfil utiliza a mesma técnica aplicada nas java applets: uma
aplicação não pode acessar nenhum servidor externo ao seu domínio. Na versão mais atual
(MIDP 2.0), já disponibiliza os mesmos recursos de segurança que a J2SE.
Com esta tecnologia, a mesma portabilidade que a Sun ofereceu ao mercado de computadores
está oferecendo aos dispositivos móveis, facilitando o desenvolvimento de software e a
abrangência destes em nível de compatibilidade de dispositivos.
2.3.3 Visual Studio .NET
Criada pela Microsoft ela possibilita, entre outras aplicações práticas de desenvolvimento,
criar aplicativos para dispositivos móveis. Haddad (2004a) afirma que com o Visual Studio
.NET é possível criar uma aplicação para executar em telefones celulares ou diretamente em
um navegador .
Para desenvolver um aplicativo para dispositivos móveis no Visual Studio .NET, além desta
ferramenta é necessário ter instalado um SDK chamado Mobile Internet Toolkit 1.0 da
Microsoft, além de um simulador para testes como o Microsoft Mobile Emulator 3.0, porém,
existem outros simuladores disponíveis no mercado, inclusive de fabricantes de dispositivos
celulares como a Nokia e a Ericsson.
45
Com esse conjunto de ferramentas o Visual Studio .NET se transforma em uma framework
completo para desenvolvimento de aplicativos para celulares. Para facilitar a identificação e
utilização dos recursos suportados por este tipo de dispositivos, ao instalar o SDK é
disponibilizado uma caixa de ferramentas com todos os componentes disponíveis para o
desenvolvimento. A linguagem de programação utilizada para desenvolvimento poderá ser
Visual Basic .NET, Visual C# ou ASP .NET (HADDAD, 2004b).
Com esta facilidade, desenvolvedores de soluções em Visual Studio .NET têm um grande
potencial para atuar também nas áreas de telefonia celular. Para este trabalho, será adotado o
Visual Studio .NET com o SDK 3.0 e Simulador da BREW, desenvolvendo assim o protótipo
que foi proposto.
Estas são apenas algumas das tecnologias disponíveis no mercado. Será dedicado o capitulo
seguinte ao estudo da plataforma que será utilizada para este trabalho: a Plataforma BREW da
Qualcomm.
46
3 BREW
3.1 VISÃO GERAL
A Plataforma BREW2 é uma proposta da fabricante Qualcomm que visa realizar a integração
total da cadeia de soluções para aplicações móveis no que se diz respeito a dispositivos
compatíveis, desenvolvimento de aplicativos, distribuição e faturamento de aplicativos, com a
segurança necessária para todos os envolvidos. Considerando que esta proposta garanta
também a satisfação dos usuários de serviço móvel, a solução da Qualcomm busca também
aumento da receita média por usuário das operadoras, chamada de ARPU (Average Revenue
Per User). A Qualcomm (2002) afirma que
a plataforma BREW (Binary Runtime Environment for Wireless), ambiente binário
de tempo de execução para aplicativos sem fio) da QUALCOMM e o BREW
Distribution System (BDS, sistema de distribuição do BREW) fornecem a única
tecnologia comercial e sistema de negócios que pode atender a esses requisitos.
Estas características fizeram com que 45 operadoras em 25 países adotassem a BREW como
solução para fornecer aplicativos aos usuários (QUALCOMM,2005). Entre elas está a VIVO,
operadora de telefonia celular que atua no Brasil e possui mais de 38% do mercado nacional
(ANATEL, 2005b). No caso específico da VIVO, ela disponibiliza o Vivo Downloads , um
site na Internet (http://www.vivo.com.br/downloads/) que permite aos seus clientes visualizar
os aplicativos disponíveis, que também pode ser feito diretamente pelo celular, fornecendo
informações como preço e disponibilidade, além de orientações de como adquirir os
aplicativos via celular.
2 Plataforma BREW (Bynary RunimeEnvironment for Wireless) disponível em http://brew.qualcomm.com.
47
No entanto, para que um dispositivo móvel tenha suporte a BREW ele necessita ter um
chipset compatível com a plataforma. A fabricante Qualcomm disponibiliza os chipsets da
série MSMTM (Mobile Station Modem) compatível com BREW. Outros fabricantes já
caminham para compatibilizar seus chipsets com a plataforma BREW. (QUALCOMM,[2002-
2005]). Mesmo com essa restrição é verificado nos sites das operadoras de celular que
utilizam BREW a grande variedade de aparelhos e fabricantes que fazem uso de chipsets
compatíveis.
Para entender melhor como se dá esta integração de ponta a ponta, serão apresentados os
componentes da plataforma BREW.
3.2 BREW DISTIBUTION SYSTEM
Como visto no capítulo anterior, existe no mercado algumas tecnologias voltadas para
desenvolvimento de aplicações para dispositivos móveis, entre elas a BREW. No entanto, a
Qualcomm foi ainda mais longe: definiu e implementou uma forma de distribuição chamada
de BDS (BREW Distribution System). O BDS é responsável pelo comércio eletrônico entre
desenvolvedores e operadoras, pela distribuição do software, por garantir a instalação deste
software no celular do usuário, além da arrecadação e distribuição dos valores entre as partes
envolvidas: Qualcomm, desenvolvedor e operadoras de celular.
Antes de mostrar as características básicas do BDS, é importante entender como um aplicativo
desenvolvido pode ser incluído no mercado. Para isso, uma das características desta
plataforma é que para se tornar um desenvolvedor e fornecedor de soluções para BREW, não
basta saber projetar e implementar, é preciso ser certificado. Para isso, é necessário que o
fornecedor de soluções possua uma certificação digital classe III fornecida pela entidade
certificadora VeriSign3. A partir da certificação ele deverá se registrar na Qualcomm como
desenvolvedor certificado para poder usufruir das ferramentas e documentações
disponibilizadas pela empresa e no NSLT (National Software Testing Laboratory), instituição
que realiza exaustivos testes nos aplicativos a pedido das operadoras (QUALCOMM, 2002).
Com a garantia de que o aplicativo a ser oferecido está de acordo com as premissas básicas,
estes são incluídos no BDS. Nele um mercado virtual é disponibilizado para operadoras e
3 Entidade certificadora VeriSign disponível em http://www.verisign.com/index.html.
48
desenvolvedores realizarem a compra e venda de aplicativos certificados, criando um
relacionamento direto entre operadoras e desenvolvedores, onde estes definem um valor para
os aplicativos. Após a compra pela operadora, ela disponibiliza os aplicativos para seus
clientes, através de um servidor de downloads da plataforma (QUALCOMM,2002).
O BDS possibilita a integração com o sistema de faturamento da operadora, facilitando o
processo de cobrança por parte dela, já que esta plataforma faz também o controle para
garantir que um software vendido foi efetivamente entregue e instalado com sucesso no
dispositivo móvel do usuário final. A cada venda efetuada, a receita é dividida entre a
operadora, o desenvolvedor e a Qualcomm, ou seja, o aplicativo é pago somente após a
devida venda para o usuário final. Este repasse aos desenvolvedores é realizado
trimestralmente.
Na figura 9 é apresentado de forma sucinta como é o modelo de negócios promovido pelo
BDS. É possível verificar que, por se tratar de um mercado virtual para todas as operadoras
que fazem uso da plataforma atualmente, os desenvolvedores acabam disponibilizando seus
aplicativos para um mercado mundial, facilitando a abertura de mercado para novos
desenvolvedores.
Figura 9: Modelo de negócio integrado do BDS. Fonte: QUALCOMM (2003a).
49
No caso de existir a necessidade de atualização de software do dispositivo móvel, a
plataforma gerencia também esta ação, permitindo que a operadora e fabricantes de telefones
celulares o façam através da interface aérea, sem a necessidade de realizar esta atualização em
pontos autorizados, dando mais comodidade aos seus clientes, reduzindo custos.
A plataforma BREW está posicionada de forma incomparável a capacitar os aplicativos
móveis do futuro, ao mesmo tempo em que suporta as tecnologias e os requisitos de negócio
da indústria da telefonia móvel. (QUALCOMM, 2002, p.25). Como o foco deste trabalho é
analisar com mais detalhes a parte de desenvolvimento de aplicativos para a plataforma
BREW, será apresentada então as partes que compõe o BREW SDK (Software Development
Kit).
3.3 BREW SDK (SOFTWARE DEVELOPMENT KIT)
O ponto importante para uma solução integrada e padronizada é a compatibilidade dos
dispositivos móveis. Inicialmente, o caminho encontrado pelos fabricantes de hardware foi a
possibilidade de ter um sistema operacional dentro de um dispositivo móvel. Algumas
experiências foram efetuadas, porém, os custos dos aparelhos se tornaram uma barreira para o
sucesso desta estratégia (QUALCOMM, 2002).
Nesta área a BREW atua como uma camada de abstração, integrada diretamente a unidade de
processamento do dispositivo, em memória RAM e flash, fornecendo uma conexão de
software entre as funções de baixo nível do processador e os aplicativos desenvolvidos.
Necessitando de apenas 150 KB para ser funcional, esta abstração elimina a necessidade dos
desenvolvedores se preocuparem com o dispositivo para qual estão implementando a solução
e sim no projeto e desenvolvimento da mesma, além de promover uma alta portabilidade e
compatibilidade entre dispositivos móveis.
O desenvolvimento de aplicativos para estes dispositivos é baseado na linguagem de
programação C/C++. Segundo a Qualcomm (2002), existe no mundo cerca de 7 milhões de
desenvolvedores em C/C++ que, tendo um conhecimento mínimo telefonia celular, podem
atuar nesta área. Um outro ponto que merece destaque é o fato desta plataforma possuir
suporte a J2ME, o que amplia mais ainda número de potenciais desenvolvedores. Isto é
possível graças ao desenvolvimento de uma máquina virtual Java (JVM
Java Virtual
Machine), conhecidas também como VM (Virtual Machine) que roda sobre o BREW,
50
possibilitando todas as vantagens de integração também para aplicativos J2ME. A Qualcomm
(2003b) ainda afirma que
essas MVs podem ser transferidas pelo ar e provisionadas automaticamente em um
aparelho telefônico com o cliente BREW 2.0 (presumindo-se que o dispositivo de
destino tenha memória suficiente), o que significa esforço e custo zero para o
fabricante de aparelhos, que pode ter aparelhos telefônicos Java no mercado
simplesmente comercializando telefones baseados no BREW 2.0.
Para realizar o desenvolvimento de aplicações para a plataforma BREW se faz necessário
conhecer alguns conceitos básicos.
3.3.1 Relação entre classes, módulos e aplicação
Todas as funcionalidades disponíveis na SDK e as que você cria estão disponíveis dentro de
classes. Neste contexto, existem classes que são disponibilizadas pela versão da SDK
normalmente da memória ROM do dispositivo - e as que você cria para desenvolver a
aplicação. A aplicação necessariamente deve possuir uma classe que será implementada a
partir da interface definida pela classe IApplet, que possibilitará iniciar a aplicação e
processar os eventos do sistema e solicitações do usuário, já que a programação utiliza
orientação a eventos (RISCHPATER, 2003).
Um módulo possui a definição das classes e a implementação das interfaces utilizadas para a
criação da aplicação.
Toda aplicação recebe uma identificação única, chamada de ID, que é um inteiro de 32 bit.
Para fins de comercialização, você tem que ser um desenvolvedor certificado pela Qualcomm,
que fornecerá o ID para sua aplicação que será única dentre todas as aplicações registradas e
comercializadas. É possível, porém, para desenvolver uma aplicação como teste você mesmo
informar um ID para sua aplicação. Com base no ID, é criado um arquivo de definição em
linguagem C que deve ser salvo no arquivo da aplicação com a extensão .BID (BREW ID).
Após os passos de criação do código fonte da aplicação, deve-se então compilar para que seja
executada no dispositivo móvel. Existe, basicamente, duas formas: gerando um arquivo DLL
através do Visual Studio .NET ou utilizando o compilador ARM da Qualcomm e gerando
arquivos de módulos com extensão .MOD.
51
3.3.2 MIF(Module Information File) e o BAR(BREW Applet Resourse)
O MIF é um arquivo de definições que informa ao BREW dados como ID da aplicação, ícone,
nome da aplicação, além de outras informações como o autor do aplicativo. Para criar um
arquivo de definição MIF, é utilizado o BREW MIF Editor disponível com o SDK.
Existe também o BAR que é utilizado para informar alguns recursos que a aplicação utilizará
como caixas de diálogo, ícones e strings específicas da aplicação, além de dados referente a
portabilidade entre dispositivos. A criação deste arquivo é feita a través da ferramenta BREW
Resourse Editor.(RISCHPATER, 2003)
3.3.3 SDK disponíveis
Ao se pensar em desenvolver um aplicativo para um dispositivo que suporte BREW, deve-se
escolher qual SDK é mais adequado às necessidades. A BREW possui atualmente cinco
especificações de SDK: 1.0, 1.1, 2.0, 2.1, 3.0 e 3.1. Cada uma das SDKs disponibilizam uma
série de recursos que atende determinados dispositivos móveis, conforme uma Data Sheet de
dispositivos disponíveis. É importante ressaltar que uma SDK com mais recursos sempre trará
consigo os recursos de todas as outras anteriores. Exemplificando, se o desenvolvedor adotar
a SDK 2.0, subentende-se que esta já possui seus recursos particulares além dos disponíveis
para a SDK 1.0 e 1.1. (QUALCOMM, 2004). Junto com o SDK, são disponibilizadas algumas
ferramenta:
SDK Device Configuration: Permite configurar o Simulador para se comportar de acordo
com os recursos e funcionalidades de uma determinada versão de SDK a qual se deseja
projetar e implementar uma aplicação.
SDK BREW Emulator: Também conhecido como Simulador, emula o dispositivo móvel em
um PC para facilitar os testes das aplicações.
BREW MIF Editor: Utilizado par criar e editar os arquivos MIF (Module Informatino File)
que contém informações sobre as classes e módulos que devem ser suportados pela aplicação,
além do identificador único da classe chamado de BID (Brew IDentfication).
52
BREW Resource Editor: Utilizado par criar e editar os arquivos BAR (BREW Application
Resource) que contém informações sobre recursos adicionais da aplicação como ícones,
algumas strings próprias para a solução e caixas de diálogos.
BREW Simulator: Veio para substituir o BREW Emulator incorporando também o SDK
Device Configuration . Este recurso está disponível somente na versão SDK 3.0.
É possível em um mesmo ambiente de desenvolvimento ter varias versões de SDK instaladas.
O que o sistema faz é instalar cada uma em um diretório e na hora que for iniciar o
desenvolvimento, deverá ser especificado em qual versão deseja desenvolver. No próximo
item será explanado os passos básicos para o desenvolvimento de um aplicativo simples.
Agora será apresentado como prepara um ambiente para o desenvolvimento de aplicativos
para a plataforma BREW.
3.4 PREPARANDO O AMBIENTE PARA DESENVOLVIMENTO
Um ambiente de desenvolvimento para a plataforma BREW necessita basicamente de um
SDK e um ambiente de desenvolvimento em C/C++.
3.4.1 Requisitos mínimos
Para que se possa ter um SDK disponível em um PC para o desenvolvimento de aplicações, é
necessário que o microcomputador possua as características mínimas de software
(QUALCOMM, 2004):
Internet Explorer 5.5 SP2 ou superior com suporte a criptografia de 128 bits
Sistema operacional Windows NT 4.0, Windows 2000 ou Windows XP
Possuir privilégio de administrador do ambiente.
3.4.2 Instalando o SDK
O primeiro passo é a instalação do BREW SDK que está disponível gratuitamente no site da
BREW em https://brewx.qualcomm.com/brew/sdk/download.jsp, onde encontra-se todas as
versões de SDK disponíveis. Para instalar, basta escolher a versão desejada de acordo com os
recursos que serão utilizados no desenvolvimento e seguir os passos conforme descrito no
53
site. É importante observar que o BREW SDK é instalado de forma on-line, sendo premissa
para tal estar conectado a internet no momento da instalação, pois, o sistema é transferido por
meio da internet para a máquina local e instalado, não disponibilizando em nenhum momento
uma opção para download4 do arquivo e posterior instalação do SDK.
Para o protótipo implementado, que será apresentado no decorrer deste trabalho, foi instalado
o BREW SDK 3.1.3 que compreende as bibliotecas necessárias, o Simulador para testar as
aplicações e o BREW MIF Editor e BREW Resource Editor que possibilita configurar as
características básicas da aplicação e recursos respectivamente.
Nesta versão, todos os recursos da plataforma estão disponíveis. Para utilizar o ambiente de
desenvolvimento, deverá ser especificada uma variável de ambiente chamada BREWDIR que
contém o caminho onde está instalado o SDK. Normalmente no momento da instalação esta
configuração é feita automaticamente, mas, nos casos onde possui mais de um SDK instalado,
pode ser necessária alguma alteração.
Exemplificando, se for desenvolver para um SDK 3.1, deverá ir até o Painel de Controle do
Windows e acessar o ícone Sistema (no caso do Windows XP) na aba Avançado
e clicar no
botão Variáveis de ambiente (figura 10).
4 Transferência de arquivos da internet para o microcomputador local.
54
Figura 10: Tela de configuração do sistema.
Na tela de configuração de variáveis, basta editar o caminho que está definido na variável
BREWDIR para o que se deseja, conforme figura 11.
55
Figura 11: Tela de configuração de variáveis de ambiente.
Após estes passos o ambiente já possui o suporte BREW necessário para o desenvolvimento,
bastando instalar uma ferramenta de desenvolvimento C/C++.
3.4.3 Preparando o Visual Studio .NET
O próximo passo é instalar o ambiente de desenvolvimento propriamente dito. Para o este
trabalho, será utilizado o Visual Stúdio .NET 2003. Se ainda não estiver instalado no
microcomputador, deve-se primeiro realizar tal instalação. O Visual Studio não possui suporte
nativo a projetos para aplicações BREW, no caso o BREW Application Wizard que facilita o
processo de desenvolvimento para a plataforma. Para instalar este recurso deverá ser instalado
o BREW Add-Ins 3.0 for Visual Studio que está disponível em
https://brewx.qualcomm.com/brew/sdk/download.jsp?page=dx/devmisc. A instalação é
similar ao BREW SDK e todas as considerações feitas para a instalação do SDK são válidas
para este, exceto na necessidade de configuração do BREWDIR.
56
A partir deste momento, ao iniciar um novo projeto no Visual Stúdio por meio do menu File -
> New. -> Project, estará disponível a opção BREWAppWizard, como mostra a figura 12..
Figura 12 : Ambiente configurado e com o BREWAppWizard disponível
Está finalizada a configuração do ambiente integrado de desenvolvimento de aplicativos para
a plataforma BREW baseado no Visual Studio .NET 2003 e BREW SDK 3 (3.1.3). É possível
a utilização de outras ferramentas de desenvolvimento em C/C++ e fazer uso do BREW SDK,
desde que esta ferramenta seja capaz de compilar e gerar uma DLL Windows (QUALCOMM,
[2002-2005b]). No entanto o conjunto escolhido é prático e de fácil execução. A mesma
configuração foi efetuada com o Visual C++ 6.0 da Microsoft e os resultados foram os
57
mesmos, havendo apenas algumas alterações de telas. Com o ambiente configurado, será
apresentada a criação de um novo projeto.
3.5 CRIANDO UMA APLICAÇÃO BREW
Como foi apresentada no item anterior, a figura 12 mostra a tela para iniciar o
desenvolvimento de uma nova aplicação BREW. Nesta deverá ser informado o nome para a
nova aplicação na caixa de texto Name e em Location o diretório base onde será salvo todos
os arquivos do novo projeto. Para este exemplo será utilizado univali
para o Name e
C:\projetos para Location, que ao final do processo será criada a estrutura de diretórios
C:\projetos\univali
Após informar o nome da aplicação e diretório base do projeto, será apresentada a tela a
seguir para a definição dos recursos que serão suportados pela aplicação:
Figura 13: Recursos que a aplicação fará uso.
Definidos os recursos em General Settings, na opção Options (figura 14) possibilita iniciar o
BREW MIF Editor e selecionar se deseja ou não que o wizard gere o arquivo inicial do projeto
com comentários padrão que auxiliam no início do desenvolvimento.
58
Figura 14: Tela Options
O BREW MIF Editor obrigatoriamente deverá ser executado para realizar a configuração
básica da aplicação. Caso ele não seja iniciado automaticamente quando o botão MIF Editor
for pressionado, poderá ser iniciado por meio do menu Iniciar
do Windows em
Programas , BREW SDK Tools 1.0.0 .
3.5.1 MIF Editor Configurando a aplicação
É por meio do MIF Edito que a aplicação será configurada, definindo os privilégios
necessários para acessar os recursos, o BID que é o identificador da aplicação, o nome da
aplicação, a categoria a qual ela pertencerá e o ícone que será apresentado para o usuário no
menu de aplicativos do celular, no nosso caso, do simulador. A tela principal do BREW MIF
Editor é apresentada na figura a seguir.
59
Figura 15: BREW MIF Editor
O primeiro passo para configurar a aplicação é a definição da applet que pode ser feita
clicando no New Applet em List of Applets defined in this Module. Pressionando este botão
será apresentado a tela de configuração do BID. Como explanado no neste capítulo, o BID é o
BREW Identified que identifica uma aplicação. Para a aplicação ser comercializada é
necessário ser desenvolvedor autorizado BREW e esta identificação é fornecida pela
Qualcomm. No entanto, é possível informar um BID local para o desenvolvimento e teste da
aplicação no Simulador. É importante ressaltar que em não será possível instalar esta
aplicação em um dispositivo móvel devido ao BID não ser oficial. Para se definir um BID
local, basta selecionar a opção Locally e informar um Class ID e um Class Name. Na figura
abaixo foi informado o Class ID 0xABCDE123 e o Class Name univali.
60
Figura 16: Informando um Class ID local
Definido o Class ID será solicitado o diretório onde será salvo o BID (arquivo.bid). Salve-o
no mesmo diretório da aplicação que será desenvolvida, neste exemplo será no diretório
C:\projetos\univali. Caso esta estrutura não exista, crie.
Concluindo este passo, será informado o nome da aplicação e o ícone que será associado à
aplicação conforme figura abaixo.
61
Figura 17: MIF Editor - Configuração da aplicação
Além destas configurações, deverá ser definida no MIF Editor na aba Privileges quais
recursos a aplicação deverá ter acesso. Estes privilégios devem estar de acordo com o que foi
informado na tela apresentada na figura 12 onde foram selecionados os recursos que deverão
estar disponíveis no ambiente de desenvolvimento, ou seja, informamos o que será utilizado
no desenvolvimento e depois damos privilégio para a aplicação utilizar os recursos na
execução.
A configuração está finalizada. Para salvar o arquivo com as definições da aplicação deverá
ser selecionada a opção Save no menu File do MIF Editor e salvar um arquivo com extensão
mfx (Module Information Resource) no mesmo diretório dos projetos, neste caso no
C:\projetos será salvo o arquivo univali.mfx, que é um arquivo XML. Depois de salvo é
necessário compilar o arquivo com as definições que será feito pelo menu Build e Compile
MIF Script que gerará um arquivo com o mesmo prefixo do arquivo mfx, mas com a extensão
mif que é um arquivo binário das configurações. Fechar o MIF Editor e clicar em Finish do
wizard.
62
A partir deste ponto o ambiente de desenvolvimento estará com a estrutura básica de nossa
aplicação, disponibilizando 3 arquivos criados automaticamente pelo wizard: univali.c,
AEEAppGen.c e o AEEAppMod.c. Os dois últimos possuem ainda seus arquivos de recursos,
ou header como são conhecidos na linguagem C/C++, que são incluídos ao projeto por meio
da diretiva #include no conteúdo do arquivo univali.c.
3.5.2 Univali.c comentado
A seguir será apresentado o código fonte do arquivo univali.c visando detalhar um pouco mais
o desenvolvimento através de comentários deste código. É necessário ter uma base de
programação na linguagem C.
/*======================================================================= FILE: univali.c =======================================================================*/ /*======================================================================= INCLUDES AND VARIABLE DEFINITIONS ====================================================================== */ #include "AEEModGen.h" // Definições da interface do módulo #include "AEEAppGen.h" // Definições da interface Applet #include "AEEShell.h" // Definições da interface Shell #include "univali.bid" // Arquivo com o ClassID
/*------------------------------------------------------------------ Estrutura da Applet. Todas as variáveis dentro da estrutura são referenciadas por "pEstrutura->variável" -------------------------------------------------------------------*/
typedef struct _univali { AEEApplet a ; // Primeiro elemento da estrutura deve ser AEEApplet AEEDeviceInfo DeviceInfo; // permitir acesso às informações dos dispositivos (hardware) IDisplay *pIDisplay; // permite acesso à interface Display de uma forma padrão IShell *pIShell; // permite acesso à interface Shell de uma forma padrão // Aqui você pode adicionar suas variáveis! } univali;
/*------------------------------------------------------------------- Function Prototypes -------------------------------------------------------------------*/ static boolean univali_HandleEvent(univali* pMe, AEEEvent eCode, uint16 wParam, uint32 dwParam); boolean univali_InitAppData(univali* pMe); void univali_FreeAppData(univali* pMe);
/*======================================================================= FUNCTION DEFINITIONS ====================================================================== */
/*======================================================================= FUNCTION: AEEClsCreateInstance. Método necessário para todas as aplicações. Instancia a aplicação em memória e gera o evento ETV_APP_START =======================================================================*/
63
int AEEClsCreateInstance(AEECLSID ClsId, IShell *pIShell, IModule *po, void **ppObj) {
*ppObj = NULL; if( ClsId == AEECLSID_UNIVALI ) {
// Cria a Applet e prepara a estrutura desta. if( AEEApplet_New(sizeof(univali), ClsId,pIShell,po,(IApplet**)ppObj, (AEEHANDLER)univali_HandleEvent, (PFNFREEAPPDATA)univali_FreeAppData) ) // a função FreeAppData é chamada depois de enviar o evento // ETV_APP_STOP para o HandleEventfunction {
//Inicializa os dados da Applet antes de // enviar o e EVT_APP_START para o HandleEvent if(univali_InitAppData((univali*)*ppObj)) {
//Dados inicializados com sucesso return(AEE_SUCCESS);
} else {
// Libera a Applet, liberando a memória alocada // quando o método AEEApplet_New for requisitado. IAPPLET_Release((IApplet*)*ppObj); return EFAILED;
} } // Fim da AEEApplet_New return(EFAILED);
} }
/*========================================================================= FUNCTION univali_HandleEvent. Esta função tem a finalidade de tratar os eventos que ocorrem durante a execução da aplicação. Ele é criado automaticamente pelo Wizard. Abaixo segue um exemplo. =========================================================================*/ static boolean univali_HandleEvent(univali* pMe, AEEEvent eCode, uint16 wParam, uint32 dwParam) {
switch (eCode) {
// Aplicação iniciando case EVT_APP_START: // Aqui você coloca o código referente à ação! return(TRUE); // Aplicação está sendo finalizada case EVT_APP_STOP: // Aqui você coloca o código referente à ação! return(TRUE); // Aplicação foi colocada em modo suspenso case EVT_APP_SUSPEND: // Aqui você coloca o código referente à ação! return(TRUE); // Aplicação está retornando do modo suspenso case EVT_APP_RESUME: // Aqui você coloca o código referente à ação! return(TRUE); // Um SMS foi entregue para a aplicação.
64
// A Mensagem é passada através do parâmetro dwParam como um //(char *) case EVT_APP_MESSAGE: // Aqui você coloca o código referente à ação! return(TRUE); // Uma tecla foi pressionada. O parâmetro wParam traz a // informação da tecla que gerou o evento. // Os códigos das teclas estão em AEEVCodes.h. // Um exemplo: código "AVK_1" refere-se a tecla "1" precionada case EVT_KEY: // Aqui você coloca o código referente à ação! return(TRUE); // Se nenhuma das condições forem satisfeitas, encerra o // processamento desta função. break;
} return FALSE; }
// Esta função é chamada quando a aplicação é iniciada boolean univali_InitAppData(univali* pMe) {
// Coleta as informações referentes ao telefone. // Referencia todos os dados da estrutura da // seguinte forma: pMe->DeviceInfo // Verifica se o dispositivo é compatível com a API necessária. pMe->DeviceInfo.wStructSize = sizeof(pMe->DeviceInfo); ISHELL_GetDeviceInfo(pMe->a.m_pIShell,&pMe->DeviceInfo); // As interfaces referentes ao Shell e Display sempre são criados por // default, possibilitando acessá-las através do "pMe->" sem o "a." pMe->pIDisplay = pMe->a.m_pIDisplay; pMe->pIShell = pMe->a.m_pIShell; // Neste ponto você pode colocar seu código alocando os recursos // necessários // Não ocorrendo nenhuma falha, retornará sucesso na execução return TRUE;
}
// Esta função é chamada quando a aplicação está sendo finalizada void univali_FreeAppData(univali* pMe) {
// Insira seu código aqui para desalocar os recursos utilizados, // liberando-os da memória. // Exemplo para liberar cada interface //if ( pMe->pIMenuCtl != NULL ) // Verifica se não é nula //{
// Libera a interface //IMENUCTL_Release(pMe->pIMenuCtl) // Seta para NULL evitando problemas // caso haja a tentativa de liberar novamente //pMe->pIMenuCtl = NULL;
//} } /*====== Fim do código =====================================*/
Por se tratar de um código fonte em linguagem C, verifica-se que, com exceção da função
AEEClsCreateInstance, todas as funções possuem um parâmetro declarado como univali *
pMe que aponta para a estrutura da aplicação. Com isso, todo o acesso a recursos da aplicação
65
é efetuado através deste ponteiro. Logo, em todas as funções que serão criadas pelo
desenvolvedor necessitam deste ponteiro caso a função necessite interagir com alguma parte
da estrutura como alteração de tela, acesso a rede, informações sobre o dispositivo móvel etc.
Após o sistema ter sido compilado, será gerado um arquivo DLL no diretório definido para o
projeto, no nosso caso em C:\projetos\univali. Para garantir que o arquivo DLL será gerado no
diretório do projeto deverá ser verificada a configuração nas opções no menu Project e
selecionar Properties. Na janela que aparece deverá ir a Linker no item Debug e as caixas de
texto Generate Debug Info e Generate Program Database File deverão estar configuradas
como mostra a figura a seguir:
Figura 18: Configurando o modo Debug no Visual Studio
Sempre que um novo projeto é criado esta configuração deve ser feita se desejar utilizar os
recursos de depuração do Visual Studio.
Após esta configuração, para se realizar a depuração da aplicação ao selecionar a opção de
debug pela primeira vez o Visual Studio solicitará qual aplicativo será responsável por
executar tal DLL. Deverá ser selecionado o arquivo BREW_Simulador.exe que se encontra
66
no diretório bin onde foi instalado o SDK. Exemplificando, se o SDK utilizado for o 3.1.3, ele
provavelmente estará em C:\Arquivos de programas\BREW 3.1.3\bin\, considerando um
microcomputador com o sistema operacional Windows XP Professional no idioma português
(Brasil).
Além da definição de onde se encontra o BREW Simulator, no simulador deve-se informar o
diretório onde estão os arquivos mfx criados, neste caso no diretório de projetos C:\projetos.
Esta configuração é realizada por meio da opção Change Applet Dir.., informando diretório
do projeto conforme figura abaixo:
Figura 19: Configuração do simulador
É bom ressaltar também que, dependendo dos recursos que serão utilizados pela aplicação,
deverá ser habilitado no simulador para utilizá-los, como a conexão a transmissão de dados
para realizar uma conexa à Internet. Isso pode ser feito por meio do menu Tools do BREW
Simulator. Além dos privilégios, esta opção permite também simular a potência do sinal de
rede, carga de bateria, selecionar o tipo de rede que está sendo utilizada (GSM, CDMA,
UMTS), a taxa de transferência, entre outros.
3.6 PROTÓTIPO: CONTROLE REMOTO PARA RESIDÊNCIA
Muito se ouve falar nas casas do futuro. Uma das características destas casas é o controle total
através de controle remoto, dando mais comodidade aos moradores. Uma tendência mundial é
a conectividade à internet através das conexões chamadas de Banda Larga, onde se tem uma
conexão à Internet 24 horas, além da evolução tecnológica exposta no capítulo 2 que
apresentou os rumos da telefonia celular focando cada vez mais em comunicação de dados.
67
Serão exploradas estas tendências de mercado para aplicar em um protótipo alguns dos
recursos disponíveis na plataforma BREW: interface com usuários, conexão de dados por
meio do celular e manipulação de arquivos. Para isso será apresentado e desenvolvido um
protótipo para fazer do telefone celular um controle remoto para residências, onde será
utilizada a conectividade à internet via celular acessando um software que simulará um
servidor instalado em uma residência e conectado via banda larga a internet.
A figura a seguir ilustra a idéia do controle remoto:
Figura 20: Controle remoto via celular
Por meio de um software instalado em um celular, o proprietário de uma residência dotada de
conexão Banda Larga e um servidor com capacidade para ligar e desligar pontos de energia
poderá de qualquer lugar que possua o serviço móvel celular disponível, verificar o estado dos
pontos de controle e até mesmo alterar seus estados (ligar/desligar).
Imaginemos que o proprietário chegará mais tarde em casa e, por este motivo, ele poderá ligar
uma lâmpada externa ou interna para deixar o ambiente iluminado, ou até mesmo acionar o
ar-condicionado em um dia quente para que, ao chegar a casa, encontre o ambiente
climatizado e confortável. Na área de segurança, poderá verificar se não esqueceu o alarme
residencial desligado ao sair para uma viagem e ativá-lo caso tenha esquecido.
Para o protótipo proposto, o servidor será simulado através de um software, porém, para um
produto comercial deverá haver além de um software em um microcomputador uma interface
(hardware) que permita controlar os pontos desejados. A evolução para este modelo seria um
periférico com software embarcado que dispense a utilização de um microcomputador para
executa a função de servidor.
Internet
68
A seguir será apresentada a modelagem do sistema cliente que será utilizado no celular e que
é o foco dos estudos deste trabalho.
3.6.1 Modelagem do protótipo
Visando atuar no foco deste trabalho, será apresentada a modelagem do protótipo que será
executado no celular, no nosso caso no BREW Simulador.
Figura 21: Casos de uso
A seguir será visto o detalhamento de cada caso de uso acima indicado.
69
Tabela 6: Caso de uso: Configurar sistema
Nome do Caso de Uso Configurar sistema
Caso de uso geral (include) Nenhum
Ator principal Usuário
Ator secundário Servidor
Resumo Descreve os passos necessários para o usuário configurar a
conexão com o host Servidor.
Pré-condição Nenhuma
Pós-condição Configuração armazenada em arquivo
Fluxo base
Ações do Ator Ações do Sistema
1. Exibe configurações atuais
2. Informa endereço IP do servidor
3 . Informa a porta do Servidor
4. Confirma alterações
5. Sistema armazena as alterações em um
arquivo de configuração
Fluxo Alternativo
No passo 4 o usuário cancela a operação
Não executa o passo 5
70
Tabela 7: Caso de uso: Conectar no servidor
Nome do Caso de Uso Conectar no servidor
Caso de uso geral (include) Nenhum
Ator principal Usuário
Ator secundário Servidor
Resumo Realizar a conexão do software cliente (celular) com o
servidor via conexão Socket Stream.
Pré-condição Nenhuma
Pós-condição A conexão é estabelecida
Fluxo base
Ações do Ator Ações do Sistema
1. Verifica se a configuração foi efetuada
2 .Realiza a conexão com o servidor de acordo
com as configurações
3. Exibe menu principal e a mensagem
Conectado!
Fluxo Alternativo 1
No passo 1, caso a configuração não tenha sido
efetuada, informa a mensagem Configuração
inválida para o usuário.
Executa o passo 3
Fluxo Alternativo 2
No passo 2, caso a conexão não seja estabelecida
exibe a mensagem Falha na conexão .
Executa o passo 3
71
Tabela 8: Caso de uso: Verificar estados dos pontos de controle
Nome do caso de uso Verificar estados dos pontos de controle
Caso de uso geral (include) Nenhum
Ator principal Usuário
Ator secundário Servidor
Resumo Descreve como o sistema fará para solicitar ao servidor a lista
de pontos de controle e seu estado atual (ligado ou desligado)
Pré-condição O sistema Cliente deve estar conectado ao Servidor
Pós-condição A lista de pontos com seus estados deverão estar disponíveis
na tela do celular.
Fluxo base
Ações do Ator Ações do Sistema
1. Solicita ao Servidor a lista de pontos de
controle e seus estados
2. Sistema exibe na tela a lista de pontos e seus
estados
Fluxo alternativo
No passo 2 não há pontos configurados no
Servidor. Exibir a mensagem: Não há pontos
configurados no servidor .
72
Tabela 9: Caso de uso: Alterar estado de um ponto de controle
Nome do caso de uso Ligar / desligar pontos de controle
Caso de uso geral (include) Verificar estados dos pontos de controle
Ator principal Usuário
Ator secundário Servidor
Resumo Permite ao usuário ligar / desligar pontos controlados pelo
servidor
Pré-condição O sistema Cliente deve estar conectado ao Servidor
Pós-condição A lista de pontos com seus estados deverão estar disponíveis
na tela do celular com os estados atualizados.
Fluxo base
Ações do Ator Ações do Sistema
1. Solicita ao Servidor a lista de pontos de
controle e seus estados
2. Exibe na tela a lista de pontos e seus
estados
3. O usuário navega pelos pontos listados e
pressiona a tecla Select para alterar estado
do ponto
4. Solicita ao servidor a mudança do estado
do ponto selecionado
5. Atualiza o estado do ponto selecionado na
tela do celular
6. O usuário seleciona a opção Sair
Fluxo alternativo
No passo 6 o Usuário poderá voltar ao passo
3 caso deseje alterar o estado de outro ponto
de controle
Com base nos casos de uso identificados, será apresentado os diagramas de seqüência para
implementar os casos de uso acima apresentados.
73
3.6.2 Diagrama de classes de domínio
O diagrama abaixo apresenta as classes de domínio identificadas para a implementação do
protótipo.
cd Data ModelEA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
MenuControleRemoto
Conexao
Tela
Pontos
0..*
1
1
1
1111
Figura 22: Diagrama de classes de domínio
74
3.6.3 Diagramas de seqüência
Utilizando a mesma ordem dos casos de uso, segue os diagramas de seqüência para
implementar a aplicação cliente.
Figura 23: Diagrama de seqüência: Configurar Sistema
O diagrama acima mostra a seqüência necessária para realizar a conexão ao servidor
responsável pelo controle da residência.
75
Figura 24: Diagrama de seqüência: Conectar ao servidor
Neste diagrama é apresentada a seqüência que o sistema deverá realizar para se conectar ao
servidor remoto. Ao final será apresentada para o usuário uma tela do resultado da tentativa
de conexão.
76
Figura 25: Diagrama de seqüência: Ligar / desligar ponto de controle
Neste diagrama estão compreendidos os casos de uso Verificar estados dos pontos de
controle e Ligar / desligar pontos de controle.
3.6.4 Implementando o protótipo
Com base na especificação acima, será apresentado alguns pontos principais da
implementação. O código fonte completo da aplicação encontra-se no anexo 1.
Para adaptar o desenvolvimento estruturado às especificações realizadas em UML, as funções
que representam os métodos de uma determinada classe serão precedidos do nome da
classe . Exemplificando, as funções responsáveis pela conexão par conectar ao servidor será
77
conexao_Conectar(). Isto foi necessário devido a algumas restrições encontradas e detalhadas
no capítulo 4. Visualizando o código fonte no anexo 1 fica mais clara esta adaptação.
Todos os recursos do BREW SDK estão disponíveis em estruturas de dados, interfaces que
manipulam estas estruturas e tipos de dados específicos da plataforma. Exemplificando, para
manipular a tela do celular se utiliza a estrutura de dados do tipo IDisplay onde utilizamos o
método da interface IDISPLAY_DrawText() para escrever na tela um texto que deve ser do
tipo AECHAR exclusivo para a plataforma BREW.
Serão expostos a seguir alguns dos recursos utilizados na aplicação e que são importantes para
o entendimento de como é o desenvolvimento e o comportamento das aplicações na
plataforma BREW. A documentação de todos os recursos disponíveis é instalada no
microcomputador juntamente com o BREW SDK, porém, estaremos utilizando apenas alguns
deles para exemplificar a utilização destes. Para tal, todos os exemplos abaixo serão baseados
na na struct da linguagem C definida a seguir que é praticamente a mesma do univali.c do
anexo 1.
typedef struct _univali { AEEApplet a; // Instância o IApplet AEEDeviceInfo DeviceInfo; // Permite o acesso as informações do dispositivo
IDisplay *pIDisplay; // Acesso os recursos do Display (IDisplay) IShell *pIShell; // Acesso as funcionalidades de Shell
INetMgr *pINetMgr; // Gerenciador de conexões de rede ISocket *pISocket; // Conexão socket IMenuCtl *pIMenuCtl; // Recurso de menu ITextCtl *pITextCtl // Recurso de caixa de texto char *bufferIn // Buffer utilizado para armazenar os dados
// recebidos pela conexão socket char *bufferOut // Buffer utilizado para armazenar os dados a
//serem enviados pelo socket
} univali;
Outro ponto importante a salientar é que no desenvolvimento em C (estruturado) em todas as
funções do sistema possuirá um parâmetro univali * pMe, que será a instância da aplicação e
será por meio desta que teremos acesso a todos os recursos definidos na struct univali.
Quando for executada alguma ação no display, por exemplo, para se acessar o ponteiro do
display deverá ser chamada pMe->pIDisplay (pMe é a aplicação e pIDisplay uma variável da
struct).
78
3.6.5 Arquitetura do ambiente
A figura abaixo apresenta a arquitetura do ambiente de desenvolvimento e simulação.
Figura 26: Arquitetura do ambiente de simulação
O ambiente é composto por dois microcomputadores que formam uma rede local baseada em
ethernet e conectados por meio de um HUB 10/100baseT. O protocolo utilizado pela conexão
entre as máquinas foi o TCP/IP.
No microcomputador da esquerda foi preparado o ambiente de desenvolvimento, bem como o
de simulação do telefone móvel celular provido pelo BREW Simulator. No segundo
computador foi implementado o simulador da residência com o software que simula o
servidor que recebe a conexão do cliente instalado no celular e faz a ativação e desativação
dos pontos de controle.
3.6.6 Interface IShell: Controlando a aplicação
A interface IShell é a responsável por iniciar e parar uma aplicação, instanciar classes /
estruturas e tratar eventos da aplicação como o pressionar de uma tecla.
A IShell poderá ser utilizada para instanciar as estruturas de interface com o usuário como a
ITextCtl que permite ler um texto digitado pelo usuário. Para realizar esta ação, utiliza-se a
seguinte função disponível na interface IShell: ISHELL_CreateInstance(IShell * pIShell,
AEECLSID cls, void * * ppobj). Em pIShell é passado o Shell instanciado na aplicação, no
caso de nosso exemplo seria pMe->aShell. Por padrão toda a estrutura de uma aplicação base
em BREW possui um ponteiro do tipo IShell com o nome pIShell. No caso da struct univali,
pode-se verificar esta situação onde á foram declaradas as variáveis com as estruturas para
IDisplay e IShell, sendo *pIDisplay e *pIShell respectivamente.
79
O parâmetro AEECLSID refere-se ao tipo de estrutura
também chamada de classe pela
plataforma
que será instanciada. Na documentação da API do SDK estão todas os
AEECLSID disponíveis, no caso de um ITextCtl será a AEECLS_TEXTCTL. O parâmetro
ppobj é o ponteiro para a variável do tipo ITextCtl que receberá a estrutura criada, no nosso
caso poderá ser pMe->pITextCtl ou uma variável teste tipo declarada dentro da função em
execução.
No código fonte univali.c, vimos que após iniciar uma aplicação é chamada por padrão da
plataforma a função static boolean univali_HandleEvent(univali* pMe, AEEEvent eCode,
uint16 wParam, uint32 dwParam) quando ocorre um evento no aparelho celular. Este evento
pode ser o pressionar de uma tecla, uma mensagem SMS (Short Message Service) destinada
para a aplicação entre outras. Esta função é tratada pela interface IShell, onde por meio dos
parâmetro da função pode-se identificar qual evento ocorreu e tratá-lo de forma adequada.
Exemplificando, caso o usuário pressione uma tecla, será gerado um evento onde o parâmetro
eCode será passado a informação EVT_KEY e no param wParam a informação AVK_9 que
corresponde a tecla 9 do telefone. Mais a frente será visto como tratar eventos de seleção de
um item de menu e como estas informações são identificadas nesta função.
3.6.7 Interface IDisplay: Manipulado a tela do celular.
Esta interface é responsável pelas ações na tela como desenhar, escrever textos, exibir menus,
entre outras. Para limpar a tela do celular pode-se usar a função
IDISPLAY_ClearScreen(IDisplay * po) onde é passado no parâmetro o display da estrutura
da aplicação. Exemplificando, ao invocar o univali_HandleEvent após iniciar a aplicação
(parâmetro eCode igual a EVT_APP_START) poderá incluir o comando
IDISPLAY_ClearScreen(pMe->pIDisplay). O pMe é repassado para a função
univali_HandleEvent por parâmetro.
3.6.8 Interfaces INetMgr e ISocket: Criando uma conexão Socket Stream (TCP)
A plataforma BREW disponibiliza estas duas interfaces que permite aos desenvolvedores
utilizarem recursos de conexão que antes eram vistos somente em microcomputadores. Para a
aplicação utilizar tais recursos é necessário que esta tenha privilégios para acesso a rede de
80
dados (ver capítulo 3.5.1). A INetMgr é responsável por gerenciar a rede, possibilitando criar
uma conexão socket por meio da conexão de dados disponíveis nas redes de telefonia celular.
Para criar um gerenciador do tipo INetMgr deve-se utilizar a interface IShell da mesma forma
que apresentamos no capítulo 3.6.4 para criar um ITextCtl, onde o AEECLSID será o
AEECLSID_NETMGR. Além disso, na estrutura da aplicação, deverá conter uma variável do
tipo INetMgr * e que será passada para a ISHELL_CreateIntance pelo parâmetro ppobj, no
caso da struct univali será a pMe->pINetMgr. Disponibilizado o gerenciador, por meio dele é
possível criar o socket do tipo ISocket utilizando a função conforme exemplo abaixo:
ISocket socket = INETMGR_OpenSocket(pMe->pINetMgr, AEE_SOCK_STREAM);
É possível criar um socket do tipo UDP alterando o parâmetro que define o tipo de
AEE_SOCK_STREAM para AEE_SOCK_DGRAM. Caso seja criado um socket com
sucesso retornará o ponteiro em socket. Caso contrário socket será NULL.
O próximo passo é realizar a conexão com o servidor. Antes de mais nada, deve-se observar
que todos os dados transferidos e recebidos além da ação de conexão são não bloqueantes e
assíncronos. Esta conexão é efetuada pela interface ISocket conforme apresentado a seguir. É
importante a análise do código e seus comentários para entender como ela funciona.
boolean conexao_Conectar(univali * pMe) { int resultado; // variável temporária para armazenar o resultado dos comandos // Faz a conversão do endereço IP para o padrão INAddr INAddr addr = conexao_ConvertToINAddr( 192.168.1.5 );
// Cria um socket do tipo stream pMe->pISocket = INETMGR_OpenSocket(pMe->pINetMgr,AEE_SOCK_STREAM); // Se criou o socket, tenta a conexão. if (pMe->pISocket){ // Repare que é passada uma função conexao_ConnectCallBack como parâmetro resultado = ISOCKET_Connect(pMe->pISocket, addr ,AEE_htons(5000), conexao_ConnectCallBack,(void*)pMe); // Retorna verdadeiro, porém, se a conexão foi efetuada com sucesso ou não // será tratado pela função conexao_ConnectCallBack return TRUE; }else{ // Falha na criação do socket return FALSE; } // Se o resultado é um erro diferente do AEE_NET_WOULDBLOCK, // ocorreu um erro na função conexao_Connect
81
if (resultado && (resultado != AEE_NET_WOULDBLOCK)) { int erro = ISOCKET_GetLastError(pMe->pISocket); return FALSE; }else if (resultado != AEE_NET_WOULDBLOCK){ // Conexão OK! return TRUE; } // Por padrão retorna erro return FALSE; }
Percebem-se três características básicas:
O endereço de destino (endereço IP) não é do tipo string e sim do tipo INAddr. A função
que realiza esta conversão está no código fonte univali.c em anexo;
A porta também não é um inteiro e sim um tipo específico da plataforma, no caso o tipo
INPort. A função AEE_htons faz a conversão de int para INPort;
Se não ocorrer nenhuma falha nesta função, o sucesso ou não da conexão é tratado pela
função conexao_ConnectCallBack e é chamada de forma assíncrona.
Quando a tentativa de conexão for finalizada, a aplicação chamará a função
conexao_ConnectCallBack passada como parâmetro para INETMGR_OpenSocket. Por
padrão a conexao_ConnectCallBack deve possuir os seguintes parâmetros: void * pUser, int
nError. Em pUser será passada a instância da aplicação que poderá ser acessada realizando
um type cast para univali (nossa struct). No parâmetro nError será repassado o código
referente ao erro ou sucesso da conexão.
Para realizar a escrita ou leitura de dados o mesmo deverá ser feito para tratar os comandos
por meio de funções chamadas na plataforma de Call Back, com uma pequena diferença que é
o fato da interface ISocket tentar enviar ou ler ela encaminha como o parâmetro da função de
call back NULL. Se nesta tentativa retornar um erro AEE_NET_WOULDBLOCK, ele fará
uma nova tentativa agora passando a função de call back. Vejamos no exemplo a seguir.
boolean conexao_Escreve(univali * pMe){ // Variável para tratar o resultado int resultado; // Verifica se o socket está instanciado if (!pMe->aSocket)
return TRUE;
82
//Cancela a função callback referente a escrita ISOCKET_Writeable(pMe->pISocket, NULL, NULL); // Verifica o tamanho dos dados a serem escritos resultado = strlen(pMe->bufferOut); // Tenta escrever os dados resultado = ISOCKET_Write(pMe->pISocket, pMe->bufferOut, strlen(pMe->bufferOut)); // Se ocorreu erro if (resultado == AEE_NET_ERROR){
// Falha no envio return FALSE;
} //Não ainda não enviou os dados if (resultado == AEE_NET_WOULDBLOCK){
//Associa uma função call back a escrita ISOCKET_Writeable(pMe->pISocket, conexao_WriteCallBack,(void*)pMe);
}else{ // Se já enviou os dados return TRUE;
} }
Como visto será realizada a tentativa de envio dos dados sem a utilização da função de call
back. Se necessário, será associada uma função, no caso do exemplo conexao_WriteCallBack,
para tratar o call back. Neste caso específico significa que o socket ainda não está preparado
para enviar os dados, então, ao chamar a função de call back deverá ser submetida a função
conexao_Escrever novamente. Nesta segunda tentativa o envio será efetuado com sucesso
sem a necessidade da função call back,ou seja, após o ISOCKET_Write resultado terá
SUCESSO.
Por este motivo que o buffer de entrada e saída ficam na struct, já que necessitamos dos dados
para enviar ou ler novamente no tratamento do callback da leitura e escrita. No código fonte
univali.c estão todas as funções de envio e recebimento dos dados com suas respectivas
funções de call back e comentários que podem servir de auxílio para um melhor
esclarecimento desta função.
Esses são as funções e requisitos básicos para a utilização do recurso de socket. Vale ressaltar
que tanto na configuração da aplicação realizada pelo desenvolvedor por meio do MIF Editor,
quando no BREW Simulator deverão ter os privilégios adequados para utilizar estes recursos.
83
3.6.9 Interfaces IFileMgr e IFile: Manipulando arquivos
Para que uma aplicação consiga manipular arquivos é necessário também que esta tenha tal
privilégio. Pra isso, basta indicar esta permissão no momento da configuração da aplicação
como que é feita por meio do BRE MIF Editor, conforme apresentado no capítulo 3.5.1.
A manipulação de arquivos nesta plataforma está dividida nas interfaces IFileMgr e IFile. A
IFileMgr é um gerenciador de arquivos que permite às aplicações criar, apagar e renomear
arquivos e diretórios no dispositivo móvel. A estrutura de diretórios que a plataforma utiliza
são (QUALCOMM, 2005):
fs:/ : É o diretório raiz;
fs:/~/ : Diretório referente a onde está aplicação corrente;
fs:/sys/ : Local onte está instalado o sistema BREW. Vale lembrar que estes celulares
não possuem um sistema operacional e sim recursos disponíveis nos chipsets;
fs:/mod/ : Diretório onde estão os arquivos referentes aos módulos que provem as
interfaces dos recursos;
fs:/mif/ : Local onde estão os arquivos .mif que são os dados básicos do sistema e que é
gerado pelo BREW MIF Edigdor;
fs:/shared/ : Este local pode ser utilizado para compartilhar arquivos com outras
aplicações. Pode-se dizer que é um diretório publico para todos os aplicativos do celular;
fs:/address/ : Aqui estão todos os contatos armazenados na agenda do telefone
fs:/ringers/ : Local onde são armazenados os arquivos com os toques;
fs:/card0/ : Disponível na versão BREW 3.1, neste diretório é possível acessar dados de
um cartão de memória removível como um MMC (MultiMedia Card);
fs:/~<clsid>/ : Disponível também na versão BREW 3.1, é possível acessar o diretório de
uma aplicação especifica através de seu Class ID. Exemplificando, no caso da aplicação
univali, seu Class ID é o AEECLSID_UNIVALI. O diretório da aplicação univali poderá
ser acessado através do fs:/~AEECLSID_UNIVALI/;
Além do caminho onde se encontra o arquivo desejado, ele poderá ser aberto em três modos
diferentes: somente leitura (_OFM_READ), leitura e escrita (_OFM_READWRITE) ou ainda
leitura e escrita a partir do fim do arquivo (_OFM_APPEND). Além destes, existe ainda o
modo _OFM_CREATE que é utilizado para criar um arquivo novo. A seguir seque o exemplo
84
de como utilizar estes recursos. No univali.c também foram utilizados para armazenar as
configurações de conexão ao servidor.
Para criar um gerenciador devemos ter uma valiável do tipo IFileMgr. Pode ser declarada
como IFileMGr *fileMgr e instanciá-lo conforme abaixo:
ISHELL_CreateInstance(pMe->pIShell,AEECLSID_FILEMGR,(void **)&fileMgr);
Após estar criado poderemos declarar e criar uma variável arquivo como por exemplo IFile
*file e abrir o arquivo com o comando:
file = IFILEMGR_OpenFile(fileMgr, fs:/~/univali.cfg , _OFM_READWRITE);
Veja que será aberto o arquivo univali.cfg que está no diretório da aplicação (fs:/~/) e o
parâmetro _OFM_READWRITE indica que ele será aberto para leitura e escrita. Se o arquivo
não existir, file conterá NULL. Deverá então ser criado o arquivo, se assim desejar, com o
mesmo comando, porém, com o parâmetro _OFM_CREATE e na seqüência aberto com o
mesmo comando e parâmetro _OFM_READWRITE.
A escrita pode ser executada por meio do comando
IFILE_Write(file,buf,sizeof(char)*strlen(buf)) onde buf contém os dados e é do tipo char*. A
leitura utiliza-se o comando IFILE_Read(file,buf,numChar) onde o buf é do tipo char* e o
numChar é o número de caracteres a serem lidos do arquivo.
Finalizada a manipulação do arquivo poderá ser fechado o arquivo com o comando
IFILE_Release(file) e, se julgar necessário, o gerenciador com IFILEMGR_Release(fileMgr).
3.6.10 Recursos visuais criados por meio do BREW Resource Editor
Existe disponível na plataforma BREW alguns recursos visuais como textos, figuras, menus e
componentes de diálogos de forma fácil e rápida. O BREW Resource Editor permite ao
desenvolvedor incluir recursos destes tipos de uma forma mais prática e ágil. A tela principal
do Resource Editor é apresentada abaixo:
85
Figura 27: BREW Resource Editor
Como pode ser percebido, existem quatro tipos de recursos disponíveis:
Strings: são textos previamente especificados. Normalmente eles são utilizados para
definir o título de uma tela, ou de um menu, textos estáticos que serão exibidos na tela,
descrição de itens de menu, entre outros;
Objects: são diferentes tipos de objetos como uma imagem ou um arquivo no formato
html;
Binaries: algum recurso que já foi gerado em outra aplicação e deseja-se importar, como
uma tela padrão de usuário e senha, por exemplo;
Dialogs: são os diálogos propriamente ditos com o usuário do celular, como por exemplo
uma nova tela de entrada de dados como um texto a ser enviado via SMS.
Ao criar um destes recursos, todos têm em comum dois atributos: seu ID e Name. O ID será
um número designado automaticamente pela ferramenta e o Name o programador é quem irá
identificá-lo. Para criar um novo recursos, basta ir no menu Resource e selecionar o tipo
desejado. A figura a seguir mostra um recurso do tipo string criado.
86
Figura 28: Criando um recurso
Pode-se verificar que o ID deste recurso chamado de STR_TITULO é o 1001, designado pela
própria ferramenta, porém, possibilita a edição que não é aconselhável. O conteúdo deste
recurso é a frase Olá UNIVALI . Depois de criado os recursos desejados, deverá salvar os
recursos no mesmo diretório onde está sendo desenvolvida a aplicação e compilado os
recursos que gerará dois arquivos: um com extensão .brh e outro .bar. O .brh será feito o
include deste na aplicação e o .bar contém os recursos já compilados, ou seja, no formato
binário.
Como acessar estes recursos será apresentado no tópico seguinte que faz uso de menu por
através da interface IMenuCtl baseado em recursos do tipo string criados com o BREW
Resource Editor.
3.6.11 Criando e manipulando menus (IMenuCtl)
Para criar e manipular menus a plataforma disponibiliza a interface IMenuCtl. É por meio
desta interface que pode ser criados menus de 4 tipos (QUALCOMM,2005):
87
AEECLSID_LISTCTL: Menu de lista tradicional com itens colocados um abaixo do outro
como uma pilha de opções e permite navegar através das teclas de posicionamento para
cima e para baixo;
AEECLSID_MENUCTL: Idêntico ao anterior, porém, possibilita a inclusão de ícones ao
lado de cada item para melhor identificá-lo;
AEECLSID_SOFTKEYCTL: Disponibiliza os itens de menu na parte mais inferior da
tela, permitindo navegar entre todos os itens através das teclas de posicionamento para
esquerda e direita;
AEECLSID_ICONVIEWCTL: Este é baseado em imagens do tipo bitmap que são
organizados na tela como uma matriz, permitindo ao usuário navegar em seus itens por
meio das teclas de direção para cima, para baixo, para a direita e para a esquerda.
Quando o usuário encontra o item desejado este pressiona a tecla de seleção que gerará um
evento passando no eCode EVT_SELECT e o wParam irá o ID do item, que no nosso caso
será o ID do recurso criado utilizando o BREW Resource Editor. Abaixo segue um exemplo
comentado da criação de um menu em tempo de execução. Ressalto que é possível criar
menus também por meio do BRE Resoucce Editor.
void menu_Principal(univali * pMe){ //Área da tela que será utilizada pelo menu AEERect rect; rect.x = 0; rect.y = 0; // Por meio do DeviceInfo, identificamos os limites da tela rect.dx = pMe->DeviceInfo.cxScreen; rect.dy = pMe->DeviceInfo.cyScreen-15; // Instancia ao controle de Menu ISHELL_CreateInstance(pMe->pIShell, AEECLSID_MENUCTL, (void **)&pMe-
>pIMenuCtl); // Seta o título onde o texto é um recurso String que foi criado como recurso. IMENUCTL_SetTitle(pMe->aMenuCtl,UNIVALI_RES_FILE,
MENU_PRINCIPAL_TITULO, NULL); // Seta o tamanho da tela IMENUCTL_SetRect(pMe->pIMenuCtl,&rect); // Adiciona os itens do menu IMENUCTL_AddItem(pMe->pIMenuCtl,UNIVALI_RES_FILE,
STR_CONECTAR,STR_CONECTAR, NULL, 0); IMENUCTL_AddItem(pMe->pIMenuCtl,UNIVALI_RES_FILE,
STR_PONTOS,STR_PONTOS, NULL, 0); IMENUCTL_AddItem(pMe->pIMenuCtl,UNIVALI_RES_FILE,
STR_CONFIGURAR,STR_CONFIGURAR, NULL, 0);
88
IMENUCTL_AddItem(pMe->pIMenuCtl,UNIVALI_RES_FILE, STR_SAIR,STR_SAIR,
NULL, 0); // Ativa o Menu IMENUCTL_SetActive(pMe->pIMenuCtl,TRUE);
}
Pode ser percebido que inicialmente deve-se definir a área da tela que será ocupada pelo
menu. Isso pode ser feito utilizando o DeviceInfo que é contém todas as informações
dimensões da tela. A criação do menu também é feita através da interface IShell.
Para adicionar um item, a função IMENUCTL_AddItem() faz referência a
UNIVALI_RES_FILE. Este é como é repassado para a aplicação qual é o arquivo de recurso
que está sendo utilizado. Pode ser verificado qual é o nome do arquivo abrinco o univali.brh e
lá teremos um #define identificando seu nome e qual arquivo.bar ele referencia. Além de
informar qual o arquivo de recursos, também é informado qual o identificador que será
repassado a função que trata o evento e qual a identificação do item de menu que no nosso
caso ambos são o recurso criado que está no arquivo de recursos.
Para que a navegação ocorra conforme o esperado, é necessário acrescentar na função
univali_HandleEvent() ao tratar o EVT_KEY (ao pressionar uma tecla) as seguintes linhas de
código:
if (pMe->pIMenuCtl){ IMENUCTL_HandleEvent(pMe->pIMenuCtl, EVT_KEY, wParam, 0);
}
Este tratamento fará com que ocorra o efeito de navegação do menu na tela. Sem ela o menu
sempre ficará estático independente das teclas que se pressiona. Quando um item for
selecionado ocorrerá a chamada da função univali_HandleEvent(), onde através do tratamento
do evento EVT_COMMAND será verificado pelo parâmetro wParam é igual a um dos
recursos (como o STR_SAIR) e o desenvolvedor trata este evento conforme suas
necessidades.
Estes são alguns dos recursos disponíveis no BREW SDK e utilizados para o estudo da
plataforma BREW por meio do protótipo apresentado. Será apresentado a seguir o
funcionamento do protótipo bem como as telas da aplicação móvel.
89
3.6.12 Funcionamento do protótipo
Inicialmente o sistema apresentará a tela principal com as opções Conectar , Configurar
pontos , Config. IP/Porta e Sair conforme a figura a seguir.
Figura 29: Tela principal
90
Note que na Figura 29, onde temos a tela do BREW Simulator por completo é possível
verificar a utilização da memória disponível para este celular virtual, já que para dispositivos
móveis as restrições de recursos é uma constante e o desenvolvedor deve estar atendo a isto.
Ao selecionar a opção conectar o cliente fará a conexão socket com o servidor. Se o IP e porta
do servidor não estiverem configurados, será apresentada uma mensagem de erro solicitando a
configuração. Uma outra mensagem de erro é apresentada no caso de falha na conexão.
A tela para configuração de IP e porta é apresentada na figura abaixo.
Figura 30: Tela de configuração
Considerando que esteja configurado corretamente e o servidor esteja ativo e respondendo, ao
solicitar a lista de pontos o sistema solicitará esta ao servidor que retornará a listagem. De
posse da lista de pontos, o cliente monta um menu em tempo de execução onde cada item é
um ponto de controle.
O usuário navegando pelos pontos de controle poderá saber se o ponto está ativo ou não pela
representação feita por meio de um ícone no formato de uma lâmpada que pode estar acesa ou
91
apagada. Abaixo é apresentado o menu com a lista de pontos e seus estados representados
pelas lâmpadas.
Figura 31: Controle dos pontos
Este é o protótipo onde foram utilizados recursos de tela, conexão socket, arquivos e
manipulação de eventos de teclado. A seguir serão apresentadas algumas comparações entre
as tecnologias de desenvolvimento disponíveis e estudadas.
3.7 COMPARANDO FERRAMENTAS DE DESENVOLVIMENTO
Como pode ser visto, o SuperWaba é uma proposta interessante para desenvolvimento de
software para dispositivos móveis. Uma tecnologia nova que possui uma similaridade com o
J2ME, porém, não muito difundido e exige dispositivos com um poder de processamento alto
ainda, como os PDA.
J2ME já é um padrão mais difundido no mundo, já que tem suas raízes baseadas em
tecnologia que deu certo como o J2SE e J2EE, sendo uma grande promessa para o mercado de
telefonia celular.
Visual Studio .NET, apesar de ser uma ferramenta de desenvolvimento que dá ganhos de
produtividade, inicialmente necessitaria de um dispositivo móvel com suporte a algumas
tecnologias Microsoft. Tudo vai depender da fatia de mercado da Microsoft neste seguimento.
92
A Plataforma BREW se mostra no cenário atual como uma solução boa para todos os
envolvidos na cadeia de produtos para telefonia celular. Além disso, ela não tem confronto
direto com as demais tecnologias, pelo contrário, possibilita que telefones celulares com
suporte BREW rodem aplicativos J2ME e que ambientes de desenvolvimento com o Visual
Studio .NET sejam facilmente adequados para o desenvolvimento de aplicativos para esta
plataforma.
Um outro ponto único da BREW é o BREW Distribution System, que permite uma gerência de
todos os recursos utilizados para disponibilizar um serviço de qualidade aos clientes, aumento
da receita média por usuário das operadoras e padroniza junto aos fabricantes o hardware dos
celulares por meio de um chipset com suporte a BREW.
Como o desenvolvimento para a plataforma é em C/C++, linguagem que já está no mercado a
alguns anos, é um ponto forte para os que já dominam esta linguagem iniciar o
desenvolvimento de soluções móveis e atuar no mercado. Ressaltamos que o desenvolvimento
para um ambiente restrito de recursos exige do programado alguns conhecimentos adicionais
sobre os dispositivos moveis, tecnologia celular, comunicação de dados nesta tecnologia e as
particularidades da BREW.
93
4 CONSIDERAÇÕES FINAIS
A proposta da Qualcomm é possibilitar o desenvolvimento de aplicações tanto em C quanto
em C++, além de Java por meio de uma máquina virtual apropriada. Na prática foram
identificadas algumas dificuldades e também deficiências relacionadas ao desenvolvimento e
testes das aplicações. A primeira dificuldade foi com o ambiente para realizar o debug ou
depuração da aplicação, já que o resultado final é um arquivo com extensão DLL e somente é
possível testá-lo executando-o no BREW Simulator. Quando um novo projeto é criado
utilizando o BREWAppWizard ele não configura o Visual Studio para permitir depurar este
projeto. Esta configuração foi identificada e apresentada neste trabalho.
O que mais impactou no desenvolvimento do protótipo com base na documentação no modelo
UML foi o fato dos recursos da plataforma ser todos baseados em struct da linguagem C, ou
seja, não são objetos como no C++, além de não conseguir criar uma aplicação em C++ como
é a proposta da Qualcomm. Aliás, a Qualcomm ([2002-2005a]) diz que pretende-se que o
BREW seja neutro em relação a linguagem de programação [...] embora haja, no momento,
certas limitações com respeito ao uso do C++ . Foram feitas tentativas de se conseguir
informações do suporte da Qualcomm para solucionar o problema, mas a mesma só oferece
suporte para os desenvolvedores registrados. Mesmo utilizando todas as orientações
disponíveis no site da Qualcomm, não se conseguiu fazer com que uma aplicação
desenvolvida em C++ fosse executada no BREW Simulador com sucesso, por isso optou-se
por desenvolver o protótipo em C estruturado.
Este problema poderia estar relacionado ao ambiente de desenvolvimento e não a plataforma,
porém, sem o suporte adequado não foi possível verificar na prática esta possibilidade, mesmo
criando dois ambientes, um com o Visual Stúdio .NET 2003 e outro com o Visual C++ 6.0
que são os que foram indicados pela Qualcomm como de fácil integração.
94
Um recurso que ainda não está disponível na plataforma é a execução de aplicações
multitarefa, que permitiria a execução de mais de uma tarefa paralelamente e muito utilizado
na programação para microcomputadores e servidores nos dias de hoje. Este recurso seria
muito utilizado para realizar o tratamento da conexão com o servidor,
95
5 CONCLUSÃO E TRABALHOS FUTUROS
5.1 CONCLUSÃO
Nos estudos realizados ficou evidente a evolução das tecnologias de celulares e o crescimento
do mercado mundial neste segmento. Pode-se dizer que a telefonia celular a médio prazo
poderá ser considerada como uma grande rede de comunicação de dados se m fio.
Além da mobilidade propiciada pela rede, os dispositivos móveis estão cada vez mais
poderosos, no que se diz respeito ao processamento de dados, disponibilizando recursos
multimídias e conexões as redes móveis com taxas de transferência que permitem o
desenvolvimento de aplicações cada vez mais interativas.
No contexto de soluções para o desenvolvimento de aplicações para telefonia móvel, a
plataforma BREW é uma solução adequada às necessidades de mercado. O BREW SDK
possui recursos que possibilitam o desenvolvimento de soluções completas, tanto para uso
pessoal quanto empresarial. Para o desenvolvedor, considerando que este seja registrado, a
Qualcomm disponibiliza uma série de recursos de suporte que não foram avaliados neste
trabalho, mas que certamente auxiliariam e muito no desenvolvimento e teste.
Esta restrição de suporte acrescentou ao trabalho a dificuldade de conseguir informações
precisas de como é o desenvolvimento para a plataforma, utilização das structs disponíveis e
uma documentação mais clara da API.
O conjunto de ferramentas que compõe o SDK é amplo e de fácil utilização, deixando a
desejar apenas em alguns aspectos de integração como o ambiente de desenvolvimento, o que
no início dos estudos e desenvolvimento para a plataforma acabou acarretando em atraso no
projeto. Ressalto que com o suporte adequado espera-se que estas dificuldades sejam
facilmente superadas.
96
O BDS (BREW Distribuction System) abre para os desenvolvedores certificados e registrados
um mercado mundial com as demais operadoras de celular. Este é um importante ponto de
apoio aos desenvolvedores que já possuem à sua disposição um grande mercado de atuação,
algo difícil de ser conquistado em relação a desenvolvimento utilizando outras tecnologias. Só
a Vivo, que possui mais de 38% do total de celulares no Brasil (ANATEL, 2005d), isto
significa aproximadamente 22 milhões de celulares considerando que no Brasil em janeiro de
2005 eram 68,6 milhões de aparelhos celulares habilitados (ANATEL, 2005b). Num mercado
mundial este número bem mais expressivo.
O foco deste trabalho era o estudo da plataforma BREW e não o desenvolvimento do
protótipo. Mesmo assim, as dificuldades para a implementação do protótipo, que
aparentemente era de simples concepção, foram inúmeras. Além restrição de suporte do
fabricante, a linguagem C não era de meu domínio, o que dificultou a implementação e
necessitou de um aprendizado sobre. A utilização da linguagem C++ se mostrou mais
amigável e de fácil desenvolvimento, mas, como foi apresentado no capítulo 4, não foi
possível utilizá-la. Considero um bom aprendizado adquirido na linguagem C com este
protótipo. A possibilidade do desenvolvimento em J2ME foi descartada, já que se buscava a
utilização de recursos diferentes dos que já foram abordados em outros trabalhos de conclusão
de curso. Um desafio que considero superado.
Outro ponto importante e que acaba impactando no desenvolvimento de aplicativos para
celular são as restrições em relação a recursos disponíveis em um aparelho celular. Mesmo
com a tecnologia atual, este cuidado deve ser tomado. Ainda há grandes limitações em relação
à memória disponível, área de tela, consumo de bateria, entre outros. Quanto maior for a
portabilidade desejada entre aparelhos que suportam BREW, maiores são as preocupações
com a escassez destes recursos. Especificamente para o BREW, ela especifica outros tipos de
variáveis similares aos nativos da linguagem C, que acrescenta mais um ponto de atenção no
desenvolvimento.
Comparando esta tecnologia com as demais estudadas, ela se destaca pela integração que o
BDS disponibiliza para toda a cadeia envolvida. Para os desenvolvedores o amplo mercado de
atuação já disponível é um outro ponto importante que deve ser considerado. No
desenvolvimento, seus recursos também são amplos e é ideal para os desenvolvedores que já
possuem conhecimentos em C/C++ e tecnologia móvel celular.
97
5.2 TRABALHOS FUTUROS
Com base nos estudos disponibilizados neste trabalho, poderá ser utilizado para o
desenvolvimento de soluções para celulares baseados em BREW. Aplicações seguras
utilizando SSL também poderão ser exploradas já que para transações entre o celular e
serviços principalmente financeiros, esta é uma premissa básica e tendência de mercado.
Especificamente para o protótipo, poderá ser desenvolvido um hardware que realize a
conexão com um modem banda lagar e controle os pontos de energia da casa. Com isso não
seria mais necessário depender de um microcomputador para tal.
Empresas que possuem seus vendedores em campo e necessitam de atualização on-line dos
seus pedidos e estoques, técnicos recebendo ordens de serviço e as executando em campo, ou
até mesmo empresas que realizam medidas como consumo de energia elétrica são clientes
potenciais. Estes podem fazer uso de aplicações em celulares, possibilitando ainda a estas
localizar geograficamente seus funcionários por meio do recurso de GPS que é oferecido pela
plataforma. Ressalto que este recurso tem que estar disponível na rede de telefonia celular.
98
ANEXO 1: UNIVALI.C
99
/*========================================================================= FILE: univali.c =========================================================================*/
/*========================================================================= INCLUDES AND VARIABLE DEFINITIONS =========================================================================*/ #include "AEEModGen.h" // Definições do módulo de interface #include "AEEAppGen.h" // Definições do módulo da aplicação (applet) #include "AEEShell.h" // Definições da interface Shell
#include "AEEFile.h" // Definições da interface File #include "AEENet.h" // Definições da interface Socket
#include "AEEMenu.h" // Definições do módulo de interface Menu #include "AEEText.h" // Módulo para utilizar o controle ITextCtl #include "AEEStdLib.h" // Módulo padrão
#include "ctype.h" #include "string.h" #include "nmdef.h"
// Arquivo gerado pelo BREW MIF Editor com os dados referentes a aplicação // como o ID da aplicação, nome da aplicação e privilégios #include "univali.bid"
// Arquivo gerado pelo BREW Resource Editor com os recursos criados // para o sistema #include "univali.brh"
//Nome escolhido para o arquivo de configuração do sistema #define ARQ_CONFIG "univali.cfg"
/*------------------------------------------------------------------- Struct da applet. Todas as variáveis são referenciadas via "pMe->" -------------------------------------------------------------------*/ typedef enum {CONECTANDO = 0, CONECTADO, LER, ESCREVER, PRONTO, DESCONECTADO, ERRO}; typedef enum {LISTA_PONTO = 0, ALTERA_PONTO, NENHUMA};
typedef struct _univali { AEEApplet a ; // Instância o IApplet AEEDeviceInfo aDeviceInfo; // Permite o acesso as informações // do dispositivo IDisplay *aDisplay; // Acesso as funcionalidades do Display IShell *aShell; // Acesso as funcionalidades de Shell INetMgr *aNetMgr; // Gerenciador de conexões de rede ISocket *aSocket; // Conexão socket IMenuCtl *aMenuCtl; // Gerencia o Menu Principal char *aHost; // Armazena o endereço IP do host remoto int aPorta; // Armazena a porta do Host remoto int aStatusSocket; // Status atual do Socket int aAcao; // Ação a ser executada char *bufferOut; // Buffer de saída do Socket char *bufferIn; // Buffer de entrada do Socket } univali;
/*------------------------------------------------------------------- Function Prototypes -------------------------------------------------------------------*/
100
//############# Funções que tratam a aplicação ###################### // Função que trata os eventos da aplicação baseada no IApplet (padrão) static boolean univali_HandleEvent(univali* pMe, AEEEvent eCode, uint16 wParam, uint32 dwParam); // É chamada por default no momento que a aplicação é iniciada pelo usuário boolean univali_InitAppData(univali* pMe); //É chamada por default no momento da finalização da aplicação pelo usuário void univali_FreeAppData(univali* pMe); // Funcão de teste para imprimir na tela void univali_Print(univali * pMe, char * pTexto, AEEFont * pFonte, RGBVAL * pCor, uint32 pAlinhamento); // Limpa a tela para ser redesenhada com os novos dados/componentes void univali_LimpaTela(univali * pMe); // Carrega a configuração de IP e Porta do servidor remoto armazenadas // em arquivo void univali_CarregaConfiguracao(univali * pMe); // Apresenta a tela para configuração de IP e Porta do servidor void univali_ConfiguraIP(univali * pMe); // Salva as confogurações informadas pelo usuário em arquivo e atualiza // aHost e aPorta void univali_SalvaConfiguracao(univali * pMe); // Trata os dados recebidos pelo socket void univali_TrataDado(univali * pMe);
//############ Funções que tratam a conexão ####################### // Faz a conexão ao servidor boolean conexao_Conectar(univali * pMe, boolean pStatus); // Faz a conversão do IP em string para o tipo INAddr da plataforma INAddr conexao_ConvertToINAddr(char * pIp); // Escreve uma sequencia de caracteres no socket boolean conexao_Escreve(univali * pMe, char * pDados); // Le uma sequencia de caracteres do socket boolean conexao_Le(univali * pMe, char * pDados); // Trata o retorno da conexão quando solicitada void conexao_ConnectCallBack(void * pUser, int nError); // Trata o retorno da leitura quando solicitada void conexao_ReadCallBack(void *pUser); // Trata o retorno da escrita quando solicitada void conexao_WriteCallBack(void *pUser);
//############ Funções que tratam os menus ######################## // Exibe o menu principal void menu_Principal(univali * pMe); // Monta um menu com os pontos de controle recebidos do servidor void menu_Pontos(univali * pMe, char * pPontos);
/*========================================================================= FUNCTION DEFINITIONS =========================================================================*/
// Função que é chamada por defaul pela plataforma para instanciar // uma aplicação int AEEClsCreateInstance(AEECLSID ClsId, IShell *pIShell, IModule *po, void **ppObj) {
*ppObj = NULL; if( ClsId == AEECLSID_UNIVALI ){
// Instancia a aplicação (applet) utilizando a // estrutura definida if( AEEApplet_New(sizeof(univali),
ClsId,
101
pIShell, po, (IApplet**)ppObj, (AEEHANDLER)univali_HandleEvent, (PFNFREEAPPDATA)univali_FreeAppData) ){
//Inicializa os dados da alicação antes de enviar //o evento ETV_APP_START
if(univali_InitAppData((univali*)*ppObj)){ // Retorna sucesso na inicialização return(AEE_SUCCESS);
}else{ //Libera a aplicação liberando a memória alocada. IAPPLET_Release((IApplet*)*ppObj); return EFAILED;
} } }
return(EFAILED); }
// Função que trata os eventos como o pressionar de uma tecla e // a chegada de um SMS static boolean univali_HandleEvent(univali* pMe, AEEEvent eCode, uint16 wParam, uint32 dwParam)
{ // Variáveis auxiliares CtlAddItem ctl; int res; char * buffer; // Trata o eCode que identifica o tipo de evento
switch (eCode) {
// Aplicação inicializada case EVT_APP_START: // Carrega os dados referentes ao dispositivo em aDeviceInfo
ISHELL_GetDeviceInfo(pMe->a.m_pIShell, &pMe->aDeviceInfo); // Instancia o gerenciador aNetMgr que tratará as conexões ISHELL_CreateInstance(pMe->a.m_pIShell, AEECLSID_NET,
(void **)&pMe->aNetMgr); // Carrega as configurações do host remoto univali_CarregaConfiguracao(pMe); if (pMe->aHost && pMe->aPorta){ // Limpa a tela univali_LimpaTela(pMe);
// Exibe o menu principal menu_Principal(pMe);
} return(TRUE);
break; // Aplicação sendo finalizada case EVT_APP_STOP: // Adicione código para tratar o encerramento da aplicação
return(TRUE); // Aplicação suspensa case EVT_APP_SUSPEND:
// Adicione seu código aqui return(TRUE); // Aplicação sendo retomada case EVT_APP_RESUME:
// Adicione seu código aqui
102
return(TRUE); // Chegada de uma Mensagem do tipo SMS case EVT_APP_MESSAGE:
// Adicione seu código aqui return(TRUE);
// As opções abaixo são para tratar // os eventos nos dialogs. // Mesmo que não sejam tratados, os // três EVTs a seguir devem ser declarados // retornando TRUE. case EVT_DIALOG_START: return TRUE; case EVT_DIALOG_INIT: return TRUE; case EVT_DIALOG_END: return TRUE;
// Tecla pressionada case EVT_KEY: if (pMe->aMenuCtl){ univali_Print(pMe,NULL,AEE_FONT_NORMAL,0, (IDF_ALIGN_BOTTOM|IDF_ALIGN_CENTER)); IDISPLAY_Update(pMe->aDisplay); // Esta linha é obrigatória para que o
// BREW atualize a tela // "animando" o menu conforme a navegação IMENUCTL_HandleEvent(pMe->aMenuCtl, EVT_KEY, wParam, 0); } return(TRUE); // Um comando foi enviado (pressionou Select) case EVT_COMMAND: // Verifica qual o comando foi enviado. Está relacionado com os // recursos criados pelo BREW Resource Editor switch (wParam){ case MENU_PRINCIPAL_SAIR: // Fechar aplicativo res = ISHELL_CloseApplet(pMe->aShell,FALSE); return TRUE;
break; case MENU_PRINCIPAL_CONFIGURAR: // Limpa a tela univali_LimpaTela(pMe); // Exibe tela de configuração de IP e Porta univali_ConfiguraIP(pMe); return (TRUE); case CONFIG_OK: // Salva configuração em arquivo univali_SalvaConfiguracao(pMe); // Finaliza tela de dialogo para configuração ISHELL_EndDialog(pMe->a.m_pIShell); // Limpa tela univali_LimpaTela(pMe); // Exibe menu principal menu_Principal(pMe); return (TRUE); case MENU_PRINCIPAL_PONTOS: // Se não ocorreu erro na última ação if (pMe->aAcao != ERRO){ // Armazena "PONTOS" no buffer de saída pMe->bufferOut = "PONTOS"; // Altera ação para LISTA_PONTO pMe->aAcao = LISTA_PONTO;
103
// Verifica se o socket está conectado if (pMe->aStatusSocket == PRONTO){ // Escreve o buffer na conexão conexao_Escreve(pMe,pMe->bufferOut); // Aguarda retorno do servidor conexao_Le(pMe,pMe->bufferIn); } }else{ // Se há erro, não está conectado univali_Print(pMe,"Não está conectado!",
AEE_FONT_NORMAL, MAKE_RGB(0xFF,0x00,0x00), (IDF_ALIGN_CENTER|IDF_ALIGN_BOTTOM)); } return (TRUE); case MENU_PRINCIPAL_CONECTAR: if (!pMe->aSocket){ // Limpa a tela univali_LimpaTela(pMe); //Envia comando de desconexão conexao_Conectar(pMe,FALSE); // Exibe um splash form simples para a conexão univali_Print(pMe,"CONECTANDO",
AEE_FONT_BOLD,0, (IDF_ALIGN_CENTER | IDF_ALIGN_MIDDLE));
univali_Print(pMe,"Aguarde...", AEE_FONT_NORMAL,0,
(IDF_ALIGN_CENTER | IDF_ALIGN_BOTTOM)); //Envia comando de conexão conexao_Conectar(pMe,TRUE); // O sucesso ou não da conexão será
//tratado pela // função conexao_ConnectCallBack
}else{ // Está conectado e solicita desconexão univali_LimpaTela(pMe); // Desconecta conexao_Conectar(pMe,FALSE); menu_Principal(pMe); } return TRUE; // Os códigos do "case 3000" e "default" são para // tratar os pontos de controle // que são montados em tempo de execução // já que quem possui a lista é o servidor. // Foi definido que os itens de menu com id
// entre 3001 e 3100 // são pontos de controle e o 3000 a opção sair do menu. case 3000: // Sai do menu de pontos e volta para o principal if (pMe->aAcao==LISTA_PONTO ||
pMe->aAcao==ALTERA_PONTO){ // Seta ação para nenhuma
pMe->aAcao = NENHUMA; // Limpa a tela
univali_LimpaTela(pMe); // Exibe menu principal menu_Principal(pMe); } return TRUE; default:
104
// Trata os pontos de controle if (wParam > 3000 && wParam < 3100){ // Recupera o íten de menu selecionado IMENUCTL_GetItem(pMe->aMenuCtl,wParam,&ctl); // Altera ação para ALTERA_PONTO pMe->aAcao = ALTERA_PONTO; // Limpa buffer de saida pMe->bufferOut = "";
// Aloca memória para a variável temporária buffer = MALLOC(sizeof(char)*21);
// Converte a descrição do ponto // de AECHAR para char
WSTRTOSTR(ctl.pText,buffer,20); // dwData = 0: ponto inativo;
// dwData = 1: ponto ativo if (ctl.dwData == 1)
// Solicita a desativação STRCAT(buffer,"|D\t"); else
// Solicita a ativação STRCAT(buffer,"|A\t"); // Faz uma cópia da string
// para o buffer de saída pMe->bufferOut = STRDUP(buffer); // Escreve os dados na conexão conexao_Escreve(pMe,pMe->bufferOut); // Aguarda o retorno conexao_Le(pMe,pMe->bufferIn); // Libera memória alocada
// nas variáveis auxiliares ctl.pImage = NULL; FREE(buffer); } return (TRUE); } return (TRUE); // Se o evento ocorrido não foi tratado de forma específica // executa o default default:
// Você pode definir o código default aqui. break; }
return FALSE; }
// Esta função é chamada quando sua aplicação está sendo iniciada boolean univali_InitAppData(univali * pMe) { // Coleta as informações do celular // E referencia todos os dados na estrutura em pMe->DeviceInfo pMe->aDeviceInfo.wStructSize = sizeof(pMe->aDeviceInfo); ISHELL_GetDeviceInfo(pMe->a.m_pIShell,&pMe->aDeviceInfo);
// Faz uma referência de pMe->a.m_pIDisplay para pMe->aDisplay // Por default, usa-se pMe->a.m_pIDisplay. Esta referência é
// para facilitar. // É incluída pelo BREW App Wizard
pMe->aDisplay = pMe->a.m_pIDisplay; pMe->aShell = pMe->a.m_pIShell;
// Inicializando os buffers utilizados
105
// Pelo fato de tratar envio e recebimento pelas // funções Callback, se faz necessário uma forma de // recuperar os dados quando executar as Callbacks pMe->bufferIn = MALLOC(sizeof(char)*1000); MEMSET(pMe->bufferIn,'\0',1000); pMe->bufferOut = MALLOC(sizeof(char)*1000); MEMSET(pMe->bufferOut,'\0',1000);
pMe->aStatusSocket = DESCONECTADO; return (TRUE); }
// Libera os recursos alocados quando a aplicação está sendo terminada void univali_FreeAppData(univali* pMe) { // Desconecta conexao_Conectar(pMe,FALSE); // Libera o menu se estiver alocado if ( pMe->aMenuCtl != NULL ){ IMENUCTL_Release(pMe->aMenuCtl); pMe->aMenuCtl = NULL;
} // Libera o gerenciador de rede se estiver alocado if (pMe->aNetMgr){ INETMGR_Release(pMe->aNetMgr); pMe->aNetMgr = NULL; } // Libera as Strings FREE(pMe->aHost); pMe->aHost = NULL; FREE(pMe->bufferOut); pMe->bufferOut = NULL; FREE(pMe->bufferIn); pMe->bufferIn = NULL; }
// Trata os dados recebinos na conexão void univali_TrataDado(univali * pMe){ // variáveis auxiliares CtlAddItem ctl; uint16 id; // Verifica qual a ação em execução switch(pMe->aAcao){ // Solicita a lista de pontos case LISTA_PONTO: // Monta um menu com os pontos recebidos pela conexão menu_Pontos(pMe,pMe->bufferIn); return; // Solicitou alterar o estado case ALTERA_PONTO: if (strcmp(pMe->bufferIn,"OK")){ id = IMENUCTL_GetSel(pMe->aMenuCtl); IMENUCTL_GetItem(pMe->aMenuCtl,id,&ctl); // dwData = 0: ponto inativo;
// dwData = 1: ponto ativo if (ctl.dwData == 0){ ctl.pImage = ISHELL_LoadResImage(pMe->aShell,
UNIVALI_RES_FILE, IMG_LIGADO);
ctl.dwData = 1; }else{ ctl.pImage = ISHELL_LoadResImage(pMe->aShell,
106
UNIVALI_RES_FILE,
IMG_DESLIGADO); ctl.dwData = 0; } // Informa a nova configuração do item IMENUCTL_SetItem(pMe->aMenuCtl,ctl.wItemID, ( MSIF_IMAGE | MSIF_DATA ) ,&ctl); // Atualiza o menu na tela IMENUCTL_Redraw(pMe->aMenuCtl); // Libera imagem da memória (temporária) IIMAGE_Release(ctl.pImage); ctl.pImage = NULL; } return; default: return; } }
// Salva as configurações atuais no arquivo univali.cfg void univali_SalvaConfiguracao(univali * pMe){ // Variável que apontará para o IDialog ativo IDialog * dialogo; // Variável utilizada para recuperar os textos dos ITextCtl // pertencentes ao IDialog ativo IStatic * texto; // Gerenciador de arquivos IFileMgr *fileMgr; // ponteiro para o arquivo de configuração IFile *file; // Variaveis "temporárias" AECHAR buffer[16]; char * buf = MALLOC(sizeof(char)*16); // Instancia um IFileMgr ISHELL_CreateInstance(pMe->aShell,AEECLSID_FILEMGR,
(void **)&fileMgr); // Se der erro para. if (!fileMgr) return; file = IFILEMGR_OpenFile(fileMgr, ARQ_CONFIG, _OFM_READWRITE); // se não coseguir abrir o arquivo, para. if(!file){ int erro = IFILEMGR_GetLastError(fileMgr); //Se o erro foi motivado por não existir o arquivo if (erro == EFILENOEXISTS){ // Cria o arquivo file = IFILEMGR_OpenFile(fileMgr, ARQ_CONFIG,
_OFM_CREATE); }else{ return; } }else{ IFILE_Truncate(file,0); } // Se o Host ainda não tem memória alocada, aloca 16 posições de char // já que o endereço será de no máximo 15 bytes + o \0
// (fim de string) if (!pMe->aHost) pMe->aHost = MALLOC(sizeof(char)*16); // Recupera o IDialog ativo
107
dialogo = ISHELL_GetActiveDialog(pMe->a.m_pIShell); // Recupera o ITextCtl referente ao endereço IP texto = (IStatic*)IDIALOG_GetControl(dialogo, DIALOGO_CONFIGURAR_IP); // Carrega em buffer o endereço IP informado ITEXTCTL_GetText((ITextCtl*)texto,buffer,16); // Converte um AECHAR* para char* WSTRTOSTR(buffer,buf,16); // Armazena o IP no atribudo aHost STRCPY(pMe->aHost,buf); //Grava no arquivo IFILE_Write(file,buf,sizeof(char)*strlen(buf)); STRCPY(buf,"|"); IFILE_Write(file,buf,sizeof(char)*strlen(buf)); // Recupera o ItexCtl referente a porta texto = (IStatic*)IDIALOG_GetControl(dialogo,
DIALOGO_CONFIGURAR_PORTA); // Carrega buffer com o valor da porta informado ITEXTCTL_GetText((ITextCtl*)texto,buffer,16); // Converte AECHAR* para char* WSTRTOSTR(buffer,buf,16); //Grava no arquivo IFILE_Write(file,buf,sizeof(char)*strlen(buf)); // Armazena a porta convertendo char* para int pMe->aPorta = ATOI(buf); //Libera memória FREEIF(buf); IFILE_Release(file); IFILEMGR_Release(fileMgr); }
// Excreve na tela uma string pTexto void univali_Print(univali * pMe, char * pTexto, AEEFont * pFonte, RGBVAL * pCor, uint32 pAlinhamento){ // Variável auxiliar AECHAR * buffer; if (!pTexto){ //Se o pTexto é null escreve espaços para "limpar a tela" pTexto = " "; } // Aloca memória para buffer buffer = MALLOC(sizeof(AECHAR) * strlen(pTexto)+1); // Converte char * para AECHAR * STRTOWSTR(pTexto,buffer,1+strlen(pTexto) * sizeof(AECHAR)); // Configura a cor do texto a ser escrito IDISPLAY_SetColor(pMe->aDisplay,CLR_USER_TEXT,pCor); IDISPLAY_DrawText(pMe->aDisplay, // Qual Display pFonte,// Tipo de fonte buffer, // Texto a ser escrito -1,//Bytes a serem escritos.-1 = todos de pTexto
NULL, // Coordenada X da tela onde deve ser escrito NULL, // Coordenada Y da tela onde deve ser escrito NULL, // Área que será utilizada para escrita (RECT) pAlinhamento);// Formata o alinhamento.
//Se setado, ignora Coordenadas X e Y; // Atualiza tela. IDISPLAY_Update(pMe->aDisplay); // Libera memória FREEIF(buffer); }
108
// Carrega as configuraçõe do arquivo univali.cfg void univali_CarregaConfiguracao(univali * pMe){ // Gerenciador de arquivos IFileMgr * fileMgr; // Ponteiro para o arquivo IFile * file; // Buffer temporário char * buffer = MALLOC(sizeof(char)*22); char * ponteiro; char * porta = MALLOC(sizeof(char) *6); // Em caso de erro será setada pra TRUE boolean erro = FALSE; // Inicializa o buffer com byte '0' (NULL) MEMSET(buffer,'\0',22); // Instancia o "gerenciador de arquivos" ISHELL_CreateInstance(pMe->aShell,AEECLSID_FILEMGR,(void**)&fileMgr); // Se instanciou o gerenciador com sucesso if (fileMgr){ // Abre o arquivo de configuração file = IFILEMGR_OpenFile(fileMgr,ARQ_CONFIG,_OFM_READ); // Se abriu com sucesso if (file){ // Carrega no buffer os dados da primeira linha IFILE_Read(file,buffer,22); // Procura pelo '|' que separa o IP da Porta,
// e aponta para a posição deste caracter ponteiro = STRCHR(buffer,'|'); // Aponta para a próxima posição referente a Porta *ponteiro++; // Faz a cópia da porta que está no ponteiro para "porta" STRCPY(porta,ponteiro); // Retorna a apontar para a ponsição de '|' *ponteiro--; // Zera a posição de buffer que contem '|'
// (trunca string), // fazendo com que em buffer permaneça somente o IP *ponteiro = 0; // Se não houver memória alocada para aHost aloca. if (!pMe->aHost) pMe->aHost = MALLOC(sizeof(char)*16); // Faz uma cópia do conteúdo de buffer para aHost STRCPY(pMe->aHost,buffer); // faz uma cópia da porta para aPorta pMe->aPorta = ATOI(porta); // Fecha o arquivo e liberando a memória alocada IFILE_Release(file); }else{ erro = TRUE; } // Fecha o gerenciador e liberando a memória alocada. IFILEMGR_Release(fileMgr); }else{ erro = TRUE; } // Libera memória FREEIF(buffer); FREEIF(porta); return; } // Exibe a tela para configurar IP e Porta void univali_ConfiguraIP(univali * pMe){
109
// Apontará para o IDialog ativo IDialog * dialogo; // Apontará para os ITextCtl de IP e Porta IStatic * texto; // Buffer de Wide String da plataforma AECHAR * buffer = MALLOC(sizeof(AECHAR)*16); // Buffer de string em C, utilizado para compatibilização dos dados char buffer2[6]; // Variável temporária. int res = 0; // Cria o Dialogo definido através do
// BREW Resource Editor(univali.bar) res = ISHELL_CreateDialog(pMe->aShell, UNIVALI_RES_FILE,
DIALOGO_CONFIGURAR, NULL); // Retorna o ponteiro do Dialog criado (e ativo) dialogo = ISHELL_GetActiveDialog(pMe->aShell); // Verifica o host está setado em aHost if (pMe->aHost && res == SUCCESS){ // Converte String em Wide String STRTOWSTR(pMe->aHost,buffer,32); // Recupera o ponteiro de ITextCtl que possui o IP texto = (IStatic*)IDIALOG_GetControl(dialogo,
DIALOGO_CONFIGURAR_IP); // Escreve no ITextCtl do IP o endereço IP que está em aHost ITEXTCTL_SetText((ITextCtl *)texto,buffer,32); } // Recupera o ponteiro de ITextCtl que possui a configuração da Porta texto = (IStatic*)IDIALOG_GetControl(dialogo,
DIALOGO_CONFIGURAR_PORTA); // Verifica sa porta está setada em aPorta if (pMe->aPorta > 0){ // Converte o int em aPorta para char* SPRINTF(buffer2,"%d",pMe->aPorta); // Converte String em Wide String STRTOWSTR(buffer2, buffer, 16); // Escreve no ITextCtl da Porta o valor de aPorta ITEXTCTL_SetText((ITextCtl *)texto,buffer,16); } // Configura o ITextCtl da porta para aceitar somente números ITEXTCTL_SetInputMode((ITextCtl *)texto,AEE_TM_NUMBERS); }
// Função para limpar completamente a tela, liberando alguns recursos da // memória void univali_LimpaTela(univali * pMe){ // Se o aMenuCtl estiver instanciado, libera if (pMe->aMenuCtl){ IMENUCTL_Release(pMe->aMenuCtl); pMe->aMenuCtl = NULL; } // Limpa a tela IDISPLAY_ClearScreen(pMe->aDisplay); // Realiza update no Display IDISPLAY_Update(pMe->aDisplay); }
// Exibe o menu principal void menu_Principal(univali * pMe){ //Variável para definir a área utilizada pelo menu AEERect rect; // Texto desconectar para alterar o menu caso a conexão
110
// seja bem sucedida AECHAR desconectar[12]={'D','e','s','c','o','n','e','c','t','a','r', '\0'}; //Define a área rect.x = 0; rect.y = 0; rect.dx = pMe->aDeviceInfo.cxScreen; // Deixa um espaço na parte inferior para servir como // barra de mensagens rect.dy = pMe->aDeviceInfo.cyScreen-15; // Instancia ao controle de Menu ISHELL_CreateInstance(pMe->aShell, AEECLSID_MENUCTL, (void **)&pMe->aMenuCtl); // Seta o título IMENUCTL_SetTitle(pMe->aMenuCtl, UNIVALI_RES_FILE, MENU_PRINCIPAL_TITULO, NULL); // Seta área da tela a ser ocupada com base no rect IMENUCTL_SetRect(pMe->aMenuCtl,&rect); // Configura o tipo de menu que deverá ser apresentado IMENUCTL_SetProperties(pMe->aMenuCtl,MP_ICON_TEXT_TOP); //Adiciona os itens do menu baseado nos recursos string criados com o //BREW Resource Editor IMENUCTL_AddItem(pMe->aMenuCtl, UNIVALI_RES_FILE, MENU_PRINCIPAL_CONECTAR,MENU_PRINCIPAL_CONECTAR, NULL, 0); IMENUCTL_AddItem(pMe->aMenuCtl, UNIVALI_RES_FILE, MENU_PRINCIPAL_PONTOS,MENU_PRINCIPAL_PONTOS, NULL, 0); IMENUCTL_AddItem(pMe->aMenuCtl, UNIVALI_RES_FILE, MENU_PRINCIPAL_CONFIGURAR,MENU_PRINCIPAL_CONFIGURAR, NULL, 0); IMENUCTL_AddItem(pMe->aMenuCtl, UNIVALI_RES_FILE, MENU_PRINCIPAL_SAIR,MENU_PRINCIPAL_SAIR, NULL, 0); //Está conectado? Então deve mudar a opção Conectar para Desconectar if (pMe->aStatusSocket < DESCONECTADO){ IMENUCTL_SetItemText(pMe->aMenuCtl,MENU_PRINCIPAL_CONECTAR, NULL,NULL,desconectar); } // Ativa o Menu IMENUCTL_SetActive(pMe->aMenuCtl,TRUE); }
// Monta em tempo de execução o menu que exibirá os pontos de controle // que foram informados e são controlados pelo servidor void menu_Pontos(univali * pMe, char * pPontos){ // Faz uma cópia do conteúdo do bufferIn char * copia = STRDUP(pMe->bufferIn); // Cria um ponteiro auxiliar char * ponteiro; // Cria a variável que irá armazenar o estado do ponto de controle char * status; // id irá conter a identificação do item que será incluído no menu // devido a necessidade de cada ítem possuir uma identificação única. // Esta mesma identificação é utilizada no tratamento dos eventos // de seleção dos itens desde menu int id = 3001; // Variável para definir a área de ocupação do menu AEERect rect; // Strutc que representa um ítem de menu CtlAddItem ctl;
111
//Declara e aloca memória para a variável que irá armazenar o nome do // ponto de controle AECHAR * ponto = MALLOC(sizeof(AECHAR)*20); // Configura o ctl para que se possa informar "manualamente" qual o // texto, a imagem e o ID de cada item de menu. ctl.pszResImage = NULL; ctl.dwData = NULL; ctl.pszResText = NULL; ctl.wFont = NULL; ctl.wText = NULL; ctl.wImage = NULL; // Define área do menu rect.x = 0; rect.y = 0; rect.dx = pMe->aDeviceInfo.cxScreen; rect.dy = pMe->aDeviceInfo.cyScreen-15; // Limpa a tela univali_LimpaTela(pMe); // Instancia ao controle de Menu ISHELL_CreateInstance(pMe->aShell, AEECLSID_MENUCTL, (void **)&pMe->aMenuCtl); // Seta o título IMENUCTL_SetTitle(pMe->aMenuCtl, UNIVALI_RES_FILE, MENU_PRINCIPAL_PONTOS, NULL); // Seta a área de ocupação IMENUCTL_SetRect(pMe->aMenuCtl,&rect); // Configura o tipo de menu IMENUCTL_SetProperties(pMe->aMenuCtl,MP_ICON_TEXT_TOP); // Para cada ponto de controle em bufferIn, insere no menu.
// Um ponto está identificado por: //<nome:char(20)>|<estado:char(1)>'\t'
// Todos os pontos seguem o padrão acima, estão em sequência // e o último possui o caracter '\0' após o '\t'
do{ // Aponta para o caracter | ponteiro = STRCHR(copia,'|'); if (ponteiro){ // Altera a posição de ponteiro para '0' *ponteiro = 0; // Faz a conversão para AECHAR e armazena
// em ponto a descrição do ponto STRTOWSTR(copia,ponto,sizeof(AECHAR) * strlen(copia)+1); // Seta pText no item a ser incluído no menu ctl.pText = ponto; // Seta o seu identificador ctl.wItemID = id++; // Avança o ponteiro ponteiro++; // Faz uma cópia da posição do ponteiro em
// diante para "copia" copia = STRDUP(ponteiro); // Aponta para '\t' ponteiro = STRCHR(copia,'\t'); if (ponteiro){ // Zera a posição *ponteiro = 0; // Copia o estado do ponto para status
status = STRDUP(copia); // Avança o ponteiro ponteiro++;
112
// Copia de ponteiro em diante para copia
copia = STRDUP(ponteiro); }else{ // É o último ponto, copia para status o estado //que está em copia status = STRDUP(copia); } //Se o estado é ativo "A", if (STRCMP(status,"A")==0){ // Seta a imagem de uma lâmpada acesa ctl.pImage = ISHELL_LoadResImage(pMe->aShell,
UNIVALI_RES_FILE, IMG_LIGADO); // Seta dwData para 1 indicando que está ligado ctl.dwData = 1; }else{ // Seta a imagem para uma lâmpada apagada ctl.pImage = ISHELL_LoadResImage(pMe->aShell,
UNIVALI_RES_FILE, IMG_DESLIGADO);
// Seta dwData para o indicando que está desligado ctl.dwData = 0; } // Adiciona o item no menu IMENUCTL_AddItemEx(pMe->aMenuCtl,&ctl); // Libera a imagem da memória (temporária) IIMAGE_Release(ctl.pImage); ctl.pImage = NULL; } } while (ponteiro); // Os passos a seguir incluem a opção sair neste menu STRTOWSTR("Sair",ponto,sizeof(AECHAR) * 5); ctl.pText = ponto; // Opção Sair terá ID = 3000 ctl.wItemID = 3000; // Ordena itens de menu antes de incluir "Sair" IMENUCTL_Sort(pMe->aMenuCtl,MCS_NAME_ASCENDING); // Adiciona Sair IMENUCTL_AddItemEx(pMe->aMenuCtl,&ctl); // Ativa menu IMENUCTL_SetActive(pMe->aMenuCtl,TRUE); // Seta aAcao para nenhuma pMe->aAcao = LISTA_PONTO; // Libera memória FREEIF(copia); FREEIF(ponteiro); FREEIF(status); FREEIF(ponto); }
// FUNÇÕES PARA TRATAR A CONEXÂO
// Realiza a conexão ao servidor boolean conexao_Conectar(univali * pMe, boolean pStatus) {
int resultado; // Trata solicitação de pStatus = TRUE (Conectar) if (pStatus){
// Faz a conversão do endereço IP para um INAddr INAddr addr = conexao_ConvertToINAddr(pMe->aHost);
113
// Seta a conexao para "pronto" pMe->aStatusSocket = CONECTANDO; // Cria um socketo do tipo stream pMe->aSocket = INETMGR_OpenSocket(pMe->aNetMgr,
AEE_SOCK_STREAM); if (pMe->aSocket){ // Faz a conexão
resultado = ISOCKET_Connect(pMe->aSocket,addr, AEE_htons(pMe->aPorta),
conexao_ConnectCallBack, (void*)pMe);
return TRUE; }else{ // Falha na conexão
return FALSE; } // Instanciou o socket mas deu erro if (resultado && (resultado != AEE_NET_WOULDBLOCK)) { return (FALSE); } // Conectou! else if (resultado != AEE_NET_WOULDBLOCK) {
pMe->aStatusSocket = CONECTADO; univali_Print(pMe,NULL,AEE_FONT_NORMAL,0,
(IDF_ALIGN_CENTER|IDF_ALIGN_BOTTOM)); }
}else{ // Trata solicitação de pStatus = FALSE (desconectar)
if (pMe->aSocket) { // Libera socket
ISOCKET_Release(pMe->aSocket); pMe->aSocket = NULL; pMe->aStatusSocket = DESCONECTADO; return TRUE;
} } return (FALSE);
}
// Função utilizada para converter um IP de string para o padrão INAddr INAddr conexao_ConvertToINAddr(char *pIP) { INAddr ul = 0; int nByte = 0; char c; if(!pIP) return 0; while (isdigit(*pIP)) { int n = 0; while (isdigit(c=*pIP)) { n = n*10 + (c - '0'); ++pIP; } ((char*)&ul)[nByte++] = n; if (nByte == 4 || *pIP != '.') break; ++pIP; }
114
if (nByte < 4 || isalnum(*pIP)) ul = 0xFFFFFFFF; // Endereço inválido return ul; }
// Trata o CallBack da conexão void conexao_ConnectCallBack(void * pUser, int nError){ // Faz o typecast do pUser para univali
univali * pMe = (univali *) pUser; // Ocorreu erro
if (nError){ // Limpa a tela
univali_LimpaTela(pMe); // Exibe menu principal menu_Principal(pMe); // Exibe mensagem de erro
univali_Print(pMe,"Falha na conexão!",AEE_FONT_NORMAL, MAKE_RGB(0xFF,0x00,0x00), (IDF_ALIGN_CENTER | IDF_ALIGN_BOTTOM)); // Marca como falha na conexão pMe->aStatusSocket = ERRO; return; }else{ // Conexão OK if (pMe->aStatusSocket == CONECTANDO){
// Exibe menu principal menu_Principal(pMe); } // Atualiza status do socket pMe->aStatusSocket = PRONTO; // Limpa área de mensagens univali_Print(pMe,NULL,AEE_FONT_NORMAL,0, (IDF_ALIGN_CENTER|IDF_ALIGN_BOTTOM)); } }
// Envia dados pela conexão boolean conexao_Escreve(univali * pMe, char * pDados){
// Variáveis temporárias int resultado; // Muda para o status de escrita pMe->aStatusSocket = ESCREVER; if (!pMe->aSocket) return TRUE; //Tenta escrever sem usar a função de callback ISOCKET_Writeable(pMe->aSocket, NULL, NULL); // Escreve no socket resultado = ISOCKET_Write(pMe->aSocket, pMe->bufferOut, strlen(pMe->bufferOut)); // Erro na escrita if (resultado == AEE_NET_ERROR){ return FALSE; } if (resultado == AEE_NET_WOULDBLOCK){ //Necessita tratar o envio com o CallBack // Associa a função conexao_WriteCallBack para tratar ISOCKET_Writeable(pMe->aSocket, conexao_WriteCallBack,(void*)pMe);
}else{ // Evio com sucesso, volta ao estado de pronto
pMe->aStatusSocket = PRONTO; return TRUE;
115
} return FALSE; }
// Função para tratar o Callback da escrita void conexao_WriteCallBack(void *pUser){ // Faz o typecast univali * pMe = (univali*)pUser; //Sendo chamada a função WriteCallBack siginifica que, // o socket está pronto para enviar. Chama novamente conexao_Escreve conexao_Escreve(pMe, pMe->bufferOut); return; }
// Le dados do socket boolean conexao_Le(univali * pMe, char * pBuffer) { int nRet; // Seta estado para leitura pMe->aStatusSocket = LER; //Cancela callback ISOCKET_Readable(pMe->aSocket, NULL, NULL); // Lê dados enviados pelo servidor nRet = ISOCKET_Read(pMe->aSocket, pMe->bufferIn, sizeof(char)*1000); if (nRet == AEE_NET_ERROR) { // Envio falhou return FALSE; } if (nRet == AEE_NET_WOULDBLOCK) { //É necessário tratar Callback. Faz associação a conexao_ReadCallBack ISOCKET_Readable(pMe->aSocket, conexao_ReadCallBack, (void*)pMe); } else { // Evnio com sucesso pMe->aStatusSocket = PRONTO;
return TRUE; } return FALSE; } // Trata o callback de leitura void conexao_ReadCallBack(void *pUser){ // Faz o typecast univali * pMe = (univali*)pUser; //Sendo chamada a função ReadCallBack siginifica que, // o socket está pronto para ler. Chama novamente conexao_Le if (conexao_Le(pMe, pMe->bufferIn)){ // leu com sucesso, encaminha dados para serem tratados // Pela aplicação
univali_TrataDado(pMe); } }
116
ANEXO 2: MODELAGEM DO SERVIDOR
117
Casos de uso
ud Use Case Model
Cliente (Celular)
Listar pontos
Alterar estado do ponto
Incluir / Alterar pontos
Alterar porta
Usuário
118
Nome do caso de uso Listar pontos
Caso de uso geral (include) Nenhum
Ator principal Cliente (Celular)
Ator secundário Nenhum
Resumo Envia para o cliente os pontos controlados pelo servidor e
seus respectivos estados
Pré-condição O sistema Cliente deve estar conectado ao Servidor
Pós-condição A lista de pontos com seus estados serão enviados ao cliente.
Fluxo base
Ações do Ator Ações do Sistema
1. Envia a mensagem solicitando os pontos
de controle
2. Interpreta pedido
3. Monta a mensagem de resposta com os
pontos de controle e seus respectivos estados.
4. Envia mensagem ao cliente
Fluxo alternativo
No passo 3 o servidor envia NULL caso não
exista nenhum ponto sendo controlado
119
Nome do caso de uso Alterar estado do ponto
Caso de uso geral (include) Nenhum
Ator principal Cliente (Celular)
Ator secundário Nenhum
Resumo Altera o estado de um ponto de controle conforme a
solicitação do cliente
Pré-condição O sistema Cliente deve estar conectado ao Servidor e
visualizando a lista de pontos de controle e seus respectivos
estados.
Pós-condição O ponto alterado deve estar no estado atual conforme
solicitação do cliente.
Fluxo base
Ações do Ator Ações do Sistema
1. Envia o ponto e seu novo estado desejado
2. Recebe mensagem
3. Localiza ponto
4. Altera o estado do ponto para o solicitado
5. Envia mensagem de sucesso ao cliente
Fluxo alternativo
Caso ocorra algum erro no passo 3 e 4 ,
suspender a execução da tarefa enviando uma
mensagem de falha ao cliente
120
Nome do caso de uso Incluir / Alterar pontos de controle
Caso de uso geral (include) Nenhum
Ator principal Usuário
Ator secundário Nenhum
Resumo Realizar o cadastro de novos pontos ou alterar um já
cadastrado direto no servidor
Pré-condição A lista de pontos de controle já se encontra no modo de
edição
Pós-condição O ponto está cadastrado ou atualizado
Fluxo base
Ações do Ator Ações do Sistema
1. Insere a descrição do ponto de controle
2. Insere o estado inicial do ponto de controle
3. Solicita salvar os dados
4. Armazena os dados no arquivo de
configuração
Fluxo alternativo
1. Navega na lista de pontos disponível
2. Seleciona e altera os dados do ponto que
deseja editar
3. Solicita salvar os dados
4. Armazena os dados no arquivo de
configuração
121
Nome do caso de uso Alterar porta
Caso de uso geral (include) Nenhum
Ator principal Usuário
Ator secundário Nenhum
Resumo Alterar o porta pela qual o servidor socket responderá
Pré-condição Tela de edição da porta deve estar visível
Pós-condição Servidor estar provendo o serviço na nova porta especificada
Fluxo base
Ações do Ator Ações do Sistema
1. Para o serviço socket
2. Informa a nova porta
3. Inicia serviço na nova porta
Fluxo alternativo
No passo 3, caso os dados informados são
inválidos (1024 > porta > 65535; porta não é
um inteiro válido) o servidor apresenta
mensagem de "Dados inválidos".
Retoma a prover o serviço na última porta
válida configurada.
122
Diagramas classes de domínio
cd Data Model
Serv idor
+ lePontos() : void+ salvaPontos() : void
Serv erSocket
# Port: Integer
+ Open() : void+ Close() : void+ Read() : void+ Write() : void
Pontos
- aDescricao: String- aStatus: Char0..*
Lista pontos
1
Socket
Diagramas de seqüência
Altera porta
sd Altera porta
Usuário
(from Casos de uso)
Tela servidor :Servidor
(from Lista pontos)
Se a porta for inválida, exibirmensagem de erro e reativaro serviço na última porta válida
Informa nova porta
Alterar porta
[nova porta é válida]:Altera porta
Ativa servidor
123
Altera estado do ponto
sd Alterar estado do ponto
Cliente (Celular)
(from Casos de uso)
socket :ServerSocket
(from Lista pontos)
servidor :Servidor
(from Lista pontos)
Ponto :Pontos
(from Lista pontos)
Mensagem com oponto e o novoestado
Repassa mensagem
Interpreta mensagem
*Solicita nome
*Verifica se é o ponto desejado
[É o ponto desejado]:Altera estado para o novo
[OK]: Confirmar aalteração
[Erro]: Erro ao tentaralterar
124
Configura pontos
sd Configura pontos
Usuário
(from Casos de uso)
Tela
(from Altera porta)
servidor :Servidor
(from Lista pontos)
Ponto :Pontos
(from Lista pontos)
Informa descriçãoe estado inicial
ConfirmaRepassa dados
Cria ponto com osdados informados
Adiciona na lista
125
Lista pontos
sd Lista pontos
Cliente (Celular)
(from Casos de uso)
socket :ServerSocket
servidor :Servidor
Ponto :Pontos
Solicita a lista de pontos
Encaminha mensagem
Interpetra mensagem
[Lista não é vazia]: *Solicitadescrição e estado do ponto
*Retorna dados[Lista vazia]: Não hápontos cadastrados
*Montamensagem deretorno
Envio da mensagem
Solicita envio damensagem
Envio da mensagem
126
ANEXO 3: FONTE DO SERVIDOR (UNSERVIDOR.PAS)
127
unit unServidor;
interface
uses Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs, StdCtrls, ScktComp, Grids, ComCtrls, Menus;
type TFrmPrincipal = class(TForm) // Servidor Socket ServerSocket: TServerSocket; // Ítens de menu incluídos pelo Delphi MainMenu1: TMainMenu; Arquivo1: TMenuItem; Sair1: TMenuItem; Salvar1: TMenuItem; Porta1: TMenuItem; IncluirPonto1: TMenuItem; Configurar1: TMenuItem; // Barra de status do servidor BarraStatus: TStatusBar; // Incluídos para auxiliar no debug do cliente GBLog: TGroupBox; MemoLog: TMemo; // Componentes para exibir os pontos de controle na tela GBPontosControle: TGroupBox; SGPontos: TStringGrid; // Eventos do ServerSocket // Evento: ClientWrite procedure ServerSocketClientWrite(Sender: TObject; Socket: TCustomWinSocket); // Evento: ClientConnect procedure ServerSocketClientConnect(Sender: TObject; Socket: TCustomWinSocket); // Evento: ClientDisconnect procedure ServerSocketClientDisconnect(Sender: TObject; Socket: TCustomWinSocket); // Evento: ClientRead procedure ServerSocketClientRead(Sender: TObject; Socket: TCustomWinSocket); // Evento chamado ao criar o form da aplicação procedure FormCreate(Sender: TObject); // Evento chamado ao selecionar a opção Savar procedure Salvar1Click(Sender: TObject); // Evento chamado ao selecionar a opção IncluirPonto procedure IncluirPonto1Click(Sender: TObject); // Evento chamado ao selecionar a opção Sair procedure Sair1Click(Sender: TObject); // Evento chamado ao selecionar a opção Configurar porta procedure Porta1Click(Sender: TObject);
private // Salvar os pontos de controle e seus estados atuais em arquivo procedure SalvaPontos(); // Carrega os pontos de controle e seus estadus do arquivo procedure LePontos();
public { Public declarations } end;
128
// record responsável por representar um Ponto de Controle Type TPonto = Record // Descrição do ponto a ser controlado aDescricao: String[20]; // Estado do ponto aStatus : String[1]; end; var FrmPrincipal: TFrmPrincipal;
implementation
{$R *.DFM}
procedure TFrmPrincipal.ServerSocketClientWrite(Sender: TObject; Socket: TCustomWinSocket); // Função utilizada para auxilio de debug do cliente begin MemoLog.Lines.Add('ClienteWrite: '+Socket.ReceiveText); end;
procedure TFrmPrincipal.ServerSocketClientConnect(Sender: TObject; Socket: TCustomWinSocket); // Função utilizada para auxilio de debug do cliente begin MemoLog.lines.add('Conectado'); end;
procedure TFrmPrincipal.ServerSocketClientDisconnect(Sender: TObject; Socket: TCustomWinSocket); // Função utilizada para auxilio de debug do cliente begin MemoLog.Lines.Add('Desconectado'); end;
procedure TFrmPrincipal.ServerSocketClientRead(Sender: TObject; Socket: TCustomWinSocket); // Trata as mensagens enviadas pelo Cliente (Celular) var Dados: String; Linha: String; I: Integer; begin // Armazena os dados recebidos em Dados Dados := Socket.ReceiveText; // Inicializa linha (auxiliar) com '' Linha := ''; // Comandos adicionados para auxiliar no debug do cliente (celular) for I := 1 to length(dados) do linha := linha + ' '+ IntToStr(ord(dados[i])+127); MemoLog.Lines.Add('ClienteRead:('+IntToStr(Length(dados))+' bytes)' +Dados); MemoLog.Lines.Add('ClienteRead:(linha)'+Linha); // Fim do debug // Cliente solicitou a lista de pontos if (Dados = 'PONTOS') then begin Linha := ''; // Cria uma string com todos os pontos for I := 1 to SGPontos.RowCount -1 do Linha := Linha + SGPontos.Cells[0,I]+'|'+
129
SGPontos.Cells[1,I]+chr(9); // Envia a lista para o Cliente Socket.SendText(Linha); end else begin // Cliente solicitoua alteração do estado de um ponto // Indentifica o ponto Linha := copy(Dados,1,Pos('|',Dados)-1); // Retira o nome da string recebida delete(Dados,1,Pos('|',Dados)); // Retira o ultimo caracter da String dados delete(Dados,Length(Dados),1); // Faz uma busca simples pelo ponto na lista de // pontos controlados for I := 1 to SGPontos.RowCount -1 do begin // Se achou o ponto, altera seu estado para o que está // em Dados if SGPontos.Cells[0,I] = Linha then begin //Altera estado do ponto SGPontos.Cells[1,I] := Dados; // Envia confirmação Socket.SendText('OK'); end; end; end; // Salva os pontos no arquivo self.SalvaPontos(); end;
procedure TFrmPrincipal.FormCreate(Sender: TObject); // Inicializa a aplicação servidor begin //Configura o nome das colunas da lista de pontos SGPontos.Cells[0,0] := 'Ponto de automação'; SGPontos.Cells[1,0] := 'Status'; SGPontos.RowCount := 2; SGPontos.RowCount := 2; // Seta a porta do ServerSocket para 5000 ServerSocket.Port := 5000; // Carrega os pontos que estão armazenados no arquivo de pontos // na tela do servidor self.LePontos(); // Atualiza o StatusBar com o número da porta atual que o servidor // está respondendo BarraStatus.Panels[0].Text := 'Porta: '+ IntToStr(ServerSocket.Port); // Inicial serviço de Socket ServerSocket.Open; end;
procedure TFrmPrincipal.SalvaPontos; // Função que armzena os pontos da lista me arquivo var Arq : File of TPonto; I: Integer; Buff: TPonto; begin // Abre o arquivo para escrita AssignFile(Arq,'pontos.dat');
130
ReWrite(Arq); for I := 1 to SGPontos.RowCount -1 do begin // Para cada ponto na tela carrega Buff do tipo TPonto com os // dados Buff.aDescricao := SGPontos.Cells[0,I]; Buff.aStatus := SGPontos.Cells[1,I]; // Escreve ponto no arquivo Write(Arq,buff); end; CloseFile(Arq); end;
procedure TFrmPrincipal.Salvar1Click(Sender: TObject); begin // Salva os pontos e seus estados em arquivo self.SalvaPontos(); end;
procedure TFrmPrincipal.LePontos; // Carrega os pontos que estão em arquivo var Arq : File of TPonto; Buff: TPonto; begin // Abre o arquivo AssignFile(Arq,'pontos.dat'); Reset(Arq); While not EOF(Arq) do begin // Lê o ponto para buff do tipo TPonto Read(Arq,buff); // Carrega os dados na tela SGPontos.Cells[0,SGPontos.RowCount - 1] := Buff.aDescricao; SGPontos.Cells[1,SGPontos.RowCount -1] := Buff.aStatus; // Se não for o fim do arquivo, inclui uma nova linha na tela // para receber o próximo ponto if not EOF(Arq) then SGPontos.RowCount := SGPontos.RowCount + 1; end; // Fecha o arquivo CloseFile(Arq); end; procedure TFrmPrincipal.IncluirPonto1Click(Sender: TObject); // Inclui um ponto de controle na lista begin if (SGPontos.Cells[0,SGPontos.RowCount-1] <> '') then begin // Adiciona uma nova linha SGPontos.RowCount := SGPontos.RowCount + 1; // Posiciona o cursor para o campo Descrição do ponto SGPontos.Col := 0; SGPontos.SetFocus; SGPontos.Row := SGPontos.RowCount -1; // Habilita para edição SGPontos.EditorMode := True; end; end;
procedure TFrmPrincipal.Sair1Click(Sender: TObject); begin
131
// Salva os pontos e seus estados self.SalvaPontos(); // Finaliza serviço de socket ServerSocket.Close; // Finaliza aplicação servidora Application.terminate; end;
procedure TFrmPrincipal.Porta1Click(Sender: TObject); begin // Finaliza o Serviço de ServerSocket ServerSocket.Close; try //Solicita ao usuário a nova porta ServerSocket.Port := StrToInt(InputBox('Porta', 'Digite o número da porta entre '+ '1024 e 65565 que este servidor irá'+ ' responder', IntToStr(ServerSocket.Port))); // Verifica se a porta informada está na faixa permitida if (ServerSocket.Port < 1024) and (ServerSocket.Port > 65535) then // Mensagem de porta inválida caso seja uma faixa indevida ShowMessage('Valor é inválido!') except // A porta informada é diferente de inteiro ShowMessage('Valor é inválido!'); BarraStatus.Panels[0].Text := IntToStr(ServerSocket.Port); end; // Inicia servico ServerSocket ServerSocket.Open; // Atualiza barra de status com a porta atual BarraStatus.Panels[0].Text := 'Porta: '+IntToStr(ServerSocket.Port); end; end.
132
133
REFERÊNCIAS BIBLIOGRÁFICAS
ALMEIDA, Leandro B. Introdução à J2ME e programação MIDP. Mundo Java, Curitiba.
n. 5, 2004.
ALENCAR, M. S. Sistemas de Comunicações. São Paulo: Érica. 2001.
ANATEL. Plano geral de Metas para a Universalização (PGMU). Brasília, 2005a.
Disponível em:
<http://www.anatel.gov.br/Tools/frame.asp?link=/telefonia_fixa/stfc/indicadores_pgmu/2005/
brasil.pdf> . Acesso em: 01 maio 2005.
ANATEL. Crescimento das comunicações móveis (1994
2004). Brasília, 2005b.
Disponível em:
<http://sistemas.anatel.gov.br/smp/administracao/consulta/acompanhamento_estacoes/telaanu
al.asp> . Acesso em: 01 maio 2005.
ANATEL. Telefonia Móvel (SERVIÇO MÓVEL PESSOAL
SMP). Brasília, 2005c.
Disponível em:
<http://www.anatel.gov.br/Tools/frame.asp?link=/comunicacao_movel/smc/evolucaosmc_sm
p_operadoras.pdf> . Acesso em: 01 maio 2005.
ANATEL. PARTICIPAÇÃO DO MERCADO DE SERVIÇO MÓVEL PESSOAL
SMP). Brasília, 2005d. Disponível em:
<http://www.anatel.gov.br/Tools/frame.asp?link=/comunicacao_movel/smp/participacao_smp
_mercado.pdf> . Acesso em: 18 maio 2005.
BARBAGALLO, Ralph; Wireless Game Development in C/C++ BREW. Texas: Wordware
Publishing Inc. 2003.
134
BONA, Cristina. Avaliação de Processos de Software: Um estudo de caso em XP e
ICONIX. Florianópolis, 2002. Disponível em: <http://teses.eps.ufsc.br/defesa/pdf/10816.pdf>
Acesso em: 4 junho 2005.
DODD, Annabel. O guia essencial para telecomunicações. Tradutor: Edson Furmankiewicz
e Joana Figueiredo. Rio de Janeiro: Campus, 2000
DORNAN, Andy. Wireless communication: o guia essencial de comunicação sem fio.
Tradutor: Fábio Freitas. Rio de Janeiro: Campus, 2001.
GUEDES, Gilleanes T.A.; UML: Uma Abordagem Prática. São Paulo: Novatec Editora.
2004.
HADDAD, Renato. Aplicações Móveis no .NET. [2004a?]. Disponível em:
<http://www.microsoft.com/brasil/msdn/Tecnologias/movel/mobilidade_aplicacoes.aspx>
Acessado em: 4 junho 2005.
HADDAD, Renato. Entendendo Aplicações Móveis no .NET. [2004b?]. Disponível em: <
http://www.microsoft.com/brasil/msdn/Tecnologias/movel/mobilidade_aspnet.aspx>
Acessado em: 4 junho 2005.
JB Online. DoCoMo lança 400 Mb/s com 4G. 2004. Disponível em:
<http://jbonline.terra.com.br/jb/papel/cadernos/internet/2004/06/06/jorinf20040606012.html>
Acessado em: 05 junho 2005.
MUCHOW, John W. Core J2ME. Tecnologia & MIDP. São Paulo: Makron Books. 2002.
OLIVEIRA, Félix Tadeu Xavier de; FILHO, Huber Bernal. Rádio Spread Spectrum
(Espalhamento Espectral). 2003. Disponível em:
<http://www.teleco.com.br/tutoriais/tutorialss/default.asp>. Acessado em: 26 maio 2005.
QUALCOMM. Introducing de BREW 3.1.3 API Reference. 2005. Em HD e parte integrante
do BREW SDK.
QUALCOMM. Maiores Lucros na Movimentação de Dados Sem Fio. 2002. Disponível
em: <http://brew.qualcomm.com/brew/pt/img/about/pdf/brew_white_paper.pdf> Acessado
em: 06 março 2005.
135
QUALCOMM. Starting with BREW. 2004. Disponível em:
<http://brew.qualcomm.com/brew_bnry/pdf/developer/resources/gs/starting_brew.pdf>
Acessado em: 06 março 2005.
QUALCOMM. Relação de Operadoras. [2005?]. Disponível em:
<http://brew.qualcomm.com/brew/pt/operator/op_directory.html> Acessado em: 06 março
2005.
QUALCOMM. Seja um desenvolvedor BREW: Autenticação. [2002-2005]. Disponível em:
< http://brew.qualcomm.com/brew/pt/developer/resources/gs/get_auth.html> Acessado em:
06 março 2005.
QUALCOMM. Visão Geral do BREW Distribution System (sistema de distribuição do
BREW). 2003a. Disponível em: <http://brew.qualcomm.com/brew/pt/img/about/pdf/bds.pdf>
Acessado em: 10 março 2005.
QUALCOMM. BREW e J2ME: Uma solução de comunicação móvel completa para
operadoras comprometidas com Java. 2003b. Disponível em:
<http://brew.qualcomm.com/brew/pt/img/about/pdf/brew_j2me.pdf> Acessado em: 10 março
2005.
QUALCOMM. FQA do Desenvolvedor: Comerciais/de negócios. [2002-2005a]. Disponível
em: <http://brew.qualcomm.com/brew/pt/developer/resources/ds/business_faq.html#B1>
Acessado em: 18 agosto 2005.
QUALCOMM. Criando aplicativos BREW: Sistemas operacionais e processadores. [2002-
2005b]. Disponível em:
<http://brew.qualcomm.com/brew/pt/developer/resources/ds/faq/techfaq9.html#T1B>
Acessado em: 18 agosto 2005.
RISCHPATER, Ray. Software Development for the QUALCOMM BREW Platform. [S.I.]:
Apress. 2003.
SUN MICROSYSTEMS. J2ME Platform, Micro Edition. [2001?]. Disponível em:
<http://java.sun.com/j2me/docs/j2me-ds.pdf> Acessado em: 5 junho 2005.
136
SUPERWABA. Documentação: Por onde começar. [2005a?]. Disponível em:
<http://www.superwaba.com.br/pt/dochow.asp> Acessado em: 3 junho 2005.
SUPERWABA. Estudo de casos: COPEL
Companhia Paranaense de Energia. [2005b?].
Disponível em: <http://www.superwaba.com.br/pt/casoCOP.asp> Acessado em: 3 junho
2005.
SHARMA, Chetan. Aplicações Comerciais da Internet Sem Fio. Tradutor: Mário Moro
Fecchio. São Paulo: Makron Books, 2001.
TAURION, César. Internet móvel: tecnologia, aplicações e modelos. Rio de Janeiro:
Campus, 2002.
UNIVERSIDADE ESTADUAL DE LONDRINA. Telefonia Celular. Londrina, 1998.
Disponível em: <http://proenca.uel.br/curso-redes-graduacao/1998/trab-05/equipe-
01/celular.doc>. Acessado em: 17 abril 2004.
VIVIANE, Mizrahi Victorine. Treinamento em Linguagem C++ Módulo 1. São Paulo:
Makron Books. 1995a.
VIVIANE, Mizrahi Victorine. Treinamento em Linguagem C++ Módulo 2. São Paulo:
Makron Books. 1995b.
WALDMAN, Hélio; YACOUB, Michel Daoud. Telecomunicações: princípios e tendências.
São Paulo: Érica, 1999.
This document was created with Win2PDF available at http://www.daneprairie.com.The unregistered version of Win2PDF is for evaluation or non-commercial use only.
