LBS com a facilidades da API Location (J2ME): Proposta de Arquitetura

1.��Introduç�o

Quem pensa que os serviços de localizaç�o apenas servem para determinar as coordenadas posicionais est� muito atrasado. Seja atrav�s de sat�lites GPS, ou de sistemas terrestres, serviços baseados em localizaç�o (de Location-Based Services � LBS) podem auxiliar os automobilistas, orientar os turistas, ou informar o p�blico em geral sobre caracter�sticas e serviços referentes � determinada zona ou regi�o.

Desde o mil�nio passado v�em-se em publicaç�es especializadas e not�cias de alguns executivos do ramo a seguinte afirmaç�o: �Neste pr�ximo ano veremos o �boom� dos serviços de LBS na telefonia m�vel�. O motivo�� simples: o lançamento e proliferaç�o de aparelhos celulares equipados com GPS, logo poderemos ouvir as pessoas se perguntando: �O seu celular tem LBS? Ent�o me autoriza a� a localiz�-lo!�.

O LBS �, basicamente, a converg�ncia de v�rias tecnologias atuais, tais como: comunicaç�o m�vel, tecnologias de localizaç�o, dispositivos m�veis (DM) com Internet, sistemas de informaç�o geogr�fica (SIG), servidores de aplicaç�es e banco de dados �espaciais� (Oracle Spatial, MySQL, PostGIS,).� Em resumo podem ser definidos como qualquer serviço com valor agregado cuja principal funç�o � obter informaç�es que determinem a localizaç�o do dispositivo m�vel e, baseado nas mesmas, oferecer serviços de acordo com o contexto de utilizaç�o com a ajuda de v�rios m�todos de indexaç�o e serviços de orientaç�o.

Para desenvolver um LBS, deve existir uma estrutura b�sica de componentes que d�em suporte aos seguintes itens: Determinaç�o da localizaç�o (software e hardware); Solicitaç�es de consultas e Processamento e gerenciamento da informaç�o geogr�fica e contextual; Serviços de gateway (midleware entre os serviços de processamento e os�dispos�tivos m�veis�para promover compatibilidade).

2. Vis�o Geral� das Arquiteturas

Devido a natureza de Java, ela foi desmembrada:

J2SE (JAVA Standart Edition)	Ediç�o para desenvolvimento de aplicaç�es desktop e estaç�es de trabalho
J2EE (JAVA Enterprise Edition)	Ediç�o para desenvolvimento de aplicaç�es web e corporativas
J2ME (JAVA Micro Edition)	Ediç�o para desenvolvimento de aplicaç�es disposit�vos m�veis

�

A ediç�o J2ME � direcionada ao mercado de dispositivos com menor poder computacional e limitaç�es de processamento, resoluç�o de tela e mem�ria. Seu conjunto de especificaç�es tem por objetivo disponibilizar uma JVM (Java Virtual Machine), APIs e ferramentas para esses tipos de equipamentos.

Aplicaç�es LBS ser�o os pr�ximos destaques no mundo do desenvolvimento sem-fio e a J2ME � ideal para tornar-se um padr�o para o desenvolvimento desse tipo de aplicaç�o, pois fornece um conjunto de classes e funcionalidades voltadas para esse fim, e disp�e de outras importantes caracter�sticas como: entrega din�mica de conte�do; segurança; compatibilidade entre plataformas; conte�do interativo; acesso Offline; o poder da linguagem orientada a objetos e a padronizaç�o da ind�stria atrav�s do Java Community Process

A plataforma J2ME oferece al�m de suas capacidades j� mencionadas a Location API for J2ME (JSR-179), esta permite que o sistema contido em um dispos�tivo m�vel equipado por exemplo com GPS (tecnologia escolhida para o trabalho por n�o ter custo com a localizaç�o atrav�s de serviços da operadora) tenha acesso, utilizando um servidor com base de dados persitente, � localizaç�o de serviços sensiveis a sua posiç�o atual.�

2.1. Especificaç�o da Location API

Esta API fornece uma interface padr�o de alto n�vel para acesso �s informaç�es de posiç�o de um DM. Ela surgiu a partir da JSR-179), liderada por um desenvolvedor da Nokia Corporation (Kimmo Loytana) junto um grupo de empresas ligadas ao ramo de telefonia m�vel [9]. Demonstra a import�ncia da JSR e a preocupaç�o das empresas na implementaç�o de uma API de localizaç�o.

