Este documento apresenta um resumo do trabalho de conclusão de curso sobre o desenvolvimento de um aplicativo para realizar pedidos via Bluetooth (PVB). O aplicativo foi desenvolvido para lanchonetes e tem como objetivo reduzir o tempo de espera dos clientes e agilizar o processo de pedido. O PVB permite que os clientes façam seus pedidos diretamente pelo celular via Bluetooth, proporcionando mais comodidade e privacidade. O aplicativo foi desenvolvido para os sistemas operacionais Java ME usando as APIs Java para Bluetooth.

1. UNIP – UNIVERSIDADE PAULISTA
PROGRAMA DE GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO
PEDIDOS VIA BLUETOOTH
(P.V.B.)
BRUNO HENRIQUE DE PAULA FERREIRA
BRUNO SCHIONATO
JOÃO HEYTOR KREITLOW PEREIRA
MARCELO FERNANDES D’ALEXANDRE
CAMPINAS
NOVEMBRO DE 2010

2. BRUNO HENRIQUE DE PAULA FERREIRA
BRUNO SCHIONATO
JOÃO HEYTOR KREITLOW PEREIRA
MARCELO FERNANDES D’ALEXANDRE
PVB: PEDIDOS VIA
BLUETOOTH
Trabalho de Conclusão de Curso apresentado no programa de
Graduação da Universidade Paulista (UNIP), como requisito
parcial para obtenção do grau de Bacharel em Ciência da
Computação.
Orientador: Prof. Jarbas Lopes Cardoso Júnior
VERSÃO 2 - REVISADA
CAMPINAS
NOVEMBRO DE 2010

3. AGRADECIMENTOS DE BRUNO HENRIQUE
Durante quatro anos passei pelos mesmos caminhos, executei diversas
tarefas e enfrentei muitos obstáculos. É verdade também que nestes mesmos 4
anos eu tomei novos rumos, ampliei meus horizontes e alcancei diversos objetivos.
Com dificuldades e superação, crises e amparos, falta de tempo e
cooperação estou aqui, concluindo meu curso, mas não, este não é meu o curso, e
sim o curso que hoje dedico, agradeço e ofereço a Deus, meus pais, minha família,
professores e aos meus amigos companheiros, que do inicio ao fim estiveram ao
meu lado.
Muito Obrigado!

4. AGRADECIMENTOS DE BRUNO SCHIONATO
Agradeço primeiramente a Deus, que é o grande responsável por cada
vitória na minha vida e por cada passo que me faz ir além do planejado.
Agradeço por cada momento em que estive na Universidade, não
aprendendo apenas teoria, mas aprendendo muito mais da vida do que sobre teorias
computacionais.
Agradeço pela minha família, pois a família é a base e a estrutura de todo
ser humano; é nela que encontrei a minha força nos momentos de fraqueza, e
quando batia a vontade de desistir, foi nela que encontrei motivos para ir além.
Agradeço também aos professores, pois foram pacientes e sempre nos
apoiaram, cada um da sua forma, mas sempre apoiando.

5. AGRADECIMENTOS DE JOÃO HEYTOR KREITLOW PEREIRA
Agradeço e dedico esse trabalho ao meu pai, Wanderley Carlos Pereira,
que em vida sempre me ensinou a ter paciência nas horas difíceis, sabedoria nas
horas delicadas e que acima de tudo, me ensinou a nunca desistir, principalmente
na primeira dificuldade que encontrei.
Agradeço também a Deus, pela vida que tenho, pelos amigos que fiz
durante todo esse longo caminho de graduação e por ter permitido que eu estivesse
aqui, conseguindo completar mais um ciclo da minha vida.
Agradeço a minha noiva, Mislane Silva Sousa, por ter tido paciência
comigo, principalmente nas horas mais difíceis que tive nessa longa jornada.
Agradeço a minha família, em especial minha mãe, Mara Silvia Kreitlow
Pereira e a minha irmã, Caroline Fernanda Kreitlow Pereira, por todo apoio que
recebi nesse caminho até aqui.
Enfim, agradeço a todos que estiveram comigo, que me ajudaram
diretamente ou indiretamente a chegar onde estou, sem vocês, eu sei que não
conseguiria alcançar os meus objetivos. Muito obrigado!

6. AGRADECIMENTOS DE MARCELO FERNANDES D’ALEXANDRE
Agradeço primeiramente a Deus, pois sem Ele não estaria aqui...
Agradeço a atenção e compreensão dos meus pais que me deram apoio
desde o começo, sempre com incentivos e boas vibrações...
Agradeço aos meus amigos e colegas de turma, parceiros que conheci
durante esses 4 anos...
Agradeço a todos os nossos professores pelo conhecimento adquirido,
em especial ao nosso orientador Prof. Jarbas Lopes Cardoso Júnior...
Meus sinceros agradecimentos a Todos... Muito Obrigado...

7. You have to generate many ideas and then you
have to work very hard only to discover that they
don´t work. And you keep doing that over and over
until you find one that does work.
John Warner Backus, FORTRAN inventor

8. RESUMO
Pedidos via Bluetooth, ou simplesmente PVB, é a forma simples, moderna
e rápida para realizar pedidos através de um aparelho celular por meio do protocolo
bluetooth.
Este aplicativo foi inicialmente desenvolvido para lanchonetes, seu uso
reduz expressivamente o tempo de espera cliente / garçom e a efetiva execução do
pedido. O PVB torna o processo mais ágil e eficaz, o que reflete maior comodidade,
privacidade e assertividade ao cliente. Será possível entender também, os
benefícios proporcionados ao empresário através desta aplicação.
Aliado a diversas vantagens, temos o fato do expressivo numero de
celulares por habitante no país, o que faz do PVB uma aplicação ainda mais
promissora.
Palavras-Chave: Bluetooth. Java. Java ME. JSR 82. BlueCove.

9. ABSTRACT
Pedidos via Bluetooth, or simply PVB, is a simple, modern and quick way
to place orders via a mobile device through bluetooth protocol.
This application was initially developed for fast food stores, its use
significantly reduces the wait time customer / waiter and effective execution of the
request. The PVB makes the process more efficient and agile, which reflects greater
comfort, privacy and assertiveness to the customer. It´ll also be possible to
understand the benefits to the manager through this application.
Combined with several advantages, we have the fact of a significant
number of phones per capita in the country, which makes this application more
promissory.
Key-words: Bluetooth. Java. Java ME. JSR 82. BlueCove.

10. LISTA DE FIGURAS
Figura 1 - Equação chave do PVB ............................................................................ 17
Figura 2 – Principais fatores de decisão na escolha do tema ................................... 18
Figura 3 - Logo Bluetooth .......................................................................................... 20
Figura 4 - Distribuição de Frequências (Adaptador de Layton e Franklin; 2000 (5)) . 20
Figura 5 - Através do Java VM, a mesma aplicação é capaz de rodar em vários OS
(Adaptado do site oficial do Java (1997) (7)) ............................................................. 23
Figura 6 – Componentes disponíveis no Java SE (Adaptado do site oficial do Java
(2007) (8)) ................................................................................................................. 24
Figura 7 - Funcionamento do BlueCove (Adaptado do Site Oficial do BlueCove (11) )
.................................................................................................................................. 26
Figura 8 - Ciclo de Desenvolvimento Orientado a Teste de Aceitação (Adaptado de
Nadalete (2010)) ....................................................................................................... 30
Figura 9 - Motorola Z3 (Motorola Inc.), primeiro equipamento usado durante os
testes ......................................................................................................................... 33
Figura 10 - Nokia Express Music 5130 (Nokia Copyright), segundo equipamento
usado durante os testes ............................................................................................ 34
Figura 11 - Código-Fonte, Tornando dispositivo detectável ...................................... 36
Figura 12 - PVB Servidor, Visão Resumida .............................................................. 36
Figura 13 – Código-Fonte, Cliente Conecta .............................................................. 36
Figura 14 - Concatenação de números enviado ao servidor ..................................... 37
Figura 15 – Código-Fonte, extração dos valores concatenados ............................... 37
Figura 16 - Código-Fonte, imprimindo dados recebidos pelo servidor ...................... 38
Figura 17 – Código-Fonte, procurando servidor e estabelecendo conexão .............. 39
Figura 18 – Código-Fonte, concatenação dos dados digitados pelo usuário e enviado
ao servidor................................................................................................................. 39
Figura 19 - PVB Cliente, Visão Resumida ................................................................. 40

11. Figura 20 - Aguardando Conexão ............................................................................. 42
Figura 21 - Dispositivo Conecta e Servidor para, aguardando pedido ...................... 43
Figura 22 - Aplicação Servidor Recebe Pedido (1) ................................................... 44
Figura 23 - Aplicação Servidor Recebe Pedido (2) ................................................... 45
Figura 24 - Aplicação Servidor Fecha Conexão e mostra o valor total da conta ....... 46
Figura 25 - Tela Inicial Aplicação Cliente .................................................................. 47
Figura 26 - Dispositivo Móvel a procura da aplicação servidor ................................. 47
Figura 27 - Tela de Pedidos ...................................................................................... 48
Figura 28 - Servidor Encontrado ............................................................................... 48
Figura 29 - Tela de Pedidos Preenchida ................................................................... 49
Figura 30 – Preenchendo Tela de Pedidos ............................................................... 49
Figura 31 - Opção que Fecha a Conta ...................................................................... 50
Figura 32 - Opção que envia dados ao servidor........................................................ 50
Figura 33 - Equação do Contador relacionado à Prioridade de Pedidos ................... 55

12. LISTA DE TABELAS
Tabela 1 – Classes disponíveis do Bluetooth (Adaptado de Bluetooth SIG (1998) (4))
.................................................................................................................................. 21
Tabela 2 - Cardápio de Exemplo, Divisão de Bebidas .............................................. 41
Tabela 3 – Cardápio de Exemplo, Divisão de Lanches ............................................. 41

13. LISTA DE ABREVIATURAS E SIGLAS
API – Application Programming Interface
ATDD – Acceptance Test Driven Development
GHz – Gigahertz
IDE – Integrated Development Environment
ISM – Industrial, Scientific and Medical
J2ME – Java 2, Platform Micro Edition
J2SE – Java 2, Platform Standard Edition
Java ME – Java Micro Edition
Java SE – Java Standard Edition
JSR – Java Specification Request
JVM – Java Virtual Machine
L2CAP – Logical Link Control and Adaptation Protocol
OBEX – Object Exchange
OS – Operational System
PVB – Pedidos via Bluetooth
RFCOMM – RS232 Serial Cable Emulation Profile
SIG – Special Interest Group
TDD – Test Driven Development
VM – Virtual Machine

