• Nenhum resultado encontrado

Desenvolvimento e implementação de um sistema de gestão de eventos baseado em Android

N/A
N/A
Protected

Academic year: 2020

Share "Desenvolvimento e implementação de um sistema de gestão de eventos baseado em Android"

Copied!
87
0
0

Texto

(1)

Jaime Luís Silva Costa

Desenvolvimento e Implementação de um

sistema de gestão de eventos baseado em

Android

Jaime L uís Silv a Cos ta dezembro de 2013 UMinho | 2013 Desen vol vimento e Im plement ação de um sis tema de g es tão de e

ventos baseado em Android

Universidade do Minho

(2)
(3)

dezembro de 2013

Tese de Mestrado

Ciclo de Estudos Integrados Conducentes ao Grau de

Mestre em Engenharia Eletrónica Industrial e Computadores

Trabalho efetuado sob a orientação do

Professor Doutor Sérgio Adriano Fernandes Lopes

Jaime Luís Silva Costa

Desenvolvimento e Implementação de um

sistema de gestão de eventos baseado em

Android

Universidade do Minho

(4)
(5)

i "I consider that a man's brain originally is like a little empty attic, and you have to stock it with such furniture as you choose. a fool takes in all the lumber of every sort that he comes across, so that the knowledge which might be useful to him gets crowded out, or at best is jumbled up with a lot of other things, so that he has a difficulty in laying his hands upon it. Now the skillful workman is very careful indeed as to what he takes into his brain-attic. He will have nothing but the tools which may help him in doing his work, but of these he has a large assortment, and all in the most perfect order. It is a mistake to think that that lit-tle room has elastic walls and can distend to any extent. Depend upon it there comes a time when for every addition of knowledge you forget something that you knew before. It is of the highest importance, therefore, not to have useless facts elbowing out the useful ones.”

(6)
(7)

iii

Agradecimentos

Gostaria de agradecer ao meu orientador Professor Sérgio Lopes pela orientação, dedicação e tempo disponibilizado, por todas as críticas construtivas e fundamentais para a realização deste projeto de dissertação.

Gostava também de agradecer ao Embedded Systems Research Group (ERSG) do Departamento de Eletrónica Industrial da Universidade do Minho e a todos que lá trabalham, funcionários, pro-fessores, investigadores e alunos, pela ajuda e bom companheirismo demonstrado por todos. Queria também agradecer à minha família, pai, mãe e irmã por toda a paciência e disponibilida-de para me ajudarem e que sem eles não seria possível concluir o meu ciclo disponibilida-de estudos.

Gostaria de agradecer em especial à minha namorada, Carla Barroso, por toda a paciência, dedicação, companheirismo e carinho que me deu durante todo este processo.

Gostaria de agradecer também ao meu grande amigo e colega César Meneses pelo apoio e aju-da que me forneceu ao longo deste ano.

Gostaria de agradecer finalmente aos meus amigos e companheiros de muitos anos, Helena Batista, Pedro Gomes, Pedro Mendes, Jorge Oliveira, Elsa Oliveira e Francisco Dias pelos momentos passados durante este meu percurso académico e pelo apoio e força que sempre me deram.

(8)
(9)

v

Resumo

Atualmente verifica-se que os dispositivos móveis se encontram com maior capacidade e que há

uma crescente utilização de smartphones. Quase todos os dispositivos permitem a obtenção da

localização do mesmo, quer por coordenadas GPS, quer pela rede, os smartphones atuais apre-sentam uma maior capacidade de processamento, uma maior quantidade de memória

disponí-vel e também possuem ligação à internet, seja por Wi-fi ou por 3G. No mercado atual o iPhone

da Apple é um dos lideres de mercado, mas os dispositivos com o sistema operativo Android

têm vindo a apresentar um aumento da utilização que supera largamente todos os outros. O principal objetivo deste projeto consiste em desenvolver e implementar um sistema que permi-ta aos utilizadores criarem e gerirem eventos sociais, como por exemplo, encontros ou reuniões, monitorizarem eventos a decorrer, bem como permitir a inscrição de participantes e acesso à informação individual do evento.

O sistema é composto por uma aplicação web, uma aplicação móvel Android, um web service e

uma base de dados. A aplicação web foi desenvolvida utilizando HTML5, JavaScript, jQuery e

CSS e a API JavaScript da Google Maps. Foi utilizado o servidor Glassfish e JavaEE para o

desenvolvimento do web service e uma base de dados MySQL para armazenar os dados do

sis-tema, a aplicação móvel foi desenvolvida utilizando as ferramentas de desenvolvimento Android. No final foram atingidos os objetivos principais do projeto permitindo a criação, edição e monito-rização de eventos e utilizadores.

Palavras-chave: Web Services, Android, gestão de eventos, JavaEE, Base de Dados, REST, Geolocalização, GlassFish, JavaScript, jQuery.

(10)
(11)

vii

Abstract

Nowadays it can be seen that mobile devices are more advanced and there is a growing use of smartphones. Almost every device allows to get its location either by GPS or by the network. Cur-rent smartphones have a greater processing ability, a larger memory available and also possess internet connection either by Wi-fi or by 3G. In the actual market the Apple's iPhone is one of the market liders but the devices with Android Operating System have been showing an increasing usage that largely overcomes all devices.

The main goal of this project is to develop and implement a system that allows users to create and manage social events, as well as allowing users to enroll events and checking an event detai-led information.

The system is composed by a web application, a mobile Android application, a web service and a database. The web application was developed using HTML5, JavaScript, jQuery and CSS and the Google Maps JavaScript API. It was used the GlassFish server and JavaEE for the development of the web service and was used a MySQL database in order to store all data from the system, the mobile application was developed using the Android Development Tools.

In the end all initial objectives were accomplished allowing users to create, edit, manage and monitor events and users.

Keywords: Web Services, Android, events management, JavaEE, Database, REST, Geolocation,

(12)
(13)

ix

Conteúdo

Capítulo 1 - Introdução... 1 1.1. Problema... 1 1.2. Proposta de Solução ... 2 1.3. Objetivos ... 2 1.4. Estrutura da tese ... 2

Capitulo 2 - Estado da arte ...5

2.1. Aplicações Web para gestão e monitorização de eventos ... 5

2.2. Aplicações móveis para monitorização de eventos ou utilizadores ... 6

2.3. Tecnologias utilizadas ... 7 2.3.1. Java EE ... 7 2.3.2. GlassFish ... 8 2.3.3. Web Services ... 8 2.3.4. Dados JSON ... 11 2.3.5. Localização ... 12 2.3.6. HTML5, CSS, Javascript e jQuery ... 12 2.3.7. Google Maps... 13 2.3.8. Android OS ... 13

2.3.9. Ferramentas de desenvolvimento de Software ... 15

Capítulo 3 - Análise do Sistema ... 18

3.1. Requisitos e restrições do Sistema ... 18

3.2. Arquitetura do sistema ... 19

3.3. Casos de uso ... 19

3.3.1. Aplicação web... 20

3.3.2. Aplicação móvel ... 21

Capítulo 4 - Implementação do Sistema ... 23

4.1. Base de Dados ... 23

4.2. Web Service... 25

4.2.1. CreateEvent ... 29

(14)

x 4.2.3. EnrollEvent ... 31 4.2.4. FBUserLogin ... 32 4.3. Aplicação Web ... 33 4.3.1. Index ... 34 4.3.2. Create Event ... 36 4.3.3. Event Details... 39 4.3.4. My Events ... 42 4.3.5. Event Users ... 43 4.3.6. Live Monitoring ... 43 4.3.7. Edit Event ... 45 4.4. Aplicação móvel... 46 4.4.1. Atividade LoginActivity ... 50 4.4.2. Atividade MapScreen ... 54

4.4.3. Atividades EventDetails e ProfileDetails ... 56

4.5. Aplicação auxiliar ... 57

Capítulo 5 - Resultados e Conclusões ... 60

5.1. Resultados... 60

5.2. Conclusões ... 62

5.3. Trabalho Futuro ... 63

(15)

xi

Lista de Figuras

Figura 1 - WEvent [2] ... 5 Figura 2 - EventBrite [3] ... 6 Figura 3 - Eventphant [4] ... 6 Figura 4 - Endomondo [5] ... 7

