Utilizao da Linguagem de Programao J2ME para a interao de dispositivos

mveis via Bluetooth

Rodrigo Celso Gobbi, Bernardo Copstein
Faculdade de Informtica Pontifcia Universidade Catlica do Rio Grande do Sul
Av. Ipiranga, 6681 Prdio 32 Porto Alegre RS Brasil
rodrigo.gobbi.7@gmail.com, bernardo.copstein@pucrs.br

Abstract: This report presents a description and analysis of the study on Bluetooth
technology and its application in daily life through a programming language. Explore the
potencial of Java Micro Edition regarding the development of applications on mobile
devices exploiting this new type of wireless communication.
Resumo: Este relatrio apresenta a descrio e a anlise do estudo sobre a tecnologia
Bluetooth e sua aplicao no cotidiano atravs de uma linguagem de programao.
Explora o potencial Java Micro Edition no que se refere ao desenvolvimento de aplicaes
em dispositivos mveis explorando este novo tipo de comunicao sem fio.
1. Introduo
Com o avano da tecnologia em diversas reas da informtica nos ltimos anos, a
demanda por comunicao sem fio cresceu consideravelmente. Essas comunicaes sem
fio, mais conhecidas como Wireless, surgiram para facilitar a implementao de redes,
comunicao entre quaisquer dispositivos, dispensando o uso de fios em determinadas
circunstncias, provendo maior conforto ao usurio final. Projetos que anteriormente eram
viveis, mas que acabavam se tornando o oposto devido ao potencial restrito das outras
comunicaes, estas, exigiam um enorme esforo para grandes e audaciosas
implementaes. Agora com esta inovao, as redes Wireless favorecem a maioria dos
projetos devido a sua praticidade.
Criado pela Ericsson por volta de 1994, o Bluetooth inicialmente buscava resolver
os problemas de comunicao de um fone de ouvido sem fio para celulares, fone
popularmente conhecido como HeadSet. Foi desenvolvido pela prpria empresa e tinha
como objetivo facilitar o uso de seus celulares no dia-a-dia de seus clientes e at mesmo no
trnsito. Falhou em todos os aspectos justamente por utilizar muitos fios, contradizendo a
idia inicial do projeto. Portanto, dois engenheiros encarregados pela rea de pesquisa e
inovao da empresa, reavaliaram e com investimentos da empresa, desenvolveram ento a
famosa tecnologia Bluetooth, que uma das comunicaes sem fios atuais, que dispensa o
uso de qualquer fio.
Perceberam tambm, que seria importante abrir a tecnologia, unindo outros grandes
fabricantes (Nokia, Ericsson, Motorola, etc.) em torno de um padro, caso contrrio a
tecnologia estaria patenteada e sua utilizao no seria em grande escala. Em 1998 ocorreu,
ento, a documentao e o licenciamento gratuito da tecnologia, fazendo com que outras
empresas adotassem o Bluetooth, estimulando o desenvolvimento da mesma.

2.0. Referencial Terico

Nas seguintes sees sero descritos todos os termos tcnicos e conceitos que sero
a base para a compreenso dos dois contedos estudados no decorrer do projeto.
2.1. Bluetooth e sua Topologia
O Bluetooth nada mais do que um chip comum de rdio, que integrado em
diversos dispositivos e aparelhos eletrnicos. Por serem chips de rdio, operam em uma
determinada freqncia - 2.4 GHz. Esta freqncia possui uma largura de 79 canais de 1
MHz, e conhecida pela sigla ISM - Industrial, Scientific and Medical - sua utilizao
gratuita para qualquer fim sendo assim, utilizada por diversos outros aparelhos e
dispositivos (que utilizam este tipo de transmisso).
Como o Bluetooth opera na mesma freqncia que outros dispositivos, uma questo
em relao a garantia de envio de dados/informaes surgem na maioria dos usurios.
Devido ao fato, dos dispositivos que estabelecem uma conexo via Bluetooth estarem na
mesma freqncia que outros diversos aparelhos, existe uma pequena possibilidade que os
dados enviados se colidam com os outros demais. Mas o que acontece na verdade,
exatamente o contrrio, a implementao da comunicao faz com que o dispositivo Master
salte para outra freqncia, sincronizando o restante de Slaves, antes de sofrer a possvel
coliso.
Sua interao pode ser feita entre qualquer dispositivo(s) eletrnico(s), desde que
este(s) possua o chip. Aparelhos como PDAs, celulares, desktops e at mesmo notebooks
j fazem parte do mercado dos dispositivos que vm com o seu chip integrado a seu
hardware.
No momento em que algum dispositivo conectado a uma rede Bluetooth, este
pode ser classificado de acordo com a sua topologia. Esta pode ser caracterizada de duas
maneiras: Piconet e Scaternett (nomes reservados para diferentes situaes). Quando se
dispe de um dispositivo ligado a outro qualquer, temos o Piconet, uma arquitetura mais
simples onde existe uma limitao quanto ao nmero de dispositivos que podem formar
esta topologia. Estes assumem um papel de Master ou Slave (Mestre ou Escravo), sendo o
mestre o dispositivo que coordena e orienta instrues/comandos aos seus respectivos
escravos, que por sua vez apenas executam essas instrues. Esta informao para o usurio
final no de grande importncia, mas ela estabelecida da seguinte forma: o primeiro
dispositivo a encontrar outro acaba tornando-se o Master, sendo o restante Slaves. A
definio da tecnologia permite que o dispositivo Slave faa uma requisio a seu Master
para acontecer uma troca, onde o slave torna-se Master e o Master torna-se Slave. A
limitao em nmero de dispositivos de no mximo oito ligados entre si, o que minimiza
o potencial da tecnologia, pois determina um nmero mximo para a implementao do
projeto. No Piconet (ver Figura 1) existe apenas um Master, independente do nmero total
de dispositivos da rede estabelecida.

