Estratégias de cache no Flutter: cache local, dados desatualizados e regras de atualização

Por que cache fica complicado em apps Flutter

Cache em um app móvel significa manter uma cópia dos dados por perto (na memória ou no dispositivo) para que a próxima tela renderize instantaneamente em vez de esperar pela rede. Esses dados podem ser uma lista de itens, um perfil de usuário ou resultados de busca.

O problema é que dados em cache frequentemente ficam um pouco errados. Os usuários percebem rápido: um preço que não atualiza, um contador de badges que parece preso, ou uma tela de detalhes mostrando informação antiga logo depois que foi alterada. O que torna isso difícil de depurar é o tempo. O mesmo endpoint pode parecer correto após um pull-to-refresh, mas errado depois de navegar para trás, ao retomar o app ou ao trocar de conta.

Há uma troca real. Se você sempre buscar dados frescos, as telas ficam lentas e saltam, e você gasta bateria e dados. Se você cachear agressivamente, o app parece rápido, mas as pessoas deixam de confiar no que veem.

Um objetivo simples ajuda: torne a frescura previsível. Decida o que cada tela pode mostrar (fresco, levemente desatualizado ou offline), quanto tempo os dados podem viver antes de serem atualizados e quais eventos devem invalidá-los.

Imagine um fluxo comum: o usuário abre um pedido e volta para a lista de pedidos. Se a lista vier do cache, pode mostrar o status antigo. Se você atualizar sempre, a lista pode piscar e parecer lenta. Regras claras como “mostrar cache instantaneamente, atualizar em segundo plano e atualizar ambas as telas quando a resposta chegar” tornam a experiência consistente na navegação.

Uma forma simples de pensar sobre cache e frescor

Um cache não é só “dados salvos.” É uma cópia salva mais uma regra de quando essa cópia ainda é válida. Se você armazena o payload mas ignora a regra, acaba com duas realidades: uma tela mostra informação nova, outra mostra a de ontem.

Um modelo prático é colocar cada item em cache em um de três estados:

• Fresco: seguro para mostrar com confiança.
• Desatualizado mas utilizável: mostrar agora, atualizar em segundo plano.
• Necessita atualizar: não confie, busque antes de mostrar (ou exiba um estado de carregamento).

Esse enquadramento mantém sua UI previsível porque ela pode reagir da mesma forma sempre que encontrar um dado estado.

Regras de frescor devem basear-se em sinais que você consiga explicar a um colega. Escolhas comuns são expiração por tempo (por exemplo, 5 minutos), mudança de versão (esquema ou versão do app), ação do usuário (pull to refresh, submeter, deletar) ou dica do servidor (ETag, timestamp last-updated ou uma resposta explícita de “cache invalido”).

Exemplo: uma tela de perfil carrega dados do usuário em cache instantaneamente. Se estiver desatualizado mas utilizável, mostra o nome e avatar em cache e depois atualiza silenciosamente. Se o usuário acabou de editar o perfil, esse é um momento de atualização obrigatória. O app deve atualizar o cache imediatamente para que todas as telas fiquem consistentes.

Decida quem é dono dessas regras. Na maioria dos apps, o melhor padrão é: a camada de dados é dona das regras de frescor e invalidação, a UI só reage (mostrar cache, mostrar carregando, mostrar erro), e o backend fornece pistas quando puder. Isso evita que cada tela invente suas próprias regras.

O que armazenar em cache (e o que não armazenar)

Um bom cache começa com uma pergunta: se esses dados estiverem um pouco antigos, isso prejudica o usuário? Se a resposta for “provavelmente não”, geralmente vale a pena armazenar localmente.

Dados muito lidos e que mudam devagar valem o cache: feeds e listas que as pessoas rolam, conteúdo tipo catálogo (produtos, artigos, templates) e dados de referência como categorias ou países. Configurações e preferências também pertencem aqui, junto com informações básicas de perfil como nome e URL do avatar.

O lado arriscado é tudo que é financeiro ou crítico no tempo. Saldos, status de pagamento, disponibilidade de estoque, horários de consulta, ETAs de entrega e “último visto online” podem causar problemas reais se estiverem desatualizados. Ainda dá para cachear por velocidade, mas trate o cache como um placeholder temporário e force atualização em pontos de decisão (por exemplo, antes de confirmar um pedido).

