Uma das melhores partes de desenvolver aplicações em J2ME é a possibilidade de criar aplicativos multi-usuário para ambientes portáteis. A idéia de se comunicar em qualquer momento e em qualquer lugar sempre foi muito atraente tanto para os desenvolvedores quanto para os usuários. Hoje em dia, as aplicações para ambiente móvel de mais sucesso são aquelas que apresentam essa característica. Como vêm sendo dito nos artigos publicados pelo grupo Inova Mobile para a Web Mobile, a palavra chave para esse sucesso é interatividade.
Baseado no artigo “Bluetooth: da teoria à prática – O mundo sem cabos” escrito por nossos colegas de Manaus, publicado na terceira edição da Web Mobile, iremos explorar o conceito de interatividade, através do desenvolvimento de um jogo multi-usuário para dispositivos J2ME/MIDP usando Bluetooth. Utilizaremos um jogo simples, o jogo da velha, para dar uma introdução à API Bluetooth (JSR-82) e a alguns conceitos básicos sobre essa tecnologia. Além disso, serão levantadas várias questões e dificuldades para se desenvolver esse tipo aplicação em Java.
Dando continuidade à série, não deixe de acompanhar o próximo artigo, em que será abordado como se construir interfaces gráficas para aplicações MIDP.
Um pouco sobre Bluetooth
Como foi dito no artigo da edição anterior, o Bluetooth é uma tecnologia de rede sem fio com o intuito de criação de redes temporárias de no máximo oito participantes (chamadas de wireless personal area networks, ou simplesmente WPANs) e capaz de transmitir dados e até mesmo voz. Tem um alcance que pode chegar a
Essas características tornam o Bluetooth uma tecnologia com espaço garantido e com um nicho de mercado muito bem definido. Mesmo assim, muitos ainda insistem em comparar o Bluetooth a outras tecnologias de transmissão aérea como o infravermelho e principalmente o Wi-Fi. O infravermelho é uma forma simples, rápida e restrita de se de fazer comunicação entre apenas dois dispositivos e requer que ambos estejam muito próximos e em visada direta. O Wi-Fi é uma tecnologia de rede sem fio cujo propósito é a interconexão de PC’s de uma mesma WLAN (Wireless Local Area Network). Tecnicamente falando, as WLANs diferem das WPANs nos seguintes aspectos:
· ciclo de vida: as WPANs tendem a ter ciclo de vida muito curto enquanto as WLANs podem ter um ciclo indefinido;
· controle de acesso ao meio: os protocolos de múltiplo acesso e as modulações diferem. Só por curiosidade, as WPANs usam uma técnica de múltiplo acesso chamada de frequency hopping ou saltos em freqüência, enquanto as WLANs utilizam técnicas como collision detection e collision avoidance. As redes metropolitanas WMAN, que utilizam a tecnologia Wi-Max, farão uso da mais nova técnica de múltiplo acesso chamada de OFDMA (Orthogonal Frequency Division Multiple Access). Bem, mas isso é só curiosidade;
· controle de potência e à cobertura: as redes WPAN são constituídas de dispositivos com restrições de potência, portanto têm uma cobertura que pode chegar a 10% da cobertura total de uma WLAN. De fato, há classes de dispositivos Bluetooth que têm um alcance de até
O Bluetooth, portanto, tem o intuito de prover uma comunicação rápida e barata, na maioria das vezes, entre dispositivos portáteis e aparelhos celulares. Nada impede, no entanto, que ele seja usado para conectar PC’s.
Para entendermos melhor os seus propósitos, vamos discutir um pouco sobre a pilha de protocolos da especificação Bluetooth, mostrada na Figura 1.
Figura 1. Pilha de protocolos Bluetooth.
Protocolos Bluetooth
Dos protocolos que constituem a pilha de protocolos Bluetooth, alguns são específicos, como SDP, L2CAP e LMP, e outros são adotados de outras tecnologias, como é o caso do IP, UDP, TCP, PPP, RFCOMM, OBEX, etc. De todos eles, somente alguns são relevantes para os nossos objetivos: L2CAP, RFCOMM, OBEX e SDP (destacados na Figura 1), que são os protocolos usados de forma direta pela API Bluetooth.
· O L2CAP (Logical Link Control and Adaptation Protocol) representa uma interface entre os protocolos adotados e os protocolos específicos do Bluetooth. Ele é responsável por multiplexar, segmentar em pacotes e reorganizar os dados vindos das camadas superiores.
· Acima do L2CAP está o RFCOMM (Radio Frequency COMMunication), protocolo que emula a interface serial RS-232. Ele proporciona compatibilidade aos serviços das camadas superiores que usam esse tipo de interface.
· O protocolo OBEX (OBject EXchange) executa transferências de objetos, que podem ser entendidos como arquivos, dados da agenda telefônica ou simplesmente bytes. É possível a um cliente OBEX fazer um GET ou um PUT de objetos no servidor.
· O SDP (Service Discovery Protocol), diferente dos três descritos anteriormente, é um protocolo usado para obter informações sobre dispositivos próximos, como serviços disponíveis, nome e endereço Bluetooth. É por meio desse protocolo que iremos procurar pelos dispositivos que estão prestando o serviço de jogo da velha. Mais adiante, veremos como funciona todo esse processo.
Existe um grupo de pessoas (comunidade) responsável pelo Bluetooth, denominado SIG (Grupo de Interesses Especiais – acesse http://www.bluetooth.org/ para saber mais). O SIG, além de definir os protocolos, foi ainda mais longe, padronizou algumas aplicações ou procedimentos especiais que utilizam determinados protocolos, os quais são chamados de profiles. A Figura 2 mostra alguns dos profiles da versão 1.1 da especificação Bluetooth.
Figura 2. Alguns profiles da versão 1.1 do Bluetooth.
A figura tem o objetivo de mostrar a relação de dependência entre os profiles, de maneira que cada um deles depende da caixa (profile) que o contém. Vamos às funcionalidades de alguns deles:
· Generic Access Profile: é o profile mais global. Todos os demais dependem dele para realizar operações de estabelecimento de conexão;
· Serial Port Profile: interage com o RFCOMM e simula uma porta serial no dispositivo;
· Service Discovery Application Profile: está relacionado com o protocolo SDP e realiza buscas por serviços em dispositivos remotos;
· Dial-up Networking: permite ao dispositivo Bluetooth adquirir a funcionalidade de um modem;
· Fax Profile: permite que um dispositivo se conecte a um aparelho de fax via Bluetooth;
· Headset Profile: um terminal que suporta esse profile, por exemplo, é capaz de se conectar a um fone de ouvido. Um outro exemplo seria o do automóvel Fiat Stilo, que pode se comunicar a um celular, receber e enviar voz via Bluetooth;
· LAN Access Profile: dispositivos com esse profile poderiam se conectar a access points ligados a redes locais.
· Generic Object Exchange Profile: necessário a todos os profiles que utilizam o protocolo OBEX, como File Transfer, Objetc Push e Synchronization;
· Cordless Phone: permite que seu terminal Bluetooth substitua seu telefone sem-fio (que também deve suportar esse profile). Assim, quando você estiver em casa, é possível atender às chamadas locais do seu celular, pois ele consegue se comunicar com a base do telefone sem fio. Baseia-se no protocolo TCS – BIN para gerenciamento de aplicações que lidam com áudio;
· Intercom Profile: permite que dois dispositivos se comuniquem como se fossem intercomunicadores. É claro, que devem estar a uma distância menor que a distância máxima determinada pela classe do dispositivo.
Para você que já estava pensando em várias idéias de aplicações que podem ser construídas utilizando esses profiles, vá com calma. Nem todos eles são suportados pelos terminais. Obviamente, o fato de um profile ser ou não suportado depende de qual é a finalidade do dispositivo.
De fato, a pergunta que se deve responder aqui é: o que pode ser feito com J2ME? Temos acesso a todos os profiles e protocolos oferecidos pelo dispositivo? Vamos agora tentar responder a essas perguntas.
Bluetooth e Java
Pelo fato de Java ser uma linguagem que depende de uma máquina virtual, existem algumas restrições em se desenvolver nesta plataforma. Não se tem acesso às mesmas facilidades e funcionalidades de uma linguagem nativa, pois ficamos presos ao que a JVM oferece. Quando se trata de desenvolvimento para dispositivos móveis, essas restrições são muito maiores (ler Nota 1). No caso do Bluetooth, se optarmos por desenvolver um aplicativo para um série 60 em Java, perderemos acesso a vários profiles e protocolos, dos quais poderíamos usufruir se tivéssemos optado pelo Symbian (ler Nota 2). Atualmente em J2ME, só é possível utilizar os protocolos SDP, L2CAP e RFCOMM. Há inclusive protocolos que são contemplados pela API Bluetooth e que não são implementados pelos fabricantes de dispositivos, como é o caso do OBEX. Toda a parte da API referente a esse protocolo ainda não pode ser usada.
Nota 1. O J2ME é multi-plataforma?
Write Once Run Anywhere (Escrever uma vez e executar em qualquer lugar!), esse é o lema do Java. Essa é a característica fundamental da tecnologia e merece um pouco de reflexão quando se trata de J2ME. Quando se trabalha com desenvolvimento em J2ME, não se tem acesso à agenda telefônica, ao nível da bateria, à potência do sinal, ao simcard, ao sistema de arquivos, não é possível utilizar a tela inteira para se desenvolver um jogo, não é possível interceptar chamadas, não é possível trabalhar com voz (pelas restrições de performance), há limites quanto ao tamanho da aplicação, não é possível fazer a bateria vibrar, não é possível fazer a luz acender, etc.
Devido a essas limitações, alguns fabricantes (como Nokia e Sony Ericsson) criam API’s proprietárias para que o desenvolvedor possa ter acesso a alguns features fundamentais para a criação de aplicações com algum apelo comercial. Por exemplo, os códigos correspondentes aos artigos do grupo Inova Mobile produzidos para essa revista, foram todos escritos estritamente para celulares Nokia série 60. Recebi vários e-mails de pessoas dizendo que não estavam conseguindo instalar o Mobile Invaders (leia as edições 1, 2 ou 3 da Web Mobile) em celulares de outra marca. Outros também tentaram instalar sem sucesso
É claro que o programador quer explorar a maior quantidade possível de recursos para a sua aplicação e para isso, ele recorre às API’s dos fabricantes. Será que, como resultado, esse programador irá obter um software multi-plataforma? Será possível usá-lo em celulares de outra marca, ou até mesmo da mesma marca, mas em modelos diferentes? Creio que não.
O objetivo do Java é que um código escrito para o celular mais simples rode, sem alterações, em um celular mais sofisticado. O preço que se paga para isso, no entanto, é muito caro. Esse código deve ser nivelado por baixo para que ele possa ser compatível com o primeiro aparelho. E o aparelho mais moderno? Ficará subutilizado? Se eu tenho um aparelho com vários recursos como display 208 x 176, infra-vermelho, bateria que vibra e câmera, por que não utilizá-los???
Apesar de tudo, Java tem a grande vantagem de ser conduzido por uma comunidade. Os programadores Java têm o grande benefício da padronização. Não há, por exemplo, uma API Bluetooth para os celulares Nokia, outra API para os Sony Ericsson, outra para os Motorola, etc. Se você sabe utilizar a JSR-82, você sabe programar para qualquer dispositivo que a implemente. Nesse ponto o J2ME é multi-plataforma.
...
