Você está na página 1de 42

Marcelo Felipe Guarani Fernandes

Udyat: um aplicativo híbrido com o intuito de


assegurar o usuário no meio em que vive

Passo Fundo
2019
Marcelo Felipe Guarani Fernandes

Udyat: um aplicativo híbrido com o intuito de assegurar o


usuário no meio em que vive

Projeto de pesquisa submetido ao Curso de


Tecnologia em Sistemas para Internet do Ins-
tituto Federal Sul-Rio-Grandense, Câmpus
Passo Fundo, como requisito parcial para a
aprovação na disciplina de Projeto de Con-
clusão I (PC I).

INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA


SUL-RIO-GRANDENSE - CÂMPUS PASSO FUNDO

Orientador: Profa. Dra. Anubis Graciela de Moraes Rossetto

Passo Fundo
2019
Lista de ilustrações

Figura 1 – Taxa de homicídios no Brasil por regiões de 2006 a 2016 . . . . . . . . 10


Figura 2 – Número de denúncias de violência contra pessoas LGBTI+ no Brasil
(2011-2017), segundo o Disque 100 . . . . . . . . . . . . . . . . . . . . 10
Figura 3 – Indisponibilidade da Internet em área rural . . . . . . . . . . . . . . . 14
Figura 4 – Diagrama de arquitetura Cordova . . . . . . . . . . . . . . . . . . . . . 22
Figura 5 – Estrutura de dados Cloud Firestore . . . . . . . . . . . . . . . . . . . . 23
Figura 6 – Os 24 satélites do Sistema Global de Posicionamento . . . . . . . . . . 26
Figura 7 – URL de solicitação da API . . . . . . . . . . . . . . . . . . . . . . . . . 27
Figura 8 – Diagrama Caso de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Figura 9 – Dados de Pessoa no Cloud Firestore . . . . . . . . . . . . . . . . . . . 31
Figura 10 – Dados do Monitor e da Rota de Pessoa no Cloud Firestore . . . . . . . 31
Figura 11 – Dados do Monitor no Cloud Firestore . . . . . . . . . . . . . . . . . . . 32
Figura 12 – Dados da Rota no Cloud Firestore . . . . . . . . . . . . . . . . . . . . 32
Figura 13 – Diagrama de Sequência para autenticação de usuário com o Firebase . 33
Figura 14 – Diagrama de Sequência para a ação de pedido de ajuda on-line . . . . 34
Figura 15 – Diagrama de Sequência para a ação de pedido de ajuda off-line . . . . 35
Figura 16 – Mock-Up: a: Cadastro; b: Login . . . . . . . . . . . . . . . . . . . . . . 36
Figura 17 – Mock-Up: a: Inicial; b: Ponto A e B; c: Meus monitores . . . . . . . . . 37
Figura 18 – Mock-Up: a: Menu; b: Meus monitores; c: Cadastro de monitores . . . 38
Figura 19 – Mock-Up: a: Notificação; b: Localização atual . . . . . . . . . . . . . . 38
Lista de tabelas

Tabela 1 – Proporção de óbitos causados por homicídios no Brasil em 2016 . . . . 9


Tabela 2 – Como aplicações nativas e híbridas abordam as principais características
do uso e desenvolvimento de aplicativos . . . . . . . . . . . . . . . . . 17
Tabela 3 – Cronograma de Atividades PC II . . . . . . . . . . . . . . . . . . . . . 39
Lista de abreviaturas e siglas

API Application Programming Interface

APP Mobile Application

APPS Mobile Applications

CSS Cascading Style Sheets

GLONASS Globalnaya Navigatsionnaya Sputnikovaya Sistema

GPS Global Positioning System

GSM Global System for Mobile Communications

HTML HyperText Markup Language

HTTP HyperText Transfer Protocol

HTTPS HyperText Transfer Protocol Secure

IBGE Instituto Brasileiro de Geografia e Estatística

IPEA Instituto de Pesquisa Econômica Aplicada

JSON JavaScript Object Notation

LGBTI+ Lésbicas, Gays, Bissexuais, Travestis, Transexuais, Intersexuais e outras


identidades de gênero e sexualidade não contempladas na sigla atual,
representadas pelo “+”

NoSQL Not Only SQL

PWA Progressive Web Apps

SMS Short Message Service

SQL Structured Query Language

SVs Space Vehicles

URL Uniform Resource Locator

V3 Version 3

Vs Versus
Lista de símbolos

⇔ se, e somente se

←− implica que

−→ implica que
Sumário

1 TEMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.1 Delimitação do Tema . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 PROBLEMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3 OBJETIVOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1 Objetivo Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2 Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4 JUSTIFICATIVA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

5 TRABALHOS CORRELATOS . . . . . . . . . . . . . . . . . . . . . 15
5.1 Não Cheguei! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.2 CheckUp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.3 Follow Us . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.4 Cerberus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

6 REFERENCIAL TEÓRICO . . . . . . . . . . . . . . . . . . . . . . . 17
6.1 Aplicações Nativas Vs Híbridas . . . . . . . . . . . . . . . . . . . . . . 17
6.2 Vantagens e Desvantagens entre aplicações Nativas e Híbridas . . . 18
6.2.1 Nativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.2.1.1 Vantagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.2.1.2 Desvantagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.2.2 Híbrido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.2.2.1 Vantagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.2.2.2 Desvantagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.3 Ionic Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.3.1 Angular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.3.2 Apache Cordova . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.4 Plataforma Firebase . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6.4.1 Cloud Firestore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6.4.2 Firebase Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.4.3 Firebase Cloud Messaging . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.5 Short Message Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.6 Global Positioning System . . . . . . . . . . . . . . . . . . . . . . . . 25
6.7 Google APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.7.1 Maps JavaScript API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.7.2 Geolocation API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.7.3 Directions API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

7 METODOLOGIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
7.1 Levantamento de Requisitos . . . . . . . . . . . . . . . . . . . . . . . 29
7.1.1 Diagrama Caso de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
7.1.2 Modelo de Armazenamento Cloud Firestore . . . . . . . . . . . . . . . . . 30
7.1.3 Diagrama de Sequência . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
7.2 Mock-Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
7.2.1 Cronograma de Atividades . . . . . . . . . . . . . . . . . . . . . . . . . . 39

REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
8

1 Tema

Desenvolvimento de aplicativo híbrido com o intuito de assegurar o usuário no


meio em que vive.

1.1 Delimitação do Tema


O presente projeto de pesquisa reflete o desenvolvimento de um aplicativo híbrido
em Ionic na versão 3, com o intuito de manter a segurança física do usuário face à sociedade
em que vive. Os usuários cadastrados no aplicativo recebem notificações atualizadas sobre
a localização do remetente do pedido de socorro, caso a ação do botão de pedido de ajuda
seja acionada. Existe também a possibilidade de gerenciamento de rota, em que o usuário
cadastrado e autorizado pode acompanhar o trajeto pré-determinado pelo usuário, a fim
de ter certeza de que este chegou em segurança ao destino planejado. A pesquisa será de
caráter aplicado e desenvolver-se-á no desempenho das ferramentas utilizadas.
9