14. SUMÁRIO
1. INTRODUÇÃO.................................................................................................. 16
1.1. OBJETIVOS ............................................................................................. 17
1.2. JUSTIFICATIVA ....................................................................................... 17
1.3. ESCOPO .................................................................................................. 18
1.4. DA VIABILIDADE ..................................................................................... 18
2. FUNDAMENTAÇÃO TEÓRICA........................................................................ 19
2.1. BLUETOOTH............................................................................................ 19
2.1.1. História......................................................................................... 19
2.1.2. Origem do nome e Logo .............................................................. 19
2.1.3. Funcionamento do Bluetooth ....................................................... 20
2.1.4. Versões do Protocolo................................................................... 21
2.2. JAVA ........................................................................................................ 22
2.2.1. Java Platform, Standard Edition (Java SE) .................................. 23
2.2.2. Java Platform, Micro Edition (Java ME) ....................................... 24
2.2.3. Java APIS for Bluetooth (JSR-82) ............................................... 24
2.3. BLUECOVE .............................................................................................. 25
2.3.1. Descrição ..................................................................................... 25
2.3.2. Funcionamento ............................................................................ 25
2.3.3. Requerimentos Mínimos .............................................................. 26
2.3.4. Limitações.................................................................................... 27
2.3.5. Funções não implementadas ....................................................... 27
2.3.6. A importância do BlueCove no Projeto ........................................ 27
3. METODOLOGIA DE DESENVOLVIMENTO .................................................... 29
3.1. DESENVOLVIMENTO ORIENTADO A TESTES ..................................... 29
3.2. FERRAMENTAS DE DESENVOLVIMENTO ............................................ 31

15. 3.3. DIFICULDADES ENCONTRADAS ........................................................... 32
4. DESENVOLVIMENTO ...................................................................................... 33
4.1. EQUIPAMENTOS NECESSÁRIOS .......................................................... 33
4.2. A METODOLOGIA NA PRÁTICA ............................................................. 34
4.3. FUNCIONAMENTO .................................................................................. 35
4.3.1. Aplicação Servidor ....................................................................... 35
4.3.2. Aplicação Cliente ......................................................................... 38
4.3.3. Cardápio ...................................................................................... 41
4.3.4. Exemplo de funcionamento ......................................................... 42
4.4. LIMITAÇÕES ENCONTRADAS ............................................................... 51
5. CONCLUSÃO ................................................................................................... 52
5.1. CONSIDERAÇÕES FINAIS ..................................................................... 52
5.2. TRABALHOS FUTUROS ......................................................................... 53
5.2.1. Em relação à Segurança ............................................................. 53
5.2.2. Melhorias no Cliente .................................................................... 55
5.2.3. Melhorias no Servidor .................................................................. 55
6. REFERÊNCIAS BIBLIOGRÁFICAS ................................................................ 57
7. ANEXOS ........................................................................................................... 60
7.1. CÓDIGO-FONTE APLICAÇÃO SERVIDOR ............................................ 60
7.1.1. Conteúdo do Arquivo Conexao.java ............................................ 60
7.1.2. Conteúdo do Arquivo Main.java ................................................... 62
7.2. CÓDIGO-FONTE APLICAÇÃO CLIENTE ................................................ 62
7.2.1. Conteúdo do Arquivo EchoClient.java ......................................... 62

16. 1. INTRODUÇÃO
A tecnologia esta atrelada as nossas vidas assim como a falta de tempo.
Através desta afirmação podemos observar que existe uma continua preocupação
para que possamos tornar processos, métodos e quaisquer atividades mais
dinâmicas, cômodas e eficazes, pois com isso podemos garantir beneficio a tudo e a
todas as pessoas. A partir desta premissa baseamos nossa proposta de Pedidos Via
Bluetooth, pois apesar de uma ideia inicialmente básica ela traria beneficio as partes
envolvidas. Nossa proposta traz uma forma de contribuir com todos os fatores
anteriormente mencionados, visando ainda um maior bem estar e qualidade de vida
das pessoas.
O “Pedidos Via Bluetooth” ou simplesmente PVB, é uma forma simples de
realizar um pedido, via celular, desde que este tenha o serviço de Bluetooth, o que
traz melhorias significativas tanto para o usuário deste serviço, como pelo
contratante.
Este sistema se torna possível, pois o custo de implantação e
equipamentos tende a ser rapidamente recuperado, devido ao baixo investimento
necessário para sua implementação, trazendo consigo todo o aspecto de inovação,
melhor aplicação de mão de obra e o mais importante, satisfação do cliente, pois
este será atendido de forma mais rápida, dinâmica e assertiva. Outro fator que torna
viável este serviço é o próprio crescimento do numero de celulares, que de acordo
com a última pesquisa divulgada pela Agência Nacional de Telecomunicações
(Anatel) (1) chega ao incrível numero de 191 milhões, em outubro deste ano, o que
significa quase um aparelho de celular por habitante. Recentemente, conforme diz
Ciarelli (2010) (2), a Anatel também divulgou que estima 300 milhões de celulares no
Brasil em 2013.
Portanto apesar de uma ideia simples e objetiva, trazemos uma
inovação no setor que pode posteriormente ser aproveitada nas mais diversas
atividades, sempre com o intuito de trazer beneficio a todas as partes envolvidas
neste tipo de projeto.
Página 16 de 68

17. Vale lembrar, que estamos anexando juntamente a essa documentação,
um CD-ROM contendo uma copia da documentação em versão PDF, juntamente
com a aplicação (código-fonte e executável).
1.1. OBJETIVOS
O PVB tem como principal foco e objetivo: automação do processo de
pedidos em pequenas e médias
empresas do setor alimentício, em
específico: pizzarias, bares e TEMPO
lanchonetes.
Este projeto baseia-se na
necessidade de diminuir o
coeficiente resultante da equação:
tempo/pedido e em outro coeficiente PEDIDO
resultante da equação: quantidade
de garçons por cliente. Quanto
Figura 1 - Equação chave do PVB
menores forem esses coeficientes,
maior será a eficácia do PVB, sendo feita as medições dos coeficientes como
parâmetros de desempenho e de redução de custos para o cliente/empregador.
1.2. JUSTIFICATIVA
Observamos a necessidade de melhorar o atendimento nas mais diversas
lojas do ramo alimentício, pelo fato de que muitos destes estabelecimentos tem
poucas pessoas no atendimento, fazendo com que seus clientes fiquem muito tempo
aguardando até serem atendidos. Isso gera insatisfação ao cliente, que perde tempo
até conseguir ser atendido da forma que gostaria. Porém, do outro lado, o do
empregador, também há certa insatisfação, pelo fato de haver muitos clientes para
serem atendidos ao mesmo tempo, fazendo com que os atendentes fiquem irritados
e/ou estressados e, por diversas vezes, troquem os pedidos de seus clientes ou,
deem demasiada atenção a uma determinada região do restaurante, esquecendo-se
de outras, ou até mesmo gerando insatisfação da equipe de atendimento ao cliente.
Página 17 de 68

18. 1.3. ESCOPO
Embora o uso de aplicações bluetooth seja grande, pois a cada dia
aparecem mais softwares que se aproveitam da facilidade de uso desta tecnologia,
esse trabalho se limitará apenas ao desenvolvimento de um protótipo de software,
voltado para o setor alimentício, com um foco maior em restaurantes, lanchonetes,
bares, lojas de fast food, etc.
Como protótipo, além dos possíveis erros e limitações aqui relatados, há
a possibilidade de que sejam encontrados mais alguns erros, ainda desconhecidos
por nossa equipe, porém, aqui nos limitamos à apenas demonstrar que nossa ideia é
viável e que ela é possível de ser implantada nas mais diversas lojas existentes.
Ressaltamos também, que pelo fato de ser um protótipo, os
equipamentos necessários ainda são restritos e, neste momento garantimos suas
funcionalidades apenas aos modelos e marcas descritos mais adiante neste
documento.
1.4. DA VIABILIDADE
Por se tratar de uma tecnologia que está presente em praticamente todos
os novos celulares, seu custo de utilização é zero, tendo em vista que o protocolo
bluetooth já foi pago junto ao celular, o que nos favorece no sentido de que não é
necessário à aquisição de licenças para utilização do mesmo.
O Java, outra tecnologia que
está presente nos modelos de celulares
PROTOCOLO
mais novos, além de ser uma opção
BLUETOOTH
gratuita na questão do desenvolvimento,
tem custo zero para utilização, já que
LINGUAGEM também está presente na grande maioria
JAVA
dos celulares.
CUSTO ZERO
PARA Graças a esses desses dois
UTILIZAÇÃO
fatores: custo zero para utilização do
protocolo e para o desenvolvimento do
Figura 2 – Principais fatores de
software, somado a grande maioria da
decisão na escolha do tema
Página 18 de 68

19. população já ter um celular com tecnologia bluetooth e Java, faz com que nosso
projeto já tenha um imenso diferencial, onde não há a necessidade de aquisição de
novos equipamentos para poder utiliza-lo, pois estaremos usando equipamentos que
a grande massa da população já possui, onde estaremos apenas agregando mais
uma função aos celulares, fazer pedidos.
2. FUNDAMENTAÇÃO TEÓRICA
2.1. BLUETOOTH
2.1.1. História
Sua história começa por volta de 1994 (3), na época em que a empresa
Ericsson começou a estudar se seria viável ou não desenvolver uma tecnologia que
permitisse a comunicação entre celulares e acessórios utilizando sinais de rádio de
baixo custo, ao invés dos tradicionais e caros cabos de dados existentes na época.
Porém, foi em 1997 que começou o interesse de outras empresas nesta
tecnologia. Graças a esse interesse, foi criado o consórcio Bluetooth SIG (Special
Interest Group) (4), formado pelas empresas: Ericsson, Intel, IBM, Toshiba e Nokia.
Foi somente graças ao apoio dessas grandes empresas que o bluetooth
começou a virar realidade, e se tornou o que é hoje em dia, um padrão de mercado
competitivo para conexão de aparelhos celulares e acessórios que está presente em
praticamente todos os celulares.
2.1.2. Origem do nome e Logo
O nome bluetooth surgiu em homenagem ao antigo rei da Dinamarca,
Harald Bluetooth, no final dos anos 900. Ele se destacou por ter conseguido unir a
Dinamarca e parte da Noruega em um só reino (5).
Como a tecnologia bluetooth foi criada por empresas da região Nórdica,
seus desenvolvedores resolveram homenagear esse grande rei que fora Harald
Bluetooth. Na Figura 3 podemos ver o logo oficial da tecnologia, que combina a letra
“B” com a letra “H” em um alfabeto antigo da região.
Página 19 de 68