Figura 1 Piconets
Como este nmero extremamente pequeno comparado com a enorme demanda de
atividades que podem ser realizadas, existe o Scatternet que a tcnica que permite
sobrepor vrios Piconets, aumentando os pontos de comunicao. O limite mximo de
sobreposies dez (ver Figura 2). Neste caso, as sobreposies fazem com que a rede
estabelecida possua mais do que um Master. Sendo assim, as instrues e comandos de
todos os Masters, sero executadas de maneira sincronizada atravs de algoritmos
implementados na prpria descrio da comunicao.

Figura 2 - Scatternets
3. Anlise comparativa: Wireless x Bluetooth
Em funo de sua arquitetura, o Bluetooth possui alguns aspectos vantajosos em
relao ao seu desempenho quando comparado a outros modelos de rede Wireless. Sua
limitao em relao a grandes LANs se reduz devido ao fato de no poder sustentar tantos
dispositivos. Outro aspecto diz respeito a velocidade que pode atingir no mximo 721
Kbps. Seu alcance extremamente limitado, segundo trs classificaes: 100m, 10m, 1m
definidas por um nmero de 48 bits.
Em contra partida, seu uso se justifica pelo seu baixo custo e grande capacidade de
adaptao. Caso o usurio necessitar de um desempenho maior, o Bluetooth quando

combinado a outras tecnologias (utilizando Hubs, Gateways, etc.) obtm um desempenho

maior do que quanto utilizada sem o auxlio destes.
4. Java Micro Edition
Das diversas subdivises da plataforma Java, existe Java Micro Edition (J2ME)
esta, possui um grande espao no mercado devido a seu uso ser extremamente popular no
quesito de desenvolvimento de aplicaes mveis. A linguagem suporta o paradigma
orientado objetos, existindo um tratamento especial a classes e mtodos j definidos. A
linguagem compilada por uma mquina virtual, a KVM (Kilo Virtual Machine), uma nova
implementao da mquina virtual otimizada para o uso em dispositivos de recursos
limitados. Esta mquina virtual aceita o mesmo conjunto de bytecodes e o mesmo formato
para o ficheiro .class que a mquina virtual clssica aceita. Desenvolvida na linguagem C,
pode ser facilmente portada para plataformas onde um compilador da prpria linguagem
esteja disponvel. O programador de dispositivos mveis necessita compreender alguns
termos tcnicos tais como Configurations, Profiles e algumas APIs necessrias para o
entendimento completo da linguagem, podendo assim, desenvolver alguma aplicao.
Para saber das limitaes dos dispositivos que sero alvo para o desenvolvimento da
aplicao, o programador deve adquirir informaes sobre as configuraes em nvel
arquitetural em termos de hardware. Devido a esta necessidade, foi criado o termo
Configurations (CLDC e CDC), que define e caracteriza o dispositivo em relao
limitao de memria, quantidade de memria usada pela mquina virtual, etc. A
Connected Limited Device Configuration (CLDC) normalmente a mais utilizada tanto em
PDAs (gama baixa), celulares, pagers, etc. Ela possui 128 Kbytes para executar a KVM,
32 Kbytes para alocao de memria e possui uma interface restrita, ou seja, a interface
extremamente reduzida quando comparada com um desktop em relao as suas limitaes
fsicas.
A Connected Device Configuration encontrada em dispositivos que normalmente
no so alvo de desenvolvimento de pequenas aplicaes tais como, PDAs (gama alta),
Set-top boxes , gateways , TVs, etc. Possui um mnimo de 512 Kbytes para executar a
KVM, 256 Kbytes para a alocao de memria.
Alm das Configurations, existem as Profiles (Classe MIDP Mobile Information
Profile), uma API com vrias funes definidas para uma famlia de dispositivos. Estes
profiles so implementados sobre uma determinada Configuration. Por se tratar de um API
que possui diversas funes, ela possui duas verses: a MIDP 1.0 e a MIDP 2.0.
4.1. Diferenas entre MIDP 1.0 e 2.0
Existem algumas diferenas entre as verses, alm do acrscimo de alguns mtodos,
e maiores facilidades na verso 2.0 como classes para jogos e tratamento de sons, temos a
diferena na comunicao de dados. No MIDP 1.0, as conexes so feitas atravs do
protocolo http que inseguro no envio de informaes. Na verso atualizada (MIDP 2.0)
est implementado o https (ssl), conexo que utiliza criptografia. A seguir, sero listados
todos os Packages disponveis para a classe MIDP.
java.lang
java.lang.ref (somente verso 1.0)

 java.io