2 Problema

Tempos de violência assolam a sociedade; insegurança, desassossego constante e


ansiedade. Sair de casa está causando esses desconfortos.
Chisholm (2017) afirma que o Brasil lidera na América Latina e no mundo um
percentual de 9,3% da população com algum tipo de transtorno de ansiedade. A taxa é
três vezes superior à média mundial. Em suas palavras, essa ansiedade “trata-se de uma
combinação da situação socioeconômica e a realidade da vida de uma população”.
Oliveira (2017 apud RIBEIRO, 2018, p. 2) diz que, “há lugares em que as equipes
de segurança pública, esperam 24 horas ou 48 horas para registrar o desaparecimento de
crianças e adolescentes, mesmo depois de uma lei determinar”. Um exemplo inspirador
para o desenvolvimento do aplicativo, foi o caso da menina Vitória Gabrielly, que foi
encontrada morta oito dias depois de desaparecer ao sair de casa para andar de patins, na
cidade de Araçariguama (SP).
É válido destacar também que, os números de óbitos causados por homicídios têm
aumentado bastante entre jovens do sexo masculino de idades entre 15 a 29 anos, e segundo
Cerqueira et al. (2018) em 2016 esse valor “correspondeu a 50,3% do total de óbitos. Se
considerarmos apenas os homens entre 15 e 19 anos, esse indicador atinge a incrível marca
dos 56,5%”, como mostra a Tabela 1.

Tabela 1 – Proporção de óbitos causados por homicídios no Brasil em 2016


Faixa etária 10 a 14 15 a 19 20 a 24 25 a 29 30 a 34 35 a 39 40 a 44 45 a 49 50 a 54 55 a 59 60 a 64 65 a 69 Total
Masculino 17,4% 56,5% 52,4% 42,8% 33,0% 22,7% 13,9% 7,6% 4,3% 2,4% 1,5% 0,8% 13,9%
Feminino 6,4% 14,1% 14,3 10,5% 7,9% 4,7% 2,6% 1,7% 0,8% 0,5% 0,3% 0,1% 2,0%
Total 13,2% 49,1% 46,0% 36,1% 26,4% 17,1% 10,1% 5,5% 3,0% 1,7% 1,0% 0,5% 9,7%

Adaptado de: (CERQUEIRA et al., 2018)

Além de homicídios entre jovens do sexo masculino, jovens do sexo feminino fazem
parte dos altos índices de violências sexuais, segundo Cerqueira, Coelho e Mendonça
(2017).
A Figura 1 mostra o reflexo de toda essa violência e a evolução das taxas de
homicídios ao longo do período de quatro anos, que ocorreu de diferentes formas entre as
regiões do Brasil. Enquanto nas regiões Sudeste e Centro-Oeste houve uma estabilidade,
nas demais regiões pode-se observar um aumento de forma acentuada, e esse número é
ainda maior na região Norte.
Capítulo 2. Problema 10

Figura 1 – Taxa de homicídios no Brasil por regiões de 2006 a 2016

Fonte: (CERQUEIRA et al., 2018)

Vale ressaltar também a violência contra pessoas LGBTI+ que segundo Cerqueira,
Lima et al. (2019), o Disque 1001 aponta um forte crescimento entre os anos de 2011 a
2017, saindo de um total de 5 casos, em 2011, para 193 casos, em 2017. Já neste ano houve
um crescimento de 127% no número de denúncias registradas, como destacado na Figura 2.

Figura 2 – Número de denúncias de violência contra pessoas LGBTI+ no Brasil (2011-


2017), segundo o Disque 100

Fonte: (CERQUEIRA; LIMA et al., 2019)

Sobre o número de registros de denúncias, os pesquisadores do IPEA propuseram


1
Disque 100: consiste em um canal que recebe, analisa e encaminha denúncias de violações de direitos
humanos relacionados a vários grupos, como crianças, idosos, LGBTI+, entre outros; e também
relacionados a vários temas, como tráfico de pessoas, trabalho escravo e outros mais. (CERQUEIRA;
LIMA et al., 2019)
Capítulo 2. Problema 11

que, “Naturalmente, pode-se aventar a possibilidade de tal crescimento ter sido ocasionado
por uma diminuição da subnotificação, uma vez que, nesse período, o movimento LGBTI+
tem sido bastante ativo no sentido de visibilizar e denunciar o problema da violência contra
a população LGBTI+” (CERQUEIRA; LIMA et al., 2019).
Tais problemas não podem ser evitados pela tecnologia pois isso é um problema de
segurança pública, mas tendo em vista que os jovens fazem parte do público principal que
faz uso constante da tecnologia, pode-se então inferir que essa seria de certa forma uma
maneira de muni-los contra a violência, levando em conta que este é um meio instantâneo
de comunicação.
Aplicativos responsáveis por assegurar o usuário em caráter físico ainda não são tão
difundidos. Nas lojas de aplicativos encontramos uma gama recheada de apps voltados para
a segurança dos periféricos, mas não para a segurança pessoal do usuário. Pensando nisso,
propõe-se no Udyat 2 essa funcionalidade. Um aplicativo pensado para gerir a segurança
física do usuário.
Manter pessoas de sua confiança informadas sobre sua atual localização, ou fazer
com que elas recebam notificações de tempo em tempo informando o mesmo, caso o usuário
necessite de ajuda, faz com que as buscas se tornem mais rápidas e precisas.

2
Udyat: símbolo egípcio milenar que significa poder e proteção, criado pelo Deus da sabedoria Toth
e dado ao Deus Hórus, o Deus do sol nascente representado por um falcão, a personificação da luz
na terra, a fim de suprir a falta de seu olho esquerdo arrancado em uma luta pelo Deus Seth, Deus
da desordem e violência. Conhecido popularmente como Olho de Hórus, é usado nos dias atuais por
muitos em forma de proteção contra mau-olhado e inveja.
12

3 Objetivos

3.1 Objetivo Geral


Desenvolver aplicativo híbrido com o Framework Ionic que possibilite o monitora-
mento do deslocamento de um usuário por outras pessoas com o intuito de auxiliar na sua
segurança pessoal.

3.2 Objetivos Específicos

• Estudar o Framework Ionic na versão 3 e os recursos para geolocalização e uso de


mapas;

• Fazer estudo do Firebase Firestore para armazenamento de dados;

• Definir alternativas para informar a localização do usuário quando seu dispositivo


estiver sem conexão de dados;

• Desenvolver a aplicação nas versões de visualização do usuário monitorado e usuario


monitor;

• Notificar usuário monitores usando Firebase Messaging ou SMS(Short Message


Service);

• Avaliar a aplicação com os usuários.


13

4 Justificativa

A introdução do aplicativo no mercado propõe a potencialização da segurança


