Skip to main content
Invia a LogBrew i log di un’app React Native. Inizia con un log di test, poi usa la CLI per trovarlo nel progetto corretto. Questa guida usa Expo. Un’app React Native senza Expo carica la chiave tramite la propria configurazione. Prima di iniziare, ti servono:

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 valore EXPO_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:
Crea la chiave. Usa un nuovo percorso di file in una directory accessibile solo al proprietario:
Continua solo dopo che il comando è riuscito. Se il risultato non è chiaro, esegui di nuovo lo stesso comando con gli stessi argomenti. Non usare --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:
Mantieni il riferimento diretto 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 in context:
Il trasporto fetch attiva la consegna automatica con una coda e un numero limitato di nuovi tentativi. Non aggiungere un secondo timer di flush. Il listener di AppState richiede un flush finale quando l’app diventa inattiva o passa in background. Chiama 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

Chiama verifyLogBrewSetup() 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:
Nel risultato, controlla l’orario e il servizio dell’evento. Un risultato vuoto non indica la causa. Controlla il progetto, la chiave e l’intervallo di tempo. RecordingTransport.alwaysAccept() serve solo per i test locali. Restituisce un 202 sintetico e non invia alcuna richiesta.

Consegna offline e dopo il riavvio

Leggi client.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.
Il valore predefinito 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

Un flush() 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:
Se l’app usa la modalità bundle di React Native Worklets, applica quella trasformazione dopo l’helper di LogBrew:
L’helper mantiene i plugin di pre-serializzazione di Expo già presenti. Un’app React Native senza Expo racchiude invece la sua configurazione Metro finale con withLogBrewMetroConfig(). Non usare questo wrapper con Expo. Se lo fai, la build di produzione si ferma con un messaggio che rimanda a getLogBrewExpoConfig().