A Location cont�m as classes b�sicas necess�rias para solicitar, recuperar e exibir uma localizaç�o geogr�fica al�m de integrar dados b�sicos de posiç�o e de orientaç�o com armazenamento persistente de POI (Points of Interest - marcos ou landmarks), e conex�o via HTTP com servlets [1], que permitem programadores implementar aplicaç�es e serviços sem fio para dispositivos de recurso limitados como DM (CDC e CLDC) [6]. Porem para a utilizaç�o dessa API recomenda-se a utilizaç�o do perfil MIDP v.2.0 por possuir conceitos novos de segurança e a plataforma m�nima de CLDC v.1.1. uma vez que a API requer suporte � calculos com pontos flutuantes (n�meros em reais).�

Vantagens do uso da API Location

Interface de alto n�vel para programadores

Usa autom�ticamente qualquer m�todo de localizaç�o dispon�vel, podendo ocorrer a combinaç�o de m�todos (GPS/assisted-GPS, Cell-ID, Time offset/TOA, Bluetooth, WLAN, etc)

Uso de persist�ncia de dados no pr�prio dispositivo m�vel, landmarkstore

Nenhum c�digo � necess�rio ser programado para uso de tal persistencia

Os marcos podem ser utilizados em outras aplicaç�es que utilizam dados duplicados

Permite aplicaç�es modulares, ex. uma aplicaç�o localiza o marco outra indica a direç�o

Classe de descriç�o das coordenadas localizacionais opcional, addressinfo

Obtenç�o das coordenadas localizacionais periodicamente de forma autom�tica

Desvantagens do uso da API Location

N�o tem suporte a mapa, necess�rio uso de outras tecnologias

dados do landmarkstore � dispon�vel a outras aplicaç�es

dados do landmarkstore podem em alguns casos ser acessado por outros

Exibiç�o de um compasso de orientaç�o 3D do dispositivo e fornecer

A implementaç�o pode limitar o n�mero de marcos adicionados

os dados n�o s�o seguros, aberto a outras aplicaç�es podendo at� serem alterados

Poucos disposit�vos m�veis possuem suporte a API, somente aparelhos novos e caros

�

2.1.1. Sistema de Coordenadas Geogr�ficas

A API utiliza coordenadas geogr�ficas que s�o obtidas pelo Sistema Geod�sico Mundial (World Geodetic System � WGS84), utilizado tamb�m como um sistema de refer�ncia via GPS.

As coordenadas s�o constitu�das de valores de latitude, longitude e altitude. Na esfera global as latitudes s�o linhas horizontais de medida que representam o norte e o sul entre os p�los. O p�lo norte � 90� norte (+90�) e o p�lo sul � 90� sul (-90�). O c�rculo central � chamado de Equador � representado por 0�. Recomenda-se o uso de b�ssola para verificar como a API est� definindo o p�lo, pois ela pode usar qualquer uma das duas definiç�es de p�lo norte (o magn�tico relativo e o geogr�fico real), .

Na esfera global as longitudes s�o linhas que atravessam o globo terrestre do norte ao sul (valores constantes longitudinais definidos por meridianos). O fato de n�o existir um meridiano de referencia (de partida), � necess�rio a definiç�o de um. Tradicionalmente, o meridiano de Greenwich (Inglaterra) � usado. O valor do primeiro meridiano � 0 grau, no entanto o WGS84 utilizado pela API Location define o 0� a 100m a leste do Greenwich.

2.1.2. O Modelo de Objeto do Pacote javax.microedition.location

O pacote Location (javax.microedition.location) � sub-dividido (Tabela 1) em 8 classes, sendo 6 principais e duas classes de interface (LocationListener e ProximityListener). Das seis classes, duas s�o classes da exceç�o (LocationException e LandmarkException) e as outras quatro (AddressInfo, Criteria, Orientation, e QualifiedCoordinates) s�o objetos que possuem valor.

Figura 1. Vis�o geral da API e as relaç�es entre as mesmas

Tabela 1. Definiç�o e resumo das funç�es das 8 classes da API Location

