- Un’app React Native che puoi eseguire in locale.
- Un progetto LogBrew. Consulta Progetti.
- Una CLI con accesso eseguito. Consulta Configurazione della CLI.
Installa l’SDK
Installa entrambi i pacchetti nella directory dell’app. Mantieni le dipendenze React e React Native dell’app:Crea una chiave SDK del progetto
Assegna all’app una chiave SDK limitata al progetto e di sola scrittura. Expo inserisce ogni valoreEXPO_PUBLIC_* nel bundle dell’app. Non inserire mai
una credenziale dell’account o del server in quella variabile.
La CLI v0.1.32 o successiva crea una chiave per un progetto esistente. Non
crea un nuovo progetto. Trova l’ID del progetto:
--abandon-retry.
Tieni il file della chiave fuori dal controllo del codice sorgente. Non usare
la credenziale dell’account che ha autorizzato la CLI. Per lo sviluppo locale
con Expo, inserisci la chiave in un file .env.local ignorato, nella radice
dell’app:
process.env.EXPO_PUBLIC_LOGBREW_CLIENT_KEY
nel modulo di configurazione qui sotto. Ricarica completamente l’app dopo aver
cambiato il valore. Consulta
Variabili d’ambiente di Expo
per la configurazione in fase di build. Un’app React Native senza Expo carica
invece la chiave tramite la propria configurazione.
Crea il client
Inserisci questa configurazione in un solo modulo che l’app carica all’avvio. Non creare un client a ogni render. Inserisci servizio, ambiente e release incontext:
stopAppStateListener() alla chiusura dell’app.
Con la coda nativa, un solo client attivo può usare una chiave. Un secondo
client con la stessa chiave non riesce e restituisce configuration_error. È
un motivo in più per creare il client una sola volta.
Invia e trova il log di test
ChiamaverifyLogBrewSetup() una volta da un’azione di test disponibile solo
in sviluppo. Attendi il risultato e gestisci una promise rifiutata. Non
stampare la chiave o il batch di eventi.
Un risultato 2xx con batches maggiore di 0 dimostra che LogBrew ha
accettato il batch. Un flush vuoto restituisce 204 con 0 tentativi e 0
batch, perché la consegna automatica può aver già inviato l’evento. In
entrambi i casi, leggi il log salvato con la CLI:
RecordingTransport.alwaysAccept() serve solo per i test locali. Restituisce
un 202 sintetico e non invia alcuna richiesta.
Consegna offline e dopo il riavvio
Leggiclient.deliveryHealth().storage nell’app in esecuzione:
persistent: il client usa la coda nativa. Dopo un riavvio dell’app, il client ricarica gli eventi in sospeso.memory: gli eventi in sospeso vanno persi quando il runtime JavaScript si riavvia.
persistentQueue: "auto" usa la coda nativa quando il
binario dell’app contiene il modulo nativo di LogBrew. Expo Go e i binari
meno recenti usano la memoria. Un aggiornamento solo JavaScript non può
aggiungere il modulo nativo.
Se un’app di produzione deve consegnare gli eventi anche dopo un riavvio,
imposta persistentQueue: "required". In questo caso, quando manca la coda
nativa, la creazione del client non riesce con configuration_error.
Ricompila l’app con il modulo nativo. Usa persistentQueue: "disabled" solo
quando vuoi una coda in memoria.
La coda nativa contiene al massimo 1.000 eventi e 4 MiB di dati degli eventi.
Valgono anche i limiti del client, se più bassi. Gli eventi nella coda nativa
mantengono i loro ID evento dopo un riavvio.
La consegna avviene almeno una volta, quindi un nuovo tentativo può inviare un
evento due volte. Quando l’ID e il contenuto dell’evento corrispondono a un
evento che LogBrew ha già accettato, LogBrew non lo salva di nuovo. Un flush
in background è un tentativo e non dimostra la consegna. Verifica
l’acquisizione offline e il riavvio dell’app. Poi trova l’evento salvato nel progetto.
Leggi lo stato della consegna
client.deliveryHealth() restituisce lo stato della coda e della consegna
senza il contenuto degli eventi. Leggi prima questi campi:
Scegli il contenuto dei log
Mantieni ogni messaggio breve e specifico. Descrivi il risultato nell’app, come una richiesta non riuscita o un nuovo tentativo pianificato. Non includere nomi, indirizzi email, token di accesso, valori dei moduli o corpi delle richieste. Usa la gravità che corrisponde all’evento:info, warning, error o
critical. Mantieni coerenti servizio, ambiente e release, così puoi trovare
i record correlati.
npx react-native log-ios e npx react-native log-android mostrano i log
locali del dispositivo. Non interrogano LogBrew. Consulta
Debug del codice nativo in React Native.
Risolvi un controllo non riuscito
Unflush() non riuscito rifiuta la promise con un codice di errore
dell’SDK. Tieni chiavi e corpi degli eventi fuori dai report degli errori.
Consulta Risoluzione degli errori per altri
controlli.
Mantieni i Debug ID di Expo nei bundle di release
Crea la configurazione Metro di Expo tramite LogBrew. Così il bundle di runtime riceve lo stesso Debug ID della sua source map:withLogBrewMetroConfig(). Non usare questo wrapper con Expo. Se
lo fai, la build di produzione si ferma con un messaggio che rimanda a
getLogBrewExpoConfig().