física dos utentes, além de ser um forte aliado das forças de segurança pública, pois
não seria necessário esperar tanto para afirmar que uma pessoa está desaparecida. Além
disso, o fornecimento da localização atual e contínua, feita por meio do GPS, aumenta a
assertividade nas buscas, em um cenário de sequestro, por exemplo.
No aplicativo proposto, os usuários cadastrados recebem notificações atualizadas
sobre a localização do remetente do pedido de socorro, caso a ação do botão de pedido
de ajuda seja acionada. Existe também a possibilidade de gerenciamento de rota, em
que o usuário cadastrado e autorizado, pode acompanhar o trajeto pré-determinado pelo
remetente, a fim de ter certeza de que esse chegou em segurança ao destino planejado.
No âmbito científico existem trabalhos correlatos, com a finalidade de assegurar
de forma física o usuário. Eles compartilham o mesmo propósito deste trabalho, mas
apresentam diferenciais entre si. O foco central dos projetos é, manter a privacidade
mútua entre os usuários, notificá-los, caso seja acionado o pedido de socorro, e manter a
comunicação entre aplicativo, banco de dados e GPS.
O Udyat compartilha das mesmas características, porém diferencia-se dos demais
ao manter a operabilidade do sistema, caso não haja conexão com a rede de dados. Em
um cenário onde o evento do botão de pedido de socorro foi acionado, e exista conexão
com a rede de dados, serão obtidas a latitude e longitude do usuário e, notificações serão
expedidas para os seus monitores, informando a localização desse de forma contínua.
Entretanto, se a aplicação estiver sem conectividade com a rede de dados, será enviada
uma mensagem SMS, obtendo dados da última localização coletada.
Manter a operabilidade do sistema caso não haja conexão com a rede de dados
se faz necessário quando levado em conta a qualidade do serviço de internet no Brasil,
principalmente em áreas rurais. Segundo o IBGE (2018) “A indisponibilidade do serviço
de acesso à Internet foi o motivo indicado em somente 1,2% dos domicílios da área urbana,
contra 21,3% daqueles em área rural.”, conforme destacado na Figura 3.
Capítulo 4. Justificativa 14

Figura 3 – Indisponibilidade da Internet em área rural

Fonte: (IBGE, 2018)


15

5 Trabalhos Correlatos

Esta seção aborda os trabalhos existentes no âmbito científico que compartilham


as mesmas características do projeto proposto pelo autor, e seus diferenciais.

5.1 Não Cheguei!


Sombra (2018) desenvolveu um sistema que gerencia um alerta aos contatos do
usuário caso esse não chegue ao seu destino na hora programada, fazendo com que uma
tomada de ação imediata seja realizada. A solução implementada nesse trabalho foi projetar
um aplicativo para o sistema móvel Android, de forma nativa e escrita em Java, cuja
função é o controle das rotas que estão sendo realizadas pelos usuários.

5.2 CheckUp
Ribeiro (2018) implementou um aplicativo para Android, de forma híbrida em
Ionic v3, utilizando o banco de dados da Plataforma Firebase.
O diferencial do aplicativo, fica a cargo da implementação de uma agenda, na qual
o usuário cria alarmes, para que seja notificado pelo aplicativo, que deverá questionar o
usuário sobre sua situação num determinado momento pré-definido. Caso o alarme não
seja contestado em um minuto, a aplicação ativa o pedido de socorro, enviando então
notificações, com a localização do mesmo, para os usuários pré-cadastrados.

5.3 Follow Us
Desenvolvido pelo Garcia (2016), tem como principal recurso, o compartilhamento
de localização entre grupos de contatos. O compartilhamento é feito em tempo real e é
atualizado com frequência por meio do framework SignalR, para comunicação cliente /
servidor. Esta ferramenta possibilita que seja escolhido o protocolo ou arquitetura utilizada
para enviar ou receber informações.

5.4 Cerberus
O Cerberus é um aplicativo que permite compartilhar a localização do deslocamento
em tempo real para contatos selecionados através de mensagem por e-mail, SMS, Twitter
e Facebook (CERBERUS, 2019).
Capítulo 5. Trabalhos Correlatos 16

É possível determinar o tempo de duração que o compartilhamento permanecerá


ativo, acionar um botão de emergência para pedido de ajuda e trocar mensagens com os
contatos que estão acompanhando o trajeto. Ele está disponível nas versões Antitheft,
que fornece proteção contra furto ou roubo do dispositivo, Persona e Kids, onde os pais
podem definir áreas seguras na cidade e receber notificações quando seus filhos entrarem
ou saírem dessas áreas.
17

6 Referencial Teórico

Esta seção apresenta as ferramentas necessárias para a produção do aplicativo hí-


brido Udyat, apresentando algumas características, arquiteturas e dependências. Outrossim,
suas documentações são a base de apoio para o desenvolvimento do aplicativo.

6.1 Aplicações Nativas Vs Híbridas


Nos dias atuais fazemos uso constate de aplicativos para dispositivos móveis. Além
dos aplicativos nativos, existem as aplicações híbridas. Todavia, há diferentes maneiras de
desenvolver aplicações mobile e inúmeros frameworks para construção dos mesmos.
Segundo More e Chandran (2016, tradução nossa), “Aplicativos nativos podem
ser criados usando a linguagem de programação nativa do dispositivo, e somente são
executados em suas plataformas designadas.” Enquanto que as aplicações híbridas são o
cruzamento entre aplicativos nativos e aplicativos da web para dispositivos móveis. Os
aplicativos da web para celular são executados por meio de uma webview, como foi citado
na seção 6.3.2, isso permite que a aplicação opere em todas as plataformas pois, para criar
essas aplicações são utilizadas linguagens de desenvolvimento web, como HTML, CSS e
JavaScript.
Na Tabela 2 é possível observar as particularidades entre as duas abordagens
de desenvolvimento mobile, suas principais características, ferramentas necessárias para
desenvolvimento, e a forma que os aplicativos são distribuídos para os usuários.

Tabela 2 – Como aplicações nativas e híbridas abordam as principais características do


uso e desenvolvimento de aplicativos
Aplicações Nativas Aplicações Híbridas
• HTML
• Objective-C • JavaScript
• C++ • CSS
Ferramentas necessárias para
• Java • Web programming
desenvolvimento das aplicações
• VB.net • languages (i.e., Java etc.)
• C# • Mobile development
• Frameworks
Instalados no dispositivo? Sim Sim
Forma de distribuição Loja de aplicativos Loja de aplicativos
Integração total: por exemplo Integração total: por exemplo
(câmera, microfone, GPS, (câmera, microfone, GPS,
Integração com recursos do dispositivo
giroscópio, acelerômetro, giroscópio, acelerômetro,
upload de arquivos, lista de contatos) upload de arquivos, lista de contatos)
• Aplicativos multiplataforma que
• Aplicativos altamente gráficos
precisa de acesso total aos dispositivos.
Melhor usado para • Aplicativos que precisam alcançar
• Aplicativos de negócios que precisam
o grande consumidor público
distribui-los nas loja de aplicativos

Adaptado de: (MORE; CHANDRAN, 2016, tradução nossa)


Capítulo 6. Referencial Teórico 18

6.2 Vantagens e Desvantagens entre aplicações Nativas e Híbridas