Classes para escolha do provedor de localizaç�o
LocationProvider	� o Ponto inicial. Representa o objeto (fonte) de recuperaç�o da posiç�o do DM (ex: m�dulo GPS).
Criteria	Utilizado para seleç�o do provedor de localizaç�o e refinar a aç�o do sistema ( quanto ao uso do LocationProvider)
Classes necess�rias para mediç�o da localizaç�o
Location	Objeto padr�o que representa o conjunto de localizaç�o b�sica de uma posiç�o de um DM.
AddressInfo	� um subtipo de objetos Location, armazena informaç�o textual sobre a localizaç�o. Entretanto, estando em campo aberto o valor de AddressInfo ser� sempre nulo.
Coordinates	Super classe de QualifiedCoordinates, representa valores de coordenadas como latitude, longitude e altitude.
QualifiedCoordinates	� um outro subtipo de objetos Location, representa em valores coordenadas geogr�ficas (como latitude, longitude e altitude) que s�o associados com um valor exato.
Classes de interface da API Location
LocationListener	Interface que reconhece eventos associados com um LocationProvider particular. Assim a aplicaç�o pode obter um �nico objeto de posiç�o coordenadas geo-posicionais)
ProximityListener	Interface de eventos associados com a detecç�o de aproximaç�o dos landmarks (registradas no LandmarkStore)
Classes de classificaç�o e Armazenamento de marcos
Landmark	Representa uma localizaç�o j� conhecida pelo usu�rio atrav�s de um nome.
LandmarkStore	M�todos para gerenciamento persistente (adiç�o, deleç�o e retorno) de Landmarks.
Classe de informaç�o de orientaç�o
Orientation	Representa a orientaç�o (curso, direç�o) f�sica de um DM

Fonte: JAVA COMMUNITY, 2006

3. Desenvolvimento de Aplicaç�es

��A metodologia indicada para o desenvolvimento � o de Projeto Orientado a Objetos por ser o paradigma mais atual em termos de criaç�o de sistemas. Al�m disso, esta metodologia permite a construç�o de aplicaç�es a partir de duas caracter�sticas b�sicas: reutilizaç�o de c�digo e modularidade. �Utilizando para isso a linguagem UML (Unified Modeling Language).

Utilizou-se tamb�m o uso de Padr�es de Projeto, os mesmos s�o descriç�es de objetos e classes que precisam ser personalizadas para resolver um problema de projeto num determinado contexto. O uso dos mesmos pode melhorar de maneira substancial a arquitetura de uma soluç�o de software, criando classes extras que permitam isolar as partes de um projeto, tornando-as independentes e mais flex�veis.

�Os padr�es utilizados no desenvolvimento do prot�tipo foram os seguintes:

Padr�o Model-View-Controller	Modelo do uso combinado de padr�es que permite a construç�o de aplicaç�es em 03 camadas. A camada Model, respons�vel pela persist�ncia dos dados. A camada View que permite a interaç�o com o usu�rio e a camada Controller, respons�vel por fazer a ligaç�o entre as outras camadas definindo como o sistema reage �s entradas do usu�rio
Padr�o Singleton	Padr�o de criaç�o de objetos garante que uma classe tenha apenas uma inst�ncia controlada pela pr�pria classe. Este padr�o � bastante �til em aplicaç�es m�veis devido ao poder de processamento reduzido do dispositivo evitando a criaç�o e destruiç�o de objetos que ser�o reutilizados
Padr�o State	Padr�o comportamental permite a um objeto alterar seu comportamento conforme seu estado interno muda. O objetivo � definir uma classe abstrata para representar os estados dos objetos onde as subclasses implementam os comportamentos espec�ficos de cada estado.

3.1. Estudo de Caso

Foi implementado um MIDlet de LBS b�sico utilizando a API Location,�por ser�muito �til pois permite ao MIDlet usar quaisquer dos m�todos conhecidos de localizaç�o existente de forma transparente ao usu�rio e com uma programaç�o f�cil, isto �, sem deixar a amostra os procedimentos e c�lculos complexos dos mesmos. Podendo at� unir m�todos para melhorar a preciss�o (por exemplo o uso do Assisted-GPS, AOA+ TDOA), exibindo apenas os resultados requeridos.

A arquitectura da aplicaç�o cliente est� esquematizada em uma arquitectura que serve h� v�rios prop�sitos: dividir a aplicaç�o em m�dulos que fornecem funcionalidades espec�ficas; separar a �l�gica de neg�cio� da interface com o utilizador e abstrair a �l�gica de neg�cio� da tecnologia.

O objectivo desta arquitectura � concentrar toda a l�gica de neg�cio em uma �nica� camada. Esta camada pretende ser independente da tecnologia usada no resto da aplicaç�o, fazendo uso apenas das interfaces definidas na camada de abstraç�o. Desta forma torna-se poss�vel implementar pequenos detalhes da interface gr�fica, por exemplo, recorrendo a bibliotecas espec�ficas de alguns dispositivos, sem alterar a l�gica de neg�cio.

