Artigo de Shailen Tuli, publicado originalmente pelo Android Developers Blog. A tradução foi feita pela Redação iMasters com autorização.

***

 

Estamos lançamos o código-fonte para o aplicativo oficial Google I/O 2017 para Android.

O aplicativo deste ano modifica substancialmente a funcionalidade existente e adiciona vários novos recursos. Ele também expande a pilha de tecnologia para usar Firebase. Nesta postagem, iremos destacar várias mudanças notáveis no aplicativo, bem como suas considerações de projeto.

O recurso mais proeminente para 2017 é o evento sistema de reserva, projetado para ajudar a economizar o tempo dos participantes e fornecer uma experiência de reunião aperfeiçoada. Os participantes registrados podem reservar sessões e se juntar a listas de espera antes e durante a conferência; uma reserva fornece entrada rápida para sessões sem ter que esperar em longas filas. Os dados da reserva são sincronizados com os crachás de conferência dos participantes, permitindo que a equipe organizadora do evento verifique as reservas usando telefones habilitados para NFC. Não só o recurso de reserva foi incrivelmente popular, mas os dados de reserva ajudaram a equipe organizadora do evento a mudar o tamanho das salas das sessões antes e durante a I/O para ajustar a demanda real de assentos.

O recurso de reserva foi implementado usando Firebase Realtime Database (RTDB) e Cloud Functionsfor firebase. O RTDB forneceu sincronização fácil em dispositivos de usuário – nós apenas tivemos que implementar um ouvinte em nosso código para receber atualizações de banco de dados. O RTDB também forneceu suporte off-line padrão, permitindo que os dados da conferência estivessem disponíveis mesmo em relação à conectividade de rede intermitente durante a viagem. Uma Função da Nuvem processou solicitações de reserva em segundo plano para o usuário, usando transações para garantir a correção do estado (impedindo que usuários maliciosos tomassem muitos assentos!) e se comunicando com o sistema de credenciamento do evento.

Como nos anos anteriores, usamos um ContentProvider como uma camada de abstração em todos os dados do aplicativo, o que significava que precisávamos descobrir como integrar dados RTDB com o ContentProvider. Tivemos que negociar entre ter dois caches locais para dados: 1) o banco de dados SQLite local existente acessado através do ContentProvider e 2) o cache local criado pelo RTDB para facilitar o acesso off-line. Nós decidimos integrar todos os dados do aplicativo no ContentProvider: sempre que os dados de reserva para o usuário mudassem em RTDB, atualizamos o ContentProvider, tornando-o a fonte única de confiança para os dados do aplicativo em todos os momentos. Isso significava que precisávamos manter conexões abertas ao RTDB somente em uma única tela, a Atividade de Detalhes da Sessão, onde os usuários podem gerenciar ativamente suas reservas. Os dados de reserva exibidos em outras partes do aplicativo foram suportados pelo ContentProvider. No modo off-line, ou no caso de uma conexão inconstante ou atrasada para o RTDB, podemos obter o último estado conhecido das reservas do usuário a partir do ContentProvider.

Nós também tivemos que descobrir bons padrões para integrar o RTDB na lógica de sincronização geral do IOSched, especialmente desde que o RTDB vem acompanhado de um modelo de sincronização muito diferente da abordagem de ping-and-fetch que estávamos usando no aplicativo. Nós decidimos continuar usando os Endpoints da Nuvem para sincronizar os dados do usuário em dispositivos e com os clients da Web e iOS (os dados emsi foram armazenados no Datastore). Enquanto o RTDB fornece sincronização de dados por padrão, queríamos garantir que os dados de reserva de um usuário estivessem atualizados em todos os dispositivos, mesmo que o aplicativo não estivesse em primeiro plano. Utilizamos uma Função de Nuvem para integrar dados de reserva de RTDB no fluxo de sincronização: uma vez que os dados de reserva para um usuário mudaram em RTDB, a função atualizou o endpoint, o que desencadeou uma mensagem a jusante da Firebase Cloud Messaging para todos os dispositivos do usuário, que então programou sincronizações de dados.

 

 

O aplicativo deste ano também apresentou um Feed para informar usuários sobre desenvolvimentos hora a hora nas I/O (a maioria dos usuários do aplicativo era remota e o Feed era uma janela da conferência para eles). O Feed também foi alimentado por RTDB, com dados enviados para o servidor usando um CMS simples. Utilizamos uma Função de Nuvem para monitorar dados de feed RTDB; quando os dados de feed foram atualizados no servidor, a Função enviou uma mensagem a jusante do Cloud Messaging aos clients, que vislumbraram visualmente a presença de novos itens de feed para o usuário.

Em 2015 e 2016, adotamos uma arquitetura MVP para a IOSched e continuamos usando isso este ano. Esta arquitetura nos proporciona uma boa separação de problemas, facilita o teste e, em geral, torna nosso código mais limpo e mais fácil de manter. Para o recurso Feed, decidimos experimentar uma implementação MVP mais leve, inspirada no Android Architecture Blueprints, que forneceu a modularidade necessária ao mesmo tempo que se mostrou muito fácil de se conceituar. O objetivo aqui era tanto pedagógico quanto prático: queríamos mostrar um padrão MVP alternativo para desenvolvedores; também queríamos mostrar uma arquitetura que fosse adequada para nossas necessidades para esse recurso.

Pela primeira vez, o IOSched fez uso intensivo da Firebase Remote Config. No passado, nos percebemos incapazes de informar os usuários quando os dados de não-sessão – informações de wifi, horário de transporte, códigos de desconto para passeios, etc. – mudavam antes ou durante a conferência. Forçar uma atualização do aplicativo não era viável; nós só queríamos que os valores padrão no aplicativo fossem atualizáveis. Usar a configuração remota resolveu facilmente este problema para nós.

No final, acabamos com um sistema de três níveis para informar os usuários sobre as mudanças:

1. As alterações dos dados da conferência e dos dados do usuário foram comunicadas através do Cloud Messaging e sincronizações de dados (ping e modelo de busca).
2. As alterações de dados de feed foram controladas através de RTDB.
3. As mudanças nas constantes no aplicativo foram controladas através da Configuração Remota.

 

Planos futuros

Embora estejamos lançando o código de 2017, ainda temos trabalho à nossa frente nos próximos meses. Estaremos atualizando o código a fim de seguir padrões modernos para o processamento em segundo plano (e tornando o nosso aplicativo compatível com “O”) e, no futuro, adotaremos os Componentes de Arquitetura do Android para simplificar o design geral do aplicativo. Os desenvolvedores podem seguir as alterações ao código no GitHub.

 

***