- Um aplicativo React Native que você possa executar localmente.
- Um projeto do LogBrew. Consulte Projetos e configuração.
- Uma CLI conectada à sua conta. Consulte Usar a CLI.
Instale o SDK
Instale os dois pacotes no diretório do aplicativo. Mantenha as dependências de React e React Native do aplicativo:Crie uma chave de SDK do projeto
Dê ao aplicativo uma chave de SDK com escopo de projeto e só de escrita. O Expo coloca todo valorEXPO_PUBLIC_* no bundle do aplicativo. Nunca coloque uma
credencial da conta ou de servidor nessa variável.
A CLI v0.1.32 ou mais recente cria uma chave para um projeto existente. Ela
não cria um projeto novo. Encontre o ID do projeto:
--abandon-retry.
Mantenha o arquivo da chave fora do controle de versão. Não use a credencial
da conta que autorizou a CLI. Para desenvolvimento local com Expo, coloque a
chave em um arquivo .env.local ignorado, na raiz do aplicativo:
process.env.EXPO_PUBLIC_LOGBREW_CLIENT_KEY
no módulo de configuração abaixo. Recarregue o aplicativo por completo depois
de mudar o valor. Para a configuração em tempo de build, consulte
variáveis de ambiente do Expo.
Um aplicativo React Native sem Expo carrega a chave pela própria
configuração.
Crie o cliente
Coloque esta configuração em um único módulo que o aplicativo carrega na inicialização. Não crie um cliente a cada renderização. Coloque o serviço, o ambiente e a versão emcontext:
stopAppStateListener() quando o aplicativo
for desmontado.
Com a fila nativa, só um cliente ativo pode usar uma chave. Um segundo cliente
com a mesma chave falha com configuration_error. Esse é mais um motivo para
criar o cliente uma única vez.
Envie e encontre o log de teste
ChameverifyLogBrewSetup() uma vez a partir de uma ação de teste só para
desenvolvimento. Aguarde o resultado e trate uma promise rejeitada. Não
imprima a chave nem o lote de eventos.
Um resultado 2xx com batches acima de 0 mostra que o LogBrew aceitou o
lote. Um flush vazio retorna 204 com 0 tentativas e 0 lotes, porque a
entrega automática pode enviar o evento antes. Nos dois casos, leia o log
salvo com a CLI:
RecordingTransport.alwaysAccept() serve só para testes locais. Ele retorna
um 202 sintético e não envia nenhuma requisição.
Entrega offline e depois de reiniciar
Leiaclient.deliveryHealth().storage no aplicativo em execução:
persistent: o cliente usa a fila nativa. Os eventos pendentes são carregados de novo depois que o aplicativo reinicia.memory: os eventos pendentes se perdem quando o runtime JavaScript reinicia.
persistentQueue: "auto" usa a fila nativa quando o binário do
aplicativo contém o módulo nativo do LogBrew. O Expo Go e binários mais
antigos usam memória. Uma atualização só de JavaScript não consegue adicionar
o módulo nativo.
Se um aplicativo em produção precisa manter a entrega depois de reiniciar,
defina persistentQueue: "required". Assim, a criação do cliente falha com
configuration_error quando a fila nativa não existe. Gere o build do
aplicativo de novo com o módulo nativo. Use persistentQueue: "disabled" só
quando você quiser uma fila em memória.
A fila nativa guarda no máximo 1.000 eventos e 4 MiB de dados de eventos.
Limites menores do cliente também se aplicam. Os eventos na fila nativa
mantêm os IDs depois de uma reinicialização.
A entrega é “pelo menos uma vez”, então uma nova tentativa pode enviar um
evento duas vezes. Quando o ID e o conteúdo do evento correspondem a um evento
que o LogBrew já aceitou, o LogBrew não o armazena de novo. Um flush em
segundo plano é uma tentativa, não uma prova de entrega. Teste a captura
offline e uma reinicialização do aplicativo. Depois, encontre o evento salvo
no projeto.
Leia o estado da entrega
client.deliveryHealth() retorna o estado da fila e da entrega sem o
conteúdo dos eventos. Leia primeiro estes campos:
Escolha o conteúdo do log
Mantenha cada mensagem curta e específica. Descreva o que aconteceu no aplicativo, como uma requisição com falha ou uma nova tentativa agendada. Não inclua nomes, endereços de e-mail, tokens de acesso, valores de formulários ou corpos de requisição. Use a gravidade que corresponde ao evento:info, warning, error ou
critical. Mantenha o serviço, o ambiente e a versão consistentes para
encontrar sinais relacionados.
npx react-native log-ios e npx react-native log-android mostram os logs
locais do dispositivo. Eles não consultam o LogBrew. Consulte
depuração de código nativo no React Native.
Corrija uma verificação com falha
Umflush() com falha é rejeitado com um código de erro do SDK. Mantenha
chaves e corpos de eventos fora dos relatórios de erro.
Para mais verificações, consulte
Solução de problemas.
Mantenha os Debug IDs do Expo nos bundles de produção
Crie a configuração do Metro do Expo pelo LogBrew. Assim, o bundle de runtime recebe o mesmo Debug ID que o source map dele:withLogBrewMetroConfig(). Não use esse wrapper com Expo. Se usar, o build de
produção para com uma mensagem que aponta para getLogBrewExpoConfig().