tg-pedro-final-finak

Prévia do material em texto

PEDRO CARVALHO GRASSETTI 
 
 
 
 
 
 
 
Desenvolvimento do protótipo de um APP Android para Automação Comercial de 
Fichas de Consumo 
 
 
 
 
 
 
 
Sorocaba 
2018 
 
 
PEDRO CARVALHO GRASSETTI 
 
 
 
 
DESENVOLVIMENTO DO PROTÓTIPO DE UM APP ANDROID PARA 
AUTOMAÇÃO COMERCIAL DE FICHAS DE CONSUMO 
 
 
 
 
Trabalho de Conclusão de Curso 
apresentado ao Instituto de Ciência e 
Tecnologia de Sorocaba, Universidade 
Estadual Paulista (UNESP), como parte 
dos requisitos para obtenção do grau de 
Bacharel em Engenharia de Controle e 
Automação. 
 
Orientador: Prof. Dr. Galdenoro Botura Jr. 
 
 
 
 
 
 
 
Sorocaba 
2018 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Ficha catalográfica elaborada pela Biblioteca da Unesp 
Instituto de Ciência e Tecnologia – Câmpus de Sorocaba 
 
 
Grassetti, Pedro Carvalho. 
 
 Desenvolvimento do protótipo de um app Android para 
automação comercial de fichas de consumo / Pedro Carvalho 
Grassetti, 2018. 
 66 f.: il. 
 
 Orientador: Galdenoro Botura Junior. 
 
 Trabalho de Conclusão de Curso (Graduação) – Universidade 
Estadual Paulista "Júlio de Mesquita Filho". Instituto de Ciência e 
Tecnologia (Câmpus de Sorocaba), 2018. 
 
 1. Automação comercial. 2. Android. 3. Android Studio. 4. 
Automação bares e restaurantes. I. Universidade Estadual Paulista 
"Júlio de Mesquita Filho". Instituto de Ciência e Tecnologia (Câmpus 
de Sorocaba). II. Título. 
 
 
 
 
Bibliotecário responsável: Bruna B. Guimarães – CRB 8/8855 
 
 
AGRADECIMENTOS 
 
Aos meus pais, meu irmão e namorada por todo o apoio durante minha formação 
acadêmica. 
Ao Prof. Dr. Galdenoro Botura Jr. pela atenção e disponibilidade em todas as etapas 
de desenvolvimento do trabalho. 
Aos meus amigos e colegas de curso por todo o tempo da graduação e pela 
superação dos grandes desafios apresentados ao longo do curso. 
Ao corpo docente do curso de engenharia de controle e automação e também à todos 
os colaboradores da Unesp Campus de Sorocaba pelos aprendizados durante o período de 
graduação. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
RESUMO 
 Com o avanço da tecnologia, os dispositivos móveis têm se tornado um 
componente muito importante dentro da automação comercial, deixando os sistemas mais 
eficientes e mais baratos. Isso por causa da quantidade imensa de funcionalidades e 
possibilidades de integração que os sistemas operacionais e hardwares possuem. Devido 
a necessidade de realizar uma automação comercial de um estabelecimento no ramo de 
bares e restaurantes, o objetivo desse projeto foi apresentar um protótipo para solução 
fácil e robusta da automação de fichas de consumo. Para a realização das etapas de 
desenvolvimento, utilizou-se a plataforma Android juntamente com o ambiente de 
programação Android Studio, também fornecido pelo Google. Esse projeto foi 
desenvolvido com o intuito de oferecer um controle maior ao dono do estabelecimento, 
diminuir custos operacionais de recursos humanos e deixar a automação do controle da 
venda de uma ficha de consumo mais rápida, o que pode determinar, portanto, um 
aumento do consumo médio dos consumidores. Com a automação, o consumo tende a 
aumentar e o estabelecimento ganhar mais eficiência e, no mercado, quando falamos de 
eficiência estamos falando de redução de custos e consequentemente aumento da 
lucratividade. Esse trabalho foi projetado e desenvolvido 100% para plataforma Android, 
porém toda a inteligência aplicada e estrutura pode ser utilizada em um aplicativo para 
celulares com sistema iOS. 
Palavras-chave: Automação Comercial. Android. Android Studio. Automação 
Bares e Restaurantes. 
 
 
 
 
 
 
 
 
 
ABSTRACT 
Mobile devices have become, with the advancement of technology, a very important 
piece in the commercial automation area, making the systems more efficient and cheaper. 
This is explained by the huge quantity of functions and different ways of integration with 
other systems. Given the need of a commercial automation of a business in the bars and 
restaurants sector, the main objective of this project was to present an easy and robust 
solution for this system. To perform these steps the Android platform and Android Studio, 
also provided by Google, were used. , provided by Google, was used. This Project was 
developed to offer greater control to the owner of the establishment, reduce operational 
costs of human resources and leave the purchase of a faster consumption sheet, which 
can therefore determine an increase in average consumer consumption. With this 
automation system, the amount of consumption tends to increase causing more efficiency 
for the shop and when we talk about efficiency, we are saying that the profits are 
increasing. This work was designed and developed 100% for Android platform, however 
all applied intelligence and structure can be used in an app for mobile phones with iOS 
system. 
Keywords: Commercial Automation. Android. Android Studio. Bars and Restaurants 
Automation. 
 
 
 
 
 
 
 
 
 
 
 
 
 
LISTA DE FIGURAS 
Figura 1 - Máquina Registradora ................................................................................................ 12 
Figura 2 - Código de Barras Linear.............................................................................................. 12 
Figura 3 - Foto do aparelho T-Mobile G1. Primeiro a possuir Android ..................................... 14 
Figura 4 - Pesquisa Gartner. ....................................................................................................... 15 
Figura 5 - Camadas da Plataforma Android ............................................................................... 17 
Figura 6 - Opções de conexões para login do usuário ............................................................... 23 
Figura 7 - Exemplo banco de dados Firebase. ........................................................................... 24 
Figura 8 - Modelo Venda de Fichas de Papel ............................................................................. 26 
Figura 9 - Aplicativo utilizado para referência ........................................................................... 28 
Figura 10 - Modelo do Aplicativo STUE ...................................................................................... 29 
Figura 11 - Estrutura Básico do Aplicativo do Projeto ............................................................... 31 
Figura 12 - Página WEB Android Studio ................................................................................... 333 
Figura 13 - Tela Login .................................................................................................................. 35 
Figura 14 - Tela 1 Cadastro - Senha e Usuário ........................................................................... 36 
Figura 15 - Tela 2 Cadastro - Informações Pessoais .................................................................. 36 
Figura 16 - Produtos disponíveis venda Cervejas ...................................................................... 37 
Figura 17 - Produtos Disponíveis Dose ...................................................................................... 37 
Figura 18 - Produtos Disponíveis Refrigerantes ........................................................................ 38 
Figura 19 - Produtos Cadastrados .............................................................................................. 38 
Figura 20 - Aba Fichas Disponíveis ............................................................................................. 39 
Figura 21 - Aba produtos já retirados (Histórico) ...................................................................... 39 
Figura 22 - Tela de administrador para iniciar leitura ............................................................... 40 
Figura 23 - Tela de Administradorpara confirmação de dados do produto ............................ 40 
Figura 24 - Estrutura Macro do Banco de Dados ....................................................................... 42 
Figura 25 - Estrutura Nó Venda .................................................................................................. 42 
Figura 26 - Estrutura Fichas Disponíveis .................................................................................... 43 
Figura 27 - Estrutura Fichas Histórico ........................................................................................ 45 
Figura 28 - Estrutura Informações Usuários .............................................................................. 46 
Figura 29 - Celular Motorola G5 ................................................................................................. 47 
Figura 30 - Telas cadastro do usuário Pedro .............................................................................. 48 
Figura 31 - Tela Cadastro Usuário Bárbara ................................................................................ 49 
Figura 32 - Tela de gestão dos Usuários..................................................................................... 50 
Figura 33 - Estrutura Banco de Dados Usuários ........................................................................ 50 
Figura 34 - Tela Produtos Usuários Teste .................................................................................. 51 
Figura 35 - Estrutura Banco de Dados Produtos Teste .............................................................. 52 
Figura 36 - Telas de Navegação Usuários ................................................................................... 53 
Figura 37 - Telas de Produtos Disponíveis Usuários Testes ...................................................... 53 
Figura 38 - QR Code gerado para retirada do produto .............................................................. 54 
Figura 39 - Tela do administrador para validar um QR Code .................................................... 55 
Figura 40 - Leitor de QR ativado para uma leitura .................................................................... 55 
Figura 41 - Tela de conferência dos dados do produto ............................................................. 56 
Figura 42 - Tela dos itens já retirados - Histórico ...................................................................... 57 
 
 
 
 LISTA DE ABREVIATURAS E SIGLAS 
API – Application Programming Interface 
APP - Aplicativo 
OHA – Open Handset Aliance 
PDV – Ponto de Venda 
QoS – Quality of Service 
SLA – Service Level Agreement 
SMS – Show Message Service 
SO – Sistema Operacional 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
SUMÁRIO 
 