Existem algumas vantagens e desvantagens entre desenvolvimento nativo e híbrido,
e elas serão abordadas nesta seção.

6.2.1 Nativo
6.2.1.1 Vantagens

− Altamente gráfico
Construído a partir da linguagem nativa do dispositivo principal e instalado nos
próprios dispositivos sem a necessidade de ser executado por meio de uma webview,
aplicativos nativos podem oferecer os melhores gráficos e animações. Se uma empresa
precisa de aplicativos altamente gráficos, como um jogo, esta é sem dúvida a melhor opção
(MORE; CHANDRAN, 2016).
− Integração de dispositivos
Os aplicativos nativos oferecem acesso total ao hardware do dispositivo, como
o sensor do GPS, lista de contatos, câmera, microfone, giroscópios, acelerômetro, e etc.
Essas capacidades são essenciais para aplicativos que exigem dados do dispositivo, como
localização geográfica. É importante salientar que os aplicativos híbridos também oferecem
integração total de dispositivos, entretanto, quando um novo dispositivo é lançado com
algum novo recurso, de forma nativa já obtemos total acesso a estes novos recursos, pois
este é desenvolvido em sua linguagem nativa, enquanto que nas aplicações híbridas é
necessário que se desenvolvam antes de tudo novos plugins capazes de acessar estes novos
recursos, para que assim possam ser acessados (MORE; CHANDRAN, 2016).

6.2.1.2 Desvantagens

− Nenhuma portabilidade
Como cada aplicativo nativo só é executado na plataforma para qual foi desenvolvido,
as empresas que criam aplicativos nativos devem fazer uma escolha - construir para uma
plataforma ou construir para múltiplas plataformas pois, construir um aplicativo para
apenas uma plataforma exclui as demais, e desenvolver para todas elas requer tempo e
recursos significativos (MORE; CHANDRAN, 2016).
− Instabilidade da plataforma
Pode-se notar que o panorama das plataformas móveis é notoriamente instável.
Uma plataforma popular hoje pode desaparecer em apenas alguns anos. Por exemplo,
tanto o Blackberry quanto o Palm dominaram a indústria móvel em apenas cinco anos, e
hoje ambas desapareceram do mercado. Não podemos prever como será o futuro de uma
Capítulo 6. Referencial Teórico 19

plataforma móvel. A escolha de desenvolver de forma nativa envolve o risco de perder tempo
e dinheiro na construção de plataformas que podem não durar (MORE; CHANDRAN,
2016).
− Custo de desenvolvimento
Embora o custo de desenvolvimento de aplicativos nativos varie de acordo com sua
complexidade, é sabido que esta é uma abordagem cara e demorada. Por exemplo, segundo
a Forrester (2019 apud MORE; CHANDRAN, 2016, p. 566) estima-se que a maioria dos
aplicativos nativos exigem pelo menos 6 meses de trabalho em tempo integral e custam
entre US $ 20.000 e US $ 150.000, dependendo da complexidade.
− Custo de manutenção
Embora todos os aplicativos requeiram atualizações e manutenção regulares, os
aplicativos nativos também precisam ser atualizados em cada novo lançamento de pla-
taforma no mercado. Além disso, as empresas que criam estes aplicativos para várias
plataformas devem manter várias versões do mesmo, duplicando todas as alterações ou
atualizações em todos as plataformas (MORE; CHANDRAN, 2016).

6.2.2 Híbrido
6.2.2.1 Vantagens

− Baixo custo de desenvolvimento


Para quem precisa de rapidez no desenvolvimento e quer aplicativos com aparência
dos apps nativos, porém sem o alto custo de desenvolvimento, as aplicações híbridas são a
melhor escolha. Assim como os aplicativos nativos, os aplicativos híbridos também são
instalados no dispositivo e lançados igualmente nas lojas. Essas aplicações são indistinguí-
veis, pois o usuário nem percebem se estão a usar uma ou a outra (MORE; CHANDRAN,
2016).
− Acesso ao hardware do dispositivo
Aplicativos híbridos oferecem acesso total ao hardware do dispositivo, igualmente
aos nativos. E além disso, com apenas uma base de código é possível disponibilizar a
aplicação em inúmeras plataformas (MORE; CHANDRAN, 2016).

6.2.2.2 Desvantagens

− Acesso aos recursos do dispositivo


Embora os plugins sejam capazes de acessar os recursos do dispositivo como câmera,
geolocalização entre outros, quando um novo recurso aparece no mercado, é necessário que
se desenvolva um novo plugin capaz de acessar este novo recurso, pois a codificação nesse
Capítulo 6. Referencial Teórico 20

modo não é feita na forma nativa (MORE; CHANDRAN, 2016).


− Framework
Exige que se tenha conhecimento sólido em algum Framework, enquanto que no
nativo basta ter conhecimento da linguagem nativa da plataforma, sem a necessidade de
se trabalhar com um Framework (MORE; CHANDRAN, 2016).

6.3 Ionic Framework


Desenvolvido com o propósito de facilitar a vida do programador mobile, o Ionic
é um framework que visa o desenvolvimento de aplicações híbridas, de fácil e rápido
desenvolvimento utilizando linguagens HTML, CSS e TypeScript (IONIC; FRAMEWORK,
2019). O desenvolvimento híbrido fundamenta em implementar apps que funcionem em
inúmeras plataformas, tais como: IOS nativo, Android, Desktop e Progressive Web Apps
(PWA), cujo lema é: “Write once, run anywhere”, tudo com apenas uma base de código.
Para tal, é utilizado o Angular para estrutura da aplicação, e o Apache Cordova para
acessar o hardware do dispositivo por meio de plugins.

6.3.1 Angular
O Angular auxilia o desenvolvedor na construção de aplicações web, móveis ou
desktop. Este framework consiste no desenvolvimento cliente em HTML e TypeScript.
Suas funcionalidade são implementadas fazendo uso de um conjunto de bibliotecas, que
são importadas para dentro da aplicação (ANGULAR, 2019a).
Estruturas escritas em Angular são modulares, e possuem seu próprio sistema de
modularidade chamado NgModules. De acordo com sua documentação, “NgModules são
contêineres para um bloco coesivo de código dedicado a um domínio de aplicativo, um
fluxo de trabalho, ou um conjunto estritamente relacionado de recursos.” (ANGULAR,
2019c, tradução nossa). Eles podem conter components, service providers e outros arquivos
de código do qual o escopo é definido pelo NgModule. Toda aplicação escrita em Angular
possui pelo menos um componente, o raiz, que também é responsável por controlar os
links de navegação de cada página.
De acordo com o Angular (2019b), a movimentação dos dados entre a view e o
model acontecem de três formas, e elas são:

• Event Binding: representado entre ( ), os dados são enviados da view para o model,
quando o usuário submete algum dado em um input, por exemplo;

(event) = handler
view −→ model
Capítulo 6. Referencial Teórico 21

(ANGULAR, 2019b)

• Property Binding: representado entre [ ], os dados são apenas expostos na tela do