20. Figura 3 - Logo Bluetooth
2.1.3. Funcionamento do Bluetooth
Como Layton e Franklin (2000) (5) escreveram, as redes formadas
usando a tecnologia bluetooth transmitem dados via ondas de rádio de alta
frequência. Ela se comunica em uma frequência de 2,45 giga-hertz (para ser mais
exato, é entre 2,402 GHz e 2,480 GHz). Tal frequência, conhecida como ISM, foi
reservada por acordo internacional para uso de dispositivos industriais, científicos e
médicos.
Figura 4 - Distribuição de Frequências (Adaptador de Layton e Franklin; 2000 (5))
Umas das primeiras perguntas que todos fazem ao começar a trabalhar
com uma nova tecnologia, principalmente quando são tecnologias voltadas para
comunicação sem fio, é se não haverá interferência de outros dispositivos que
também trabalham com ondas de rádio de baixa frequência.
Os dispositivos bluetooth evitam tal interferência com outros sistemas
através do envio de sinais fracos, de cerca de 1 miliwatt. Para motivo de
comparação, os celulares mais modernos podem transmitir um sinal de até 3 watts.
Assim como Layton e Franklin (2000) (5) continuam em seu artigo, os
sistemas bluetooth podem se conectar com até oito dispositivos simultaneamente.
Mesmo com todos esses dispositivos trabalhando ao mesmo tempo, é totalmente
improvável que haja interferência entre eles, pois o bluetooth usa uma técnica
chamada salto de frequência de espalhamento espectral, que praticamente
impossibilita que mais de um dispositivo transmita na mesma frequência ao mesmo
tempo. Isso ocorre, porque um dispositivo usa 79 frequências individuais escolhidas
Página 20 de 68

21. aleatoriamente dentro de uma faixa previamente designada, mudando de uma para
outra com regularidade. Em se tratando do protocolo bluetooth, os transmissores
alteram as frequências 1.600 vezes por segundo, o que na prática quer dizer que
muitos dispositivos podem utilizar totalmente uma fatia limitada do espectro de rádio.
Como podemos observar na Tabela 1, assim como vários outros
protocolos, ele possui diversas classes, onde cada classe é mais especifica pra
certo tipo de aparelho. Abaixo, descriminamos as classes disponíveis:
POTÊNCIA MÁXIMA DE
CLASSE ALCANCE
TRANSMISSÃO
Classe 1 100 mW Até 100m
Classe 2 2,5 mW Até 10m
Classe 3 1 mW ~ 1m
Tabela 1 – Classes disponíveis do Bluetooth (Adaptado de Bluetooth SIG (1998) (4))
2.1.4. Versões do Protocolo
De acordo com ALECRIM (3) o histórico de versões do bluetooth até o
momento se resume à:
Bluetooth 1.0: A versão 1.0, inclusive a 1.0B, o início de tudo.
Justamente por ser primeira versão lançada, havia diversos problemas que faziam
com que sua implementação fosse ainda bem difícil e restrita há apenas alguns
modelos/marcas de celulares específicos;
Bluetooth 1.1: Lançada oficialmente em meados de fevereiro de 2001,
essa versão firma o bluetooth realmente como um padrão, o padrão IEEE 802.15;
Bluetooth 1.2: Seu lançamento ocorreu em novembro de 2003, e como
novidade destacou: Conexões mais rápidas, melhor proteção contra interferências
externas, suporte aperfeiçoado a scatternets1 e processamentos de voz mais
avançado;
1
Scatternets – Várias piconets (Conexão entre dois ou mais dispositivos usando o
protocolo bluetooth) conectadas.
Página 21 de 68

22. Bluetooth 2.0: Foi em novembro de 2004 que a versão 2.0 veio à tona.
Com ela, contamos com importantes aperfeiçoamentos que ocorrem no protocolo
bluetooth, como por exemplo: Diminuição do consumo de energia, aumento na
velocidade de transmissão de dados para 3 mbps (2.1 mbps efetivos), correção às
diversas falhas encontradas na versão anterior, e uma melhor comunicação entre os
dispositivos;
Bluetooth 2.1: Lançada em meados de agosto do ano de 2007, ela tem
como principal destaque o acréscimo de mais informações nos sinais de busca, isso
permite uma seleção melhorada dos dispositivos antes de estabelecerem uma
conexão entre si. Houve também melhorias nos procedimentos de segurança,
criptografia e uma diminuição ainda maior do consumo de energia;
Bluetooth 3.0: Tal versão foi lançada em abril de 2009, e suas principais
características são: Taxas de velocidade ainda maiores durante a transferência de
dados (Os dispositivos compatíveis com essa versão do bluetooth podem alcançar
até 24 mbps de transferência) e consumo de energia melhorado;
Bluetooth 4.0: A última versão disponível do protocolo. Lançado no final
de 2009, seu foco não foi na velocidade, mas sim no consumo de energia
inteligente, economizando ainda mais energia durante sua execução.
Vale lembrar que todas as versões são compatíveis entre si, porém sua
velocidade é determinada pela velocidade do menor protocolo em uso.
2.2. JAVA
Traduzido do próprio site do Java (6), a tecnologia Java, é tanto uma
linguagem de programação quanto uma plataforma, criada na década de 90 pela
empresa Sun Microsystems.
Como linguagem de programação, conta com uma grande vantagem em
relação às outras linguagens: como seus arquivos contendo o código-fonte não
possuem código nativo de processadores (ao invés disso, eles possuem os
bytecodes apenas da Java VM), e como o Java VM está disponível para os mais
diversos sistemas operacionais, o mesmo arquivo é capaz de rodar nas diversas
plataformas, por exemplo: Microsoft Windows, Solaris OS, Linux ou Mac OS. O
Página 22 de 68

23. segredo está na Java VM, que é específica de cada sistema operacional, diferente
da linguagem que é a mesma para todos os sistemas.
Figura 5 - Através do Java VM, a mesma aplicação é capaz de rodar em vários OS
(Adaptado do site oficial do Java (1997) (7))
Já como plataforma, o Java se divide em dois componentes:
 O Java Virtual Machine;
 Java API (Java Application Programming Interface).
Como mencionamos, o Java VM é à base da plataforma Java que é
compatível com várias plataformas. Já a Java API é uma larga coleção de
componentes (Classes e interfaces) da implementação Java já prontas, que provem
diversas utilidades.
Na verdade, para conseguir cobrir as mais diversas plataformas e ser
compatível com vários dispositivos, à tecnologia Java foi dividida em três
plataformas: Java SE (Java Platform, Standard Edition), Java ME (Java Platform,
Micro Edition) e Java EE (Java Platform, Enterprise Edition). Porém, nesse trabalho,
focaremos apenas nas duas primeiras.
2.2.1. Java Platform, Standard Edition (Java SE)
Página 23 de 68

24. Java SE é a plataforma Java para desenvolvimento de aplicações
voltadas para desktops e/ou servidores, usada como base para as demais
plataformas [JAVA SE, 2007] (8). Na Figura 6 podemos ver todos os componentes
que formam o Java SE:
Figura 6 – Componentes disponíveis no Java SE
(Adaptado do site oficial do Java (2007) (8))
2.2.2. Java Platform, Micro Edition (Java ME)
O Java Platform, Micro Edition (ou simplesmente Java ME) provem um
sistema robusto e flexível capaz de executar nos mais diversos equipamentos
móveis e embarcados que existem no mercado, como por exemplo: celulares, PDAs,
set-top boxes (conversores usados em televisão digital) e outros equipamentos com
características de baixa disponibilidade de recursos [JAVA ME, 2010] (9).
2.2.3. Java APIS for Bluetooth (JSR-82)
A JSR-82 é um pacote opcional que possibilita o uso do protocolo
Bluetooth dentro da linguagem Java, já que a mesma não possui suporte nativo ao
protocolo (10). Tal especificação divide-se em dois pacotes principais:
javax.bluetooth e javax.obex.
Comecemos pelo pacote javax.bluetooth. Ele é o centro dessa
especificação e, é ele que provê acesso a API responsável pela busca de
Página 24 de 68

25. dispositivos e procura de serviço, além de dar suporte as comunicações através dos
protocolos L2CAP2 e RFCOMM3.
Já o pacote javax.obex é o responsável por implementar uma API de
transferência de objetos via OBEX4.
2.3. BLUECOVE
2.3.1. Descrição
Segundo Paul Totterman5 e Skarzhevskyy6 (2004) (11), criadores do
BlueCove, ela é uma biblioteca que implementa o protocolo bluetooth
(implementação a especificação JSR-82) que é utilizada para a comunicação entre
aplicações J2ME e J2SE.
Além do fato de ser gratuito (O BlueCove está sob a licença Apache
License, Version 2.0, licença está que permite a distribuição comercial de softwares
com o BlueCove, desde que mencionada as fontes), o BlueCove é uma biblioteca
para a linguagem Java de fácil aprendizagem que implementa as principais funções
para a comunicação com dispositivos bluetooth, fazendo com que não haja a
necessidade de criarmos métodos para conexão diretamente dos celulares.
2.3.2. Funcionamento
O BlueCove trabalha junto com a Java VM, utilizando uma pilha bluetooth
que existe no Windows XP SP2 (No caso do nosso protótipo) que, através de
simples funções, fazem todo o trabalho de se comunicar com os aparelhos de
celulares via bluetooth, fazendo com que não seja preciso trabalharmos diretamente
com o hardware do celular.
Na Figura 7 temos uma imagem retirada do site oficial do BlueCove
<http://www.bluecove.org> que mostra em qual camada o BlueCove trabalha:
2
L2CAP - Logical Link Control and Adaptation Protocol: esse protocolo faz parte da
subcamada MAC do Bluetooth e “permite a multiplexação de protocolos de nível superior e os
processos de segmentação e remontagem de pacotes” (23)
3
RFCOMM - Protocolo que emula um cabo Serial baseado no ETSI TS 07.10 (22)
4
OBEX - protocolo de transferência que define objetos, dados e protocolo de
comunicação que dois dispositivos podem usar para trocar tais dados e ou objetos (24)
5
Paul Totterman – Criador do BlueCove
6
Skarzhevskyy - Criador BlueCove
Página 25 de 68

26. Figura 7 - Funcionamento do BlueCove (Adaptado do Site Oficial do BlueCove (11) )
2.3.3. Requerimentos Mínimos
Conforme documentação técnica disponível no site do BlueCove (2004)
(11), podemos ver a seguir os requerimentos mínimos para podermos trabalhar com
o BlueCove:
Pilhas que o BlueCove suporta (é necessário ter em mente que uma pilha
é um meio de comunicação entre um dispositivo bluetooth, nesse caso desktop, e
um dispositivo ambiente, no nosso caso, um dispositivo móvel):
WIDCOMM (Broadcom) BTW Stack software versão 1.4.2.10 SP5 ou
superior;
BlueSoleil versão 1.6.0, 2.3 ou 3.2.2.8. A versão 5.0 não é suportada;
Página 26 de 68

