Muszę jutro zadzwonić zapytać czym się różnią te 2 produkty :D

Tech Interview Handbook
https://github.com/yangshun/tech-interview-handbook/

#getintofaang

Odc 3. Apka w google play store

https://play.google.com/store[...]=com.grzegorziwanek.stopwatch

Znalazłem w końcu trochę czasu i zabrałem się za automatyczne zapisywanie stanu trwającej sesji przy ręcznym ubiciu aplikacji.Taki niby cache.

Sama apka zbudowana jest wokół pomysłu braku wykonywanych obliczeń będąc w background oraz obsłużenia wszystkich kombinacji przypadków wejścia w stan background ( liczniki w pauzie, liczniki działające, liczniki wyzerowane itp).

O ile ta implementacja sprawdzała się to bez zarzutów, o tyle nie załatwiała w żaden sposób przypadku, gdy niechący wciśniemy back telefonu ( i ubijemy Activity - co kończy się wyczyszczeniem danych), albo gdy ubije się apkę ręcznie.
Do obsłużenia takiego przypadku trzeba dodać obsługę zapisywania stanu sesji przy końcu lifecycle ekranu oraz odtworzenia z cache przy starcie.
Jak na razie tylko dla seksji "Stopwatch". Sekcja "Countdown" work-in-progress a'la refactor kodu.

Aplikację zbudowałem wokół patternu MVI oraz operowania jednym globalnym stanem ( dokładniej po jednym dla ekranu), co bardzo ułatwia dorobienie takiej funkcjonalności, ponieważ mamy gotowe obiekty ( XXXViewState) które są na bieżąco aktualizowane o zmiany w obrębie swoich ekranów, które posiadają wszystkie potrzebne nam dane na temat ekranu, i które musimy tylko serializaować do JSON i zapisać przed zamknięciem apki, oraz deserializować przy starcie aplikacji i wyrenderować z nich ekrany.
Serializacja oraz lokalne zapisywanie historii pomiarów do JSON było już w aplikacji od samego początku jako jedna z funkcjonalności. Zrobione za pomocą biblioteki moshi.
Dotychczas miałem do czynienia tylko z Gson oraz jackson, a informacja o kotlinx-serialization jakoś mnie ominęła, wybór padł więc na tę bibliotekę.

O ile do tego momentu nie miałem żadnych problemów z serializacją danych ( dodanie wyjątków obfuskacji w Proguard, płaskie struktury danych, bez polimorfiii, zagnieżdżeń oraz kotlinowych obiektów singletonów) o tyle w tym przypadku natrafiłem na ścianę w postaci polimorficznej kotlinowej Sealed Class której serializację musiałem przeprowadzić.

EDIT po komentarzu @Michał Sikora
Da się serializować object z sealed class jako jej supertypem, jednak jest to wiedza bardzo niepowszechna i trzeba dopisać sporo kodu do serializacji.
EDIT end

Spędzenie 3 wieczorów nad tą ścianą, sprawdzenie innych bibliotek oraz przeczytania mnóstwa tematów dotyczących serializacji kotlinowych sealed class, albo inaczej, klas polimorficznych, zaowocowało sieczka w głowie oraz nową wiedzą:

• jeśli potencjalnie będziemy potrzebowali serializować/deserializować obiekty danej klasy, idealnie byłoby nie używać obiektów polimorficznych
• broń boże używać kotlinowych object ( na zasadzie object ObjectSubclass : SealedSuperClass()) - można próbować jakiejkolwiek z bibliotek do serializacji a i tak nie zadziała nam próba odtworzenia typu ObjectSubclass ( nie ma tam informacji identyfikującej oraz jest to singleton) - najlepiej sobie odpuścić i już lepiej mieć zamiast tego pustą klasę class ObjectSubclass() : SealedSuperClass() - z tym po kombinacjach poniżej można działać
• dla sealed class rodzic możemy użyć class albo data class jako dziedziczące, jednak żeby nasze czary zadziałały musimy w przypadku Moshi dodać identyfikator w postacji enuma ( lub jakiegoś stringa) dla każdego podtypu superklasy ( dodać to pole w superklasie oraz w definicji podklas) oraz spiąć to z PolymorphicJsonAdapter; dla bibliotek kotlinx oraz jackson też trzeba było dorabiać dodatkowe struktury danych żeby można było przeprowadzić "identyfikację" typu danego obiektu do i z JSON.
• a już najlepiej byłoby nie mieć polimorfii i posiadać płaską strukturę danych bo strasznie to brzydkie :)

.Dodatkowo poprawiłem w końcu ikonę aplikacji oraz dodałem Changelog.
W tym tygodniu jeśli będę mieć czas, cache dla sekcji Countdown ( które w zasadzie jest już gotowe, ale potrzbuje refactoringu).

Tak na marginesie: zauważył ktoś, że proces akceptacji zmian ( czy to zmiany grafik sklepowych, czy to nowe wersje apki) baaardzo się wydłużył w google play store?
Natknąłem się na kilka tematów na reddit, zarówno od developerów jak i ogłoszeń od googla, ale dotychczas nie dotknęło mnie to w ogóle.
A teraz ni z gruchy, ni z pietruchy, akceptacja update ikony aplikacji ( wyświetlanej w sklepie!) trwała gdzieś prawie 3 dni.

Zauważyłem też, że po ustawieniu tagów ( od kilku dni w konsoli deweloperskiej aplikacji można przypisać jej do 5 kategorii/tagów) oraz ostatniej aktualizacji apka skoczyła do pierwszej dziesiątki wyników dla "stopwatch timer", mimo mniej niż 50 instalacji, hehe.

Może komuś to kiedyś uratuje tyłek

W HTTP/2 Content-Length jest opcjonalny, więc takie coś może nie przejść var buffer = new byte[Convert.ToInt32(request.ContentLength)]; - będzie 0 ;)

Szybki myk (C#) (request.ContentLength ?? (request.Body?.Length ?? 0)) i "u mnie działa", ale radzę zapytać experta / sprawdzić doca libki od obsługi HTTP :D

https://svn.tools.ietf.org/sv[...]30.html#header.content-length

https://tools.ietf.org/html/rfc7540#section-8.1.2.6

edit

W HTTP/1.1 też jest opcjonalny, więc nvm.

Bez tego ani rusz!