usuário, sem que este possa editar. Um exemplo prático é quando instalamos um
novo aplicativo em um smartphone, nos é exibido um termos de serviço, e as opções
são apenas aceitar ou recusar, não podemos editar o que está contido no corpo do
texto;

[property] = value
view ←− model

(ANGULAR, 2019b)

• Two Way Data Binding: representado entre [( )], os dados trafegam nas duas vias,
(view ⇔ model), caso seja alterado na view será também alterado no model e vice
versa.

[(ng-model)] = property
view ⇔ model

(ANGULAR, 2019b)

Desse modo, podemos especificar quais informações podem ser editadas ou apenas
apresentadas ao usuário.

6.3.2 Apache Cordova


O Apache Cordova é um framework de desenvolvimento mobile para aplicações
cross-platform. O termo cross-platform fundamenta em implementar apps que funcionem
em inúmeras plataformas, tais como: IOS nativo, Android, Desktop e Progressive Web
Apps (PWA).
Porém, uma aplicação híbrida não tem acesso aos recursos nativos do dispositivo.
Para isso, se faz necessário o uso dos plugins Cordova para que se tenha acesso aos recursos
como: câmera, geolocalização, entre outros.
Plugins são partes vitais do ecossistema Cordova, sem eles é impossível acessar
recursos nativos do dispositivo em aplicações híbridas. Eles fornecem uma interface para
que o Cordova e os componentes nativos se comuniquem e vinculem-se às APIs padrões
do dispositivo. Existe também a possibilidade de se fazer uso de plugins de terceiros, por
ser um framework open-source, dá a liberdade para que desenvolvedores criem recursos
não necessariamente disponíveis em todas as plataformas (CORDOVA, 2019).
Capítulo 6. Referencial Teórico 22

A Figura 4 mostra como é feita a interação entre a aplicação e os plugins Cordova.


Após o app ser renderizado, ele é executado em uma webview, que por sua vez acessa os
recursos nativos do dispositivo por meio desses plugins.

Figura 4 – Diagrama de arquitetura Cordova

Fonte: (CORDOVA, 2019)

6.4 Plataforma Firebase


Firebase é uma plataforma de desenvolvimento mobile e web com foco em ser um
back-end completo e de fácil usabilidade. Ela oferece funcionalidades como análises, bancos
de dados, mensagens e relatórios de falhas para que o desenvolvedor possa se concentrar
nos usuários e sua aplicação, sem que precise gerenciar a infraestrutura (FIREBASE,
2019).

6.4.1 Cloud Firestore


O Cloud Firestore é um banco de dados flexível e escalonável para desenvolvimento
de dispositivos móveis, web e servidores (CLOUD FIRESTORE, 2019). Como o Firebase
Realtime Database, ele mantém por meio de listeners seus dados em sincronia em aplicativos
cliente em tempo real. Além disso, oferece suporte off-line para dispositivos móveis e web
para que se possa criar aplicativos que funcionem independentemente da latência da rede
ou da conectividade com a Internet.
Capítulo 6. Referencial Teórico 23

O modelo de dados do Cloud Firestore disponibiliza estruturas de dados hierárquicas


flexíveis. Os dados são organizados em coleções que são como tabelas no modelo SQL. E
os documentos, que aqui são como registros de uma tabela em SQL, são armazenados nas
coleções e podem conter objetos aninhados complexos, além de subcoleções.
No modelo de dados NoSQL, os dados são armazenados em documentos que contém
mapeamentos de campos para valores, como destaca a Figura 5. Esses documentos são
armazenados em coleções, que são contêineres de documentos que podem ser usados
para organizar dados e criar consultas. Os documentos são compatíveis com muitos tipos
de dados diferentes, como strings e números simples a objetos complexos. É possível
também criar subcoleções dentro dos documentos e criar estruturas de dados hierárquicas
que podem ser escalonadas de acordo com o crescimento do banco de dados (CLOUD
FIRESTORE, 2019).

Figura 5 – Estrutura de dados Cloud Firestore

Fonte: (CLOUD FIRESTORE, 2019)

Segundo a sua documentação, é usado “sincronização de dados para atualizar


dados em qualquer dispositivo conectado. No entanto, ele também é projetado para fazer
consultas de busca simples e únicas de maneira eficiente.” (CLOUD FIRESTORE, 2019).

6.4.2 Firebase Authentication


Grande parte das aplicações verificam a autenticidade dos seus usuários pois
precisam reconhecer sua identidade. Essa premissa permite armazenar os dados com
segurança. O Firebase Authentication fornece serviços de back-end fáceis de usar e prontos
para autenticar os usuários nos apps. Além disso, oferece suporte à autenticação por
meio de senhas, redes sociais como Google, Facebook, Twitter, entre outros (FIREBASE;
AUTHENTICATION, 2019).
Capítulo 6. Referencial Teórico 24

O componente FirebaseUI implementa práticas recomendadas para autenticação


dos usuários em dispositivos móveis e web, isso melhora a conversão dos dados de inscrição
na aplicação (FIREBASE; AUTHENTICATION, 2019).
Para conectar um usuário ao seu app, você precisa primeiro ter suas credenciais de
autenticação. As credenciais podem ser o endereço de e-mail e a senha do usuário ou até
um token do OAuth de um provedor de identidade como o Facebook, twitter, entre outros.
Em seguida, você transmite essas credenciais para o SDK do Firebase Authentication.
Então, os serviços de back-end farão a verificação desses dados e posteriormente enviarão
uma resposta ao cliente (FIREBASE; AUTHENTICATION, 2019).
Após fazer login, é dado acesso às informações básicas do perfil do usuário e pode
então controlar o acesso dele aos dados armazenados em outros produtos do Firebase
(FIREBASE; AUTHENTICATION, 2019).

6.4.3 Firebase Cloud Messaging


O Firebase Cloud Messaging (FCM) é uma solução de mensagens cross-platform,
que permite enviar notificações sem nenhum custo (FIREBASE; CLOUD MESSAGING,
2019). O termo cross-platform, fundamenta em implementar aplicações que funcionem em
inúmeras plataformas, tais como: IOS nativo, Android, Desktop e Progressive Web Apps
(PWA). Para pleno funcionamento do serviço é necessário que haja conexão via wi-fi ou
dados móveis, pois é por meia dela que o FCM notificará o usuário.
Existem dois componentes principais para envio e recebimento de notificações, o
Cloud Functions, onde o desenvolvedor pode criar funções que são acionadas por produtos
do próprio Firebase; ou uma aplicação cliente IOS, Android ou Web para recebimento das
mensagens (FIREBASE; CLOUD MESSAGING, 2019).
A primeira tarefa é obter o token de permissão do FCM para um determinado
dispositivo. É preciso lidar com isso de maneira diferente em cada plataforma. Em especial,
o Android exige a solicitação de permissão antes de tudo. Essa função retorna uma promise,
então utilizamos async/await. Ou seja, deve-se criar uma função async, e retornar em uma
variável await o retorno desta função (FIREBASE; CLOUD MESSAGING, 2019).
Um usuário pode ter vários dispositivos registrados para notificações, porém é
preciso de um documento que preserve o relacionamento entre o usuário e o dispositivo.
Além disso, um token é apenas uma string, portanto, pode ser usado como o ID do
documento para garantir que cada token tenha apenas um documento (FIREBASE;
CLOUD MESSAGING, 2019).
Notificações push são projetadas para funcionar somente quando o aplicativo está
rodando em segundo plano; elas são recebidas diretamente no dispositivo do usuário e
a exibição do seu conteúdo e as ações são gerenciadas pelo sistema operacional de cada
Capítulo 6. Referencial Teórico 25

