Estratégias De Carregamento Do Firebase Remote Config

Post de Todd Kerpelman, publicado originalmente pelo Google Developers Brazil. Se você é fã do nosso canal FirebaseDevelopers, deve ter percebido que publicamos pouco tempo atrás um vídeo apenas sobre isso como carregar valores do Remote Config no seu aplicativo da melhor forma. No entanto, sabemos que alguns preferem ler a olhar a um vídeo, sendo assim, pensamos em oferecer este tema em modelo de texto bem como!

Você oferece ao Remote Config um monte de valores padrão. Isto acontece localmente no equipamento, no código ou inserindo os valores a partir de um arquivo xml ou plist lugar. Depois, você poderá chamar fetch() pra baixar os novos valores da nuvem. Em conclusão, você chama activateFetched() pra substituir os valores modelo originalmente acordados por estes valores baixados.

Neste momento, quando você consulta um determinado valor no Remote Config, recebe o valor atualizado da nuvem ou qualquer padrão que você tenha fornecido localmente. E isso é parabéns, por causa de você pode conectar o seu aplicativo pra recolher todos esses valores pelo Remote Config. Você ainda mantém as chamadas de rede convenientemente pequenas, uma vez que só está baixando os valores que são diferentes dos seus valores modelo, contudo sem demora com a flexibilidade de poder modificar cada porte do aplicativo depois na nuvem. Bem acessível, não é?

• Arthur Veríssimo


• Corporações dobram faturamento com preços menores e novos serviços


• três Dicas pra vender mais


• 5 cuidados básicos antes de investir em banco médios


• Ceder espaço às estratégias de comprido prazo


• seis - Faça um excelente pós-venda

E, em extenso fração, é fácil mesmo. Essa estratégia é a mais claro e direta, então, ela é a mais comum nos nossos aplicativos e tutoriais de exemplo. A ideia é que, após baixar estes novos valores da nuvem, você chame activateFetched() no gerenciador de conclusão para aplicá-los já e, depois, libere o aplicativo para escoltar pra atualização. Essa estratégia é bem bacana, já que permite que o usuário entre direto no aplicativo. Contudo, é um pouco estranho que o seu aplicativo possa variar coisas como texto de botões, a diagramação da IU ou outros valores críticos no tempo em que o usuário está usando, o que poderá gerar uma experiência de uso mau. Uma estratégia bem comum é exibir uma tela de carregamento no momento em que o usuário inicializa o aplicativo.

Definitivamente, a grande desvantagem por esse caso é que imediatamente você tem uma tela de carregamento. É preciso tempo e empenho pra criá-la, e também ser uma barreira para os usuários que entram no aplicativo. Mas, se o aplicativo agora tem uma tela de carregamento porque você tem que fazer outras tarefas e/ou chamadas de rede na inicialização, essa poderá ser uma boa estratégia. É só buscar os valores da configuração remota junto das novas tarefas de inicialização que são feitas. Porém, se o aplicativo não tiver uma tela de carregamento, recomendo tentar uma estratégia alternativa.

Essa parece um tanto incomum, porém deixe eu esclarecer: no momento em que o usuário inicializa o aplicativo, você chama activateFetched() neste instante. Isso aplicará todos os valores antigos buscados antecipadamente pela nuvem. Depois, o usuário poderá começar a interagir prontamente com o aplicativo. No tempo em que isto, você inicia uma chamada de fetch() assíncrona pra buscar novos valores da nuvem.

E no gerenciador de conclusão dessa chamada, você não faz nada. Olha que formosura: você não necessita nem ao menos englobar um gerenciador de conclusão. Esses valores buscados na nuvem continuarão armazenados localmente no mecanismo até o usuário chamar activateFetched pela próxima vez em que inicializar o aplicativo. Essa estratégia é bem curioso, pelo motivo de os usuários conseguem começar a utilizar o aplicativo prontamente e o aplicativo não fica com aquele modo estranho de variar a interface de repente no meio do exercício.

A desvantagem óbvia é que é necessário que os usuários iniciem duas sessões para enxergar os valores atualizados da configuração remota. Você tem que decidir se esse é ou não o melhor comportamento para o teu aplicativo. Se você utiliza o Remote Config pra, digamos, ajustar alguns valores no seu jogo de defesa de torre, essa abordagem tem que funcionar bem. No entanto, se você o utiliza para enviar a "mensagem do dia" ou tema específico de acordada data (como um design sazonal do seu aplicativo), ela podes não funcionar tão bem.

Uma vantagem do Remote Config é que ele pode informar quando a última chamada de fetch() bem-sucedida aconteceu. E portanto, você podes criar muitas estratégias híbridas nas quais primeiro você verifica há quanto tempo a pesquisa mais recente dos detalhes do Remote Config aconteceu. Se for bem recente (digamos, nas últimas quartenta e oito horas), você pode acompanhar em frente e botar a estratégia de colocar o lote de valores mais recente e realizar outra busca para o próximo exercício.