obyčejné screenshoty toho měnícího se kódu v aplikaci a podíval se jestli se jednotlivé "frames" mění v čase (porovnat klidně jako obrázky)
Předpokládám, že se nebavíme o jízdence, ale o InKartě. Tam se mění celý QR kód (všechny jeho dlaždice) každou vteřinu – na to nepotřebuju screenshoty a porovnání obrázků, na to mi stačí oči.
Domnívám se že se tak děje proto, že se data inKarty nevejdou do jednoho QR kódu (je tam ta barevná fotografie), a tudíž pořád dokola rotuje několik QR kódů které ta data inKarty postupně do čtečky přenesou.
Mnou navržené porovnávání směřuje k zjištění toho zda jde opravdu o stále stejnou smyčku (dat podepsaných jednou provždy na serveru při nákupu inKarty), a nebo zda jsou ty kódy generovány/podepisovány nějak složitěji v aplikaci.
- QR kód jízdenky může být vytištěný
Pro jízdenky (o kterých tu ale podle mne nediskutujeme) se používá aztécký kód, ne QR kód.
Moje domněnka byla (a pravděpodobně jsem se, když o tom teď přemýšlím, mýlil) že kódy jízdenek (to že jde o Aztec a ne QR kódy je technický detail) jsou také zařazeny do té animace. Vzpomněl jsem si nicméně na situaci která nasvědčuje opaku: průvodčí eTicket po načtení animace neviděla (nebyl tedy stažený do její čtečky kde by se spároval s načtenou inKartou), a požádala mě abych jej ukázal zvlášť.
Nevidím žádný přínos toho že by ty kódy v aplikaci byly nějak "dynamicky" podepisované, nebo spojené dohromady (myslím tím inKartu a jízdenky). Naopak by to celý systém jenom komplikovalo a chovalo se v různých scénářích.
Někde dříve tady bylo zmíněno, že kód InKarty obsahuje i naposledy koupené jízdenky. Což by dávalo smysl – průvodčí může načíst jenom InKartu a pokud v ní budou uložené i poslední jízdenky, bude to celé fungovat offline (po stažení jízdenky do aplikace).
K tomu viz moje zkušenost výše. Moje úvaha byla že pokud ta animace obsahuje jak inKartu tak jízdenky, jejich kódy jsou oddělené (podepsané nezávisle, a fungujícící samostatně), a pouze se po sobě ukazují ve smyčce a čtečka je postupně - nezávisle na sobě - načte.