plataforma (FIREBASE; CLOUD MESSAGING, 2019).

6.5 Short Message Service


O serviço de mensagens curtas GSM fornece um envio de mensagens sem conexão
com a rede de dados e cada mensagem pode transmitir até 140 octetos (LIN, 1997). As
mensagens curtas são transportadas nos links de sinalização GSM. Assim, as mensagens
podem ser recebidas enquanto os usuários estão em uma ligação.
Segundo Lin (1997), existem dois tipos de serviços de mensagens curtas:

• Cell broadcast: periodicamente fornece mensagens curtas para todos os usuário em


uma determinada área;

• Point-to-point: permite mensagens curtas para um usuário específico; este recurso


GSM pode ser considerado como um serviço de paginação bidirecional aprimorado.

Por ser um recurso nativo do dispositivo e independente de conectividade com a


rede de dados, pode ser usado como forma de notificar usuários em um cenário onde a
aplicação não pode perder sua operabilidade (LIN, 1997).

6.6 Global Positioning System


O Sistema de Posicionamento Global (GPS) com o passar do tempo se tornou uma
tecnologia comumente disponível para medições tridimensionais precisas na Terra. Embora
existam dois sistemas em operação, o sistema russo GLONASS e o GPS dos E.U.A., o
sistema estadunidense é o mais usado. O GPS consiste numa constelação de 24 satélites
(referidos como SVs ou veículos espaciais) que orbitam em seis planos a uma inclinação
de 55o para o plano do equador a cerca de 20.187 km acima da Terra, como destaca a
Figura 6.
Capítulo 6. Referencial Teórico 26

Figura 6 – Os 24 satélites do Sistema Global de Posicionamento

Fonte: (FIX; BURT, 1995)

Os satélites emitem periodicamente sinal de rádio de pulsos curtos para os receptores


GPS. Um receptor GPS recebe o sinal de pelo menos três satélites para calcular a distância
e usa uma técnica de triangulação para calcular suas duas dimensões (latitude e longitude)
ou pelo menos quatro satélites para calcular suas três dimensões (latitude, longitude e
altitude). Depois que um local é calculado, ele pode calcular velocidade média e direção
da viagem. Portanto, o GPS é um tecnologia chave para informar ao dispositivo a sua
posição (FIX; BURT, 1995).

6.7 Google APIs


As APIs do Google são um conjunto de interfaces de programação de aplicativos,
desenvolvidas pelo Google que permitem a comunicação com o Google Services e sua
integração a outros serviços. Exemplos disso incluem Pesquisa, Gmail, Tradutor ou Google
Maps. Aplicativos de terceiros podem usar essas APIs para aproveitar ou ampliar a
funcionalidade dos serviços existentes.
As APIs fornecem funcionalidade como análise, aprendizado de máquina como um
serviço (a API de previsão) ou acesso a dados do usuário (quando a permissão para ler os
dados é fornecida). Outro exemplo importante é um mapa do Google incorporado em um
Capítulo 6. Referencial Teórico 27

site, que pode ser obtido usando a API de mapas estáticos, a API do Google Places ou a
API do Google Earth.

6.7.1 Maps JavaScript API


A Maps JavaScript API permite personalizar mapas com seu próprio conteúdo e
imagens para exibição em páginas da web e dispositivos móveis. Além disso, é possível
utilizar quatro tipos básicos de mapas (roteiro, satélite, híbrido e terreno) que você pode
customizar usando camadas e estilos, controles e eventos, entre outras bibliotecas e serviços
(MAPS; JAVASCRIPT API, 2019).

6.7.2 Geolocation API


A Geolocation API de localização geográfica retorna um local e um raio de precisão
com base nas informações sobre torres de celular e nós de wi-fi que o cliente móvel pode
detectar (GEOLOCATION API, 2019). Esta seção descreve o protocolo usado para enviar
esses dados para o servidor e para retornar uma resposta ao cliente.
A comunicação é feita via HTTPS usando o POST. Tanto a solicitação quanto a
resposta são formatadas como JSON e o tipo de conteúdo de ambos é application/json.
As solicitações de geolocalização são enviadas usando o método POST para a URL,
conforme sintaxe ilustrada na Figura 7 (GEOLOCATION API, 2019).

Figura 7 – URL de solicitação da API

Fonte: (GEOLOCATION API, 2019)

Deve-se especificar uma chave em sua solicitação, agregado a um valor de um


keyparâmetro. Essa chave identifica seu aplicativo para fins de gerenciamento de cotas
(GEOLOCATION API, 2019).

6.7.3 Directions API


A Directions API oferece a capacidade de se acessar rotas de direção, ciclismo,
caminhada e transporte público usando uma solicitação HTTP. Os pontos de referência
oferecem a capacidade de alterar uma rota através de um local específico. Nela pode-se
informar pontos de origens, de destinos e pontos de referência como sequências de texto
por exemplo, “Chicago, IL” ou “Darwin, NT, Austrália” ou como coordenadas de latitude
e longitude (DIRECTIONS API, 2019).
Capítulo 6. Referencial Teórico 28

A API retorna as rotas mais eficientes ao calcular rotas. O tempo de viagem é o


principal fator otimizado, mas a API também pode levar em conta outros fatores, como
distância, número de voltas e muito mais, ao decidir qual rota é a mais eficiente.
A segurança é importante e o HTTPS é recomendado sempre que possível, especial-
mente para aplicativos que incluem dados confidenciais do usuário, como a localização de
um usuário, em solicitações. O uso de criptografia HTTPS torna o aplicativo mais seguro
e mais resistente a invasões ou adulterações (DIRECTIONS API, 2019).
29

7 Metodologia

Esta seção tem o intuito de expor toda a modelagem a ser utilizada no desen-
volvimento do aplicativo, que dar-se-á perante o uso dos frameworks e APIs elucidados
na seção 6. Foi desenvolvido também para esta seção, o Mock-Up do sistema, a fim de
apresentar como o autor pretende projetar as interfaces da aplicação.

7.1 Levantamento de Requisitos


Esta etapa é uma das mais importantes no processo que resultará no desenvolvi-
mento de um software. Nela, são expostas o que se deseja do produto e suas necessidades.

7.1.1 Diagrama Caso de Uso


