Progresivní webové aplikace: Kdy PWA nahradí nativní aplikaci

01Posuzujte uživatelskou práci, ne označení aplikace

PWA je webová aplikace rozšířená o možnosti, které přibližují používání instalované aplikaci. Podporované prostředí ji může spouštět samostatně a nabídnout vlastní ikonu. Zůstává ale závislá na webové platformě a jejích pravidlech. Ikona na ploše neznamená stejný přístup ke všem funkcím jako u nativního programu.

Sepište hlavní cestu uživatele: otevření služby, přihlášení, výběr práce, uložení a další návštěvu. U každého kroku napište požadavky na síť, zařízení a oprávnění. Rozlišujte nezbytnou funkci od pohodlného doplňku. Bez tohoto rozlišení bude diskuse přeskakovat mezi cenou, technologií a jednotlivými přáními.

Ilustrativní příklad: servisní portál může potřebovat seznam zakázek, fotografii závady a rozepsaný formulář při ztrátě signálu. To je jiné zadání než nepřetržité sledování pohybu nebo komunikace s konkrétním přístrojem. Výběr technologie potvrďte na těchto scénářích, nikoli ukázkou úvodní obrazovky.

Pokud už potřebujete distribuovanou mobilní aplikaci, navazuje srovnání nativního a multiplatformního vývoje. Zde rozhodujete o předchozí otázce: zda lze potřebnou službu bezpečně a pohodlně dodat přes webovou platformu.

02Instalace musí odpovídat zařízení a uživateli

MDN popisuje instalovatelnost PWA, manifest a podmínky bezpečného připojení. Podoba instalace se liší mezi prohlížeči a systémy. Nepočítejte s jedním univerzálním dialogem a stejným tlačítkem na všech telefonech.

Z webu musí jít službu rozumně použít i bez instalace, pokud to zadání umožňuje. Vysvětlete, co uživatel instalací získá: rychlý návrat, samostatné okno nebo konkrétní podporovanou funkci. Nenabízejte instalaci předtím, než člověk pochopí hodnotu služby. U interního portálu může návod poskytnout správce, veřejný produkt potřebuje srozumitelnou cestu sám.

Připravte název, ikony a správnou vstupní adresu. Ověřte přihlášení po spuštění z plochy i odkazy, které aplikaci otevírají. Uživatel se nesmí dostat do jiné části služby nebo ztratit rozepsanou práci jen proto, že otevřel oznámení. Podporu instalace ověřte pro konkrétní kombinaci systému, prohlížeče a režimu správy zařízení.

Distribuce přes web může zjednodušit první přístup z odkazu. Pokud požadujete obchod s aplikacemi, připravte samostatný plán balení a ověření pravidel daného obchodu. Samotné slovo PWA není zárukou schválení v každém distribučním kanálu.

U interní aplikace se zeptejte také správce firemních telefonů. Instalace, výchozí prohlížeč nebo přístup k úložišti mohou být omezené správou zařízení. Připravte návod pro skutečné prostředí zaměstnanců a možnost podpory bez sdílení hesla. Pokud se aplikace používá na soukromém telefonu, ujasněte hranici mezi firemními a osobními údaji a podmínky ukončení přístupu.

03Offline režim navrhněte po jednotlivých operacích

Průvodce MDN offline provozem ukazuje použití service workeru a místní cache. Instalace a offline schopnost jsou různé věci. Nestačí uložit grafiku a zobrazit obrazovku, pokud uživatel nemůže dokončit práci nebo nepozná stav dat.

Rozlišujte uloženo v zařízení, čeká na odeslání a potvrzeno serverem. Při návratu sítě mohou dva lidé změnit stejný záznam. Domluvte řešení konfliktu, opakování a ztraceného potvrzení. U objednávky se nesmí jen podle zelené ikony vytvářet dojem, že ji obchod skutečně přijal.

Určete, co smí zůstat v zařízení, jak se data mažou a co nastane při změně účtu. Sdílený tablet ve skladu má jiné podmínky než osobní telefon. Otestujte první návštěvu bez připravené cache, stará data a nedostatek místního prostoru. Uživatel musí mít srozumitelný postup, pokud některou operaci síť stále vyžaduje.

Nezapomeňte na chování více otevřených oken. Uživatel může mít tutéž službu v běžném prohlížeči a zároveň spuštěnou z ikony. Ověřte, jak se propíše změna, odhlášení a dokončená operace. Dva místní koncepty nesmějí tiše přepsat jeden druhý. Při synchronizaci ukažte člověku situaci, kterou musí rozhodnout, a zachovejte potřebné údaje pro podporu.

04Push a běh na pozadí nejsou totéž

WebKit dokumentuje Web Push pro webové aplikace na ploše iOS a iPadOS od verze 16.4. Žádost o oprávnění musí navazovat na přímou akci uživatele. Pro návrh je podstatná instalace na plochu, podpora prostředí a skutečně udělené oprávnění.