java.util
javax.microedition.io
javax.microedition.lcdui
javax.microedition.lcdui.game (somente na verso 2.0)
javax.microedition.media (somente na verso 2.0)
javax.microedition.media.control (somente na verso 2.0)
javax.microedtition.midlet
javax.microedition.rms
javax.microedition.pki (somente na verso 2.0)
4.2. Segurana
Normalmente surgem dvidas quando o assunto a segurana dos dispositivos. J
que programas estaro rodando no dispositivo, porque os desenvolvedores no tero
problemas com vrus, ou programas maliciosos? A resposta no, pois o J2ME no tem
acesso a API do celular em si, ou seja, no possvel acessar funes especficas do celular
como, por exemplo, a agenda telefnica, sendo assim, no podero ser apagados ou
modificados qualquer tipo de dados do usurio, a no ser que o fabricante disponibilize
uma API especfica, como o caso dos jogos nos celulares, onde cada fabricante
disponibiliza uma API que possa aproveitar melhor o mximo desempenho do aparelho. A
mquina virtual tem um espao independente de memria, e no pode acessar a memria
correspondente s aplicaes nativas do celular.
Outro ponto importante que no permitida a carga de classes definidas pelo
usurio, ou seja, o usurio no tem acesso a outras funes que no seja as da KVM,o que
aumenta a segurana, porm restringe um pouco o desenvolvimento.
5. Criando projetos, Compilando e Executando
O programador possui uma sria de opes quanto escolha da ferramenta que
servir de auxlio no desenvolvimento do projeto(s). Dentre as divesas e as mais conhecidas
IDEs, foi escolhido para este projeto, o Eclipse. Nesse, a programao se torna mais fcil
e rpida, evitando erros de sintaxe que origina erros na compilao.
Para usufruir destas funcionalidades, o usurio necessita fazer algumas atualizaes,
como o plugin EclipseME, disponibilizado de maneira gratuita no site da Sun.Aps o
download, basta descompactar todos os ficheiros para o folder Eclipse/plugins. Alm disso,
o Wireless Toolkit deve ser instalado para a aplicao ser emulada e testada, bastando
realizar alguns ajustes (ver Figura 3). As diversas verses deste kit trazem algumas
atualizaes, como acrscimo de bibliotecas grficas, verses aprimoradas dos termos
CLDC e at mesmo outros skins de dispositivos. Portanto, para o desenvolvimento de uma
pequena aplicao, no necessrio a ltima ou a melhor verso. Uma verso que exija
menos desempenho do computador usado ser to eficiente na hora da simulao quanto
uma verso mais aprimorada.

Figura 3 Acrescentando Emulador ao Eclipse

