1. Proposta de arquitetura para a implantação da
funcionalidade de entrega de mensagens instantâneas para
aplicações multiplataforma utilizando o serviço Firebase
Cloud Message
Edgar da Silva Fernandes∗
fernandes.s.edgar@gmail.com
2016, v-0.0.1
Resumo
Este artigo propõe, por meio da utilização do serviço de mensagens Firebase Cloud
Message e do estudo de Padrões de Projetos para sistemas de software, uma arquite-
tura para a implantação da funcionalidade de troca de mensagens instantâneas para
aplicativos multiplataformas, garantindo, ao término de sua implantação, um módulo
de software com eficaz consumo de energia e internet.
Palavras-chave: Firebase Cloud Message. Google Cloud Message. Mensagem Instan-
tânea. Push Notification.
Introdução
De acordo com a publicação Acesso a Internet e à Televisão e Posse de Telefone
Móvel Celular para Uso Pessoal (IBGE, 2016), o principal ponto de acesso dos brasileiros
a internet a partir do ano de 2014 é por meio de dispositivos móveis, superando os acessos
via computador pessoal. Com a praticidade de acesso a partir do bolso - assim como a
adoção de planos de internet acessíveis por parte das operadoras de telefonia móvel - o
tempo despendido em navegação pela internet dos Brasileiros aumentou.
Este fato levou a utilização de dispositivos móveis para a realização de tarefas
até então destinadas a processos não informatizados. Neste contexto, os aplicativos de
Mensagens Instantâneas1 se disseminaram, atingindo elevados patamares de penetrabilidade
na sociedade brasileira, estabelecendo-se como meio preferido de comunicação por seus
usuários. O aplicativo WhatsApp, por exemplo, hoje apresenta entre 1 e 5 bilhões de
downloads na Play Store brasileira, com cerca de 1 bilhão de usuários ativos, chegando a
∗
Engenheiro da Computação
M.B.A. Projeto de Sistemas Móveis
Instituto de Gestão de Tecnologia da Informação - IGTI
contato: fernandes.s.edgar@gmail.com
1
Comumente abreviado por MI ou IM do inglês Instant Message
1

2. transmitir mais de 42 bilhões de mensagens diariamente no mundo(UM. . . , 2016)(PRIGG,
2016). O aplicativo Telegram possui cerca de 100 milhões de usuários ativos, trafegando
aproximadamente 15 bilhões de mensagens por dia no mundo no ano de 2016(BURNS, 2016).
Estes aplicativos foram responsáveis por estabelecer uma interface de usuário consistente
que dita o patamar de qualidade para aplicações similares.
A ampla adoção dos sistemas citados deu origem a fenômenos particularmente
interessantes na forma como as empresas estabelecem diversos de seus processos negociais
- a disponibilização de canais que visam atender clientes através da funcionalidade de
mensagens instantâneas tornou-se item obrigatório para diversos segmentos de negócio.
Adaptar-se a esta nova realidade, no entanto, não consiste em tarefa simples, demandando
cuidadosa atenção na tomada de decisão relativa a implantação da problemática discutida.
Questões sobre como implantar a funcionalidade de forma nativa na aplicação proprietária
ou terceirizá-la para um aplicativo especializado devem ser analisadas para chegar a
conclusão mais vantajosa para cada situação.
A primeira abordagem citada apresenta diversos desafios técnicos que podem
fazer com que os stackholders2 desistam desta opção na implantação de seus processos,
voltando-se para a segunda opção, na qual ocorre a terceirização das atividades relacionadas
para aplicativos especializados - como os citados anteriormente. Tal decisão traz consigo
uma série de riscos, dentre os quais cita-se a falta de controle do processo conduzido
pela aplicação terceira e, ainda, a influência dos níveis de disponibilidade do sistema. São
exemplos das condições citadas as situações em que o aplicativo WhatsApp teve seu serviço
interrompido no Brasil:
• Em 25 de Fevereiro de 2015, por determinação do juiz Luiz de Moura Correia da
Justiça do Piauí;
• Em 16 de Dezembro de 2015, durante 48 horas, por decisão da 1o Vara Criminal de
São Bernardo do Campo, SP;
• Em 2 de Maio de 2016, durante 72 horas, por decisão da Justiça de Sergipe;
• Em 19 de Julho de 2016, por decisão da juíza Daniella Barbosa Assumpção de Souza
da 2o Vara Criminal de Duque de Caixas - RJ;
0.1 Objetivo e Metodologia
O objetivo deste trabalho é propor uma arquitetura que utilize o serviço de
mensagens Firebase Cloud Message como componente principal no processo de implantação
da funcionalidade de troca de mensagens instantâneas, facilitando a adoção da abordagem
de implantação nativa da mesma. A metodologia adotada visa estabelecer a problemática
que envolve o assunto, procurando elucidar a importância do tema debatido no atual
mercado de aplicativos móveis.
O desenvolvimento do trabalho inicia-se com a descrição do serviço adotado com
base em documentação pública(FIREBASE, 2016) para sua utilização. A partir de então,
é realizada a elaboração de uma arquitetura de software para a implantação do módulo
de mensagens instantâneas, tomando como base Padrões de Projeto aplicáveis ao cenário
levantado. Em seguida, as vantagens e os riscos da adoção dessa arquitetura são analisados
2
Pessoas envolvidas no desenvolvimento do projeto em questão
2

