Skip to main content
Bir React Native uygulamasından LogBrew’e log gönderin. Tek bir test loguyla başlayın, ardından logu doğru projede bulmak için CLI’ı kullanın. Bu rehber Expo kullanır. Expo’suz (bare) bir React Native uygulaması anahtarı kendi yapılandırmasından alır. Başlamadan önce şunlar gerekir:
  • Yerelde çalıştırabildiğiniz bir React Native uygulaması.
  • Bir LogBrew projesi. Projeler sayfasına bakın.
  • Giriş yapılmış bir CLI. CLI kurulumu sayfasına bakın.

SDK’yı kurun

İki paketi de uygulama dizinine kurun. Uygulamanın React ve React Native bağımlılıklarını koruyun:

Bir proje SDK anahtarı oluşturun

Uygulamaya proje kapsamlı, yalnızca yazma yetkili bir SDK anahtarı verin. Expo her EXPO_PUBLIC_* değerini uygulama paketine koyar. Bu değişkene asla hesap veya sunucu kimlik bilgisi koymayın. CLI v0.1.32 veya daha yeni bir sürüm, var olan bir proje için anahtar oluşturur. Yeni proje oluşturmaz. Proje kimliğini bulun:
Anahtarı oluşturun. Yalnızca sahibinin erişebildiği bir dizinde yeni bir dosya yolu kullanın:
Yalnızca komut başarılı olduktan sonra devam edin. Sonuç belirsizse aynı komutu aynı argümanlarla yeniden çalıştırın. --abandon-retry kullanmayın. Anahtar dosyasını kaynak kontrolünün dışında tutun. CLI’ı yetkilendiren hesap kimlik bilgisini kullanmayın. Yerel Expo geliştirmesi için anahtarı uygulama kökünde, yok sayılan bir .env.local dosyasına koyun:
Aşağıdaki kurulum modülünde doğrudan process.env.EXPO_PUBLIC_LOGBREW_CLIENT_KEY başvurusunu koruyun. Değeri değiştirdikten sonra uygulamayı tamamen yeniden yükleyin. Derleme zamanı yapılandırması için Expo ortam değişkenleri sayfasına bakın. Expo’suz bir React Native uygulaması ise anahtarı kendi yapılandırmasından alır.

İstemciyi oluşturun

Bu kurulumu uygulamanın açılışta yüklediği tek bir modüle koyun. Her render’da yeni istemci oluşturmayın. Hizmeti, ortamı ve sürümü context içine koyun:
Fetch aktarımı, sınırlı yeniden denemeler ve bir kuyrukla otomatik gönderimi açar. İkinci bir flush zamanlayıcısı eklemeyin. AppState dinleyicisi, uygulama etkin olmaktan çıktığında veya arka plana geçtiğinde son bir flush ister. Uygulama kapanırken stopAppStateListener() çağırın. Native kuyrukta bir anahtarı yalnızca bir etkin istemci kullanabilir. Aynı anahtar için ikinci bir istemci configuration_error ile başarısız olur. Bu da istemciyi bir kez oluşturmanın bir başka nedenidir.

Test logunu gönderin ve bulun

verifyLogBrewSetup() fonksiyonunu yalnızca geliştirmede kullanılan bir test aksiyonundan bir kez çağırın. Sonucu bekleyin ve reddedilen promise’i ele alın. Anahtarı veya olayların toplu gönderimini yazdırmayın. batches değeri 0’dan büyük olan bir 2xx sonucu, LogBrew’ün toplu gönderimi kabul ettiğini gösterir. Boş bir flush 0 deneme ve 0 toplu gönderimle 204 döndürür, çünkü otomatik gönderim olayı daha önce göndermiş olabilir. İki durumda da kaydedilen logu CLI ile okuyun:
Sonuçtaki olay zamanını ve hizmeti kontrol edin. Boş bir sonuç nedeni göstermez. Projeyi, anahtarı ve zaman aralığını kontrol edin. RecordingTransport.alwaysAccept() yalnızca yerel testler içindir. Sentetik bir 202 döndürür ve istek göndermez.

