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:
- 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).
- As alterações de dados de feed foram controladas através de RTDB.
- 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.
***