3. de modo a auxiliar a tomada de decisão com relação à melhor abordagem de acordo com
um determinado cenário específico.
A qualidade da arquitetura proposta é evidenciada na eficácia da transferência de
dados com eliminação do limite de carga útil inerente a utilização do serviço empregado,
com consequente proteção de dados sensíveis que por ventura venham a ser trafegados
na aplicação. Enfatiza-se ainda o grau de extensão propiciado, permitindo a evolução
da aplicação que adota a tal arquitetura para um sistema que oferece diversos serviços
relacionados ao contexto discutido. O tipo de pesquisa que conduz a escolha do tema
debatido é exploratória procurando, através da revisão bibliográfica associada, apresentar
a melhor abordagem com relação à problemática estabelecida. Os resultados obtidos foram
analisados de forma qualitativa com base nos seguintes fatores chave de sucesso:
• Possibilidade de envio e recebimento de dados multimídia sem restrição de tamanho;
• Manutenibilidade do código produzido;
• Diminuição no consumo de energia e banda de internet por serviços implementados
de maneira eficiente e eficaz;
Desenvolvimento
Entende-se por Troca de Mensagens Instantâneas a funcionalidade que permite que
dois ou mais usuários compartilhem dados significativos - quer sejam textos ou arquivos
multimídia - de forma próxima ao tempo real. Esta funcionalidade, em geral, deve abstrair
o dispositivo de hardware e, mais recentemente, o requisito de abstração da plataforma de
software tem ganhado cada vez mais importância.
Uma implantação minimalista desse recurso deve contar com uma tela de conversa,
onde os usuários conectados são capazes de enviar e receber mensagens em tempo próximo
ao real; uma tela de listagens das conversas existentes, que é atualizada e ordenada de
acordo com as últimas mensagens recebidas. É importante ponderar a respeito do aspecto
evolutivo do projeto em questão ao analisar os componentes descritos.
As funcionalidades citadas representam exemplos de eventos que devem ser tratados
dentro de uma estrutura robusta e que facilite a evolução deste cenário, possibilitando a
implantação de novos recursos de acordo com o crescimento e expansão do aplicativo e seu
público alvo. Este fato exige que, desde o início, a arquitetura para tal aplicação esteja
preparada para comportar tais crescimentos de complexidade.
O primeiro ponto de preocupação para o desenvolvedor consiste no estabelecimento
de um mecanismo eficaz para notificação de eventos por parte do servidor de aplicação
para a aplicação cliente. Esta lógica é importante para gerenciar aspectos como consumo
de energia e banda de internet. Uma arquitetura ineficiente, do ponto de vista dos fatores
citados, consiste da chamada contínua de um serviço de verificação de novos eventos que,
de tempos em tempos, checa junto ao servidor de aplicação se existem novos eventos a
serem processados.
Essa abordagem se torna inviável quando o número de clientes da aplicação torna-
se demasiado grande, podendo sobrecarregar os servidores ou gerar elevado custo de
manutenção por exigir alto processamento por parte do mesmo. A fim de mitigar tais
problemas, a utilização do serviço de mensagens Firebase Cloud Message com o intuito
3