6. Introduo ao Ciclo de Vida de uma MIDlet
Uma MIDlet uma classe que une as duas principais definies: Configurations e
Profiles. Todas as aplicaes que sero desenvolvidas pelo programador utilizaro herana
simples, onde estas herdaro todos os mtodos e funes necessrias da classe MIDP
(Superclasse). Aps a aplicao ser compilada ela emulada atravs do kit de simulao e
testada em skins idnticos a modelos de celulares. Caso o desenvolvedor optar por verificar
o seu funcionamento em um aparelho fsico, ele dever enviar de alguma maneira o .jar da
aplicao ao dispositivo, seja por Bluetooth, USB ou outro mtodo.
Sendo assim, cada dispositivo deve possuir algum sistema ou implementao que
controle a aplicao. Este sistema chamado AMS (Aplication Manager System) que
responsvel por controlar os aplicativos que sero instalados e tambm administrar como
sero armazenados e como ser o seu comportamento durante a execuo. Uma coisa que
deve ser ressaltada a importncia do arquivo .JAD que vem acompanhado com o arquivo
.JAR (arquivo nico que agrupa diversos outros (.class, .html, ou at mesmo arquivos de
udio) tornando-o um arquivo executvel. No .JAD esto todas as informaes que o .JAR
precisa para executar a MIDlet no terminal mvel.
7. Ciclo de vida de uma MIDlet
O Aplication Manager System (AMS) de cada dispositivo quem vai controlar os
aplicativos a serem instalados, onde e como sero armazenados e como sero executados.
As classes de cada aplicativo esto em um arquivo .JAR, o qual vem acompanhado de um
descritor JAD, que ter todas as informaes as quais j vimos anteriormente. Assim que a

MIDlet invocada, o AM invoca o mtodo startApp(), o qual coloca a MIDlet no estado

Active.
Enquanto ela estiver executando, o AMS pode pausar ela invocando o mtodo
pauseApp(), no caso de uma chamada sendo recebida, ou um SMS chegando. A aplicao
pode pausar a si mesma, bastando invocar notifyPaused(). Assim como a AMS pode pausar
a aplicao e esta a si mesma, ocorre o mesmo com o destroyApp() que invocado pela
AMS para fechar a aplicao ou at mesmo pode ser fechada atravs da prpria aplicao
invocando o notifyDestroyed(). (ver Figura 3)

Figura 3 - Estados de uma MIDlet

8. Interface
As MIDlets podem ser executadas em qualquer dispositivo sem nenhuma alterao,
porm isso torna-se bastante difcil na parte de Interface com usurio, pois certos
dispositivos variam em caractersticas fsicas como tamanho de tela, cores, teclados, touchscreens, etc. As aplicaes so desenvolvidas com certa abstrao de tela, pois os comandos
e a insero de dados so feitos atravs dos botes do celular, e isto no sabemos
previamente devido diversidade dos dispositivos. As aplicaes descobrem estes aspectos
em tempo de execuo, se comportando de maneira apropriada a cada celular.
No desenvolvimento de jogos a aplicao bem mais especfica, pois o
desenvolvedor precisa conhecer o dispositivo previamente para ter um maior desempenho
de seus recursos.
A tela do dispositivo independentemente de seu modelo e fabricante representada
por uma instncia da classe Display, a qual obtida pelo mtodo getDisplay(), geralmente
contida no mtodo startApp(), pois o mtodo getDisplay(), somente fica disponvel aps o
incio da Aplicao (startApp()). A seguir, temos uma instanciao de Display, onde no
futuro sero inseridas heranas de Displayable (ver Figura 4).

Na tela so mostrados componentes, objetos j instanciados, os quais so chamados

pelo mtodo setCurrent(), este seta o objeto que ser mostrado no display. O ciclo bsico
de uma MIDlet pode ser definido da seguinte maneira:
Mostrar um Displayable;
Esperar por Ao do Usurio;
Decidir qual Displayable mostrar em seguida;
Repetir algumas destas aes;
As aes do usurio so gerenciadas por commands, os quais so adicionados a
componentes visuais. Estes componentes pertencem classe Displayable, esta se divide em
Screen e Canvas que se subdividem em duas APIs reservadas:
High-level API's: engloba a classe Screen e suas heranas. So classificados como
objetos de Interface.
Low-level API's: engloba a classe Canvas e suas heranas, as quais proporcionam
uma rea livre para grficos.
A seguir sero descritos de maneira breve, a maioria dos itens grficos que a
linguagem oferece, em seguida, ser descrito quais foram utilizados na elaborao da
ferramenta.

Figura 4 Objetos de interface

8.1. Commands

Os commands como vimos, so usados para interao do usurio com a aplicao.

Sua aplicao bsica na troca de Displayables, os quais so acionados por elementos reais
do dispositivo que podem ser: softkeys, itens de menu, botes e dispositivos de
acionamento. Esses commands so entidades abstratas e podem ser adicionados
arbitrariamente para cada elemento da classe Screen ou Canvas.
Os commands possuem trs parmetros (ver Figura 5) como mostra o formato de
seu construtor:

Figura 5 Instncia de Command

Label: texto mostrado ao usurio na interface;
Type: tipo do comando;
Priority: prioridade dos comandos que so utilizados para mostrar os comandos mais
utilizados com maior facilidade.
A seguir a instanciao de um objeto Command com os parmetros devidamente
preenchidos.

Os commands so geralmente relacionados a SoftKeys ou SoftButtons, que so

botes existentes nos celulares os quais so usados para menus, e navegao em geral, sem
uma funo nica. Geralmente celulares possuem apenas dois botes de SoftKeys, porm
isso no significa que voc precisa ter apenas dois commands sendo implementados, pois se
houver mais commands que botes, eles so agrupados e aberto um menu. Para isso que
serve a priority setada nos botes, ou seja, a prioridade zero (mais prioritrio) indica que
esse command deve ser mostrado nas softKeys, ou em primeiro lugar no menu.
As aes dos commands so totalmente dependentes do cdigo, ou seja, voc ter
que implementar a ao de cada command selecionado, os quais ficaro dentro de um
mtodo chamado commandAction, que vem como herana quando a MIDlet herda
CommandListener. Observe (ver Figura 6) que necessrio que a classe principal
implemente a interface CommandListener. Sendo assim, o mtodo CommandAction j
estar disponvel para o tratamento dos Commands.

Figura 6 Implementing CommandListener

O tratamento dos commands feito com o conceito de Listeners, ou seja, comandos
so adicionados a Displayables, cada displayable pode possuir um CommandListener o
qual invocado assim que um command acionado. Abaixo segue o construtor:

Figura 6 setCommandListener

- Mtodo CommandAction
Como o ciclo bsico de uma aplicao se limita as quatro etapas declaradas
anteriormente, necessitamos que a nossa classe principal implemente a interface
CommandListener, explicada anteriormente. O nico mtodo que esta interface possui o
declarado a seguir:

Sua nica funo tratar as decises de usurios feitas pelos Commands.

8.2. TextBox

 um componente bsico que serve para entrada de texto(string) em celulares. O

construtor de um textBox :

Onde os seus parmetros so definidos abaixo:

title: uma string mostrada no topo da tela.
text: mostrado dentro do textbox, como string inicial.
maxsize: tamanho mximo que ser alcanado pelo textBox.
constraints: so as constantes da classe TextField, as quais veremos logo abaixo.
A seguir descrito um exemplo de TextBox, usando a constraint TextField.ANY, ou
seja, os dados que sero escritos podem conter um contedo qualquer.

Alm dessas constantes, pertencem a classe TextField (EMAILADDR, NUMERIC,

PHONENUMBER,URL). Onde os seus nomes so sugestivos, o campo poder aceitar
apenas uma string de email, nmeros ou at mesmo uma URL.
8.3. Tickers
Ticker nada mais que um texto que corre no topo da tela, semelhante as tickers de
mercados de aes, e semelhante ao <marquee> de html. O recurso de Ticker serve para
algum texto informativo que possa ser importante, lembrando o usurio a todo momento ou
algo de enfeite que voc queira colocar. Mas lembre-se, a tela do celular j pequena para
sua aplicao, e o ticker tomara mais uma linha para si, a qual no poder ser usada. Sua
criao simples. A seguir, verifique o construtor do objeto Ticker seguido de um exemplo.

Os mtodos para manuseio so os seguintes:

public void setTicker(Ticker ticker)
public Ticker getTicker();
Ambos so muito simples de utilizar. O setTicker adiciona um objeto ticker a algum
objeto da classe displayable.
8.4. Forms
Form uma herana de Screen e Displayable, a qual pode conter um nmero
arbitrrio de controles de interface chamados Itens. Ele serve para poder-se colocar mais de
um componente na tela. Apesar de haver rolagem automtica quando todos os objetos no
cabem na tela, o programador deve cuidar para no deixar um Form muito grande com
muitos componentes, pois a rolagem dos Forms tende a ser confusa nos dispositivos, pois
cada um implementa isso da sua maneira, e por isso no deve se tornar uma prtica
corriqueira, alm de tornar seu aplicativo esteticamente mal feito, pois o usurio muitas
vezes no ir saber se h mais objetos a serem preenchidos.
Para criarmos um Form temos duas sobrecargas:
public Form(String Titulo);
public Form(String Titulo, Item[] itens);
Como vimos os Forms recebem itens os quais so divididos em diversos tipos cada
um com sua finalidade. Os itens podem ser adicionados e removidos mesmo com os
Forms sendo mostrados. Os mtodos de trabalho com os Forms so:
append(Item item);
set(int Indice, Item item);
insert(int Indice, Item item);
delete(int Indice);
Existe uma diferena entre os mtodos append() e insert(),onde o mtodo append
adiciona um novo item no final da lista, e o mtodo insert adiciona um item no ndice
passado por parmetro, assim movendo os outros existentes para baixo.
8.5. Item

Como foi descrito anteriormente, existem vrios tipos de itens (ver Figura 7), e cada
um com sua determinada funo. Esses diversos tipos de itens estendem da classe Item.
Esses itens so inseridos em forms, opcional a insero de um Label assim como, no
necessitam ser mostrados em um display, eles tambm podem ter commands associados a
eles. Segue abaixo o construtor:

Figura 7 - Itens

8.5.1. StringItem
O StringItem apenas uma string simples que ser mostrada na tela. Para este objeto
Item, existem os mtodos de manipulao: getLabel(), setLabel(), getText(), setText().
Segue abaixo o construtor seguido de um exemplo.

8.5.2. TextField
Textfield uma string editvel onde o usurio tem acesso a um campo para
preencher. Para este item existem os mtodos de manipulao: getString(); setString(). O
terceiro parmetro (constraints) possui os mesmos tipos que o TextBox. Segue abaixo o
constructor:

A seguir um exemplo de Textfield onde o usurio ir poder preencher o seu nome.

8.5.3 Imagens
A especificao de MIDP determina que a implementao dever ser capaz de
manipular imagens .png, o que no ocorre em todos os celulares. Alguns trabalham com
.jpg, outros com .gif, .bmp, e at mesmo .png sem compactao, porm muito raro
conseguir encontrar a especificao de cada aparelho para isso, o que torna muito difcil a
programao com imagens, quando no usado o padro.
public static Image createImage(String nome);
public static Image createImage(byte[] dados, int offset, int tamanho);

O primeiro construtor busca o arquivo indicado pelo nome na pasta /res, de sua
aplicao. No caso de uso do emulador, quando ele compilado e empacotado, a imagem
empacotada junto com o programa. O segundo construtor obtm a imagem de um Arrray de
Bytes, partindo da posio offset, at o tamanho indicado. Essas imagens podem ser
Mutveis ou Imutveis. As Mutveis podem ser modificadas pelo objeto Graphics, obtido
pelo mtodo getGraphics(). Porm, esses dois construtores citados acima geram imagens
Imutveis
8.5.4. ImageItem
Este item mostra a instncia de uma Imagem (Imutvel) dentro de um Form, ou seja,
voc precisa j de um objeto Image. Este item possui um Label, um texto alternativo,
texto_alt, e pode ser posicionado segundo um layout. Antes de mostrar a instanciao de
um ImageItem, iremos adicionar ao cdigo um bloco Try/Catch para assim, criarmos um
objeto Image. Precisamos deste bloco para tratar possveis erros ao carregar a imagem do
diretrio fonte (Image source).
Observe a seguir o bloco descrito.

Aps criar um objeto Image, podemos acrescent-lo ao ImageItem.

Concluindo o objeto ImageItem:

Os parmetros layouts so constantes da classe, e podem ser: AYOUT_DEFAULT,

LAYOUT_LEFT,LAYOUT_CENTER,LAYOUT_RIGHT,LAYOUT_NEWLINE_BEFORE
*, LAYOUT_NEWLINE_AFTER*). Estas definies servem para posicionar as imagens na
tela de acordo com o usurio.
*somente existentes no MIDP 2.0
8.5.5. DateField

 uma interface usada para datas, horas ou ambos. Como ir aparecer por conta