Na Figura 8 está o diagrama de casos de uso do aplicativo que contém as principais
funcionalidades e a interação dessas funcionalidades com os usuários. Primeiramente
é obrigatório logar-se com uma conta existente, mas caso o utente esteja fazendo uso
da aplicação pela primeira vez, um formulário para submissão de seus dados deve ser
devidamente preenchido, ou também é possível criar uma conta informando um e-mail já
cadastrado na rede social Facebook, ou Google plus.
Feito isso, as demais ações “Logout” (para encerrar a seção de login), “Cadas-
trarUsuarios” (que consiste no registro dos dados dos seus monitores), “DefinirRota” e
“PedirAjuda”, são possíveis de ser acessadas pelo usuário.
Dando enfoque nas duas últimas ações, onde o usuário pode definir a sua rota do
ponto A (latitude e longitude inicial) ao ponto B (latitude e longitude final), e que ao
atingir o destino final, notifica ao seus monitores sua chegada em segurança, todavia, existe
a possibilidade de apenas pressionar o botão de pedido de ajuda, no qual automaticamente
coletará as informações atuais de latitude e longitude e notificará de tempo em tempo os
monitores sobre a localização atual do dispositivo do usuário remetente.
Capítulo 7. Metodologia 30

Figura 8 – Diagrama Caso de Uso

Fonte: Própria, 2019

7.1.2 Modelo de Armazenamento Cloud Firestore


Como foi destacado na seção 6.4.1, os dados dos usuários são armazenados em
documentos, que por sua vez são armazenados em coleções. Pode-se notar na Figura 9
existe uma coleção de nome “Pessoa”, e nela estão registrados campos que guardam valores
a respeito de determinado usuário.
Capítulo 7. Metodologia 31

Figura 9 – Dados de Pessoa no Cloud Firestore

Fonte: Própria, 2019

Dentro do documento desta “Pessoa”, existem duas coleções: “Monitor” e “Rota”.


Todos os dados a respeito de pessoa, devem ser guardados em seu documento, como destaca
a Figura 10.

Figura 10 – Dados do Monitor e da Rota de Pessoa no Cloud Firestore

Fonte: Própria, 2019

Pode-se notar na Figura 11 os valores dos campos do monitor de uma pessoa. O


monitor é um usuário que foi selecionado para acompanhar uma determinada rota da
pessoa.
Capítulo 7. Metodologia 32

Figura 11 – Dados do Monitor no Cloud Firestore

Fonte: Própria, 2019

Já na Figura 12 estão destacados os dados de geolocalização da rota desta pessoa.

Figura 12 – Dados da Rota no Cloud Firestore

Fonte: Própria, 2019

Ou seja, em bancos de dados NoSQL, não existem tabelas e seus relacionamentos.


Todos os dados de uma pessoa são armazenados em seu documento, deixando as consultas
e persistências de dados mais rápidas, e consequentemente nossa aplicação ágil.
Capítulo 7. Metodologia 33

7.1.3 Diagrama de Sequência


Na Figura 13 é elucidado o Diagrama de Sequência para autenticação do usuário
no Cloud Firebase, no momento em que o mesmo fizer “Login”. Os dados serão submetidos
na view da aplicação, que em sequência requisita um processo no model da aplicação,
responsável por ratificar os dados recebidos e devolver o resultado dessa validação, que
caso seja verdadeira, o login é cedido; e caso seja falso, o login é indeferido.

Figura 13 – Diagrama de Sequência para autenticação de usuário com o Firebase

Fonte: Própria, 2019

A ação de “PedirAjuda”, representada de forma sequencial na Figura 14, expõe


todos os processos que devem ser executados, caso haja conexão com a rede de dados, seja
ela Wi-fi ou dados móveis.
O botão de pedido de ajuda, presente na view da aplicação, é como um gatilho,
que no momento em que é ativado, desencadeia vários outros processos automatizados na
aplicação, sem que o usuário interfira em suas execuções. Quando ativado, a view requisita
o processo que verifica a conectividade da aplicação com a rede de dados, que quando
retorna “verdadeiro”, coleta a latitude e longitude atual via GPS, atualiza esses dados de
tempo em tempo, e notifica usuários monitores por meio do Firebase Messaging.
Em contrapartida, caso o processo responsável por verificar a conectividade com a
rede de dados retorne falso, demonstrado na Figura 15, serão enviadas mensagens SMS
diretamente aos monitores, obtendo também os valores de latitude e longitude, porém
esses dados serão atualizados com menor frequencia, tendo em vista que o envio de SMS
Capítulo 7. Metodologia 34

gera custo para o usuário monitorado.

Figura 14 – Diagrama de Sequência para a ação de pedido de ajuda on-line

Fonte: Própria, 2019


Capítulo 7. Metodologia 35

Figura 15 – Diagrama de Sequência para a ação de pedido de ajuda off-line

Fonte: Própria, 2019

7.2 Mock-Up
Esta seção elucida de forma visual, o Mock-Up desenvolvido na ferramenta Figma
(2019) para o aplicativo proposto neste projeto. O termo Mock-Up é a representação do
produto que se deseja implementar.
A Figura 16 retrata a interface no qual o utente criará uma conta na aplicação,
ilustrado na imagem a, e após efetuará login b.
Capítulo 7. Metodologia 36

Figura 16 – Mock-Up: a: Cadastro; b: Login

a: b:
Fonte: Própria, 2019

Após efetuar login, lhe será apresentada a página a da Figura 17, contento um
botão para acesso ao menu, uma searchbar para que seja informado o destino aprazível ao
utente, mostrado na imagem b, que deve também informar quais serão os seus monitores
relativos à esta rota, destacado na imagem c. Entretanto, existe a possibilidade de apenas
acionar o botão relativo a ação de pedir ajuda, que notificará aos seus monitores o pedido
de ajuda.
Capítulo 7. Metodologia 37

Figura 17 – Mock-Up: a: Inicial; b: Ponto A e B; c: Meus monitores

a: b: c:
Fonte: Própria, 2019

É uma obrigatoriedade, que sejam cadastrados os monitores, destacado na Fi-


gura 18c. Para tal, é disposto um formulário, onde os dados informados serão armazenados
no banco de dados. Dois dos campos deste formulário são essenciais, o nome do monitor, e
o número do telefone, pois caso a aplicação esteja sem acesso a rede dados, a aplicação não
obterá sucesso em acessar o Firebase Messaging que reside na nuvem do Cloud Firestore,
então, uma SMS precisa ser enviada para informar aos monitores um possível pedido de
ajuda.
Capítulo 7. Metodologia 38

Figura 18 – Mock-Up: a: Menu; b: Meus monitores; c: Cadastro de monitores

a: b: c:
Fonte: Própria, 2019

A ação de pedido de ajuda, implica em notificar aos monitores. Desse modo, está
exposto na Figura 19 a página de visualização do monitor, onde ao receber uma notificação
e abri-la, lhe será mostrado no mapa a posição atual do remetente do pedido de ajuda.

Figura 19 – Mock-Up: a: Notificação; b: Localização atual

a: b:
Fonte: Própria, 2019
Capítulo 7. Metodologia 39

7.2.1 Cronograma de Atividades