Estado derivado da UI é outra categoria. Salvar a aba selecionada, filtros, consulta de busca, ordem de ordenação ou posição de rolagem pode tornar a navegação suave. Também pode confundir quando escolhas antigas reaparecem inesperadamente. Uma regra simples funciona bem: mantenha estado de UI em memória enquanto o usuário estiver naquele fluxo, mas reinicie quando ele “recomeçar” intencionalmente (como voltar para a tela inicial).

Evite cachear dados que criem risco de segurança ou privacidade: segredos (senhas, chaves de API), tokens de uso único (códigos OTP, tokens de reset), e dados pessoais sensíveis a menos que precise realmente de acesso offline. Nunca armazene detalhes completos de cartão ou qualquer coisa que aumente o risco de fraude.

Em um app de compras, cachear a lista de produtos é um grande ganho. A tela de checkout, porém, deve sempre atualizar totais e disponibilidade antes da compra.

Escolhendo uma camada de cache local: memória, disco, banco de dados

A maioria dos apps Flutter precisa de um cache local para telas carregarem rápido e não piscarem vazias enquanto a rede acorda. A decisão chave é onde os dados cacheados vivem, porque cada camada tem velocidade, limites de tamanho e comportamento de limpeza diferentes.

Um cache em memória é o mais rápido. Ótimo para dados que você acabou de buscar e vai reutilizar enquanto o app ficar aberto, como o perfil atual, últimos resultados de busca ou um produto recentemente visualizado. O tradeoff é simples: some quando o app é finalizado, então não ajuda em cold starts ou uso offline.

Armazenamento em disco chave-valor serve para itens pequenos que você quer manter entre reinícios. Pense em preferências e blobs simples: flags de feature, “última aba selecionada” e pequenas respostas JSON que raramente mudam. Mantenha intencionalmente pequeno. Ao começar a jogar listas grandes em armazenamento chave-valor, atualizações ficam complicadas e o bloat aparece fácil.

Um banco de dados local é melhor quando seus dados são maiores, estruturados ou precisam de comportamento offline. Também ajuda quando você precisa de consultas (“todas as mensagens não lidas”, “itens no carrinho”, “pedidos do mês passado”) em vez de carregar um grande blob e filtrar em memória.

Para manter o cache previsível, escolha uma loja primária por tipo de dado e evite guardar o mesmo dataset em três lugares.

Uma regra prática:

• Memória: reutilizar durante a sessão atual
• Chave-valor no disco: itens pequenos, simples, que mudam raramente
• Banco de dados: grande, estruturado, offline-friendly

Também planeje tamanho. Decida o que significa “grande demais”, quanto tempo manter itens e como limpar. Por exemplo: limite resultados de busca em cache às últimas 20 consultas e remova registros mais velhos que 30 dias para que o cache não cresça silenciosamente para sempre.

Regras de atualização para dados que o usuário pode tolerar desatualizados

Regras de atualização devem ser simples o bastante para explicar em uma frase por tela. Aí é que o cache sensato compensa: telas rápidas e app confiável.

A regra mais simples é TTL (time to live). Armazene dados com timestamp e trate como frescos por, digamos, 5 minutos. Depois disso, tornam-se desatualizados. TTL funciona bem para dados "agradáveis de ter" como feed, categorias ou recomendações.

Uma melhoria útil é dividir TTL em soft TTL e hard TTL.

Com soft TTL, você mostra dados em cache imediatamente, atualiza em segundo plano e atualiza a UI se algo mudou. Com hard TTL, você para de mostrar dados antigos quando expiram. Ou bloqueia com um loader ou exibe um estado “offline/tente novamente”. Hard TTL serve quando estar errado é pior que ser lento, como saldos, status de pedido ou permissões.

Se seu backend suportar, prefira “atualizar só quando mudou” usando ETag, updatedAt ou campo de versão. O app pode perguntar “isso mudou?” e pular download do payload completo quando nada for novo.