27. Microsoft Bluetooth Stack (Windows XP SP2 e Windows Mobile 2003);
PowerPC - ou Intel-based Mac OS X 10.4 (Bluetooth v1.2) ou superior;
Linux com BlueZ Bluetooth stack;
Também é necessário um dispositivo Bluetooth que suporte WIDCOMM,
BlueSoleil ou o Microsoft Bluetooth Stack;
Java 1.1 ou superior para a execução dos binários e Java 1.4 ou superior
para compilar;
E por fim, é indispensável outro dispositivo Bluetooth, para que haja
comunicação entre ambos.
2.3.4. Limitações
Também extraído da documentação técnica do BlueCove (2004) (11), os
autores continuam informando sobre as principais limitações descobertas durantes
os testes com o mesmo:
L2CAP o suporte está apenas disponível usando as pilhas: Windows
WIDCOMM Stack, Linux BlueZ e Mac OS X Stack.
Como o Microsoft Bluetooth Stack suporta apenas conexões RFCOMM,
logicamente o BlueCove também suporta apenas conexões RFCOMM quando é
usado tal pilha. Os sistemas Microsoft que suportam tal pilha são: Windows XP SP2,
Windows Mobile 2003 ou superior, tudo isso pelo fato do Microsoft Bluetooth Stack
não estar disponível em outros sistemas operacionais da empresa.
2.3.5. Funções não implementadas
Os autores do BlueCove (2004) (11) relatam que tanto a autenticação, a
autorização e a criptografia ainda não foram implementadas nos dispositivos móveis.
2.3.6. A importância do BlueCove no Projeto
“Não reinventar a roda” (Provérbio com autor desconhecido), eis nossa
ideia básica ao criar este projeto. O que queremos na verdade, é demonstrar como é
possível usar de tecnologias simples, mas que estão presentes na maioria dos
celulares nos tempos atuais. Por isso mesmo, resolvemos adotar essa
implementação dos controles do Bluetooth feito com base na linguagem de
Página 27 de 68

28. programação Java no nosso projeto. Tendo em vista que, igual ao provérbio
mencionado, não desejamos reinventar algo que existe, mas sim criar soluções
novas utilizando o que já dispomos.
A biblioteca BlueCove foi importante para a gerencia do protocolo
bluetooth. A partir de sua implementação as instruções para manuseio de conexões,
a procura por aparelhos, emparelhamento de dispositivos e envio e recebimento de
informações eram gerenciados e providos pelo próprio BlueCove, o que ocasionou
ganho de tempo, pois tornou aplicação funcional, além do que o objetivo era o de
usar e não o de gerenciar o protocolo bluetooth.
Página 28 de 68

29. 3. METODOLOGIA DE DESENVOLVIMENTO
3.1. DESENVOLVIMENTO ORIENTADO A TESTES
Devido ao curto prazo de desenvolvimento do nosso projeto, adotamos
uma metodologia ágil, mais precisamente a desenvolvimento orientado a testes, que
como Sanchez (2006) (12) menciona, ela se baseia em três regras básicas:
Escreva um teste que falhe: É a primeira coisa que devemos fazer
nesse caso de metodologia, descrever o contexto e definir quais são as verificações
que necessitam ser feitas. Vale ressaltar que não existe nenhum limite do número de
vezes que o teste precisa ser executado;
Faça o teste passar: Este é o ponto crucial do desenvolvimento
orientado a testes. Deve-se escrever o mínimo de código para que o teste seja
concluído com êxito, mesmo que tenhamos a certeza de que o código deve fazer
mais coisas do que deveria, devemos nos limitar apenas a fazer com o que o teste
seja concluído;
Melhore o código já escrito: Após o teste ter sido concluído, deve-se
verificar o código para que seja identificada qualquer melhoria necessária e/ou
possível, lembrando que os testes ainda precisam ser concluídos com êxito.
Tais passos são repetidos inúmeras vezes, até que não se consiga
elaborar novos testes ou, até que o software em questão esteja pronto.
Podemos ver claramente o ciclo da metodologia de desenvolvimento
orientado a testes com base na Figura 8:
Página 29 de 68

30. Figura 8 - Ciclo de Desenvolvimento Orientado a Teste de Aceitação
(Adaptado de Nadalete (2010))
Como Hendrickson (2008) (13) exemplifica, a Figura 8 nos mostra um
exemplo prático e completo de como extrair o melhor das práticas de
desenvolvimento orientando a testes e desenvolvimento orientando a teste de
aceitação. Nadalete (2010) (14) ainda destaca que as equipes que aplicam tais
práticas, principalmente ATDD, tendem a sentir os benefícios ainda na fase de
discussão dos requisitos e estabelecimento dos critérios de aceitação, por meio de
uma melhor e mais completa compreensão das necessidades previamente
solicitadas.
Por fim, Nadalete (2010) (14) continua informando que quando o ciclo
proposto na Figura 8 é trabalhado do começo ao fim do projeto, os envolvidos
tendem a concordar que o sistema tende a se tornar mais testável, manutenível e
relativamente fácil. Com a suíte de testes gerada é possível efetuar os testes de
regressão automaticamente, fornecendo um pronto feedback sobre as expectativas
relacionadas às funcionalidades bases do sistema, e ao negócio como um todo.
Página 30 de 68

31. Além do mais, como Pedroso (2010) (15) cita, entre os principais
beneficios, podemos citar:
Código bem Testado: Como primeiro beneficio, temos o processo de
automação de testes, que ao longo do desenvolvimento, é a obtenção de uma suíte
de testes de regressão;
Segurança para Refatorar: O código fonte foi gerado com o principio da
refatoração, o que faz com que ele possa ser reestruturado, transformando-o em um
código com maior flexibilidade, sem duplicidades, melhor comunicação e mesmo
assim com a funcionalidade preservada.;
Design Evolutivo: A escrita dos testes feita antes do código induz aos
programadores a pensar na interface externa do programa e no seu comportamento
antes de pensar nos detalhes de implementação. Isso faz com que o código-fonte
seja projetado a partir de necessidades reais de uso, mantendo a solução sempre
objetiva e simples. Some-se a isso a disposição de escrever inicialmente sempre o
código mais simples possível, para somente depois pensar com calma em sua
estrutura e torna-lo mais bem feito do ponto de vista do design interno, sem
modificar sua interface externa;
Documentação: Os testes são exemplos claros e diretos de como se
espera que nosso programa se comporte. Uma rápida revisada sobre a suíte de
testes quando bem estruturada é suficiente para entender muita coisa sobre o
código-fonte. O melhor de tudo, é que sendo os testes executados com frequência e
mantidos 100% satisfeitos durante todo o tempo, tem-se certeza de que aquele
código é uma especificação atualíssima que reflete com precisão o estado atual do
programa;
Sistema de organização: A metodologia orientada a testes define com
precisão a sequência de atividades que deve ser desempenhada para a criação do
código-fonte.
3.2. FERRAMENTAS DE DESENVOLVIMENTO
Para o desenvolvimento do nosso projeto, utilizamos apenas uma IDE:
Netbeans: Ótima ferramenta para desenvolvimento de softwares,
principalmente pela questão dela já possuir plug-ins adicionais para edição visual
Página 31 de 68

32. dos programas, fazendo com que seja necessária apenas a inserção de códigos
relacionados às funções em especifico e, também conta o suporte a edição de
diversas outras linguagens de desenvolvimento (16). Porém, sua grande
desvantagem, é que seu código-fonte torna-se bastante poluído e muitas vezes,
torna-se extremamente difícil de ser editado manualmente devido a sua alta
complexidade, devido ao fato do Netbeans gerar diversas marcações e/ou código
que por diversas vezes podem ser desnecessários ao uso da aplicação.
3.3. DIFICULDADES ENCONTRADAS
Como principais dificuldades no desenvolvimento do nosso projeto,
contamos logo de inicio com a falta de conhecimento que tínhamos na questão de
conexão entre dispositivos utilizando o protocolo bluetooth.
Para sanar tal dificuldade, tentamos procurar por sistemas semelhantes,
ou pelo menos sistemas que usassem conexões bluetooth para enviar e receber
dados. Foi nesse ponto que descobrimos o BlueCove e resolvemos adota-lo como
pilar central do nosso projeto, fazendo com que finalmente tivéssemos uma base
para iniciar o desenvolvimento do PVB.
Página 32 de 68

33. 4. DESENVOLVIMENTO
Dividimos a aplicação em dois módulos: O Módulo Servidor e o Módulo
Cliente. O primeiro foi desenvolvido para ser executado em um notebook e/ou
desktop, já o segundo, deverá ser instalado em um celular comum.
4.1. EQUIPAMENTOS NECESSÁRIOS
Durante os testes executados e para o funcionamento correto do software
cliente, precisamos de um celular que tenha no mínimo:
Java Virtual Machine;
Tecnologia Bluetooth.
No decorrer do processo de criação deste protótipo, todos os seus testes
foram utilizando os seguintes modelos de celulares: Motorola Z3 e o Nokia Express
Music 5130.
Figura 9 - Motorola Z3 (Motorola Inc.), primeiro equipamento usado durante os testes
Página 33 de 68

34. Figura 10 - Nokia Express Music 5130 (Nokia Copyright), segundo equipamento usado durante os testes
Já para o funcionamento do servidor, foi preciso a aquisição de um
dispositivo de conexão bluetooth comum e, tendo em vista que estamos na fase de
protótipo, não nos importamos com a classe e/ou outras especificações do
dispositivo.
4.2. A METODOLOGIA NA PRÁTICA
Como descrito na Figura 8, o Desenvolvimento Orientado a Testes de
Aceitação consiste de diversas fases. Como primeira fase, ouve diversas reuniões
da equipe de desenvolvimento, onde era discutido como deveria ser e se comportar
nosso software. Nada de muito concreto nessa fase, apenas diversas ideias
lançadas e debatidas. Já na segunda fase, a de refino, foi onde filtramos tudo o que
seria viável e possível de ser implementado. Durante essas fases iniciais, foi
elaborado a nossa primeira documentação, que consistia de apenas um resumo do
trabalho em questão. Tal resumo foi apresentado em sala de aula, e exaustivamente
melhorado, dando origem à documentação final deste Trabalho de Conclusão de
Curso.
Aqui entramos na terceira fase, o desenvolvimento em si. Começamos por
desenvolver a aplicação servidor, pois imaginamos que este seria o ponto crítico de
Página 34 de 68

