Mbajtja e chat-it gjallë kur telefoni fle

Agjenti i Mythex mund të punojë për minuta të tëra për një kërkesë, dhe ti mund ta shikosh nga një telefon që kyçet, ndërron aplikacionet dhe ndryshon rrjetin gjatë punës. Dy gabime e prishnin këtë. Në njërin, chat-i e trajtonte çdo sinjal “faqja është përsëri e dukshme” si provë se lidhja e tij kishte vdekur, dhe rrotullohej derisa mbetej te “Duke u lidhur…”. Në tjetrin, një telefon që kishte fjetur gjatë përgjigjes së parë të një chat-i të ri kthehej duke shfaqur vetëm disa pjesët e para të saj, derisa rifreskoje dorazi. Të dyja janë rregulluar.

Si e ndjek chat-i një turn që po punon

Kur agjenti punon, chat-i mban të hapur një transmetim nga serverat tanë: çdo hap, një mendim, një thirrje mjeti, një pjesë e përgjigjes, arrin si ngjarje. Nëse transmetimi ndërpritet, chat-i rilidhet dhe serveri rishfaq ngjarjet e fundit nga një buffer që mban 120 sekondat e fundit. Kur turni mbaron, chat-i kërkon edhe historikun e ruajtur nga serveri dhe e pajton atë që shfaqi me atë që është ruajtur. Ky hap i fundit kap çdo gjë që transmetimi i humbi.

Për të dalluar një lidhje të gjallë nga një e vdekur kur nuk ndodh asgjë, serveri dërgon një “ping” të vogël çdo 15 sekonda.

Gabimi 1: zgjimi vriste një transmetim të shëndetshëm

Shfletuesit i tregojnë një faqeje kur bëhet përsëri e dukshme: pas ndërrimit të skedës, pas zhbllokimit të ekranit. Ne e përdornim këtë si shenjë për të kontrolluar lidhjen, dhe në praktikë për ta ndërprerë transmetimin dhe rilidhur, duke supozuar se kishte vdekur ndërkohë që ishte e fshehur.

Në telefona dhe shfletues të integruar, këto ngjarje ndodhin shumë më shpesh se sa vdesin transmetimet: çdo ndërrim skede, çdo zhbllokim, dhe në disa shfletues të integruar rreth çdo disa sekondash. Çdo njëra ndërpriste një transmetim krejt të shëndetshëm. Chat-i rilidhej, rifitonte, ndërpritej përsëri, dhe mbetej te “Duke u lidhur…”. Pastaj thoshte se turni kishte mbaruar ndërsa agjenti akoma punonte.

Rregullimi: gjykoje transmetimin nga fakti nëse po fliste

Chat-i tani regjistron kur transmetimi i çdo projekti mori për herë të fundit çfarëdo gjëje: ngjarje dhe ping-et 15-sekondëshe të dyja. Një sinjal “faqja është përsëri e dukshme” ndërpret një transmetim vetëm nëse ka qenë i heshtur për 25 sekonda: më shumë se intervali i ping-ut plus një kërcim i ngadaltë rrjeti, kështu që një transmetim i gjallë nuk kualifikohet kurrë. Testet kontrollojnë që një ping llogaritet si shenjë jete, dhe që një transmetim që sapo ka dërguar ping nuk trajtohet si i vdekur.

Rregulli që nxorëm nga kjo: dukshmëria e një faqeje tregon diçka për faqen, jo për lidhjen e rrjetit. Pyet lidhjen.

Gabimi 2: gjysmë përgjigjeje pasi u zgjua telefoni

Këtë e riprodhonim gjithmonë në simulatorin iOS:

Nis një chat të ri dhe dërgo një kërkesë që zgjat.
Lër telefonin të flejë gjatë ndërtimit.
Kthehu kur turni ka mbaruar dhe buffer-i 120 sekondash ka skaduar.

Chat-i shfaqte disa blloqet e para të përgjigjes, të shënuara si të mbaruara, dhe qëndronte kështu derisa rifreskoje faqen.

Pse

Një chat i ri nuk ka ende një thread, pra bisedën e ruajtur, derisa mesazhi i parë ta krijojë atë. Kjo ndodh brenda funksionit të dërgimit, pasi dërgimi kishte kapur tashmë hapin e pajtimit, i cili ende mendonte se nuk kishte thread. Kështu që në fund të turnit të parë në një chat të ri, pajtimi nuk pa asnjë thread dhe u kthye në heshtje pa kërkuar asgjë.

Zakonisht askush nuk e vinte re, sepse transmetimi kishte dorëzuar tashmë gjithë turnin. Por një telefon që kishte fjetur gjatë turnit dhe u kthye pasi buffer-i 120-sekondësh kishte skaduar nuk mund t’i merrte ngjarjet e munguara nga transmetimi, dhe pajtimi që duhej ta mbushte boshllëkun nuk kishte ekzekutuar kurrë.

Rregullimi

Dërgimi i tregon pajtimit cilit thread i takon turni, kështu që turni i parë i një chat-i të ri pajtohet si çdo tjetër. Nëse ke hapur një chat tjetër kur të vijë përgjigjia, rezultati hidhet në vend që të shfaqet në vendin e gabuar.
Pajtimi i dështuar riprovohet. Një telefon që zgjohet me lidhje të keqe mund ta gjejë turnin të mbaruar dhe pastaj të dështojë të marrë historikun. Kjo tani mbahet mend, dhe chat-i pyet përsëri kur shfaqet skeda ose kthehet rrjeti.
“Worked for” është i ndershëm. Çdo përgjigje tregon sa punoi agjenti. Nëse skeda nuk pa kurrë mesazhin e serverit për fund turni, më parë e plotësonte nga ora e vet, që numëronte nga Send deri kur u zgjua telefoni, duke përfshirë kohën e larguar. Kjo shifër tani shënohet si vlerësim, dhe zëvendësohet nga kohëzgjatja e ruajtur sapo arrin historiku.

Çfarë morëm nga kjo

Testo në pajisjen që njerëzit përdorin vërtet, në mënyrën që e përdorin. Të dy gabimet jetonin në hapësirën midis “një transmetimi që punon” dhe “një telefoni në xhep”.
Një rezervë që nuk ekzekutohet kurrë nuk është rezervë. Hapi i pajtimit ekzistonte pikërisht për ta kapur këtë rast, dhe e kapërcente në heshtje.
Riprovo edhe rikuperimin. Momenti kur zgjohet një telefon është shpesh kur lidhja e tij është më e dobët.
Mos shfaq një hamendje si fakt. Një kohëzgjatje nga ora e gabuar është më keq se aspak; shëno ose zëvendëso.

I njëjti punë pastroi edhe disa gjëra që do t’i shohësh ndërsa një turn po punon: hapat e shell-it etiketohen nga komanda që bën punën, jo nga cd; screenshot-et në chat mbajnë pjesën e sipërme majtas të faqes dhe përshtaten me kolonën; dhe një projekt i ri merr emrin e gjeneruar pa rifreskim.

Nëse po ndërton aplikacion për telefona, udhëzuesit tanë për ndërtimin e një aplikacioni web të përshtatshëm për celular dhe aplikacionet native kundrejt atyre progresive web mbulojnë bazat. Më shumë për vetë chat-in gjendet në dokumentacionin e chat-it.