Desafios e Limita¸ c˜ oes

Podemos destacar alguns desafios ou limita¸c˜oes encontrados no desenvolvimento do prot´otipo apresentado. Em rela¸c˜ao aos servi¸cos Web suportados pela aplica¸c˜ao, n˜ao foi poss´ıvel emularmos um conjunto maior de servi¸cos remotos, tais como de localiza¸c˜ao, tr´afego, emergˆencias, dentre outros. A integra¸c˜ao do servidor de eventos com outros m´odulos tamb´em foi comprometida devido a n˜ao conclus˜ao de algumas funcionalidades dependentes, conforme apresentado na Figura 4.3. Alguns m´odulos

Caracter´ıstica JME Android

Modelo de Graphical User

Interface (GUI)

Componentes do Liquid

Crystal Display GUI

(LCDUI)

Atividades e componentes de interface (Widgets) Mecanismo de persistˆencia local Record Management System Provedores de conte´udo

Ativa¸c˜ao de componentes Program´atico Inten¸c˜oes

Conectividade de dados Generic Connection

Framework

HTTP Commonse Java Net API

Concorrˆencia Processos (threads) Provedores e consumidores

de servi¸cos

Ciclo de vida da aplica¸c˜ao MIDP Propriet´ario

Persistˆencia permanente N˜ao possui SQLLite

Mecanismo de permiss˜oes MIDP Propriet´ario

Suporte a Mapas N˜ao impl´ıcito Sim

Tabela 4.3. Comparativo de recursos entre o JavaME e o Android.

