- 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 herEXPO_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:
--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:
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:
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:
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 uygulamadaclient.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.
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 birflush() 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:withLogBrewMetroConfig() ile sarar. Bu sarmalayıcıyı Expo ile kullanmayın.
Kullanırsanız canlı ortam derlemesi getLogBrewExpoConfig() fonksiyonunu
gösteren bir mesajla durur.