35. todo o nosso sistema. Pois bem, seguindo a metodologia escolhida, após as
primeiras linhas de código, começamos em paralelo, os testes do sistema. O
interessante dessa metodologia, é que sempre temos o código bem testado, fazendo
com que diversos erros, sejam facilmente detectados, logo no início do
desenvolvimento.
Por fim, na última fase da metodologia orientada a testes de aceitação,
após desenvolver apenas um pedaço do software, e testa-lo por inúmeras vezes,
detectamos a possibilidade de aperfeiçoar tal função. Isso foi feito por incontáveis
vezes, até percebermos que não era mais possível otimiza-la.
E o ciclo continua sempre se repetindo. Seguimos tais passos,
implementando função por função até que finalmente nosso protótipo estava
operacional e pronto para ser apresentado.
4.3. FUNCIONAMENTO
Na prática, com um cardápio impresso e disponível na mesa do cliente, é
possível que ele identifique os códigos dos itens que deseja solicitar e então,
coloque-os na aplicação cliente previamente instalada em seu celular. A aplicação
servidor recebe tais itens, e os responsáveis apenas entregam na mesa do cliente o
que foi solicitado.
4.3.1. Aplicação Servidor
O servidor consiste de dois arquivos: Main.java e Conexao.java. O
primeiro arquivo contém apenas uma chamada que invoca o servidor propriamente
dito. Já o segundo, é o responsável por fazer toda a parte de conexão,
emparelhamento de dispositivos e recebimento dos dados enviados da aplicação
cliente.
Além disso, esse lado da aplicação consiste de um software desenvolvido
em J2SE que funciona de uma forma extremamente simples. Ao carrega-lo, ele abre
uma conexão bluetooth, tornando-se detectável para os outros dispositivos que
estejam ao seu alcance e que possuem o aplicativo cliente instalado. Na Figura 11,
podemos observar diretamente no código-fonte, onde exatamente o servidor torna-
se detectável por outros dispositivos bluetooth:
Página 35 de 68

36. 37 System.out.println("Habilitando dispositivo para ser descoberto...");
38 local = LocalDevice.getLocalDevice();
39 local.setDiscoverable(DiscoveryAgent.GIAC);
40 System.out.println("Dispositivo habilitado");
41 server = (StreamConnectionNotifier)Connector.open(url);
42 System.out.println("Aguardando por conexoes...");
Figura 11 - Código-Fonte, Tornando dispositivo detectável
Como já citado, a parte de conexão é feita através de simples chamadas,
onde é requisitado à biblioteca do BlueCove que faça a conexão com o hardware
bluetooth, tornando nosso servidor disponível para aceitar conexões de outros
dispositivos bluetooth.
INICIO SERVIDOR DETECTÁVEL CLIENTE CONECTA AGUARDANDO
PEDIDO
Figura 12 - PVB Servidor, Visão Resumida
Após o software tornar-se detectável, qualquer celular que tenha a versão
Cliente do PVB pode facilmente detectar e conectar ao sistema, conseguindo assim
transferir todos os seus pedidos.
A Figura 13, nos mostra a parte do código-fonte responsável por aceitar
dispositivos que possuem a aplicação cliente instalada. Como observado, após o
servidor detectar que houve a conexão de algum dispositivo, ele para e aguarda até
que os dados do pedido sejam recebidos.
44 conn = server.acceptAndOpen();
45 System.out.println("Cliente conectado");
46 System.out.println("Aguardando Pedido...n");
Figura 13 – Código-Fonte, Cliente Conecta
O funcionamento do servidor é extremamente simples, ele recebe uma
string com um conjunto de vários números concatenados e separados pelo símbolo
de dois pontos. Por exemplo:
Página 36 de 68