4. de notificar, em fluxo inverso, a aplicação cliente a partir do servidor de aplicação, será
utilizada na arquitetura proposta.
Outro fator que afeta negativamente a evolução e manutenção do projeto de software
trata-se da abordagem de tratamento para os múltiplos eventos que disparam alterações
nas camadas de persistência e de interface com o usuário. A partir do cenário debatido,
são elencados quatro eventos fundamentais:
• Evento 01: notificação push recebida do Servidor FCM;
• Evento 02: mensagens lidas a partir do Servidor de Aplicação;
• Evento 03: aviso para atualização de mensagens na tela;
• Evento 04: aviso para a atualização das conversas.
A quantidade de eventos pode alterar substancialmente conforme novos recursos são
adicionados na aplicação. É interessante notar que, por vezes, o processamento destes deve
ocorrer de forma assíncrona e paralela, fator este que aumenta, ainda mais, a complexidade
de processá-los.
Um padrão de projeto amplamente empregado no lido de situações como esta é o
Observer(GAMMA RICHARD HELM; VLISSIDES, 1995). A partir da implementação
deste padrão, é possível criar uma infraestrutura única, centralizadora, responsável por
conhecer todos os componentes do sistema que necessitam ser notificados de acordo com a
ocorrência de sucesso ou falha de um determinado evento. Esta estrutura passa então a
receber tais notificações e, por sua vez, repassa a informação recebida para aqueles que se
inscrevem para recebê-las.
As seções seguintes descreverão com mais detalhes os componentes a serem utiliza-
dos, provendo, através de diagramas de sequência e de classe, a descrição da arquitetura
pretendida por este trabalho.
0.2 Proposta de Arquitetura
A arquitetura proposta possui os seguintes objetivos:
• Prover um meio eficiente e eficaz, do ponto de vista do consumo de banda de internet
e energia, para a comunicação cliente-servidor;
• Viabilizar a transmissão de mensagens multimídia sem límite de tamanho para os
dados trafegados;
• Possibilitar a construção de uma arquitetura extensível para o tratamento de eventos
de rede (comunicação cliente-servidor) e de interface com o usuário;
4

5. 0.3 Comunicação cliente-servidor com uso do serviço Firebase Cloud Message
Sucessor do Google Cloud Message3, este serviço compõem o portfólio da empresa
Firebase4, provedora de serviços na nuvem e de back end as a service5. O serviço FCM,
cuja as especificações técnicas mais relevantes encontram-se descritas na tabela 1, lida com
todos os aspectos de enfileiramento de mensagens e entrega de notificações para e a partir
de aplicações clientes.
Tabela 1 – Especificação Técnica do Serviço FCM
Valor R$ 0,00
Limite de notificações diário Não há
Máxima carga útil por mensagem 4Kb
Protocolos Suportados HTTP e XMPP
Plataformas Suportadas Android. iOS e Web
Fonte – Produzido pelo autor com base nas informações
fornecidas em Firebase (2016).
Como definido em sua documentação pública, este serviço consiste de dois elementos
principais: componentes, descritos na tabela 2, e credenciais, descritos na tabela 36.
Tabela 2 – Componentes do serviço FCM
Nome Descrição
Servidor FCM
Aplicações servidoras responsáveis por receber mensagens up-
stream/downstream
Servidor de Aplicação
Aplicação servidora, independente de tecnologia, implementada por
quem utilizará serviço FCM
Aplicação cliente
Aplicação cliente que pertencente a uma das seguintes plataformas:
Android, IOS ou Web. Implementa a API cliente do FCM
Fonte – Produzido pelo autor com base nas informações fornecidas em Firebase (2016).
A figura 1 tem por objetivo elucidar, de maneira didática, o relacionamento entre
os elementos do serviço FCM. Os eventos que regem tais relacionamentos são dispostos
conforme uma ordem de execução que dá origem ao ciclo de vida do serviço. Este ciclo
possui duas ações principais, descritas nos diagramas de sequência das figuras 2 e 3 .
3
(GCM) Serviço de mensagens que provê a funcionalidade de envio de notificações a partir da nuvem para
dispositivos móveis multiplataforma. Foi anunciado em Agosto de 2013 como sucessor do framework
Android Cloud to Device Messaging (C2DM) e, na Google I/O de 2016, foi anunciada sua integração
com a web API Firebase. Atualmente o serviço encontra-se depreciado com provável retirada do mercado
em data futura, sendo os desenvolvedores altamente aconselhados a migrarem para nova plataforma
FCM. Dentre as melhorias advindas deste serviço - em comparação com o C2DM - cita-se: remoção do
limite diário de envio de notificações; melhorias no processo de autenticação e entrega de notificações;
novos end-points e parâmetros de mensagem; aumento do tamanho das mensagens.
4
Fundada em 2011 por Andrew Lee e James Tamplin; foi comprada pela Google em Outubro de 2014.
5
BasS consiste em um modelo de negócio que propicia serviços de back-end de sistemas - como armazena-
mento de dados, notificações push, webservices, dentre outros - através de uma plataforma na nuvem.
6
No contexto do serviço FCM, existem dois tipos de mensagem: downstream e upstream. A primeira
corresponde ao envio de dados a partir do Servidor de Aplicação para as Aplicações Cliente por
intermédio do Servidor FCM; a segunda diz respeito ao envio de mensagens a partir da Aplicação Cliente
5