Um padrão amigável é stale-while-revalidate: mostrar agora, atualizar silenciosamente e redesenhar apenas se o resultado for diferente. Dá velocidade sem piscadas aleatórias.

Frescor por tela frequentemente fica assim:

• Feed inicial: soft TTL (1 a 5 minutos), refresh em background na abertura
• Perfil: soft TTL (15 a 60 minutos), refresh após edições
• Mensagens: hard TTL ou TTL muito curto (0 a 10 segundos), refresh ao retomar o app
• Checkout/pedido: hard TTL, sempre confirmar com o servidor
• Configurações/listas estáticas: TTL longo (dias), atualizar em atualização do app

Escolha regras com base no custo de estar errado, não só no custo de buscar.

Quando invalidar cache (gatilhos que importam)

Invalidação de cache começa com uma pergunta: que evento torna os dados em cache menos confiáveis que o custo de refetch? Se você escolher um conjunto pequeno de gatilhos e segui-los, o comportamento será previsível e a UI parecerá estável.

Gatilhos que realmente importam em apps reais:

• Ação do usuário: pull-to-refresh, tocar em Retry depois de um erro, ou retornar a uma tela onde o usuário espera o “mais recente” (como uma caixa de entrada).
• Ciclo de vida: início do app (preaqueça o cache, depois atualize) e retorno do background (atualize apenas se for mais velho que seu TTL).
• Identidade: login, logout, troca de conta. Trate como limite rígido: limpe caches escopados ao usuário e cancele requisições em andamento vinculadas ao usuário antigo.
• Ações de escrita (CRUD): após create, update ou delete, atualize o cache imediatamente para manter telas consistentes. Refaça fetch só se o servidor puder aplicar regras extras (ordenacao, permissões, campos calculados).
• Segurança: atualização do app, mudança de esquema local, mudanças em feature flags. Aumente a versão do cache e limpe ou migre.

Exemplo: o usuário edita a foto do perfil e volta. Se você depender só de atualização baseada em tempo, a tela anterior pode mostrar a imagem antiga até o próximo fetch. Em vez disso, trate a edição como gatilho: atualize o objeto de perfil cacheado na hora e marque como fresco com novo timestamp.

Mantenha regras de invalidação pequenas e explícitas. Se você não consegue apontar o evento exato que invalida uma entrada de cache, você vai atualizar demais (UI lenta e saltante) ou de menos (telas desatualizadas).

Passo a passo: implementar um fluxo de cache previsível

Comece listando suas telas-chave e os dados que cada uma precisa. Não pense em endpoints — pense em objetos visíveis para o usuário: perfil, carrinho, lista de pedidos, item de catálogo, contador de não lidos.

Em seguida, escolha uma fonte de verdade por tipo de dado. No Flutter, geralmente é um repositório que esconde de onde os dados vêm (memória, disco, rede). As telas não devem decidir quando bater na rede. Elas pedem o repositório e reagem ao estado retornado.

Um fluxo prático:

• Mapeie telas aos dados necessários (e se são escopados ao usuário ou compartilhados).
• Direcione todas leituras e escritas por um repositório por tipo de dado.
• Salve dados com metadados: savedAt, versão de esquema/app e ownerUserId.
• Defina comportamento da UI para quatro estados: fresco, desatualizado, carregando, erro.
• Adicione dois caminhos de atualização: manual (pull to refresh) e background (refresh silencioso quando desatualizado).

Metadados são o que tornam regras aplicáveis. Se ownerUserId mudar (logout/login), você pode descartar ou ignorar linhas antigas do cache imediatamente em vez de mostrar os dados do usuário anterior por um instante.

Para comportamento da UI, decida desde o começo o que “desatualizado” significa. Uma regra comum: mostrar dados desatualizados instantaneamente para não deixar a tela em branco, iniciar um refresh em background e atualizar quando novos dados chegarem. Se o refresh falhar, mantenha o dado desatualizado visível e mostre um erro pequeno e claro.

Depois, fixe as regras com alguns testes simples:

• TTL: dados ficam desatualizados após X minutos.
• Logout: cache escopado ao ownerUserId é limpo ou isolado.
• Update: escrita local atualiza cache imediatamente e depois sincroniza.
• Bump de versão: cache antigo é ignorado após mudança de versão do esquema/app.
• Erro: dados desatualizados permanecem visíveis quando refresh falha.

