Marcello Camara
Marcello Camara
Marcello Camara
CDD -
1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.1 Introdução Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.2 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.3 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.4 Estrutura do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2 TRABALHOS RELACIONADOS . . . . . . . . . . . . . . . . . . . . 21
2.1 1746 Rio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2 Delegacia Online PCERJ . . . . . . . . . . . . . . . . . . . . . . . . . 24
3 MODELAGEM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.1 Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.1.1 Requisitos funcionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.1.2 Requisitos não funcionais . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.2 Casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.2.1 Descrição dos Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.2.2 Diagrama de casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4 TECNOLOGIAS UTILIZADAS . . . . . . . . . . . . . . . . . . . . . 43
4.1 Ambiente de desenvolvimento . . . . . . . . . . . . . . . . . . . . . . 43
4.2 Controle de versão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.3 Bibliotecas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.3.1 SmartTabLayout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.3.2 JustifiedTextView . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.3.3 Volley . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.3.4 Toasty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.3.5 GmailBackground . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.3.6 StateProgressBar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5 DESENVOLVIMENTO . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.1 Banco de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.1.1 Modelo do banco de dados . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.1.2 API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.2 Implementação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.2.1 Tela de Boas-vindas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.2.2 Tela Inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.2.3 Cadastro de Adesão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.2.4 Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.2.5 Fale Conosco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.2.6 Menu de navegação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.2.7 Tela Inicial do Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.2.8 Iniciar Boletim de Ocorrência . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.2.9 Minha Conta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.2.10 Alterar Senha . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.2.11 Documentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.2.12 Identificação do Boletim de Ocorrência . . . . . . . . . . . . . . . . . . . 69
5.2.13 Dados da Vistoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.2.14 Danos Humanos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.2.15 Relatório Fotográfico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.1 Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
APÊNDICES 79
1 Introdução
1.2 Motivação
A principal motivação surgiu de uma disciplina que o autor deste trabalho cursou
durante o tempo para a graduação, Introdução à Computação Móvel, ministrada pelo
professor Alessandro Copetti, na qual os alunos inscritos deveriam desenvolver aplicativos
móveis, utilizando o Android Studio1 , com temas voltados para a saúde. No desenvolvimento
1
Ambiente de Desenvolvimento Integrado (IDE) oficial para o desenvolvimento de aplicativos Android
18 Capítulo 1. Introdução
1.3 Objetivos
O PRODEC (Programa de Registro de Ocorrências em Defesa Civil) é um sistema
inteiramente voltado para desktop (meio mais tradicional de navegação pela web), sendo
uma tecnologia que a maior parte dos usuários já tem experiência em sua utilização. Com a
diversidade de funcionalidades que a plataforma apresenta, o sistema não foi desenvolvido
com responsividade. Sendo assim, ele não mantém o visual semelhante e agradável de se
utilizar, em quaisquer tamanhos e qualidades de telas que sejam abertos. Desta maneira,
ao utilizar o sistema do PRODEC em dispositivos móveis, a interface apresenta alguns
erros como sobreposição de elementos textuais, imagens e campos de digitação.
Da maneira como o sistema PRODEC está desenvolvido, o Agente de Defesa Civil,
responsável por ir até o local de registro de ocorrência, necessita preencher um formulário
impresso em papel A4 para realizar o registro de ocorrência, vide Documento de Boletim
de Ocorrência e Documento de Dados da Vistoria e Danos Humanos. Após a coleta dos
dados da ocorrência, o agente ainda precisará acessar o sistema do PRODEC e enviar esse
formulário, preenchido em papel A4 impresso, através de um computador, por meio de uma
foto ou escaneamento. Desta maneira, o trabalho torna-se redundante e há a possibilidade
do agente deixar esta tarefa para ser feita depois e/ou até mesmo esquecer de fazê-la.
O objetivo deste trabalho é filtrar as funcionalidades que são de maior importância
no dia a dia do Agente de Defesa Civil, que será o usuário principal, utilizando o aplicativo
1.4. Estrutura do trabalho 19
para realizar uma tarefa de maneira ágil, prática e agradável, visando a eficiência na coleta
dos dados e envio imediato do registro de ocorrência, através do aplicativo desenvolvido.
2 Trabalhos relacionados
Nesta seção, serão apresentados dois trabalhos de aplicativos móveis que contém
as funcionalidades de solicitações ou registros de ocorrências. Outras funcionalidades dos
trabalhos não serão abordadas por não serem relevantes para o atual trabalho. Serão
citados neste projeto os aplicativos 1746 Rio e Delegacia Online PCERJ. Existem vários
outros trabalhos, porém, os projetos apresentados a seguir possuem maior semelhança
com o presente projeto.
Caso o usuário não possua uma conta e não esteja logado, o aplicativo dirá ao
usuário que estão faltando algumas informações para continuar, como mostrado na Figura 3.
Ao selecionar a opção do botão “Informar dados”, o usuário é levado para uma nova tela,
vide Figura 4, para realizar seu cadastro no sistema. As informações que o usuário necessita
preencher são: nome e sobrenome, telefone de contato e seu e-mail. Nesta tela, ainda há
uma opção de entrar em contato com a Central 1746. Basta selecionar o botão “Ligar
para a central 1746” e será aberto a tela de discagem do celular com o número 1746 para
continuar a ligação.
Analisando a funcionalidade de abrir uma nova solicitação, como é o exemplo de
uma reclamação da falta ou problema de iluminação pública na Figura 5, o aplicativo
leva o usuário à uma tela a qual é necessário o preenchimento de alguns dados para que a
solicitação seja aberta:
2
Acedeu a um sistema informático, mediante uma identificação e uma respectiva senha.
2.1. 1746 Rio 23
• Local da solicitação
Endereço físico onde a falta de iluminação pública se encontra, onde deve-se ativar
o GPS do smartphone e utilizá-lo juntamente com o sinal de internet para obter a
aproximação da localização do usuário.
• Complemento do endereço
Espaço onde o usuário pode fornecer alguma informação de referência para encontrar
a localidade da solicitação.
• Descrição do problema
Campo onde o usuário descreve o problema encontrado na iluminação pública, como
por exemplo o número de postes, se são sequenciais ou intercalados e se são postes
altos ou baixos.
• Incluir foto
Opção que permite o usuário utilizar a câmera do smartphone para enviar uma
foto de onde há a falta e/ou problema de iluminação pública, comprovando sua
problemática.
outros motivos.
Segundo (EXTRA, 2016), a necessidade de ampliar a comunicação entre a Institui-
ção e os cidadãos do estado do Rio de Janeiro, tornando o atendimento mais atrativo e
simplificado, levou o DGTIT (Departamento Geral de Tecnologia da Informação e Teleco-
municações) da Instituição a criar a Delegacia Online, que hoje conta com a plataforma
web (<https://dedic.pcivil.rj.gov.br/>) e o aplicativo (Delegacia Online PCERJ) para
maior prestação de serviços.
Na Figura 6, pode-se observar a tela inicial do aplicativo Delegacia Online PCERJ.
O menu localizado na lateral à esquerda, comumente conhecido como Navigation Drawer 4 ,
dá ao usuário as seguintes opções: CAC (Central de Atendimento ao Cidadão), comunicar
ocorrência, extravio de documentos, extravio de celular, encontro de documentos, cancela-
mento de pré-registro, consultas, agendamento e reagendamento, denúncias de bairro e
suporte.
• Local
Menu de seleção (também conhecido como Dropdown Menu), onde o usuário seleciona
o município referente a localidade de denúncia.
• Bairro
• Assunto
• Denúncia
Como terceiro passo, o aplicativo leva o usuário à uma nova tela, mostrado na
Figura 10. Nesta tela, o usuário necessita selecionar o tipo de ocorrência que ele deseja
comunicar, selecionando uma opção através do menu de opções. Os tipos de ocorrência
disponíveis para seleção são os seguintes: Roubo ou furto de documentos, a qual necessita
ser especificado se na subtração do documento foi usado arma de fogo (revólver, pistola) ou
arma branca, se alguém foi ameaçado ou se houve agressão física; Roubo ou furto de objetos,
o qual também necessita da mesma especificação do item anterior; Desaparecimento de
uma pessoa; Encontro de pessoas desaparecidas; Agressão física; Violência doméstica;
Injúria, ameaça ou calúnia; E outros.
Ao prosseguir para o quarto passo, o usuário é levado à mais uma nova tela a
qual ele precisará preencher, com seus dados pessoais, alguns campos, demonstrado na
Figura 11, para criar a comunicação de ocorrência.
De acordo com (MOURA, 2016), quando o usuário faz uma denúncia pelo aplicativo,
é gerado um registro de ocorrência que será validado e assinado pelo delegado (da mesma
maneira como é feito presencialmente nas delegacias) que pode ser acessado e impresso
2.2. Delegacia Online PCERJ 29
em casa. Além disso, durante o processo de denúncia, o usuário escolhe a delegacia mais
próxima onde deseja ser atendido, caso haja a necessidade. Quanto melhor a qualidade
e quantidade de informações descritas pelo usuário no aplicativo, a investigação se dará
a partir daquele ponto descrito. Dependendo da complexidade do caso, ou se houver a
necessidade da representação da pessoa, o delegado comunica à vítima (usuário), que
poderá escolher pelo aplicativo a data e hora, para ir à delegacia.
3 Modelagem
3.1 Requisitos
ID Descrição Prioridade
O sistema deve permitir que o usuário faça o login na
RF04 Alta
aplicação utilizando seu e-mail e senha
O sistema deve permitir que o usuário possa continuar
RF05 Baixa
conectado na aplicação e também finalizar sua sessão
O sistema deve apresentar um menu para navegar entre
RF06 as funcionalidades do sistema: página inicial, iniciar Alta
Boletim de Ocorrência, minha conta e trocar senha.
RF07 O sistema deve permitir ao usuário alterar sua senha Baixa
O sistema deve permitir ao usuário alterar seus dados
RF08 Média
cadastrais
O sistema deve permitir ao usuário criar um Boletim de
RF09 Alta
Ocorrência
O sistema deve lista os documentos recebidos e os
documentos emitidos, separando-os em documentos
RF10 Alta
resolvidos, não resolvidos com prazo não expirado e não
resolvidos com prazo expirado
O sistema deve listar cada documento, informando os
seguintes campos: entrada/emissão, documento,
RF11 Alta
origem/destino, assunto, síntese, número, protocolo e
prazo
O sistema deve exibir a identificação do Boletim de
RF12 Alta
Ocorrência ao interagir com algum documento
O sistema deve permitir que o usuário crie os dados da
RF13 Média
vistoria
O sistema deve permitir que o usuário edite um Boletim
RF14 Média
de Ocorrência existente
O sistema deve permitir que o usuário envie o relatório
RF15 Média
fotográfico da ocorrência
O sistema deve exibir ao usuário uma mensagem caso a
RF16 Baixa
conexão com a internet comprometa a tarefa em questão
Fonte: Próprio autor
Segundo (LEITE, 2000), após definir as tarefas associadas a cada papel do usuário,
o próximo passo é elaborar os casos de uso (use cases). Os casos de uso permitem definir
funções da aplicação que o sistema deverá oferecer para o usuário. Vale ressaltar que os
casos de uso podem ser utilizadas durante a análise e levantamento dos requisitos para
descrever a funcionalidade do sistema.
Ainda de acordo com (LEITE, 2000), o caso de uso especifica o comportamento
do sistema, não descrevendo como o comportamento será implementado. Um caso de uso
representa o que o sistema faz e não como o sistema faz, proporcionando uma visão externa
do sistema.
Cada caso de uso define um requisito funcional do sistema. O caso de uso descreve
um conjunto de ações que o sistema desempenha. Cada sequência representa a interação
de entidades externas e o sistema. Estas entidades são chamadas de atores, que podem ser
usuários ou outros sistemas. No caso do usuário, o ator representa uma função do usuário.
Para realizar o Diagrama de Casos de Uso, utilizou-se do software Astah. O Astah
é uma ferramenta de modelagem UML (Unified Modeling Language), em sua tradução
Linguagem de Modelagem Unificada, que ajuda na tarefa de modelar e documentar os
sistemas orientados a objetos.
1
Versão da API (Application Programming Interface - Interface de Programação de Aplicativos) que
abrange 100% dos dispositivos.
2
Sistema de gerenciamento de banco de dados (SGBD), que utiliza a linguagem SQL (Structured Query
Language) como interface.
34 Capítulo 3. Modelagem
4 Tecnologias Utilizadas
• JDK
Como primeiro passo, foi instalado o JDK (Java Development Kit) – versão 1.8,
que são pacotes de ferramentas básicas, contendo os recursos necessários, como o
compilador e bibliotecas, para criação e execução de programas em Java.
• Android Studio
Após a instalação do JDK, o próximo passo foi instalar o Android Studio – versão 3.1,
que é a ferramenta oficial da Google para desenvolvimento de aplicativos Android.
Por ser uma IDE, ela fornece uma interface gráfica permitindo ao desenvolvedor
executar tarefas de forma prática.
• Android SDK
Instalando o Android Studio, que por padrão instala juntamente o Android Software
Development Kit (Kit de Desenvolvimento de Software para Android), o qual inclui
ferramentas de desenvolvimento, projetos exemplos com código-fonte, entre outros.
44 Capítulo 4. Tecnologias Utilizadas
• AVD
• Git
O software Git – versão 2.17, que será abordado na próxima seção, foi utilizado para
versionamento. O próprio Android Studio tem ferramentas de integração com o Git
para que o desenvolvedor faça o controle de versão do código.
1
Programa, ferramenta ou extensão encaixada a outro programa para adicionar mais funções e recursos.
4.3. Bibliotecas 45
4.3 Bibliotecas
Para utilizar bibliotecas em um projeto do Android Studio, é fundamental conhecer
os conceitos do Gradle. Segundo (DUARTE, 2017), o Gradle é um build system (sistema
de build responsável por construir seus projetos) moderno, que junta as melhores caracte-
rísticas de outros sistemas de build em um só. O Gradle roda sobre a JVM, permitindo um
código ser escrito em Java para executar scripts 2 durante o build, sendo vantajoso para
programadores Java (não obrigando-os a aprender uma nova linguagem). Ele funciona
à base de plugins, então o desenvolver pode criar diversos scripts para que, durante a
compilação, outras tarefas sejam executadas.
Segundo (CORDEIRO, 2015), todo projeto criado no Android Studio é estruturado
para usar o Gradle, sendo um arquivo de configuração para o projeto principal e um para
cada módulo. Os arquivos de configuração são chamados de build.gradle.
Para este trabalho, será apenas adicionado configurações de dependências no arquivo
build.gradle do módulo para que as bibliotecas sejam importadas. Todas as bibliotecas
utilizadas são de código aberto e estão disponíveis na plataforma GitHub, com licença
para uso.
4.3.1 SmartTabLayout
A biblioteca SmartTabLayout, criada por ogaclejapan, em 2015, disponível em
<https://github.com/ogaclejapan/SmartTabLayout>, permite ao desenvolvedor a criação
de um widget 3 para atuar como um menu de títulos customizado, fornecendo feedback
contínuo ao usuário durante a seleção dos itens.
Para utilizar a biblioteca SmartTabLayout, bastou adicionar ao build.gradle as
dependências:
1 implementation ’ com . ogaclejapan . smarttablayout : library :1.6.1 @aar ’
2 implementation ’ com . ogaclejapan . smarttablayout : utils - v4 :1.6.1 @aar ’
Fonte: <https://github.com/ogaclejapan/SmartTabLayout>
2
Códigos que automatizam a execução de tarefas.
3
Componente de interface gráfica do usuário que inclui menus, botões, ícones, barras de rolagem, entre
outros.
46 Capítulo 4. Tecnologias Utilizadas
4.3.2 JustifiedTextView
A justificação de textos requer, no mínimo, API 26 (Android 8.0, Oreo). Como
o aplicativo proposto utiliza a API 14, (Android 4.0, Ice Cream Sandwich) para abran-
ger smartphones com sistemas ainda antigos, o uso da biblioteca JustifiedTextView,
criada por ufo22940268, em 2014, disponível em <https://github.com/ufo22940268/
android-justifiedtextview>, tornou-se fundamental no uso de textos, preenchendo a largura
da tela sem espaços extras no final de cada linha.
Para utilizar a biblioteca JustifiedTextView, bastou adicionar ao build.gradle a
dependência:
1 implementation ’ me . biubiubiu . justifytext : library :1.1 ’
Fonte: <https://github.com/ufo22940268/android-justifiedtextview>
4.3.3 Volley
Desenvolvida pela Google, disponível em <https://github.com/google/volley>, a
Volley é uma biblioteca HTTP (Hypertext Transfer Protocol - Protocolo de Transferência
de Hipertexto) utilizada para fazer conexões de forma simples e rápida, sem a necessidade
de criar várias threads4 secundárias. Integra-se facilmente a qualquer protocolo, dando
suporte para imagens, strings e JSON5 .
Para utilizar a biblioteca Volley, bastou adicionar ao build.gradle a dependência:
1 implementation ’ com . android . volley : volley :1.1.1 ’
4
Forma de um processo se auto dividir em duas ou mais tarefas.
5
JavaScript Object Notation - Notação de Objetos JavaScript
4.3. Bibliotecas 47
4.3.4 Toasty
Toast é um recurso do Android que exibe mensagens rápidas, e temporais, em
uma pequena janela rodapé do aparelho, sendo útil para enviar uma informação ao
usuário. A biblioteca Toasty, criada por Daniel Morales, em 2016, disponível em <https:
//github.com/GrenderG/Toasty>, adiciona maior facilidade de uso de um Toast, podendo
customizar suas cores e adicionar um ícone à mensagem.
Para utilizar a biblioteca Toasty, foi necessário adicionar ao build.gradle a depen-
dência:
1 implementation ’ com . github . GrenderG : Toasty :1.3.0 ’
Fonte: <https://github.com/GrenderG/Toasty>
4.3.5 GmailBackground
Inicialmente desenvolvida por Yesid, em 2015, disponível em <https://github.com/
yesidlazaro/GmailBackground>, tendo como propósito o envio de e-mails, em segundo
plano, sem a interação do usuário. Dessa maneira, utilizando a biblioteca, o usuário não é
redirecionado para um aplicativo de e-mails dedicado, no seu dispositivo móvel, para enviar
sua mensagem de e-mail, como é de forma padrão nos aplicativos. Porém, a biblioteca
foi descontinuada, deixando de receber updates 6 . Então, Luong Vo decide continuar o
projeto de Yesid, deixando a biblioteca, disponível em <https://github.com/luongvo/
GmailBackground>, atualizada até os dias atuais.
Para utilizar a biblioteca GmailBackground, bastou adicionar ao build.gradle a
dependência:
1 implementation ’ com . github . luongvo : GmailBackground :2.1.1 ’
6
Atualização de um dado por algo mais recente e sofisticado.
48 Capítulo 4. Tecnologias Utilizadas
4.3.6 StateProgressBar
A biblioteca StateProgressBar, criada por Kofi Gyan, em 2016, disponível em
<https://github.com/kofigyan/StateProgressBar>, permite separar e executar os vários
estados de transições em uma ProgressBar. Desta maneira, uma tela que contém diveras
informações, pode ser dividida em até 5 (cinco) telas, que serão etapas a serem concluídas,
tornando a tarefa de percorre-las uma a uma atrativa e menos cansativa, informando ao
usuário quantos passos ainda faltam para conclusão.
Para utilizar a biblioteca StateProgressBar, bastou adicionar ao build.gradle a
dependência:
1 implementation ’ com . kofigyan . stateprogressbar : stateprogressbar :1.0.0 ’
Fonte: <https://github.com/kofigyan/StateProgressBar>
49
5 Desenvolvimento
5.1.2 API
de Danos Humanos
12) seção A.12 - Consultar Danos Humanos - Responsável pela busca de um
documento de Danos Humanos
13) seção A.13 - Criar Relatório Fotográfico - Responsável pelo upload de um
arquivo de imagem do Relatório Fotográfico
Para melhor organização e manutenção do projeto, algumas variáveis de acesso
ao banco de dados foram criadas em uma classe, no pacote da aplicação, com todos os
endereços de comunicação com a API desenvolvida.
Cada classe é responsável por controlar seus atributos, sendo eles públicos, privados
ou protegidos (modificadores de acesso que dão visibilidade de acessos às classes). Ao
declarar um atributo como público estático final, o atributo ficará visível à todas as classes
do projeto e têm valor único, sendo impossível alterá-los.
5 public static final String LOGIN = URL + " login . php " ;
6 public static final String READ_BOS = URL + " consultarBOs . php " ;
7 public static final String EDIT_PROFILE = URL + " minhaConta . php " ;
8 public static final String EDIT_PASSWORD = URL + " trocarSenha . php
";
9 public static final String NEW_BO = URL + " criarBO . php " ;
10 public static final String PULL_BO = URL + " resumoBO . php " ;
11 public static final String UPDATE_BO = URL + " updateBO . php " ;
12 public static final String UPLOAD_PHOTO = URL + " uploadFotos . php "
;
13 public static final String R EA D _ DA D O S_ V I ST O R IA = URL + "
co ns ul ta r D a d o s V i s t o r i a . php " ;
14 public static final String N EW _D AD OS _V IS TO RI A = URL + "
criarDad os Vi st or ia . php " ;
15 public static final String R EA D_ DA NO S_ HU MA NO S = URL + "
con sult a r D a n o s H u m a n o s . php " ;
16 public static final String NE W_DANO S_HUMA NOS = URL + "
criarDano sHuman os . php " ;
5.2 Implementação
Nesta seção serão abordadas as telas do aplicativo desenvolvido e suas principais
funcionalidades. Também serão abordados trechos de códigos, quando necessário para
explicação de alguma funcionalidade desenvolvida.
1
Peça de design que identifica ou representa uma entidade (marca de produto ou serviço).
54 Capítulo 5. Desenvolvimento
O próprio Android Studio oferece a classe Handler, que trabalha com threads 2 .
Para executar uma thread com delay 3 no Handler, utilizou-se o método postDelayed(),
localizado na linha 7 da tela de boas-vindas. Este método recebe uma interface Runnable,
que é a thread que será executada após um determinado tempo (delay), em milissegundos.
3 @Override
4 protected void onCreate ( Bundle s av ed In st an ce Sta te ) {
5
19 }
20
21 }
Tela de boas-vindas
à direita. Então, para justificar o texto de apresentação do aplicativo, da Tela Inicial, foi
utilizada a biblioteca JustifiedTextView.
5.2.4 Login
Todo processo de comunicação com a API no aplicativo, através de um web service,
utiliza a biblioteca Volley, abordada anteriormente. Nesta subseção, será abordado como é
realizada esta requisição, sendo a mesma para todas as outras que necessitam criar ou
alterar dados. A diferença entre as demais requisições são a quantidade de parâmetros
passadas e a forma de leitura do arquivo JSON.
Para entendimento das explicações a seguir, a requisição HTTP será utilizada como
exemplo de utilização da biblioteca citada acima. Como o trecho de código é extenso, este
será o único exemplo de web service.
Ao realizar requisições web services deve-se utilizar a classe ResquestQueue, que
utiliza uma nova thread responsável pelo gerenciamento das requisições. Uma instância da
classe RequestQueue deve ser criada, como mostrado na linha 73, através da classe Volley,
utilizando o método newRequestQueue. Após criar a instância da classe ResquestQueue,
deve-se utilizar um objeto do tipo Request como parâmetro para o método add da classe
ResquestQueue, demonstrado na linha 74.
Um ProgressDialog, que é um elemento de interação com o usuário, é exibido
58 Capítulo 5. Desenvolvimento
para indicar que há algo sendo processado, demonstrado na linha 5. Esta é uma boa
estratégia para impedir que o usuário realize outras operações enquanto os dados estão
sendo processados.
12 progressDialog . dismiss () ;
13 try {
14
27 }
28
35 if (! checkBox . isChecked () ) {
36 // Vari á vel que controla se h á
necessidade de realizar logout da
sess ã o ao fechar o app na pr ó xima
tela
37 PRODEC . putExtra ( " logout " , true ) ;
38 }
39 startActivity ( PRODEC ) ;
40 finish () ;
41 } else {
42 // Caso a resposta n ã o seja " sucesso " =
"1"
43 Toasty . warning ( this , " Login ou senha
incorretos . " , Toast . LENGTH_SHORT , true )
. show () ;
44 }
45
46 } catch ( JSONException e ) {
47 e . printStackTrace () ;
48 Toasty . error ( this , " Login ou senha incorretos
. " , Toast . LENGTH_LONG , true ) . show () ;
49 }
50 }
51 },
52
71 };
72
76 }
Requisição HTTP
Esta é uma tela na qual o usuário pode interagir com o administrador do sistema,
enviando uma mensagem por escrito. Para sua implementação, utilizou-se a biblioteca
GmailBackground, abordada anteriormente.
A biblioteca permite o envio de mensagens de e-mail direto pelo aplicativo de-
senvolvido, sem que haja o redirecionamento para um aplicativo de envio de e-mails no
smartphone do usuário, através de configurações SMTP (Simple Mail Transfer Protocol -
Protocolo Simples de Transferência de Correio) do Gmail 4 . Para isso, foi necessário deixar
um e-mail do Gmail, com login e senha no código, disponível para o envio das mensagens.
4
Serviço de e-mails da Google. É comum ver smartphones com sistema operacional Android possuir
este aplicativo pré-instalado.
5.2. Implementação 61
9 f ra g m e nt T r an s a ct i o n . commit () ;
10 break ;
11 }
12 case R . id . nav_BO : {
13 P r o d e c I n i c i a r B O F r a g m e n t p r o d e c I n i c i a r B O F r a g m e n t = new
P r o d e c I n i c i a r B O F r a g m e n t () ;
14 F ra g m e nt T r an s a ct io n f r ag m e nt T r an s a ct i o n =
g e t S u p p o r t F r a g m e n t M a n a g e r () . beginTransaction () ;
15 f ra g m e nt T r an s a ct io n . replace ( R . id . frameLayout ,
prodecIniciarBOFragment );
16 f ra g m e nt T r an s a ct io n . commit () ;
17 break ;
18 }
19 case R . id . nav_conta : {
20 ProdecMinhaContaFragment prodecMinhaContaFragment =
new P r o d e c M i n h a C o n t a F r a g m e n t () ;
21 F ra g m e nt T r an s a ct io n f r ag m e nt T r an s a ct i o n =
g e t S u p p o r t F r a g m e n t M a n a g e r () . beginTransaction () ;
22 f ra g m e nt T r an s a ct io n . replace ( R . id . frameLayout ,
p r o d e c M i n h a C o nt a F r a g m e n t ) ;
23 f ra g m e nt T r an s a ct io n . commit () ;
24 break ;
25 }
26 case R . id . nav_senha : {
27 ProdecTrocarSenhaFragment prodecTrocarSenhaFragment =
new P r o d e c T r o c a r S e n h a F r a g m e n t () ;
28 F ra g m e nt T r an s a ct io n f r ag m e nt T r an s a ct i o n =
g e t S u p p o r t F r a g m e n t M a n a g e r () . beginTransaction () ;
29 f ra g m e nt T r an s a ct io n . replace ( R . id . frameLayout ,
prodecTrocarSenhaFragment );
30 f ra g m e nt T r an s a ct io n . commit () ;
31 break ;
32 }
33 }
34
39 }
Menu de navegação
5.2. Implementação 63
1 < animation - list xmlns : android = " http :// schemas . android . com / apk / res
/ android " >
2
Animação da circunferência
Nesta tela, é possível que o usuário altere seus dados cadastrais no sistema do
PRODEC. Não foi implementada uma validação do número do CPF, pois o sistema já
realiza esta verificação.
66 Capítulo 5. Desenvolvimento
Para esta tela, assim como qualquer outra que requer o preenchimento de um
endereço de e-mail, há uma validação do campo preenchido. O método isValidEmail(), do
trecho de código de validação de e-mail, exemplifica este processo descrito acima.
7 }
Validação de e-mail
Uma simples validação de campos foi implementada para esta tela, permitindo que
a senha só seja alterada caso a nova senha seja diferente da senha antiga e que a nova
senha seja a mesma preenchida nos campos ‘Nova senha’ e ‘Repita nova senha’.
5.2.11 Documentos
É possível navegar até esta tela pressionando uma das circunferências da tela inicial
do sistema, em verde, amarelo ou vermelho (se não houver nenhum documento para ser
exibido, o clique não abre a tela de documentos).
Para implementação desta tela, foi utilizado o widget RecyclerView, responsável
por carregar cada um dos itens de uma lista, para exibir os documentos de Boletim de
Ocorrência.
O trecho de código da configuração do Adapter para o RecylerView demonstra a
utilização de um adapter que será utilizado para criação do RecyclerView. O adapter é
uma classe responsável por associar a lista de conteúdo à tela correspondente, onde cada
objeto da lista será um item na lista.
O ViewHolder, mostrado na linha 36, é a parte visual de cada item da lista, que
68 Capítulo 5. Desenvolvimento
será replicada para todos elementos (ficando dentro do adapter, na estrutura acima).
11 @NonNull
12 @Override
13 public ListBOAdapter . ViewHolder o nC re at eV iew Ho ld er ( @NonNull
ViewGroup parent , int viewType ) {
5.2. Implementação 69
26 @Override
27 public void onBindViewHolder ( @NonNull ListBOAdapter .
ViewHolder holder , int position ) {
28 // Exibe de cada item da lista
29 }
30
31 @Override
32 public int getItemCount () {
33 return listaBOS . size () ;
34 }
35
Ambas as ações descritas acima, irão redirecionar o usuário à esta tela, com o
resumo dos dados do Boletim de Ocorrência em questão.
Nesta tela, também é possível editar o documento de Boletim de Ocorrência, no
botão ‘Solicitação’, criar um documento de Dados da Vistoria, no botão ‘Dados da Vistoria’,
criar um documento de Danos Humanos, no botão ‘Danos Humanos’ e enviar arquivos de
imagem, no botão ‘Relatório Fotográfico’.
5 if ( num . isEmpty () ) {
6 return 0;
7 }
8 else {
9 return Integer . parseInt ( num ) ;
10 }
11 }
Método para retornar um número inteiro
Diferente dos webservices que são realizados em telas anteriores, este necessita
que a imagem seja compactada em bytes e convertida para o formato String, utilizando o
Base64 como criptografia. Desta maneira, a imagem pode ser enviada para o banco de
dados.
O trecho de código de codificação de uma imagem no formato Bitmap demonstra
esta mudança no webservice para o processo descrito acima.
6 Conclusão
Referências
SCHMITZ, D. Tudo que você queria saber sobre Git e GitHub, mas ti-
nha vergonha de perguntar. 2015. Disponível em: <https://tableless.com.br/
tudo-que-voce-queria-saber-sobre-git-e-github-mas-tinha-vergonha-de-perguntar/>.
Acesso em: 29 ago. 2018. Citado na página 44.
A.1 Conexão
connect.php
1 <? php
2
7 ?>
Fonte: Próprio autor
A.2 Login
login.php
1 <? php
2
14 $result = array () ;
15
18 // E - mail encontrado
19
28 $index [ ’ id ’] = $row [ ’ id ’ ];
29 $index [ ’ nome ’] = $row [ ’ nome ’ ];
30 $index [ ’ cpf ’] = $row [ ’ cpf ’ ];
31 $index [ ’ matricula ’] = $row [ ’ matricula ’ ];
32 $index [ ’ email ’] = $row [ ’ email ’ ];
33 $index [ ’ funcao ’] = $row [ ’ funcao ’ ];
34 $index [ ’ orgao ’] = $row [ ’ orgao ’ ];
35 $index [ ’ permissao ’] = $row [ ’ permissao ’ ];
36 $index [ ’ vistoriante ’] = $row [ ’ vistoriante ’ ];
37
43 } else {
44
50 }
51 }
52 else {
53 // E - mail incorreto / inexistente
54
61 ?>
5 $id = $_POST [ ’ id ’ ];
6 $nome = $_POST [ ’ nome ’ ];
7 $cpf = $_POST [ ’ cpf ’ ];
8 $matricula = $_POST [ ’ matricula ’ ];
9 $email = $_POST [ ’ email ’ ];
10 $funcao = $_POST [ ’ funcao ’ ];
11 $orgao = $_POST [ ’ orgao ’ ];
12 $permissao = $_POST [ ’ permissao ’ ];
13 $vistoriante = $_POST [ ’ vistoriante ’ ];
14
24 } else {
25 $result [ " sucesso " ] = " 0 " ;
26 echo json_encode ( $result ) ;
27 }
28 mysqli_close ( $conn ) ;
29 }
30 else {
31 $result [ " sucesso " ] = " 0 " ;
32 echo json_encode ( $result ) ;
33 }
34
35 ?>
Fonte: Próprio autor
84 APÊNDICE A. API desenvolvida
5 $id = $_POST [ ’ id ’ ];
6 $senhaAntiga = $_POST [ ’ senhaAntiga ’ ];
7 $senhaNova = $_POST [ ’ senhaNova ’ ];
8
1 <? php
2
32 $result = array () ;
33 $result [ " sucesso " ] = " 1 " ;
34 $result [ " idBO " ] = mysqli_insert_id ( $conn ) ;
35 echo json_encode ( $result ) ;
36
37 }
38 else {
39
43 }
44 mysqli_close ( $conn ) ;
45 }
46
47 ?>
Fonte: Próprio autor
11 $result = array () ;
12
22 }
23
26 } else {
27
31 }
32
33 mysqli_close ( $conn ) ;
34
35 }
36
37 ?>
Fonte: Próprio autor
5 $id = $_POST [ ’ id ’ ];
6
13 $result = array () ;
14
24 }
25
28 } else {
29
33 }
34
35 mysqli_close ( $conn ) ;
36 }
37
38 ?>
Fonte: Próprio autor
5 $id = $_POST [ ’ id ’ ];
6 $data = $_POST [ ’ data ’ ];
7 $hora = $_POST [ ’ hora ’ ];
8 $solicitante = $_POST [ ’ solicitante ’ ];
9 $telefone = $_POST [ ’ telefone ’ ];
10 $endereco = $_POST [ ’ endereco ’ ];
11 $numero = $_POST [ ’ numero ’ ];
12 $complemento = $_POST [ ’ complemento ’ ];
13 $bairro = $_POST [ ’ bairro ’ ];
14 $ptreferencia = $_POST [ ’ ptreferencia ’ ];
15 $divadm = $_POST [ ’ divadm ’ ];
16 $responsavel = $_POST [ ’ responsavel ’ ];
17 $outra = $_POST [ ’ outra ’ ];
18 $autorBO = $_POST [ ’ autorBO ’ ];
A.8. Alterar Boletim de Ocorrência 89
34 $result = array () ;
35 $result [ " sucesso " ] = " 1 " ;
36 echo json_encode ( $result ) ;
37
38 }
39 else {
40
44 }
45 mysqli_close ( $conn ) ;
46 }
47
48 ?>
1 <? php
2
5 $id = $_POST [ ’ id ’ ];
6 $responsavel = $_POST [ ’ responsavel ’ ];
7 $cpf = $_POST [ ’ cpf ’ ];
8 $email = $_POST [ ’ email ’ ];
9 $telefone = $_POST [ ’ telefone ’ ];
10 $razaosocial = $_POST [ ’ razaosocial ’ ];
11 $cargo = $_POST [ ’ cargo ’ ];
12 $cnpj = $_POST [ ’ cnpj ’ ];
13 $tel = $_POST [ ’ tel ’ ];
14 $pavimentos = $_POST [ ’ pavimentos ’ ];
15 $rg1 = $_POST [ ’ rg1 ’ ];
16 $rg2 = $_POST [ ’ rg2 ’ ];
17 $rg3 = $_POST [ ’ rg3 ’ ];
18 $rg4 = $_POST [ ’ rg4 ’ ];
19 $rg5 = $_POST [ ’ rg5 ’ ];
20 $rg6 = $_POST [ ’ rg6 ’ ];
21 $rg7 = $_POST [ ’ rg7 ’ ];
22 $rg8 = $_POST [ ’ rg8 ’ ];
23 $idbo = $_POST [ ’ idbo ’ ];
24
30 $result = array () ;
31 $result [ " sucesso " ] = " 1 " ;
32 echo json_encode ( $result ) ;
33
34 }
35 else {
36
43 ?>
Fonte: Próprio autor
5 $id = $_POST [ ’ id ’ ];
6
24 } else {
25
29 }
30 mysqli_close ( $conn ) ;
31 }
32
33 ?>
Fonte: Próprio autor
5 $id = $_POST [ ’ id ’ ];
6 $parcial1 = $_POST [ ’ parcial1 ’ ];
7 $parcial2 = $_POST [ ’ parcial2 ’ ];
8 $parcial3 = $_POST [ ’ parcial3 ’ ];
9 $parcial4 = $_POST [ ’ parcial4 ’ ];
10 $parcial5 = $_POST [ ’ parcial5 ’ ];
11 $parcial6 = $_POST [ ’ parcial6 ’ ];
12 $fatal1 = $_POST [ ’ fatal1 ’ ];
13 $fatal2 = $_POST [ ’ fatal2 ’ ];
14 $fatal3 = $_POST [ ’ fatal3 ’ ];
15 $fatal4 = $_POST [ ’ fatal4 ’ ];
16 $fatal5 = $_POST [ ’ fatal5 ’ ];
17 $fatal6 = $_POST [ ’ fatal6 ’ ];
18 $desabrigados1 = $_POST [ ’ desabrigados1 ’ ];
19 $desabrigados2 = $_POST [ ’ desabrigados2 ’ ];
20 $desabrigados3 = $_POST [ ’ desabrigados3 ’ ];
21 $desabrigados4 = $_POST [ ’ desabrigados4 ’ ];
22 $desabrigados5 = $_POST [ ’ desabrigados5 ’ ];
23 $desabrigados6 = $_POST [ ’ desabrigados6 ’ ];
24 $desalojados1 = $_POST [ ’ desalojados1 ’ ];
25 $desalojados2 = $_POST [ ’ desalojados2 ’ ];
A.11. Criar Danos Humanos 93
47 $result = array () ;
48 $result [ " sucesso " ] = " 1 " ;
49 echo json_encode ( $result ) ;
50
51 }
52 else {
53
57 }
58
59 mysqli_close ( $conn ) ;
60
61 }
62
63 ?>
Fonte: Próprio autor
3 $id = $_POST [ ’ id ’ ];
4
12
13 $result = array () ;
14
24 }
25
28 } else {
29
33 }
34
35 mysqli_close ( $conn ) ;
36
37 }
38
39 ?>
Fonte: Próprio autor
5 $id = $_POST [ ’ id ’ ];
6 $photo = $_POST [ ’ photo ’ ];
7
16 $result = array () ;
17
25 } else {
26
32 } else {
33
37 }
38
39 mysqli_close ( $conn ) ;
40
41 }
42
43 ?>
Fonte: Próprio autor
Anexos
99
Fonte: <http://www.prodec.defesacivil.rj.gov.br/>
100 ANEXO A. Plataforma do PRODEC
Fonte: <http://www.prodec.defesacivil.rj.gov.br/>
101
Fonte: <http://www.prodec.defesacivil.rj.gov.br/>
102 ANEXO A. Plataforma do PRODEC
Fonte: <http://www.prodec.defesacivil.rj.gov.br/>
103
Fonte: <http://www.prodec.defesacivil.rj.gov.br/>
104 ANEXO A. Plataforma do PRODEC
Fonte: <http://www.prodec.defesacivil.rj.gov.br/>
105
Fonte: <http://www.prodec.defesacivil.rj.gov.br/>
Fonte: <http://www.prodec.defesacivil.rj.gov.br/>
106 ANEXO A. Plataforma do PRODEC
Fonte: <http://www.prodec.defesacivil.rj.gov.br/>
Fonte: <http://www.prodec.defesacivil.rj.gov.br/>
107
Fonte: <http://www.prodec.defesacivil.rj.gov.br/>
Fonte: <http://www.prodec.defesacivil.rj.gov.br/>
108 ANEXO A. Plataforma do PRODEC
Fonte: <http://www.prodec.defesacivil.rj.gov.br/>
ANEXO B – Documento de Boletim de
Ocorrência
CABEÇALHO DO ÓRGÃO
RODAPÉ DO ÓRGÃO
ANEXO C – Documento de Dados da
Vistoria e Danos Humanos
CABEÇALHO DO ÓRGÃO
RODAPÉ DO ÓRGÃO