1. INTRODUÇÃO ............................................................................................................. 11 
1.1. Contextualização ....................................................................................................... 11 
1.1.1. Automação Comercial ....................................................................................... 11 
1.1.2. Android e Dispositivos Móveis ......................................................................... 13 
1.2. Objetivos .................................................................................................................... 16 
2. FUNDAMENTAÇÃO TEÓRICA ............................................................................... 17 
2.1. Estrutura Android..................................................................................................... 17 
2.1.1. Núcleo Linux ...................................................................................................... 17 
2.1.2. Bibliotecas .......................................................................................................... 18 
2.1.3. Tempo de Execução (Android Runtime) ......................................................... 18 
2.1.4. Framework de Aplicativos ................................................................................ 19 
2.1.5. Aplicações ........................................................................................................... 19 
2.2. Computação em Nuvem ............................................................................................ 19 
2.2.1. Serviço sob demanda ......................................................................................... 20 
2.2.2. Independência de localização ........................................................................... 21 
2.2.3. Elasticidade e Escalabilidade ........................................................................... 21 
2.2.4. Medição dos Serviços ........................................................................................ 21 
2.3. Google Firebase ......................................................................................................... 22 
2.3.1. Login de Usuários (Authentication) ................................................................. 23 
2.3.2. Realtime Database ............................................................................................. 23 
2.4. Proposição .................................................................................................................. 25 
2.5. Metodologia ............................................................................................................... 25 
2.6. Definição do Escopo do Projeto ............................................................................... 27 
2.6.1. Cliente (1) ........................................................................................................... 29 
2.6.2. Realizando o Pedido e Pagamento (2) .............................................................. 29 
2.6.3. Envio do Pedido (3) ........................................................................................... 30 
2.6.4. Entrega do Pedido (4) ....................................................................................... 30 
3. DESENVOLVIMENTO ............................................................................................... 33 
3.1. Preparação do Ambiente Android ........................................................................... 33 
3.2. Estrutura Geral das Telas ........................................................................................ 34 
3.3. Tela Inicial de Login ................................................................................................. 34 
3.4. Telas Cadastro Usuário ............................................................................................ 35 
3.5. Tela Compra Ficha.................................................................................................... 36 
3.6. Telas Gestão de Fichas .............................................................................................. 38 
 
 
3.7. Telas Retirada Produto Balcão ................................................................................ 39 
3.8. Estrutura Banco de Dados ........................................................................................ 41 
4. Resultados e Discussões ................................................................................................ 47 
5. CONCLUSÃO ............................................................................................................... 58 
REFERÊNCIAS ...................................................................................................................... 59 
ANEXOS.................................................................................................................................. 61 
 
 
11 
 
1. INTRODUÇÃO 
1.1. Contextualização 
1.1.1. Automação Comercial 
 
 Com o avanço da tecnologia das redes móveis, o acesso a informação tem tornado 
o consumidor, de maneira geral, mais exigente e, de certa, forma impacientena compra 
de qualquer produto ou serviço. Ao invés de esperar por horas na fila de um 
supermercado, ou mesmo em caixas de bancos, hoje, em poucos minutos, é possível 
realizar pagamentos de contas e até mesmo abastecer a geladeira de maneira fácil e rápida. 
Assim, essa agilidade provoca uma série de mudanças em todo o mercado, 
alterando desde a estrutura de recursos humanos da empresa até o relacionamento 
consumidor-fornecedor. Dessa maneira a constante evolução da tecnologia passou a não 
ser mais um diferencial, e sim uma questão de sobrevivência no mercado (CEPE, MAIA 
2017). 
Todo o processo repetitivo básico de qualquer empresa, como compra, venda e 
controle de estoque, por exemplo, que antigamente era feito de forma manual, cada vez 
mais vem se tornando mais automática, definindo o que conhecemos por Automação 
Comercial. (DOZE TI, 2018). 
A automação teve seu marco inicial com a invenção das chamadas máquinas 
registradoras, que não eram nem um pouco parecidas com o que temos hoje nas lojas. 
Essas máquinas eram utilizadas para realizar a somatória dos produtos, sumarizar as 
vendas e facilitar o trabalho do operador de caixa. 
Nos anos 90, as primeiras integrações surgiram o que possibilitou a troca mais 
eficiente de informações e também uma segurança e confiabilidade de armazenamento de 
dados. (A NOVA ERA DA AUTOMAÇÃO COMERCIAL, 2017) 
12 
 
 
Figura 1 - Máquina Registradora 
A partir dessa integração dos dados, apareceram os primeiros sistemas que 
consideravam os PDVs (Pontos de Vendas) nos estabelecimentos. Esses terminais 
trabalhavam apenas como um ponto de captura das informações dos produtos, que com o 
passar do tempo começaram a contar com o leitor de código de barras para facilitar esse 
lançamento. Devido ao grande sucesso desse tipo de terminal, as empresas investiram em 
uma padronização internacional de identificação dos produtos. Na figura 2, temos um 
exemplo de um modelo linear do código de barras. Atualmente, a tecnologia da 
padronização atingiu o modelo do QR CODE, do inglês Quick Response. (PINTO, 2018). 
 
Figura 2 - Código de Barras Linear 
Acompanhando toda essa evolução na venda e controle das informações em 
ambiente comercial, o setor de bares e restaurantes também sofreu gigantes mudanças no 
comportamento. Neste sentido, apareceram empresas especializadas para esses tipos de 
automações gerando excelentes resultados operacionais, diminuindo prejuízos e 
otimizando os custos. 
Até o surgimento dos dispositivos móveis, as automações comerciais eram 
basicamente utilizadas pelos colaboradores da empresa, por meio de hardwares 
específicos e dedicados, facilitando assim retirar o pedido do cliente, enviar para a 
cozinha algum prato ou mesmo realizar o fechamento da conta. Porém, com o advento 
13 
 
desses aparelhos móveis, o cliente passa a ser parte necessária e integrante da automação, 
alterando por completo a experiência desse consumidor e todos os dados que ele gera para 
a empresa. 
Por fim, toda a automação visa garantir o acesso aos dados, concentração de 
informações e mais agilidade no atendimento do consumidor que cada vez deseja perder 
menos tempo com coisas simples. 
1.1.2. Android e Dispositivos Móveis 
O Android é a plataforma móvel mais popular do Mundo e vem crescendo cada vez 
mais. Segundo o site de tecnologia TecMundo (acesso realizado em 18/04/2018) em 2017 
tínhamos 85% dos aparelhos do mundo com sistema operacional gerenciado pelo Google. 
Desde o surgimento dos aparelhos celulares, diversos modelos foram criados e 
lançados pelas grandes produtoras, porém todos possuíam basicamente as mesmas 
funcionalidades diferenciando-se um do outro apenas pelo seu formato, pelo tamanho, 
etc. 
Funcionalidades tais como: agenda de contatos, câmeras de baixa resolução, rádio 
FM e praticamente nenhuma integração com qualquer outro device de nosso cotidiano. 
Dessa maneira, no ano de 2005, o Google realizou uma parceria com essas grandes 
indústrias, como LG, Sony, Samsung entre outras e criaram um grupo chamado OHA 
(Open Handset Aliance) com a finalidade de criar uma plataforma única para o 
desenvolvimento de dispositivos móveis. (USE A CABEÇA, 2016). 
Assim, a partir dessa iniciativa surgiu o Android, que é um ambiente operacional 
baseado em Linux, com código open source. 
Essa plataforma tem como conceito principal ser totalmente aberta, ou seja, oferece 
gratuitamente diversos recursos para o desenvolvimento de novos aplicativos fazendo que 
com o passar o tempo tenhamos mais bibliografias a respeito. 
No início, seu destino era somente o campo de dispositivos móveis, entretanto a 
grande variedade de serviços, aplicações e suporte totalmente funcional possibilitou que 
se tornasse útil em outras plataformas com diversas aplicações e um ambiente 
extremamente flexível. (USE A CABEÇA, 2016). 
14 
 
Em outubro de 2008 o primeiro aparelho a funcionar com o sistema operacional 
Android começou a ser comercializado. O aparelho levou o nome de T-Mobile G1, que 
pode ser observado na figura 3. (FINCOTTO, SANTOS, 2014). 
 
Figura 3 - Foto do aparelho T-Mobile G1. Primeiro a possuir Android 
As vendas superaram as expectativas e a plataforma se tornou um sucesso entre os 
fabricantes. Um dos principais motivos para essa impressionante evolução nos últimos 
anos é estar baseado em “Código Aberto”. Sistema baseados em uma estrutura que pode 
ser modificada por qualquer usuário que tenha conhecimento de linguagens de 
programação ou mesmo de sistemas. Esses sistemas se diferenciam de sistemas 
operacionais usados atualmente, por exemplo o Windows. (COSTA, SANTOS, 2015). 
E, por esse e outros fatos que serão abordados ao longo desse trabalho, pode-se 
afirmar que o Android, hoje, é utilizado por quase todas as empresas do ramo, liderando 
o mercado mundial de dispositivos móveis. (KINOTO,COSTA) 
Ocorre, porém, que o Android não está sozinho nesse nicho de alto giro financeiro, 
que só entre os meses de abril e junho de 2016 movimentou mais de 11,4 bilhões no 
Brasil. Isso porque, sistemas como IOS (presente em produtos Apple), Windows (muito 
conhecido na indústria de computadores) e Blackberry, compartilham os altos números 
desse mercado. 
Prova disso é que, de acordo com a consultoria americana Gartner, 
aproximadamente 408 milhões de aparelhos foram vendidos somente no 4 trimestre de 
2017, considerando que 82% desse total com o SO do Google. 
15 
 
Na figura 4 é possível observar o quanto o Android tornou-se expressivo no 
mercado de Smartfones. Observa-se também que muitos sistemas operacionais, como por 
exemplo o Windows, saíram do mercado dos dispositivos móveis dando espaço 
praticamente para dois players. 
 
