Artigos Mobile 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.

API.JPG

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.

JudeLBS.JPG

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();

     …
    }

}

 

servlet.JPG

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).