6. Tabela 3 – Credenciais do serviço FCM
Nome Descrição
Identificador do Servidor Valor numérico único que identifica o componente Servidor de Aplicação
Chave da API
Identificador único do desenvolvedor responsável por prover o acesso a
utilização da API
Identificador da Aplicação
Registra a aplicação cliente para receber as notificações. Seu valor é
dependente da plataforma da aplicação cliente
Token de registro
Identificador da aplicação cliente utilizado pela conexão FCM para
identificar o aplicativo online
Fonte – Produzido pelo autor com base nas informações fornecidas em Firebase (2016).
Figura 1 – interação entre os componentes do serviço FCM
Figura 2 – diagrama de fluxo para a ação “registra cliente”
A arquitetura do serviço FCM compreende os requisitos de segurança relacionados
para outras Aplicações Clientes através do emprego do protocolo XMPP
6

7. Figura 3 – diagrama de fluxo para a ação “envia mensagem downstream”
ao tráfego de informações entre dispositivos - bem como garante o alto índice de entrega
das mensagens enviadas, graças ao enfileiramento e persistência das mesmas em caso de
indisponibilidade do dispositivo alvo. Detalhes adicionais a respeito da implantação do
serviço em uma plataforma especifica podem ser encontrados na documentação pública do
mesmo(FIREBASE, 2016).
Como descrito na tabela 1, o limite de tamanho para a carga útil das notificações é
de 4Kb. Além desta limitação, é comum encontrar requisitos não funcionais que inviabilizam
o tráfego de informações sensíveis por servidores terceiros - algo que ocorre no emprego
nativo do serviço FCM, pois, como demonstrado na figura 3, o conteúdo da mensagem
inevitavelmente trafega pelos Servidores FCM.
A fim de mitigar os riscos descritos, o serviço FCM pode ser utilizado não como
condutor do conteúdo útil da mensagem mas, como um meio de notificar os componentes
de que um evento ocorreu e está disponível para consulta. A partir desta abordagem
quando uma aplicação cliente envia uma mensagem para outra, a primeira comunica ao
servidor de aplicação - pela exposição de um webservice do tipo POST - informações como
7

8. o destinatário e o conteúdo da mensagem. O servidor de aplicação, por sua vez, envia
por meio do servidor FCM uma notificação para a aplicação cliente de destino. Uma vez
recebida a notificação, a aplicação cliente realiza uma chamada ao servidor de aplicação
solicitando as ações correspondentes ao evento recebido. O diagrama da figura 4 elucida
tal fluxo de eventos:
Figura 4 – diagrama de fluxo para o ação “trata mensagem recebida”
0.4 Módulo de tratamento de eventos
O terceiro objetivo da arquitetura proposta pode ser atingido através do emprego do
Padrão de Projeto Observer(GAMMA RICHARD HELM; VLISSIDES, 1995). O diagrama
apresentado na figura 5 detalha a interação entre classes para uma implantação deste
padrão no contexto debatido:
A classe EventCatalog é responsável por listar todos os eventos existentes passíveis
de receberem tratamento - quer sejam do tipo Network ou UI7. As classes NotificationCen-
ter e RegistrationCenter desempenham o papel de Publisher dentro da implementação do
padrão Observer, ou seja, armazenam uma referência para todos os objetos do tipo Sub-
scriber que serão notificados da ocorrência de algum evento. Mais especificamente, a classes
RegistrationCenter é responsável por apresentar uma interface pela qual implementações
do contrato de Subscriber registram-se ou retiram-se da fila de recebimento de notificações.
A interface TaskExecutor é responsável por prover o contrato que determina a
forma pela qual as notificações e seus conteúdos úteis irão trafegar, contando com dois
métodos distintos para cada estado de resposta de um dado evento: sucesso ou erro. O
7
Sigla para o termo inglês User Interface, ou Interface de Usuário
8