Když uživatel oznámení odmítne, musí služba nabídnout rozumný způsob kontroly důležitých stavů. Push nepovažujte za potvrzení, že člověk informaci přečetl. Citlivé údaje neposílejte zbytečně do textu na zamčené obrazovce. Otevření oznámení ověřte s odhlášeným účtem i po změně oprávnění.

Service worker nefunguje jako trvale běžící proces. Prohlížeč jej může ukončit a schopnosti synchronizace se liší. Nepřipravujte proto klíčovou obchodní garanci na předpokladu nepřetržité práce na pozadí. Pokud úloha musí pokračovat nezávisle na telefonu, zvažte její vykonání na serveru a následné zobrazení výsledku.

05Funkce telefonu ověřte v malém prototypu

U kamery, polohy, sdílení nebo práce se soubory napište přesný požadavek. Vyfotit jednu přílohu není stejné jako dlouhé zpracování videa. Jednorázové zjištění polohy není průběžné sledování na pozadí. Požadavek „podpora Bluetooth“ zase neříká, s jakým příslušenstvím a kdy se má komunikovat.

MDN označuje Web Bluetooth jako omezeně dostupné rozhraní. To je příklad, proč nestačí seznam webových API. Ověřte podporu v cílových prohlížečích, oprávnění a konkrétní periférii. Kritickou funkci vyzkoušejte před závazkem k architektuře.

• Vyberte zařízení a verze podle skutečného publika.
• Ověřte funkci v běžném i zamítnutém stavu oprávnění.
• Vyzkoušejte přerušení, návrat a opakování operace.
• Zapište omezení a náhradní cestu pro nepodporované prostředí.

Nativní řešení zvažte, pokud web nedokáže splnit nezbytnou funkci v požadovaném provozu. Ani tam však nepředpokládejte neomezený běh nebo volný přístup k datům. Posouzení musí zahrnovat pravidla platformy, oprávnění a provozní testy. Rozhodnutí není soutěž seznamů funkcí, ale ověření konkrétního výsledku.

06Údržbu a bezpečnost započítejte do rozhodnutí

Společná webová aplikace může sdílet podstatnou část rozhraní a způsobu vydávání. Náklady však vznikají také testováním různých prostředí, offline daty, synchronizací a podporou uživatelů. Neodvozujte pevnou úsporu z počtu kódových základen. Srovnávejte konkrétní rozsah a odpovědnost za provoz.

Aktualizace musí respektovat cache a starší otevřenou verzi aplikace. Změna API nesmí znefunkčnit uživatele, který právě dokončuje formulář. Připravte informaci o dostupné verzi a bezpečný přechod bez ztráty práce. Otestujte i návrat k předchozímu vydání, pokud nový obsah nebo skript způsobí problém.

PWA není automaticky bezpečnější proto, že je webová. Řešte přihlášení, serverová oprávnění, místní data a citlivé údaje v cache. Bezpečnost mobilní aplikace nabízí související otázky k datům a API. V zadání PWA určete také, co se stane při odhlášení, zrušení účtu nebo ztrátě zařízení.

Plánujte podporu po změnách prohlížečů. Matice podporovaných prostředí potřebuje vlastníka a pravidelnou kontrolu. Záznam problému má obsahovat verzi systému, způsob otevření a konkrétní scénář. Obecné hlášení „na telefonu to nejde“ nestačí pro rychlou opravu.

07Rozhodněte podle ověřeného scénáře

Prototyp zaměřte na nejrizikovější cestu, nikoli na nejhezčí obrazovku. U servisního portálu může jít o fotografii, rozepsaný záznam bez sítě a pozdější potvrzení serverem. Přidejte instalaci, návrat z oznámení a chování po aktualizaci. Výsledek ukažte lidem, kteří budou službu skutečně používat.

1. Sepište nezbytné scénáře a podporovaná zařízení.
2. Ověřte omezení platformy a rizikové funkce.
3. Vyzkoušejte prototyp včetně přerušení a obnovy.
4. Porovnejte provoz, podporu a celkové zadání variant.

Přejímací kritéria formulujte jako viditelný výsledek: koncept se obnoví, server potvrdí změnu, uživatel pozná stará data. Nepřijímejte pouze technické tvrzení „service worker funguje“. Zapište, které funkce pilot nepokryl a na čem se rozhodnutí může změnit. Pokud klíčový scénář neprojde, upravte rozsah nebo zvolte jinou architekturu.

Služba může začít webem a později dostat jinou mobilní podobu. Pomůže společné API a dobře vymezený datový model, nikoli slib bezpracného převodu. Už při prvním řešení uchovávejte přehled vlastních účtů, dat a integrací, aby se další rozhodnutí nemuselo opírat o jednu obtížně změnitelnou obrazovku.

Do rozhodnutí zahrňte také dostupnost podpory. Připravte jednoduchý způsob zjištění verze aplikace a nahlášení problému bez citlivých dat. Při pilotu sledujte, které kroky uživatelé opakují nebo řeší mimo aplikaci. Takové pozorování může odhalit překážku instalace nebo nejasné potvrzení rychleji než obecná otázka, zda se jim aplikace líbí.

08Časté otázky k PWA