37. 14 : 015 : 02
Identifica a
Identifica o Identifica o
quantidade
numero da item
do item
mesa pedido
pedido
Figura 14 - Concatenação de números enviado ao servidor
No exemplo da Figura 14, temos a sequência 14:015:02, onde os dois
primeiros números identificam qual mesa o cliente está sentado, seguido por mais
três números, estes responsáveis por identificar o item que o cliente deseja, e por
fim temos mais dois números, que significam a quantidade do item solicitado.
Como podemos observar na Figura 15, o código-fonte que separa os
valores recebidos da aplicação cliente, é composto por:
58 if ( !(cmd.equals("conta"))) {
59 mesa = "";
60 item = "";
61 quantidade = "";
62
63 contador = cmd.length();
64 for(int i = 0;i<contador;i++){
65 if (i < 2) {
66 mesa += cmd.substring(i,i+1);
67 }else {
68 if ((i > 2) && (i < 6)) {
69 item += cmd.substring(i,i+1);
70 }else{
71 if (i > 6) {
72 quantidade += cmd.substring(i,i+1);
73 }
74 }}}
Figura 15 – Código-Fonte, extração dos valores concatenados
Desta forma, fica fácil manipular todos os dados enviados pelo cliente,
dando-nos a possibilidade para que possamos fazer o que bem entendemos com os
dados recebidos.
Página 37 de 68

38. Também podemos notar pela Figura 16, onde está localizada a parte do
código-fonte responsável por captar os dados enviados pelo cliente e exibir na tela:
84 if (Integer.parseInt(item) <= 11){
85 totalParcial = Integer.parseInt(quantidade) * ((Double)
dff.parse(itemsPreco[Integer.parseInt(item)].toString()).doubleValue());
86 total += totalParcial;
87
88 if (contadorItem < 10){
89 mostraContador = "0"+String.valueOf(contadorItem);
90 } else {
91 mostraContador = String.valueOf(contadorItem);
92 }
93 System.out.println(" "+mostraContador+" "+item+" " +
itemsBar[Integer.parseInt(item)].toString()+" "+quantidade+" R$" +
itemsPreco[Integer.parseInt(item)].toString() + "R$"+String.format("%.2f",
totalParcial));
94 } else{
95 System.out.println( "Item nao encontrado..");
96 }
Figura 16 - Código-Fonte, imprimindo dados recebidos pelo servidor
4.3.2. Aplicação Cliente
Já o lado cliente, foi desenvolvido utilizando J2ME que, como já
discutimos, é uma subdivisão da linguagem de programação Java.
O cliente deverá ter o aplicativo instalado em seu celular, para isso é
necessário que seja feito um cadastro junto ao estabelecimento, e a partir disto é
disponibilizado o software ao cliente e este por sua vez instala a aplicação em seu
aparelho celular.
Assim que iniciado, é necessário efetuar a busca por algum servidor que
esteja disponível ao seu redor. Para isso, existe uma opção de iniciar busca. Ao
iniciar tal busca, o software cliente procura por todos os dispositivos bluetooth que
estejam ao seu alcance e que possuem o software servidor instalado.
Como podemos observar na Figura 17, é exatamente o que acabamos de
descrever. Nesse pedaço do código-fonte, é feito a chamada de função para a busca
de dispositivos (neste caso, dispositivos que possuem a aplicação servidor
previamente instaladas e já com a conexão bluetooth habilitada). Logo após, é
estabelecido à conexão com o servidor. Se não for possível conectar, será exibido
Página 38 de 68

39. uma mensagem de erro (Error Connecting), caso contrário o cliente se conectará e
estará disponível para poder enviar os pedidos que desejar.
349 public void FindDevices(){
350 try{
351 devices = new java.util.Vector();
352 LocalDevice local = LocalDevice.getLocalDevice();
353 DiscoveryAgent agent = local.getDiscoveryAgent();
354 agent.startInquiry(DiscoveryAgent.GIAC,this);
355 }catch(Exception e){this.do_alert("Erro ao iniciar busca" , 4000);}
356 }
357
358 public void FindServices(RemoteDevice device){
359 try{
360 UUID[] uuids = new UUID[1];
361 uuids[0] = new UUID("27012f0c68af4fbf8dbe6bbaf7aa432a",false);
362 local = LocalDevice.getLocalDevice();
363 agent = local.getDiscoveryAgent();
364 agent.searchServices(null,uuids,device,this);
365 }catch(Exception e) { this.do_alert("Erro ao iniciar busca" , 4000);}
366 }
Figura 17 – Código-Fonte, procurando servidor e estabelecendo conexão
Após efetuar o emparelhamento entre o cliente e o servidor, existem três
opções disponíveis para o cliente, que são as mesmas do lado servidor. A única
diferença aqui, é que é nesse ponto que o usuário deve inserir os valores. Em
seguida, o software cliente trata de concatenar os dados (assim como descriminado
na parte do servidor), e então envia a mensagem através da conexão Bluetooth
previamente estabelecida.
É possível observar na Figura 18, onde dentro do código-fonte é feito a
concatenação dos dados digitados pelo usuário e em seguida transmitidos ao
servidor:
196 dout.writeChars(mesa + ":" + item + ":" + qtde + "n");
197 dout.flush();
Figura 18 – Código-Fonte, concatenação dos dados digitados pelo usuário e enviado ao servidor
Também está disponível a opção de “Fechar Conta”. Opção essa, que
envia uma mensagem ao servidor informando para finalizar o pedido da mesa.
Em seguida, ocorrem dois fatos importantes:
Página 39 de 68

40.  No Servidor: É somada a conta, gerando um valor total e encerrada a
conexão com o dispositivo móvel. Todos os itens pedidos e valores são exibidos na
tela do servidor;
 No Cliente: O programa apenas é encerrado.
Na Figura 19, destacamos uma versão extremamente resumida de como
deve funcionar a aplicação cliente:
PROCURA ENVIA
INICIO CONECTA
SERVIDOR PEDIDO
Figura 19 - PVB Cliente, Visão Resumida
Página 40 de 68

41. 4.3.3. Cardápio
Para fins de testes, criamos um cardápio simples, contendo apenas
alguns itens de exemplo, assim como mostrado abaixo:
Cardápio – Divisão de Bebidas
CÓDIGO DESCRIÇÃO VALOR UNITÁRIO
001 Coca-Cola Lata R$ 2,50
002 Coca-Cola Light Lata R$ 2,50
003 Kuat Lata R$ 2,50
004 Kuat Light Lata R$ 2,50
005 Fanta Laranja Lata R$ 2,50
Tabela 2 - Cardápio de Exemplo, Divisão de Bebidas
Cardápio – Divisão de Lanches
CÓDIGO DESCRIÇÃO VALOR UNITÁRIO
006 X-Tudo R$ 9,90
007 X-Egg R$ 8,00
008 X-Salada R$ 5,00
009 X-Burger R$ 5,50
010 Cachorro-Quente R$ 3,00
011 Misto Quente R$ 3,00
Tabela 3 – Cardápio de Exemplo, Divisão de Lanches
Página 41 de 68

42. 4.3.4. Exemplo de funcionamento
4.3.4.1. Módulo Servidor
Figura 20 - Aguardando Conexão
Página 42 de 68

43. Figura 21 - Dispositivo Conecta e Servidor para, aguardando pedido
Página 43 de 68

44. Figura 22 - Aplicação Servidor Recebe Pedido (1)
Página 44 de 68

45. Figura 23 - Aplicação Servidor Recebe Pedido (2)
Página 45 de 68

46. Figura 24 - Aplicação Servidor Fecha Conexão e mostra o valor total da conta
Página 46 de 68

47. 4.3.4.2. Módulo Cliente
Figura 25 - Tela Inicial Aplicação Figura 26 - Dispositivo Móvel a
Cliente procura da aplicação servidor
Página 47 de 68

48. Figura 28 - Servidor Encontrado Figura 27 - Tela de Pedidos
Página 48 de 68

49. Figura 29 - Tela de Pedidos Preenchida
Figura 30 – Preenchendo Tela de
Pedidos
Página 49 de 68

50. Figura 32 - Opção que envia dados ao Figura 31 - Opção que Fecha a
servidor Conta
Página 50 de 68

51. 4.4. LIMITAÇÕES ENCONTRADAS
Por ainda se tratar de um protótipo, nosso software ainda conta com
algumas limitações, onde dentre elas podemos destacar:
Limite de Conexões Simultâneas: O software servidor não aceita mais
de um dispositivo conectado ao mesmo tempo, esta limitação esta ligada
diretamente à programação, onde ainda não foi implementada tal função, que para
que seja corrigida, será necessário a utilização de threads;
Suporte a poucos Aparelhos: O software cliente simplesmente não roda
em alguns modelos de aparelhos móveis devido ao fato destes aparelhos conterem
diferentes versões da linguagem Java;
Limite de Aparelhos ao Redor: O bluetooth conta com uma limitação de
8 conexões simultâneas em sua rede. Portanto, se houver mais de 8 aparelhos com
o bluetooth habilitado no raio do dispositivo, há uma grande possibilidade da
aplicação cliente retornar erro na hora que tentar localizar a aplicação servidor. Por
diversas vezes, o erro informado é “Dispositivo Não Encontrado”, devido o fato de
em algumas circunstâncias o servidor ser o 9º dispositivo a ser localizado.
Infelizmente, essa é uma limitação do próprio protocolo bluetooth.
Página 51 de 68

52. 5. CONCLUSÃO
5.1. CONSIDERAÇÕES FINAIS
No início do desenvolvimento da aplicação elencamos várias
funcionalidades que iriamos implementar: iniciar uma conexão entre um celular e um
computador, onde o celular deveria ser capaz de enviar dados ao computador, e o
mesmo ser capaz de interpreta-los, tudo isso utilizando o protocolo de comunicação
bluetooth. Ao término pode-se observar que as funcionalidades inicialmente
propostas foram criadas, atingindo nossas principais metas e objetivos.
A grande dificuldade inicial, foi conseguir estabelecer uma conexão
bluetooth. Poucos exemplos e material extremamente escasso na área dificultaram
ainda mais nosso entendimento e o desenvolvimento da aplicação.
O uso da biblioteca BlueCove para o desenvolvimento da aplicação como
um todo nos facilitou a implementação e um melhor entendimento de como funciona
conexões Bluetooth com a linguagem de programação Java. Como mencionamos,
essa biblioteca é uma implementação complexa da especificação JSR-82, que tem
como propósito padronizar um conjunto de APIs Java que possibilite a um
dispositivo integrar um ambiente bluetooth.
Nossa principal ideia ao desenvolvermos uma aplicação desse tipo é
agilizar a forma como os clientes são atendidos nos mais variados estabelecimentos
do ramo alimentício. Notamos que poderíamos aproveitar de tecnologias que estão
presentes no nosso dia-a-dia, tal como celulares com conexão bluetooth, e a
linguagem Java, que está presente também na grande maioria dos novos celulares.
É claro que apesar de tais tecnologias estarem presentes em nosso
cotidiano, é fácil notar a falta de aplicações que as use. Não sabemos ao certo
porque isso ocorre. Talvez pelo fato da precária documentação sobre como trabalhar
com dispositivos móveis que atualmente existem no mercado. Se os fabricantes dos
mesmos disponibilizassem algumas informações internas do funcionamento de tais
dispositivos, isso facilitaria o ingresso em tal área. Ou se pelo menos houvesse
algum outro tipo de padrão, que definiria os tipos de aplicações ou produtos que os
dispositivos móveis necessitariam ter ou suportar. De qualquer modo, não existe
Página 52 de 68

53. uma resposta totalmente concreta para tal pergunta. Essa ainda é uma área pouco
explorada pelo mercado.
Além disso, na questão do desenvolvimento dos softwares em si, temos o
problema da difícil implementação da conexão bluetooth, devido ao fato de pouca
documentação e exemplos disponíveis para podermos trabalhar com o mesmo. O
padrão JSR-82 veio para tentar suprir tal necessidade, porém ainda não é muito
explorado e estudado pelos desenvolvedores, que mesmo assim encontram várias
dificuldades ao tentar implementa-lo.
Foi essa a razão que fez com que adotássemos a biblioteca BlueCove,
que é a responsável por implementar o padrão JSR-82, que facilitou nosso trabalho
de desenvolvimento, pois podemos focar totalmente no desenvolvimento da nossa
aplicação.
Contudo, esperamos que com mais esse trabalho consigamos chamar
atenção das empresas e desenvolvedores, para o grande potencial que podemos ter
utilizando tecnologias que a grande maioria da população já possui. Entendemos
que com o fim desse trabalho, fomos incentivados a buscar cada vez mais
conhecimento não só profissional, mas também acadêmico.
5.2. TRABALHOS FUTUROS
Em seguida, alguns itens que pretendemos implementar para que nossa
aplicação esteja pronta para ser comercializada:
a. Servidor com suporte a múltiplas conexões simultâneas;
b. Interação com banco de dados.
5.2.1. Em relação à Segurança
A camada de segurança que será implementada terá seu funcionamento
baseado principalmente em conceitos de sessão e whitelist.
Whitelist, em uma tradução literal seria lista branca, que tem por
definição listar os usuários ou sistemas que podem acessar - ou tem permissão para
isso - um determinado serviço, sistema ou dado sendo sua antítese a Blacklist, que
lista quem não tem esse privilégio.
Página 53 de 68

54. Nossa opção por usarmos uma whitelist é pela maior facilidade em
determinarmos quem poderá acessar o sistema do que quem não poderá acessá-lo;
o cálculo para essa conclusão é simples:
 Se número de bloqueados for maior que o número de permitidos, usar
whitelist;
 Se número de bloqueados for menor que o número de permitidos, usar
blacklist.
Outra ponderação na escolha de whitelist foi na sua facilidade de
manutenção, pois é mais fácil inserir um elemento em um universo de permitidos do
que retirar um elemento de um universo de restritos.
A whitelist será composta pelos MAC’s (Media Access Control) Address
dos celulares cadastrados nos estabelecimentos.
Sessão é o método que determina que o usuário acessando determinado
serviço ou sistema é o mesmo que o sistema acredita estar logado, em outros
termos, é responsável por garantir a identidade do cliente/usuário.
O processo de autenticação de um usuário/cliente no sistema começará
com uma solicitação do cliente para abrir uma conexão com o Sistema/Servidor;
uma vez aceita, o sistema irá validar o MAC Address do cliente comparando-o com a
whitelist. Caso o sistema encontre o MAC Address na relação da whitelist, ele dará
início a uma sessão, caso contrário será fechada a conexão.
Uma vez que a sessão for aberta, sua vida útil será até o encerramento
da conta ou se houver algum problema na conexão.
Por medidas de segurança, caso outro dispositivo tente acessar
simultaneamente a sessão, o mesmo terá a sua conexão cancelada; evitando que
terceiros façam pedidos de forma anônima ou por roubo de identidade.
Cada sessão é única e direcionada a apenas a um usuário, no caso MAC
Address; sendo que cada MAC Address só pode ter uma sessão por vez e cada
sessão só poderá ter um único MAC Address durante toda a sua vida útil.
Página 54 de 68

55. 5.2.2. Melhorias no Cliente
Pensamos primeiramente em sanar as limitações da aplicação,
melhorando a conexão, de forma que se possa encontrar o servidor mais facilmente.
estudaremos também, uma forma de tornar o software cliente funcionar na maioria
dos celulares disponíveis no mercado, tornando cada vez mais viável nosso
software.
Em segundo plano trabalharemos o visual implementando uma tela de
saudações e um cardápio mais completo contendo promoções feitas pela casa, uma
vez que o cliente se conectar ao servidor, uma lista de promoções será envida ao
cliente, possibilitando ser acessada qualquer momento, um bom incentivo para o uso
do software, uma vez que essas promoções só serão validas se o pedido vier pelo
software... pensamos também na possibilidade de quando a conta for fechada, o
resumo da conta, juntamente com a soma dos itens sejam enviados a aplicação
cliente, pensamos em algo mais simples para esta aplicação, porem funcional, de
forma que fique bem genérica, podendo ser utilizada em todos os estabelecimentos
que sejam franqueados ao PVB.
5.2.3. Melhorias no Servidor
A equipe está estudando implementar a interface do servidor de forma
simples e objetiva. Há algumas métricas que pretendemos utilizar como: menus
relacionados por assuntos semelhantes e a quantidade de “cliques” que são
necessários para navegar de um menu a outro.
 Prioridade dos pedidos: Iremos implementar um contador que será
responsável por calcular o tempo de espera de cada pedido. Assim o sistema irá
ordenar com maior prioridade os pedidos que tiverem o valor do contador mais
elevado. Sendo a fórmula para o
TEMPO
TEMPO contador:
DO
ATUAL
PEDIDO
Tempo Atual - Tempo do pedido
CONTADOR
Figura 33 - Equação do Contador relacionado à
Prioridade de Pedidos
Página 55 de 68

56.  Menus/Telas:
1. Cadastro de Produto: É a janela que será responsável por
cadastrar o produto no Banco de Dados; informações como: marca, descrição, tipo
de unidade de medida e número do produto (id) serão obrigatórios; sendo o número
do produto de origem automática pelo Sistema.
2. Cadastro de Fornecedores: Nessa janela serão cadastrados os
dados dos fornecedores, assim como nome, endereço, CNPJ e contato da empresa.
3. Pedidos: Será a janela que ficará disponível para os
responsáveis pela cozinha, nela estarão os pedidos que estão abertos, ordenados
conforme prioridade.
4. Entrada de Notas Fiscais: Nessa tela serão inseridas as notas
fiscais no Sistema, que automaticamente alimentarão o estoque. Há também a
necessidade da criação de um ícone para impressão de notas fiscais.
5. Estoque: Nosso conceito de estoque foi inspirado no SAP, onde
cada nota fiscal é responsável por alimentar o estoque. Cada item já tem que estar
previamente cadastrado no banco, via tela de Cadastro de Produto; e cada
Fornecedor também tem que estar previamente cadastrado, via tela de Cadastro de
Fornecedores.
Conforme houver o consumo via pedido o estoque terá o débito
automaticamente.
Página 56 de 68

57. 6. REFERÊNCIAS BIBLIOGRÁFICAS
1 CARDOSO, F. H. Agência Nacional de Telecomunicações. Anatel,
1997. Disponivel em: <http://www.anatel.gov.br>. Acesso em: 19 Março 2010.
2 CIARELLI, M. Anatel estima 300 milhões de celulares no Brasil em
2013. Exame, 2010. Disponivel em:
<http://exame.abril.com.br/tecnologia/noticias/anatel-estima-300-milhoes-celulares-
brasil-2013-561697>. Acesso em: 22 Outubro 2010.
3 ALECRIM, E. Tecnologias Bluetooth. InfoWester, 2008. Disponivel em:
<http://www.infowester.com/bluetooth.php>. Acesso em: 19 Outubro 2010.
4 ERICSSON, IBM, TOSHIBA, NOKIA, 3COM, LUCENT
TECHNOLOGIES, MICROSOFT E MOTOROLA. Bluetooth Special Interest Group.
Bluetooth SIG, 1998. Disponivel em: <http://www.bluetooth.com>. Acesso em: 15
Outubro 2010.
5 LAYTON, J.; FRANKLIN, C. Como Funciona o Bluetooth. Como as
Coisas Funcionam?, 2006. Disponivel em:
<http://informatica.hsw.uol.com.br/bluetooth.htm>. Acesso em: 22 Outubro 2010.
6 ORACLE. Conceitos e Definições Úteis. Java SE, 2007. Disponivel em:
<http://www.java.com/pt_BR/download/faq/helpful_concepts.xml>. Acesso em: 15
Outubro 2010.
7 ORACLE. About the Java Technology. Java, 2007. Disponivel em:
<http://download.oracle.com/javase/tutorial/getStarted/intro/definition.html>. Acesso
em: 11 Outubro 2010.
8 ORACLE. Java SE 6 Documentation. Java SE, 2007. Disponivel em:
<http://download.oracle.com/javase/6/docs/index.html>. Acesso em: 11 Outubro
2010.
9 ORACLE. Java ME at a Glance. Java ME, 2007. Disponivel em:
<http://www.oracle.com/technetwork/java/javame/overview/index.html>. Acesso em:
11 Outubro 2010.
10 JSR-82. JSR-82: Java Bluetooth, 2006. Disponivel em:
<http://www.jsr82.com>. Acesso em: 15 Outubro 2010.
Página 57 de 68

58. 11 BLUECOVE Project. BlueCove, 2004. Disponivel em:
<http://www.bluecove.org>. Acesso em: 12 Março 2010.
12 SANCHEZ, I. Introdução ao Desenvolvimento Orientado a Testes
(TDD). Coding Dojo Floripa, 2006. Disponivel em:
<http://dojofloripa.wordpress.com/2006/11/07/introducao-ao-desenvolvimento-
orientado-a-testes>. Acesso em: 26 Outubro 2010.
13 HENDRICKSON, E. Driven Development with Tests: ATDD and TDD.
Test Obsessed, 2008. Disponivel em: <http://testobsessed.com/wp-
content/uploads/2008/12/atddexample.pdf>. Acesso em: 3 Novembro 2010.
14 NADALETE, L. G. Capítulo 7: Teste Ágil, Como Implementar?
Conversando Sobre Teste de Software, 2010. Disponivel em:
<http://dftestes.gershon.info/index.php/Cap%C3%ADtulo_7:_Teste_%C3%A1gil,_co
mo_implementar%3F>. Acesso em: 3 Novembro 2010.
15 PEDROSO, B. Desenvolvimento Orientado a Testes, Conceitos
Básicos, Aplicação e Benefícios. Java Magazine, n. 82, p. 66-74, Agosto 2010.
16 SUN MICROSYSTEMS. NetBeans IDE. NetBeans, 200. Disponivel
em: <http://www.netbeans.org>. Acesso em: 12 Março 2010.
17 CAMARGO, D. JavaFree. JavaFree, 2003. Disponivel em:
<http://www.javafree.org>. Acesso em: 12 Março 2010.
18 MATTOS, É. T. Programação Java para Wireless. São Paulo:
Digerati Books, 2005. Capítulo 1 ao 6, onde é passada uma base para o
desenvolvimento de softwares usando a linguagem J2ME.
19 TANENBAUM, A. S. Redes de Computadores. Rio de Janeiro:
Elsevier, 2003. Capítulo 4 explica a Arquitetura, Aplicação e As Camadas do
Protocolo Bluetooth.
20 TAURION, C. Internet Móvel. 1ª Edição. ed. Rio de Janeiro: Campos,
2002. Capítulo 2 onde há uma introdução ao protocolo Bluetooth e o Capítulo 3,
onde são relacionadas as aplicações voltada para a Internet Móvel.
21 SCRIMGER, R. TCP/IP, A Bíblia. 7ª Edição. ed. Rio de Janeiro:
Elsevier, 2002. Capítulo 25 detalhe à Internet Sem Fio.
Página 58 de 68

59. 22 GLEIZER, G. D. A.; JUNIOR, A. D. L. E. S. J. Bluetooth - Camada
Física e Controle de Acesso ao Meio. GTA / UFRJ - Grupo de Teleinformática e
Automação, 2007. Disponivel em:
<http://www.gta.ufrj.br/grad/07_1/bluetooth/glossar.htm>. Acesso em: 22 Novembro
2010.
23 GLEIZER, G. D. A.; JUNIOR, A. D. L. E. S. J. Protocolo de Controle e
Adaptação de Enlace Lógico (L2CAP). GTA / UFRJ - Grupo de Teleinformática e
Automação, 2007. Disponivel em:
<http://www.gta.ufrj.br/grad/07_1/bluetooth/l2cap.htm>. Acesso em: 22 Novembro
2010.
24 WIKIPEDIA. OBEX. Wikipédia, 2010. Disponivel em:
<http://pt.wikipedia.org/wiki/OBEX>. Acesso em: 22 Novembro 2010.
Página 59 de 68

60. 7. ANEXOS
7.1. CÓDIGO-FONTE APLICAÇÃO SERVIDOR
7.1.1. Conteúdo do Arquivo Conexao.java
1 package serverfinal;
2
3 import java.io.*;
4 import java.text.DecimalFormat;
5 import javax.bluetooth.*;
6 import javax.microedition.io.*;
7
8 public class Conexao {
9 private int contador = 0;
10 private int contadorItem = 0;
11 private String mostraContador = "";
12 private String item = "";
13 private String mesa = "";
14 private String mesaA = "";
15 private String quantidade ="";
16 private double totalParcial = 0;
17 private double total = 0;
18 private LocalDevice local = null;
19 private StreamConnectionNotifier server = null;
20 private StreamConnection conn = null;
21 public final UUID uuid = new UUID("27012f0c68af4fbf8dbe6bbaf7aa432a",
false);
22 public final String name = "Echo Server";
23 public final String url = "btspp://localhost:" + uuid + ";name=" + name +
";authenticate=false;encrypt=false;";
24 private String[] itemsBar = {"", "Coca-Cola Lata", "Coca-Cola Light Lata", "Kuat
Lata", "Kuat Light Lata", "Fanta Laranja Lata", "X-Tudo", "X-Egg", "X-Salada", "X-
Burger", "Cachorro-Quente", "Misto Quente"};
25 private String[] itemsPreco = {"", "2,50", "2,50", "2,50", "2,50", "2,50", "9,90",
"8,00", "5,00", "5,50", "3,00", "3,00"};
26 private static DecimalFormat dff = (DecimalFormat)
DecimalFormat.getInstance();
27
28 public Conexao() {
29 try {
30 System.out.println("n------------------------------------------------------------------");
31 System.out.println("<><><>< Sistema Servidor P.V.B. ><><><>");
32 System.out.println("-------------------------------------------------------------------");
33 System.out.println("Habilitando dispositivo para ser descoberto...");
34 local = LocalDevice.getLocalDevice();
35 local.setDiscoverable(DiscoveryAgent.GIAC);
36 System.out.println("Dispositivo habilitado");
37 server = (StreamConnectionNotifier)Connector.open(url);
Página 60 de 68

61. 38 System.out.println("Aguardando por conexoes...");
39 System.out.println("-------------------------------------------------------------------");
40 conn = server.acceptAndOpen();
41 System.out.println("Cliente conectado");
42 System.out.println("Aguardando Pedido...n");
43
44 DataInputStream din = new DataInputStream(conn.openInputStream());
45
46 contadorItem = 0;
47 while(true){
48 String cmd = "";
49 char c;
50 while (((c = din.readChar()) > 0) && (c!='n') ){
51 cmd = cmd + c;
52 }
53
54 if ( !(cmd.equals("conta"))) {
55 mesa = "";
56 item = "";
57 quantidade = "";
58
59 contador = cmd.length();
60 for(int i = 0;i<contador;i++){
61 if (i < 2) {
62 mesa += cmd.substring(i,i+1);
63 }else {
64 if ((i > 2) && (i < 6)) {
65 item += cmd.substring(i,i+1);
66 }else{
67 if (i > 6) {
68 quantidade += cmd.substring(i,i+1);
69 }
70 }
71 }
72 }
73
74 contadorItem++;
75 if (contadorItem == 1){
76 System.out.println("----------------------------------------------------------------");
77 System.out.println("MESA: " + cmd.substring(0,2));
78 System.out.println("----------------------------------------------------------------");
79 System.out.println(" ITEM CODITEM DESCRICAO QTDE VALOR
UNITARIO TOTAL");
80 }
81
82 if (Integer.parseInt(item) <= 11){
83 totalParcial = Integer.parseInt(quantidade) * ((Double)
dff.parse(itemsPreco[Integer.parseInt(item)].toString()).doubleValue());
84 total += totalParcial;
85
Página 61 de 68

62. 86 if (contadorItem < 10){
87 mostraContador = "0" + String.valueOf(contadorItem);
88 } else {
89 mostraContador = String.valueOf(contadorItem);
90 }
91 System.out.println(" " + mostraContador + " " + item + " " +
itemsBar[Integer.parseInt(item)].toString() + " " + quantidade + " R$ " +
itemsPreco[Integer.parseInt(item)].toString() + " R$ " + String.format("%.2f",
totalParcial));
92 } else{
93 System.out.println( "Item nao encontrado..");
94 }
95
96 }else {
97 System.out.println("-----------------------------------------------------------------");
98 System.out.println("Valor da conta: R$" + String.format("%.2f", total));
99 System.out.println("------------------------------------------------------------------");
100 }
101 }
102
103 } catch (Exception e) { System.out.println("Cliente desconectado...");}
104 }
105 }
7.1.2. Conteúdo do Arquivo Main.java
1 package serverfinal;
2
3 public class Main {
4
5 public static void main(String[] args) {
6 Conexao echoserver = new Conexao();
7 }
8}
7.2. CÓDIGO-FONTE APLICAÇÃO CLIENTE
7.2.1. Conteúdo do Arquivo EchoClient.java
1 import javax.microedition.midlet.*;
2 import javax.microedition.lcdui.*;
3 import javax.microedition.io.*;
4 import javax.bluetooth.*;
5 import java.io.*;
6
7 public class EchoClient extends MIDlet implements
CommandListener,DiscoveryListener {
8
9 List main_list,dev_list;
10 Command exit,ok;
11 TextBox cmd;
Página 62 de 68

63. 12 Display display;
13 java.util.Vector devices,services;
14 LocalDevice local;
15 DiscoveryAgent agent;
16 DataOutputStream dout;
17 int currentDevice = 0;
18 String qtde,mesa,item;
19
20 private Form form;
21 private TextField textField1;
22 private TextField textField;
23 private TextField textField2;
24 private Command okCommand;
25 private Command exitCommand;
26 private Command itemCommand;
27
28 public EchoClient() {
29 }
30 private void initialize() {
31 }
32 public void startMIDlet() {
33 switchDisplayable(null, getForm());
34 }
35 public void resumeMIDlet() {
36 }
37 public void switchDisplayable(Alert alert, Displayable nextDisplayable) {
38 Display display = getDisplay();
39 if (alert == null) {
40 display.setCurrent(nextDisplayable);
41 } else {
42 display.setCurrent(alert, nextDisplayable);
43 }
44 }
45 public Form getForm() {
46 if (form == null) {
48 form = new Form("Pedido", new Item[] { getTextField(), getTextField1(),
getTextField2() });
49 form.addCommand(getOkCommand());
50 form.addCommand(getExitCommand());
51 form.addCommand(getItemCommand());
52 form.setCommandListener(this);
53 }
54 return form;
55 }
56 public void commandAction(Command command, Displayable displayable) {
58 if (command == exit){
59 exitMIDlet();
60 }
61 if (command == List.SELECT_COMMAND){
62 if (displayable == main_list){
Página 63 de 68

64. 63 if (main_list.getSelectedIndex() >= 0){
64 FindDevices();
65 do_alert("Procurando dispositivos...", Alert.FOREVER);
66 }
67 }
68 if (displayable == dev_list){
69 StreamConnection conn = null;
70 ServiceRecord service = (ServiceRecord)
71 services.elementAt(dev_list.getSelectedIndex());
72 String url = service.getConnectionURL(
73 ServiceRecord.NOAUTHENTICATE_NOENCRYPT,
74 false);
75 try {
76 conn = (StreamConnection) Connector.open(url);
77 dout = new DataOutputStream(conn.openOutputStream());
78 switchDisplayable(null, getForm());
79
80 } catch (Exception e) {this.do_alert("Error Connecting" , 4000);}
81
82 }
83 }
84 if(command == ok){
85 }
86 if (displayable == form) {
87 if (command == exitCommand) {
88 exitMIDlet();
89 } else if (command == itemCommand) {
90 try{
91 dout.writeChars("contan");
92 dout.flush();
93 } catch (Exception e) {this.do_alert("Error sending data" , 4000);}
94 } else if (command == okCommand) {
95 try{
96
97 mesa = textField.getString();
98 item = textField1.getString();
99 qtde = textField2.getString();
100
101 if (mesa.length() == 1) {
102 mesa = "0"+mesa;
103 }
104
105 if (item.length() == 1) {
106 item = "00"+item;
107 } else{
108 if (item.length() == 2) {
109 item = "0"+item;
110 }
111 }
112 if( qtde.length() == 1) {
Página 64 de 68

65. 113 qtde = "0"+qtde;
114 }
115 dout.writeChars(mesa+":"+item+":"+qtde+"n");
116 dout.flush();
117
118 textField1.setString("");
119 textField2.setString("");
120
121 } catch (Exception e) {this.do_alert("Error sending data" , 4000);}
122 }
123 }
124 }
125 public TextField getTextField() {
126 if (textField == null) {
127 textField = new TextField("Mesa", null, 2, TextField.NUMERIC);
128 }
129 return textField;
130 }
131
132 public TextField getTextField1() {
133 if (textField1 == null) {
134 textField1 = new TextField("Item", null, 3, TextField.NUMERIC);
135 }
136 return textField1;
137 }
138 public TextField getTextField2() {
139 if (textField2 == null) {
140 textField2 = new TextField("Quantidade", null, 2, TextField.NUMERIC);
141 }
142 return textField2;
143 }
144 public Command getOkCommand() {
145 if (okCommand == null) {
146 okCommand = new Command("Ok", Command.OK, 0);
147 }
148 return okCommand;
149 }
150 public Command getExitCommand() {
151 if (exitCommand == null) {
152 exitCommand = new Command("Sair", Command.EXIT, 0);
153 }
154 return exitCommand;
155 }
156 public Command getItemCommand() {
157 if (itemCommand == null) {
158 itemCommand = new Command("Fechar Conta", Command.ITEM, 0);
159 }
160 return itemCommand;
161 }
162 public Display getDisplay () {
Página 65 de 68

66. 163 return Display.getDisplay(this);
164 }
165 switchDisplayable (null, null);
166 destroyApp(true);
167 notifyDestroyed();
168 }
169 public void startApp() {
170 main_list = new List("P.V.B.",Choice.IMPLICIT);
171 dev_list = new List("Selecione o Dispositivo",Choice.IMPLICIT);
172 cmd = new TextBox("Text to echo","",120,TextField.ANY);
173 exit = new Command("Sair",Command.EXIT,1);
174 ok = new Command("Send",Command.OK,1);
175 display = Display.getDisplay(this);
176
177 main_list.addCommand(exit);
178 main_list.setCommandListener(this);
179 dev_list.addCommand(exit);
180 dev_list.setCommandListener(this);
181 cmd.addCommand(ok);
182 cmd.setCommandListener(this);
183
184 main_list.append("Procurar Servidor",null);
185 display.setCurrent(main_list);
186 }
187 public void pauseApp() {}
188
189 public void FindDevices(){
190 try{
191 devices = new java.util.Vector();
193 LocalDevice local = LocalDevice.getLocalDevice();
194 DiscoveryAgent agent = local.getDiscoveryAgent();
195 agent.startInquiry(DiscoveryAgent.GIAC,this);
196 }catch(Exception e){this.do_alert("Erro ao iniciar busca" , 4000);}
197 }
198
199 public void FindServices(RemoteDevice device){
200 try{
201 UUID[] uuids = new UUID[1];
202 uuids[0] = new UUID("27012f0c68af4fbf8dbe6bbaf7aa432a",false);
203 local = LocalDevice.getLocalDevice();
204 agent = local.getDiscoveryAgent();
205 agent.searchServices(null,uuids,device,this);
206 }catch(Exception e){this.do_alert("Erro ao iniciar busca" , 4000);}
207 }
208 public void destroyApp(boolean unconditional) {}
209
210 public void deviceDiscovered(RemoteDevice remoteDevice, DeviceClass
deviceClass) {
211 devices.addElement(remoteDevice);
212 }
Página 66 de 68

67. 213
214 public void inquiryCompleted(int param) {
215 switch (param) {
216 case DiscoveryListener.INQUIRY_COMPLETED:
217 if (devices.size() > 0){
218 services = new java.util.Vector();
219 this.FindServices((RemoteDevice)
220 devices.elementAt(0)); 385 }else
221 do_alert("Nenhum dispositivo encontrado",4000);
222 break;
223 case DiscoveryListener.INQUIRY_ERROR:
224 this.do_alert("Erro na busca" , 4000);
225 break;
226 case DiscoveryListener.INQUIRY_TERMINATED: 392
this.do_alert("Busca cancelada" , 4000);
227 break;
228 }
229 }
230
231 public void serviceSearchCompleted(int transID, int respCode) {
232 switch(respCode) {
233 case DiscoveryListener.SERVICE_SEARCH_COMPLETED:
234 if(currentDevice == devices.size() -1){
235 if(services.size() > 0){
236 display.setCurrent(dev_list);
237 } else
238 do_alert("O serviço não foi encontrado",4000);
239 } else{
240 currentDevice++;
241 this.FindServices((RemoteDevice)devices.elementAt(currentDevice));
242 }
243 break;
244 case DiscoveryListener.SERVICE_SEARCH_DEVICE_NOT_REACHABLE:
245 this.do_alert("Dispositivo não alcançável" , 4000);
246 break;
247 case DiscoveryListener.SERVICE_SEARCH_ERROR:
248 this.do_alert("Erro na busca" , 4000);
249 break;
250 case DiscoveryListener.SERVICE_SEARCH_NO_RECORDS:
251 this.do_alert("Nenhum registro encontrado" , 4000);
252 break;
253 case DiscoveryListener.SERVICE_SEARCH_TERMINATED:
254 this.do_alert("Busca cancelada" , 4000);
255 break;
256 }
257 }
258
259 public void servicesDiscovered(int i, ServiceRecord[] serviceRecord) {
260 for (int x = 0; x < serviceRecord.length; x++ )
261 services.addElement(serviceRecord[x]);
Página 67 de 68

68. 262 try{
263 dev_list.append(((RemoteDevice)devices.elementAt(currentDevice)).
264 getFriendlyName(false),null);
265 }catch(Exception e){this.do_alert("Erro ao iniciar a pesquisa" , 4000);}
266 }
267
268 public void do_alert(String msg,int time_out){
269 if (display.getCurrent() instanceof Alert ){
270 ((Alert)display.getCurrent()).setString(msg);
271 ((Alert)display.getCurrent()).setTimeout(time_out);
272 }else{
273 Alert alert = new Alert("Bluetooth");
274 alert.setString(msg);
275 alert.setTimeout(time_out);
276 display.setCurrent(alert);
277 }
278 }
279 }
Página 68 de 68