Figura 5 - Containers do Java EE ... 8

Figura 6 - Arquitetura RESTful de um Web Service ... 10

Figura 7 - Objeto JSON ... 11

Figura 8 - Array JSON ... 11

Figura 9 - Arquitetura do Sistema Operativo Android [13]... 14

Figura 10 - MySQL Workbench ... 15

Figura 11 - Arquitetura do Sistema ... 19

Figura 12 - Diagrama de casos de uso da aplicação web ... 20

Figura 13 - Diagrama de casos de uso da aplicação móvel ... 21

Figura 14 - Diagrama ER ... 23

Figura 15 - Camadas do Servidor ... 25

Figura 16 - Classes da camada business ... 26

Figura 17 - Camada service ... 26

Figura 18 - Caminho base dos serviços ... 27

Figura 19 - CreateEvent ... 29

Figura 20 - EditEvent ... 30

Figura 21 - EnrollEvent... 31

Figura 22 - FBUserLogin ... 32

Figura 23 - Estrutura da Aplicação Web ... 33

Figura 24 - página index sem login efetuado ... 34

Figura 25 - Função login ... 35

Figura 26 - Página index com login efetuado ... 35

Figura 27 - Página Create Event ... 36

Figura 28 - Mapa para verificar localização do evento ... 36

Figura 29 - Escolher ficheiros e adicionar parâmetros ... 37

(16)

xii

Figura 31 - Novo Parâmetro ... 37

Figura 32 - Mensagem de sucesso ... 37

Figura 33 - Mensagem de erro ... 37

Figura 34 - Fluxograma da ação Submit ... 38

Figura 35 - publicação no Facebook ... 39

Figura 36 - Página do Evento (Título e fotos) ... 39

Figura 37 - Página do Evento (Localização)... 39

Figura 38 - Página do Evento (Informação adicional e comentários) ... 40

Figura 39 - Criação da página do evento ... 40

Figura 40 - Mensagem de inscrição com sucesso ... 41

Figura 41 - Inscrição em evento ... 41

Figura 42 - Tabela dos eventos criados pelo utilizador ... 42

Figura 43 - Menu da tabela da página My Events... 42

Figura 44 - Utilizadores inscritos no Evento ... 43

Figura 45 - Live Monitoring ... 43

Figura 46 - Fluxograma da página Live monitoring ... 44

Figura 47 - Página Edit Event ... 45

Figura 48 - Classes da aplicação Android ... 46

Figura 49 - Balão personalizado ... 46

Figura 50 - Diagrama de classes da aplicação Android ... 47

Figura 51 - Relação entre as classes BallonItemizedOverlay, BaloonOverlayView e customItemizedOverlay ... 47

Figura 52 - Relação entre as classes MapScreen, Constants, LoginActivity e BaseRequestListener ... 48

Figura 53 - Diagrama das classes ProfileDetails, EventDetails e SettingActivity ... 48

Figura 54 - Aplicação YourEvent (Fluxo da aplicação) ... 49

Figura 55 - Aplicação YourEvent (LoginActivity) ... 50

Figura 56 - Aplicação YourEvent no Facebook Developers ... 51

Figura 57 - Ciclo de uma atividade [17] ... 51

Figura 58 - Fluxograma da função loginToFacebook() ... 52

Figura 59 - Objeto JSON enviado pelo Facebook ... 53

(17)

xiii

Figura 61 - Aplicação YourEvent (MapScreen)... 54

Figura 62 - Aplicação YourEvent (Balão de utilizador) ... 54

Figura 63 - Aplicação YourEvent (Balão de evento) ... 54

Figura 64 - Fluxograma da função onCreate da atividade MapScreen ... 55

Figura 65 - Aplicação YourEvent (Detalhes do Evento)... 56

Figura 66 - Aplicação YourEvent (Detalhes de utilizador) ... 57

Figura 67 - Aplicação auxiliar (Main Activity) ... 57

Figura 68 - Aplicação Auxiliar ("Recording") ... 58

Figura 69 - Exemplo de um Objeto JSON guardado no ficheiro de texto... 58

Figura 70 - Aplicação YourEvent a correr num Nexus7 ... 61

Figura 71 - Aplicação YourEvent a correr num Nexus7 (mapa) ... 61

(18)

xiv

Lista de Tabelas

(19)
(20)
(21)

1

Capítulo 1

Introdução

Este projeto de mestrado apresenta o desenvolvimento e implementação de um sistema de ges-tão de eventos, no ESRG (Embedded Systems Research Group) do Departamento de Eletrónica Industrial da Universidade do Minho.

O objetivo deste projeto de mestrado foi desenvolver um sistema que permite aos utilizadores criar, gerir e monitorizar eventos das mais variadas categorias.

1.1. Problema

Atualmente os dispositivos móveis estão mais desenvolvidos e observa-se uma crescente

utiliza-ção de smartphones. Quase todos os dispositivos permitem a obtenção da localização do

mes-mo, quer por coordenadas GPS, quer pela rede. Os smartphones atuais apresentam uma maior

capacidade de processamento, uma maior quantidade de memória disponível e também pos-suem ligação à internet, seja por Wi-fi ou por 3G. No mercado atual o sistema operativo Android é o líder e têm vindo a apresentar uma crescente de utilização [1].

As aplicações atuais de gestão e monitorização de eventos sociais existentes no mercado são muito limitadas, desde funcionalidades à monitorização dos próprios eventos em tempo-real. Esta tese visa colmatar algumas das lacunas das aplicações existentes, dando a hipótese aos utilizadores de poderem criar e monitorizar os seus eventos de forma rápida e simples.

(22)

2

1.2. Proposta de Solução

Este projeto de dissertação centra-se em desenvolver um sistema simples para o utilizador, em

que seja possível a criação de eventos de forma rápida, através de um website e também a

monitorização dos eventos.

Através de uma aplicação móvel para smartphones Android será possível a cada utilizador fazer o login e verificar automaticamente a sua posição, a do evento e bem como a de outros utiliza-dores associados a esse mesmo evento, contudo cada utilizador terá a possibilidade de definir a sua visibilidade para os outros utilizadores.

1.3. Objetivos

Este projeto tem como objetivo desenvolver uma aplicação Android, uma aplicação web e um

web service. A aplicação web terá como finalidade criar eventos, consultar eventos a decorrer, permitir a inscrição em eventos, e terá uma parte de gestão que permitirá ao criador de um evento monitorizar o mesmo, verificar as pessoas inscritas e editar eventos.

A aplicação móvel servirá como uma aplicação auxiliar à aplicação web, onde será possível aos

utilizadores verificarem a localização de eventos, ver detalhes dos eventos, consultar detalhes do organizador de uma evento e também alterar as definições de privacidade na aplicação.

No final do desenvolvimento de ambas as aplicações todo o sistema deverá ser testado.

1.4. Estrutura da tese

No capítulo 2 é apresentado o estado da arte, onde serão abordados alguns exemplos de

aplica-ções web de gestão de eventos e algumas aplicações móveis de monitorização de utilizadores.

No capitulo 3 será feita a análise do sistema a desenvolver, onde serão abordadas as restrições,

os requisitos e arquitetura do sistema e as especificações de software. No capitulo 4 irá ser

abordada a implementação do sistema e subsistemas, onde se abordará a implementação da

(23)

3 irão ser abordados os resultados obtidos bem como sugerido um trabalho futuro que poderá ser implementado de modo a melhorar este projeto de dissertação.

(24)
(25)

5

Capítulo 2

Estado da arte

2.1. Aplicações Web para gestão e monitorização de eventos

Existem várias aplicações para gestão de eventos disponíveis, porém estas aplicações não têm todas as funcionalidades proporcionadas pelo sistema desenvolvido.

Atualmente duas das aplicações em voga em Portugal são o WEvent e o EventBrite. O WEvent, Figura 1, é uma aplicação web pertencente à Opensoft que permite a criação de eventos com diferentes tipos de inscrição, a partilha de eventos através das redes sociais Facebook, Twitter e Google+, a gestão de eventos, inscrição em eventos e também alteração de inscrições já efetua-das.

