Numa primeira fase do projeto, foi necessário implementar um servidor que tivesse como características: a capacidade de armazenar dados num SGBD, assim como a capacidade de desenvolvimento numa linguagem server-side, neste caso a linguagem PHP. A escolha desta linguagem está relacionada com o objetivo, não apenas de desenvolver o backoffice, como o de utilizar as suas potencialidades no uso do JSON, notação de objetos em JavaScript, que possibilita a troca de dados entre sistemas distintos, que geram um resultado leve e facilmente interpretável com outras linguagens.
Para tal, foi utilizado o WAMPServer, que é nada mais que um instalador de um pacote que contém um servidor Apache, juntamente com o PHP e um SGBD, neste caso, o MySQL, baseado em SQL e que conta com a interface gráfica de administração phpMyAdmin.
Neste trabalho foi instalado o Apache Server na versão 2.4.9, o qual vem integrado no wampserver. Uma vez instalado dá ao utilizador uma configuração automática, sendo apenas necessário configurar um ficheiro para abrir o porto ou port HTTP (port: 80 ou 8080). No entanto, a abertura da HTTP port necessita de algumas restrições e é apenas numa subpasta da pasta pública, por defeito, que o cliente da aplicação deve ter acesso, como indica a Figura 16, em que a pasta partilhada se encontra a negrito e onde estão alojados todos os ficheiros relativos ao projeto.
Figura 16: Esquema de Diretorias do Servidor em Árvore
Para permitir o acesso a esta pasta é necessário, como já foi referido, fazer algumas alterações no ficheiro principal de configuração do servidor, o httpd.conf, presente na diretoria indicada na Figura 17, que também está com o caminho a negrito. Por defeito, este ficheiro vem à partida configurado para garantir acesso total ao localhost na pasta pública www/. No entanto, por questões de segurança mínima, esta pasta deve ser assim mantida e criado outro módulo de configuração para uma nova pasta, neste caso a android_connect/, a negrito na Figura 16, com a opção “Require all granted”, ou seja, acesso externo garantido a todos os dispositivos conectados ao servidor como está apresentado na Figura 18. Após as alterações efetuadas, o servidor deverá ser reiniciado, de modo a ser atualizado.
Figura 17: Esquema da Diretoria do Ficheiro httpd.conf em Árvore
2. Aplicação Móvel
Para desenvolvimento desta aplicação foi escolhida a linguagem Java, linguagem nativa no desenvolvimento para sistema operativo Android a par do C# ( C Sharp). Como ambiente integrado de desenvolvimento (IDE), foi utilizado o Android Studio 1.0.1, atualmente o Integrated Development
Environment oficial da Google para o sistema operativo Android em substituição do Eclipse. Numa fase
de testes foi utilizado um emulador com a última versão Android, a 5.0.1 ou Lollipop, assim como um dispositivo móvel em modo de depuração USB com a versão 4.0.3 ou Ice Cream Sandwich, ambos com as respetivas Google APIs presentes.
1. Diagrama de Classes
O diagrama de classes relativo à aplicação móvel, apresentado na Figura 19, representa as classes utilizadas no desenvolvimento da aplicação. No desenvolvimento em Java para Android, estas classes poderão ou não ser activities. Uma activity poderá ser uma janela em full-screen ou uma janela flutuante. Nesta aplicação foram apenas utilizadas activities de full- screen, sendo que cada uma representa os possíveis passos que podem ser seguidos durante a navegação na aplicação, isto é a mudança de páginas.
Iniciando a aplicação na MainActivity(), esta poderá ou não ter este nome, a qual interage com duas activities e uma classe de background, neste caso o JSONParser(). Esta activity representa a página inicial da aplicação onde são inseridos os dados de autenticação ou redirecionamento para uma outra activity, a RegisterActivity().
A RegisterActivity(), como o nome indica, é responsável pelo registo de um novo utilizador, enquanto que a outra activity diretamente ligada à MainActivity(), a MapActivity(), tem uma segunda background class associada, o GPSTracker(), responsável por interagir com o sistema de GPS existente nos smartphones.
A MapActivity(), numa situação em que o utilizador tenha como objetivo adicionar um novo elemento de biodiversidade, passa por três novas activities – ListarBDiversidade(), InfoBDiversidade() e PictureActivity(), sequencialmente – em que a primeira é responsável por apresentar a biodiversidade existente nos locais sob forma de lista, a segunda pela informação relativa ao elemento da biodiversidade após ter sido selecionado na activity anterior e o terceiro
que tem como finalidade capturar imagens. Associado ao ListarBDiversidade(), existem mais duas activities, também estas sequenciais, em que o utilizador poderá visualizar a lista de fotografias associadas a um determinado elemento de biodiversidade e a seguinte em que é apresentada a imagem em singular.
2. Interação JSON
Para permitir a troca de dados entre cada activity da aplicação móvel e o servidor, é necessário uma classe que faça a textualização dos valores a enviar e a receber por parte da aplicação. Para tal, está presente nesta aplicação uma classe denominada JSONParser(), que para cada activity passa a objecto, com o objetivo de tratar quer dos pedidos (“GET”), como dos envios (“POST”). No diagrama seguinte (Figura 20), estão representados à esquerda as classes que dão uso a este método de troca de dados, e à direita estão os ficheiros que geram objetos JSON. As setas de fluxo representam os pedidos, se o sentido for o dos ficheiros PHP, e os envios caso se dirija às classes.
A utilização deste mecanismo é muito importante, pois o JSON cria outputs sob a forma de string ou array, demorando muito menos tempo no seu envio e receção, e são igualmente interpretadas por várias linguagens, como é caso do PHP e do Java.
3. Funcionamento da Aplicação
Nesta fase é descrita com recurso a imagens a forma como o utilizador e o administrador interagem com a aplicação.
Ao iniciar a aplicação, aparece uma página inicial em que são dadas duas opções ao utilizador, uma de autenticação e outra de registo, Figura 21, no entanto a Activity inicial (neste caso, a layer ou página), surge em primeiro plano com quatro elementos – EditText, dois campos de entrada de texto, e dois Buttons, entenda-se butões, associados aos EditText para autenticação e outro para efetuar registo, Signup. O primeiro EditText, aceita valores textuais para a introdução de um username, e vem, assim como o campo seguinte, com o título inline,
ou seja, no próprio campo de preenchimento, com os valores username e password. O EditText destinado à introdução da password tem a particularidade de possuir um inputType específico, destinado a introdução das mesmas, fazendo-se representar por pontos ao invés de texto, para proteção de dados.
Selecionado o botão destinado ao registo, apresenta-se a página de formulário para esse efeito, na Figura 22. Nesta, encontram-se dois botões e três campos de entrada de texto. É mostrado um botão inicial no qual é possível o retrocesso, ou encaminhamento para a autenticação. Seguem-se os campos de entrada de texto para efetuar o registo. Contém três campos, um destinado ao nome de utilizador, ou username, introdução de password , e introdução do correio eletrónico. À imagem do formulário de autenticação, o inputType é também do tipo password, o que faz com que o texto introduzido seja visualizado como pontos. Existem ainda algumas condições no que toca à introdução de dados: o username tem que ter no mínimo 6 caracteres; a password deverá ter 8 e o endereço de correio eletrónico, 11 caracteres. Após a conclusão da introdução dos dados o utilizador deve “pressionar” o botão para prosseguir (“Continue”) e é redirecionado para a página de autenticação.
Após autenticação, é apresentado o mapa com os marcadores associados às espécies já georreferenciadas onde é possível obter o nome comum da espécie, title, assim como o Reino a que pertencem, snippet, em que um é correspondente ao título, apresentado a negrito, e o
Figura 22: Página de Registo - Aplicação Móvel
seguinte um sub-título ou descrição, representado na Figura 23. É disponibilizado automaticamente, pela Google Maps API, o botão que encaminha para a vista inicial do mapa que indica onde está o utilizador. Ao contrário do que acontece com as páginas anteriormente descritas, nesta existe apenas um Fragment. A este está associado um MapFragment, delimitando assim, a área em que é visível o mapa, como um elemento inserido na activity que a Google disponibiliza diretamente para mapas à semelhança de outros como EditText,
TextView e ImageView. De referir que, para maior facilidade em obter a coordenada correta, é
necessário ter o serviço de GPS ativado.
Uma vez que o mapa, como elemento de destaque para melhor aproveitamento do enquadramento geográfico, se encontra a ocupar a totalidade do ecrã, é na action bar que é possível a adição de um elemento de biodiversidade. Neste exemplo, a action bar não se encontra visível, mas é possível recorrer a ela através da seleção dos botões físicos do
dispositivo, visível na Figura 24.
Após selecionar a opção “Adicionar”, é aberta uma activity. Nesta activity, é apresentada uma lista da biodiversidade existente no local onde se encontra o utilizador, o qual pode efetuar uma filtragem textual para encontrar mais facilmente o que pretende, como é exemplificado na Figura 25. Para a criação desta activity foi necessário recorrer a uma ListView, elemento para criar listagens, em que para cada linha é necessário definir num ficheiro específico os campos que irá ter. Neste caso, um elemento da lista, ou linha, tem a si associados três elementos – dois TextViews e um ImageView. Como nesta activity os elementos são carregados através do número de identificação que os define na base-de-dados, e uma vez que este valor não é importante no contexto visual, encontra-se escondido, possuindo a opção gone nas suas propriedades, que tem como objetivo esconder esse valor. O campo seguinte é destinado à
Figura 24: Página c/ Mapa e Menus Seguintes - Aplicação Móvel
apresentação de uma imagem, com o campo ImageView. Neste caso específico, é apresentada uma imagem genérica de um elemento de biodiversidade, seguindo-se outro campo de texto, TextView, com a finalidade de apresentar o nome comum. Para organização das linhas da lista, existe o campo ListView que dispõe os elementos por número de identificação da base-de- dados. Para efetuar a filtragem dos elementos por texto, está associado ao campo destinado ao nome comum das espécies, um campo de entrada de texto, EditText, que elimina em tempo real os campos que não correspondam ao texto introduzido, Figura 26.
Figura 25: Página de Listagem da Biodiversidade - Aplicação Móvel
Segue-se após esta listagem, a seleção do elemento da biodiversidade a georreferenciar que, ao ser selecionado abre numa nova activity toda a informação a si associada, representado na Figura 27. Apresenta a imagem introduzida previamente no backoffice, juntamente com todas as informações associadas, neste caso a ficha científica, com informações como por exemplo o Reino, Classe e Ordem a que pertence e ainda as coordenadas geográficas, com precisão decimal, do local atual onde se encontra o utilizador e, neste caso, o referido elemento de biodiversidade.
Por fim, antes de regressar ao mapa com o georreferenciamento concluído e após esta listagem de características, o utilizador é encaminhado para uma activity, na qual é apresentado um botão que, ao ser pressionado, permite fotografar o elemento avistado.
Figura 26: Página de Listagem da Biodiversidade c/ Conteúdos Filtrados - Aplicação Móvel
Esta função destinada a fotografar elementos de biodiversidade, Ilustrações 28 e 29, faz um preview da mesma e dá a possibilidade de o utilizador poder tirar novamente uma fotografia ou aprová-la, sendo redirecionado para a página inicial, onde se encontra o mapa, desta vez já com o marcador inserido no local devido. A foto tirada é armazenada automaticamente numa pasta criada pela aplicação, denominada georeferenced/. Pode relatar-se que este processo de captura, armazenamento no dispositivo e envio para o servidor se encontra inserido na mesma activity. A existência de dois Buttons e uma ImageView, que numa fase inicial contém apenas um dos botões visível, isto porque ao iniciar a câmara, o sistema só aceita efetuar a marcação do elemento de biodiversidade se existir uma fotografia que comprove o avistamento, ou seja, se o utilizador não captar a fotografia, o botão de regresso ao mapa não fica disponível.
Figura 27: Página c/ Elemento de Biodiversidade Selecionado
Figura 28: Página de Captura de Imagem - Aplicação Móvel
Figura 29: Página c/ Imagem Capturada - Aplicação Móvel
3. Aplicação Web de Backoffice
Do lado do servidor, foi desenvolvida uma aplicação web com a finalidade de fazer a gestão da biodiversidade disponível para o utilizador poder consultar. Esta aplicação web muito simples tem interação direta com a base-de-dados e foi desenvolvida tendo como recurso algumas linguagens, como o PHP, recurso a query strings de MySQL, com recurso às funções no PHP encontradas. Para criação de alguns elementos como hiperligações e a tabela é utilizado o HTML, juntamente com o JavaScript para janelas de decisão. Como editor de código foi utilizado um bloco de notas mais avançado, o Notepad++ no qual é possível editar todas as linguagens referidas anteriormente e outras não utilizadas, como é o caso das CSS, que permitem melhorar visualmente as aplicações web.
1. Funcionamento da Aplicação Web de Backoffice
No que toca ao funcionamento do administrador, existe uma página a que só o próprio pode aceder através das credenciais corretas, como exemplificam as Ilustrações 30, 31 e 32.
Figura 30: Formulário de Autenticação de Administrador - Aplicação Web de Backoffice
Para tal, este sistema de autenticação apenas aceita a autenticação de um utilizador, com credenciais definidas diretamente no ficheiro de desenvolvimento, com a extensão .php. No entanto, os dados de autenticação não são atualmente seguros, visto que possui as credenciais genéricas de teste, em que o utilizador e a password são ambas “admin”. Para garantir uma maior segurança, o backoffice é dotado de um sistema de cookies com o objetivo de terminar a sessão automaticamente passado algum tempo. Neste caso, a sessão termina ao fim de trinta minutos ou 1800 segundos, uma vez que o sistema trabalha em segundos.
Após efetuada a autenticação é apresentada uma tabela com os elementos adicionados juntamente com uma coluna em que é possível adicionar e remover cada elemento. Fora da tabela existe um campo de adição de elementos, juntamente com a opção de logout, ou seja, terminar autenticação.
Figura 31: Formulário de Autenticação de Administrador c/ Valores Inseridos - Aplicação Web de Backoffice
Figura 32: Resposta a Valores Incorretos - Aplicação Web de Backoffice
Na Figura 33, está exemplificada a tabela de biodiversidade, com os valores repetidos consoante os títulos das colunas, com o objetivo de garantir que os valores introduzidos das espécies de biodiversidade, correspondam à coluna correta da tabela. Para cada linha da tabela, pode verificar-se as opções de edição e eliminação dos campos para cada espécies.
Ao contrário da aplicação móvel, a aplicação web destinada ao backoffice não dispõe de classes para o seu funcionamento. Na Figura 34, é apresentado o modo como interage a aplicação em relação às páginas que a formam.
Figura 33: Página c/ Administrador Autenticado - Aplicação Web de Backoffice
Figura 34: Diagrama de Componentes - Aplicação Web de Backoffice