Essa é a diferença entre “temos cache” e “nosso app se comporta igual sempre”.

Manter telas consistentes na navegação

Nada quebra confiança mais rápido do que ver um valor na lista, abrir detalhes, editar e voltar para ver o valor antigo. Consistência na navegação vem de fazer cada tela ler da mesma fonte.

Uma regra sólida: buscar uma vez, salvar uma vez, renderizar muitas vezes. Telas não devem chamar o mesmo endpoint independentemente e manter cópias privadas. Coloque dados cacheados em um store compartilhado (sua camada de state management) e deixe lista e detalhe observarem os mesmos dados.

Faça uma fonte de verdade

Mantenha um único lugar que seja dono do valor atual e do frescor. Telas podem pedir refresh, mas não devem gerir seus próprios timers, retries e parsing.

Hábitos práticos que evitam “duas realidades”:

• Compartilhe estado entre rotas (um store/provider por feature, não por widget).
• Deduplicate requisições em andamento para que duas telas não busquem a mesma coisa duas vezes.
• Na navegação de volta, releia do store em vez de ressuscitar estado antigo do widget.
• Após edições, atualize o store imediatamente para que todas as telas reflitam a mudança.

Mostre o que está acontecendo

Mesmo com boas regras, usuários às vezes verão dados desatualizados (offline, rede lenta, app em background). Torne isso óbvio com sinais pequenos e calmos: um carimbo “Atualizado agora”, um indicador sutil “Atualizando…” ou um badge “Offline”.

Para edições, updates otimistas frequentemente funcionam melhor. Exemplo: o usuário altera o preço de um produto na tela de detalhes. Atualize o store compartilhado na hora para que a lista mostre o novo preço ao voltar. Se o salvamento falhar, reverta e mostre um erro curto.

Erros comuns de cache e como evitá-los

A maioria das falhas de cache é chata: o cache funciona, mas ninguém consegue explicar quando deve ser usado, quando expira e quem é dono.

A primeira armadilha é cachear sem metadados. Se só armazenar o payload, você não sabe se está velho, qual versão do app gerou ou a qual usuário pertence. Salve ao menos savedAt, um número de versão simples e userId. Esse hábito evita muitos bugs de “por que esta tela está errada?”.

Outro problema comum é múltiplos caches para os mesmos dados sem dono. Uma lista mantém uma lista em memória, um repositório grava no disco e uma tela de detalhes busca de novo e salva em outro lugar. Escolha uma fonte de verdade (geralmente a camada de repositório) e faça todas as telas lerem por ela.

Trocas de conta são um perigo frequente. Se alguém fizer logout ou trocar de conta, limpe tabelas e chaves escopadas ao usuário. Caso contrário você pode mostrar a foto do perfil ou pedidos do usuário anterior por um instante, o que parece uma violação de privacidade.

Correções práticas:

• Armazene entradas de cache com savedAt, versão e userId, não só JSON.
• Defina um dono por dataset (por exemplo, ProfileRepository é dono do perfil).
• Use a regra “mostrar cache agora, atualizar em background” para a maioria das telas.
• Rate-limit de refresh (por exemplo, um refresh de rede por X minutos por endpoint).
• Exiba erros de refresh (banner pequeno ou retry) e defina um tempo máximo de staleness.

Exemplo: sua lista de produtos carrega instantaneamente do cache e depois atualiza silenciosamente. Se o refresh falhar, continue mostrando o cache mas deixe claro que pode estar desatualizado e ofereça Retry. Não bloqueie a UI quando o cache é suficiente.

Checklist rápido antes de enviar

Antes do lançamento, transforme o cache de “parece ok” em regras testáveis. Usuários devem ver dados que fazem sentido mesmo após navegar, ficar offline ou entrar com outra conta.

Defina frescor e comportamento de atualização

Para cada tela, decida quanto tempo os dados podem ser considerados frescos. Pode ser minutos para dados que mudam rápido (mensagens, saldos) ou horas para dados que mudam devagar (configurações, categorias). Então confirme o que acontece quando não estiver fresco: refresh em background, refresh ao abrir ou pull-to-refresh manual.