do dispositivo e o programador no tem controle sobre isso. No construtor deve ser
especificado a Label e o tipo de dado, entre eles:
DateField.DATE
DateField.TIME
DateField.DATE_TIME
A seguir, o construtor de DateField:
public DateField(String Label, int modo);
Exemplo utilizando o Label DateField.DATE:

8.5.6. Gauges
uma representao grfica de um valor inteiro, e como ele ser mostrado depende
da implementao de cada aparelho. Esta forma grfica similar as barras de progresso
de downloads ou afins. Existem dois tipos de Gauges, o interativo, que permite a ao do
usurio sobre seu valor, e o no interativo, controlado somente pelo programa. Os valores
podem ser alterados em tempo de execuo pelos comandos getMaxValue(),
setMaxValue(), setValue(), getValue().
Construtor de Gauge:

Exemplo:

8.5.7. ChoiceGroup

O ChoiceGroup uma lista de escolhas semelhante a List (declarada na seo 8.6.

Lists), ambos implementam a interface Choice. Os tipos de listas so Exclusive e Multiple,
porm no tem o tipo Implicit (como no Lists). J na MIDP 2.0 implementado o tipo
POPUP, que deixa a lista semelhante a um menu DropDown.
Construtor de ChoiceGroup:

8.6. Lists
Como o prprio nome diz so listas, as quais permitem ao usurio selecionar itens
(elements) de uma lista. Esses elementos podem ser representados tanto por Strings quanto
por Imagens. Existem trs tipos de listas, Implicit, Exclusive e Multiple (ver Figura 8). A
seguir o construtor de List:

