- Aplikacji React Native, którą możesz uruchomić lokalnie.
- Projektu LogBrew. Zobacz Projekty.
- Zalogowanego CLI. Zobacz stronę Praca z CLI.
Zainstaluj SDK
Zainstaluj oba pakiety w katalogu aplikacji. Zachowaj zależności React i React Native, których używa aplikacja:Utwórz klucz SDK projektu
Daj aplikacji klucz SDK przypisany do projektu i tylko do zapisu. Expo umieszcza każdą wartośćEXPO_PUBLIC_* w pakiecie aplikacji. Nigdy nie
umieszczaj w tej zmiennej poświadczenia konta ani serwera.
CLI v0.1.32 lub nowszy tworzy klucz dla istniejącego projektu. Nie tworzy
nowego projektu. Znajdź ID projektu:
--abandon-retry.
Nie dodawaj pliku klucza do systemu kontroli wersji. Nie używaj poświadczenia
konta, które autoryzowało CLI. Przy lokalnej pracy z Expo umieść klucz w
ignorowanym pliku .env.local w katalogu głównym aplikacji:
process.env.EXPO_PUBLIC_LOGBREW_CLIENT_KEY w
module konfiguracji poniżej. Po zmianie wartości w pełni przeładuj aplikację.
Konfigurację w czasie builda opisuje strona
Zmienne środowiskowe w Expo.
Aplikacja w czystym React Native ładuje natomiast klucz przez własną
konfigurację.
Utwórz klienta
Umieść tę konfigurację w jednym module, który aplikacja ładuje przy starcie. Nie twórz klienta przy każdym renderowaniu. Umieść usługę, środowisko i wydanie wcontext:
stopAppStateListener(), gdy
aplikacja się zamyka.
Przy natywnej kolejce z klucza może korzystać tylko jeden aktywny klient.
Utworzenie drugiego klienta dla tego samego klucza kończy się błędem
configuration_error.
To kolejny powód, by tworzyć klienta tylko raz.
Wyślij i znajdź testowy log
WywołajverifyLogBrewSetup() raz z testowej akcji dostępnej tylko w wersji
deweloperskiej. Poczekaj na wynik i obsłuż odrzucony promise. Nie wypisuj
klucza ani paczki zdarzeń.
Wynik 2xx z batches większym niż 0 pokazuje, że LogBrew przyjął paczkę.
Puste opróżnienie kolejki zwraca 204 z 0 prób i 0 paczek, bo automatyczne
dostarczanie mogło wysłać zdarzenie wcześniej. W obu przypadkach odczytaj
zapisany log w CLI:
RecordingTransport.alwaysAccept() służy tylko do testów lokalnych. Zwraca
syntetyczne 202 i nie wysyła żadnego żądania.
Dostarczanie offline i po restarcie
Odczytajclient.deliveryHealth().storage w działającej aplikacji:
persistent: klient używa natywnej kolejki. Oczekujące zdarzenia ładują się ponownie po restarcie aplikacji.memory: oczekujące zdarzenia giną, gdy środowisko uruchomieniowe JavaScript się restartuje.
persistentQueue: "auto" używa natywnej kolejki, gdy plik binarny
aplikacji zawiera natywny moduł LogBrew. Expo Go i starsze pliki binarne
używają kolejki w pamięci. Aktualizacja samego JavaScriptu nie doda natywnego modułu.
Jeśli aplikacja produkcyjna potrzebuje dostarczania po restarcie, ustaw
persistentQueue: "required". Wtedy tworzenie klienta kończy się błędem
configuration_error, gdy brakuje natywnej kolejki. Zbuduj aplikację ponownie
z natywnym modułem. Używaj persistentQueue: "disabled" tylko wtedy, gdy
chcesz mieć kolejkę w pamięci.
Natywna kolejka mieści najwyżej 1000 zdarzeń i 4 MiB danych zdarzeń.
Obowiązują też mniejsze limity klienta. Zdarzenia w natywnej kolejce zachowują
swoje ID po restarcie.
Dostarczanie działa w trybie „co najmniej raz”, więc ponowienie może wysłać
zdarzenie dwa razy. Gdy ID i treść zdarzenia pasują do zdarzenia, które
LogBrew już przyjął, LogBrew nie zapisuje go ponownie. Opróżnienie kolejki w
tle to próba, a nie dowód dostarczenia. Przetestuj rejestrowanie offline i
restart aplikacji. Potem znajdź zapisane zdarzenie w projekcie.
Odczytaj stan dostarczania
client.deliveryHealth() zwraca stan kolejki i dostarczania bez treści
zdarzeń. Najpierw odczytaj te pola:
Wybierz treść logu
Każdy komunikat powinien być krótki i konkretny. Opisz wynik w aplikacji, na przykład nieudane żądanie albo zaplanowane ponowienie. Nie umieszczaj imion i nazwisk, adresów e-mail, tokenów dostępu, wartości formularzy ani treści żądań. Użyj poziomu ważności, który pasuje do zdarzenia:info, warning, error
lub critical. Usługa, środowisko i wydanie powinny być spójne, aby dało się
znaleźć powiązane wpisy.
npx react-native log-ios i npx react-native log-android pokazują lokalne
logi urządzenia. Nie odpytują LogBrew. Zobacz
Debugowanie kodu natywnego w React Native.
Napraw nieudane sprawdzenie
Nieudaneflush() odrzuca promise z kodem błędu SDK. Nie umieszczaj kluczy
ani treści zdarzeń w raportach błędów.
Więcej sprawdzeń opisuje strona
Rozwiązywanie problemów.
Zachowaj Debug ID z Expo w pakietach wydania
Utwórz konfigurację Metro dla Expo przez LogBrew. Wtedy pakiet uruchomieniowy dostaje to samo Debug ID co jego mapa źródeł (source map):withLogBrewMetroConfig(). Nie używaj tego opakowania z Expo. W
przeciwnym razie build produkcyjny zatrzyma się z komunikatem, który wskazuje
getLogBrewExpoConfig().