furb mobile gincanas: sistema mÓvel na plataforma phonegap …
TRANSCRIPT
UNIVERSIDADE REGIONAL DE BLUMENAU
CENTRO DE CIÊNCIAS EXATAS E NATURAIS
CURSO DE CIÊNCIA DA COMPUTAÇÃO – BACHARELADO
FURB MOBILE GINCANAS: SISTEMA MÓVEL NA
PLATAFORMA PHONEGAP PARA GINCANAS VIRTUAIS
RAFAEL ADÃO
BLUMENAU
2016
RAFAEL ADÃO
FURB MOBILE GINCANAS: SISTEMA MÓVEL NA
PLATAFORMA PHONEGAP PARA GINCANAS VIRTUAIS
Trabalho de Conclusão de Curso apresentado
ao curso de graduação em Ciência da
Computação do Centro de Ciências Exatas e
Naturais da Universidade Regional de
Blumenau como requisito parcial para a
obtenção do grau de Bacharel em Ciência da
Computação.
Prof. Dalton Solano dos Reis, Mestre - Orientador
BLUMENAU
2016
FURB MOBILE GINCANAS: SISTEMA MÓVEL NA
PLATAFORMA PHONEGAP PARA GINCANAS VIRTUAIS
Por
RAFEL ADÃO
Trabalho de Conclusão de Curso aprovado
para obtenção dos créditos na disciplina de
Trabalho de Conclusão de Curso II pela banca
examinadora formada por:
______________________________________________________
Presidente: Prof. Dalton Solano dos Reis, Mestre – Orientador, FURB
______________________________________________________
Membro: Prof. Aurélio Faustino Hoppe, Mestre – FURB
______________________________________________________
Membro: Prof. Joyce Martins, Mestre – FURB
Blumenau, 07 de julho de 2016
AGRADECIMENTOS
A Deus, pelo seu imenso amor e graça.
À minha família, que me apoiou e sempre esteve presente.
Aos meus amigos, pelos empurrões e cobranças.
Ao meu orientador, Dalton Solano dos Reis, por ter acreditado na conclusão deste
trabalho.
Tudo o que a mente pode conceber e acreditar,
a mente pode realizar.
Napoleon Hill
RESUMO
Este trabalho apresenta o desenvolvimento de um aplicativo voltado para a aplicação de
gincanas. É possível aplicar tarefas do tipo pergunta, imagem, vídeo e geolocalização, além de
definir dependências entre as tarefas, permitindo que as mesmas sejam encadeadas no estilo
caça ao tesouro. Os participantes da gincana devem se organizar em grupos pré-definidos pelo
organizador da gincana, onde os líderes devem distribuir as tarefas para seus colegas de
grupo, avaliando qual tarefa se encaixa com o perfil de cada usuário. O aplicativo permite que
o participante da gincana se autentique utilizando sua conta da rede social Facebook. Os
usuários podem utilizar os recursos de câmera e GPS para responder as tarefas,
respectivamente, de imagem e geolocalização. O aplicativo permite a pesquisa no site de
compartilhamento de vídeos YouTube para responder as tarefas do tipo vídeo. Os usuários
são notificados sobre os acontecimentos na gincana, através de notificações push. A gincana
pode ser acompanhada em um placar público, através do site de quadro virtual e organizador
de tarefas Trello. Desenvolvido com o framework Phonegap e seus plugins, o aplicativo
utiliza as tecnologias web (HTML, CSS, Javascript) como padrão de desenvolvimento, além
do framework Ionic, que é utilizado para diminuir a sensação do usuário estar navegando em
um site. Como resultado da implementação, o aplicativo executou muito bem a integração
com os serviços externos de rede social, vídeos, mapas, notificações e quadro virtual.
Palavras-chave: Phonegap. Dispositivo móvel. Rede social. Notificações. GPS. Gincanas.
ABSTRACT
This work presents the development of a focused application for applying gymkhanas. You
can apply the question type tasks, image, video and geolocation, and set dependencies
between tasks, allowing them to be linked in hunting style treasure. The contest participants
should be organized in pre-defined groups by the organizer of the contest, where leaders
should distribute tasks to your peers, evaluating which task fits each user's profile. The
application allows the participant of the contest to authenticate using your Facebook social
network account. Users can use the camera and GPS capabilities to meet the tasks,
respectively, image and geolocation. The application allows you to search on the YouTube
video sharing site to answer the video type tasks. Users are notified of events in gymkhana
through push notifications. The contest can be followed on a public scoreboard through the
virtual frame site and organizer Trello tasks. Developed with Phonegap framework and its
plugins, the application uses web technologies (HTML, CSS, Javascript) as standard
development, beyond the Ionic framework, which is used to decrease the user feeling to be
browsing a website. As a result of the implementation, the application performed well the
integration with external services social networking, maps, reports and virtual table.
Key-words: Phonegap. Mobile device. Social networking. Notifications. GPS. Gymkhanas.
LISTA DE FIGURAS
Figura 1 - Adicionando o plugin de GPS ................................................................................. 18
Figura 2 - Funcionamento da API de push do Ionic Platform .................................................. 19
Figura 3 - Cenário do Sistema .................................................................................................. 20
Figura 4 - Tô Aqui: Tela inicial ................................................................................................ 22
Figura 5 - Tela inicial do jogo Ingress ...................................................................................... 23
Figura 6 - Casos de uso do front-end ........................................................................................ 27
Figura 7 - Casos de uso do mobile ............................................................................................ 28
Figura 8 - Diagrama de classes do fron-end ............................................................................. 30
Figura 9 - Diagrama de classes do aplicativo mobile ............................................................... 31
Figura 10 - Diagrama de classes da arquitetura do back-end ................................................... 32
Figura 11 - Diagrama de classes do pacote MODEL ................................................................. 33
Figura 12 - Diagrama de classes do pacote DAO ...................................................................... 35
Figura 13 - Diagrama de classes do pacote DTO ...................................................................... 36
Figura 14 - Diagrama de classes do pacote Trello Model ................................................ 37
Figura 15 - Diagrama de classes do pacote Trello Service ............................................ 37
Figura 16 - Diagrama de classes do pacote Trello Client .............................................. 38
Figura 17 - Diagrama de classes do pacote Ionic API ........................................................ 38
Figura 18 - Diagrama de classes do pacote Service ............................................................ 39
Figura 19 - Diagrama de classes do pacote API ...................................................................... 41
Figura 20 - Diagrama de atividades .......................................................................................... 42
Figura 21 - Arquitetura do aplicativo ....................................................................................... 43
Figura 22 - Processo de autenticação ....................................................................................... 44
Figura 23 - Tela de cadastro de gincana ................................................................................... 56
Figura 24 – Tela de cadastro de tarefa ...................................................................................... 57
Figura 25 - Tela para vincular tarefas requisitos ...................................................................... 58
Figura 26 - Tela de cadastro de grupo ...................................................................................... 58
Figura 27 - Autorizar Trello ..................................................................................................... 59
Figura 28 - Quadro criado no Trello ......................................................................................... 60
Figura 29 - Tela inicial do aplicativo........................................................................................ 60
Figura 30 - Entrando em um grupo e lista de tarefas................................................................ 61
Figura 31 - Novo membro e delegação de tarefas .................................................................... 61
Figura 32 - Resolvendo tarefa de vídeo .................................................................................... 62
Figura 33 - Resolvendo tarefa de geolocalização ..................................................................... 62
Figura 34 - Resolvendo tarefa de imagem ................................................................................ 63
Figura 35 - Monitoramento da gincana .................................................................................... 64
Figura 36 - Avaliação das tarefas de imagem ......................................................................... 64
Figura 37 - Avaliação das tarefas de vídeo ........................................................................... 65
Figura 38 - Avaliação das tarefas de geolocalização ...................................................... 65
Figura 39 - Resultado final da gincana ..................................................................................... 66
Figura 40 - Localização da Chave de API do Trello ................................................................ 76
Figura 41 – Configurando URIs de redirecionamento ............................................................. 77
Figura 42 - Habilitando usuários .............................................................................................. 78
LISTA DE QUADROS
Quadro 1 - Lista de recursos e plugins ..................................................................................... 17
Quadro 2 - Diretiva ng-map do módulo ngMap ................................................................... 47
Quadro 3 - Código para integração com o Trello no Front-end ......................................... 48
Quadro 4 - Integração com o Trello na ativação da gincana .................................................... 48
Quadro 5 - Integração com a rede social Facebook.................................................................. 49
Quadro 6 - Integração com o Ionic Platform ............................................................................ 50
Quadro 7 - Enviando dados do usuário para o back-end .......................................................... 50
Quadro 8 - Enviando notificações no back-end........................................................................ 51
Quadro 9 - Realizando uma busca de vídeos no YouTube....................................................... 52
Quadro 10- Utilizando a câmera do dispositivo móvel ............................................................ 53
Quadro 11 - Integração com o Google Maps no aplicativo ...................................................... 54
Quadro 12 - Quadro comparativo entre os trabalhos correlatos ............................................... 69
Quadro 13 - Importando client.js ..................................................................................... 76
Quadro 14 - Código fonte da página oauthcallback.html ......................................................... 77
Quadro 15 - Inicialização da classe ngFB ............................................................................... 78
LISTA DE ABREVIATURAS E SIGLAS
API – Application Programming Interface
APNS – Apple Push Notification Service
GCM – Google Cloud Messaging
HTTP – HyperText Transfer Protocol
HTTPS – HyperText Transfer Protocol Secure
MVC – Model-View-Controller
URI – Uniform Resource Locator
URL – Uniform Resource Locator
SUMÁRIO
1 INTRODUÇÃO .................................................................................................................. 12
1.1 OBJETIVOS ...................................................................................................................... 13
1.2 ESTRUTURA.................................................................................................................... 14
2 FUNDAMENTAÇÃO TEÓRICA .................................................................................... 15
2.1 REALIDADE ALTERNATIVA – GINCANAS VIRTUAIS ........................................... 15
2.2 FURB – INTERAÇÃO FURB .......................................................................................... 16
2.3 PHONEGAP ...................................................................................................................... 17
2.4 IONIC PLATFORM – NOTIFICAÇÕES PUSH.............................................................. 18
2.5 TRABALHOS CORRELATOS ........................................................................................ 19
2.5.1 Sistema Móvel na plataforma Android para compartilhamento de geolocalização usando
mapas e notificações da Google ...................................................................................... 20
2.5.2 Tô Aqui: Aplicativo para georreferenciamento em ambientes restritos ......................... 21
2.5.3 Ingress ............................................................................................................................. 22
3 DESENVOLVIMENTO .................................................................................................... 24
3.1 REQUISITOS .................................................................................................................... 24
3.2 ESPECIFICAÇÃO ............................................................................................................ 26
3.2.1 Diagrama de casos de uso ............................................................................................... 27
3.2.2 Diagrama de classes ........................................................................................................ 29
3.2.3 Diagrama de atividades ................................................................................................... 41
3.2.4 Arquitetura e integrações do aplicativo........................................................................... 42
3.3 IMPLEMENTAÇÃO ........................................................................................................ 44
3.3.1 Técnicas e ferramentas utilizadas.................................................................................... 45
3.3.2 Trechos de código ........................................................................................................... 46
3.3.3 Operacionalidade da implementação .............................................................................. 55
3.4 RESULTADOS E DISCUSSÕES ..................................................................................... 66
3.4.1 Quadro de comparação entre os trabalhos ...................................................................... 69
4 CONCLUSÕES .................................................................................................................. 71
4.1 EXTENSÕES .................................................................................................................... 72
APÊNDICE A – INTEGRANDO COM O TRELLO ......................................................... 76
APÊNDICE B – INTEGRANDO COM O FACEBOOK ................................................... 77
12
1 INTRODUÇÃO
Atualmente vive-se em uma sociedade onde cada vez mais se está conectado uns aos
outros por meio da tecnologia, podendo a qualquer momento e lugar obter e compartilhar
informações e relacionamentos. Se está vivendo a chamada terceira plataforma da Tecnologia
da Informação (TI), onde após as duas primeiras plataformas, mainframes e PCs, a terceira
plataforma é baseada no uso comum e integrado de serviços de nuvem (cloud computing), de
mobilidade, de big data em soluções inteligentes capazes de lidar com grande volume de
dados e de rede sociais (social business) (SCHNEIDER, 2013).
As soluções criadas utilizando tecnologias móveis tornam-se acessíveis à medida que
inovações tecnológicas permitem que o smartphone seja performático e com suporte aos
vários recursos multimídia por um custo baixo. Assim, o número de pessoas que utilizam os
smartphones está aumentado (FACEBOOK PARA EMPRESAS, 2013).
Os indivíduos que nasceram a partir de 1989, a chamada geração Z, são incentivadores
e adeptos das novas tecnologias (CERETTA; FROEEMING, 2011). No Brasil, 9 em cada 10
possuem um aparelho celular e 8% deles não são usuários da internet (CONSUMERLAB,
2012, apud ERICSSON, 2013). O smartphone é utilizado para se relacionar com amigos, para
pesquisar preços, localizar estabelecimentos, pesquisar sobre assuntos de interesse, entre
outras atividades. As organizações que desejam conquistar esse público devem estar
preparadas para atender as expectativas e necessidades dessa geração que está tão acostumada
com o uso dessa tecnologia (CERETTA; FROEEMING, 2011). As universidades também se
encaixam nesse cenário e precisam introduzir o uso dessa tecnologia ao seu cotidiano para
buscar a atenção dessa geração tão conectada.
A Universidade Regional de Blumenau (FURB) realiza o evento Interação FURB
desde 2007, com a intenção de apresentar a estrutura da universidade para os alunos que estão
finalizando o ensino médio (geração Z), através de oficinas e atividades relacionadas com os
cursos da instituição (UNIVERSIDADE REGIONAL DE BLUMENAU, 2014b). No ano de
2015 foram mais de 26.000 vagas ofertadas em mais de 590 oficinas. Se inscreveram no
evento um total de 7.500 alunos, vindos de mais de 190 escolas de Blumenau e região
(FURBTV, 2015).
As atividades realizadas no evento envolvem a preparação de salas, auditórios,
laboratórios e tendas espalhadas pela universidade para atender os alunos. Para ajudar os
alunos a chegarem nesses lugares, são posicionados vários marcadores e pessoas em lugares
13
estratégicos para indicar a localização correta (UNIVERSIDADE REGIONAL DE
BLUMENAU, 2014b).
Uma estratégia para atrair as pessoas em tarefas de uma forma mais imersiva e
utilizando as novas tecnologias são as Gincanas Virtuais. Esse tipo de atividade procura
acrescentar elementos reais a uma Realidade Virtual (RV), tornando o ambiente virtual mais
próximo da realidade (NASCIMENTO; CALAÇA; MELO, 2009). Segundo Souza (2008, p.
149), uma gincana permite aos seus participantes que se “movimentem em busca de parcerias
e na exploração de atividades e objetos, comunicando-se com seus pares, expressando-se por
meio de múltiplas linguagens, descobrindo regras e tomando decisões”.
Desta forma, foi identificada uma oportunidade de desenvolver um aplicativo de
gincanas virtuais para dispositivos móveis no qual pudesse ser utilizado no evento Interação
FURB, contribuindo na tarefa das universidades de atrair a atenção do público jovem e
possibilitando maior interação dos possíveis novos alunos com a própria universidade.
Este trabalho apresenta o desenvolvimento de um aplicativo interativo que possibilite
aos alunos do evento Interação FURB participarem de gincanas virtuais, possibilitando a
integração com as redes sociais.
1.1 OBJETIVOS
O objetivo deste trabalho é criar uma aplicação de gincana virtual voltada para o
evento Interação FURB utilizando o framework multiplataforma Phonegap.
Os objetivos específicos do trabalho são:
a) disponibilizar o uso da rede social Facebook para autenticação e integração dos
grupos;
b) disponibilizar um quadro público da gincana no Trello para que qualquer pessoa
possa acompanhar o seu andamento;
c) disponibilizar a utilização dos recursos do dispositivo móvel na resolução de
tarefas;
d) disponibilizar a utilização da plataforma de compartilhamento de vídeos YouTube
na resolução de tarefas de vídeo;
e) possibilitar o recebimento de notificações para o acompanhamento dos
acontecimentos na gincana;
f) utilizar a solução OpenShift como plataforma de serviço para hospedar o servidor
do protótipo online.
14
1.2 ESTRUTURA
Para melhor organização e entendimento do leitor, este trabalho está separado em
quatro capítulos. Iniciando o primeiro capítulo com a introdução ao tema do trabalho, seguido
do segundo capítulo no qual estão descritos os fundamentos básicos para o entendimento das
técnicas e ferramentas utilizadas. O terceiro capítulo apresenta informações sobre a
construção do aplicativo como diagramas, arquitetura, comunicação entre cliente e servidores
e o código fonte. As últimas seções trazem as telas do aplicativo demonstrando sua
operacionalidade, os resultados obtidos após o desenvolvimento e comparação entre os
trabalhos correlatos. No quarto e último capítulo estão as conclusões finais e sugestões para o
desenvolvimento de trabalhos futuros.
15
2 FUNDAMENTAÇÃO TEÓRICA
A seção 2.1 descreve realidade alternativa e gincanas virtuais, apresentando alguns
conceitos iniciais sobre realidade virtual, os tipos de realidade e o surgimento de gincanas
virtuais. Na seção 2.2 é apresentado como a FURB foi criada e o que é o evento Interação
FURB. Na seção 2.3 é apresentado um pouco sobre o framework Phonegap e seus recursos
para o desenvolvimento multiplataforma. Na seção 2.4 é apresentado o Ionic Plataform, e
como a ferramenta possibilita o envio de notificações push para as plataformas Android e
iOS. E ao final, a seção 2.5 apresenta três trabalhos correlatos.
2.1 REALIDADE ALTERNATIVA – GINCANAS VIRTUAIS
A Realidade Virtual (RV) busca criar novas interfaces que cheguem o mais próximo
dos sentidos dos seres humanos. A RV trabalha na ponta do desenvolvimento tecnológico e o
que é considerado RV pode vir a ser a interface padrão do computador do futuro, e RV passa
a ser o que se está sendo pesquisado nos laboratórios de pesquisa (KIRNER, 2004).
A RV possui várias definições aceitas no meio acadêmico, tanto por ser uma área
multidisciplinar, quanto por ser uma área em constante evolução (PINHO; KIRNER,
[1997?]). Uma definição mais refinada de RV, segundo Tori, Kirner e Siscouto (2006, p. 7)
diz que a RV “é uma interface avançada para aplicações computacionais, que permite ao
usuário a movimentação (navegação) e interação em tempo real, em um ambiente
tridimensional, podendo fazer uso de dispositivos multissensoriais, para atuação ou
feedback”.
A RV pode ser classificada conforme o nível de interação do usuário com o sistema de
RV, em imersiva e não-imersiva. É imersiva quando o usuário é transportado para o domínio
da aplicação de RV, com a utilização de ferramentas que auxiliem na imersão, como, por
exemplo, capacete e luva para simulação de visão e tato, auxiliando a sensação de estar dentro
de um mundo virtual. E é não-imersiva quando o usuário é transportado para o domínio da
aplicação parcialmente, interagindo com um mundo virtual sem fazer parte dele, como, por
exemplo, a utilização de monitor e projeção (TORI; KIRNER; SISCOUTO, 2006).
Com a evolução das aplicações multimídias e da RV, e também devido ao maior poder
de processamento nos computadores, tornou-se possível aplicações do tipo Realidade
Aumentada (TORI; KIRNER; SISCOUTO, 2006). A RV procura trazer o usuário da
aplicação para o ambiente virtual, já a Realidade Aumentada, segundo Tori, Kirner e Siscouto
(2006, p. 22), “mantém o usuário no seu ambiente físico e transporta o ambiente virtual para o
16
espaço do usuário, permitindo a interação com o mundo virtual, de maneira mais natural e
sem necessidade de treinamento ou adaptação”.
Um tipo de aplicação que está aparecendo nos últimos anos são as aplicações de
realidade alternativa de gincanas virtuais. Nessas aplicações os usuários interagem com
elementos reais para interagir em um mundo virtual, misturando elementos reais com virtuais
(NASCIMENTO; CALAÇA; MELO, 2009). Nas gincanas os participantes se dividem em
grupos e buscam realizar tarefas para completar objetivos. Durante essa busca, são
desenvolvidas habilidades de trabalho em grupo e o desenvolvimento do raciocínio. Os
participantes são postos a lidar com diferentes situações e precisam utilizar habilidades que
muitas vezes não estão habituados a utilizar (GOSSENHEIMER; CARNEIRO; CASTRO,
2015).
2.2 FURB – INTERAÇÃO FURB
A FURB teve sua origem no ano de 1964. Com os esforços da comunidade da região
em trazer ensino de nível superior para o interior do estado de Santa Catarina, foi criada a
Faculdade de Ciências Econômicas. Com a construção de um obelisco em 1968, é iniciada a
construção da sede da universidade. Neste ano também foi assinada a carta de Ibirama,
documento símbolo que representa a integração dos municípios em reconhecer a instituição
como universidade. Em 1995, pela Lei Complementar Municipal nº 80, a Universidade
Regional de Blumenau figura como uma Instituição de Ensino Superior criada e mantida pela
Fundação Universidade Regional de Blumenau (UNIVERSIDADE REGIONAL DE
BLUMENAU, 2014a).
Desde de 2007 a FURB vem realizando o evento Interação FURB. Este evento tem
como objetivo apresentar toda a estrutura da universidade para os alunos do ensino médio da
região, através de oficinas e atividades, no intuito de auxiliá-los na escolha do seu futuro
profissional. Como os alunos que participam do evento não conhecem a estrutura da
universidade, a FURB posiciona placas, avisos e disponibiliza pessoas para que sirvam como
guia para que os alunos consigam achar os locais onde são ministrados as palestras e oficinas.
(UNIVERSIDADE REGIONAL DE BLUMENAU, 2014b).
As atividades são focadas nos cursos oferecidos na universidade. Os alunos se
inscrevem de acordo com o seu interesse em cada área, podendo tirar dúvidas com os
professores e alunos do curso. Por exemplo, existe a oficina de robótica do curso Ciência da
Computação, onde os alunos são apresentados a alguns conceitos da área e podem ver os
trabalhos feitos dentro da disciplina de robótica. Outro exemplo de oficina é o júri simulado
17
do curso de Direito, onde os alunos podem participar como ouvintes de um tribunal. É
explicado o objetivo e como uma sessão é organizada, quais os papeis que existem e a função
de cada um (FURBTV, 2015; OSTETTO, 2013).
Este evento é uma oportunidade para a universidade divulgar seu nome e seu trabalho
para a comunidade, visando também a motivação dos alunos para escolher a FURB como seu
futuro no ensino superior.
2.3 PHONEGAP
O Phonegap foi criado para resolver o problema que os desenvolvedores possuem
quando precisam criar aplicativos para várias plataformas existentes no mercado, como por
exemplo iPhone, Android, Windows Phone, entre outras. Como cada plataforma utiliza uma
framework e linguagem diferente, os desenvolvedores, caso desejarem que seus aplicativos
tenham uma maior abrangência no mercado, precisam investir seus recursos em várias frentes
de desenvolvimento. O Phonegap resolve este problema porque utiliza tecnologias baseadas
em padrões da web, como, por exemplo, HTML, CSS e JavaScript, tornando o aplicativo apto
a futuramente evoluir para ser compatível com os navegadores (TRICE, 2012a).
O desenvolvimento com o Phonegap envolve a utilização de plugins para acessar os
recursos nativos do celular (TRICE, 2012b). Alguns recursos geralmente utilizados são GPS,
push notification, integração com redes sociais e banco de dados. O Quadro 1 mostra uma
relação de plugins disponíveis no Phonegap para cada recurso mencionado.
Quadro 1 - Lista de recursos e plugins
Recurso Plugin Link
GPS Cordova-plugin-
geolocation
https://github.com/apache/cordova-plugin-geolocation
Push notification Phonegap-plugin-
push
https://github.com/phonegap/phonegap-plugin-push
Integração rede
social
SocialSharing-
PhoneGap-Plugin
https://github.com/EddyVerbruggen/SocialSharing-
PhoneGap-Plugin
Banco de dados Cordova-sqlite-
storage
https://github.com/litehelpers/Cordova-sqlite-storage
Fonte: adaptado de Apache Cordova (2013).
O Phonegap possui uma interface via linha de comando, Phonegap CLI, que possibilita
que os plugins sejam adicionados ao projeto. Por exemplo, para adicionar o plugin que
permite a manipulação de dados de GPS, basta executar o comando cordova plugin add
cordova-plugin-geolocation, conforme a Figura 1.
18
Figura 1 - Adicionando o plugin de GPS
É possível a criação de plugins customizados para que os desenvolvedores possam
utilizar todos os recursos do desenvolvimento nativo em uma plataforma híbrida. Um
exemplo de uso de plugin customizado seria a criação de uma interface que comunica
nativamente com o back-end da aplicação, na tentativa de proteger os dados de acesso ao
serviço. Esses plugins devem ser escritos na linguagem nativa de cada plataforma.
O Phonegap utiliza os componentes padrões do HTML5 para a interface com o
usuário, fazendo com que o aplicativo se assemelhe muito a uma página web. Para diminuir a
sensação do usuário estar navegando em um site, existem alguns frameworks que fornecem
componentes visuais que se adaptam ao sistema operacional do dispositivo móvel do usuário.
Um desses frameworks é o Ionic, criado em 2013, focado em disponibilizar um SDK de
componentes para web, utilizando as tecnologias HTML, CSS e Javascript, tendo o
framework AngularJS como suporte à criação de aplicações utilizando o modelo MVC
(Model-View-Controller) (IONICFRAMEWORK, 2016; PEREIRA, 2015).
2.4 IONIC PLATFORM – NOTIFICAÇÕES PUSH
O Ionic Platform é um conjunto de serviços integrados na nuvem, focado em
proporcionar ferramentas que ajudam o desenvolvimento, distribuição e escalonamento de
aplicativos. Ele oferece serviços para autenticação de usuários, notificações push, compilação
e distribuição nas lojas de aplicativo oficiais do Google (Google Play) e Apple (App Store).
Com isso, mesmo o desenvolvedor não possuindo um Mac, ele pode disponibilizar o
aplicativo na App Store através do Ionic Platform. A plataforma também fornece a
atualização dos aplicativos integrada com o Google Play e App Store, onde após realizar o
deploy para o Ionic Platform, a própria plataforma atualiza as lojas com a nova versão (IONIC
PLATFORM, 2016a).
Para aumentar o engajamento dos usuários na utilização do aplicativo, é importante
manter o seu conteúdo sempre atualizado. Uma maneira comum de fazer isso é a utilização de
notificações push, informando sobre as novidades do aplicativo sem a necessidade do mesmo
estar aberto. As notificações push são textos curtos enviados pelos aplicativos para os
19
dispositivos móveis (ANDROID DEVELOPERS, 2016). Cada plataforma possui um serviço
próprio para o envio de notificações, exigindo configurações específicas para os aplicativos
que fazem uso desse recurso. O serviço de Push do Ionic Platform oferece uma solução
integrada com os serviços de notificação das plataformas Android e iOS. A Figura 2 ilustra o
funcionamento do serviço de notificações do Ionic Platform, onde o envio de notificações é
centralizado na API de push, que, através de um registro prévio do aplicativo identificando o
dispositivo móvel com um token, encaminha a mensagem para o serviço de notificação
correspondente ao sistema operacional do dispositivo móvel, ficando esse responsável pela
entrega da notificação para o usuário (IONIC PLATFORM, 2016b).
Figura 2 - Funcionamento da API de push do Ionic Platform
Fonte: Ionic Platform (2016b).
2.5 TRABALHOS CORRELATOS
A seguir são descritos dois trabalhos e um produto com características semelhantes aos
principais objetivos deste trabalho. A seção 2.4.1 detalha “Sistema móvel na plataforma
Android para compartilhamento de geolocalização usando mapas e notificações da Google”
de Kestring (2014). A seção 2.4.2 detalha “TôAqui! Aplicativo para Georreferenciamento em
Ambientes Restritos” de Rocha (2015). É possível verificar que nestes dois trabalhos foi
utilizada uma aplicação na plataforma móvel para ser aplicado no evento Interação FURB. A
seção 2.4.3 traz o produto Ingress (NIANTIC LABS, 2012). Neste jogo é possível verificar
que é utilizado o conceito de mundo virtual junto com a utilização de lugares reais para
aumentar a imersão dentro do jogo. A seção 2.5 traz um quadro comparativo entre os
trabalhos correlatos.
20
2.5.1 Sistema Móvel na plataforma Android para compartilhamento de geolocalização
usando mapas e notificações da Google
O trabalho de Kestring (2014) busca auxiliar os usuários a se localizarem no evento
Interação FURB. Através de um aplicativo é possível visualizar a posição do usuário, a
posição de outros usuários logados e visualizar os pontos de interesse cadastrados pelo
usuário e/ou pela universidade. O aplicativo foi desenvolvido utilizando Java na plataforma
Android.
Foi desenvolvido também um aplicativo servidor web service em Java para atender as
necessidades do aplicativo mobile. A Figura 3 apresenta a arquitetura da solução
desenvolvida.
Figura 3 - Cenário do Sistema
Fonte: Kestring (2014, p. 23).
Conforme descrito no trabalho de Kestring (2014), segue legenda da arquitetura do
projeto apresentada na Figura 3.
A aplicação cliente denominada VisEduAndroid (1), a área de recursos
compartilhados (2), o serviço Google Cloud Message (GCM) na aplicação cliente
(3), o serviço BroadcastReceiver configurado para receber notificações (4), o
próprio servidor GCM da Google (5), o aplicativo servidor VisEduWebservice (6), o
serviço Cloud Connection Server (CCS) no servidor (7) e o armazenamento das
informações na base de dados MySQL no servidor (8). O aplicativo cliente salva o
gcmId, que é o registro de identificação do aparelho no GCM, na SharedPreferences
do Android, para que posteriormente ele utilize este mesmo identificador sem a
necessidade de realizar um novo registro (A). O aplicativo VisEduAndroid envia e
recebe informações do aplicativo VisEduWebservice através do webservice
construído para realizar a comunicação entre o aplicativo cliente e o aplicativo
servidor (B). O aplicativo VisEduAndroid identifica a necessidade de registrar o
21
aparelho no GCM e inicia o processo requisitando o identificador. Ao receber o
identificador, guarda o valor na SharedPreferences do Android e envia via
notificação o valor para o servidor VisEduWebservice. O primeiro projeto
desenvolvido foi o VisEduAndroid, conforme representado na legenda (1) da Figura
3, responsável por apresentar os dados ao usuário e trata os eventos ocorridos para
enviar os dados do aplicativo para o servidor webservice (B). O servidor webservice
por sua vez, representa o segundo projeto, que disponibiliza acesso ao banco de
dados conforme representado na legenda (6) da Figura 3 (KESTRING, 2014, p. 23-
24).
O trabalho de Kestring (2014) não distingue qual a altitude da posição do usuário. Não
é possível saber se o ponto de interesse está acima ou abaixo da posição atual. O trabalho de
Rocha (2015) descrito a seguir trata esta situação utilizando AGPS e Beacons.
2.5.2 Tô Aqui: Aplicativo para georreferenciamento em ambientes restritos
O trabalho de Rocha (2015) busca, através da utilização de Assisted Global Positioning
System (AGPS) e Beacons, aprimorar o georreferenciamento em ambientes restritos. Neste
trabalho é possível visualizar a localização do usuário dentro de um mapa interno. Também é
possível receber notificações conforme a localização dentro da universidade. O usuário é
notificado ao se aproximar de um local que possua um evento que acontecerá dentro de 1
hora. Rocha (2015) resolveu o problema da altitude (se o ponto de interesse está acima, no
andar atual, ou abaixo da posição do usuário) utilizando os Beacons. Cada Beacon é
configurado com as informações de latitude, longitude e andar, assim, quando o celular se
comunica com um Beacon, é possível definir em qual andar e direção o ponto de interesse
está. A comunicação com o Beacon é feita através de bluetooth.
Na Figura 4 é possível visualizar a tela inicial do aplicativo. Na parte superior é
indicado em qual bloco e andar o usuário está. A localização atual do usuário é apresentada no
centro da tela.
22
Figura 4 - Tô Aqui: Tela inicial
Fonte: Rocha (2015, p. 48).
Para o desenvolvimento do aplicativo foi utilizado o framework Phonegap. Segundo
Rocha (2015), a utilização desse framework foi muito efetiva e cumpriu com o seu objetivo.
Em sua conclusão, ele descreve:
A possibilidade de disponibilizar o aplicativo para a plataforma iOS e para a
plataforma Android com todos os recursos foi um objetivo concluído e muito
importante, pois com a mesma implementação será possível atender uma quantidade
maior de usuários e a manutenção do código estaria centralizada em apenas um
projeto, além de comprovar o uso de um gerador de código, Cordova/Phonegap,
para gerar um aplicativo integrado com hardware (ROCHA, 2015, p. 57).
2.5.3 Ingress
Ingress é um jogo criado pela empresa NianticLabs, startup do Google, e foi lançado
em dezembro de 2012 para dispositivos Android. No mundo virtual de Ingress, duas
organizações rivais lutam pelo domínio sobre uma energia que emana de vários pontos do
planeta. A organização “The Enlightened” defende que essa energia é benéfica e deve ser
utilizada para o bem do planeta. A organização “The Resistence” defende que essa energia
está influenciando a mente das pessoas e que deve ser detida (KARASINSKI, 2012).
O jogo Ingress está na categoria de jogos de Realidade Alternativa. Nele é preciso
realizar missões tanto na tela do aplicativo como na vida real. Nessas missões o usuário deve
23
seguir trajetos previamente especificados para acumular pontos e destravar melhorias
(KARASINSKI, 2012).
A Figura 5 mostra a tela inicial do jogo. A esquerda é possível verificar a posição do
usuário (uma seta com um círculo ao redor) e a posição de uma fonte de energia
(concentração de pontos logo acima da posição do usuário). A direita é possível verificar
alguns portais próximos a localização do usuário.
Figura 5 - Tela inicial do jogo Ingress
Fonte: Reis (2014, p. 371).
É utilizado o GPS do smartphone para mostrar a localização do usuário. A plataforma
de desenvolvimento utilizada foi o libGDX (LIBGDX, 2015a). O libGDX é um framework
Open Source de desenvolvimento de jogos escrito em Java e permite o desenvolvimento para
as plataformas desktop, web e mobile utilizando a mesma base de código. Este framework
utiliza o Open GL ES 2 para processamento gráfico (LIBGDX, 2015b).
24
3 DESENVOLVIMENTO
Este capítulo aborda os aspectos referente à construção do aplicativo. Na seção 3.1
encontram-se os requisitos funcionais e não funcionais. Na seção 3.2 são apresentados os
diagramas de casos de usos, classes e atividades, detalhando o funcionamento e especificando
o aplicativo. Ainda nesta seção, são apresentados os principais serviços que integram o Furb
Mobile Gincanas, mostrando a comunicação entre todos os componentes. A seção 3.3 trata de
todas as ferramentas, bibliotecas e frameworks utilizados durante o desenvolvimento. Os
principais trechos de código e utilização do aplicativo também são explicados nesta seção.
Para encerrar o capítulo, a seção 3.4 expõem os resultados obtidos após o desenvolvimento do
aplicativo e realiza a comparação entre trabalhos correlatos apresentados na seção 2.4.
3.1 REQUISITOS
Os requisitos funcionais e não funcionais do aplicativo estão descritos conforme a lista
abaixo:
a) permitir que o usuário utilize sua conta da rede social Facebook para se autenticar
(Requisito Funcional - RF);
b) permitir que o usuário participe de gincanas (RF);
c) permitir que o usuário participe de grupos (RF);
d) permitir que o usuário assuma o papel de líder e delegue tarefas para outros
membros do grupo (RF);
e) permitir que o usuário utilize a câmera do dispositivo móvel para resolver tarefas
de imagem (RF);
f) permitir que o usuário utilize o site de compartilhamento de vídeos YouTube para
resolver tarefas de vídeo (RF);
g) permitir que o usuário visualize sua localização atual em um mapa (RF);
h) permitir que o usuário utilize sua localização atual através do GPS para resolver
tarefas de geolocalização (RF);
i) notificar o líder do grupo sobre novos membros (RF);
j) notificar um membro do grupo quando uma tarefa é associada a ele (RF);
k) notificar o líder do grupo quando um membro fica sem tarefas (RF);
l) notificar o líder e o membro responsável pela tarefa quando a mesma é avaliada
(RF);
m) notificar todos os participantes da gincana sobre o resultado final da gincana (RF);
25
n) permitir que o usuário acesse o placar da gincana no Trello (RF);
o) o aplicativo deve ser desenvolvido com a plataforma PhoneGap (Requisito Não-
Funcional – RNF);
p) o aplicativo deve utilizar o framework Ionic (RNF);
q) o aplicativo deve ser desenvolvido no ambiente de desenvolvimento Visual Studio
Code (RNF);
r) o aplicativo deve se comunicar com o servidor back-end por requisições web
service do tipo REST, utilizando a biblioteca AngularJS (RNF);
s) o aplicativo deve utilizar a API do Google Maps para a plataforma PhoneGap e
realizar a integração com os mapas da Google (RNF);
t) o aplicativo deve utilizar o módulo do AngularJS ngCordova para acessar a
câmera e o GPS do dispositivo móvel (RNF);
u) o aplicativo deve utilizar a API do YouTube para permitir a integração dos vídeos
do YouTube (RNF);
v) o aplicativo deve utilizar a API do Ionic Platform para realizar a integração com o
servidor de notificações.
Os requisitos funcionais e não funcionais do site (front-end) e do servidor (back-end)
estão descritos conforme a lista abaixo:
a) permitir que o usuário crie gincanas (RF);
b) permitir que o usuário crie grupos (RF);
c) permitir que o usuário crie tarefas dos tipos pergunta, imagem, vídeo e
geolocalização (RF);
d) apresentar um mapa com uma cerca virtual quando a tarefa for do tipo
geolocalização (RF)
e) permitir que o usuário autorize o acesso do site a sua conta do Trello (RF);
f) disponibilizar uma tela para monitoramento da gincana (RF);
g) permitir que as tarefas sejam avaliadas (RF);
h) mostrar a imagem utilizada pelo participante da gincana na resolução das tarefas
de imagem (RF);
i) mostrar o vídeo utilizado pelo participante da gincana na resolução das tarefas de
video (RF);
j) mostrar a localização do participante da gincana usada na resolução das tarefas de
geolocalização (RF);
26
k) o servidor deve converter o token de autorização do usuário no Facebook para um
token de longa duração (RF);
l) o servidor deve notificar os usuários do aplicativo sobre os acontecimentos da
gincana (RF);
m) o servidor deve criar os quadros, listas e cartões respectivos as gincanas, grupos e
tarefas no Trello (RF);
n) o site deve ser desenvolvido com tecnologia web (HTML, CSS e Javascript) no
ambiente de desenvolvimento Visual Studio Code (RNF);
o) a arquitetura do site deve utilizar o modelo MVC utilizando o framework
AngularJS (RNF);
p) o site deve utilizar a biblioteca cliente.js para realizar a integração com o Trello;
q) o site deve utilizar a API do Google Maps para a plataforma Javascript e realizar a
integração com os mapas da Google (RNF);
r) o servidor deve ficar hospedado online na plataforma OpenShift (RNF);
s) o servidor deve ser desenvolvido na linguagem de programação Java no ambiente
de desenvolvimento Eclipse, utilizando a ferramenta para automação de
compilação Maven (RNF);
t) o servidor deve suportar chamadas REST através do framework RESTEasy
(RNF);
u) o servidor deve utilizar a classe JTrello, disponibilizada pelo usuário asommariva
no serviço de hospedagem de projetos Bitbucket, para integrar com a API do
Trello (RNF);
v) o servidor deve utilizar a biblioteca restfb para integrar com a API do Facebook
(RNF);
w) o servidor deve utilizar a classe Ionic, disponibilizada pelo usuário slarsen no
serviço de hospedagem de projetos GitHub, para integrar com o Ionic Platform
(RNF);
x) o servidor deve utilizar o banco de dados PostgreSQL e realizar a persistência dos
dados através do framework Hibernate (RNF).
3.2 ESPECIFICAÇÃO
Para o entendimento das funcionalidades e arquitetura do aplicativo, esta seção
apresenta os diagramas de casos de uso, classes e atividades, elaborados com as ferramentas
27
StarUML, Creately e Draw.io. No final desta seção é apresentada a arquitetura de
comunicação entre o aplicativo, site e o servidor.
3.2.1 Diagrama de casos de uso
A partir do levantamento dos requisitos da aplicação, foram desenvolvidos dois
diagramas de caso de uso. A Figura 6 mostra os casos de usos que representam as
funcionalidades disponíveis para o ator Organizador.
Figura 6 - Casos de uso do front-end
O caso de uso UC01 – Cadastrar gincana é a ação inicial que o Organizador deve
fazer para iniciar o cadastro de uma gincana. No caso de uso UC02 – Cadastrar tarefas é
possível cadastrar tarefas do tipo pergunta, imagem, vídeo e geolocalização. Para as tarefas do
tipo localização, o caso de uso UC03 – Tarefa geolocalização permite ao Organizador
selecionar um local no mapa e definir o tamanho do raio de alcance. O caso de uso UC04 –
Vincular dependência permite definir quais tarefas são pré-requisitos para outra. No caso
de uso UC05 – Cadastrar grupo é possível cadastrar os grupos que participaram da
gincana. No caso de uso UC06 – Ativar gincana, é necessário o usuário possuir e autorizar
sua conta do Trello para integração com o Furb Mobile Gincanas, como descrito no caso de
uso UC07 – Autorizar Trello. O link do quadro criado no Trello para a gincana está
disponível para consulta no caso de uso UC08 – Visualizar Trello. No caso de uso UC09
– Monitorar gincana, o usuário pode verificar o andamento da gincana, podendo visualizar
as tarefas e avaliar as já resolvidas. No caso de uso UC10 – Avaliar resposta o usuário
28
deve dar uma nota para a resposta da tarefa. Ao chegar ao final da gincana, o usuário deve
finalizar a gincana através do caso de uso UC11 – Finalizar gincana.
A Figura 7 mostra os casos de uso que representam as funcionalidades disponíveis para
o ator Participante e para as suas generalizações Líder e Membro.
Figura 7 - Casos de uso do mobile
O caso de uso UC01 – Efetuar login é a ação inicial do usuário para utilizar o Furb
Mobile Gincanas, ele deve autorizar o acesso ao seu nome e foto pública de perfil do
Facebook. Após sua autenticação, o caso de uso UC02 – Participar gincana permite o
usuário entrar em uma gincana. Ao entrar na gincana, o usuário deve escolher um grupo para
entrar, descrito no caso de uso UC03 – Participar grupo. Caso ele seja o primeiro
integrante do grupo, ele se torna o líder do mesmo, caso contrário ele vira um membro
comum. O caso de uso UC04 – Delegar tarefa permite que o Líder possa delegar uma
tarefa para um membro do grupo que não esteja associado com alguma tarefa. O caso de uso
UC05 – Resolver tarefa permite ao usuário resolver uma tarefa que esteja associada com
seu usuário. Como descrito nos casos de uso UC06 – Resolver tarefa pergunta, UC07 –
Resolver tarefa imagem, UC08 – Resolver tarefa vídeo e UC09 – Resolver tarefa
geolocalização, cada tarefa exige um tipo de resposta diferente. Quando a tarefa for do tipo
imagem, é necessário que o usuário permita o aplicativo acessar sua câmera para tirar fotos,
ação que está descrita no caso de uso UC10 – Autorizar acesso a câmera. Quando a
tarefa for do tipo geolocalização, é necessário que o usuário permita o aplicativo receber suas
informações de localização fornecidas pelo GPS e com base na rede, ação que está descrita no
29
caso de uso UC11 – Autorizar acesso a localização. No caso de uso UC12 –
Visualizar placar é possível visualizar o quadro correspondente a gincana no site Trello.
3.2.2 Diagrama de classes
O diagrama de classes apresenta uma visão de como as classes estão estruturadas e
relacionadas. Nesta seção são descritas as classes necessárias para o desenvolvimento desta
aplicação, sendo que a aplicação está dividida em três partes, o front-end, aplicativo mobile e
back-end.
3.2.2.1 Diagrama de classes do front-end
A Figura 8 retrata a estrutura de classes do front-end. A classe Gincana contém as
propriedades utilizadas pela aplicação para representar uma gincana. A classe gincanaCtrl
controla a apresentação das gincanas existentes no sistema, permitindo também a sua
ativação. A classe novoGincanaCtrl permite o cadastro e alteração de gincanas. A classe
monitorarGincanaCtrl disponibiliza a visualização do andamento da gincana,
disponibilizando uma lista de tarefas por usuário, além de permitir o encerramento da gincana.
A classe gincanaAPI contém os métodos de comunicação com o back-end necessários para
inserir, alterar, listar, monitorar e finalizar uma gincana. A classe Tarefa contém as
propriedades utilizadas na aplicação para representar uma tarefa da gincana. A classe
tarefaGincanaCtrl permite a visualização das tarefas cadastradas. A classe
novoTarefaCtrl permite o cadastro e alteração das tarefas. A classe
dependenciaTarefaCtrl contém os métodos para visualizar e alterar a dependência entre as
tarefas. A classe TarefaGrupo contém as propriedades utilizadas na aplicação para
representar uma tarefa do grupo associada a um usuário. A classe avaliarRespostaCtrl
permite visualizar a resposta dada por um participante a tarefa e também permite sua
avaliação com uma nota de zero a dez. A classe tarefaAPI contém os métodos de
comunicação com o back-end necessários para inserir, alterar, vincular dependência e avaliar
uma tarefa.
A classe Grupo contém as propriedades utilizadas na aplicação para representar um
grupo da gincana. A classe gruposGincanaCtrl permite visualizar os grupos cadastrados. A
classe novoGrupoCtrl é utilizado para cadastrar e alterar os grupos. A classe grupoAPI
contém os métodos de comunicação com o back-end necessários para inserir e alterar os
grupos. A classe config contém o endereço base para fazer as chamadas à API do back-end,
além do endereço base do diretório de imagens no servidor.
30
Figura 8 - Diagrama de classes do fron-end
3.2.2.2 Diagrama de classes do aplicativo mobile
A Figura 9 retrata a estrutura de classes do aplicativo mobile. A classe
furbMobileCtrl é responsável por realizar o login do usuário através do Facebook, obtendo
um token que será utilizado para realizar as chamadas à API do Facebook, tanto pelo
aplicativo mobile quanto pela aplicação back-end. Esta classe também obtém o token do
telefone que será utilizado para as Push Notifications integradas com o Ionic Platform. A
classe Usuario contém as propriedades utilizadas pela aplicação para representar um usuário.
A classe usuarioAPI contém os métodos de comunicação com o back-end necessários para
inserir, obter dados do usuário e obter uma lista de usuários sem tarefa. A classe Gincana
contém as propriedades utilizadas pela aplicação para representar uma gincana. A classe
gincanasCtrl permite a visualização de gincanas ativas, onde também é possível selecionar
uma gincana para entrar. A classe GincanaAPI contém os métodos de comunicação com o
back-end necessários para obter a lista de gincanas ativas e informações específicas de uma
gincana. A classe Grupo contém as propriedades utilizadas pela aplicação para representar um
grupo. A classe gruposCtrl disponibiliza a lista de grupos da gincana para o usuário escolher
para entrar. A classe GrupoAPI contém os métodos de comunicação com o back-end
necessários para obter a lista de grupos disponíveis para uma gincana, obter o grupo do
usuário e vincular o usuário com um grupo. A classe TarefaGrupo e Tarefa contêm as
31
propriedades utilizadas na aplicação para representar uma tarefa do grupo associada a um
usuário. A classe tarefasCtrl permite visualizar as tarefas associadas ao usuário. A classe
TarefaAPI contém os métodos de comunicação com o back-end necessários para obter a lista
de tarefas associadas ao usuário, atribuir uma tarefa a um membro e responder as tarefas de
pergunta, imagem, vídeo e geolocalização. A classe delegarTarefaCtrl permite ao líder do
grupo associar uma tarefa para um usuário sem tarefas.
A classe resolverPerguntaCtrl permite informar uma resposta para uma tarefa do
tipo pergunta. A classe resolverImagemCtrl faz acesso a câmera do aparelho para tirar uma
foto e responder uma tarefa do tipo imagem. A classe resolverVideoCtrl permite o usuário
procurar e selecionar um vídeo do site YouTube para responder uma tarefa do tipo vídeo. A
classe resolverGeolocalizacaoCtrl permite ao usuário verificar sua posição atual,
visualizar o objetivo da tarefa e responder a tarefa caso sua posição esteja dentro do raio do
ponto central do objetivo da tarefa do tipo geolocalização. A classe Config contém o
endereço base para fazer as chamadas à API do servidor back-end.
Figura 9 - Diagrama de classes do aplicativo mobile
32
3.2.2.3 Diagrama de classes do back-end
A Figura 10 apresenta o diagrama de pacotes do back-end da aplicação. O pacote API é
a porta de entrada para a comunicação entre a aplicação mobile e front-end com o back-end.
Este pacote faz uso dos objetos do pacote DTO para transferência simplificada de dados e dos
objetos do pacote Service para a invocação das regras de negócio. O pacote Service
representa as classes que possuem as regras de negócio que atuam sobre os objetos dos
pacotes DTO, MODEL e DAO. Os objetos do pacote DAO fazem a ligação do banco de dados com o
restante da aplicação, disponibilizando métodos para inserir, alterar e retornar os dados. Os
objetos do pacote MODEL representam a modelagem de tabelas e campos utilizados na
aplicação. O pacote Trello API faz a integração com a ferramenta Trello. O pacote Ionic
API faz a integração com a ferramenta Ionic Platform.
Figura 10 - Diagrama de classes da arquitetura do back-end
3.2.2.3.1 Diagrama de classes do pacote MODEL
A Figura 11 apresenta as classes que pertencem ao pacote MODEL. Estas classes contêm
as informações necessárias para a persistência dos dados no banco de dados. Todas elas
implementam a interface BaseEntityId, a qual possuem o campo id que é utilizado como
chave primária. A classe Usuario possui o id do usuário e token do Facebook, e token de
identificação para notificações push do Ionic Plataform. A classe Gincana possui os atributos
titulo, descricao e situacao, podendo estar não ativada, ativada e finalizada, além do
33
token utilizado para integração com o Trello, id e URL do quadro. A classe Grupo possui o
nome do grupo, o usuário líder e o id da lista correspondente ao grupo no quadro da gincana
no Trello. A classe Tarefa possui os atributos titulo, descricao e tipoTarefa, sendo que
os tipos podem ser pergunta, imagem, vídeo e geolocalização. A classe Tarefa também
representa a localização para as tarefas do tipo geolocalização, através dos atributos
latitude, longitude e raio. A classe DependenciaTarefa representa a ligação de uma
tarefa com outra, sendo que uma tarefa só fica disponível para o participante da gincana caso
não possua nenhuma tarefa requisito pendente. A classe UsuarioGrupo representa a ligação
do usuário com um grupo da gincana, sendo que um usuário pode apenas participar de um
grupo por gincana. A classe TarefaGrupo representa a tarefa associada ao grupo, com a
indicação do usuário responsável pela tarefa. Também possui os atributos de resposta,
latitude e longitude quando a tarefa for do tipo geolocalização, nota, situacao podendo
estar pendente, assumida, em avalição e completa, além da indicação do usuário associado a
tarefa. A classe ResultadoGincana contém os atributos utilizados para representar o
resultado do grupo na gincana. A classe possui os atributos de somaNotas, para indicar a
soma das notas, quantidadeIntegrantes, representando a quantidade de participantes do
grupo e colocacao, indicando a posição do grupo no placar final da gincana.
Figura 11 - Diagrama de classes do pacote MODEL
34
3.2.2.3.2 Diagrama de classes do pacote DAO
A Figura 12 apresenta as classes que pertencem ao pacote DAO. Estas classes
disponibilizam métodos para acesso aos dados no banco de dados. A classe GenericDAO
implementa métodos genéricos para adicionar, remover, buscar, atualizar e obter uma lista dos
registros. Todas as classes DAO estendem dessa classe para reaproveitar os métodos de acesso
simples. Cada DAO também possui os métodos create, que adiciona o registro caso seu id
não exista, ou atualiza caso exista, update para atualizar o registro e recupera para obter a
entidade pelo seu id. Além do método getEntityClass que retorna a classe da entidade base
da classe DAO.
A classe GincanaDAO disponibiliza o método getListaGincanaAtiva que retorna
uma lista de gincanas com a situação ativa. A classe GrupoDAO disponibiliza o método
getGruposFromGincana que retorna uma lista de grupos pertencentes a gincana. A classe
UsuarioDAO disponibiliza o método recuperaPorIdFacebook para recuperar o cadastro do
usuário pelo seu id do Facebook. A classe TarefaDAO disponibiliza o método
getTarefasByIdGincana que retorna uma lista de tarefas pertencentes a gincana. A classe
DependenciaTarefaDAO disponibiliza o método excluirDependenciasTarefa que exclui
todas a configuração de dependência e requisito de uma tarefa, e o método
obterTarefasDependentes que retorna uma lista de dependências da tarefa. A classe
TarefaGrupoDAO disponibiliza o método getTarefasFromGrupoByUsuario que retorna uma
lista de tarefas que estejam disponíveis ao usuário, ou seja, que estejam associadas ao usuário,
com a situação pendente ou assumida e não possuam nenhuma tarefa requisito com a situação
pendente ou assumida. O método vincularTarefasComUsuarioLider associa todas as
tarefas do grupo a um usuário. O método vincularTarefaComUsuario associa uma tarefa do
grupo a um usuário e o método getTarefasByGincana retorna uma lista de tarefas de grupos
associada a uma gincana. A classe UsuarioGrupoDAO possui o método
getUsuariosFromGrupo que retorna uma lista de usuários pertencentes a um grupo. O
método getGrupoFromUsuario retorna o grupo associado a um usuário. O método
getUsuariosFromGrupoSemTarefa retorna uma lista de usuários do grupo que estão sem
tarefas assumidas, excluindo o líder do grupo que possui todas as tarefas assumidas para
poder delegar para outros usuários. O método getQuantidadeUsuariosPorGrupo retorna à
quantidade de usuários que pertencem ao grupo. A classe ResultadoGincanaDAO
disponibiliza o método getListaByIdGincana que retorna a lista de resultados da gincana.
35
Figura 12 - Diagrama de classes do pacote DAO
3.2.2.3.3 Diagrama de classes do pacote DTO
A Figura 13 apresenta as classes que pertencem ao pacote DTO. Estas classes são
utilizadas para facilitar a transferência de dados entre sistemas, onde os atributos das classes
MODEL podem ser expostos de uma outra forma para aplicações externas. Todas as classes
possuem os getters e setters para os atributos correspondentes da classe MODEL. Os métodos
parse servem para converter um objeto DTO em objeto MODEL. Os métodos create fazem o
inverso, ou seja, convertem objetos MODEL em DTO.
36
Figura 13 - Diagrama de classes do pacote DTO
3.2.2.3.4 Diagrama de classes do pacote Trello API
Para a integração com a ferramenta Trello, foi adaptada a biblioteca JTrello
disponibilizada pelo usuário asommariva no serviço de hospedagem de projetos Bitbucket.
Foi adaptado para que o JTrello utilize o mesmo framework que o Furb Mobile Gincanas está
utilizando para comunicação via web services RESTful. Assim, ao invés de utilizar o Jersey,
foi alterado para que se utilize o RESTEasy. Também foi adicionado a opção de se poder criar
um quadro público. O pacote Trello API está separado em três pacotes: Trello Model,
Trello Service e Trello Client. A Figura 14 apresenta o diagrama de classes do pacote
Trello Model. A classe Board foi utilizada para representar uma gincana. A classe Listas
foi utilizada para representar as equipes e o resultado final da gincana. A classe Card foi
utilizada para representar as tarefas cumpridas por cada equipe.
37
Figura 14 - Diagrama de classes do pacote Trello Model
A Figura 15 mostra o diagrama de classes do pacote Trello Service. Todas as
classes herdam da classe TrelloApiBase, que implementa os métodos de comunicação com a
API do Trello. O método create da classe BoardService é utilizado para criar um quadro. É
importante guardar o atributo id do quadro criado já que esse será necessário na criação das
listas e cartões.
Figura 15 - Diagrama de classes do pacote Trello Service
A Figura 16 mostra o diagrama de classes do pacote Trello Client. As classes do
pacote Service interagem com a classe JTrelloClient para obter o serviço necessário que
trata cada assunto. É utilizado o método construtor que recebe o parâmetro authKey e
38
authToken, respectivamente a chave de API de desenvolvedor e o token de autorização do
cliente.
Figura 16 - Diagrama de classes do pacote Trello Client
3.2.2.3.5 Diagrama de classes do pacote Ionic API
Para a integração com a ferramenta Ionic Platform, foi utilizada a classe Ionic
disponibilizada pelo usuário slarsen no serviço de hospedagem de projetos GitHub. A Figura
17 apresenta o diagrama de classes do pacote Ionic API. O método construtor da classe
Ionic requer um token que identifica o aplicativo integrado com a ferramenta Ionic Platform.
Para enviar uma notificação push, é necessário fornecer ao método push um parâmetro
String em formato JSON com as informações de integração com o Ionic Platform, os tokens
de usuários e o texto da notificação. Mais detalhes da implementação estão na seção 3.3.2.4.
Figura 17 - Diagrama de classes do pacote Ionic API
39
3.2.2.3.6 Diagrama de classes do pacote Service
A Figura 18 mostra as classes que pertencem ao pacote Service. Estas classes
encapsulam as regras de negócio da aplicação. A classe IonicService comunica com a
classe Ionic para enviar as notificações para os participantes da gincana. A classe
FacebookService comunica com a API restfb para transformar um token de curta duração
em um de longa duração, e obter o nome e foto do Facebook do participante. A classe
TrelloService comunica com a API JTrello através da classe JTrelloCliente para
manipular os quadros, listas e cartões da gincana. A classe UtilitarioService disponibiliza
um método para salvar uma imagem no formato base64 no diretório configurado no atributo
DIRETORIO_IMAGENS.
Figura 18 - Diagrama de classes do pacote Service
3.2.2.3.7 Diagrama de classes do pacote API
A Figura 19 apresenta o diagrama de classes do pacote API. Os web services foram
construídos no estilo arquitetural REST utilizado o framework RESTEasy. A classe
Application possui a anotação @ApplicationPath("/api") que indica para o RESTEasy
qual a Uniform Resource Locator (URI) base. Uma gincana é cadastrada pelo método
cadastrarGincana da classe GincanaAPI. As tarefas são cadastradas pelo método
40
cadastrarTarefa da classe TarefaAPI. Os grupos são cadastrados no método
cadastrarGrupo da classe GrupoAPI. Após os cadastros, a gincana é ativada pelo método
ativarGincana da classe GincanaAPI. Os usuários são registrados e obtidos pelo método
obterCadastrarPorIdFacebook da classe UsuarioAPI, o qual cadastra um usuário novo
caso o idFacebook fornecido seja desconhecido, ou devolve um existente caso o idFacebook
pertença a um cadastro existente. Após o usuário selecionar uma gincana ativa obtida pelo
método listarGincanasAtivas da classe GincanaAPI, é verificado se o participante
pertence a algum grupo através do método retornarGrupoUsuario da classe GrupoAPI.
Caso esteja sem grupo, o usuário deve se vincular a um grupo da gincana através do método
vincularUsuarioGrupo da classe GrupoAPI. Nesse momento o participante assume o papel
de líder, caso ele seja o primeiro integrante do grupo, ou assume o papel de membro caso o
grupo já possua um líder.
O método obterDisponiveis da classe UsuarioAPI, é utilizado para obter a lista de
membros que estão sem tarefas. Assim o líder pode associar a tarefa a um membro através do
método associarComUsuario da classe TarefaAPI. Um membro resolve uma tarefa através
do método resolver da classe TarefaAPI. Caso a tarefa seja uma imagem, é utilizado o
método resolverImagem da mesma classe. O organizador da gincana avalia as tarefas pelo
método avaliar da classe TarefaAPI. Ao final da gincana, o método finalizar da classe
GincanaAPI é utilizado para encerrar a gincana, calcular o resultado final, publicar o
resultado no Trello e notificar todos os participantes a posição e quantidade de pontos do
grupo na gincana.
41
Figura 19 - Diagrama de classes do pacote API
3.2.3 Diagrama de atividades
A Figura 20 apresenta um diagrama de atividades onde são representados as etapas e
ações do usuário na utilização do aplicativo. Quando o aplicativo é aberto o token referente ao
dispositivo móvel é registrado junto ao Ionic Platform, possibilitando que o dispositivo móvel
seja identificado para recebimento de notificações push. Em seguida o usuário acessa o menu
de gincanas, onde deve autorizar o aplicativo a acessar informações do perfil do usuário no
Facebook. Após a autorização, o token de acesso referente ao perfil do Facebook e o token
referente ao dispositivo móvel são enviados para o registro/atualização do usuário no back-
end. Após o registro/atualização do usuário, o token do Facebook é convertido para um token
de longa duração, para estender o uso do usuário ao aplicativo sem precisar autorizar
novamente junto ao Facebook. O token gerado é enviado para o dispositivo móvel onde
substituí o token de curta duração. Após isso o usuário deve selecionar uma gincana que esteja
ativa para participar. Depois da seleção da gincana, o usuário deve selecionar um grupo. Caso
o grupo não possua um líder, o usuário assume o papel de líder, caso contrário, assume o
papel de membro. No papel de líder o usuário atribui as tarefas para outros membros do
grupo, além de ser notificado quando novos membros se juntam ao grupo, quando um
membro fica sem tarefa, quando uma tarefa é avaliada e quando a gincana chega ao fim. No
papel de membro o usuário resolve as tarefas atribuídas a ele, além de ser notificado quando
42
uma nova tarefa lhe é atribuída, quando uma tarefa sua é avaliada e quando a gincana chega
ao fim.
Figura 20 - Diagrama de atividades
3.2.4 Arquitetura e integrações do aplicativo
Para o funcionamento deste trabalho, vários serviços e ferramentas de terceiros foram
utilizados. A Figura 21 mostra a arquitetura macro criada com a integração de todos estes
serviços.
43
Figura 21 - Arquitetura do aplicativo
A camada Dispositivo Móvel representa o dispositivo móvel do usuário com o
aplicativo Furb Mobile Gincanas instalado. Este por sua vez, é um Hybrid Web Container
desenvolvido na plataforma Ionic e que pode ser executado em sistemas operacionais Android
e iOS. O aplicativo está integrado com a Rede Social Facebook para facilitar o processo de
autenticação, além de obter o nome e foto do perfil do usuário. O site de Videos YouTube é
utilizado para permitir o participante da gincana procurar e selecionar um vídeo para resposta
a uma tarefa. O aplicativo utiliza o sistema de Geolocalização Google Maps para mostrar
um mapa ao usuário demostrando sua posição atual e a posição do objetivo da tarefa.
Na camada Servidor de Aplicação encontra-se o Front-end, onde o organizador
cria, monitora e finaliza as gincanas. O Trello é utilizando como sistema de Quadro Virtual
para que o público em geral possa acompanhar o andamento da gincana. O Ionic Platform é
utilizado para o envio de Push Notifications para os sistemas de notificações da Apple
(APNS) e da Google (GCM). O Back-end é responsável por gerenciar e integrar todas as
partes do Furb Mobile Gincanas, persistindo os dados em um Banco de Dados PostgreSQL.
Essas aplicações rodam no container de aplicação WildFly e estão hospedados na plataforma
44
de serviço OpenShift. Para assimilação da comunicação entre os serviços utilizados, a Figura
22 demonstra o processo de autenticação do usuário no aplicativo.
Figura 22 - Processo de autenticação
Conforme descrito anteriormente, para iniciar o uso da aplicação é necessário que o
usuário realize a autenticação através de sua conta do Facebook. Assim como mostra o passo
(1), após a autenticação ser realizada o identificador e token são retornados ao aplicativo. No
passo (2), o aplicativo solicita o registro do usuário no serviço de push notification do Ionic
Plataform, que por sua vez encaminha para o serviço correspondente ao sistema operacional
do dispositivo do usuário. Um token será retornado e as informações de registro do usuário
são enviados ao Back-end durante o passo (3). No passo (4) o token é enviado ao Facebook
para ser transformado em um de longa duração. Após isso, o Back-end persiste as
informações do usuário e devolve o novo token para o dispositivo no passo (5).
3.3 IMPLEMENTAÇÃO
Nesta seção são apresentadas as técnicas e ferramentas utilizadas no trabalho e as
etapas seguintes para o desenvolvimento do aplicativo Furb Mobile Gincanas, do site front-
end e do servidor back-end. Para finalizar esta seção são apresentadas as telas e
funcionalidades do protótipo desenvolvido.
45
3.3.1 Técnicas e ferramentas utilizadas
O desenvolvimento deste trabalho está dividido em quatro etapas. A primeira delas é a
criação do servidor back-end na plataforma de serviços OpenShift. O servidor foi construído
na linguagem de programação Java, no ambiente de desenvolvimento Eclipse e em conjunto
com a ferramenta para automação de compilação e gerenciamento de dependências Maven.
Para as operações com banco de dados foi utilizado o framework Hibernate, que permitiu
utilizar um mapeamento objeto-relacional para aumentar a abstração na manipulação das
tabelas e atributos. Para a camada de serviço, foi utilizado o framework RESTeasy,
permitindo através de anotações no código fonte, mapear as chamadas web services para os
métodos correspondentes. Para a integração com o Facebook, foi incluída a dependência da
biblioteca restfb para Java. No que diz respeito a integração com o Trello, foi utilizada a
biblioteca JTrello disponibilizada pelo usuário asommariva no serviço de hospedagem de
projetos Bitbucket. Quanto as notificações push, foi utilizada a classe Ionic disponibilizada
pelo usuário slarsen no serviço de hospedagem de projetos GitHub. E para hospedar o back-
end e o front-end, foi utilizado o container de aplicação WildFly.
A segunda etapa é o desenvolvimento do front-end, onde o organizador pode criar,
monitorar e finalizar gincanas. Para a construção do código fonte, utilizou-se as ferramentas
padrões de desenvolvimento web HTML, CSS e Javascript, com o auxílio do ambiente de
desenvolvimento Visual Studio Code. Foram utilizados os frameworks Bower e NPM para
gerenciamento de dependências. O NPM foi utilizado para gerenciamento de módulos node,
como o Grunt, já o Bower foi utilizado para gerenciar componentes que são utilizados no
código do front-end, como o AngularJS. O Grunt foi utilizado como automatizador de tarefas
para a realizar uma verificação de possíveis falhas no código Javascript antes de gerar uma
versão de distribuição. Ainda no Grunt, também foram utilizados os plugins grunt-contrib-
connect, para disponibilizar um servidor localhost com o código fonte do front-end, e o plugin
grunt-contrib-watch, para que o servidor localhost seja atualizado cada vez que um código
fonte sofra uma modificação. A biblioteca AngularJS foi utilizada para aumentar a abstração
da manipulação do HTML, utilizando diretivas que facilitaram a integração entre os dados de
domínio e a interface com o usuário. O AngularJS também foi utilizado para realizar as
chamadas web service do tipo RESTful, utilizando o padrão de notação de objetos JSON para
enviar e receber dados do servidor.
Foram adicionados alguns módulos que não vêm com a biblioteca padrão do
AngularJS. Foi adicionado o módulo ngRoute para gerenciar as rotas da aplicação, onde foi
46
utilizado o conceito de Single Page Application, para que a percepção de mudança de páginas
seja menos impactante para o usuário. Foi adicionado também o módulo ui.bootstrap, que
fornece diretivas para facilitar a montagem das páginas de interface com o usuário. O mapa
foi renderizado com a ajuda do módulo ngMap, que forneceu diretivas para centralizar o mapa
na posição atual do usuário, além de uma diretiva para marcar a região objetivo das tarefas do
tipo geolocalização. O módulo ngSanitize foi utilizado para renderizar dinamicamente o
frame de vídeo do site YouTube, realizando um tratamento de segurança na URL do vídeo
renderizado. Para realizar a integração com o site Trello, é realizada a importação da
biblioteca client.js com o parâmetro da chave de API de desenvolvedor. A biblioteca
JQuery foi adicionada por ser um requisito da biblioteca cliente.js.
A terceira etapa é a criação do aplicativo para dispositivos móveis multiplataforma
Furb Mobile Gincanas, construído utilizando o framework Ionic na plataforma Phonegap.
Para a construção do código fonte, utilizaram-se as ferramentas padrões de desenvolvimento
web HTML, CSS e Javascript, com o auxílio do ambiente de desenvolvimento Visual Studio
Code. Assim como no front-end, foram utilizadas as bibliotecas AngularJS, NPM, Bower, e o
módulo ngMap. Para a integração com o Facebook, foi utilizada o módulo ngOpenFB, que foi
disponibilizado pelo usuário ccoenraets no serviço de hospedagem de projetos GitHub. O
tratamento das notificações push e integração com o Ionic Platform é realizado pelo módulo
ionic.service.push.
Complementando o desenvolvimento do aplicativo, foram utilizados os seguintes
plugins: um para leitura do GPS do dispositivo móvel (cordova-plugin-geolocation); um
para abrir os sites Facebook e Trello dentro do aplicativo (cordova-plugin-inappbrowser);
um para acessar a câmera do dispositivo móvel (cordova-plugin-camera); um para
apresentar uma tela durante a inicialização do aplicativo (cordova-plugin-splashscreen);
um para recebimento de notificações (phonegap-plugin-push); e o último para permitir a
navegação a domínios externos ao aplicativo (cordova-plugin-whitelist). Foi utilizado o
módulo ngCordova para acessar os plugins no formato de injeção de dependências utilizando
módulos do AngularJS.
3.3.2 Trechos de código
Nesta seção, encontram-se trechos de códigos desenvolvidos para realizar a integração
com os serviços de rede social, quadro virtual, câmera, mapas e notificações. Os principais
métodos do aplicativo são detalhados para o entendimento de comportamento de sua
execução.
47
3.3.2.1 Mapas no front-end
O Quadro 2 demostra como foram utilizadas as diretivas do módulo ngMap para
renderizar um mapa no cadastro de uma tarefa de geolocalização. As diretivas indicam para
o AngularJS que a parte de código HTML marcado será substituído pelo resultado da
execução de uma função responsável por interpretar a diretiva em questão. Na linha 1 é
declarada a diretiva ng-map, onde posteriormente o módulo ngMap irá rederizar um mapa,
com o zoom no nível 18. A linha 2 indica, através do parâmetro center, em qual coordenada
a visão do mapa será centralizada. Caso seja uma nova tarefa, o parâmetro posicao estará
undefined, e, portanto, o mapa será centralizado na posição atual do usuário, através do valor
current-position, caso contrário, o mapa será centralizado na posição previamente
cadastrada na tarefa. Na linha 3 é utilizada a diretiva shape para renderizar um círculo no
mapa, posicionando na localização atual do usuário, ou na localização previamente
cadastrada, conforme a linha 5. A linha 6 contém o parâmetro radius para indicar o tamanho
do raio do círculo, e também o parâmetro editable com o valor true para indicar que é
possível alterar a localização e raio do círculo.
Quadro 2 - Diretiva ng-map do módulo ngMap 1
2
3
4
5
6
7
8
<ng-map zoom="18"
center="{{posicao === undefined? 'current-position': posicao }}">
<shape id="circle" name="circle" centered="true"
stroke-color='#00549A' stroke-opacity="0.8" stroke-weight="2"
center="{{posicao === undefined? 'current-position': posicao }}"
radius="{{raio === undefined? 50: raio}}" editable="true">
</shape>
</ng-map>
3.3.2.2 Integração com o quadro virtual Trello
Primeiramente deve-se importar a biblioteca client.js fornecendo a chave de API de
desenvolvedor associada a conta do Furb Mobile Gincanas no Trello. No Apêndice A é
demostrado como obter a chave de desenvolvedor e importar a biblioteca. Na ativação de uma
gincana o usuário deve autorizar o Furb Mobile Gincanas com sua conta pessoal do Trello. O
Quadro 3 apresenta como é feita essa integração. Na linha 19 é realizada a chamada ao
método authorize(opts) da classe Trello. As opções de integração utilizadas indicam para
apresentar uma janela de integração em forma de popup (linha 3), que o nome da aplicação é
Furb Mobile Gincanas (linha 4), as permissões requeridas são de leitura, escrita e acesso a
dados do perfil da conta (linha 5) e que o token de autorização não possui data de expiração.
Após o usuário autorizar a integração, a classe Trello grava o token no armazenamento local,
o qual é obtido na linha 8 e enviado ao servidor junto com o id da gincana na linha 9, para
48
que se possa ativar a gincana através do id e que se possa utilizar o token para criar os
quadros e listas no Trello.
Quadro 3 - Código para integração com o Trello no Front-end 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
$scope.ativarGincana = function (gincana, indice) {
var opts = {
type: "popup",
name: "Furb Mobile Gincanas",
scope: {read: true, write: true, account: true},
expiration: "never",
success: function () {
var token = localStorage.getItem("trello_token");
gincanaAPI.ativar(gincana.id, token).then(
function onSuccess(params) {
$scope.gincanas[indice] = params.data;
});
},
error: function (params) {
alert("Não foi possível víncular com o Trelo: " +
params);
}
};
Trello.authorize(opts);
};
No Quadro 4 é demostrado como é feita a utilização da biblioteca JTrello para a
integração com o Trello no back-end. É possível verificar na linha 2 que na criação da classe
JTrelloClient são fornecidos a chave de API de desenvolvedor e o token obtido na ativação
da gincana no front-end. Nas linhas 4 e 5 são obtidos os serviços responsáveis por criar os
quadros e as listas. Nas linhas 7, 8 e 9, um quadro é criado e seu nome é definido com o título
da gincana, e sua descrição com a descrição da gincana. Na linha 11 é utilizado o serviço de
quadros para criar e obter o quadro no Trello. Nas linhas 12 e 13 a gincana recebe o id e url
correspondes ao quadro. Após isso, para cada grupo da gincana é criado uma lista no quadro
do Trello. Na linha 19 é definido o id ao qual a lista pertence, e na linha 20 é definido que o
nome da lista será o mesmo que o nome do grupo. Após criar a lista no Trello, o grupo recebe
o id correspondente a lista criada. Na linha 25 o objeto grupo é persistido no banco de dados.
A gincana é persistida no banco de dados posteriormente pela rotina que chamou o método
criarQuadroGincana.
Quadro 4 - Integração com o Trello na ativação da gincana 1
2
3
4
5
6
7
8
9
10
public Gincana criarQuadroGincana(Gincana gincana) throws Exception{
JTrelloClient client = new JTrelloClient(authKey,
gincana.getTrello_token());
BoardService boards = client.getBoards();
ListaService listas = client.getLists();
Board quadroGincana = new Board();
quadroGincana.setName(gincana.getTitulo());
quadroGincana.setDesc(gincana.getDescricao());
49
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
Board quadroCriado = boards.create(quadroGincana);
gincana.setTrello_IdBoard(quadroCriado.getId());
gincana.setTrello_UrlBoard(quadroCriado.getUrl());
List<Grupo> listaGruposFromGincana =
grupoService.getListaGruposFromGincana(gincana.getId());
for (Grupo grupo : listaGruposFromGincana) {
Lista lista = new Lista();
lista.setIdBoard(quadroCriado.getId());
lista.setName(grupo.getNome());
Lista listaCriada = listas.create(lista);
grupo.setTrello_idLista(listaCriada.getId());
grupoDAO.create(grupo);
}
return gincana;
}
3.3.2.3 Integração com a rede social Facebook
Para utilizar o login pelo Facebook em um aplicativo, é necessário possuir uma conta
na plataforma Facebook Developers e configurar um projeto para o aplicativo que vai utilizar
a funcionalidade do login. No Apêndice B é apresentado como foi feita a configuração do
aplicativo Furb Mobile Gincanas e como o módulo ngOpenFb foi configurado. Na linha 1 do
Quadro 5 é feito a chamada ao método getLoginStatus da classe ngFB para verificar se o
aplicativo está autorizado, não está autorizado ou se o usuário não está conectado a sua conta
do Facebook. Nas linhas 3 e 4, caso o usuário esteja conectado e o aplicativo esteja
autorizado, a tela de gincanas é aberta. Caso o aplicativo não esteja autorizado, o usuário é
informado que apenas poderá utilizar a funcionalidade de gincanas caso entre com sua conta
do Facebook. Caso o usuário não esteja conectado na sua conta do Facebook, na linha 12 a
função login da classe ngFB é chamada, passando como parâmetro os tipos de dados que o
aplicativo deseja utilizar do perfil acessado, como por exemplo seu nome e foto de perfil.
Quadro 5 - Integração com a rede social Facebook 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
ngFB.getLoginStatus().then(
function(response) {
if (response.status === 'connected') {
$state.go('gincanas');
} else if (response.status === 'not_authorized') {
// está logado no Facebook,
// mas não autorizou o aplicativo
alert('Para utilizar Gincanas, você deve utilizar sua conta do
Facebook');
} else {
// não está logado no Facebook
ngFB.login({scope : 'public_profile'}).then(
function(response) {
if (response.status === 'connected') {
localStorage.setItem('tokenfacebook',
response.authResponse.accessToken);
50
17
18
19
20
21
22
23
27
$state.go('gincanas');
} else {
alert('É necessário entrar com sua conta do Facebook');
}
});
}
});
3.3.2.4 Integração com o Ionic Platform
O código fonte apresentado no Quadro 6, realiza a integração com o Ionic Platform
para integrar as notificações push enviadas ao dispositivo. Para utilizar o Ionic Platform é
necessário fornecer a chave de API configurada para o aplicativo. A execução da rotina
demostrada no Quadro 6 acontece na inicialização do aplicativo, onde é possível verificar que
não há tratamento específico caso o aparelho possua o sistema operacional Android ou iOS.
Na linha 2 é definido que quando o aplicativo receber uma notificação, uma janela será aberta
informado o título e texto da mensagem. A função register na linha 9 executa o plugin
phonegap-plugin-push que obtém um token de acordo com o sistema operacional onde o
aplicativo está sendo executado. Na linha 11 o token é registrado no Ionic Platform para
identificar o aparelho integrado com o servidor de notificações.
Quadro 6 - Integração com o Ionic Platform 1
2
3
4
5
6
7
8
9
10
11
12
var push = new Ionic.Push({
"onNotification" : function(notification) {
$ionicPopup.alert({
title : notification.title,
template : notification.text
});
}
});
push.register(function(token) {
// persiste o token no Ionic Platform
push.saveToken(token);
});
O back-end envia as notificações para os usuários identificando-os através do token
enviado no registro do usuário. O Quadro 7 mostra o código que envia as informações do
usuário para o back-end. Na linha 2 é feita uma chamada a API do Facebook para obter o id
do usuário. Na linha 18 é realizada uma chamada post ao método
obtercadastrarporidfacebook do web sercice usuário, passando como parâmetro um
objeto usuario com idFacebook, o token de permissão de acesso do aplicativo a conta do
usuário no Facebook e o token registrado no Ionic Platform.
Quadro 7 - Enviando dados do usuário para o back-end 1
2
3
var _getUsuario = function() {
return ngFB.api({
path : '/me',
51
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
params : {
fields : 'id'
}
}).then(
function(user) {
var fbAccessToken =
localStorage.getItem("fbAccessToken");
var ionicPushToken = JSON.parse(localStorage
.getItem("ionic_io_push_token")).token
var usuario = {
idFacebook : user.id,
facebookToken : fbAccessToken,
ionicPushToken : ionicPushToken
};
return $http.post(config.baseUrl
+ "usuario/obtercadastrarporidfacebook/",
usuario);
}, function(error) {
alert('Facebook error: ' + error.message);
});
};
O código e exemplo de uso de envio de notificações aos usuários é apresentado no
Quadro 8. Uma notificação válida do Ionic Platform exige que sejam informados os tokens de
identificação dos dispositivos móveis, o nome de um profile configurado para o aplicativo e o
título e descrição da notificação, além da chave de API do desenvolvedor fornecida na
instanciação da classe Ionic na linha 18. Na linha 1, é apresentada a função que notifica o
líder do grupo e o membro que resolveu a tarefa, informando que a tarefa foi avaliada e qual a
nota recebida. Na linha 6 é realizada a chamada à função privada Notificar, passando como
parâmetro os tokens dos usuários e o título e descrição da notificação.
Quadro 8 - Enviando notificações no back-end 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
public void Notificar_Avaliar(String tokenLider, String tokenUsuario,
String tituloTarefa, int notaTarefa) {
ArrayList<String> tokens = new ArrayList<>();
tokens.add(tokenLider);
tokens.add(tokenUsuario);
Notificar(tokens, "Tarefa Avaliada", tituloTarefa + " foi
avaliada e recebeu a nota " + notaTarefa);
}
private void Notificar(ArrayList<String> tokens, String titulo, String
descricao) {
Notificacao notificacao = new Notificacao();
notificacao.getTokens().addAll(tokens);
notificacao.setProfile(IONIC_API_PROFILE);
notificacao.getNotification().put("title", titulo);
notificacao.getNotification().put("message", descricao);
Ionic ionic = new Ionic(IONIC_API_TOKEN);
ionic.push(new Gson().toJson(notificacao));
}
52
3.3.2.5 Integração com o site de compartilhamento de vídeos YouTube
O YouTube é utilizado nas tarefas do tipo vídeo, onde o usuário realiza uma pesquisa
utilizando palavras chave para selecionar um vídeo que será utilizado como resposta para a
tarefa. No Quadro 9 é apresentado o código fonte que realiza uma pesquisa de vídeos
utilizando um termo de pesquisa informado pelo usuário. Para utilizar a API de pesquisa do
YouTube, é necessário configurar o serviço YouTube Data API para o aplicativo, obtendo
uma chave de API utilizada como parâmetro no código da integração. Na linha 1 do Quadro
9, é definido o objeto de parâmetros para integração, onde são definidos a chave de API, o
parâmetro type indicando que a pesquisa retornará apenas vídeos, excluindo canais e listas de
reprodução, o número máximo de resultados, quais informações dos vídeos serão retornadas e
a ordem em que os vídeos serão retornados, onde foi utilizado o critério de relevância
(relevance). Na linha 16 é feita a associação do termo pesquisado pelo usuário ao parâmetro
q. Na linha 18 é realizada uma chamada HTTP através do método GET a API do YouTube,
passando como parâmetro a variável youtubeParams. Nas linhas 20 e 21 são armazenados os
tokens correspondentes a próxima página e página anterior da pesquisa. Quando o usuário
clica no botão Próxima Página ou Página Anterior da Figura 32, estes tokens são
utilizados para retornar a página específica do conjunto de resultados. Na linha 22 do Quadro
9, é indicado que para cada vídeo na lista de vídeos obtida (response.items), será executada
de forma assíncrona a função implementada na linha 23, que implementa o código onde
adiciona o vídeo na lista de vídeos renderizados na tela. Na linha 24 é utilizada a função all
do serviço $q do AngularJS, para fazer com que a janela de espera de carregamento dos
vídeos seja escondida apenas depois que todos os vídeos sejam renderizados.
Quadro 9 - Realizando uma busca de vídeos no YouTube 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
$scope.youtubeParams = {
key: 'AIzaSyAueU10e1r89L0AVh8dhVfXXXXXXXXXXXX',
type: 'video',
maxResults: '5',
part: 'id,snippet',
q: '',
order: 'relevance'
}
$scope.getVideos = function (query) {
$ionicLoading.show({
template: '<p>Carregando ' + query + '...</p><ion-
spinner></ion-spinner>'
});
$scope.youtubeParams.q = query;
$scope.videos = [];
$http.get('https://www.googleapis.com/youtube/v3/search', { params:
$scope.youtubeParams }).success(function (response) {
53
20
21
22
23
24
25
26
27
28
29
$scope.nextPageToken = response.nextPageToken;
$scope.prevPageToken = response.prevPageToken;
angular.forEach(response.items, function (child) {
$scope.videos.push(child);
});
$q.all($scope.videos).then(function () {
$ionicLoading.hide();
});
});
};
3.3.2.6 Acessando a câmera do dispositivo móvel
Nas tarefas do tipo imagem, o usuário deve utilizar como resposta uma foto tirada com
a câmera do seu dispositivo móvel. Foi utilizado o plugin cordova-plugin-camera com a
extensão ngCordova para acessar o recurso da câmera do dispositivo. O Quadro 10 apresenta
o código fonte utilizado, onde na linha 2 é definido o objeto options com as opções
disponíveis no plugin. A qualidade da imagem foi definida com o valor 30, em uma escala de
0 a 100, para que a imagem ocupe uma quantidade de dados menor, visando agilizar a
transferência da imagem para o servidor back-end, principalmente quando o usuário estiver
utilizando uma conexão de dados lenta. Na linha 9, o método getPicture da classe
$cordovaCamera, abre o aplicativo de câmera nativo do sistema operacional do dispositivo
móvel. Após o usuário tirar a foto, a imagem é passada como parâmetro para o método na
linha 10 no formato base64, onde posteriormente será enviada ao servidor back-end.
Quadro 10- Utilizando a câmera do dispositivo móvel 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
$scope.tirarFoto = function () {
var options = {
quality: 30,
destinationType: Camera.DestinationType.DATA_URL,
sourceType: Camera.PictureSourceType.CAMERA,
encodingType: Camera.EncodingType.JPEG
}
$cordovaCamera.getPicture(options).then(
function (imageData) {
$scope.imageData = imageData;
$scope.srcImagem = "data:image/jpeg;base64," + imageData;
}
);
}
3.3.2.7 Integração com os mapas do Google Maps no aplicativo
A integração do aplicativo com o Google Maps foi realiza com auxílio do plugin
cordova-plugin-geolocation e, assim como no front-ent, foi utilizado o módulo ngMap. O
código apresentado no Quadro 11, é utilizado na tela de resolução de tarefas de
geolocalização para adicionar um marcador representando a posição atual do usuário, além
54
de centralizar o mapa no marcador e adicionar um círculo representando as coordenadas do
objetivo da tarefa. Para utilizar a API de mapas do Google no aplicativo, é necessário
configurar o serviço Google Maps Javascript API, obtendo uma chave de API utilizada para
importar a biblioteca de integração. Quando o usuário aciona o botão para mostrar o mapa, o
método mostrarMapa é acionado, dando início a execução da função representada pela linha
1. Primeiramente é executada na linha 2 a função do ngMap para buscar a referência do objeto
mapa declarado no elemento HTML da página. Na linha 4 o plugin de geolocalização é
acionado para obter a posição atual do usuário.
Na linha 4 do Quadro 11, a função do plugin para recuperar a localização é acionada,
com a função onMapErrorFirstTime como parâmetro caso o plugin falhe na tentativa de
obter a localização. Dentro da função onMapErrorFirstTime na linha 29, o código para obter
a localização é executado novamente, mas passando a função de tratamento de erros geral
onMapError como parâmetro caso o plugin falhe na tentativa de obter a localização. Essa
estratégia foi implementada pois o comportamento do plugin foi impactando em dispositivos
Android, devido a uma atualização nas políticas de segurança da API de geolocalização do
Google, onde não é mais possível obter dados de localização do dispositivo do usuário, sob
domínios inseguros, exigindo que a aplicação esteja em um contexto seguro como o HTTPS
(HyperText Transfer Protocol Secure) (KINLAN, 2016). Como o plugin prioriza a utilização
do componente de localização utilizado no browser nativo para acesso ao GPS, a função
retorna com erro, informando que não conseguiu obter a posição do usuário. Isto acontece,
pois, o aplicativo está sendo executado em um Hybrid Web Container, que não utiliza o
protocolo HTTPS. Nas próximas tentativas o plugin dá prioridade para a utilização do GPS de
forma nativa integrado com o sistema operacional do aparelho, retornando corretamente a
posição do usuário.
Ainda no Quadro 11, na linha 12 a função onMostrarMapaSuccess implementa o
tratamento para centralizar o mapa na posição atual do usuário, desenhando um marcador na
linha 18 indicando visualmente sua posição. Na linha 22, a função watchPosition é
chamada, indicando que quando o usuário se movimentar, a função onMapWatchSuccess será
executada. Esta função, por sua vez, atualiza o marcador com a nova posição do usuário.
Quadro 11 - Integração com o Google Maps no aplicativo 1
2
3
4
5
6
7
$scope.mostrarMapa = function() {
NgMap.getMap("mapa").then(function(map) {
$scope.mapa = map;
navigator.geolocation.getCurrentPosition(onMostrarMapaSuccess,
onMapErrorFirstTime, {
maximumAge: 3000,
timeout: 5000,
55
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
enableHighAccuracy: true
});
});
};
var onMostrarMapaSuccess = function(position) {
$scope.posicaoAtual.latitude = position.coords.latitude;
$scope.posicaoAtual.longitude = position.coords.longitude;
$scope.mapa.setCenter(new
google.maps.LatLngposition.coords.latitude,
position.coords.longitude));
$scope.mapa.markers[0].setPosition(new
google.maps.LatLng(position.coords.latitude,
position.coords.longitude));
$scope.mapa.setZoom(13);
navigator.geolocation.watchPosition(onMapWatchSuccess, onMapError,
{
enableHighAccuracy: true
});
};
function onMapErrorFirstTime(error) {
navigator.geolocation.getCurrentPosition(onMostrarMapaSuccess,
onMapError, {
maximumAge: 3000,
timeout: 20000,
enableHighAccuracy: true
});
}
3.3.3 Operacionalidade da implementação
Nesta seção é apresentada a operacionalidade da aplicação desenvolvida, através da
interface gráfica disponível para o usuário. As imagens abaixo foram obtidas utilizando o
navegador Google Chrome na versão 53.0.2774.2 canary (64-bit), um dispositivo mobile Sony
XPERIA modelo C2104 com Android 5.1.1, um dispositivo mobile Samsung S4 modelo
i9505 com Android 6.0 e um iPad Mini com iOS 9.3.2.
3.3.3.1 Cadastro de gincanas
Primeiramente o organizador deve criar uma gincana acessando o site do Furb Mobile
Gincanas. A Figura 23 apresenta a tela para cadastrar a gincana, onde deve ser informado um
título e uma descrição.
56
Figura 23 - Tela de cadastro de gincana
Após o cadastro da gincana, deve ser feito o cadastro das tarefas. A Figura 24 exibe a
tela de cadastro de tarefa, onde deve ser informado o título, descrição e tipo da tarefa. Para as
tarefas de geolocalização, deve-se configurar a área de objetivo da tarefa, mudando a
posição do círculo e aumentado ou diminuindo seu raio.
57
Figura 24 – Tela de cadastro de tarefa
É possível definir dependências para as tarefas, onde uma tarefa só estará disponível
quando as tarefas requisitos forem resolvidas. Na Figura 25 é mostrado a tela para realizar
essa operação, onde o usuário seleciona quais tarefas da lista de tarefas serão utilizadas como
dependências.
58
Figura 25 - Tela para vincular tarefas requisitos
Os grupos são cadastrados pelo organizador da gincana. Na Figura 26 é apresentado a
tela de cadastro de grupos, onde deve ser informado o nome do grupo.
Figura 26 - Tela de cadastro de grupo
Para ativar a gincana, o usuário deve autorizar o Furb Mobile Gincanas acessar a sua
conta do Trello. Na Figura 27, ao clicar no botão Ativar na gincana, é solicitado ao usuário
que autorize o Furb Mobile Gincanas, informado quais permissões estão sendo solicitadas.
59
Figura 27 - Autorizar Trello
Após a autorização, um quadro público da gincana é criado no Trello, onde é criada
uma lista para cada grupo. A Figura 28 mostra o quadro criado, onde constam as informações
da gincana e seus grupos. O site está sendo acessado sem estar conectado a uma conta do
Trello, assim, como o quadro está público, qualquer pessoa pode acompanhar o andamento da
gincana.
60
Figura 28 - Quadro criado no Trello
A Figura 29 mostra a tela inicial do aplicativo. Após o usuário acessar o menu
Gincanas, ele deve se autentificar através da rede social Facebook. Após realizar a
autenticação, é apresentada a tela com a lista de gincanas ativas disponíveis.
Figura 29 - Tela inicial do aplicativo
Ao clicar na gincana, o usuário deve, como ilustrado na Figura 30, selecionar um
grupo para participar. Após selecionar um grupo, caso o usuário seja o primeiro integrante do
grupo, ele assume o papel de líder e uma lista de tarefas é apresentada a ele. É possível
61
verificar qual o placar atual da gincana através do botão Placar, onde o quadro da gincana no
Trello é aberto dentro do aplicativo.
Figura 30 - Entrando em um grupo e lista de tarefas
A Figura 31 apresenta a situação onde um novo usuário se junta ao grupo. O líder
recebe uma notificação push informando sobre o novo membro e, portanto, pode delegar uma
tarefa para o novo membro. Após a tarefa ser associada com o membro, este é notificado
através de uma notificação push.
Figura 31 - Novo membro e delegação de tarefas
A Figura 32 apresenta a tela de resolução de tarefas de vídeo, onde o membro deve
utilizar termos de pesquisa para procurar um vídeo no YouTube. Os botões Página Anterior
e Próxima Página mudam a página dos resultados de acordo com a opção selecionada.
62
Figura 32 - Resolvendo tarefa de vídeo
Na tela de resolução de tarefa de geolocalização, apresentada na Figura 33, o
usuário deve permitir o aplicativo acessar sua localização. Existem os botões Posição,
Objetivo e Confirmar. O botão Posição centraliza o mapa na localização atual do usuário,
enquanto que o botão Objetivo centraliza o mapa no centro do objetivo da tarefa. O botão
Confirmar serve para o usuário confirmar sua resposta. É feita uma validação para verificar
se o usuário realmente está dentro dos limites da localização da tarefa. Como ilustrado na
Figura 33, caso o usuário esteja fora da cerca virtual, é apresentada uma mensagem na tela.
Figura 33 - Resolvendo tarefa de geolocalização
Na tela de resolução de tarefa de imagem, apresentada na Figura 34, o usuário deve
permitir o aplicativo acessar sua câmera. Após isso, o usuário deve tirar a foto que será
63
utilizada como resposta. A tela apresenta a foto tirada antes de enviá-la ao servidor back-end,
permitindo o usuário tirar uma outra foto caso não tenha gostado da atual.
Figura 34 - Resolvendo tarefa de imagem
O organizador da gincana dispõe da tela apresentada na Figura 35 para monitorar o
andamento da gincana. Também nesta tela é possível finalizar a gincana através do botão
Finalizar Gincana, onde o cálculo da pontuação será executado e o resultado será
publicado no Trello, além de avisar por notificação push todos os usuários participantes da
gincana sobre o resultado da mesma.
64
Figura 35 - Monitoramento da gincana
Na Figura 36 é apresentada a tela de avaliação de tarefas do tipo imagem. O
organizador deve avaliar a tarefa dando uma nota de 0 a 10 estrelas. Após a avaliação, um
cartão com a nota da tarefa é adicionado na lista no Trello correspondente ao grupo.
Figura 36 - Avaliação das tarefas de imagem
65
A Figura 37 apresenta a tela para avaliação das tarefas do tipo vídeo. O vídeo enviado
pelo usuário é apresentado na tela para que o organizador possa realizar a sua avaliação.
Figura 37 - Avaliação das tarefas de vídeo
A Figura 38 apresenta a tela para avaliação das tarefas do tipo geolocalização. As
coordenadas do objetivo da tarefa e a posição do usuário são renderizados na tela.
Figura 38 - Avaliação das tarefas de geolocalização
66
A Figura 39 apresenta o resultado final da gincana no Trello, onde é criada uma lista,
com o título RESULTADO, contendo os cartões equivalentes aos grupos que participaram da
gincana. Cada cartão informa a posição do grupo, o total de pontos e a quantidade de
integrantes.
Figura 39 - Resultado final da gincana
3.4 RESULTADOS E DISCUSSÕES
O principal objetivo deste trabalho era disponibilizar um protótipo de um sistema de
gincanas voltado para o evento Interação FURB utilizando o framework multiplataforma
Phonegap. Assim, criou-se uma ferramenta integrada a redes sociais e voltada para
dispositivos móveis, buscando aprimorar as experiências dos visitantes do evento Interação
FURB, auxiliando-os a explorar e interagir com as oficinas, e atividades realizadas através de
gincanas virtuais. Este aplicativo também está integrado com o site de compartilhamento de
vídeos YouTube, aos mapas do Google Maps e suporta o recebimento de notificações
enviadas pelo serviço de notificações correspondente ao sistema operacional do dispositivo do
usuário (APNS e GCM). Além disso, disponibiliza no Trello um quadro público onde
qualquer pessoa possa acompanhar o andamento da gincana.
A proposta de utilizar essas tecnologias em uma gincana se mostrou possível, pois os
participantes já estão acostumados a várias das tecnologias utilizadas. Na cidade de Blumenau
ocorre desde o ano de 1993 a Gincana Cidade de Blumenau, onde existem várias tarefas
envolvendo charadas, localização de pessoas e objetos, entre outros (DAY, 2011). A proposta
desse trabalho foi validada com a participante da Gincana Cidade de Blumenau Paola
Adriano, que participa a um ano da mesma. Segundo Adriano (2016), sobre a ideia de usar
essas tecnologias na gincana, “acredito que essa seja a ideia mesmo, claro que não utilizamos
tanta tecnologia como login por Facebook e o Trello, mas são tecnologias super acessíveis
que seriam ótimas serem implantadas”.
67
No início do desenvolvimento deste trabalho tentou-se estender o trabalho de Campos
(2015), adicionando as regras de negócio para as gincanas. Não foi possível realizar essa
tarefa pois o protótipo desenvolvido no trabalho de Campos (2015) não estava funcionando
para a plataforma Android. Em sua monografia, ele comenta que os testes para a plataforma
iOS ocorreram com sucesso, porém, o mesmo não ocorreu para a plataforma Android. Em sua
conclusão, ele descreve:
Na tentativa de gerar o arquivo APK (extensão dos aplicativos Android), ocorreu um
erro ocasionado pelo conflito entre as dependências utilizadas pelos plug-ins do
PhoneGap, desta forma, impossibilitando a instalação do aplicativo nos dispositivos
com o sistema Android e sendo necessário testar outras alternativas de plug-ins
(CAMPOS, 2015, p. 47).
Tentou-se corrigir o erro comentado por Campos (2015), porém, não foi possível
corrigir o erro. Além disso, foi verificado em fóruns que esse conflito de dependências está
sem solução desde 2014, indicando que a própria comunidade de desenvolvedores prioriza a
utilização de outros plugins para trabalhar com o Phonegap. Devido a esta situação, optou-se
por iniciar o desenvolvimento de outro aplicativo, utilizando o framework Ionic, e com foco
em ser uma plataforma onde várias outras funcionalidades além de gincanas possam ser
implementadas.
A utilização do framework Ionic para a criação da interface gráfica aprimorou a
experiência do usuário ao proporcionar o visual de um aplicativo nativo, diminuindo a
sensação de estar navegando em uma página web. Os componentes de interface do Ionic são
diretivas do AngularJS, facilitando a integração entre os dados de domínio e a interface com o
usuário. Durante o desenvolvimento, foi possível realizar os testes do aplicativo diretamente
no browser do computador, agilizando o processo de testes, pois o processo de deploy do
aplicativo para um dispositivo móvel é demorado. Não foram utilizados emuladores para os
testes do aplicativo. A plataforma Ionic Platform se mostrou bastante estável para envio de
notificações através dos serviços APNS e GCM. Durante o desenvolvimento deste trabalho a
plataforma passou da versão Alfa para a versão Beta, obrigando que alguns métodos
utilizados para a integração fossem ajustados.
Um dos objetivos específicos deste trabalho era integrar os grupos do Facebook para
estender a comunicação entre os membros dos grupos da gincana. Porém, na atualização para
a versão 2.6 da API do Facebook ocorrida na metade de abril de 2016, a API de grupos foi
descontinuada e passaria a não aceitar mais novas requisições de integração a partir de maio
de 2016 (FACEBOOK FOR DEVELOPERS, 2016). Para continuar dando suporte a grupos
na gincana, a integração com os grupos do Facebook no trabalho foi reformulada, fazendo
68
com que o controle de grupos e relacionamento entre os membros ficasse no domínio do
protótipo desenvolvido.
Um outro objetivo também foi impactado devido a uma atualização na API de
terceiros. A integração com o Google Maps para dispositivos Android foi impactada devido a
uma atualização, na metade de abril de 2016, nas políticas de segurança da API de
geolocalização do Google, onde não é mais possível obter dados de localização do dispositivo
do usuário, sob domínios inseguros, exigindo que a aplicação esteja em um contexto seguro
como o HTTPS (KINLAN, 2016). Como o plugin oficial do Cordova para geolocalização
prioriza a utilização do componente de localização utilizado no browser nativo para acesso ao
GPS, a rotina que retorna à posição do usuário retorna com erro, informando que não
consegue obter a posição do usuário devido a questões de segurança. Isto acontece, pois, o
aplicativo está sendo executado em um Hybrid Web Container, que não utiliza o protocolo
HTTPS. A solução foi implementar uma estratégia onde o plugin, após não conseguir obter a
localização do usuário, acessa diretamente o recurso GPS do dispositivo móvel, obtendo
assim sua localização mediante aprovação do usuário. Até o final da implementação deste
trabalho, não foi lançanda uma atualização para o plugin utilizado.
Um outro problema encontrado foi a renderização dos mapas nas páginas HTML, onde
o mesmo não era renderizado em páginas que possuem o comportamento modal. As páginas
modais são aquelas páginas que são abertas normalmente no meio da tela, escurecendo o resto
do site, que quando se clica fora da janela, ela desaparece. Para isso foi implementado para
que ao abrir essas janelas, os mapas não fossem renderizados, e foi colocado um botão
Mostrar Mapa adicionando o mapa no HTML após a janela já estar renderizada na tela.
Uma outra premissa era que os serviços construídos para o organizador criar as
gincanas estivessem disponíveis online. Para isso, optou-se por criar uma instância de
aplicação na plataforma OpenShift, utilizando o WildFly como container da aplicação. Uma
vantagem dessa plataforma é que ela permite hospedar até três instâncias gratuitas de
aplicações de pequeno porte, além de uma documentação bem abrangente dos serviços
oferecidos. Durante os testes do aplicativo, verificou-se que o OpenShift parava o serviço
várias vezes ao dia, principalmente quando ficava um período grande ocioso. Isso atrapalhou
um pouco o desenvolvimento, pois muitas vezes era necessário esperar alguns minutos até
que o serviço ficasse online novamente.
69
3.4.1 Quadro de comparação entre os trabalhos
No Quadro 12, estão sendo comparados os trabalhos correlatos apresentados na seção
2.4, ao trabalho desenvolvido. Os trabalhos que possuírem as características descritas na
primeira coluna, estão marcados com “X”.
Quadro 12 - Quadro comparativo entre os trabalhos correlatos
Kestring
(2014)
Rocha (2015) Niantic Labs
(2012)
Furb Mobile Gincanas
geolocalização de usuários X X X X
interface gráfica com mapa X X X X
mundo virtual X X
compartilhamento de localização X
envio de notificações X X X X
integração com FURB X X X
login com Facebook X
quadro virtual com Trello X
uso de Beacons X
grupos X X
integração com YouTube X
plataforma suportada Android Híbrido Híbrido Híbrido
framework mobile Nativo Phonegap LibGDX Phonegap
Através das informações demonstradas no Quadro 12, percebe-se todos trabalham
com geolocalização, apresentando em um mapa a localização do usuário. Também se percebe
que todos utilizam as notificações push de forma a aumentar o engajamento dos usuários na
utilização do aplicativo. O jogo de Niantic Labs (2012) e o Furb Mobile Gincanas trabalham
com o conceito de mundo virtual, onde o usuário interage com elementos do mundo real
influenciando acontecimentos no mundo virtual, além de permitirem a participação de grupos
para aumentar a integração entre os usuários. Percebe-se que trabalho de Kestring (2014),
Rocha (2015) e o Furb Mobile Gincanas estão integrados com a FURB, e que o trabalho de
Kestring (2014) permite o compartilhamento de localização entre os usuários. O trabalho de
Rocha (2015) faz o uso de Beacons para otimizar a localização do usuário, permitindo que,
por exemplo, sejam mapeados os andares e salas de um prédio, permitindo oferecer mais
informações sobre a localização do usuário. Verifica-se que o aplicativo Furb Mobile
Gincanas utiliza o quadro virtual do Trello para disponibilizar um meio público de acesso aos
acontecimentos da Gincana, além de integrar com o YouTube e o Facebook, buscando utilizar
tecnologias muito comuns hoje na geração Z. Apenas trabalho de Kestring (2014) foi
70
desenvolvido está disponível exclusivamente para a plataforma Android, já que foi utilizado o
Android nativo como framework de desenvolvimento. Já o jogo de Niantic Labs (2012), o
trabalho de Rocha (2015) e o Furb Mobile Gincanas estão disponíveis para as plataformas
Android e iOS. O trabalho de Rocha (2015) e o Furb Mobile Gincanas foram desenvolvidos
utilizando o framework Phonegap, que trabalha com tecnologias web, já o jogo de Niantic
Labs (2012) utiliza o framework libGDX, que trabalha com a linguagem de programação
Java. O libGDX utiliza o framework RoboVM para portar o código Java entre as diversas
plataformas, mas, segundo Müller (2016), a plataforma está sendo descontinuada e não vai
mais receber atualizações.
71
4 CONCLUSÕES
Este trabalho apresentou o desenvolvimento de um aplicativo voltado para a aplicação
de gincanas em eventos, como o Interação FURB, utilizando o framework Phonegap para
disponibilizar o aplicativo em múltiplas plataformas. É possível aplicar tarefas do tipo
pergunta, imagem, vídeo e geolocalização, além de definir dependências entre as tarefas,
permitindo que as mesmas sejam encadeadas no estilo caça ao tesouro. Os participantes da
gincana devem se organizar em grupos pré-definidos pelo organizador da gincana. Os líderes
dos grupos devem distribuir as tarefas para seus colegas de grupo, avaliando qual tarefa se
encaixa com o perfil de cada usuário. O aplicativo permite que o participante da gincana se
autentique utilizando sua conta da rede social Facebook. Os usuários podem utilizar os
recursos de câmera e GPS para responder as tarefas, respectivamente, de imagem e
geolocalização. O aplicativo permite a pesquisa de vídeos do site de compartilhamento de
vídeos YouTube para responder as tarefas do tipo vídeo. Os usuários são notificados sobre
acontecimentos na gincana, através de notificações push. A gincana pode ser acompanhada
em um placar público, através do site de quadro virtual e organizador de tarefas Trello.
Inicialmente tentou-se estender o trabalho de Campos (2015), porém o mesmo se
encontra com erro na hora de gerar a APK para dispositivos Android, por motivo de conflito
entre dependências dos plugins utilizados. Tentou-se ajustar esse erro, porém não foi obtido
sucesso na sua correção. Ainda foi verificado que esse problema acontece desde 2014, sendo
que os plugins em conflito não receberam atualizações para correção do erro. Assim, foi
optado pela criação de um novo protótipo, voltado para a aplicação de gincanas, integrado
com várias plataformas de terceiros.
O objetivo de criar uma aplicação voltada a gincanas, utilizando diversas integrações
com serviços terceiros foi cumprido. Também foi cumprido o objeto de desenvolver o
aplicativo utilizando um framework multiplataforma. Os plugins do Phonegap utilizados no
aplicativo foram compatíveis e possibilitaram a distribuição para as plataformas Android e
iOS.
Ocorreram atualizações nas APIs de integração com o Ionic Platform, Facebook e
Google Maps, sendo que os maiores impactos foram a descontinuação da API de grupos do
Facebook, impossibilitando a utilização dos grupos do Facebook no aplicativo, e a atualização
nas políticas de segurança do Google Maps API, fazendo com que o comportamento do
plugin oficial de geolocalização do Phonegap falhe mais vezes em dispositivos Android para
obter a localização do usuário. Foi verificado que a comunidade de desenvolvedores está
72
utilizando uma customização da versão antiga do plugin, onde o erro não ocorre, enquanto
não é lançado uma atualização oficial para correção deste erro.
A utilização da plataforma OpenShift para a hospedagem do site e do servidor de
gincanas se mostrou positiva, pois fornece um plano grátis para hospedagem de aplicações de
pequeno porte. Um ponto negativo foi que a plataforma se mostrou um pouco instável durante
o desenvolvimento deste trabalho, ficando off-line várias vezes, mesmo quando a aplicação
não estava ociosa.
Por fim, a utilização do Ionic Platform para o envio de notificações push se mostrou
produtiva, onde não existe nenhum tratamento específico para a plataforma onde o aplicativo
está sendo executado para o recebimento das notificações. Durante o desenvolvimento da
aplicação, foi percebido que algumas notificações não eram enviadas aos dispositivos, isso
pode acontecer pois a ferramenta se encontra na fase Beta de lançamento no presente atual.
4.1 EXTENSÕES
Sugerem-se as seguintes extensões para trabalhos futuros:
a) realizar a integração dos equipamentos Beacons para aprimorar a geolocalização
em espaços interno;
b) criar uma forma de diferenciar usuários que estão logados e deslogados, para que o
líder consiga distinguir se o um membro está logado na aplicação;
c) utilizar o framework Auth0 para unificar a implementação de autenticação de
usuário no site e no aplicativo;
d) implementar o compartilhamento de localizações proposto por Campos (2015)
entre os membros do grupo;
e) melhorar a integração com o Trello, procurando disponibilizar mais informações
sobre o andamento da gincana;
f) permitir a busca de gincanas disponíveis por proximidade;
g) implementar a integração com a API do Telegram para disponibilizar um chat
entre os integrantes dos grupos, proporcionando uma maior integração entre os
membros;
h) implementar aspectos de Gamificação para aumentar a motivação e o
engajamento dos usuários;
i) aumentar a integação com as redes social, possibilitando o usuário compartilhar as
fotos, vídeos e check-ins em seus perfis do Facebook, Twitter, Instagram, entre
outros.
73
REFERÊNCIAS
ADRIANO, Paola Avaliação Gincana. [mensagem pessoal]. Mensagem recebida por
<[email protected]> em 22 jun. 2016.
ANDROID DEVELOPERS. Google. Integrate Google Cloud Messaging. [S. I.], 2016.
Disponível em: <https://developer.android.com/distribute/engage/gcm.html>. Acesso em: 22
jun. 2016.
APACHE CORDOVA. Cordova Plugins. [S.I.], 2013. Disponível em:
<http://cordova.apache.org/plugins/>. Acesso em: 25 out. 2015.
CAMPOS, Gabriel F. B. Aplicação ios para visualização de pontos de interesse e rotas em
espaços internos. 2015. 26f. Proposta do Trabalho de Conclusão de Curso (Bacharelado em
Ciências da Computação – Centro de Ciências Exatas e Naturais, Universidade Regional de
Blumenau, Blumenau.
CERETTA, S. B.; FROEMMING, L. M. Geração Z: Compreendendo os hábitos de consumo
da geração emergente. Raunp, Natal, Ano 3, n. 2, p 15-24, abr./set. 2011. Disponível em:
<http://portal.unp.br/arquivos/pdf/institucional/edunp/raunp_a3n2.pdf>. Acesso em 20 set.
2015.
DAY, Adalberto Histórico Gincana Cidade de Blumenau. Blumenau, 2011. Disponível em:
< http://adalbertoday.blogspot.com.br/2011/08/historico-gincana-cidade-de-blumenau.html>.
Acesso em: 22 jun. 2016.
DESAFIOS DA EDUCAÇÃO. Como as universidades vão se adaptar à Geração Z e
garantir seu próprio futuro. [S.I], 2014. Disponível em:
<http://www.desafiosdaeducacao.com.br/como-universidades-vao-se-adaptar-a-geracao-
garantir-seu-proprio-futuro/>. Acesso em: 15 nov. 2015.
ERICSSON. Ericsson analisa a geração conectada no Brasil. [S.I.], 2013. Disponível em: <
http://www.ericsson.com/br/news/2013-02-19-connected-po_254740124_c>. Acesso em: 01
nov. 2015.
FACEBOOK FOR DEVELOPERS. Facebook. Log de alterações da Plataforma do
Facebook: 12 de abril de 2016 - API versão 2.6. [S. I.], 2016. Disponível em: <
https://developers.facebook.com/docs/apps/changelog>. Acesso em: 22 jun. 2016.
FACEBOOK PARA EMPRESAS. Facebook. O futuro centrado em tecnologias móveis. [S.
I.], 2013. Disponível em: <https://www.facebook.com/business/news/BR-O-futuro-centrado-
em-tecnologias-moveis>. Acesso em: 20 set. 2015.
FURBTV. 23/09/2015 - Interação FURB 2015. Blumenau, 2015. Disponível em: <
https://www.youtube.com/watch?t=17&v=Vgl6wl04vzI>. Acesso em: 12 nov. 2015.
GOSSENHEIMER, A. N.; CARNEIRO, M. L. F.; CASTRO, M. S. Estudo comparativo da
metodologia ativa “gincana” nas modalidades presencial e à distância em curso de graduação
de Farmácia. Abcs Health Sciences, [S.I.], v. 40, n. 3, p.234-240, 21 dez. 2015. Disponível
em: <http://dx.doi.org/10.7322/abcshs.v40i3.801>. Acesso em 12 jul. 2016.
IONIC PLATFORM. Ionic. The Ionic Platform. [S. I.], 2016a. Disponível em: <
https://ionic.io/platform>. Acesso em: 22 jun. 2016.
______. Information about the Ionic Push service. [S. I.], 2016b. Disponível em: <
http://docs.ionic.io/docs/push-overview>. Acesso em: 22 jun. 2016.
IONICFRAMEWORK. Ionic. Ionic Documentation Overview. [S. I.], 2016. Disponível em:
< http://ionicframework.com/docs/overview/ >. Acesso em: 22 jun. 2016.
74
KARASINSKI, Lucas Ingress: jogo de realidade virtual da Google chega ao iOS. [S. I.],
2012. Disponível em <http://www.tecmundo.com.br/android/32778-conheca-ingress-o-jogo-
de-realidade-alternativa-criado-pela-google-para-o-android.htm>. Acesso em: 07 set. 2015.
KESTRING, Bruno André Sistema Móvel na plataforma Android para compartilhamento
de geolocalização usando mapas e notificações da Google. 2014. 72 f. TCC (Graduação) –
Curso de Ciência da Computação, Centro de Ciências Exatas e Naturais, Universidade
Regional de Blumenau, Blumenau, 2014.
KINLAN, Paul. Geolocation API removed from unsecured origins in Chrome 50. [S.I.],
2016. Disponível em <https://developers.google.com/web/updates/2016/04/geolocation-on-
secure-contexts-only>. Acesso em: 18 jun. 2016.
KIRNER, Claudio; TORI, Romero Realidade Virtual: Conceitos e Tendências. 1. ed. São
Paulo, 2004.
LIBGDX, Bad Logic Games. Goals and Features. [S.I.], 2015a. Disponível em: <
https://libgdx.badlogicgames.com/features.html >. Acesso em: 15 nov. 2015.
______. Ingress by NianticLabs@Google. [S.I.], 2015b. Disponível em:
<https://libgdx.badlogicgames.com/showentry.html?id=ingress>. Acesso em: 15 nov. 2015.
MÜLLER, Henric RoboVM Winding Down. [S.I.], 2016. Disponivel em: <
https://robovm.com/robovm-winding-down/ >. Acesso em: 23 jun. 2016.
NASCIMENTO, R. J.; CALAÇA, E. C. D; MELO, J. C. B. Gincana Virtual: Uma estratégia
didática interdisciplinar. Recife, 2009. Disponível em
<http://www.eventosufrpe.com.br/jepex2009/cd/resumos/R1353-1.pdf>. Acesso em: 20 set.
2015.
NIANTIC LABS, Ingress. 2012. Disponível em < https://www.ingress.com>. Acesso em 24
set. 2015.
OSTETTO, Giancarlo Reiter. Júri Simulado (Parte I) - Interação FURB 2013. Blumenau,
2013. Disponível em: <https://www.youtube.com/watch?v=c9PqnUjAIZI>. Acesso em: 14
jul. 2016.
PEREIRA, Michael H. R. Angularjs: Uma abordagem prática e objetiva. 2. ed. São Paulo:
Novatec, 2015.
PINHO, Márcio S.; KIRNER, Claudio Uma Introdução a Realidade Virtual. [S.I.],
[1997?]. Disponível em: <http://grv.inf.pucrs.br/tutorials/rv/index.htm>. Acesso em: 01 set.
2015.
REIS, Breno M. S. A experiência urbana e apropriação espacial a partir do jogo de realidade
aumentada (ARG) Ingress. Iluminuras, Porto Alegre, v. 16, n. 36, p. 360-378, ago./dez.
2014. Disponível em: <http://seer.ufrgs.br/index.php/iluminuras/article/view/52650/32598>.
Acesso em 07 set. 2015.
ROCHA, Diego Tondim Tô Aqui: Aplicativo Para Georreferenciamento. 2015. 67 f. YCC
(Graduação) – Curso de Ciência da Computação, Centro de Ciências Exatas e Naturais,
Universidade Regional de Blumenau, Blumenau, 2015.
SCHNEIDER, Kamila. A terceira plataforma da TI. Revista Interface, 18. ed. Blumenau, ano
05, p. 13-15, abr./mai./jun. 2013. Disponível em
<http://www.senior.com.br/interface/18/?force-desktop=1>. Acesso em 19 set 2015.
75
SOUZA, K. S. G. O lúdico na comunidade virtual de aprendizagem. Uma visão
transdisciplinar. EccoS – Revista Científica, v. 10, n. 1, p. 143-168, jan./jun. 2008.
Disponível em:
<http://www.uninove.br/PDFs/Publicacoes/eccos/eccos_v10n1/eccosv10n1_3d08.pdf>.
Acesso em 20 set. 2015.
TORI, Romero; KIRNER, Claudio; SISCOUTO, Robson Fundamentos e Tecnologia de
Realidade Virtual e Aumentada. 1. ed. Pará, 2006. Disponível em
<http://www.ckirner.com/download/capitulos/Fundamentos_e_Tecnologia_de_Realidade_Vir
tual_e_Aumentada-v22-11-06.pdf>. Acesso em: 01 set. 2015.
TRICE, Andrew PhoneGap Explained Visually. [S.I.], 2012a. Disponível em
<http://phonegap.com/2012/05/02/phonegap-explained-visually/>. Acesso em 06 set. 2015.
______. PhoneGap Native Plugins. [S.I.], 2012b. Disponível em
<http://www.tricedesigns.com/2012/03/01/phonegap-native-plugins/>. Acesso em 06 set.
2015.
UNIVERSIDADE REGIONAL DE BLUMENAU Nossa História: como tudo começou.
Blumenau, [2014a?]. Disponível em <http://www.furb.br/web/1317/institucional/a-
furb/nossa-historia>. Acesso em: 05 set. 2015.
______. Interação FURB. Blumenau, [2014b?]. Disponível em
<http://www.furb.br/web/1368/relacao-com-a-comunidade/interacao-furb>. Acesso em: 05
set. 2015.
76
APÊNDICE A – Integrando com o Trello
Neste apêndice encontram-se os passos para realizar a configuração da chave API de
desenvolvedor do Trello. Estes passos estão divididos em duas etapas: (1) efetuar login no
Trello e obter a chave API de desenvolvedor e (2) importar a biblioteca cliente.js no
arquivo index.html da aplicação. Na etapa (1) deve-se acessar o endereço
https://trello.com/app-key e localizar a chave gerada para a conta logada no Trello. A Figura
40 apresenta onde localizar a chave de API.
Figura 40 - Localização da Chave de API do Trello
Na etapa (2), deve-se importar a biblioteca client.js, utilizando a chave obtida como
parâmetro. A linha 1 do Quadro 13, apresenta a importação da biblioteca na seção head do
arquivo index.html. Após a importação, é possível utilizar a classe Trello para invocar os
métodos da API.
Quadro 13 - Importando client.js 1
2
3
<script
src="https://trello.com/1/client.js?key=ca4f9f958a4115bf66c830bXXXXXXXXX">
</script>
Após seguir os passos apresentados nesse apêndice, as rotinas de integração com a API
do Trello poderão ser utilizadas e estarão vinculadas com o projeto associado a chave API de
desenvolvedor.
77
APÊNDICE B – Integrando com o Facebook
Neste apêndice encontram-se os passos para realizar a configuração da chave API de
desenvolvedor do Facebook. Estes passos estão divididos em quatro etapas: (1) criar um
projeto no Facebook Developer, adicionando a funcionalidade Login do Facebook, (2)
configurar as URIs válidas de redirecionamento, (3) habilitar os usuários para realizar os
testes de integração e (4) informar a chave de API na inicialização do módulo ngOpenFB.
Na etapa (1), deve-se acessar a opção Create New App na tela inicial do Facebook
Developer, adicionando a funcionalidade Login do Facebook. Quando o usuário do
aplicativo informar suas credenciais de acesso a sua conta, a API do Facebook redireciona o
usuário para um endereço de retorno configurado no ngOpenGB. Este endereço deve estar
configurado previamente no projeto do aplicativo. Para a etapa (2), a Figura 41 mostra a
configuração feita para o Furb Mobile Gincanas, onde a URI
http://localhost:8100/oauthcallback.html é utilizada quando o acesso é feito no
aplicativo mobile através do framework Phonegap, e a URI
https://www.facebook.com/connect/login_success.html é utilizada para acesso via
browser. A segunda URI foi utilizada durante a fase inicial de desenvolvimento do aplicativo,
onde os testes eram feitos diretamente em um browser.
Figura 41 – Configurando URIs de redirecionamento
O quadro mostra o código fonte da página HTML oauthcallback.html, onde, na
linha 4, a classe openFB recebe a URL da janela de login do Facebook, onde consta o token de
autenticação do usuário.
Quadro 14 - Código fonte da página oauthcallback.html 1
2
3
4
5
6
7
8
<html>
<body>
<script>
window.opener.openFB.oauthCallback(window.location.href);
window.close();
</script>
</body>
</html>
Na etapa (3) é feito a configuração de permissão de acesso dos usuários. Os projetos
configurados no Facebook iniciam no modo desenvolvimento, ficando indisponíveis para o
uso público. Durante o desenvolvimento do Furb Mobile Gincanas, não foi feito o processo de
78
envio do aplicativo para avaliação do Facebook. Assim, para realizar os testes, foi necessário
habilitar manualmente o acesso de usuários ao aplicativo, dando-lhes a função de testadores.
A Figura 42 apresenta a tela para convidar os usuários do Facebook, para as funções de
Administrador, Desenvolvedor, Testador e Usuário de informações.
Figura 42 - Habilitando usuários
A etapa (4) é feita a configuração do módulo ngOpenFB, onde a chave de API do
aplicativo, obtido na página inicial do projeto no Facebook Developers, deve ser passada
como parâmetro na inicialização da classe ngFB. Essa configuração é apresentada no Quadro
15.
Quadro 15 - Inicialização da classe ngFB 1
2
3
ngFB.init({
appId : '999117715125999',
});
Após seguir os passos apresentados nesse apêndice, as rotinas de integração com a API
do Facebook poderão ser utilizadas e estarão vinculadas com o projeto configurado na
plataforma Facebook Developers.