A Implicit deixa voc escolher uma opo e clicar no boto padro de seleo ou em
um command que voc adicionar, a Exclusive, permite somente a seleo de uma opo e
para selecion-la deve-se usar um boto com um command setado. E ainda tem a Multiple,
que funciona como uma CheckList j conhecida de outras linguagens de programao, que
nos permite selecionar vrias opes.

Figura 8 List Types

Quando selecionado um item em uma lista Implicit, o mtodo CommandAction

chamado, sendo que para esta List j foi anteriormente adicionado um CommandListener.
Existem duas sobrecargas para este construtor, no qual voc pode iniciar os Arrays de
elementos e de Imagens, ou no. O array de elementos, se utilizado, no poder ser nulo,
mas poder conter elementos nulos, os quais aparecero em branco na tela.
Quando uma lista tornar-se grande demais para a tela, ser criada uma rolagem, a
qual no cabe aos desenvolvedores implement-la, sendo assim, a mquina virtual ir
implement-la. Cada elemento da List possui um ndice, o qual inicia em zero. Para editar
uma List, existem alguns mtodos que valem a pena serem lembrados, tais como:
set: altera o elemento do qual o ndice foi fornecido;
insert: insere um elemento em uma posio indicada por um ndice. Se este ndice
estiver no meio da lista, ele fora os outros elementos uma posio frente;
append: inclui um elemento ao final da lista;
addCommand: inclui um command na lista (ver Figura 9);
delete: remove o elemento indicado pelo ndice;