9. Figura 5 – módulo de tratamento de evento na aplicação cliente
conteúdo útil que acompanha o evento é enviado como parâmetro para cada um dos
métodos em questão.
A classe Postman provê uma interface para comunicação REST com o servidor
de aplicação. As implementações distintas poderão ser acionadas através da utilização
do padrão de projeto Delegate(GAMMA RICHARD HELM; VLISSIDES, 1995). Por fim,
a classe MailBox implementa a interface FirebaseMessageService provida no pacote do
serviço FCM. Em geral essa classe possui características de um serviço pois, mesmo que a
aplicação encontre-se fechada no dispositivo, os eventos de notificação tipo push devem ser
tratados.
Considerações finais
A implantação de um servido XMPP8 pode pode apresentar custos elevados -
tanto em tempo quanto em complexidade - ou inviáveis devido às licenças comerciais caso
implantações já existentes sejam consideradas - por exemplo, Ejjaberd (2016). Neste cenário,
a proposta de uma arquitetura simples e capaz de prover, minimamente, a funcionalidade
debatida apresenta-se como alternativa interessante.
A utilização do serviço FCM permite a comunicação de dois ou mais dispositivos sem
a necessidade de implantar serviços que checam de maneira rotineira atualizações disponíveis
no servidor de aplicação do sistema - quer seja través de APIs HTTP como proposto neste
trabalho ou através da implantação da especificação XMPP. Essa característica permite a
8
Extensible Messaging and Presence Protocol - XMPP (Jabber): protocolo escrito em XML especializado
para situações de comunicação em tempo real, incluindo a funcionalidade de mensagens instantâneas.
Existem diversas camadas de protocolos construídos em cima da camada central do XMPP, com vista a
atender cenários específicos garantindo a interoperabilidade adotada desde o início pelo XMPP. Tais
extensões, com frequência, oferecem implementações dos protocolos através de servidores já implantados
que devem ser encorporados ao sistema em desenvolvimento. O serviço FCM é capaz de ser interligar
com a especificação XMPP
9