que foram postergados incluem: (a) adapta¸c˜ao (Adp) no que diz respeito ao consumo de conte´udo (e.g., texto, ´audio e v´ıdeo), (b) de contexto f´ısico (PaC) no que diz respeito `a informa¸c˜oes de tr´afego e de localiza¸c˜ao e (c) de escalonamento de atividades (AS) com informa¸c˜oes relativas a atividades executadas ou n˜ao executadas pelo turista e sugest˜oes de atividades levando em considera¸c˜ao a localiza¸c˜ao do usu´ario.

O modelo de desenvolvimento de aplica¸c˜oes m´oveis proposto pela plataforma Android trouxe tamb´em um desafio significativo ao trabalho, j´a que ela difere de todos os outros modelos de desenvolvimento de aplica¸c˜oes m´oveis existentes antes deste, tais como o Mobile Information Device Profile (MIDP) 2.0 [53]. O Android utiliza padr˜oes de desenho e de desenvolvimento diferentes do MIDP na cria¸c˜ao das aplica¸c˜oes e servi¸cos executados sobre a plataforma. Algumas diferen¸cas incluem o modelo de interface gr´afica baseado em atividades, mecanismo de persistˆencia local via provedores de conte´udo e a ativa¸c˜ao de componentes atrav´es de inten¸c˜oes, conforme apresentado na Tabela 4.3. Esta nova metodologia de desenvolvimento exigiu um maior tempo para o entendimento de como as aplica¸c˜oes m´oveis s˜ao constru´ıdas sobre plataforma a partir dos conceitos definidos pelo servidor de eventos e aplica¸c˜ao m´ovel propostos.

Al´em dos desafios j´a apresentados acima sobre a plataforma Android, outras dificuldades foram tamb´em encontradas na utiliza¸c˜ao de sua API. A API do Android sofreu frequentes atualiza¸c˜oes durante o desenvolvimento deste trabalho. Nos primeiros prot´otipos implementados, utilizamos a vers˜ao 0.8 para a constru¸c˜ao das interfaces gr´aficas e do mecanismo de comunica¸c˜ao com o servidor. Durante o desenvolvimento, a vers˜ao 1.0 e 1.1 foram disponibilizadas, com diversas altera¸c˜oes em sua API, resultando em problemas de compatibilidade entre a nova vers˜ao e componentes j´a desenvolvidos na vers˜ao anterior. Optamos em migrar o prot´otipo para a vers˜ao 1.1 e, logo ap´os, para a vers˜ao 2.0, j´a que as migra¸c˜oes poderiam ser um risco para a finaliza¸c˜ao da aplica¸c˜ao m´ovel. Atualmente, o Android est´a na vers˜ao 2.1 de sua API.

4.5. Aplica¸c˜ao da Arquitetura Proposta 97

Componente DroidGuide

Processador de eventos no servidor

Processamento de eventos de clientes m´oveis e servi¸cos Web

Container de eventos Armazenamento de eventos tur´ısticos Gestor de subscri¸c˜oes Assinatura por eventos tur´ısticos Processador de eventos

no servidor

Coordena os componentes acima no guia tur´ıstico Container de servi¸cos

Web

Container de servi¸cos Web tur´ısticos

Container de

aplica¸c˜oes

Container da aplica¸c˜ao tur´ıstica Processador de eventos

no cliente

Processa eventos no Android Gestor de perfil e

contexto

Gerencia informa¸c˜oes do usu´ario e tur´ısticas no Android Aplica¸c˜oes e servi¸cos Aplica¸c˜ao cliente desenvolvida no Android

Sensores no ambiente Sensores presentes no dispositivo m´ovel e ambiente

Tabela 4.4. Componentes da arquitetura do servidor de eventos aplicada no prot´otipo DroidGuide.

4.5

Aplica¸c˜ao da Arquitetura Proposta

Esta se¸c˜ao tem como objetivo apresentar a rela¸c˜ao do prot´otipo desenvolvido neste trabalho com a arquitetura do servidor de eventos proposta. Esta se¸c˜ao tamb´em discute como a arquitetura proposta foi utilizada no estudo de caso do guia tur´ıstico desenvolvido neste trabalho. Conforme apresentado na Figura 3.14, a arquitetura do sistema proposto neste trabalho ´e composta por diversos componentes e m´odulos. Cada um destes componentes possui responsabilidades definidas para o prot´otipo desenvolvido neste trabalho. Utilizamos a arquitetura definida para o servidor de eventos para o desenvolvimento dos servi¸cos necess´arios na aplica¸c˜ao. Um mapeamento entre os componentes definidos na arquitetura do servidor de eventos e do prot´otipo DroidGuide pode ser visualizado na Tabela 4.4.

No guia tur´ıstico DroidGuide, o servidor de eventos tem como responsabilidade a capta¸c˜ao dos eventos vindos da aplica¸c˜ao m´ovel e de servi¸cos Web. Neste processo, o servidor utiliza os componentes de assinatura de eventos, processamento e armazenamento de eventos presentes no lado do servidor remoto de dados, conforme a Figura 4.18. O gerenciador de subscri¸c˜oes ´e respons´avel por captar as solicita¸c˜oes de assinatura em eventos, servi¸cos Web e atra¸c˜oes tur´ısticas atrav´es de t´opicos ou canais de interesse. Estes t´opicos s˜ao definidos por atra¸c˜oes, servi¸cos ou pelo pr´oprio usu´ario em casos de eventos de interesse tur´ıstico. O processador de eventos ´e respons´avel por captar eventos vindos do lado do cliente e tamb´em do servidor, armazen´a-los no container de eventos ou Event Container e enfileirar eventos para notifica¸c˜ao em fun¸c˜ao das assinaturas existentes no sistema. No guia tur´ıstico, quando eventos s˜ao criados por servi¸cos remotos, o processador de eventos efetua o enfileiramento de notifica¸c˜oes para o usu´ario m´ovel em fun¸c˜ao de seus interesses em receber notifica¸c˜oes referentes

Figura 4.18. Mapeamento dos componentes no prot´otipo DroidGuide em fun¸c˜ao da arquitetura proposta.

aos eventos.

Dois outros componentes adicionais oferecem recursos a aplica¸c˜ao servidora do guia tur´ıstico. O container de servi¸cos Web baseados em informa¸c˜oes (IBWS Proxy) ´e respons´avel por agrupar os servi¸cos Web dispon´ıveis para usu´arios m´oveis, tais como servi¸cos meteorol´ogicos, de tr´afego, de servi¸cos sens´ıveis `a localiza¸c˜ao, dentre outros. No caso do guia tur´ıstico, este componente fornece ao gerenciador de subscri¸c˜oes a listagem de servi¸cos remotos dispon´ıveis para o usu´ario m´ovel e o processamento de eventos vindos do cliente. Desta forma, os servi¸cos Web utilizam as informa¸c˜oes de perfil e contexto do usu´ario m´ovel providas atrav´es da publica¸c˜ao e notifica¸c˜ao de eventos a fim de prover atividades e recursos relacionados ao turismo. O container de aplica¸c˜oes localizado no servidor gerencia as instancias de aplica¸c˜oes remotas utilizadas pelo guia tur´ıstico, como por exemplo, autentica¸c˜ao, sele¸c˜ao de atividades tur´ısticas, comunica¸c˜ao entre usu´arios m´oveis, localiza¸c˜ao do usu´ario e gest˜ao de marcos tur´ısticos. O container de aplica¸c˜oes comunica diretamente com o servidor de eventos a fim de oferecer diversas informa¸c˜oes do usu´ario m´ovel e de atra¸c˜oes tur´ısticas dispon´ıveis no sistema.

