Desenvolvimento em Android

Embora a linguagem de programação utilizada seja a linguagem JAVA existem al- gumas diferenças no que toca ao desenvolvimento de aplicações móveis, em relação ao desenvolvimento de outras aplicações usando a mesma linguagem. O ambiente Android é muito gráfico e como tal a sua programação tem um grande enfoque nessa componente. Ao criarmos um projeto de Android, é automaticamente criada uma Activity. Uma

Capítulo 3. Sistema de Navegação Indoor 25

Activityé uma componente da aplicação que fornece uma interface com a qual os utiliza- dores podem interagir, com um propósito, como enviar um email ou tirar um fotografia, escolher uma música ou interagir com um mapa. Para cada atividade que o utilizador pretende executar é criada uma Activity. Esta funciona para ser criado toda interface da aplicação móvel. Geralmente uma aplicação tem vários Activities estão ligadas entre si. Como mostra a figura 3.3, uma Activity tem um período de vida que está associado com a funcionalidade que o utilizador pretende usufruir.

Figura 3.3: Período do ciclo de vida de uma Activity

Como mostra a figura 3.3, existem alguns métodos que são essenciais para definir o estado de vida de uma Activity. Os estados de vida de cada uma são Paused, Resumed e Stopped. Esta imagem foi retirada de [28]].

• Resumed Este estado indica que a Activity está visível e que qualquer utilização pode ser realizada, por parte do utilizador.

• Paused Neste estado indica que uma outra Activity está ativa e tem o foco do utili- zador, mas no entanto está continuamente visível no ecrã.

• Stopped Este estado refere-se a uma Activity que está completamente em back- groung, mas no entanto ainda está viva.

Os estados de cada Activity são controlados por métodos que são incorporados na classe onde foi criada a Activity. Os métodos referidos são:

• onCreate() - Chamado quando a Activity é criada pela primeira vez e devem ser inicializados todos os componentes essenciais desta. É neste método também que é chamado o Layout definido para a mesma. É sempre seguido pelo método onStart(). • onRestart() - Chamado depois da Activity ser interrompida, pouco antes de esta ser

iniciada novamente. É sempre seguido pelo método onStart().

• onStart() - Chamado imediatamente antes da Activity tornar-se visível para o utili- zador. É seguido pelo método onResume() se esta vem para primeiro plano, ou pelo método onStop() se se vai tornar oculta.

• onResume() - Chamado imediatamente antes da Activity passar a ser visível e a interagir com o utilizador. Neste ponto, esta está no topo da pilha de Activities.É sempre seguido pelo método onPause().

• onPause() - Chamado quando o sistema está prestes a começar a retomar outra Ac- tivity. Este método é geralmente usado para confirmar as alterações não guardadas, dados persistentes e outras coisas que podem estar a consumir recursos do CPU. Este método deve fazer tudo rapidamente, porque a próxima Activity não será reto- mada enquanto este não termine o trabalho. É seguido pelo método onResume() se a atividade volta ao primeiro plano, ou pelo método onStop() se se vai torna invisível para o utilizador.

• onStop() - Chamado quando a Activity já não é visível para o utilizador. Isso pode acontecer porque esta está a ser destruída, ou porque outra Activity (seja uma exis- tente ou uma nova) foi retomada e está em primeiro plano. É seguido pelo método onRestart()se a atividade está a voltar para interagir com o utilizador, ou pelo mé- todo onDestroy() se essa atividade vai ser destruída.

• onDestroy() - Chamado antes da Activity ser destruída. Esta é a chamada final que a Activity irá receber. Este método poderá ser chamado, quer porque a Activity está a ser destruída (alguém chamou o método finish()), ou porque o sistema está a a destruir para economizar espaço.

Todos as configurações de uma aplicação móvel estão confinadas a um só ficheiro, AndroidManifest.xml. Este ficheiro vai apresentar a informação essencial sobre a aplica- ção móvel ao sistema Android. Toda esta informação é lida antes sequer de lido o código

Capítulo 3. Sistema de Navegação Indoor 27

da aplicação em si. Entre outra informação, este ficheiro contém as Activities criadas, os servicesentre outros. Neste ficheiro estão especificadas as permissões necessárias para que a aplicação móvel possa aceder a partes do sistema operativo ou mesmo interagir com outras aplicações instaladas. Outro tipo de informação importante contida neste ficheiro são os mínimos da versão do SO Android que a aplicação permite.