Trave invalidação e metadados do cache

Para cada tipo de dado, decida quais eventos devem limpar ou ignorar o cache. Gatilhos comuns: logout, editar item, troca de conta e atualizações do app que mudem a forma dos dados.

Certifique-se de que entradas em cache armazenem um pequeno conjunto de metadados junto ao payload:

• savedAt
• userId
• version (esquema/versão do app)
• source (opcional: network vs local)

Mantenha ownership claro: um repositório por tipo de dado (por exemplo, ProductsRepository), não por widget. Widgets pedem dados, não decidem regras de cache.

Decida e teste também o comportamento offline. Confirme o que cada tela mostra a partir do cache, quais ações ficam desabilitadas e qual texto exibir (“Mostrando dados salvos”, com controle de refresh visível). Refresh manual deve existir em toda tela com cache e ser fácil de encontrar.

Exemplo: um app de catálogo que se mantém consistente

Imagine um app de loja simples com três telas: catálogo (lista), detalhes do produto e aba Favoritos. Usuários rolam o catálogo, abrem um produto e tocam no coração para favoritar. O objetivo é parecer rápido mesmo em redes lentas, sem mostrar discrepâncias confusas.

Cache localmente o que ajuda a renderizar instantaneamente: páginas de catálogo (IDs, título, preço, URL da miniatura, flag de favorito), detalhes do produto (descrição, especificações, disponibilidade, lastUpdated), metadados de imagem (URLs, tamanhos, chaves de cache) e os favoritos do usuário (um conjunto de IDs de produto, opcionalmente com timestamps).

Quando o usuário abre o catálogo, mostre resultados em cache imediatamente e depois revalide em background. Se chegarem dados frescos, atualize só o que mudou e mantenha a posição de rolagem.

Para o toggle de favorito, trate como ação que precisa ser consistente. Atualize o conjunto local de favoritos na hora (optimistic update), depois atualize qualquer linha de produto em cache e os detalhes do produto daquele ID. Se a chamada de rede falhar, reverta e mostre uma mensagem curta.

Para manter a navegação consistente, direcione tanto os badges da lista quanto o ícone de coração dos detalhes à mesma fonte de verdade (seu cache local ou store), não a estados separados das telas. O coração da lista atualiza assim que você volta dos detalhes, a tela de detalhes reflete mudanças feitas na lista e a contagem da aba Favoritos bate em todo lugar sem esperar refetch.

Adicione regras simples de refresh: cache do catálogo expira rápido (minutos), detalhes do produto um pouco mais tarde, e favoritos nunca expiram mas sempre se reconciliam após login/logout.

Próximos passos: documente regras e facilite a manutenção

O cache deixa de ser misterioso quando o time aponta para uma página de regras e concorda no que deve acontecer. O objetivo não é perfeição. É comportamento previsível que se mantém entre releases.

Escreva uma pequena tabela por tela e mantenha curta o suficiente para revisar em mudanças: nome da tela e dado principal, local e chave do cache, regra de frescor (TTL, baseada em evento ou manual), gatilhos de invalidação e o que o usuário vê durante a atualização.

Adicione logging leve enquanto você afina. Registre hits e misses de cache e por que um refresh aconteceu (TTL expirou, usuário puxou para atualizar, app retomou, mutação completou). Quando alguém relatar “essa lista está errada”, esses logs tornam o bug solucionável.

Comece com TTLs simples e refine conforme os usuários notarem. Um feed de notícias pode aceitar 5 a 10 minutos de staleness, enquanto uma tela de status de pedido pode precisar de atualização ao retomar e após qualquer ação de checkout.

Se você está construindo um app Flutter rapidamente, ajuda delinear sua camada de dados e regras de cache antes de implementar. Para times usando Koder.ai (koder.ai), o modo de planejamento é um lugar prático para escrever essas regras por tela antes de construir.

Ao ajustar comportamento de refresh, proteja telas estáveis enquanto experimenta. Snapshots e rollback economizam tempo quando uma nova regra introduz flicker, estados vazios ou contagens inconsistentes na navegação.