(26)

6

O EventBrite, Figura 2, é também uma aplicação web que tem como finalidade criar e promover eventos, gerir inscrições e facilitar pagamentos de inscrições. Esta aplicação fornece ainda uma API que pode ser utilizada por programadores. EventBrite é também o nome da empresa inter-nacional com sedes em São Francisco e Londres.

Figura 2 - EventBrite [3]

2.2. Aplicações móveis para monitorização de eventos ou utilizadores

Existe neste campo um défice de aplicações Android que permitam monitorizar eventos e os utilizadores inscritos nos eventos simultaneamente, no entanto, existem várias aplicações que servem para apenas visualizar eventos existentes. No caso da gestão de eventos existe, por exemplo a aplicação Eventphant, que tem como principal função descobrir eventos perto de uma certa localização.

(27)

7 Uma das aplicações Android mais conhecidas para a monitorização de utilizadores é a Endo-mondo, Figura 4. Esta aplicação permite gravar e monitorizar a posição, o percurso percorrido por um utilizador, e também visualizar tempos de corrida entre outros.

Figura 4 - Endomondo [5]

2.3. Tecnologias utilizadas

2.3.1. Java EE

O Java EE (Java Enterprise Edition) fornece um conjunto de especificações com o propósito de

serem utilizadas em aplicações profissionais, pode ser visto simplesmente como uma extensão do Java SE (Java Standard Edition). O Java EE é utilizado para desenvolver aplicações distribuí-das, robustas e com grande distribuição. O Java EE fornece muitas APIs que implementam nor-mas de forma que o programador já não tem que criar as suas próprias implementações Java [6] [7].

Atualmente o Java EE, anteriormente chamado de J2EE, encontra-se na versão 7, Java EE 7.

Esta versão do Java EE introduziu novas especificações, tais como websockets e processamento

de dados JSON (JavaScript Oriented Notation). Foi a partir do J2EE 1.4, em 2003, que foi

adi-cionado o suporte a web services.

A arquitetura do Java EE baseia-se num conjunto de especificações que são implementadas por

(28)

dife-8

rentes serviços aos componentes web. Como o Java EE é um superconjunto do Java SE,

qual-quer API do Java SE pode ser utilizada por qualqual-quer componente do Java EE.

A Figura 5 representa as relações entre os containers e os protocolos utilizados comunicarem

entre si.

Figura 5 - Containers do Java EE

2.3.2. GlassFish

O GlassFish é um servidor open-source suportado pela Oracle e é a referência de implementação

de JavaEE e do Java Persistance API. Este servidor suporta o JavaEE, o Enterprise JavaBeans,

vários tipos de aplicações distribuídas e é ideal para o desenvolvimento de aplicações orientadas a serviços (SOA - Service Oriented Aplications). Encontra-se neste momento na versão 3 e é constituído por um kernel modular que corre sobre o servidor HTTP Apache.

2.3.3. Web Services

Web Service ou serviço Web implementa um conjunto de operações que estão acessíveis através de uma rede. Um web service executa uma tarefa especifica ou um conjunto de tarefas e é

des-crito utilizando um conjunto de regras standard, chamada de service description, que define

todas as regras necessárias para a interação com o web service, incluindo o tipo de dados

(29)

9 Os web services são cada vez mais utilizados em aplicações distribuídas em que é necessário a interação entre plataformas e sistemas diferentes.

Existem várias arquiteturas de web services utilizadas atualmente, estando entre elas os

RPC-style web services e os RESTful web services. Os web services baseados no estilo RPC (Remote Procedure Call) servem os propósitos de pequenas ou médias aplicações no que toca a

interope-rabilidade e partilha de dados, mas para aplicações de maior escala os web services baseados

no estilo RPC perdem em escalabilidade, complexidade e desempenho em relação aos RESTful

web services [8]

2.3.3.1. RPC

Os web services baseados neste estilo de arquitetura veem o servidor como um conjunto de

funções onde o cliente chama essas funções de forma a realizar uma determinada tarefa. A

arquitetura mais predominante utilizada nos RPCs é uma arquitetura orientada aos objetos (SOA

- Service Oriented Architecture), que tem como propósito abstrair os serviços da aplicação.

Este tipo de web services não são perfeitos, sendo que, com o aumento da dimensão dos

siste-mas, os web services tendem a apresentar limites, principalmente no que toca à complexidade e performance o que leva a que o sistema não mantenha um design bem estruturado.

2.3.3.2. REST

REST (REpresentational State Transfer) é um estilo híbrido de arquitetura de web services, que deriva de diversos estilos de arquiteturas com restrições adicionais, que define uma estrutura uniforme. De modo a compreender a arquitetura REST, é necessário saber o conceito de recur-so, representação e estado.

Um recurso pode ser definido como um objeto físico ou um conceito abstrato, ou seja, um recurso pode ser definido como sendo qualquer coisa, desde que, seja importante o suficiente para ser referenciado e definido como tal, sendo normalmente, algo que possa ser guardado num computador e representado por um conjunto de bits. Pode-se definir uma representação como qualquer informação acerca de um recurso e do seu estado. Um recurso pode ter várias representações. A arquitetura REST apresenta dois tipos de estado, um que é o estado do

(30)

recur-10

so, isto é, informação sobre um recurso, e um outro que é o estado da aplicação, que indica o caminho pelo qual o cliente percorreu a aplicação.

Conforme acima referido, o REST apresenta um conjunto de restrições chave, que realçam a escalabilidade entre componentes. Estas restrições definem que: tudo tem que ser um recurso;

todos os recursos têm de ser identificados através de um Uniforme Resource Identifier (URI);

devem seguir um interface uniforme; a manipulação de recursos deve ser feita através de repre-sentações; todas as mensagens devem ser auto descritivas, e, as interações devem ser sem estado (stateless).

A Figura 6 representa a arquitetura RESTful de um Web Service, onde o cliente interage com o

servidor através de um interface uniforme baseado nos verbos HTTP (GET, PUT, POST e DELE-TE).

Figura 6 - Arquitetura RESTful de um Web Service

No que toca à segurança O REST tem um modelo mais simples e eficiente, como tudo é um recurso e cada recurso é apenas identificado por um URI, torna-se mais fácil esconder um recur-so, caso seja necessário, sendo que para isrecur-so, basta apenas não revelar a sua URI. O REST apresenta também a possibilidade de definir diferentes permissões de acesso aos recursos mais facilmente, pois como o REST utiliza os verbos do HTTP, no caso de um recurso ser apenas de leitura é apenas necessário revelar o método GET desse recurso. Ajudando assim a facilitar a implementação das regras de segurança.

Uma das maiores vantagens do REST é a desempenho que é obtida sobretudo pela sua simpli-cidade. Sendo baseado em normas da web não requer implementações adicionais, e é indepen-dente da plataforma ou de uma máquina em particular [8]. Ao utilizar diretamente o protocolo HTTP a carga sobre o servidor e sobre o cliente é reduzida, pois nenhum dos lados tem de fazer o parsing. De acordo com a Amazon.com, que fornece web services baseados nas duas arquite-turas, os que seguem a arquitetura REST são 6 vezes mais rápidos que os baseados no RPC [9].

(31)

11

2.3.4.Dados JSON

JSON ou JavaScript Object Notation é um formato de dados que apresenta uma estrutura de

fácil leitura para humanos e que torna simples para as máquinas, fazer o parsing e geração.

Apresenta a particularidade de ser independente de qualquer linguagem de programação mas usa convecções utilizadas pelas linguagens de programação da família da linguagem C. É, por isso, uma linguagem muito adequada para a comunicação entre aplicações.

A estrutura do JSON baseia-se na utilização de objetos, arrays e vários tipos de dados. A Figura 7

exemplifica um objeto JSON. Este é encapsulado entre chavetas e cada campo do objeto tem o seu identificador e valor, separados por dois pontos.

Figura 7 - Objeto JSON

A Figura 8 apresenta um exemplo de um array de objetos JSON. Os objetos dentro de um array JSON são separados por vírgulas, e podem ser acedidos através do índice de cada um deles.

(32)

12

2.3.5.Localização