Em relação à interface, o ficheiro responsável por manter a informação acerca de todo o layout da aplicação móvel denomina-se, activitymain.xml. Este nome porém define- se consoante o nome da Activity correspondente. Como tal existem tantos ficheiros de layout, quantas Activities foram criadas. Neste tipo de ficheiro estão armazenados todos os elementos gráficos relativos às Activities correspondentes. Como exemplo se numa Activityexistirem botões, existirá no ficheiro de layout informação acerca desses mesmo botões, como ids para serem identificados nas classes programadas, tamanhos, entre ou- tras características.

3.3

Considerações Finais

Neste capítulo foram apresentados as características do Sistema de Navegação Indoor, através da divisão da arquitetura geral do sistema em componentes, a da Base de Dados, a do Servidor e a do Cliente/Aplicação Móvel. Foi introduzido o funcionamento, deixando uma visão geral de cada uma.

Como toda a aplicação móvel irá ser desenvolvida para o Sistema Operativo Android, foram introduzidas algumas noções básicas de como é constituída a arquitetura do An- droid, bem como algumas das suas características da linguagem de programação.

No próximo capítulo serão apresentadas as soluções de implementação das compo- nentes descritas, neste capítulo, bem como a sua ordem de implementação.

Capítulo 4

Concretização do Sistema Navegação

Indoor

Neste capítulo serão apresentados os detalhes de concretização do trabalho desenvol- vido. Em primeiro lugar será abordado, e como referido em 3.1, a divisão do sistema de navegação indoor, no serviço baseado no posicionamento do dispositivo móvel e no sistema de navegação geral. O primeiro serviço refere-se ao posicionamento, no espaço onde está inserido, de cada utilizador e o segundo refere-se à navegação do próprio no espaço indoor. Para que o serviço de navegação funcione corretamente, o serviço de po- sicionamento terá de fornecer o input da localização do utilizador. Em segundo lugar será dividida por componentes, toda a arquitetura do sistema geral, onde serão apresentadas as suas características, bem como a modo de implementação. Para clarificar e explicar melhor toda a implementação das componentes do servidor e do cliente/aplicação móvel foram criados diagramas para cada uma destas.

4.1

Considerações Gerais

Como pode ser observado na figura 3.1, e como referido no início do capítulo anterior, na secção 3.1, a arquitetura é composta por uma componente Cliente/Aplicação móvel, uma componente Servidor e uma componente Base de Dados.

Com base no planeamento que foi efetuado e referido na secção 1.4, a primeira com- ponente a ser implementada foi a Base de Dados. Como primeira fase de implementação de todo o sistema optou-se por começar por desenvolver a base de dados que iria arma- zenar os pontos de interesse identificados ao longo do edifício do caso do estudo. Numa primeira instância, esta base de dados armazenou também a informação acerca dos AP espalhados pelo edifício. No entanto e após a investigação acerca das formas de armaze- namento de informação geográfica foi optado por criar uma base de dados local inserida no dispositivo da aplicação móvel. Com esta abordagem a componente da Base de Dados ficaria apenas a armazenar a informação dos pontos de interesse.

No contexto do desenvolvimento do projeto, a componente do Servidor foi a segunda 29

a ser desenvolvida. O próprio desenvolvimento da mesma foi efetuado de forma faseada. Numa primeira fase foi desenvolvido uma pequeno programa que pudesse comunicar com a componente da Base de Dados. Esta ligação serviu também para que fossem efetuados testes à base de dados. Estes testes eram simples chamadas, com input das coordenadas geográficas de uma localização, dentro do edifício. Como resposta era obtida informação acerca dos pontos de interesse, armazenados, que estivessem a uma distância definida do ponto dado como input. Numa segunda fase foi implementado o modelo de Cliente- Servidor para realizar as comunicações com a componente do Cliente. Todo este processo irá ser descrito com maior detalhe na subsecção do Servidor 4.3.

Como última componente a ser desenvolvida temos o Cliente/Aplicação Móvel. Como já referido anteriormente, esta componente é constituída por uma aplicação móvel, de- senvolvida para o SO móvel Android e que permite aos utilizadores usufruírem de todo o sistema de navegação indoor. Esta componente começou por ser desenvolvida com a implementação do modelo de comunicação Cliente-Servidor e posteriormente foram de- senvolvidas todas as funções relacionadas com a parte física do dispositivo móvel, tais como a ligação do dispositivo aos AP, a ligação ao serviço de WMS fornecido através do software ArcGIS Server e ainda a inclusão das funções dos sensores embutidos no próprio dispositivo.

Nas secções seguintes serão apresentadas algumas características de cada compo- nente, como as ferramentas utilizadas, as linhas de código necessárias e os tipos de dados utilizadas para o desenvolvimento das componentes. A ordem da descrição das compo- nentes é coincidente com a ordem de implementação referida anteriormente.