No lado cliente, a aplica¸c˜ao m´ovel possui o processador de eventos, o gerenciador de informa¸c˜oes de perfil e contexto e a aplica¸c˜ao contendo diversos servi¸cos a serem oferecidos ao usu´ario m´ovel e a aplica¸c˜ao m´ovel. O processador de eventos no cliente recebe requisi¸c˜oes de mudan¸cas de informa¸c˜oes de perfil e contexto vindas do gerenciador e as envia para serem processadas pelo servidor de eventos no servidor.

4.6. Resultados obtidos 99

Por exemplo, quando o usu´ario solicita uma mudan¸ca no seu contexto l´ogico, ela ´e detectada pelo gerenciador de perfil e contexto e, ap´os a detec¸c˜ao, ela ´e enviada para o processador de eventos que ir´a finalmente envi´a-la para o servidor para armazenamento e processamento.

Em rela¸c˜ao aos sensores de ambiente, o guia tur´ıstico utiliza recursos no cliente e servidor para ”emular”informa¸c˜oes coletadas para serem utilizadas pelo servi¸co e aplica¸c˜ao. No caso do cliente, as informa¸c˜oes coletadas pelo dispositivo m´ovel e por sensores presentes no ambiente s˜ao utilizadas na defini¸c˜ao do perfil e contexto local do usu´ario m´ovel. Alguns exemplos de informa¸c˜oes de contexto local incluem estado do usu´ario, localiza¸c˜ao, temperatura ambiente, dentre outros. No lado do servidor, informa¸c˜oes coletadas por sensores e servi¸cos remotos compˆoem as informa¸c˜oes de perfil e contexto remoto do usu´ario m´ovel. As informa¸c˜oes remotas incluem condi¸c˜ao de tr´afego, clima, proximidade entre usu´arios e servi¸cos tur´ısticos, dentre outros. A uni˜ao das informa¸c˜oes locais e remotas compˆoe o contexto representado ao usu´ario m´ovel, contendo informa¸c˜oes locais e remotas referentes ao seu estado e interesses.

4.6

Resultados obtidos

Os resultados obtidos a partir do prot´otipo DroidGuide podem ser visualizados no cap´ıtulo 6. Estes resultados incluem a cria¸c˜ao de um evento clim´atico e a notifica¸c˜ao deste evento no dispositivo m´ovel atrav´es do servidor de eventos proposto.

Cap´ıtulo 5