Figura 4 - Pesquisa Gartner (Disponível em https://www.gartner.com/newsroom/id/3859963) 
Sendo assim, seria muito contraditório a não utilização dessa ferramenta no ramo 
da automação, já que é possível realizar diversas integrações com diferentes sistemas. 
Além das infinitas integrações, os aparelhos também possuem um baixo custo de 
aquisição e até mesmo manutenção quando comparamos com hardwares dedicados. 
Esse cenário permite que os desenvolvedores explorem os potentes hardwares que 
os telefones possuem. Como exemplo, é possível utilizar a câmera para algum tipo de 
realidade virtual aumentada, consultar um endereço no Google Maps ou até mesmo 
explorar o acelerômetro do dispositivo. Dessa forma, a eficiência da plataforma 
juntamente com a alta oferta de internet facilitou e barateou a automação comercial. 
Há alguns anos, para que um restaurante conseguisse uma automação simples de 
pedido, ou seja, realizar o atendimento do cliente e envio para o local responsável dentro 
do estabelecimento era necessário um dispositivo dedicado. Isso aumentava o preço de 
custo, manutenção e até mesmo de melhoria e atualização do sistema, pois tudo era muito 
restrito aos desenvolvedores e técnicos de manutenção.Hoje, utilizando-se apenas um celular é possível realizar uma conexão com um 
servidor, que recebe o pedido e direciona para um computador ou mesmo um outro 
dispositivo, o qual a encaminhará à área interna. Isso com toda a certeza trouxe avanços 
para grandes empresas, mas beneficiando também pequenos empreendedores que 
conseguiram automatizar seus processos de maneira barata. 
16 
 
1.2. Objetivos 
O tema escolhido para esse trabalho foi desenvolver um protótipo de automação do 
processo de venda de fichas de consumo para o setor de bares e restaurantes, desde a 
criação do login e carteira digital do cliente, como o direcionamento e armazenamento de 
todas as informações de produtos e usuários diretamente na nuvem, utilizando uma 
plataforma do Google. 
O foco do projeto será na criação de toda a automação para a venda de fichas e na 
entrega do produto pelo balconista, onde ambos utilizarão o mesmo aplicativo, gerando 
eficiência e integração total dos dados. Nesse projeto, entretanto, não foi considerado a 
implementação de nenhuma empresa financeira para realizar a venda no cartão de crédito 
efetivamente. 
A escolha do tema tem como motivo, a redução de custos, aumento de eficiência e 
também a criação de um banco de dados com todas as informações dos consumidores do 
estabelecimento que é extremamente valioso para qualquer ação de publicidade ou venda 
e que hoje apenas as grandes empresas se utilizam dessas informações. 
 
 
 
 
 
 
 
17 
 
2. FUNDAMENTAÇÃO TEÓRICA 
2.1. Estrutura Android 
A plataforma Android é formada por diversas camadas e muitos componentes 
diferentes e distintos desde funções básicas como armazenamento de contatos a até 
mesmo um conjunto de APIs e bibliotecas de apoio. 
A plataforma Android pode ser considerada, ou melhor, comparada a uma pilha de 
softwares distribuída em camadas com conjunto de bibliotecas e APIs e seu 
SDK(Software Development Kit). A figura 5 abaixo, é capaz de exemplificar toda essa 
estrutura. (FINCOTTO, 2014) 
 
Figura 5 - Camadas da Plataforma Android 
2.1.1. Núcleo Linux 
A camada que está sob todas as outras da “pilha”, ou seja, a base da plataforma é 
denominada Núcleo Linux. Essa parte da estrutura é a responsável por realizar toda a 
18 
 
comunicação entre as aplicações, ou seja, a parte virtual do aplicativo e o hardware. Isso 
determina que essa camada seja o intermediário entre o comando realizado via código, e 
o componente do dispositivo, por exemplo, uma câmera ou a saída de som. Além dessa 
ponte entre o virtual e o real, o núcleo também é responsável pelo gerenciamento de 
memória, processos e aplicações. (FINCOTTO, 2014). 
2.1.2. Bibliotecas 
Nessa camada estão todas as bibliotecas nativas do Android, ou seja, aquelas 
bibliotecas que estão disponíveis para qualquer desenvolvedor fazer e que já estão 
contempladas no sistema operacional. Essa biblioteca reúne diversas classes, auxiliando, 
portanto, no desenvolvimento das aplicações e sistemas. Essas bibliotecas são escritas em 
código C e C++, que são expostas por meio das APIs de framework. (GRIFFITHS, 2014) 
As bibliotecas mais utilizadas são: 
• Webkit: Biblioteca utilizada para interpretar e exibir páginas WEB e 
conteúdos HTML (HyperText Markup). 
• Telephony Manager: utilizada para obter os dados básicos do telefone, como 
por exemplo rede de cobertura, bateria, status de conexão. 
• Location Manager: Utilizado para obter dados de geolocalização do 
dispositivo, muito utilizado em aplicações que utilizam uma referência de 
posicionamento global (GPS – Global Positioning System). 
2.1.3. Tempo de Execução (Android Runtime) 
Essa camada possui um grupo de bibliotecas do núcleo Java e da máquina virtual 
Dalvik. Todas as linhas de código programadas em código Java no Android, são 
executadas sobre essa máquina virtual em um processo e instâncias únicos. (FINCOTTO, 
2014). 
Essa máquina virtual foi projetada para ter alto desempenho e executar vários 
processos paralelos e não executar os byte-codes do Java mas compilar e converter para 
um formato específico executado na máquina virtual. 
19 
 
2.1.4. Framework de Aplicativos 
Essa camada possui os programas que gerenciam as funcionalidades básicas do 
telefone. Esse nível possui um grupo de recursos que possibilitam o desenvolvimento das 
aplicações dos sistemas, tais como criação de listas, botões e até mesmo as integrações 
com os hardwares do dispositivo. (ANDROID DEVELOPERS, 2014) 
2.1.5. Aplicações 
As aplicações são todas as funcionalidades virtuais intrínsecas do telefone. Todo 
dispositivo Android vem com um conjunto de aplicativos básicos, como por exemplo, 
Envio de SMS, Calendários, Navegador de Internet e outro bem conhecidos pelos 
usuários de smartphones. 
Esses aplicativos “nativos” do Android não possuem qualquer condição especial 
que qualquer outro aplicativo que o usuário venha a instalar, ou seja, caso o usuário queira 
trocar o aplicativo que envia SMS ou mesmo a agenda de contatos, ele conseguirá sem 
problemas. Mas o ponto mais relevante dessas aplicações, é que eles podem ser facilmente 
acessados por qualquer outro aplicativo, sendo ele nativo ou não. Por exemplo: se em um 
desenvolvimento do sistema, uma parte do processo automático contempla o envio de 
SMS. 
Nesse caso, não é necessário gastar tempo e investimento com essa programação. 
Basta realizar a integração com a aplicação de envio de SMS nativo da plataforma e focar 
todos os esforços no desenvolvimento do que realmente é necessário. (BORGES, 2015) 
2.2. Computação em Nuvem 
Atualmente qualquer empresa que visa manter competitividade no mercado, deve 
investir em tecnologia, e nesse caso em tecnologia da informação para manter todos os 
sistemas interligados com muita rapidez, estabilidade e alto desempenho. Dessa maneira, 
a computação em nuvem, é o mais novo recurso que grandes players do mercado estão 
utilizando para usar e extrair resultado de informações que são geradas e capturadas. Com 
o avanço das startups, ou seja, pequenos empreendedores da tecnologia com foco no 
trabalho colaborativo, companhias de pequeno porte também estão se interessando e 
20 
 
conseguindo utilizar o armazenamento de dados em uma “nuvem”. Além do 
armazenamento, os empresários podem transferir grande parte das camadas de TI de uma 
empresa para os provedores, e assim ter um foco mais concentrado nas estratégias de 
negócio da empresa deixando de lado questões processuais e operacionais que a gestão 
de TI determina. 
Podemos definir a computação em nuvem como um conjunto de serviços baseado 
na WEB com o intuito de fornecer diferentes funcionalidades e soluções para as 
companhias. Até o surgimento e a definição do conceito de computação em nuvem, para 
que isso fosse possível um alto investimento era necessário e é o que determina a 
característica marcante na solução: o modelo de cobrança. Essa alteração do modelo, 
determinou uma verdadeira revolução nas empresas pois um paradigma do ponto de vista 
financeiro foi quebrado. (BORGES, 2015) 
O NIST (National Institute of Standards and Technology – USA), define a 
computação em nuvem como um conveniente modelo de acesso, a um grupo de recursos 
compartilhados configuráveis, que são disponibilizados de maneira ágil, com o mínimo 
de interação possível com o provedor dos serviços. Algumas características essenciais 
também foram definidas pelo instituto Americano: 
• Virtualização de recursos 
• Serviços sob demanda 
• Independência de localização 
• Elasticidade e Escalabilidade 
• Medição dos Serviços 
• Repositórios de Recursos 
Dentre as características acima definidas pelo NIST, podemos destacar a questão 
do Serviço Sob Demanda, Independência de Localização, Elasticidade e Escalabilidade e 
a Medição dos serviços. 
2.2.1. Serviço sob demanda 
Um dos aspectos marcantes desse tipo de tecnologia, onde o cliente pode requerer 
maior ou menor quantidadede recursos, sem a necessidade de interação humana com o 
21 
 
provedor. Isso determina que o próprio cliente, através de um aplicativo do celular, uma 
aplicação no computador ou mesmo uma solução WEB possa requisitar mais recursos 
para sua empresa em situações pontuais onde um aumento no processamento de dados é 
necessário. 
2.2.2. Independência de localização 
Todo o serviço está disponível através de rede e internet, tornando o usuário capaz 
de acessar as informações de diferentes dispositivos, em plataformas diferentes como por 
exemplo: telefones, computadores e tablets. Nesse caso, a nuvem funciona como um 
acesso centralizado, disponível a todo tempo e em qualquer lugar. Isso faz com que a 
empresa possa mudar de endereço, de cidade e até mesmo de país de uma maneira muito 
mais fácil e rápida já que toda a camada de TI está alocada em uma nuvem. 
2.2.3. Elasticidade e Escalabilidade 
A elasticidade é a característica que mais quebra os paradigmas da tecnologia da 
informação nas companhias. Ela é definida pela capacidade de fornecer e remover 
recursos em tempo de execução, não dependendo de quanto o cliente solicitou. 
(BORGES, 2015). 
Aliada a elasticidade, a escalabilidade é definida basicamente pelo aumento da 
capacidade de processamento ou trabalho pela adição de recursos proporcionalmente. 
(BORGES, 2015) 
Dessa maneira, todo o serviço é disponibilizado sete dias por semana, 24 horas por 
dia onde em períodos de pico recursos são fornecidos, e quando a demanda cai, ocorre a 
retirada de capacidade. 
2.2.4. Medição dos Serviços 
Essa é a característica mais interessante do ponto de vista financeiro da empresa, 
pois é possível mensurar exatamente o gasto com o serviço, melhorando, portanto, o 
controle se está acima ou abaixo, não onerando em nenhum momento a eficiência do 
serviço. Dessa maneira, a empresa tem a plena certeza que está utilizando a estrutura 
22 
 
correta para o tamanho do processamento de dados, evitando lentidão dos servidores por 
falta de investimento ou mesmo gastos desnecessários com componentes extras. Vamos 
utilizar o exemplo de contas de água e luz. Esses serviços estão disponíveis para todos, 
24 horas por dia, 7 dias por semana, porém existe a cobrança quando ocorre o uso, 
portanto caso você precise 1000 litros de água basta abrir a torneira que o fornecimento 
acontece e o mesmo é válido caso seja necessário apenas 1 litro. Essa analogia define 
exatamente o modelo normalmente utilizado na computação em nuvem. Este modelo 
agrega transparência no serviço, tanto para o fornecedor quanto para o cliente, com base 
em SLAs (Service Level Agreement) e QoS(Quality of Serviece) para especificar os 
valores a serem cobrados. 
Dessa maneira, devido todas essas características, cada vez mais, as empresas estão 
evoluindo suas camadas de TI determinando, portanto, um desenvolvimento acelerado de 
provedores de serviços de computação em nuvem pois, como citamos acima, é um 
investimento assertivo onde o desperdício é zero. (BORGES, 2015) 
2.3. Google Firebase 
Desenvolvido pelo Google, o Firebase é uma plataforma que contém diversos 
produtos distribuídos de forma gratuita para os usuários. Porém, a disponibilização possui 
limites de utilização em alguns casos. As funcionalidades são as mais diversas, porém, 
utilizamos nesse trabalho, os seguintes produtos: 
 Serviço de Hospedagem 
 Monitoramento de Usuário 
 Login e Gestão de Usuários 
 Banco de Dados 
Essa potente ferramenta WEB possui bibliotecas prontas e integrações estruturadas 
que com poucas linhas de código é possível adicionar o banco de dados, inserir o modelo 
de gestão de usuários e até mesmo armazenar figuras e imagens. Essas funcionalidades 
facilitam o desenvolvimento da aplicação e agilizam o trabalho. (FIREBASE GOOGLE) 
A utilização do Firebase está interligada com uma conta Google, ou seja, é um 
produto fornecido pela Google para todos os usuários que possuem uma conta Gmail. 
Abaixo estão todos os produtos que foram utilizados nesse trabalho. 
23 
 
2.3.1. Login de Usuários (Authentication) 
Em praticamente todos os aplicativos, é necessário ou no mínimo interessante, 
reconhecer a identidade do usuário. Assim, essa funcionalidade do Firebase permite que 
os usuários se cadastrem, fornecendo algumas informações que são armazenadas no 
banco de dados. 
Nesse sentido, o produto de autenticação do Firebase fornece SDKs prontas e fáceis 
de usar, bem como bibliotecas para implementar rapidamente o ponto de cadastro dos 
usuários. Ele permite que essa autenticação seja feita de diferentes maneiras, por diversas 
redes sociais e informações. Na figura 6, pode-se observar todas as opções que o produto 
de usuários do Firebase nos fornece. 
Figura 6 - Opções de conexões para login do usuário 
2.3.2. Realtime Database 
Dentro da plataforma do Firebase, existe o “produto” ou podemos chamar de 
funcionalidade do banco de dados. Esse banco é alocado na nuvem, ou seja, fica 
armazenado direto na plataforma nos servidores do Google, e possui uma arquitetura 
NoSQL, ou seja, não existe uma estrutura de tabela, e sim uma lógica de “nós”. 
(FIREBASE GOOGLE, 2016) 
24 
 
Todas as informações que são alocados no DataBase do Firebase são armazenadas 
como objetos JSON, sendo que o banco de dados funciona como uma árvore JSON 
hospedada na nuvem. Esse tipo de estrutura “em árvore” não apresenta nenhum tipo de 
tabelas nem registros, e em toda marcação que fazemos no banco, ela se torna um nó 
associado a uma chave que podemos classificar como principais e filhos. Podemos ter até 
32 níveis de chaves, e como boa prática nesse tipo de estrutura deve-se evitar o uso de 
chaves muito “profundas” e buscar sempre a redundância das informações para garantir 
a rapidez e simplicidade na hora de recuperar os dados do banco. Abaixo temos um 
exemplo de um banco de dados que armazena dados dos usuários, suas expressões e 
quantos votos cada expressão obteve: 
 
Figura 7 - Exemplo banco de dados Firebase. Retirada de https://www.appcoda.com/wp-
content/uploads/2016/02/joke-firebase-data.png 
No exemplo acima, temos dois nós principais “jokes” e “users”. O nó “users” estão 
todas as informações dos usuários (e-mail, provider e username) e também o nó “votes” 
que contabiliza todos os votos do usuário. Temos dois usuários cadastrados nesse banco 
de dados identificados no nó com um ID alfanumérico gerado pelo próprio Firebase para 
distinguir os usuários. 
No outro nó estão as informações das expressões, ou como estão denominadas no 
exemplo “Jokes”, e todas as suas informações. Percebe-se que temos informações 
duplicadas nos nós, como por exemplo número de votos, ou mesmo o nome do autor, 
https://www.appcoda.com/wp-content/uploads/2016/02/joke-firebase-data.png
https://www.appcoda.com/wp-content/uploads/2016/02/joke-firebase-data.png
25 
 
porém para simplificar as consultas e extração dos dados, a redundância determina uma 
boa prática para esse tipo de estrutura de dados. 
2.4. Proposição 
Levando em consideração todos os tópicos apresentados na introdução deste 
trabalho, pontos abordados na revisão de literatura e também visando uma possível 
implementação real do projeto, decidiu-se desenvolver uma automação para vendas de 
fichas virtuais com foco em estabelecimentos do setor de bares e restaurantes. Visou-se 
correlacionar todo o conceito da programação aprendida durante o cursou de controle e 
automação com a aplicabilidade dos principais elementos da automação comercial. Esse 
trabalho não visa a implementação de um sistema de venda envolvendo moedas reais, e 
sim o conceito da automação e lógica do sistema. 
2.5. Metodologia 
Esse projeto tem como proposição o desenvolvimento de um aplicativo capaz de 
automatizar a venda e retirada de produtos que são vendidos em bares e restaurantes. Toda 
a estrutura leva em consideração uma venda simples sem a efetivação da cobrança porcartão de crédito, que pode ser facilmente integrada com qualquer plataforma. 
O aplicativo proposto tem o intuito de facilitar a venda em estabelecimentos que 
utilizam fichas de consumo ao invés de comandas eletrônicas. A rastreabilidade e 
validação dos dados é feito tudo vida QrCode, melhorando a segurança e como utilizamos 
base de dados em nuvem a blindagem das informações é garantida. 
Para facilitar o desenvolvimento, dividimos as atividades em etapas: 
• Etapa 1: Mapeamento do fluxo existente nos bares e identificação dos pontos de 
automação. 
• Etapa 2: Esboço da estrutura principal do aplicativo 
• Etapa 3: Preparação do ambiente de desenvolvimento (Android Studio) 
• Etapa 4: Integração com a plataforma Firebase 
26 
 
• Etapa 5: Leitura e geração de QrCode 
Antes de qualquer tipo de programação, ou mesmo desenho de tela, foi necessário 
realizar um mapeamento completo de um ambiente de venda de fichas. Para isso 
utilizamos exemplos de estabelecimentos que possuem esse tipo de sistema (fichas de 
papel) e foram mapeadas diversas oportunidades de melhorias e também de automação. 
Dessa maneira, após todo o estudo desse simples modelo de venda de fichas, foi 
possível determinar um fluxo de como funciona a venda com fichas de papel e assim 
determinar os pontos a serem automatizados. Abaixo temos o fluxo do uso de fichas 
físicas: 
 
Figura 8 - Modelo Venda de Fichas de Papel 
No fluxo acima, aparentemente parece muito simples, com poucas etapas, porém 
da percepção de controle, automação e mesmo na questão de experiência do cliente é 
muito precário. O sistema de uso de fichas de papel não possui nenhum armazenamento 
computacional, sequer uma validação dos dados. Abaixo todos os passos desse sistema. 
• O passo 1 é momento que o cliente deve ir até o caixa e realizar a compra da 
ficha. Nesse momento é necessário um funcionário para realizar a cobrança do 
produto e a entrega da ficha, e há a possibilidade do consumidor ficar na fila 
para realizar a compra, impactando e muito a experiência de nosso cliente. 
• Após realizar a compra, o cliente armazena as fichas de papel para ir realizar a 
retirada. Esse armazenamento é de feito pelo próprio cliente, que coloca as 
fichas no bolso ou na carteira. 
27 
 
• Na retirada é necessário ir até o balcão e entregar a ficha, e assim o colaborador 
do estabelecimento realiza a entrega. 
Observa-se, portanto, um trabalho muito grande desde o início da compra, onde é 
necessário ficar numa fila, realizar o pagamento e também dirigir-se para retirar o produto 
desejado e também um investimento por parte do estabelecimento em diversos 
funcionários para fazer o atendimento. Além do custo e da experiência do cliente, temos 
que existe o risco de fraude no sistema de ficha de papel, podendo causar prejuízos 
enormes para a empresa. 
Assim, listamos nossos 4 pontos principais para o desenvolvimento da estrutura do 
protótipo do aplicativo: 
• Experiência do Cliente 
• Custo com funcionário 
• Fraude 
• Big DATA 
2.6. Definição do Escopo do Projeto 
Após a estruturação de todo o conceito e objetivo da automação, foi necessário 
realizar uma pesquisa (benchmarking) para entender e conhecer as principais 
características de outros aplicativos disponíveis no mercado. Esse mapeamento tem como 
principal função levantar os pontos relevantes de outros sistemas e aplicar no projeto. 
Nessa pesquisa realizada, não foi encontrado nenhum aplicativo semelhante ao proposto 
neste trabalho, porém foi identificado um sistema com funcionalidades com algum grau 
de proximidade. A automação que foi considerada mais próxima ao do escopo proposto 
é do restaurante STUE. 
28 
 
 
Figura 9 - Aplicativo utilizado para referência 
Esse restaurante possui uma culinária brasileira, com o conceito de pratos menores, 
ou seja, em uma porção mais diminuta. Esse modelo permite que o consumidor tenha a 
chance de provar mais de um prato em uma refeição, aproveitando melhor o cardápio. 
Dessa maneira, o consumidor realiza diversos pedidos, ou seja, a frequência que um 
garçom teria que atendê-lo seria muito maior e consequentemente o número de garçons 
teria que ser aumentado para que todos tivessem um bom atendimento. Com isso, o 
aplicativo do estabelecimento auxilia na velocidade e também na facilidade dos pedidos. 
Na figura 10 abaixo, temos uma estrutura de como funciona o aplicativo em questão. 
29 
 
 
Figura 10 - Modelo do Aplicativo STUE 
 
2.6.1. Cliente (1) 
O cliente entra no estabelecimento e é recebido por um funcionário do restaurante 
que o acomoda na mesa mais apropriada. Essa função de receber o consumidor e 
acomodá-lo não é interessante retirar, já que faz parte da experiência do usuário. 
Porém, uma diferença existe, o garçom não entrega um cardápio para o consumidor 
pois o consumidor consegue realizar o pedido diretamente do celular, sem 
necessitar chamar o colaborador novamente. 
 
2.6.2. Realizando o Pedido e Pagamento (2) 
Após ser recebido, analisar o cardápio o cliente pode escolher sozinho quais opções 
que deseja e realizar o pedido. Esse pedido é feito diretamente pelo seu próprio 
celular, portanto cada um faz seu próprio pedido, e já realiza o pagamento via cartão 
de crédito. 
 
30 
 
2.6.3. Envio do Pedido (3) 
Após realizar o pagamento, o pedido é enviado para o local correto dentro do 
estabelecimento, ou seja, o sistema é capaz de enviar para a cozinha tudo que for 
comida, e também envia para o balcão todas as bebidas. Dessa maneira, a entrega 
se torna mais rápida e mais eficiente, possibilitando um aumento de faturamento 
para a empresa. 
2.6.4. Entrega do Pedido (4) 
Assim que o pedido está pronto, seja na cozinha ou no balcão, o garçom é avisado 
e realiza a entrega para o consumidor. Como o pedido foi pago antecipadamente, o cliente 
pode levantar e ir embora a hora que desejar evitando, portanto, filas e qualquer tipo de 
espera para o fechamento da conta. 
Levando em consideração a referência do aplicativo pesquisado, foram levantados 
todos os pontos que poderiam ser utilizados como exemplo nesse trabalho e assim 
definimos o escopo do sistema considerando as peculiaridades do negócio em questão, e 
também as limitações que o ambiente possui. 
O aplicativo em questão é o mesmo para o estabelecimento e também para o 
empresário, ou seja, o tipo de usuário é determinado logo na autenticação. Na tela inicial, 
o usuário deve necessariamente realizar o login e caso não tenha, deverá realizar o 
cadastro. O cadastro é realizado somente para usuário comuns, enquanto os 
administradores do sistema, isto é, os colaboradores do estabelecimento são cadastrados 
diretamente na ferramenta Firebase. O armazenamento na nuvem garante que exista uma 
segurança a respeito do acesso aos dados do banco de dados, pois existe uma blindagem 
e, portanto, apenas o administrador consegue acessar os dados. 
A estrutura de banco de dados escolhida atende todos os requisitos do projeto que 
tem como principal função o acesso fácil e rápido por dispositivos móveis. Além disso, 
temos a segurança que os dados não serão perdidos, ou seja, fica localizado em um bando 
de dados em nuvem. 
Na figura 11, temos a estrutura básica do aplicativo: 
31 
 
 
Figura 11 - Estrutura Básico do Aplicativo do Projeto 
Primeiramente existe um cadastro do usuário para que o cliente consiga ser 
identificado pelo sistema. Essa validação é essencial pois toda a estrutura do banco de 
dados está no ID do usuário que o Firebase gera, pois ele é único e cada “tabela” que no 
banco de dados “noSql” é chamado de nó, é determinada pelo usuário. 
Após a validação do usuário no aplicativo, que é realizada por uma funcionalidade 
raiz do Firebase o consumidor pode escolher o produto e realizar a compra que é 
representada pelo bloco “Venda da Ficha”. Como a estrutura de validação do usuário é 
fornecida diretamente pela plataforma, nem mesmo o administradordo sistema tem 
acesso às informações dos usuários, determinando uma blindagem completa das 
informações sensíveis. Vale ressaltar que nesse projeto não está sendo considerada a 
venda por completo, ou seja, realizar o cadastro de cartão de crédito e a venda de fato, 
porém toda a estrutura está preparada para receber essa funcionalidade. 
Cada ficha que é vendida, é armazenada no banco de dados na “carteira digital” do 
cliente com um número único que será utilizado para realizar a retirada do produto. Esse 
número único será utilizado para gerar o QrCode necessário para a validação no banco 
de dados. Essa validação ocorre para evitar fraudes, confirmando sempre se a ficha está 
paga, foi retirada ou simplesmente não existe. 
O código gerado é transparente para o usuário final, e, portanto, apena é visível de 
forma bem simples todas as fichas que o usuário tem disponível para retirar. Esse 
32 
 
armazenamento determina uma carteira virtual do consumidor que possibilita uma gestão 
de todas as fichas. 
No momento da retirada, o cliente seleciona a ficha desejada e gera o QR Code na 
tela do aplicativo. Para validar o produto, é necessário apresentar esse código para o 
funcionário do estabelecimento que vai realizar a leitura com um outro dispositivo mível. 
Essa função realiza a consulta no banco de dados e retorna todas as informações da ficha, 
informando para o colaborador se deve ou não entregar o produto. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
33 
 
3. DESENVOLVIMENTO 
 
Considerando todo o escopo apresentado, as telas foram desenhadas e 
desenvolvidas de acordo com as ferramentas disponibilizadas. 
3.1. Preparação do Ambiente Android 
O Android Studio é o ambiente oficial para qualquer desenvolvimento para a 
plataforma do Google. Esse IDE, Ambiente de Desenvolvimento Integrado em Português, 
é baseado no IntellJ IDEA que possui muitas outras ferramentas para incrementar e 
aumentar as funcionalidades dos aplicativos Android. (DEVELOPER ANDROID, 2017). 
IntellJ IDEA é um ambiente de desenvolvimento Java para computadores que 
utilizam sistema operacional Linux e que trabalham com Frameworks, serviços 
corporativos e dispositivos móveis. (DEVELOPER ANDROID, 2017). 
Assim, determinou-se que essa seria a ferramenta principal para todo o 
desenvolvimento do sistema. Esse ambiente de desenvolvimento está disponível 
gratuitamente no site do Google (https://developer.android.com/studio), conforme a 
imagem 12. 
 
 
Figura 12 - Página WEB Android Studio 
 
https://developer.android.com/studio
34 
 
 
3.2. Estrutura Geral das Telas 
Aplicativos Android são feitos basicamente de telas e comandos de como elas se 
relacionam. Dessa maneira, na construção do aplicativo determinou-se telas principais, 
ou seja, quais eram as funcionalidades que necessariamente o aplicativo requisitava e, 
após a estruturação dessas telas principais outras telas suportes foram construídas. 
Abaixo, foi listada todas as telas que direcionam todo o funcionamento do aplicativo. 
• Tela Inicial de Login 
• Telas de Cadastro de Usuário 
• Telas de Compra de Ficha 
• Telas Gestão de Fichas 
• Tela de Retirada de Produto Balcão 
As telas foram desenvolvidas com o apoio das bibliotecas do Android Studio que 
são baseadas em código xml com o auxílio do ambiente da plataforma de 
desenvolvimento. 
3.3. Tela Inicial de Login 
A tela de login é a primeira tela do aplicativo e contém os campos para a realização 
da validação do usuário bem como a logomarca da empresa utilizada como exemplo. 
Assim, é nesse primeiro momento que a identificação do usuário é realizada, e caso o 
usuário não tenha cadastro no sistema, ou seja, caso seja o primeiro acesso um botão para 
então realizar o envio dos dados é disponibilizado. Na imagem 13, temos a primeira tela 
que o usuário interage. 
35 
 
 
Figura 13 - Tela Login 
Portanto, para seguir com a utilização do aplicativo o usuário deve se logar, ou seja, 
o sistema deve validar quem é que está usando o aplicativo e dessa maneira resgatar todas 
as informações do usuário em questão na base de dados. Na automação proposta, 
determinou-se que o login é formado por um e-mail e a senha deve ser composta por letras 
e números. 
3.4. Telas Cadastro Usuário 
Todo usuário do sistema deve realizar o cadastro para conseguir acessar. É nesse 
ponto do processo que capturamos informações muito importantes para identificar o 
usuário. Toda a estrutura de cadastro de dados pessoas desse projeto é baseado em 
informações simples, porém é possível colocar diversos itens para enriquecer o banco de 
dados de usuários, que pode ser utilizado para outros fins como, por exemplo, estudos e 
análises, mediante um termo de uso que regulamente a manipulação dos dados. 
O cadastro é feito em duas telas diferentes: 
• Tela de inserção de login, senha e confirmação de senha. 
36 
 
 
Figura 14 - Tela 1 Cadastro - Senha e Usuário 
• Tela de cadastro de informações pessoais do usuário: 
 
Figura 15 - Tela 2 Cadastro - Informações Pessoais 
As caixas de textos foram programadas para formatar os campos automaticamente, 
ou seja, os campos CPF levam um formato padrão (XXX.XXX.XXX-XX) e o telefone 
(XX) X XXXX-XXX. Na tela de entrada de senha, caso as senhas não sejam compatíveis 
o usuário não consegue realizar o acesso. 
3.5. Tela Compra Ficha 
Após o login do usuário, a tela de compra de fichas é automaticamente aberta, e 
dessa maneira possibilita o cliente dar o comando de compra de qualquer produto ali 
37 
 
disponível. Na tela de compra, temos 3 grandes grupos de produtos, divididos por sua 
categoria: Cervejas, Doses e Refrigerantes. Dessa maneira o usuário consegue navegar 
mais rapidamente pelos comandos e também facilitar o bloqueio de algumas seções por 
parte do aplicativo, caso o usuário seja identificado como menor de idade. 
Cada produto disponível é apresentado de forma horizontal, e cada linha possui a 
foto, informações relevantes (preço, origem, entre outros) e o botão para efetuar a venda. 
 
Figura 16 - Produtos disponíveis venda Cervejas 
 
Figura 17 - Produtos Disponíveis Dose 
38 
 
 
Figura 18 - Produtos Disponíveis Refrigerantes 
 
Figura 19 - Produtos Cadastrados 
 
3.6. Telas Gestão de Fichas 
Após o usuário comprar a ficha desejada, esse voucher fica disponível na tela de 
gestão de fichas. Essa tela possui duas abas: Fichas Disponíveis e Histórico. Na primeira 
aba, é possível visualizar todas as fichas que o usuário efetuou a compra e que ainda não 
retirou, ou seja, as fichas que ele ainda tem na carteira. Nessa seção, observa-se as 
informações da ficha: Quantidade, Nome, Data da Compra e Preço. 
Na segunda aba, denominada de histórico, apresenta para o usuário todas aquelas 
fichas que já foram retiradas no balcão do estabelecimento. Essa parte fornece ao usuário 
o controle das fichas já utilizadas e quando foram utilizadas. Dessa maneira, uma ficha 
que foi comprada, aparece inicialmente na aba de fichas existentes, e após a retirada é 
retirada dessa página e aparece no item histórico da tela de gestão de fichas. 
39 
 
 
Figura 20 - Aba Fichas Disponíveis 
 
Figura 21 - Aba produtos já retirados (Histórico) 
3.7. Telas Retirada Produto Balcão 
As telas apresentadas no item anterior, são exclusivamente utilizadas pelo usuário, 
ou seja, pelo cliente ou consumidor. Mas no sistema proposto, o colaborador do 
estabelecimento utiliza o mesmo aplicativo, diminuindo custos e facilitando a 
manutenção. Assim, existe uma diferenciação do usuário comum com o administrador, 
ou seja, do funcionário que irá confirmar a compra da ficha pelo cliente realizando a 
leitura do QR CODE gerado e assim entregar o produto. A tela do administrador é 
simples, sendo necessário, portanto, apenas um botão para realizar a leitura, e outra tela 
40 
 
que traz todas as informações da ficha. Na figura 22, temos as telas que compõe a vistade administrador. 
 
Figura 22 - Tela de administrador para iniciar leitura 
 
Figura 23 - Tela de Administrador para confirmação de dados do produto 
Dessa maneira, o funcionário é capaz de validar a quantidade de produtos, preço e 
também data da compra, visto que a ficha permanece na carteira do cliente. Todas as 
informações são capturadas a partir do QR CODE que foi lido, pois cada ficha possui um 
ID único, e a partir desse número todas as informações são acessadas no banco de dados. 
41 
 
O campo mais importante dessa tela, é o campo “Status”. No banco de dados, a 
ficha tem a informação se já foi retirada ou não, ou mesmo se teve algum problema no 
pagamento. A entrega do produto só é feita se o Status está como “Pago”. Isso evita 
fraudes, já que toda a validação é feita diretamente no banco de dados. 
3.8. Estrutura Banco de Dados 
Toda a estrutura do aplicativo é baseado no banco de dados fornecido pelo Firebase, 
uma plataforma Google. Essa plataforma possui toda a API necessária para que o 
aplicativo acesse o banco, escreve e recupere os dados necessário. 
A conexão do banco de dados é determinada no mesmo momento em que 
adicionamos o Firebase ao nosso projeto, ou seja, após essa sincronização todas as 
funções da plataforma estão disponíveis para serem utilizadas. 
Inicialmente para definir a nossa estrutura de banco de dados, levantamos todos os 
tipos de “tabelas” que seriam necessárias, isso pois no Firebase não possuímos tabelas e 
sim nós. No Firebase existe uma orientação de utilizar dados redundantes em diferentes 
tabelas, para facilitar e agilizar a leitura. Levando isso em consideração, 4 nós foram 
determinados e estão representados na figura 24. 
• Informações das Vendas: Esse nó é uma base onde todas as vendas são 
armazenadas, ou seja, uma base analítica que traz todas as informações. 
• Fichas Disponíveis: Nó utilizado exclusivamente para armazenar as fichas 
disponíveis. 
• Fichas Retiradas ou Histórico: Nó utilizado para armazenar todas as informações 
de fichas já retiradas. 
• Informações dos usuários: Nesse nó as informações dos usuários são 
armazenadas. 
42 
 
 
Figura 24 - Estrutura Macro do Banco de Dados 
Dessa maneira, as informações são armazenadas abaixo desses nós. Cada nó raiz 
pode ter vários nós filhos, ou seja, podemos expandir várias vezes e assim relacionar as 
informações que desejamos. 
Todas as vendas possuem um ID único, ou seja, nenhuma outra venda possuirá esse 
código e, portanto, utilizamos essa chave para criar os nós “filhos”, pois assim 
conseguimos facilmente recuperar os dados específicos de uma venda na tela do 
aplicativo. 
Portanto, utilizamos para o nó que armazenamos todas as vendas realizadas: 
 
Figura 25 - Estrutura Nó Venda 
Na imagem 25, conseguimos visualizar todas as informações de uma venda: 
• dia: Data da compra da Ficha 
• dia_retirado: Data da retirada do produto 
• func_retirado: Nome do colaborador que realizou a retirada do produto 
• preço: qual foi o preço pago por cada produto 
43 
 
• produto: Qual foi o produto em questão 
• quantidade: Número de produtos comprados 
• Status: Nesse item a marcação do produto é realizada, ou seja, é o campo 
que sabemos se o item foi retirado ou não. 
• User: quem foi o cliente que compro. Nesse campo não é marcado o nome 
que o cliente cadastrou, mas sim o número que o firebase gerou para o 
usuário que é um número única para cada usuário. 
Em nosso outro nó, armazenamos todas as fichas disponíveis de cada usuário. Nessa 
estrutura foi determinado que além do nó com o ID da venda temos também um nó filho 
com o ID do usuário. Dessa maneira, temos 3 níveis de nós sendo que o primeiro é o nó 
Mãe, seguido pelo nó do usuário e na ponta temos o nó da venda em si. Essa estrutura foi 
escolhida, pois facilita, e muito, a recuperação dos dados melhorando o processamento 
de dados tornando a recuperação mais rápida. 
 
Figura 26 - Estrutura Fichas Disponíveis 
Na figura 26 é possível perceber a relação das informações. No primeiro nível, na 
raiz, temos o nó de fichas disponíveis como o nó mãe. O segundo nível é formado pelo 
usuário, ou seja, pelo cliente e tudo o que está abaixo desse nó pertence a esse cliente. 
Dessa maneira, agrupamos as informações de forma redundante, porém isso facilita o 
44 
 
acesso e recuperação das informações. No terceiro nível temos todas as fichas do usuário, 
e as informações dessa ficha. Assim podemos assumir que os nós dessa estrutura 
assumem a seguinte hierarquia: 
No Mãe -> Filho 1 -> Filho 2 -> Informações 
 Assim, o que interessa para o aplicativo nessa estrutura são as informações, 
enquanto todos os outros nós são apenas para conseguirmos navegar e retornar as 
informações desejadas. Nessa estrutura, temos o “nó filho 1” que é o agrupamento por 
usuário das fichas, enquanto o “nó filho 2” é a ficha em questão. Dessa maneira, temos 
sempre uma relação entre os nós e assim é possível recuperar a venda certa. 
No código de recuperação de dados, conseguimos determinar qual nó filho vamos 
procurar pois o usuário está identificado, e assim realizamos uma espécie de filtro e 
procuramos o nó do usuário e assim recuperamos todas as fichas disponíveis e são 
mostradas na tela de fichas disponíveis. 
Portanto, dessa maneira armazenamos nesse nó: 
• dia: data da compra da ficha 
• idvenda: número único da venda 
• preco: valor pago em cada ficha no momento da compra 
• produto: produto que foi comprado 
• quantidade: número de produtos comprado 
Foi criada uma tabela de fichas já utilizadas, com o nome de 
“user_fichas_historico” e possui a mesma relação de nós filhos e nós mães do mostrado 
na estrutura de fichas disponíveis. As informações armazenadas são praticamente as 
mesmas, porém são usadas em telas diferentes e em situações distintas. Como já 
apresentamos nesse documento, a redundância é uma característica dessa estrutura de 
banco de dados pois deixa as consultas mais rápidas. 
45 
 
 
Figura 27 - Estrutura Fichas Histórico 
Nesse nó temos todas as informações do outro mais a informação do colaborar que 
atendeu. Dessa maneira, basicamente transferimos os dados de um nó para outro quando 
ocorre a retirada do produto. A hierarquia entre nós é a mesma do nó anterior, portanto 
temos as fichas agrupadas por cliente, facilitando a recuperação. 
O último nó de nosso banco de dados traz todas as informações do cliente. Esses 
dados são capturados durante o cadastro no primeiro login. Essa é a parte mais valiosa no 
quesito de estratégia de publicidade. Com as informações capturadas e armazenadas nessa 
parte, é possível cruzar com os dados de vendas e estabelecer estratégias de campanhas 
publicitárias. 
Nesse projeto determinamos alguns dados, porém quanto mais informações for 
capturada dos clientes, mais rica a base de dados se torna. 
46 
 
 
Figura 28 - Estrutura Informações Usuários 
Conforme podemos observar na figura 28, a estrutura é mais simples que a de 
fichas. Nessa base, armazenamos os seguintes dados: 
• cidade: Cidade do Usuário 
• datanascimento: Data de Nascimento do Usuário 
• endereço: Endereço do Usuário 
• estado: Estado 
• Nome: Nome do usuário 
• Telefone: telefone do usuário 
Assim, todo o aplicativo está baseado nesses quatro nós abordados, e ao cruzarmos 
todos esses dados, conseguimos relacionar as telas e manipular os dados através dos 
códigos. 
Toda essa funcionalidade fica armazenada na nuvem, e acontece em tempo real e é 
possível observar com o aplicativo em funcionamento. 
47 
 
4. Resultados e Discussões 
Após toda a estruturação e programação, realizamos um teste completo com uma 
jornada completa. Para isso, foi necessário instalar em dois aparelhos verdadeiro o 
sistema, para que fosse possível testar a compra e a retirada da ficha. Utilizou-se um 
aparelho Motorola Moto G5 Plus com um sistema Android 7.0. 
 
Figura 29 - Celular Motorola G5 
Dessa maneira,após a instalação iniciamos os testes fora do ambiente virtual do 
Android Studio para analisar o comportamento de todos os comandos e telas. Para iniciar 
esse funcionamento, utilizamos 2 usuários diferentes com o objetivo de observar o 
comportamento da base de dados e também do processamento de dados. Na figura 30, é 
possível observar a simulação da inserção dos dados de cadastro. 
48 
 
 
Figura 30 - Telas cadastro do usuário Pedro 
Consideramos os dados abaixo para os testes no banco de dados: 
Usuário 1 
Nome: Pedro Carvalho Grassetti 
Data de Nascimento: 10/06/1992 
Endereço: Rua Bahia 999 
Cidade: Avaré 
Estado: São Paulo 
Telefone: (11) 9 8765-4321 
Email: pedro_grassetti@gmail.com 
Senha: pedro123 
 
mailto:pedro_grassetti@gmail.com
49 
 
 
Figura 31 - Tela Cadastro Usuário Bárbara 
Usuário 2 
Nome: Barbara Castro Vieira 
Data de Nascimento: 07/11/1986 
Endereço: Avenida Gilberto Filgueiras 1234 
Cidade: Avaré 
Estado: São Paulo 
Telefone: (11) 9 2345-6789 
Email: barbara_vieira@gmail.com 
Senha: barbara123 
 
Cada um dos usuários inseriu essas informações diretamente no aparelho para 
realizar a criação de um novo acesso na plataforma. Todas essas informações foram 
armazenadas na base de dados e também na parte de autenticação da plataforma Firebase, 
que automaticamente gera um ID único do usuário e não deixa a senha disponível nem 
para o administrador do ambiente. Nas figuras 32 e 33, é possível observar a tela de 
controle dos usuários cadastrados no sistema. 
mailto:barbara_vieira@gmail.com
50 
 
Figura 32 - Tela de gestão dos Usuários 
Figura 33 - Estrutura Banco de Dados Usuários 
Como é possível observar nas figuras 32 e 33, cada usuário possui um ID único 
gerado pelo próprio Firebase, que é utilizado pelo aplicativo para a geração de nós e 
organização de todas as informações visão usuário no database. 
Dessa maneira, os usuários possuem cadastro e conseguem realizar o login no 
aplicativo. Os usuários, portanto, utilizam e-mail e senha cadastrada para acessar o 
sistema e conseguir realizar ações. 
51 
 
 
Figura 34 - Tela Produtos Usuários Teste 
Após o login, o usuário acessa a tela da figura 34, e dessa maneira é possível realizar 
as ações de incluir os produtos em sua carteira virtual. Para essa situação, consideramos 
diferentes compras para os dois usuários de teste, e cada usuário realizou as ações 
separadamente. 
Usuário 1: 
1 Stella Artois 
2 Água com Gás 
1 Amstel 
 
Usuário 2 
2 Smirnoff 
1 Refrigerante 
1 Heineken 
 
52 
 
Após a compra, todas as fichas foram armazenadas nos respectivos nós no banco 
de dados, para que fossem recuperadas sempre que o usuário acessar a aba de fichas 
disponíveis em seu dispositivo. 
Na figura 35, podemos ver a estrutura do banco de dados das fichas disponíveis de 
cada usuário, e também a aba de disponíveis no celular de cada usuário. 
Figura 35 - Estrutura Banco de Dados Produtos Teste 
Percebe-se na figura 35, que temos o nó “mãe”, logo abaixo do nó 
“user_fichas_disponiveis”, que é comum para os dois usuários, 
“user_fichas_disponíveis”, e cada usuário possui seu próprio nó que armazena as 
respectivas fichas. Cada venda possui um ID único que é utilizada por todo o sistema para 
buscar e recuperar as informações, tanto na retirada como em consultas feitas pelo 
usuário. 
Portanto, para mostrar ao usuário todas as fichas disponíveis, o sistema realiza uma 
busca em todo o nó do usuário que está “logado”, interpreta as informações e aloca na 
tela de fichas. Esse caminho das fichas é denominado de “Minhas Fichas” no menu do 
aplicativo, que traz uma personalização com o nome do usuário logado. 
53 
 
 
Figura 36 - Telas de Navegação Usuários 
Assim, ao clicar no ícone de Minhas Compras, automaticamente o usuário é 
direcionado para a tela que mostra todas as fichas disponíveis na conta do usuário. Nesse 
momento, o aplicativo vai até o banco de dados que está na nuvem, e recupera todos os 
dados de fichas disponíveis do usuário que está logado. Todo esse processamento é 
realizado diretamente na plataforma Firebase e, é possível acessar de qualquer lugar, e a 
qualquer hora. 
Na figura 37, temos as telas que foram formadas pelos dados recuperados pelo 
aplicativo, para os dois usuários da figura 36. 
 
Figura 37 - Telas de Produtos Disponíveis Usuários Testes 
54 
 
Assim, a partir das telas apresentadas, o usuário é capaz de realizar a retirada do 
produto a partir de um QR code. Ao clicar no botão para retirada, automaticamente um 
QrCode é gerado e assim o usuário pode dirigir-se ao balcão e retirar o produto. Abaixo, 
na imagem 38, temos um exemplo para o produto “Amstel” do usuário 1. 
 
Figura 38 - QR Code gerado para retirada do produto 
Ao se dirigir ao balcão de retirada, o colaborador do estabelecimento possui o 
mesmo aplicativo, porém, ao realizar o login com um usuário administrador, é 
direcionado para outra tela que possui um ícone para realizar a leitura do QR Code. A tela 
é bem simples e ao clicar no botão para validar o código do usuário o aplicativo acessa a 
câmera do dispositivo para realizar a leitura, como podemos observar na figura 39 abaixo: 
55 
 
 
Figura 39 - Tela do administrador para validar um QR Code 
 
Figura 40 - Leitor de QR ativado para uma leitura 
Com a leitura, o aplicativo busca na base de dados o produto em questão, e, mostra 
automaticamente todas essas informações para o responsável em realizar a entrega do 
produto. Na figura 41, podemos conferir essa tela para o QRCode apresentado na figura 
49. 
56 
 
 
Figura 41 - Tela de conferência dos dados do produto 
No momento da entrega do produto, o usuário administrador tem que avisar o 
sistema da retirada do produto e aciona o botão "Retirar". Ao clicar nesse botão, o sistema 
realiza basicamente três ações da base de dados: 
• Coloca no Status do nó Venda como: Retirado 
• Retira do nó de produtos disponíveis do usuário 
• Insere na base histórica do usuário 
Após essas movimentações que ocorrem em tempo real, o usuário pode conferir 
que o produto que estava disponível em sua carteira digital foi retirado, e está agora na 
parte de histórico conforme a figura 42. 
57 
 
 
Figura 42 - Tela dos itens já retirados - Histórico 
Dessa maneira, o sistema fecha um ciclo da compra, armazenamento na carteira 
digital e retirada, conforme estrutura e lógica esperada. 
Como esse projeto não contempla toda a jornada de compra de fichas, pois não foi 
considerada a venda com a validação de todos os dados de cartão de crédito e também o 
código de segurança, a automação pode receber qualquer interface de venda virtual. 
A automação é capaz de adquirir todos os dados do usuário, realizando as ações de 
leitura e recuperação dos dados, bem como a geração e leitura de QRCode para a retirada 
dos produtos. 
 
 
 
 
 
 
58 
 
5. CONCLUSÃO 
Objetivo desse trabalho é demonstrar e aplicar toda a estrutura de uma automação 
comercial de vendas de fichas de consumo para bares e restaurantes. Tratou-se aqui, desde 
a evolução dos aparelhos celulares, até o desenho da base de dados, design e programação 
de botões e funcionalidades. 
Desta forma, construiu-se o protótipo de um aplicativo para Android (mas que, 
frisa-se, com as devidas modificações estruturais pode ser perfeitamente adequado a outro 
sistema, como, por exemplo, o iOS) que possui uma base para o desenvolvimento de um 
produto totalmente comercial que tem como finalidade dar praticidade à experiência do 
consumidor dentro de um estabelecimento comercial. Isso porque, facilita tanto o modo 
como o consumidor faz seus pedidos, como o pagamento de sua conta ao final de sua 
estada no bar/restaurante. 
Assim sendo, foi possível demonstrar toda a visão comercial de uma automação, 
utilizando conhecimentos e pesquisas do setor de bares e restaurantes, somado com todas 
as funcionalidades e opções que a plataforma Androidpossibilita. 
Frisa-se, por fim, que como o projeto se finalizou sem a implementação de fato de 
uma venda em si, ou seja, sem o cadastro de qualquer cartão de crédito e nenhuma 
plataforma de cobrança, somente foi possível realizar teste em ambientes controlados e 
com produtos não reais. Todavia, em fases futuras do projeto, basta acoplar qualquer 
estrutura de cobrança com cartão de crédito e débito que o aplicativo pode ser colocado 
em produção. 
 
 
 
 
 
 
59 
 
REFERÊNCIAS 
 
MAIA, Mariana Paes da Fonseca. A informação tecnológica como fator de 
sobrevivência e vantagem competitiva. Disponível em 
<http://www.machadosobrinho.com.br/revista_online/publicacao/artigos/Artigo01R
EMS7.pdf>. Acesso em 16 de abril de 2018. 
 
DOZE TI. E-social e processos repetitivos podem ser feitas rapidamente por 
automação A informação tecnológica como fator de sobrevivência e vantagem 
competitiva. Disponível em <http://doze-ti.com.br/artigos/esocial-e-processos-
repetitivos-podem-ser-feitas-rapidamente-por-automacao >. Acesso em 16 de abril de 
2018. 
 
INGRAMMICRO. A nova era da automação comercial, 2017. Disponível em 
<http://www.ingrammicro.com.br/portal/a-nova-era-da-automacao-comercial/>. 
Acesso em 16 de abril de 2018. 
 
ALVES PINTO, Marcelo Caballero, 2014.Código de barras. Um estudo de 
múltiplos casos. Disponível em < 
http://lyceumonline.usf.edu.br/salavirtual/documentos/2623.pdf >. Acesso em 16 de 
abril de 2018. 
 
GRIFFITHS, Dawn; GRIFFITHS, David. Use a Cabeça! Desenvolvendo para 
Android. 
 
FINCOTTO, Marcos Apolinário; SANTOS, Marilde Terezinha Prado, 2014. 
Automação Comercial utilizando Aplicativo Móveis – Um Foco na Plataforma 
Android. Disponível em 
<http://www.revistatis.dc.ufscar.br/index.php/revista/article/viewFile/85/79>. 
Acesso em 18 de abril de 2018. 
 
http://www.ingrammicro.com.br/portal/a-nova-era-da-automacao-comercial/
60 
 
DA COSTA, Reinaldo Candido; DOS SANTOS, Rosaria Ferreira Otoni. 
Conhecendo o Software Livre. Disponível em 
<http://www.periodicos.letras.ufmg.br/index.php/ueadsl/article/viewFile/2504/2456
>. Acesso em 18 de abril de 2018. 
 
ANDROID DEVELOPERS. Arquitetura da Plataforma. Disponível em < 
https://developer.android.com/guide/platform/index.html?hl=pt-br#api-framework>. 
Acesso em 25 de janeiro de 2018. 
 
BORGES, Hélder Pereira; DE SOUZA, José Neuman; SCHULZE, Bruno; MURY, 
Antonio Roberto. Computação em Nuvem. Disponível em < 
http://livroaberto.ibict.br/bitstream/1/861/1/COMPUTA%C3%87%C3%83O%20E
M%20NUVEM.pdf>. Acesso em 23 de Março de 2018. 
 
FIREBASE GOOGLE. Firebase Realtime Database. Disponível em < 
https://firebase.google.com/docs/database/?hl=pt-br#top_of_page>. Acesso em 23 de 
Março de 2018. 
 
DEVELOPER ANDROID. Conheça o Android Studio. Disponível em < 
https://developer.android.com/studio/intro/index.html?hl=pt-br>. Acesso em 01 de 
Fevereiro de 2018. 
 
 
 
 
 
 
 
 
 
 
 
 
 
http://www.periodicos.letras.ufmg.br/index.php/ueadsl/article/viewFile/2504/2456
http://www.periodicos.letras.ufmg.br/index.php/ueadsl/article/viewFile/2504/2456
https://firebase.google.com/docs/database/?hl=pt-br
https://developer.android.com/studio/intro/index.html?hl=pt-br
61 
 
ANEXOS 
Conforme já foi abordado anteriormente nesse trabalho, o Firebase foi a plataforma 
escolhida para implementar algumas das principais funcionalidades do aplicativo. Para 
realizar a utilização desse serviço, foi necessário utilizar uma conta Google para acessar 
a plataforma e realizar a criação de um novo projeto. Na figura abaixo, temos a tela inicial 
após o login. 
 
Dessa maneira, conseguimos iniciar a criação de um novo projeto, para depois 
sincronizar com nosso aplicativo no Android Studio. Ao clicar em “Adicionar Projeto”, 
começamos a configuração de um novo arquivo, e podemos nomear como desejamos. 
62 
 
 
Após esse passo, já concluímos a criação do projeto no Firebase, de maneira fácil e 
rápida. Nosso próximo passo foi realizar o sincronismo com o nosso projeto do Android 
Studio. Para isso, na tela inicial da plataforma, selecionamos a opção de “Adicionar o 
Firebase ao seu projeto” com o objetivo de conectar o nosso projeto no Android Studio. 
 
Para realizar essa conexão, precisamos preencher o campo package com o nome do 
pacote de nosso projeto. Esse nome deve ser exatamente o mesmo, para que ocorra o 
sincronismo. Essa informação pode ser capturada nas classes de nosso projeto, conforme 
observamos na figura a seguir: 
63 
 
 
 
Assim, preenchemos o primeiro campo, com o nosso de nosso package e 
avançamos essa etapa. Com todas as informações que incluímos até agora, a plataforma 
gera um arquivo json, via download. 
64 
 
 
Esse arquivo gerado é um pacote de informações, que deve ser colocado dentro do 
diretório app de nosso projeto do Android Studio, conforme imagem abaixo: 
 
Figura 29 - Diretório Android Studio 
Após a inserção desse pacote de informações que geramos na plataforma do 
Firebase em nosso aplicativo, foi necessário realizar algumas alterações nos arquivos 
build.gradle no projeto e no módulo. Inicialmente, realizamos a inserção do código 
“classpath ‘com.google.gms:google-services:3.0.0’ no nível de projeto. 
65 
 
 
 
Para finalizar devemos clicar em “Sync now” para que todas as sincronizações e 
configuração sejam por fim realizadas. 
Agora, após todas as configurações do Firebase em nosso projeto, tivemos que 
adicionar as bibliotecas das funcionalidades da plataforma Firebase que utilizamos. No 
caso desse projeto, foram utilizadas as bibliotecas de autenticação e banco de dados. 
• com.google.firebase:firebase-auth:10.2.1 
• com.google.firebase:firebase-database:10.2.1 
66