Jak utrzymać czat przy życiu, gdy telefon zasypia

Agent Mythex potrafi pracować przez minuty nad jednym żądaniem, a Ty możesz śledzić to z telefonu, który się blokuje, przełącza aplikacje i zmienia sieć podczas pracy. Dwa błędy sprawiały, że to się psuło. W jednym czat uznawał każdy sygnał „strona znów jest widoczna” za dowód, że jego połączenie padło, i zapętlał się, aż utknął na „Łączenie…”. W drugim telefon, który przespał pierwszą odpowiedź w nowym czacie, po powrocie pokazywał tylko kilka pierwszych fragmentów, aż do ręcznego odświeżenia. Oba są naprawione.

Jak czat śledzi działającą turę

Podczas pracy agenta czat utrzymuje otwarty strumień z naszych serwerów: każdy krok — myśl, wywołanie narzędzia, fragment odpowiedzi — przychodzi jako zdarzenie. Jeśli strumień się urwie, czat łączy się ponownie, a serwer odtwarza ostatnie zdarzenia z bufora, który trzyma ostatnie 120 sekund. Gdy tura się kończy, czat prosi też serwer o zapisaną historię i uzgadnia to, co pokazał, z tym, co zapisano. Ten ostatni krok łapie wszystko, co strumień przegapił.

Żeby odróżnić żywe połączenie od martwego, gdy nic się nie dzieje, serwer wysyła mały „ping” co 15 sekund.

Błąd 1: obudzenie zabijało zdrowy strumień

Przeglądarki informują stronę, gdy znów staje się widoczna: po przełączeniu karty, po odblokowaniu ekranu. Używaliśmy tego jako sygnału do sprawdzenia połączenia — a w praktyce do przerwania strumienia i ponownego połączenia, zakładając, że w ukryciu padł.

Na telefonach i w osadzonych przeglądarkach te zdarzenia pojawiają się znacznie częściej niż strumienie padają — przy każdym przełączeniu karty, każdym odblokowaniu, a w niektórych osadzonych przeglądarkach co kilka sekund. Każde z nich przerywało zdrowy strumień. Czat łączył się ponownie, odtwarzał zdarzenia, był przerywany znowu i kończył na „Łączenie…”. Potem pokazywał, że tura się skończyła, choć agent wciąż pracował.

Naprawa: oceniaj strumień po tym, czy coś przez niego przychodzi

Czat zapisuje teraz, kiedy strumień każdego projektu ostatnio otrzymał cokolwiek — zdarzenia i pingi co 15 sekund. Sygnał „znów widoczny” przerywa strumień tylko wtedy, gdy milczał przez 25 sekund: dłużej niż interwał pingów plus wolny skok sieci, więc żywy strumień nigdy się nie kwalifikuje. Testy sprawdzają, że ping liczy się jako oznaka życia i że strumień, który właśnie pingnął, nie jest traktowany jako martwy.

Zasada, którą z tego wynieśliśmy: widoczność strony mówi coś o stronie, a nie o połączeniu sieciowym. Pytaj połączenie.

Błąd 2: pół odpowiedzi po obudzeniu telefonu

Ten błąd udało nam się odtworzyć za każdym razem w symulatorze iOS:

Rozpocznij nowy czat i wyślij żądanie, którego wykonanie trwa.
Pozwól telefonowi zasnąć na czas budowania.
Wróć, gdy tura już się skończyła, a dwuminutowy bufor odtwarzania wygasł.

Czat pokazywał pierwsze kilka bloków odpowiedzi, oznaczonych jako zakończone — i tak zostawało, aż odświeżyłeś stronę.

Dlaczego

Nowy czat nie ma wątku — zapisanej rozmowy — dopóki pierwsza wiadomość go nie utworzy. Dzieje się to wewnątrz funkcji wysyłania, po tym, jak wysyłanie już zapamiętało krok uzgadniania, który wciąż myślał, że wątku nie ma. Więc na końcu pierwszej tury w nowym czacie uzgadnianie widziało brak wątku i po cichu wychodziło, niczego nie pobierając.

Zwykle nikt tego nie zauważał, bo strumień i tak dostarczył całą turę. Ale telefon, który przespał turę i wrócił po wygaśnięciu 120-sekundowego bufora odtwarzania, nie mógł dostać brakujących zdarzeń ze strumienia — a uzgadnianie, które miało wypełnić lukę, nigdy nie zostało uruchomione.

Naprawa

Wysyłanie mówi uzgadnianiu, do którego wątku należy tura, więc pierwsza tura w nowym czacie jest uzgadniana jak każda inna. Jeśli do czasu przyjścia odpowiedzi otworzyłeś inny czat, wynik jest odrzucany, zamiast pokazać się w złym miejscu.
Nieudane uzgadnianie jest ponawiane. Telefon budzący się na złym połączeniu może zastać turę zakończoną, a potem nie pobrać jej. To jest teraz zapamiętywane, a czat ponawia próbę, gdy karta znów się pokaże albo sieć wróci.
„Czas pracy” jest uczciwy. Każda odpowiedź pokazuje, jak długo agent pracował. Jeśli karta nigdy nie zobaczyła komunikatu serwera o końcu tury, czat uzupełniał tę wartość własnym zegarem — który liczył od Wyślij do chwili, gdy telefon się obudził, łącznie z czasem nieobecności. Ten czas jest teraz oznaczony jako szacunek i zastępowany zapisanym czasem trwania, gdy tylko przyjdzie historia.

Co z tego wynieśliśmy

Testuj na urządzeniu, którego ludzie faktycznie używają, w sposób, w jaki go używają. Oba błędy siedziały w luce między „strumieniem, który działa” a „telefonem w kieszeni”.
Zapasowy mechanizm, który nigdy nie działa, nie jest zapasowym. Uzgadnianie istniało właśnie po to, by łapać ten przypadek, a po cichu go pomijało.
Ponawiaj również odzyskiwanie. Moment obudzenia telefonu to często moment, w którym jego połączenie jest najgorsze.
Nie pokazuj domysłu jako faktu. Czas z niewłaściwego zegara jest gorszy niż brak czasu; oznacz go albo zastąp.

Ta sama praca uporządkowała też kilka rzeczy, które widać podczas działania tury: kroki powłoki są opisane przez polecenie, które wykonuje właściwą pracę, a nie przez cd; zrzuty ekranu w czacie zachowują lewy górny róg strony i mieszczą się w kolumnie; a nowy projekt przejmuje wygenerowaną nazwę bez odświeżania strony.

Jeśli budujesz własną aplikację na telefony, nasze poradniki o budowaniu aplikacji webowej przyjaznej dla telefonu i aplikacjach natywnych a progresywnych aplikacjach webowych omawiają podstawy. Więcej o samym czacie znajdziesz w dokumentacji czatu.