Figura 9 Adicionando um command a uma List

Dois mtodos bastante utilizados que valem a pena ser comentados so:
public boolean isSelected(int indice): que me diz se o ndice esta selecionado
atualmente.
public int getSelectedIndex(): que me retorna o ndice que foi escolhido, somente
para listas Implicit e Exclusive.

8.7. Alerts
Um Alert nada mais que uma mensagem informativa ao usurio, tendo a mesma
funo de um alert de Javascript, ou VB, ou qualquer outra linguagem, ou seja, ele
basicamente uma telinha que mostra uma mensagem e logo depois sai da tela. Esses
alerts podem ser tanto Timed Alerts, ou Modal Alert. Assumem tambm um critrio em
relao a mensagem mostrada tais como: alerta, informao ou erro. Estes so setados pelo
desenvolvedor. No Timed Alert, voc pode setar um tempo ou no o qual receber o tempo
padro do aparelho.

Figura 10 Construtor Alert

Alerts so criados com um tempo default para desaparecer, tempo que

implementado na VM, e pode ser obtido pelo mtodo getDefaultTimeout(), e tambm
configurado por setTimeout(). Quando criamos um Timed Alert, podemos transform-lo em
modal adicionando ao parmetro AlertType para Alert.FOREVER. Verifique o exemplo de
um Alert que tem definido como seu tipo o de informao (AlertType.INFO).

O comportamento padro de um Alert mostar a prxima tela setada, se usado o

mtodo setCurrent(atual, prximo), ou ele ir voltar para a tela atual se for usado,
setCurrent(Alert).
9.0 Bluetooth Integrado com J2ME Projeto Marge
Para integrar as duas tecnologias de maneira a aproveitar o mximo desempenho de
ambas e tambm, para a elaborao de uma ferramenta, foi escolhida para o foco de estudo
uma implementao da API JSR-82. Como a Sun no possui uma implementao desta API
em seu site, foi realizada uma busca para verificar qual seria a melhor opo para tilizao.
O Projeto Marge foi escolhido para acrescentar ao projeto a comunicao
Bluetooth. Este framework tambm chamado de marge-core desenvolvido por um
brasileiro, Bruno Ghisi, capaz de desenvolver aplicaes utilizando a comunicao sem
fio, sendo compatvel com o Java SE alm do Java ME.
10.0 Ferramenta
No decorrer do projeto, aps o estudo da tecnologia Bluetooth, houve uma
preparao inical para a utilizao da tecnologia C# (Microsoft), mas acabou concluindo-se
que a mesma s possui implementao estvel para dispositivos mveis sofisticados.
Passou-se ento a explorar o J2ME.
Aps estes desvios, houve uma srie de dificuldades para a compreenso do
framework e assim impediram o desenvolvimento completo da ferramenta, que tinha como
foco principal, o Bluetooth. Apesar da implementao da Marge no ser muito complicada,
houve algumas dificuldades para o entendimento de algumas classes especficas como:
DeviceDiscoverer, InquiryListener, ServiceDiscoverer e algumas outras que so necessrias
para estabeceler e reconhecer outros dispositivos.
Sendo assim, foi elaborada uma ferramenta sem o uso da comunicao, sendo
utilizada a maioria dos objetos grficos que a linguagem oferece. A seguir, sero descritos
detalhadamente a construo da ferramenta, assim como imagens da execuo dela no
simulador e no celular.
10.1. Classes
As classes utilizadas nessa ferramenta so duas: AplicaoTeste e Data. As duas
foram implementadas de maneira muito simples, com o objetivo de mostrar a capacidade
grfica da linguagem. A classe AplicaoTeste herda de MIDlet todos os mtodos e tem
como objetivo inicializar a aplicao.

Alm do construtor, que instancia os Forms, TextFields e os Commands que so