Çevrimdışı ve yeniden başlatma sonrası gönderim

Çalışan uygulamada client.deliveryHealth().storage değerini okuyun:
  • persistent: İstemci native kuyruğu kullanır. Bekleyen olaylar uygulama yeniden başladıktan sonra tekrar yüklenir.
  • memory: JavaScript çalışma ortamı yeniden başladığında bekleyen olaylar kaybolur.
Varsayılan persistentQueue: "auto", uygulama ikili dosyası LogBrew native modülünü içeriyorsa native kuyruğu kullanır. Expo Go ve eski ikili dosyalar belleği kullanır. Yalnızca JavaScript içeren bir güncelleme native modülü ekleyemez. Canlıdaki bir uygulamanın yeniden başlatma sonrası gönderime ihtiyacı varsa persistentQueue: "required" ayarlayın. Bu durumda native kuyruk yoksa istemci oluşturma configuration_error ile başarısız olur. Uygulamayı native modülle yeniden derleyin. persistentQueue: "disabled" ayarını yalnızca bir bellek kuyruğu istediğinizde kullanın. Native kuyruk en fazla 1.000 olay ve 4 MiB olay verisi tutar. Daha küçük istemci sınırları da geçerlidir. Native kuyruktaki olaylar yeniden başlatmadan sonra olay kimliklerini korur. Gönderim en az bir kez yapılır. Bu yüzden bir yeniden deneme bir olayı iki kez gönderebilir. Olay kimliği ve içeriği LogBrew’ün daha önce kabul ettiği bir olayla eşleşirse LogBrew onu yeniden saklamaz. Arka plandaki bir flush bir denemedir, gönderimin kanıtı değildir. Çevrimdışı yakalamayı ve uygulamanın yeniden başlatılmasını test edin. Ardından kaydedilen olayı projede bulun.

Gönderim durumunu okuyun

client.deliveryHealth(), olay içeriği olmadan kuyruk ve gönderim durumunu döndürür. Önce şu alanları okuyun:

Log içeriğini seçin

Her mesajı kısa ve belirli tutun. Başarısız bir istek veya planlanmış bir yeniden deneme gibi uygulamadaki sonucu anlatın. Adları, e-posta adreslerini, erişim tokenlarını, form değerlerini veya istek gövdelerini eklemeyin. Olaya uyan önem düzeyini kullanın: info, warning, error veya critical. İlgili kayıtları bulabilmek için hizmeti, ortamı ve sürümü tutarlı tutun. npx react-native log-ios ve npx react-native log-android yerel cihaz loglarını gösterir. LogBrew’ü sorgulamaz. React Native native kod hata ayıklama sayfasına bakın.

Başarısız bir kontrolden kurtulun

Başarısız bir flush() bir SDK hata koduyla reddedilir. Anahtarları ve olay gövdelerini hata raporlarının dışında tutun. Daha fazla kontrol için Sorun giderme sayfasına bakın.

Expo Debug ID’lerini sürüm paketlerinde koruyun

Expo Metro yapılandırmasını LogBrew ile oluşturun. Böylece çalışma zamanı paketi, source map’iyle aynı Debug ID’yi alır:
Uygulama React Native Worklets paket kipini kullanıyorsa bu dönüşümü LogBrew yardımcısından sonra uygulayın:
Yardımcı, mevcut Expo serileştirme öncesi eklentilerini korur. Expo’suz bir React Native uygulaması ise bitmiş Metro yapılandırmasını withLogBrewMetroConfig() ile sarar. Bu sarmalayıcıyı Expo ile kullanmayın. Kullanırsanız canlı ortam derlemesi getLogBrewExpoConfig() fonksiyonunu gösteren bir mesajla durur.