A localização de dispositivos ou pessoas tem vindo a tornar-se uma parte muito importante em muitos sistemas de computação e é vista como um requisito por muitos sistemas de computa-ção ubíquos.

O Sistema de Posicionamento Global (GPS) é um dos sistemas de localização mais conhecidos em todo o mundo, no entanto, não é o único e existem diversas técnicas de determinar a locali-zação. No entanto, nenhuma das técnicas pode ser escolhida como a melhor para todos os tipos de cenário.

Neste projeto foram utilizados como sistemas de localização, o GPS e a localização por rede, wi-fi e por rede móvel.

2.3.6.HTML5, CSS, Javascript e jQuery

No desenvolvimento da aplicação web foram utilizadas as tecnologias para desenvolvimento web

HTML5, CSS, JavaScript e recorrendo também ao jQuery.

O HTML5 é uma linguagem de markup, que veio reforçar as versões anteriores e veio reduzir a

necessidade de recorrer a plugins externos, como por exemplo o Flash, outra das preocupações

do HTML5 foi em simplificar a sintaxe, facilitando assim o trabalho dos programadores web. O

HTML5 veio disponibilizar um conjunto novo de APIs [10], tais como, a reprodução de video e audio, disponibilizar aplicações web offline, entre outras.

O CSS (cascading style sheets) é uma linguagem que é utilizada para definir o estilo dos

compo-nentes de linguagens markup como o HTML5. Com esta linguagem torna-se mais fácil fazer a

separação do conteudo de um documento HTML ou XML, da sua apresentação.

O jQuery é uma biblioteca JavaScript que cada vez mais tem vindo a ser considerada a biblioteca

de preferência dos programadores web [11]. As funcionalidades do jQuery estão diretamente

relacionadas com aquilo que o utilizador vê e manipula, e oferecem ao programador capacida-des de manipulação gráfica, capacida-desde animações a efeitos, comunicações AJAX, entre outras. A arquitetura do jQuery é baseada em plugins que lhe confere uma grande extensibilidade.

(33)

13

2.3.7. Google Maps

O Google Maps é um serviço de mapas que permite utilizar e incorporar mapas em aplicações web ou aplicações web através das suas APIs.

A Google Maps API lançada em 2005 oferece a possibilidade aos programadores web de

incor-porarem mapas nas suas aplicações web, ou seja, através desta API é possível embeber o Goo-gle Maps numa aplicação web externa. Também é possível obter através desta API as

coordena-das de uma localização através de um endereço, conhecido como geocoding, e também obter

um endereço através das coordenadas, também conhecido por reverse geocoding. Esta API

encontra-se atualmente na versão 3.13 lançada em Fevereiro de 2013. [12]

O Google Maps fornece também uma API para dispositivos Android. Esta permite incorporar mapas em aplicações Android. A API gere automaticamente o acesso aos servidores do Google

Maps, o download de dados, resposta a inputs, facilitando a implementação de mapas numa

aplicação. Também é possível adicionar marcadores e diferentes overlays aos mapas através da API. Esta API encontra-se na versão 2.

2.3.8. Android OS

O Android OS (Android Operating System) é um sistema operativo open source para dispositivos

móveis baseados em Linux e foi desenvolvido pela Google. É baseado no kernel Linux e adiciona

um interface com o utilizador, bibliotecas para desenvolvimento, suporte multimédia entre outros. Esta plataforma permite aos programadores desenvolverem aplicações na linguagem Java usando bibliotecas desenvolvidas pela Google. Suporta uma enorme variedade de opções de conectividade tais como GSM, Wi-Fi, 3G, 4G, Bluetooth e outros.

A arquitetura deste sistema, Figura 9, está dividido em 5 grandes partes, o kernel Linux, as

(34)

14

Figura 9 - Arquitetura do Sistema Operativo Android [13]

O kernel disponibiliza uma camada de abstração entre o software e hardware bem como um

conjunto de serviços de sistema, como por exemplo, segurança e memória. O kernel implementa device drivers específicos como Wi-Fi e o Bluetooth e suporta portabilidade entre diversos dispo-sitivos com diferente hardware.

O Android OS inclui um conjunto de bibliotecas C/C++, que estão disponíveis aos

programado-res através da framework para aplicações e estas incluem bibliotecas multimédia, de sistema,

SQLite, etc.

A essência do Android Runtime é a Dalvik VM(virtual machine), que foi escrita de uma maneira

que permite que um dispositivo corra múltiplas máquinas virtuais de forma eficiente e com uma memory footprint mínima. O Android Runtime inclui um conjunto de bibliotecas que dão suporte às funcionalidades das bibliotecas Java. Cada aplicação corre no seu próprio processo e na sua

própria máquina virtual. Contudo a máquina virtual Dalvik depende do kernel Linux para realizar

funcionalidades como threading e gestão de memória.

A framework para aplicações disponibiliza uma camada de acesso às APIs usadas pelas

aplica-ções e permite aos programadores utilizarem determinados componentes.

A camada das aplicações é a camada onde as aplicações a correr no sistema operativo Android são instaladas.

(35)

15

2.3.9. Ferramentas de desenvolvimento de

Software

Durante a realização deste trabalho foram utilizados 3 IDEs (Integrated Development Environ-ment): o MySQL Workbench, o Eclipse e o Netbeans.

O MySQL Workbench, Figura 10, é uma aplicação gráfica utilizada no desenvolvimento e manu-tenção de bases de dados. Esta aplicação permite a criação de esquemas EER(Extended Entity-Relationship) e através desses esquemas permite gerar código SQL para a criação de base de

dados através de um wizard. Este IDE também permite establecer ligações a bases de dados já

existentes e realizar querys em linguagem SQL.

Figura 10 - MySQL Workbench

No desenvolvimento da aplicação móvel foi utilizado o IDE Eclipse com o plugin da Google

ADT(Android Development Tools). Este IDE é open-source e é principalmente utilizado no

desen-volvimento de aplicações em linguagem Java, contudo permite a instalação de plugins como o

ADT de forma a permitir desenvolver aplicações em diferentes linguagens. O ADT traz ao Eclipse

a possibilidade de desenvolver aplicações Android e fazer o debug das aplicações. Este IDE foi

utilizado no desenvolvimento da aplicação móvel.

O Netbeans é um IDE open-source e é utilizado no desenvolvimento de aplicações em Java ou

C/C++. Todas as funcionalidades são modulares, o que significa que é possível adicionar módu-los ao pacote básico do Netbeans de forma a ser possível desenvolver aplicações com diferentes

(36)

16

propósitos. Neste projeto foi utilizado o pacote completo do Netbeans(NetBeans IDE Complete Bundle) que inclui no pacote de instalação o suporte ao Java EE, Java SE, C/C++, web e o