A Tabela 3 apresenta o cronograma das atividades a serem desenvolvidas no PC II.

Tabela 3 – Cronograma de Atividades PC II


Atividades Jul Ago Set Out Nov Dez
Desenvolvimento das interfaces •
Integração com o Firebase Platform •
Autenticação de usuários por diferentes possibilidades •
Desenvolvimento da definição de rota •
Desenvolvimento do acompanhamento da rota pelos monitores •
Desenvolvimento das opções de notificação para os usuários monitores •
Teste da aplicação com usuários •
Aplicação de questionários •
Escrita de Artigo • • • •
Defesa do Projeto de Conclusão II •

Fonte: Própria, 2019


40

Referências

ANGULAR, G. Architecture Overview. 2019. Disponível em: <https://angular.io/guide/


architecture>. Acesso em: 18 mai 2019. Citado na página 20.

ANGULAR, G. Introduction to components. 2019. Disponível em: <https:


//angular.io/guide/architecture-components>. Acesso em: 18 mai 2019. Citado 2 vezes
nas páginas 20 e 21.

ANGULAR, G. Introduction to modules. 2019. Disponível em: <https://angular.io/guide/


architecture-modules>. Acesso em: 18 mai 2019. Citado na página 20.

CERBERUS, L. Protection for your phone, yourself and your loved ones. 2019. Disponível
em: <https://www.cerberusapp.com>. Acesso em: 07 mai 2019. Citado na página 15.

CERQUEIRA, D.; COELHO, D. S. C.; MENDONÇA, H. F. de. Estupro no Brasil:


vítimas, autores, fatores situacionais e evolução das notificações no sistema de saúde
entre 2011 e 2014. [S.l.], 2017. Citado na página 9.

CERQUEIRA, D. C.; LIMA, R. et al. Atlas da violência 2019. Instituto de Pesquisa


Econômica Aplicada (IPEA), 2019. Citado 2 vezes nas páginas 10 e 11.

CERQUEIRA, D. C. et al. Atlas da violência 2018. Instituto de Pesquisa Econômica


Aplicada (IPEA), 2018. Citado 2 vezes nas páginas 9 e 10.

CHISHOLM, D. Brasil tem a maior taxa de transtorno de ansie-


dade do mundo diz oms. 2017. Disponível em: <https://istoe.com.br/
brasil-tem-maior-taxa-de-transtorno-de-ansiedade-do-mundo-diz-oms>. Acesso
em: 15 nov 2018. Citado na página 9.

CLOUD FIRESTORE, G. D. Firebase Cloud Firestore. 2019. Disponível em:


<https://firebase.google.com/docs/firestore>. Acesso em: 16 mai 2019. Citado 2 vezes
nas páginas 22 e 23.

CORDOVA, A. Architecture. 2019. Disponível em: <https://cordova.apache.org/docs/en/


9.x/guide/overview/index.html#architecture>. Acesso em: 18 mai 2019. Citado 2 vezes
nas páginas 21 e 22.

DIRECTIONS API, G. D. Developer Guide. 2019. Disponível em: <https:


//developers.google.com/maps/documentation/directions/start?hl=pt_BR>. Acesso em:
03 mai 2019. Citado 2 vezes nas páginas 27 e 28.

FIGMA, T. Udyat Project. 2019. Disponível em: <https://www.figma.com/file/


IrR94H8KN2zyngIafPGVOnCJ/Udyat>. Acesso em: 16 abr 2019. Citado na página 35.

FIREBASE; AUTHENTICATION, G. D. Firebase Authentication. 2019. Disponível em:


<https://firebase.google.com/docs/auth>. Acesso em: 16 mai 2019. Citado 2 vezes nas
páginas 23 e 24.
Referências 41

FIREBASE; CLOUD MESSAGING, G. D. Firebase Cloud Messaging. 2019. Disponível


em: <https://firebase.google.com/docs/cloud-messaging>. Acesso em: 16 mai 2019.
Citado 2 vezes nas páginas 24 e 25.
FIREBASE, G. D. Firebase. 2019. Disponível em: <https://firebase.google.com/>. Acesso
em: 16 mai 2019. Citado na página 22.
FIX, R. E.; BURT, T. Global positioning system: an effective way to map a small area or
catchment. Earth Surface Processes and Landforms, Wiley Online Library, v. 20, n. 9, p.
817–827, 1995. Citado na página 26.
FORRESTER, R. Forrester works with business and technology leaders to
develop customer-obsessed strategies that drive growth. 2019. Disponível em:
<https://www.forrester.com/home/0,6092,1-0,FF.html>. Acesso em: 02 jun 2019. Citado
na página 19.
GARCIA, L. S. Follow us: aplicativo para compartilhamento de localização em tempo real.
Universidade do Vale do Rio dos Sinos, 2016. Citado na página 15.
GEOLOCATION API, G. D. Developer Guide. 2019. Disponível em: <https:
//developers.google.com/maps/documentation/geolocation/intro?hl=pt_BR>. Acesso
em: 03 mai 2019. Citado na página 27.
IBGE. PNAD Contínua TIC 2017: Internet chega a três em cada qua-
tro domicílios do país. 2018. Disponível em: <https://agenciadenoticias.
ibge.gov.br/agencia-sala-de-imprensa/2013-agencia-de-noticias/releases/
23445-pnad-continua-tic-2017-internet-chega-a-tres-em-cada-quatro-domicilios-do-pais>.
Acesso em: 02 jun 2019. Citado 2 vezes nas páginas 13 e 14.
IONIC; FRAMEWORK. Documentation. What is Ionic Framework? 2019. Disponível em:
<https://ionicframework.com/docs/intro>. Acesso em: 20 fev 2019. Citado na página 20.
LIN, Y.-B. Gsm point-to-point short message service. International Journal of Wireless
Information Networks, Springer, v. 4, n. 4, p. 249–256, 1997. Citado na página 25.
MAPS; JAVASCRIPT API, G. D. Documentation. Overview. 2019. Disponível em:
<https://developers.google.com/maps/documentation/javascript/tutorial>. Acesso em:
03 mai 2019. Citado na página 27.
MORE, K. A.; CHANDRAN, M. P. Native vs hybrid apps. Proceeding of International
Journal of Current Trends in Engineering & Research, p. 563–572, 2016. Citado 4 vezes
nas páginas 17, 18, 19 e 20.
OLIVEIRA, D. D. Filhos desaparecidos: uma história sem fim. 2017.
Disponível em: <https://gauchazh.clicrbs.com.br/geral/noticia/2017/02/
filhos-desaparecidos-uma-historia-sem-fim-9707777.html>. Acesso em: 15 nov
2018. Citado na página 9.
RIBEIRO, E. G. Checkup: aplicativo android para auxiliar a segurança pessoal. Ciência
da Computação-Tubarão, 2018. Citado 2 vezes nas páginas 9 e 15.
SOMBRA, F. F. S. Não cheguei! um aplicativo para aumentar a segurança dos
deslocamentos cotidianos. Universidade Federal do Rio de Janeiro, 2018. Citado na
página 15.