mostrados na tela inicial, existem tambm Load(), LoadComplete(), PrepararLista(),
Help() e About(). No Form inicial, o usurio visualiza alguns itens declarados durante este
relatrio, tais como: TextField, DateField, Ticker, Commands. Dentre os dois commands
adicionados ao primeiro Form, esto o Exit e Load. O command Load carrega a
aplicao chamando o mtodo Load(), caso contrrio a aplicao encerrada.

No mtodo Load, verificado se o usurio digitou o seu nome corretamente, caso

ele no tenha digitado, utilizou-se uma instncia do objeto Alert, para avisar de maneira
visual e sonora o usurio que o campo deve ser preenchido corretamente (ver Figura 11).
Caso contrrio (ver Figura 12), ser iniciada uma Thread com o seguinte nome
GaugUpdater que foi implementada juntamente com a classe principal.
Esta Thread tem como funo exibir na tela uma barra de progresso (ver Figura
13), conhecida com Gauge que mostra a aplicao sendo carregada, neste caso, no tem
nenhuma importncia, ou seja, ela no carrega nenhuma funo ou aplicativo.
Aps ser carregada exibido em um novo Form (ver Figura 14), com uma
mensagem dizendo ao usurio que a aplicao foi carregada com sucesso. Assim, o usurio
tem novamente, duas opes para realizar atravs dos commands, e so elas: sair da
aplicao e avanar. No momento em que o usurio avana, outro Form ir ser setado
como Display atual, mostrando uma lista de menus que so as verdadeiras opes da
aplicao (ver Figura 15).
Essas opes so: Bluetooth, Help e About. O item Bluetooth no possui nenhuma
implementao devido aos problemas citados anteriormente. J os dois ltimos itens, so

apenas Forms, que adicionados a eles, objetos grficos como o StringItem, que serve
apenas para informar algo ao usurio.
A classe Data, uma classe que utlizada a biblioteca java.util.Calendar; para
exibir no display inicial, a data atual segundo o sistema do celular.

Figura 11 Alert

Figura 12 Load Screen

Figura 13 Loading with Threads

Figura 14 Load Complete

Figura 15 List Menu

11. Consideraes Finais

Atualmente o Bluetooth uma inovao no aspecto de redes sem fio, com suas
limitaes e suas vantagens. A pesquisa iniciou-se com o estudo da tecnologia sem fio,
analisando sua arquitetura e o seu desempenho, quando comparada com outros tipos de
comunicao. Observou-se que a tecnologia muito inovadora e satisfaz a maioria dos
projetos que possuem um pequeno planejamento, ou seja, quando no necessrio uma
implementao muito robusta. Caso contrrio, se o projeto necessitar um desempenho
maior, a comunicao Bluetooth atende as necessidades quando utilizada juntamente com
outros dispositivos, embarcando esta conexo com outros ambientes, permitindo um maior
desempenho.
Independentemente do nvel exigido pelo projeto, a velocidade do Bluetooth
consideravelmente boa quando comparada com outras situaes. A maior motivao que
fez com que esse assunto fizesse parte do projeto foi exatamente o seu funcionamento, e o
seu uso ser totalmente gratuito.
A linguagem de programao escolhida satisfaz as necessidades e solues quando
deparadas com problemas. A maioria destas solues so propostas pela ferramenta
escolhida para programar, e evitam a maioria de erros de sintaxe e tornam o cdigo mais
legvel e organizado.
Por se tratar de uma linguagem que explora, na maioria das vezes, objetos grficos,
o nvel de complexidade inferior quando comparada com alguma outra linguagem e em

outra ocasio. A implementao dos objetos de interface so muito fceis e prticas,

tornando a programao muito rpida.
Apesar dos desvios que ocorreram no projeto, uma ferramenta foi elaborada com os
itens grficos da tecnologia (esta foi descrita anteriormente), mas falhou ao explorar a
tecnologia Bluetooth. Contudo, o projeto teve pontos positivos ao bolsista, como
organizao na diviso das tarefas, elaborao de materias, estes expostos e apresentados
no Salo de Iniciao Cientfica da PUCRS, alm do interesse e busca por informaes
necessrias para o estudo e para a implementao e utilizao da linguagem de
programao.

References:

Miller, Michael; Descobrindo Bluetooth. Rio de Janeiro, Campus Ltda., 2001,

289p.
Morrow, Robert K.; Bluetooth Operation and Use. New York, McGraw-Hill,
2002, 567p.
Held, Gilbert; Data Over Wireless Networks Bluetooth. Wap, and Wireless
LANs, New York, McGraw-Hill,2001,344p.
Gratton, Dean Anthony; Bluetooth profiles: the definitive guide. Upper Saddle
River, Prentice Hall PTR, 2003, 569p.
Keogh, James; J2ME The Complete Reference. Editora Osborne.
Knudsen, Jonathan; Wireless Java Developing with J2ME. Editora Apress.