servi-dor Glassfish. Este IDE foi utilizado no desenvolvimento da aplicação web (JavaScript, jQuery,

(37)
(38)

18

Capítulo 3

Análise do Sistema

Este capítulo aborda a análise do sistema YourEvent, nomeadamente, os requisitos e as

restri-ções do sistema, a arquitetura e os componentes do mesmo Este sistema é baseado em 4 com-ponentes, a base de dados, o web service, o cliente web e o cliente móvel Android. .

3.1. Requisitos e restrições do Sistema

O sistema YourEvent tem como objetivo implementar um sistema de gestão de eventos baseado

em Android. Este sistema deve permitir ao utilizador criar um evento, inscrever-se num evento, visualizar eventos anteriores, editar eventos, partilhar eventos, monitorizar participantes num determinado evento e permitir descobrir a localização de um evento através da aplicação móvel. O sistema deve fornecer duas aplicações com funcionalidades diferentes, um cliente web e um cliente móvel e tem que ser capaz de suportar o desenvolvimento de novas funcionalidades no futuro.

(39)

19

3.2. Arquitetura do sistema

O sistema YourEvent é constituído por quatro componentes, a aplicação web, a aplicação móvel, o web service e a base de dados, conforme ilustrado no diagrama de blocos da Figura 11.

A aplicação web e a aplicação móvel irão comunicar com o servidor através de pedidos HTTP,

GET, POST, PUT e DELETE, que serão processados pelo web service implementado no servidor

e que por sua vez acederá à informação presente na base de dados. O web service será o

res-ponsável por várias ações desde criar eventos a registar utilizadores.

Figura 11 - Arquitetura do Sistema

3.3. Casos de uso

Nesta secção são abordados os casos de uso das duas aplicações do sistema: os casos de uso

para a aplicação web para utilizadores registados e não registados e os casos de uso para a

(40)

20

3.3.1. Aplicação

web

A Figura 12 representa o diagrama de casos de uso da aplicação web. A aplicação web destina-se a utilizadores registados no sistema e a não registados. Um utilizador não registado tem a possibilidade ao abrir a aplicação, de visualizar todos os eventos criados, ver os eventos ainda por decorrer, os eventos decorridos e ainda visualizar a página de um evento. Este tipo de utili-zador pode ainda realizar o login no sistema.

Após um utilizador realizar o login no sistema, este passa a ser um utilizador registado e passa a

ter a possibilidade de, para além das opções de um utilizador não registado, criar eventos,

ins-crever-se em eventos, verificar os eventos criados e também realizar o logout do sistema. O

utili-zador registado pode também verificar todos os eventos criados pelo mesmo, editar os eventos, monitorizar os participantes num evento, e consultar a lista de utilizadores inscritos num evento criado pelo próprio.

(41)

21

3.3.2. Aplicação móvel

A Figura 13 representa o diagrama de casos de uso da aplicação móvel. Em contraste com a

aplicação web, esta suporta apenas utilizadores registados, sendo a entrada na aplicação a

opção de realizar o login.

O utilizador tem a possibilidade de verificar a localização do evento no mapa, dos utilizadores associados a esse evento e de si próprio. Pode também visualizar os detalhes do perfil do orga-nizador e do evento, consultar o seu perfil e alterar as definições de visualização e monitoriza-ção.

(42)
(43)

23

Capítulo 4

Implementação do Sistema

4.1.Base de Dados

Para a implementação da base de dados deste sistema foi utilizado o MySQL. Foi também utili-zada a ferramenta MySQL Workbench que facilita a criação de bases de dados através de um diagrama ER(Entity-Relationship) de forma mais intuitiva e simples. A Figura 14 representa o diagrama ER criado para o sistema.

(44)

24

Esta base de dados foi desenvolvida de forma a suportar a criação de eventos das mais variadas categorias e com atributos personalizáveis. Começando pela tabela 'user' que tem como propósi-to guardar a informação de um utilizador, e que tem como chave primária o campo 'id_user'. Outros campos relevantes nesta tabela são 'username' e 'email', que são utilizados para realizar

o login dos utilizadores, 'latitude', 'longitude' e 'visibility' que são utilizados na monitorização da

localização dos utilizadores e o 'id' que guarda o id do Facebook do utilizador que usar o Face-book para realizar o login. Esta tabela está relacionada com 2 outras tabelas, a tabela 'user_in_event' e a tabela 'activity_tracker'.

A tabela 'user_in_event' tem como finalidade guardar os utilizadores associados a um

determi-nado evento bem como o tipo de utilizador e o tipo de registo do utilizador no evento. Para tal, esta tabela importa as chaves primárias das tabelas 'users', 'registration', 'user_type' e 'event'.

A tabela 'activity_tracker' serve para guardar qual o utilizador e o evento associado aos valores

guardados na tabela 'tracker_value' – do acelerómetro do dispositivo Android de um utilizador, a hora e data, velocidade e altitude – para que seja possível realizar a monitorização da atividade do utilizador.

A tabela 'event' é uma tabela simples que tem apenas 3 campos, o 'id_event', 'date' e 'name', no entanto, como é necessário que os eventos possam ter atributos variáveis de acordo com as

necessidades do utilizador, criaram-se as tabelas 'event_params', com os campos

'pa-ram_name' e 'param_value', e a tabela 'params_in_event', onde são guardados quais são os parâmetros associados a um evento e vice-versa. No caso de um evento ser desportivo é

neces-sário que contenha checkpoints, para tal criou-se a tabela 'checkpoints', esta tabela é também

utilizada caso o evento não seja desportivo, mas apenas para definir a localização do mesmo. Dado que um evento pode ter várias categorias diferentes e uma categoria pode ser associada a

diferentes eventos foi necessário utilizar uma tabela auxiliar, 'event_in_category' que faz o

rela-cionamento entre a tabela 'event' e a tabela 'event_category'.

Após o desenho do diagrama ER da Figura 14, a ferramenta MySQL Workbench gerou automati-camente o código MySQL para a criação da base de dados.

(45)

25

4.2.Web Service

O web service é utilizado para responder aos pedidos HTTP realizados pelas aplicações web e

Android. Apesar de este web service usar pedidos HTTP POST e GET e o formato de dados

utili-zados ser o JSON, este web service não segue a arquitetura REST. Os pedidos recebidos são

redirecionados para a camada business que inclui todas as funções necessárias para responder

aos pedidos, enquanto que a camada model é a responsável por disponibilizar as classes

cor-respondentes à estrutura da base de dados e a camada DAO(Data Access Object) é a camada

responsável por isolar o acesso à base de dados. Esta estrutura pode ser vista na Figura 15.

Figura 15 - Camadas do Servidor

O web service foi desenvolvido utilizando o IDE NetBeans e a linguagem Java. O NetBeans ajuda

a acelerar o processo de desenvolvimento do web service pois cria automaticamente o código

para a camada model e a camada DAO, através de uma base de dados já existente. A camada DAO permite criar, pesquisar, editar e remover registos sem ter que estar a reescrever o código de acesso à base de dados.

Na camada business foram desenvolvidas todas as funções para responder aos pedidos dos

clientes, tanto Android como web, nesta camada está também presente a função de gestão da

(46)

26

Nesta camada foram criadas as classes Evento, Category, SessionManager e Utilizador, Figura

16, estas classes são responsáveis por comunicar com a camada DAO e tratar de toda a lógica necessária, desde verificar se existe sessão iniciada a preparar os parâmetros recebidos para realizar querys.

Figura 16 - Classes da camada business

A classe Evento é a responsável por tratar toda a informação relevante para um evento, quer seja a criação, edição, procura ou remoção do mesmo. A classe Utilizador é a classe responsável pela criação, login, logout, procura e monitorização dos utilizadores. Já a classe SessionManager é a classe responsável pela gestão e atribuição de sessões aos utilizadores.

Na camada service é onde estão descritos todos os métodos existentes no web service e é verifi-cada se a sessão está iniciada ou se é necessário fazer login. Os métodos implementados para o web service são os que estão representados na Tabela 1.Esta camada é composta pela classe YourEventResource e pela ApplicationConfig, sendo a primeira responsável por descrever o caminho de todos os serviços, o tipo de pedidos, os valores recebidos e os valores devolvidos por

cada um dos serviços. A segunda, a ApplicationConfig, é uma classe gerada pelo NetBeans e

descreve a configuração da aplicação e o caminho base dos serviços, Figura 18.

(47)

27 Figura 18 - Caminho base dos serviços

Tabela 1 - Métodos do web service

Tipo de

pedido URI* Sessão inicia-da Devolve

POST

"http://<endereço>/YourEvent/webresources/YourEvent

/CreateEvent" Sim Objeto JSON

"http://<endereço>/YourEvent/webresources/YourEvent

/EditEvent" Sim Objeto JSON

"http://<endereço>/YourEvent/webresources/YourEvent

/EnrollEvent" Sim Objeto JSON

"http://<endereço>/YourEvent/webresources/YourEvent

/FBUserlogin" Não Objeto JSON

"http://<endereço>/YourEvent/webresources/YourEvent

/Userlogin" Não Objeto JSON

GET

"http://<endereço>/YourEvent/webresources/YourEvent

/getCategoriesList" Não Array JSON

"http://<endereço>/YourEvent/webresources/YourEvent

/getEventListDetailed" Não Array JSON

"http://<endereço>/YourEvent/webresources/YourEvent

/getEventById{id}" Não Objeto JSON

"http://<endereço>/YourEvent/webresources/YourEvent

(48)

28

Tabela 1 - - Métodos do web service (continuação)

Tipo de

pedido URI* Necessário ses-são iniciada Devolve

GET

"http://<endereço>/YourEvent/webresources/YourEvent/

getEventList" Não Array JSON

"http://<endereço>/YourEvent/webresources/YourEvent/

getEventListDetailed" Não Array JSON

"http://<endereço>/YourEvent/webresources/YourEvent/

getEventsFromUser{id} Sim Array JSON

"http://<endereço>/YourEvent/webresources/YourEvent/

getFutureEventListDetailed" Não Array JSON

"http://<endereço>/YourEvent/webresources/YourEvent/

getUserList" Sim Array JSON

"http://<endereço>/YourEvent/webresources/YourEvent/

getNextEventDetails{iduser}" Sim Objeto JSON

"http://<endereço>/YourEvent/webresources/YourEvent/

getUserById{id}" Sim Objeto JSON

"http://<endereço>/YourEvent/webresources/YourEvent/

getUsersFromEvent{id}" Não Array JSON

"http://<endereço>/YourEvent/webresources/YourEvent/

getUsersInEvent{id}" Sim Array JSON

POST

"http://<endereço>/YourEvent/webresources/YourEvent/

uploadImage" Sim Objeto JSON

"http://<endereço>/YourEvent/webresources/YourEvent/

getImage" Não Base64 String

Todos os métodos acima descritos estão representados por um URI único, e alguns dos métodos só estão disponíveis a utilizadores com sessão iniciada.

(49)

29

4.2.1.

CreateEvent

O método CreateEvent é o responsável pela criação de um evento e a resposta enviada por este

método é o id do evento criado. Conforme se pode verificar no fluxograma da Figura 19, neste

método começa-se por verificar se o utilizador tem a sessão iniciada. Caso isto não se verifique, é lançada uma exceção de "Invalid Session". Se o utilizador tiver sessão iniciada é então verifi-cado se o atributo do nome do Evento a criar e a data de realização foram preenchidos

correta-mente. Se esta condição não se verificar a resposta devolvida pelo servidor é um id de evento

inválido, neste caso "-1", no entanto, se os campos forem diferentes de null, é de seguida

verifi-cado se o valor recebido das coordenadas são diferentes de null. Indo de seguida verificar se

existe um nome na base de dados igual ao inserido pelo utilizador. Se se verificar esta condição é então criado o evento na base de dados, bem como todas as tabelas a ele associadas, e é devolvido como resposta o id do evento acabado de criar.

(50)

30

4.2.2.

EditEvent

O método EditEvent é o método responsável por fazer alterações aos eventos já existentes, quer seja nome, localização, data ou até os parâmetros adicionais. Este método, Figura 20, começa como o método anterior, por verificar se o utilizador tem sessão válida iniciada. Se a sessão for válida procura-se então pelo evento a modificar e caso este exista, e o valor das novas

coordena-das e o novo nome não forem null, pois são parâmetros necessários para um evento para o

evento, caso o novo nome para o evento não exista na base de dados, o método procura por todos os parâmetros associados ao evento com o id do evento a editar e altera os existentes pelos novos parâmetros inseridos pelo utilizador. No caso de tudo ser efetuado sem nenhum erro o método devolve o valor "1" caso contrário o valor "-1".

(51)

31

4.2.3.

EnrollEvent

Para um utilizador se inscrever num evento é necessário utilizar o método EnrollEvent, Figura

21. Neste método após fazer a verificação da sessão, conforme descrito na secção 4.2.1, é

necessário dividir o objeto JSON recebido em dois parâmetros, o id do utilizador a inscrever e o

id do evento no qual o utilizador se vai inscrever. De seguida é necessário procurar se o utiliza-dor e o evento com os ids obtidos existem na base de dados, caso algum destes não se encontre

na mesma, é devolvido a mensagem "user or event not found". Caso existam, é ainda

necessá-rio verificar se o utilizador está já inscrito no evento. Se este se encontrar inscrito no evento é devolvido a mensagem "user already in event", caso contrário o utilizador é inscrito no evento.

(52)

32

4.2.4.

FBUserLogin

Quando o utilizador faz o login no sistema utilizando o Facebook o método utilizado é o

FBUser-Login, Figura 22. Neste método é verificado se o utilizador já existe na base de dados e caso não exista é adicionado um novo utilizador. No final é sempre iniciada a sessão para o utilizador.

Dado que ambos os clientes, web e móvel utilizam a API do Facebook para realizar o login, a

autenticação é feita pelo Facebook, sendo apenas necessário adicionar utilizadores e iniciar ses-são.

Figura 22 - FBUserLogin

(53)

33

4.3. Aplicação

Web

A aplicação web foi desenvolvida utilizando a linguagem de markup HTML5, CSS, JavaScript e

jQuery. As principais funcionalidades da aplicação web são efetuar login através do Facebook,

criar eventos, inscrever em eventos, comentar eventos existentes, editar eventos criados, fazer a monitorização dos utilizadores registados nos eventos e verificar lista de utilizadores registados num evento.

A aplicação web está “fisicamente” estruturada, conforme se pode visualizar na Figura 23, da

seguinte forma: as páginas públicas, acessíveis sem ter sessão iniciada, encontram-se no

diretó-rio raiz da página; as páginas privadas ficaram na pasta "admin_pages"; todos os ficheiros

JavaScript encontram-se na pasta "js"; os ficheiros CSS encontram-se na pasta "styles_folder"; e

todas as imagens utilizadas na aplicação web ficaram na pasta "images". Na pasta "js"

encon-tram-se ainda 2 outras pastas, a pasta "maps" e a pasta "plugins" que contêem o plugin do

Google Maps e alguns plugins de jQuery, respetivamente.

Figura 23 - Estrutura da Aplicação Web

A aplicação é composta por 10 páginas diferentes, "index" , "createevent", "EventList", "elapse-devents", "futureevents", "my_events", "eventdetails", "edit_event", "eventusers" e

(54)

"livemonito-34

ring". A implementação e funcionalidades de cada uma destas páginas serão descritas nas sec-ções seguintes deste documento.

Todas as páginas da aplicação web são carregadas e sendo de seguida feitos pedidos ao

servi-dor de modo a construir as páginas com a informação relevante, como por exemplo, os detalhes de um evento ou a lista de eventos.

4.3.1.

Index

A página "index", Figura 24, é a página onde a aplicação web inicia. Nesta página é possível ao utilizador realizar o login na aplicação, visualizar eventos existentes através de um mosaico com

uma interface visual do estilo metro do Windows8, e navegar para as outras páginas através da

barra de menu ou através do painel de controlo.

Figura 24 - página index sem login efetuado

O utilizador pode realizar o login na aplicação clicando apenas no botão superior direito e

utili-zando o Facebook para o realizar. Ao clicar no botão de login, Figura 25, a aplicação faz um

pedido de utilizando a função FB.login(function,{scope:""}) da API do Facebook, pedindo permis-sões para aceder ao email do utilizador, para publicar em nome do utilizador e para aceder ao

aniversário, bem como a outras informações como o nome e o username do utilizador. Após o

pedido ser realizado com sucesso é feito um pedido POST, para o método FBUserLogin do web service enviando os dados do utilizador, de modo a iniciar a sessão no servidor.

(55)

35

Figura 25 - Função login

Após realizar o login, aparece na página principal o painel de controlo e o botão de login

desapa-rece para dar lugar a uma label onde aparece o nome do utilizador e um botão para realizar o

logout da aplicação, conforme se pode visualizar na Figura 26. Nesta página é também possível

ao utilizador fazer um "Gosto" ou comentar a aplicação no Facebook através do plugin social do

Facebook.

(56)

36

4.3.2.

Create Event

A página "Create Event", Figura 27, é a que permite ao utilizador criar um evento. Quando a

página acaba de carregar é realizado um pedido ao servidor para obter todas as categorias dis-poníveis para atribuir a um evento., Quando a resposta do servidor chega são então adicionadas a uma lista todas as categorias obtidas.

Figura 27 - Página Create Event

À medida que o utilizador vai preenchendo os campos da localização do evento é apresentado um mapa ao utilizador de modo a permitir que este verifique se a localização escolhida para o evento é a correta e se não existe nenhum erro, Figura 28.

Figura 28 - Mapa para verificar localização do evento

A função desenvolvida para a realização desta tarefa foi a função RefreshMap(), realizada quando

ocorre um evento de alteração de um campo do formulário, que realiza um pedido GET ao

servi-dor da Google Maps com o endereço "http://maps.google.com/maps/api/

geoco-de/json?address=<params>", enviando como parâmetros os inseridos pelo utilizador. A resposta enviada pelo servidor é um objeto JSON com a latitude e a longitude associada a essa

(57)

localiza-37

ção, caso a localização não seja encontrada é lançado um alerta com a mensagem "Location not

found".

O utilizador pode também nesta página escolher fazer o upload de fotos para o evento e escolher adicionar mais parâmetros ao evento que aqueles presentes no formulário para tal clicando no sinal de mais, Figura 29.

Figura 29 - Escolher ficheiros e adicionar parâmetros

Ao clicar no sinal mais é apresentado ao utilizador o ecrã da Figura 30, onde o utilizador pode inserir o nome do parâmetro a inserir.

Figura 30 - Add new Information

Após inserir e clicar em adicionar informação nova, o novo parâmetro é adicionado ao formulá-rio, Figura 31.

Figura 31 - Novo Parâmetro

Após o utilizador preencher o formulário pode clicar no botão Submit para criar um evento. Caso este pedido seja realizado com sucesso é apresentada uma mensagem de sucesso no ecrã,

utilizando a função jQuery animate(), que altera a posição atual da mensagem que se encontra

fora do ecrã, para uma posição visível no fundo deste, Figura 32, indicando que tudo correu como esperado; caso contrário, é apresentada uma mensagem de erro, Figura 33.

(58)

38

Ao botão Submit está associado um handler para quando o utilizador clicar no botão realizar o

pedido ao servidor. Esta função, Figura 34, começa por construir um objeto JSON utilizando todos os parâmetros inseridos pelo utilizador, e de seguida realiza um pedido ao servidor do Google Maps de modo a obter a latitude e longitude da localização adicionando esses valores ao

objeto JSON. Finalmente, é realizado então um pedido POST ao método CreateEvent do web

service. Sendo a resposta diferente do valor "-1", é mostrada a mensagem de sucesso, é feita

uma publicação no Facebook, Figura 35 e no final é feito o upload das imagens do evento

atra-vés de um pedido POST para o método uploadimage.

(59)

39 Figura 35 - publicação no Facebook

4.3.3.

Event Details

A página Event Details é a página de cada evento, onde é possível ao utilizador verificar os deta-lhes do evento selecionado, as fotos(Figura 36), a localização(Figura 37) e os parâmetros adicio-nais, é também possível aos utilizadores comentarem cada evento através do Facebook, Figura 38. É neste ecrã que é feita a inscrição de um utilizador num evento.

Figura 36 - Página do Evento (Título e fotos)

(60)

40

Figura 38 - Página do Evento (Informação adicional e comentários)

Esta página é construída de acordo com o evento em questão, ou seja, durante o carregamento da página é feito um pedido ao servidor para obter os detalhes do evento, de seguida é necessá-rio obter o endereço das coordenadas associadas ao evento, para isso é realizado um pedido ao Google Maps no endereço "http://maps.googleapis.com/maps/api/geocode/json?latlng= {lat,lng}" que devolve um objeto JSON com o endereço. Tendo esse pedido sido realizado com

sucesso é então inicializado o mapa com a localização do evento. Por fim é feito o download das

imagens do evento através do método getImage.

Para implementar o slideshow das imagens dos eventos foi utilizado o plugin jQuery flexslider

[14]. O fluxograma de funcionamento do carregamento desta página pode ser visualizado na Figura 39.

(61)

41

Para a inscrição do utilizador num evento é feito um POST utilizando o método EnrollEvent e

enviando os dados do utilizador, caso este pedido seja bem sucedido é mostrada uma mensa-gem de sucesso, Figura 40, caso contrário é mostrada uma mensamensa-gem de erro, Figura 41.

Figura 40 - Mensagem de inscrição com sucesso

(62)

42

4.3.4.

My Events

A página My Events é responsável por mostrar ao utilizador todos os eventos criados pelo

pró-prio. Esta página começa por fazer um pedido GET ao servidor utilizando o método

getEvent-FromOrg que retorna um array JSON contendo todos os dados dos eventos criados pelo utiliza-dor. Na tabela da Figura 42 são mostrados os eventos, o número de utilizadores em cada even-to, a data de realização de um evento e a localização.

Figura 42 - Tabela dos eventos criados pelo utilizador

A última coluna da tabela é onde se encontra um botão que abre um menu que permite ir para

uma das seguintes páginas, "eventusers", "edit_event", "livemonitoring" e a página do próprio

evento, Figura 43. A tabela da Figura 42 foi implementada utilizando o plugin jQuery dataTables

[15].

(63)

43

4.3.5.

Event Users

Na página Event Users o utilizador pode consultar quais os utilizadores inscritos num evento e

alguns dos seus dados, como por exemplo, o email ou a data de aniversário, ver a Figura 44.

Figura 44 - Utilizadores inscritos no Evento

4.3.6.

Live Monitoring

Na página Live Monitoring é possível ao organizador do evento ver a posição dos utilizadores

inscritos no evento caso estes tenham o atributo visibility como "true", Figura 45. Esta funciona-lidade é possível em qualquer altura do evento e só é possível obter posições atualizadas caso os utilizadores tenham a aplicação Android a correr.

(64)

44

Esta página começa por inicializar o mapa do Google Maps, de seguida efetua um pedido ao servidor para obter os detalhes do evento em questão. Após receber a resposta do servidor é adicionado um marcador (marker) na posição correspondente à localização do evento. Finalizada a ação anterior, é feito um novo pedido ao servidor, desta vez para obter os utilizadores inscritos no evento e as suas posições, sendo por fim adicionados os marcadores correspondentes a cada

utilizador e de seguida inicializado um temporizador para fazer o refresh das posições de 10 em

10 segundos. O fluxograma desta página pode ser visualizado na Figura 46.

(65)

45

4.3.7.

Edit Event

Esta página permite ao organizador do evento editar o evento em questão, dando a possibilidade de alterar o nome do evento, a localização a data e a hora de início e as informações adicionais, Figura 47.

Após o utilizador fazer as alterações e clicar no botão submit é apresentada uma mensagem de

sucesso caso as alterações tenham sido realizadas com sucesso ou uma mensagem de erro caso tenho ocorrido um erro.

(66)

46

4.4. Aplicação móvel

A aplicação móvel deste sistema foi desenvolvida utilizando o IDE Eclipse com o ADT plugin da

Google, este plugin permite o acesso às APIs para o desenvolvimento de uma aplicação Android.

A aplicação YourEvent permite aos utilizadores fazerem o login utilizando o Facebook, sendo

direcionados logo de seguida para o mapa do próximo evento no qual estão inscritos, onde podem ver a sua própria localização bem como a localização de outros utilizadores que estão inscritos no mesmo evento. Cada utilizador pode ainda aceder aos detalhes do evento, do orga-nizador do evento e do próprio utilizador.

Esta aplicação está dividida em 5 atividades; LoginActivity; MapScreen; ProfileDetails;

EventDe-tails e SettingActivity.

As classes implementadas para a criação desta aplicação foram as representadas na Figura 48. As classes BallonItemizedOverlay, BaloonOverlayView e customItemizedOverlay são responsáveis pela criação de um balão personalizado, Figura 49, ou seja, um balão diferente daquele pré definido pela API da Google. Estas classes são também responsáveis pela gestão de eventos de clique no balão.

Figura 48 - Classes da aplicação Android

Figura 49 - Balão personalizado

É na classe Constants que são guardadas e declaradas todas as constantes e variáveis globais

usadas no sistema. A classe BaseRequestListener é a responsável por implementar os Listeners que são chamados quando ocorre um evento de login utilizando a API do Facebook. As classes SettingActivity, ProfileDetails, MapScreen, EventDetails e LoginActivity são as responsáveis pela implementação das atividades da aplicação.

(67)

47 O diagrama de classes da aplicação móvel é o presente na Figura 50.

Figura 50 - Diagrama de classes da aplicação Android

A relação entre as classes BallonItemizedOverlay, BaloonOverlayView e customItemizedOverlay estão descritas na Figura 51.

(68)

48

A relação entre as classes MapScreen, Constants, LoginActivity e BaseRequestListener estão descritas na Figura 52.

Figura 52 - Relação entre as classes MapScreen, Constants, LoginActivity e BaseRequestListener

As classes EventDetails, ProfileDetails e Settings Activity não possuem relações entre si conforme se pode ver no seu diagrama de classes na Figura 53.

(69)

49 O fluxo da aplicação móvel pode ser visto na Figura 54.

(70)

50

4.4.1. Atividade

LoginActivity

Quando o utilizador inicia a aplicação YourEvent esta começa pela atividade LoginActivity (Figura

55).

Figura 55 - Aplicação YourEvent (LoginActivity)

O objetivo desta atividade é realizar a autenticação do utilizador fazendo uso da biblioteca do Facebook para Android [16]. Para tal é necessário ter uma aplicação criada no site do Facebook Developers (https://developers.facebook.com/apps/). Após criar com sucesso a aplicação é

fornecida um APP_ID, Figura 56, que permite ao Facebook identificar a aplicação que está a

(71)

51

Figura 56 - Aplicação YourEvent no Facebook Developers

O ciclo de vida de uma atividade começa pela função onCreate(), conforme podemos verificar no fluxograma da Figura 57, esta função começa por definir o layout da atividade indo de seguida inicializar todos os handlers necessários.

(72)

52

Nesta atividade o utilizador apenas tem a possibilidade de realizar o login ou fechar a aplicação, se o utilizador clicar no botão para realizar o login é chamada a função loginToFacebook(), que é responsável por fazer o pedido utilizando funções da biblioteca do Facebook.

Como se pode ver no fluxograma da Figura 58, a função começa por obter as preferências

guar-dadas no dispositivo móvel pela aplicação do Facebook, onde se encontram guardados o Access

Token para esta aplicação e o tempo de sessão, de seguida verifica se o Access Token não é null

e, caso não seja é guardado o Access Token existente para acesso à API do Facebook. Se o

tempo de acesso for diferente do valor "0", o valor obtido é atribuído à sessão atual. Após estes

dois passos verifica-se se já existe uma sessão válida no Facebook para a aplicação YourEvent.

Se a sessão for inválida é feito um pedido que autorize o acesso a parte da informação do utili-zador, bem como permissão para publicar em seu nome, indo de seguida guardar as novas preferências, como o novo Access Token e o tempo de sessão.

(73)

53

Após o utilizador autorizar a aplicação YourEvent, clicando no botão de permitir aplicação, é

rea-lizado um pedido ao Facebook para obter os dados do utirea-lizador, obtendo um objeto JSON como resposta, Figura 59.

Figura 59 - Objeto JSON enviado pelo Facebook

Ao receber a resposta do Facebook a atividade executa a AssyncTask postFbLogin. A AssyncTask

é uma tarefa que funciona em background, ou seja, não corre na UI (User Interface), e é

respon-sável por fazer um pedido POST ao web service utilizando o método FBUserLogin. Enquanto o

pedido é feito ao servidor é mostrado ao utilizador a mensagem da Figura 60. Finalizado o pedi-do é lançada a atividade seguinte MapScreen e é terminada a atividade atual.

(74)

54

Enquanto o utilizador estiver nesta atividade o utilizador pode também fechar a aplicação o que leva à atividade LoginActivity entrar na função onDestroy().

4.4.2. Atividade

MapScreen

A atividade seguinte é a MapScreen. Conforme se pode ver na Figura 61, esta atividade tem o

objetivo de mostrar a localização do utilizador, a localização do evento e a localização dos restan-tes utilizadores inscritos no evento. O evento é marcado com o ícone verde, enquanto que o utilizador é marcado com o ícone cinzento escuro e os restantes utilizadores são representados com o ícone cinzento claro, ver a Figura 61.

Figura 61 - Aplicação YourEvent (MapScreen)

Neste ecrã o utilizador pode clicar em cada um dos ícones de modo a descobrir quem, ou o que, é cada um. Se clicar num dos ícones cinzentos irá abrir um balão com o nome, a foto e o email daquele utilizador, Figura 62; caso clique no ícone verde irá abrir um balão com a foto do even-to, o nome, a data e a hora, Figura 63.

(75)

55 A Figura 64 representa o fluxograma da função onCreate() da atividade MapScreen. Esta função

começa por definir o layout desta atividade e adicionar um menu na ActionBar 1 da atividade. A

atividade executa de seguida um conjunto de AsyncTask de modo a obter qual o evento a

mos-trar, os detalhes do evento e os utilizadores. Após receber as respostas dos pedidos é inicializado o gestor de localizações do Android e definido o critério de escolha do provedor da localização: o

que menos consuma bateria. De seguida é executada uma outra AsyncTask para obter a

locali-zação das coordenadas do evento e é inicializado o objeto MapView. Após a obtenção dos dados

são criados os overlays para cada utilizador e evento.

Figura 64 - Fluxograma da função onCreate da atividade MapScreen

1

ActionBar é a barra da aplicação onde estão colocados o nome da atividade, os botões de menu e o

(76)

56

Cada vez que ocorra uma alteração na posição atual do utilizador é feita uma atualização às

posições de todos os utilizadores. Nesta atividade existe também uma thread responsável por

obter as novas posições dos utilizadores que é executada a cada 5 minutos, tendo sido utilizado para isso a função Thread.sleep() de forma a que a thread só execute os pedidos ao servidor a cada 5 minutos.

Na atividade MapScreen o utilizador pode navegar para outras atividades através dos botões

presentes na Action Bar ou através das setas nos balões, tanto dos utilizadores como do evento. Estas atividades apresentam os detalhes do utilizador ou do evento dependendo da atividade iniciada.

4.4.3. Atividades

EventDetails

e

ProfileDetails

A atividade EventDetails, Figura 65, permite ao utilizador verificar os detalhes do evento, como o

nome, a localização, a data e o organizador. Deste ecrã o utilizador pode voltar para o ecrã ante-rior ou então clicar na fotografia do organizador para ver os detalhes daquele utilizador.

Figura 65 - Aplicação YourEvent (Detalhes do Evento)

A atividade responsável por mostrar os detalhes de um utilizador é a atividade ProfileDetails,

Figura 66, esta atividade começa por obter o id do utilizador a mostrar, valor que foi previamente guardado pela atividade anterior, de seguida apenas preenche os campos com o nome de utili-zador, o nome, a data de nascimento e o email.

Imagem

Figura 1 - WEvent [2]
Figura 2 - EventBrite [3]
Figura 5 -  Containers  do  Java EE
Figura 9 - Arquitetura do Sistema Operativo Android [13]
+7

Referências

Outline

Documentos relacionados

Para preparar a pimenta branca, as espigas são colhidas quando os frutos apresentam a coloração amarelada ou vermelha. As espigas são colocadas em sacos de plástico trançado sem

nesta nossa modesta obra O sonho e os sonhos analisa- mos o sono e sua importância para o corpo e sobretudo para a alma que, nas horas de repouso da matéria, liberta-se parcialmente

Os interessados em adquirir quaisquer dos animais inscritos nos páreos de claiming deverão comparecer à sala da Diretoria Geral de Turfe, localizada no 4º andar da Arquibancada

No entanto, maiores lucros com publicidade e um crescimento no uso da plataforma em smartphones e tablets não serão suficientes para o mercado se a maior rede social do mundo

3.3 o Município tem caminhão da coleta seletiva, sendo orientado a providenciar a contratação direta da associação para o recolhimento dos resíduos recicláveis,

Neste estudo foram estipulados os seguintes objec- tivos: (a) identifi car as dimensões do desenvolvimento vocacional (convicção vocacional, cooperação vocacio- nal,

Ficou com a impressão de estar na presença de um compositor ( Clique aqui para introduzir texto. ), de um guitarrista ( Clique aqui para introduzir texto. ), de um director

Atualmente os currículos em ensino de ciências sinalizam que os conteúdos difundidos em sala de aula devem proporcionar ao educando o desenvolvimento de competências e habilidades