10. economia de energia e de banda de internet do dispositivo que abriga a aplicação cliente,
através da realização de requisições apenas sob demanda. Estes dois fatores são essenciais
para o desenvolvimento de aplicações para dispositivos embarcados.
Dentre as desvantagens impostas pelo uso do serviço FCM, cita-se o limite de carga
útil que cada notificação pode conduzir e outra que diz respeito ao compartilhamento de
informações sensíveis com servidores de empresas terceiras. Ambas as situações podem ser
contornadas através do emprego do FCM como notificador de eventos, sem a condução da
carga útil em si, conforme demonstrado no fluxo de eventos do diagrama da figura 5.
Apesar da solução de contorno descrita no parágrafo anterior existem ainda outras
características que requerem atenção no momento de optar-se pela utilização da arquitetura
aqui proposta. O serviço FCM pertence a uma empresa privada que em algum momento
pode optar por retirar este produto de seu portfólio - fato este já presenciado pela
comunidade de desenvolvedores quando da retirada do framework Parse do mercado. O
arquiteto deve atentar-se, ainda, para questões técnicas relativas a entrega de mensagens.
Como mencionado anteriormente, o serviço FCM tenta realizar a entrega da
notificação para o dispositivo alvo quando solicitado. Caso este encontre-se offline, o
servidor FCM se encarrega de enfileiras as notificações enviadas e armazená-las para
posterior entrega. Eventos específicos das plataformas clientes são responsáveis por avisar o
servidor FCM de que o dispositivo alvo retomou acesso à internet. Em casos de aplicações
que apresentam requisitos de criticidade quanto à velocidade de entrega de dados, este
fato pode representar um grande problema por se ter de confiar em mecanismos que
encontram-se fora do seu domínio de controle. O cenário em que tal problema ocorre é
reforçado quando o usuário da aplicação encontra-se conectado a redes que, apesar de
sustentar comunicação com o dispositivo móvel, são incapazes de entregar os pacotes
envidos de/para o mesmo.
Uma vez solucionadas as questões relacionadas com a arquitetura de comunicação
entre cliente-servidor, há de se definir a melhor maneira de lidar com os eventos advindos
de tal interação, especialmente no que tange notificar a UI do aplicativo com os novos
estados da aplicação. Para tanto, a implantação do padrão de projeto Observer - associado
a outros como Delegate - descritos em detalhes na figura 5, é capaz de prover uma
infraestrutura extensível, ou seja, capaz de abrigar diversos eventos que possam surgir
conforme o desenvolvimento da aplicação. Essa característica é importante por facilitar a
construção do sistema com menor risco de erros bem como por reduzir os custos envolvidos
com a manutenção do software uma vez que este entre em estágio de produção.
Mediante os resultados obtidos, conclui-se que a arquitetura proposta apresenta
uma alternativa a implantação de um servidor XMPP, bem como se mostra como aborda-
gem viável quando comparada a terceirização da funcionalidade de troca de mensagens
instantâneas para aplicações terceirizadas.
10

11. A proposal for using Firebase Cloud Service (FCM) in the
context of instant message delivery for multi platform
applications
Edgar da Silva Fernandes‡‡
fernandes.s.edgar@gmail.com
2016, v-0.0.1
Abstract
This article proposes, through the use of Firebase Cloud Message service and the
study of Design Patterns for Software Systems, an architecture for implementing the
funcionality of instant message exchange for multi platform devices, allowing, at the
end of its implementation, a software module with effective and efficient energy and
internet consumption.
Keywords: Firebase Cloud Message. Google Cloud Message. Instant Message. Push
Notification
Referências
BURNS, M. Encrypted Messaging App Telegram Hits 100M Monthly Active Users, 350k
New Users Each Day. 2016. Disponível em: <https://techcrunch.com/2016/02/23/
encrypted-messaging-app-telegram-hits-100m-monthly-active-users-350k-new-users-each-day/
>. Acesso em: 25 jan. 2016. Citado na página 2.
EJJABERD. 2016. Documentação Pública: Ejjaberd. Disponível em: <https:
//www.ejabberd.im/>. Citado na página 9.
FIREBASE. 2016. Documentação Pública: Firebase Cloud Message. Disponível em:
<https://firebase.google.com/docs/cloud-messaging/?hl=pt-br>. Acesso em: 25 jan. 2016.
Citado 4 vezes nas páginas 2, 5, 6 e 7.
‡‡
Engenheiro da Computação
M.B.A. Projeto de Sistemas Móveis
Instituto de Gestão de Tecnologia da Informação - IGTI
contato: fernandes.s.edgar@gmail.com
11

12. GAMMA RICHARD HELM, R. J. E.; VLISSIDES, J. Design Patterns: Elements of
Reusable Object-Oriented Software. 1. ed. [S.l.: s.n.], 1995. Citado 3 vezes nas páginas 4, 8
e 9.
IBGE. Acesso à internet e à televisão e posse de telefone móvel celular para uso pessoal:
2014. 2016. 87 p. Disponível em: <http://biblioteca.ibge.gov.br/visualizacao/livros/
liv95753.pdf>. Acesso em: 25 jan. 2016. Citado na página 1.
PRIGG, M. WhatsApp now has over a BILLION users: Messaging ser-
vice reveals over 42bn messages and 250m videos now sent every day.
2016. Disponível em: <http://www.dailymail.co.uk/sciencetech/article-3427373/
WhatsApp-BILLION-users-Messaging-service-reveals-42bn-messages-250mn-videos-sent-day.
html>. Citado na página 2.
UM bilhão. 2016. Disponível em: <https://blog.whatsapp.com/>. Acesso em: 25 jan.
2016. Citado na página 2.
12