A camada de abstracç�o � constitu�da por interfaces e classes abstractas. Isto permite que a aplicaç�o use os serviços disponibilizados por essa camada enquanto que a implementaç�o concreta desses serviços � feita apenas na camada inferior. Desta forma torna-se simples trocar, por exemplo, o m�dulo de comunicaç�es atrav�s de Web Services ou Servlets sem alterar o resto do sistema.

Esta distribuiç�o em camadas facilita tamb�m a poss�vel adaptaç�o do sistema a dispositivos concretos usando as APIs fornecidas pelos fabricantes (ex. a API da Nokia ou da Siemens).

A camada de classes concretas representa a implementaç�o propriamente dita, da camada de abstraç�o. � nesta camada que est� realmente o c�digo que implementa as funcionalidades definidas pela camada superior.

Figura 2. Vis�o geral do funcionamento do MIDlet LBS

��Vamos ao funcionamento pr�rpiamente dito. Ao in�cio do MIDlet � executa-se uma busca autom�tica por um� fornecedor de posiç�o (LocationProvider). O uso de MIDlet pode começar depois que um fornecedor � encontrado tornando-o capacitado para determinar posiç�es e receber eventos de atualizaç�o de posiç�o, com demonstra o c�digo:

protected void startApp() throws MIDletStateChangeException{

�� if (ConfigurationProvider.isLocationApiSupported()){

�� ConfigurationProvider.getInstance().autoSearch(this);

�� }

�� ...

�

Depois que um fornecedor de posiç�o � selecionado autom�ticamente pela API, a classe ConfigurationProvider guarda a seleç�o do LocationProvider autom�tica e emite uma notificaç�o de evento via ProviderSelectedListener. A classe �ConfigurationProvider ainda possui a funç�o aidiconal de, verificar o suporte a orientaç�o e o acesso a classe.

Para se obter de forma autom�tica atualizaç�es de uma posiç�o atual em intervalos de tempo pr�-determinados, deve-se usar a relaç�o de LocationListener. Uma vez feita o instanciamento do mesmo, deve registra-lo com LocationProvider atrav�s do m�todo setLocationListener, para assim poder obter a posiç�o atual do dispositivo (como pode ser visto abaixo). Podendo tamb�m determinar crit�rios (dispon�veis na classe Criteria) para refinar a aç�o do sistema ou melhorar a preciss�o da busca:

public LocationProv(ProviderStatusListener listener){
�� ConfigurationProvider config = ConfigurationProvider.getInstance();
�� LocationProvider provider = config.getSelectedProvider();
�� if (provider != null){
�� provider.setLocationListener(this,interval,timeout,maxage);

}

�

Os crit�rios escolhidos em um projeto de aplicaç�o pode afetar a: vida da bateria do DM; lat�ncia na aplicaç�o; adequaç�o da precis�o (horizontal e vertical); determinaç�o manualmente ou n�o do m�todo a ser usado para recuperar a posiç�o (ex. GPS indoor), e custo. Como este � potencialmente um processo longo, este � executado em uma thread[2] para evitar travamentos e deixar livre para execuç�o de outras funç�es:

cr.setHorizontalAccuracy(Diametro);
cr.setVerticalAccuracy(Diametro);
cr.setPreferredResponseTime(TempoResposta); cr.setPreferredPowerConsumption(Criteria.POWER_USAGE_MEDIUM);
cr.setAddressInfoRequired(true);
lp = LocationProvider.getInstance(cr);

�

O LocationListener (classe de interface ou ouvinte de eventos) cont�m dois m�todo:

��LocationProvider: chama o m�todo locationUpdated sempre que a posiç�o �atual for modificada.

public void locationUpdated(LocationProvider provider, final Location location){

�� if (ProviderStatusListener != null){

�� new Thread(){

�� public void run(){

�� if (location != null && location.isValid()){
�� this.locationInfo();

�� AddressInfo address = location.getAddressInfo();

�� QualifiedCoordinates coord =location.getQualifiedCoordinates();

�� }
�� ...

�

��ProviderStateChanged � chamado quando h� modificaç�o do estado do LocationProvider entre: AVAILABLE, TEMPORARILY_UNAVAILABLE, e OUT_OF_SERVICE [6].

public void providerStateChanged(LocationProvider provider, final int newState){

�� if (prodiver != null){

�� new Thread(){

�� public void run(){

�� switch (newState) {

�� case LocationProvider.AVAILABLE:

�� providerState = "Avaliado";

�� break;

�� ...

�� default:

�� providerState = "Desconhecido";

�� break;

�� }

�

Para auxiliar o LocationListener e o ProximityListener, foi criada a classe InfoData, �que escuta os eventos atrav�s dos mesmo, trata e segura a atualizaç�o dos dados na classe view� principal.

Vamos agora aos objetos de posiç�o, estes s�o adquiridos da classe LocationProvider (parametrizado por um objeto Criteria). Ap�s ter os� objetos �em m�os�, usa-se para encontrar as informaç�es atuais atrav�s do objeto QualifiedCoordinates de acordo com o quadro abaixo:

new Thread(){
�� public void run(){
�� if (location != null && location.isValid()){
�� AddressInfo address = location.getAddressInfo();
�� QualifiedCoordinates coord = location.getQualifiedCoordinates();
�� float speed = location.getSpeed();��
�� providerState = "Avaliado";��
�� }�
�� ...

�

J� a direç�o, a velocidade, e a altura s�o retornados de QualifiedCoordinates como valores em reais enquanto que a coordenadas s�o retornadas em double. Para melhor visualizaç�o dos dados, a classe Coordinates possui um m�todo de convers�o (Coordinates.convert) do mesmo em uma string (palavra) em um dos dois formatos:

a) Graus, minutos, e fraç�es decimais de minuto (em double: 61.51d e em string: 61:30:36);

b) Graus, minutos, segundos, e fraç�es decimais de segundo (em double: 61.51d e em string, 61:30.6).

Abaixo, temos uma implementaç�o onde a informaç�o da posiç�o � exibido na tela sendo usado o formato �b�, usando o campo constante Coordinates.DD_MM_SS. Alternativamente, o formato �a�� pode ser selecionado usando Coordinates.DD_MM:

if((qc != null) || (location.isValid())) {

�� lat = new StringItem("Latitude: " + Coordinates.convert

�� (coord.getLatitude(), Coordinates.DD_MM_SS), "");

�� long = new StringItem("Longitude: " +� Coordinates.convert��
�� (coord.getLongitude(), Coordinates.DD_MM_SS), "");��

��

}

�� A classe das coordenadas encapsulam m�todos geom�tricos, como o c�lculo do �ngulo, dist�ncia entre dois pontos (da atual a coordenada dada) e a direç�o da b�ssola (azimuth) entre eles. O calcula da dist�ncia geod�sica entre posiç�es � de acordo com o modelo do ellipsoid de WGS84. �A exatid�o desse calculo ser� o m�ximo poss�vel, entretanto, requer-se que o resultado est� dentro de 0.36% do resultado correto.� De modo an�logo o calcula da direç�o � de acordo com o modelo de WGS84.
�� O azimuth � relativo ao norte verdadeiro. O objeto Coordinates em que este m�todo � chamado � considerado a origem para o c�lculo e as coordenadas dadas pelo usu�rio � o parametro destino a calcular. Quando a origem for o p�lo norte e o destino n�o for o p�lo norte, a resposta do calculo ser� de 180� ja no caso de a origem for o p�lo sul e o destino for diferente do mesmo, os retornos ser�o de 0�. Se a origem for igual ao destino, tamb�m ser�o de 0�. A execuç�o calcular� o resultado t�o exatamente quanto ele poder. Entretanto, requer-se que o resultado est� dentro de 1� do resultado correto.

flooat distancia = coord.distance(coordenadas);
form.append(�A dist�ncia � =� + distancia);
int direcao = new FLoat(coord.azimuthTo(coordenadas)).intValue();

if(direcao >= 338 || direcao <= 22)

form.append ("Norte " + distAway + " metros";

if(direcao >= 23 && direcao <= 67)

form.append ("Nordeste " + distAway + " metros ";

if(direcao >= 68 && direcao <= 112)

form.append ("Leste " + distAway + " meters";

�

O que distingue particularmente esta API de outras bibliotecas LBS � o uso do armazenamento persistente sendo uma base de dados dos POI nos dispositivos. O que desloca a �nfase nos termos de aplicaç�es em relaç�o a posiç�o-cliente, permitindo mapeamento locais de posiç�es j� conhecidas. A vantagem principal desta �, em caso de problemas de conex�o com a rede a aplicaç�o n�o fica inoperante.

Esta persist�ncia � controlada utilizando o pela camada Controller do padr�o MVC que trata todas as operaç�es relacionadas� ao �LandmarkStore.

Vantagens de uso do LandmarkStore

Nenhum c�digo � necess�rio ser programado para tal uso de tal persistencia

os marcos podem ser utilizados em outras aplicaç�es que conservam dados duplicados e permite aplicaç�es modulares, por exemplo, uma aplicaç�o localiza o marco quando outra da a direç�o

Desvantagens de uso do LandmarkStore

a implementaç�o pode limitar o n�mero dos marcos

os dados n�o s�o seguros, aberto a outras aplicaç�es e os dados poderiam ser alterados/suprimido por getLandmarks externos

�

�O LandmarkStore � uma coleç�o de POI, podendo haver muitos destes em um dispositivo compartilhado por aplicaç�es m�ltiplas. Os POI podem ser armazenados em lojas e categorias m�ltiplas. A �nica limitaç�o � que n�o pode ser adicionado v�rias vezes � uma mesma categoria.

Uma caracter�stica da API � que um objeto POI podem ser adicionados� autom�ticamente ao LandmarkStore. Objetos estes de coordenada e de AdressInfo de uma posiç�o gerada pelo LocationProvider:

try{
�� store = LandmarkStore.getInstance(�NomeStore�);
}
if (store == null){
�� try{��
�� LandmarkStore.createLandmarkStore(�NomeStore�);
}

�

Landmark lm = new Landmark(Nome.getString(), Desc.getString(), coord, info);
if (landmark != null){
�� try{
�� landmarkStore.addCategory("NomeCategoria");
�� createProximityListener(coord);
�� landmarkStore.addLandmark(�NomeLandmark�, " NomeCategoria");

�� }
�� }

�

Mais tarde � feita a recuperaç�o (pesquisa) de um POI determinado usando o m�todo� getLandmarks, passando os nomes da categoria e o POI como par�metros:

public Landmark findLandmark(int index){

�� Enumeration enu = store.getInstance().getLandmarks(�NomeLandmark�,��
�� NomeCategoria);

�� while (enu.hasMoreElements()){

�� landmark = (Landmark) enu.nextElement();
� ��if (counter == index)

�� break;

�� counter++;

�� }�

�� return landmark;

}

�

Pode-se realizar pesquisas de POI que estejam pr�ximos a posiç�o atual do disposit�vo �(eventos tur�sticos e logradouros nas� proximidades):

�

public Landmark findNearestLandMark(Coordinates coord){
�� double LatRaio = 0.1;� double LonRaio = 0.1;� float distan = Float.MAX_VALUE;
�� try{ // gerando um enumeration de marcos de acordo com as coordenadas dadas
�� Enumeration enu = store.getLandmarks(null, coord.getLatitude() - LatRaio,��
�� coord.getLatitude() + LatRaio, coord.getLongitude() - LonRaio,
�� coord.getLongitude() + LonRaio);

�� while (enu.hasMoreElements()){
�� tmpLandmark = (Landmark) enu.nextElement();
�� tmpDistan = tmpLandmark.getQualifiedCoordinates().distance(coord);
�� if (tmpDist < dist){
�� landmark = tmpLandmark;
�� }
�� }
�� }
...

�

Um objeto de posiç�o pode ser do tipo v�lido ou invalido. O mesmo pode ser verificado atrav�s do m�todo location.isValid. Um objeto v�lido representa uma posiç�o de coordenadas v�lidas retornada por getQualifiedCoordinates. No caso de objeto inv�lido usamos o info extra, obtido pelo m�todo getExtraInfo que informa a raz�o pelo qual n�o � poss�vel fornecer uma posiç�o v�lida.

if (loc.isValid()) {
�� if((loc.getLocationMethod() & loc.MTE_SATELLITE) !=0){
�� f.append(�M�todo usado � = Sat�lite GPS�);
}
else{
�� Location.getExtraInfo(String mimetype);
�� getExtraInfo(�application/X-jsr179-location-nmea�);
�� getExtraInfo(�text/plain�);
�� f.append(loc.getExtraInfo(�text/plain�));
}
qc = loc.getQualifiedCoordinates();

�

3.2. Comunicaç�o com o Servlet

��Uma outra forma de integraç�o do J2ME com o LBS, podendo ser at� uma alternativa ao uso da API Location, ou em casos de o dispositivo n�o terem suporte nativo as coordenadas endereçadas (addressing� coordinates) ou com pouco poder de armazenamento usa-se a geo-codificaç�o atrav�s de GIS e pesquisa sobre a rede atrav�s de conte�do em p�ginas web especiais, os servlets que trabalham com banco de dado espaciais. Depois de j� obtida a informaç�o da posiç�o atual, � poss�vel submet�-la ao servlet sobre uma conex�o do tipo HTTP padr�o (definiç�o de uma URL), no caso usando para solicitaç�o o m�todo Get da aplicaç�o LBS.

public void PesquisarGet() throws IOException {

��

�� thread tConnection = new thread(){

�� public void run(){

�� hc = (HttpConnection) Connector.open(url);

�� hc.setRequestMethod(HttpConnection.GET); }

�� };

�� try{

�� AlertType.INFO.playSound(m_Display);

�� tConnection.start();

�� tConnection.join();

��
�� }

}

�

Figura 3. Procedimento de um Servlet

Como foi visto, o MIDLet faz o trabalho de recuperar (no caso via GPS) a posiç�o atual do DM e de entreg�-la ao usu�rio. Em uma aplicaç�o t�pica se tem um servlet que aceita os pedidos de requisiç�o e manipula essas informaç�es de localizaç�o. As suas aç�es s�o de: fazer a analisar das informaç�es repassadas do dispositivos, realizar a consulta via uma instruç�o SQL ao banco de dados e ent�o retornar as informaç�es de resposta (eventos tur�sticos e logradouros nas� proximidades) ao MIDLet.

public void doGet(HttpServletRequest req, HttpServletResponse res) throws�
�� ServletException, IOException {
�� latitude = request.getParameter("latitude"), �
�� longitude=request.getParameter("longitude"),

�� localidade = pesquisaLocal(latitude, longitude);

�� public String pesquisaLocal(String latitude, String longitude){

�� // Obejtos de conex�o

��

�� String sql = �Select LOCALIDADE From DADOS_LOCALIDADE Where latitude = " +

�� latitude - latRadius + � BETWEEN � + latitude - latRadius + " And longitude = " +

�� longitude � lonRadius + � BETWEEN � + longitude + lonRadius + �;�

�� try{

�� Class.forName("�");

�� ResultSet rs = stm.executeQuery(sql);

��
�� }

}

�

3.3. Outros Sistemas

��Dentre as operadoras brasileiras a VIVO � a pioneira no uso de serviços LBS a n�vel nacional[3], com o serviço VIVO Localiza e outros do g�nero. O serviço utiliza tanto o recurso handset-based com o A-GPS (Assisted GPS) quanto network-based com a triangulaç�o de ERBs. Normalmente ao se estar outdoor � utilizado o A-GPS e em indoor a triangulaç�o.

Com o MIDlet da VIVO j� descarregado para o disposit�vo, este captura as informaç�es geo-localizacionais do GPS integrado e os envia para um servidor que converte as informaç�es para que sejam plotadas em um mapa georeferenciado. Seu erro esta na m�dia de 5 a 50m.

Atualmente j� � poss�vel usar O Google Maps que oferece uma gama de possibilidades de novos serviços incr�veis, e o melhor. Est� API escrito em JavaScript, permite qualquer pessoa utilizar os serviços de orientaç�es detalhadas de rotas de origem e destino (geo-coding), por meio de mapas e imagens via sat�lite do Google Earth do Google em seus pr�prios WebSites e MIDlets.

O Google Maps para celulares � um aplicativo J2ME interativo que inclui mapas, pesquisa local, informaç�es de rotas para motoristas e a funcionalidade click-to-call (clique para chamar).

Existem ainda outras aplicaç�es m�veis LBS muito boas, como:�MapQuest Mobile, Vindigo City Guide, Mobile GMaps. Todas recomendados por JAVA.com.

4.�� Conclus�es

Os LBS possuem caracter�sticas que resultam em um desafio complexo do ponto de vista tecnol�gico e comercial. A heterogeneidade e dispers�o das fontes de informaç�o e a associaç�o destas as localizaç�es f�sicas, assim como a condiç�o de mobilidade dos utilizadores, s�o aspectos que necessitam estar integrados e interagindo uniformemente.

N�o � dif�cil imaginar as novas situaç�es que este novo cen�rio trar� para as nossas vidas, tanto no lado pessoal como profissional. No �mbito corporativo, os celulares com GPS gerar�o infinitas aplicaç�es, aumentando a efici�ncia dos neg�cios e produtividade das equipes de campo ainda mais. Localizar automaticamente a viatura mais pr�xima para atender um chamado ou o vendedor mais pr�ximo para tirar um pedido no cliente ser�o situaç�es comuns na maioria das empresas.

� claro que este novo cen�rio n�o trar� s� boas not�cias. Quest�es relativas � privacidade liderar�o pol�micas e discuss�es em torno do tema. No in�cio, como qualquer novidade em qualquer ind�stria, os valores cobrados pelos serviços ser�o mais altos do que esperamos. Mas o que importa � que o saldo de tudo isso ser� muito positivo!� Agora sim! Que venham os serviços de localizaç�o!

Com a implementaç�o deste sistema tenta-se chamar as atenç�es como um incentivo e divulgaç�o ainda maior no contexto de LBS. Consecutivamente surge o interesse de criar novos sistemas genuinamente brasileiros, para assim termos um desenvolvimento tecnol�gico em um segmento altamanete lucrativo, devido � alta agregaç�o de valor aos serviços, onde a localizaç�o e sua descriç�o s�o os principais componentes.

�

5.�� Refer�ncias

�Fortes, Fernando Jos� Clemente (2006) �Metodologia de Avaliaç�o da Qualidade dos Serviços Dependentes da Posiç�o (Localizaç�o em Sistemas M�veis� Dispon�vel em: http://campus.fct.unl.pt/ama/tsig/slides/lbn26.ppt., Dezembro.

Haiges, Sven (2003) The Location API, http://jdj.sys-con.com/read/37747.htm, Agosto.

Process, Java Community (2006) �Location API for Java� 2 Micro Edition Version 1.0.1�, Dispon�vel em http://www.forum.nokia.com/main/resources/technologies/java/documentation/java_jsr. Agosto.

Wick, Ryan e Lyon, Zane (2006) �Practical Applications of JSR 179�, Dispon�vel em: http://developers.sun.com/learning/, Agosto.

Parsons, David (2005) �The Java Location API - Knowing where you are is half the battle�, Dispon�vel em: http://www.ddj.com/dept/java/184406388, Setembro.

Venturella, Adam (2006) �J2ME - Location Based Data�, Dispon�vel em: http://www.google.com/notebook/public/04105482259393985038/BDUYhIgoQtqSQzbsh, Setembro.

Quaddus, M.A., Noland, R.B., e Ochieng, W.Y. (2005) �The effects of navigation sensors and digital map quality on the performance of map matching algorithms�, Dispon�vel em: http://www.geomatics.cv.imperial.ac.uk/html/ResearchActivities/publicationDetails.asp?PublicationID=650, Dezembro.

Loytana, Kimmo. JSR 179: Location API for J2ME. Java Community Process.
Dispon�vel em: <http://jcp.org/en/jsr/detail?id=179>. Acesso em: 19 set. 2005.

[1] Servlet: Programa em JAVA que � carregado dinamicamente para atender �s solicitaç�es de um servidor web, ou seja, � uma extens�o para aumentar��sua funcionalidade, normalmente utilizados para busca de dados. Usam por padr�o conex�es do tipo soquete HTTP.

[2] Thread: � uma forma de um processo dividir a si mesmo em duas ou mais tarefas que podem ser executadas simultaneamente, O suporte � thread � fornecido pelo pr�prio sistema operacional

[3] A n�vel local: as brasileiras Prolan Soluç�es Integradas (atividades em integraç�o de sistemas) e a empresa Inteliredes atividades em localizaç�o e em LBS de celular), escolheram a tecnologia de localizaç�o da empresa americana SigmaOne atividade em desenvolvimento de soluç�es de alta precis�o em localizaç�o de DM) fizeram um estrat�gico acordo no romissor e crescente mercado brasileiro de LBS para apoiar o m-commerce no Brasil.

Vers�o adaptada do artigo �Sistemas Baseados em Localizaç�o em um Mundo Sem-fio com J2ME e API Location� aprovado no 3� SBSI � Simp�sio Brasileiro de Sistemas de Informaç�o (realizado no per�odo de 8 a 10 de novembro de 2006) e aprovado no 2� CISTI - Confer�ncia Ib�rica de Sistemas e Tecnologias de Informaç�o (realizado no per�odo de 21 e 23 de Junho de 2007).

�

LBS com a facilidades da API Location (J2ME): Proposta de Arquitetura

Artigos relacionados