Vysoká škola ekonomická v Praze
Fakulta informatiky a statistiky
Vývoj progresivní webové aplikace
DIPLOMOVÁ PRÁCE
Studijní program: Aplikovaná informatika Studijní obor: Informační systémy a technologie
Autor: Bc. Tran Thanh Tung
Vedoucí diplomové práce: Ing. Zuzana Šedivá, Ph.D.
Praha, Prosinec 2021
Poděkování
Chtěl bych poděkovat vedoucí diplomové práce Ing. Zuzaně Šedivé, Ph.D. za její cenné připomínky, ochotu a hlavně toleranci. Dále bych chtěl poděkovat své rodině a přítelkyni za jejich nepřetržitou podporu.
Abstrakt
Cílem diplomové práce je prozkoumání možností, které progresivní webové aplikace oblasti vývoje nabízí. Po rešerši progresivních webových aplikací byly stanoveny jejich požadavky a následně byly popsány metody pro jejich splnění. Součástí práce je také popis omezení progresivních webových aplikací vůči nativním aplikacím. Pro demonstraci progresivní webové aplikace je navržen a implementován prototyp progresivní webové aplikace pro správu rezervací. Pomocí analýzy existujících řešení byly specifikovány funkční požadavky.
Klientská část je postavena na ReactJS a serverová část na NodeJS. Zhodnocení výsledné implementace je v práci také popsáno.
Klíčová slova
Progresivní webová aplikace, PWA, multiplatformní aplikace, rezervační systém, reactJS, nodeJS
Abstract
The main goal of this master’s thesis is to explore the possibilities that progressive web application in development offers. After research of progressive web applications, their requirements were defined and the methods needed for their fulfillment were described.
The limitations of progressive web applications compared to native mobile applications were described as well. A prototype of progressive web application for reservation management is designed and implemented to demonstrate progressive web application capabilities. Functional requirements were specified using analysis of existing solutions.
The client is built on ReactJS and the server built on NodeJS. The evaluation of the resulting implementation is also described.
Keywords
Progressive web application, PWA, multiplatform application, reservation system, reactJS, nodeJS
Obsah
Úvod ... 12
Cíl práce ... 12
Osobní motivace ... 12
Metodika dosažení cílů ... 12
Omezení ... 13
Přínos práce ... 13
Struktura práce ... 13
1 Progresivní webové aplikace ...14
1.1 Webová aplikace ...14
1.1.1 Webová aplikace vs Webová stránka ...14
1.1.2 Přístupy k tvorbě webových aplikací ...14
Multi-Page Application ...14
Single-Page Application ... 15
1.2 Definice PWA ...16
1.2.1 Dohledatelnost (Discoverability) ...16
1.2.2 Odkazovatelnost (Linkability) ...16
1.2.3 Instalovatelnost (Installability) ...16
1.2.4 Progresivní (Progressive) ... 17
1.2.5 Responzivní (Responsiveness) ... 17
1.2.6 Bezpečnost (Safety) ... 17
1.2.7 Nezávislost na konektivitě (Network independence) ... 17
1.2.8 Opětovné zapojení uživatele (Re-engageability) ... 17
1.2.9 Působící jako nativní aplikace (Native-like) ... 17
1.2.10 Aktuální (Up-to-date) ... 18
1.3 Kontrolní seznamy pro PWA ... 18
1.4 Struktura PWA ... 20
1.4.1 Service Worker ... 20
1.4.2 Bezpečnost ... 24
1.4.3 Web app manifest ... 24
1.4.4 Cache a přípojení k internetu ... 25
1.4.5 Výkon ... 28
1.4.6 History API ... 30
1.4.7 Indexace ve webových vyhledávačích ... 30
1.4.8 Metadata sociálních sítí ... 31
1.4.9 Responzivní web design ... 32
1.4.10 UX ... 33
1.4.11 Push notifikace ... 33
1.4.12 Podpora prohlížečů ... 35
1.5 PWA vs Nativní mobilní aplikace ... 36
1.5.1 Publikace a dostupnost ... 36
1.5.2 Výkon ... 37
1.5.3 Přístup k hardwaru a funkcionalitám mobilního zařízení ... 37
1.5.4 Implementace ... 39
2 Analýza požadavků ... 40
2.1 Rezervační systém ... 40
2.2 Testování a hodnocení dostupných aplikací ... 40
2.2.1 MyFox ...41
2.2.2 Sdiary ...41
2.2.3 Rezervovač... 42
2.2.4 SuperSaaS ... 43
2.2.5 Reservanto ... 43
2.2.6 Reenio ... 43
2.2.7 Shrnutí ... 44
2.3 Požadavky ... 45
2.3.1 Funkční požadavky ... 45
2.3.2 Nefunkční požadavky ... 46
2.3.3 PWA požadavky ... 47
3 Použité technologie ... 49
3.1 Klient ... 49
3.1.1 HTML ... 49
3.1.2 CSS ... 49
3.1.3 JavaScript ... 49
ReactJS ... 50
3.1.4 Material-UI ... 51
Material Design ... 51
3.2 Server ... 51
3.2.1 Node.js ... 51
3.2.2 NPM ... 51
3.2.3 Express.js ... 52
3.2.4 Postman ... 52
3.2.5 Chai a Mocha ... 52
3.3 Komunikace mezi serverem a klientem ... 52
3.3.1 REST API ... 53
3.4 Databáze... 53
3.4.1 PostgreSQL ... 54
3.5 Nástroj pro zpracování souborů ... 54
3.5.1 Webpack ... 55
3.6 Formátování zdrojového kódu ... 55
3.6.1 ESLint ... 55
3.7 Hosting ... 56
4 Návrh aplikace ... 57
4.1 Návrh uživatelského rozhraní ... 57
4.1.1 Aplikační schránka ... 57
4.1.2 Stránka přehledu rezervací ... 58
4.1.3 Stránka seznamu obsahu ... 59
4.1.4 Stránka vytvoření a editace obsahu ... 59
4.1.5 Stránka přihlášení ... 60
4.1.6 Stránka tvorby a editace rezervace ... 60
4.2 Datový model ...61
4.2.1 Tabulka Reservation ... 62
4.2.2 Tabulka Service ... 62
4.2.3 Tabulka Employee ... 62
4.2.4 Tabulka Customer ... 63
4.2.5 Tabulka User ... 63
5 Implementace aplikace ... 64
5.1 Adresářová struktura ... 64
5.2 Server ... 64
5.2.1 Soubor .env ... 64
5.2.2 Soubor package.json ... 65
5.2.3 Integrační testy ... 66
5.2.4 Směrování ... 66
5.3 Klient ... 67
5.3.1 Stránky ... 67
5.3.2 Off-line funkcionalita ... 68
5.4 Service worker ... 68
5.5 Web app manifest ... 69
5.6 Nasazení aplikace ... 69
6 Testování ... 71
6.1 Funkční testování ... 71
6.1.1 Možnost registrace nového uživatele ... 71
6.1.2 Možnost přihlášení uživatele ... 72
6.1.3 Možnost odhlášení uživatele ... 72
6.1.4 Možnost tvorby rezervace (administrátor) ... 72
6.1.5 Možnost zamítnutí rezervace ... 73
6.1.6 Možnost zobrazení seznamu všech existujících rezervací ... 73
6.1.7 Seznam rezervací lze zobrazit bez připojení k internetu ... 73
6.1.8 Možnost filtrovat rezervace dle časového intervalu ... 74
6.1.9 Možnost tvorby rezervace bez připojení (administrátor) ... 74
6.1.10 Možnost tvorby nové služby ... 74
6.1.11 Možnost změny údajů služby ... 75
6.1.12 Možnost smazání služby ... 75
6.1.13 Možnost zobrazení seznamu všech existujících služeb ... 76
6.1.14 Možnost tvorby nového zaměstnance ... 76
6.1.15 Možnost změny údajů zaměstnance ... 76
6.1.16 Možnost smazání zaměstnance ... 77
6.1.17 Možnost tvorby rezervace (zákazník) ... 77
6.1.18 Výsledky funkčního testování ... 77
6.2 Uživatelské testování ... 78
6.2.1 Výsledky uživatelského testování ... 79
6.3 Testování PWA požadavků ... 80
6.3.1 Automatizované testování ... 80
6.3.2 Manuální testování... 80
6.4 Shrnutí ... 83
7 Shrnutí vývoje PWA ... 84
Závěr ... 85
Použitá literatura ... 86
Seznam obrázků
Obrázek 1 MPA vs SPA (Single Page Application using AngularJS, 2015) ... 15
Obrázek 2 Ukázka architektury – Aplikační schránky a Obsah (Osmani, 2020) ... 18
Obrázek 3 Životní cyklus service workeru při první instalaci (GDev, 2019) ... 21
Obrázek 4: DevTools - seznam registrovaných service workerů (GDev, 2019) ... 22
Obrázek 5: Ukázka HTTPS protokolu a platného certifikátu ... 24
Obrázek 6: Výhradně z cache (Web.dev, 2020) ... 27
Obrázek 7: Výhradně ze sítě (Web.dev, 2020) ... 27
Obrázek 8: Prvně z cache, potom ze sítě (Web.dev, 2020) ... 27
Obrázek 9: Prvně ze sítě, potom z cache (Web.dev, 2020) ... 28
Obrázek 10: Cache/síť závod (Web.dev, 2020) ... 28
Obrázek 11: Ukázka aplikace Sdiary (Sdiary, 2021) ... 42
Obrázek 12: Reservační systém Reenio ... 44
Obrázek 13: Počet dotazů jednotlivých frameworků (StackOverflow, 2021) ... 50
Obrázek 14: REST API (Benharosh, 2018) ... 53
Obrázek 15: Návrh aplikační schránky (mobilní zařízení) (zdroj: autor) ... 57
Obrázek 16: Návrh aplikační schránky (desktopové zařízení) (zdroj: autor) ... 58
Obrázek 17: Stránka přehledu rezervací (zdroj: autor) ... 58
Obrázek 18: Stránka seznamu obsahu (zdroj: autor) ... 59
Obrázek 19: Přihlašovací stránka (zdroj: autor) ... 60
Obrázek 20: Stránka tvorby rezervace (nepřihlášený uživatel) (zdroj: autor) ...61
Obrázek 21: Datový model (zdroj: autor) ...61
Obrázek 22: Adresářová struktura projektu (zdroj: autor) ... 64
Obrázek 23: Adresářová struktura serveru (zdroj: autor) ... 64
Obrázek 24: Report vygenerovaný nástrojem Lighthouse (Google, 2021) ... 82
Seznam tabulek
Tabulka 1 Kritéria pro základní PWA (Brightscout, 2018) ...19
Tabulka 2 Kritéria pro optimální PWA (Brightscout, 2018) ...19
Tabulka 3: Výhody a nevýhody publikace a dostupnosti nativních aplikací (zdroj: autor) 36 Tabulka 4: Výhody a nevýhody publikace a dostupnosti PWA (zdroj: autor) ... 37
Tabulka 5: Zařízení, operační systém a webový prohlížeč (zdroj: autor) ... 71
Tabulka 6: Výsledky funkčního testování (zdroj: autor) ... 77
Tabulka 7: Zařízení účastníků testování (zdroj: autor) ... 78
Tabulka 8: Výsledky uživatelského testování (zdroj: autor) ... 79
Tabulka 9: Výsledky manuálního testování (zdroj: autor) ... 80
Seznam výpisů programového kódu
Výpis zdrojového kódu 1: Registrace service worker (GDev, 2019) ... 22
Výpis zdrojového kódu 2: Instalace service workeru (GDev, 2019) ... 23
Výpis zdrojového kódu 3: Aktivace Service Workeru (GDev, 2019) ... 23
Výpis zdrojového kódu 4: Příklad web app manifestu (Mozilla, 2021) ... 25
Výpis zdrojového kódu 5: Zachycení stavu připojení (Mozilla, 2021) ... 26
Výpis zdrojového kódu 6: History API (Mozilla, 2021) ... 30
Výpis zdrojového kódu 7: Metadata Schema.org (Google, 2021) ... 31
Výpis zdrojového kódu 8: Příklad umístění značek Open Graph v hlavičce HTML (zdroj: autor) ... 32
Výpis zdrojového kódu 9: Viewport – meta tag (zdroj: autor) ... 32
Výpis zdrojového kódu 10: Media Queries (zdroj: autor) ... 32
Výpis zdrojového kódu 11: Zpracování push události (zdroj: autor) ... 35
Výpis zdrojového kódu 12: .env soubor (zdroj: autor) ... 65
Výpis zdrojového kódu 13: Soubor package.json (zdroj: autor) ... 66
Výpis zdrojového kódu 14: GET metoda (zdroj: autor) ... 67
Výpis zdrojového kódu 15: Jednotlivé stránky aplikace (zdroj: autor) ... 68
Výpis zdrojového kódu 16: Generování Service workera webpackem (zdroj: autor) ... 69
Výpis zdrojového kódu 17: Generování manifest.json webpackem (zdroj: autor) ... 69
Výpis zdrojového kódu 18: Obsah Procfile souboru (zdroj: autor) ... 70
Úvod
V současné době se v oblasti vývoji webových aplikací vývojáři setkávají s dotazy a požadavky klientů na možnosti využití jejich stávající webové aplikace a její transformace do desktopové či mobilní verze. Vývoj nové aplikace pro všechny dostupné platformy je nejen časově a finančně, ale také i technologicky náročné. Tento problém má však řadu možných řešení, které ušetří nejenom peníze na tvorbě několika aplikací, ale také potřebu znát a ovládat několik programovacích jazyků a technologií současně.
Jedním ze současných trendů v oblasti vývoje aplikací jsou tzv. progresivní webové aplikace, které fungují na všech platformách a uživatelům mobilních zařízení přináší pocit, jako kdyby se jednalo o nativní aplikaci. Tento dojem je vyvolán tím, že progresivní webové aplikace nabízí možnost instalace, přijímání notifikací a také částečně umožňují fungování i bez připojení k internetu.
Cíl práce
Hlavním cílem této diplomové práce je prozkoumání možností progresivních webových aplikací v oblasti vývoje multiplatformních aplikací, a za pomoci ukázkové aplikace tyto možnosti demonstrovat. Možnostmi se rozumí struktura, požadavky a omezení PWA a také funkcionality, které PWA nabízí ve srovnání s nativními mobilními aplikacemi.
Dílčími cíli této práce jsou:
- Testování a vyhodnocení existujících rezervačních systémů - Stanovení funkčních, nefunkčních a PWA požadavků - Návrh a implementace PWA pro správu rezervací
- Testování a identifikace případných problémů implementace
Osobní motivace
Jedním z hlavních důvodů výběru tématu je, že vývoj webových aplikací mi je blízký a v budoucnu bych se této profesi chtěl dále věnovat. Dalším důvodem je, že multiplatformní aplikace jsou v současné době velkým trendem. Ze všech dostupných multiplatformních řešení mě zaujaly nejvíce progresivní webové aplikace a jsem si jist, že během vypracování této aplikace si prohloubím své dosavadní znalosti.
Metodika dosažení cílů
Jedním z prvních kroků při tvorbě této diplomové práce je sběr informací. Jednalo se primárně o informace, které se týkají progresivních webových aplikací a jejich způsobu
využití. Dále byly dohledány informace a vlastnosti existujících rezervačních systémů. Na základě nalezených informací byla provedena analýza a návrh řešení reprezentující hrubý výstup této práce.
Omezení
Primárním cílem této práce není vývoj aplikace, která by konkurovala současným aplikacím, ale pouze ukázková aplikace, na které jsou demonstrovány jednotlivé funkcionality, které PWA nabízí.
Přínos práce
V práci byly popsány nejen PWA, ale i moderní technologie týkající se vývoje webových aplikací. V práci byl tedy popsán úvod do problematiky PWA, výběr technologií, implementace a nasazení. Proto může práce sloužit jako návod pro vývoj PWA.
Struktura práce
Práce byla zahájena rešerší informačních zdrojů, které se týkají problematiky progresivních webových aplikací. Obsahem první kapitoly je detailní popis PWA, kritérií a struktury PWA a srovnání s nativními mobilními aplikacemi. V další kapitole jsou popsány požadavky na aplikaci. Součástí je také testování existujících aplikací zabývajících se správou rezervací.
Následně je proveden výběr technologií, návrh řešení a samotná implementace aplikace, včetně nasazení. Poslední část se zaměřuje na testování aplikace.
1 Progresivní webové aplikace
1.1 Webová aplikace
Webová aplikace je aplikační software, který běží na webovém serveru, na rozdíl od počítačových softwarových programů, které se spouští lokálně v operačním systému zařízení. K webovým aplikacím má uživatel přístup prostřednictvím webového prohlížeče s aktivním připojením k internetu. Webové aplikace fungují na základě síťové architektury klient-server. Serverová část (označována také jako back-end) je část aplikace, která slouží ke zpracování dat a generování komponent pro zobrazení klientské části. Klientská část (označována také jako front-end) je část aplikace, kterou uživatel vidí skrze webový prohlížeč.
1.1.1 Webová aplikace vs Webová stránka
Webové stránky obsahují stránky s pevným obsahem. Každá stránka je kódována tak, aby se každému návštěvníkovi zobrazila stejné informace. Statické stránky jsou nejzákladnějším typem webových stránek a je nejsnadnější je vytvořit. Na rozdíl od dynamických webů nevyžadují téměř žádné programování. Statický web lze vytvořit jednoduchým vytvořením několika stránek HTML a jejich nasazením na webový server.
Hlavní rozdíl mezi webovou aplikaci a webovou stránkou spočívá v tom, že webová aplikace dovolí uživatelům plnit různé aktivity, jako je např. nákup výrobků, správa uživatelů, zasílání e-mailů apod.
1.1.2 Přístupy k tvorbě webových aplikací
V dnešní době se využívají převážně dva přístupy k tvorbě webových aplikací. Jedná se o Single-Page Application (dále jen SPA) a Multi-Page Application (dále jen MPA).
Multi-Page Application
MPA je historicky starší přístup a mnoho webů je na tomto principu stále založena. MPA využívá např. většina známých open-source systému pro správu obsahu, jako je Drupal nebo Wordpress, který je využíván třetinou všech webových stránek na světě (Barron, 2020).
Při každém dotazu na serveru je klientovi načtena kompletní stránka i s obsahem. Pokud uživatel provede akci, která vyžaduje odeslání požadavku, dochází opět k načtení celé stránky. Veškerá logika a načítání probíhá tedy na straně serveru, klient poté slouží jen k zobrazení statické stránky (Madhuri & al, 2015).
Single-Page Application
SPA je webová aplikace, která načte všechny potřebné zdroje (HTML, CSS, JS) v počátečním požadavku pouze jednou a poté jsou jednotlivé komponenty stránky nahrazovány či aktualizovány v závislosti na interakci uživatele. To je docíleno díky AJAX dotazům a Web Socketům, které umožňují asynchronní získávání dat. Pomocí JavaScriptu je podle nově příchozích dat upravován Document Object Model (dále jen DOM) a tím se projeví jednotlivé úpravy stránek. Vše probíhá na straně klienta, kterým je webový prohlížeč. Server vrací pouze surová data v JSON či XML formátu, zajišťuje autorizaci, avšak samotné zobrazení obsahu stránky zajišťuje klient. Tím je SPA velmi rychlá a zároveň je snížena zátěž na server, který může působit pouze jako API server. Taková aplikace může působit jako nativní aplikace (Madhuri & al, 2015).
V dnešní době se SPA vyvíjí zejména v progresivních front-end JavaScript frameworcích.
Mezi hlavní patří například React, VueJS nebo Angular (GitHub, 2021).
Obrázek 1 MPA vs SPA (Madhuri & al, 2015).
1.2 Definice PWA
Progresivní webová aplikace (zkráceně PWA) je označení pro technologie, které kombinují to nejlepší z oblastí webových aplikací a nativních mobilních aplikací. Koncept PWA je postaven na přístupu SPA. Výstupem je tedy aplikace maximalizující přívětivost a zároveň působí jako nativní mobilní aplikace.
Koncept PWA byl poprvé představen v roce 2015 softwarovým inženýrem Alexem Russellem (Russel, 2015). Proto, aby aplikace mohla být považována za PWA, musí splňovat následující kritéria (Sam Richard, 2020) (Mozilla, 2020):
• Dohledatelnost
• Odkazovatelnost
• Možnost instalace
• Progresivní
• Responzivní
• Bezpečná
• Nezávislá na konektivitě
• Znovuzapojující uživatele
• Působící jako nativní aplikace
• Aktuální
1.2.1 Dohledatelnost (Discoverability)
Aplikace je v internetových vyhledávačích snadněji dohledatelná díky webovému standardu zvaný Web App Manifest, který definuje základní informace o aplikaci. Díky těmto meta datům je aplikace pro internetové vyhledávače srozumitelnější a tím poskytují lepší a přesnější výsledky vyhledávání (Mozilla, 2020).
1.2.2 Odkazovatelnost (Linkability)
Jelikož se jedná o webovou aplikaci, tak lze k aplikaci přistupovat pomocí pouhé URL a není potřeba ji dohledat a instalovat ve specializovaných obchodech s aplikacemi jako je GooglePlay nebo AppStore (Mozilla, 2020).
1.2.3 Instalovatelnost (Installability)
Aplikace lze nainstalovat na domovskou stránku zařízení pouhým odesláním aplikace na domovskou stránku zařízení, tedy bez zbytečného zdlouhavého procesu skrze specializovaný obchod s aplikacemi vydavatele operačního systému zařízení.
1.2.4 Progresivní (Progressive)
Aplikace není nijak vázána na konkrétní prohlížeč či zařízení. Je tedy funkční ve všech hlavních1 prohlížečích (Mozilla, 2020). Podporu hlavních prohlížečů lze zkontrolovat na https://jakearchibald.github.io/isserviceworkerready/ (Archibald, 2021).
1.2.5 Responzivní (Responsiveness)
Aplikace se zobrazuje a přizpůsobuje různým rozlišením na všech zařízeních (desktop, mobil, tablet). Aplikace se nezobrazuje na různých zařízeních identicky, ale rozvržení a obsah stránky se každému zařízení přizpůsobí a maximálně využije její velikost (Mozilla, 2020).
1.2.6 Bezpečnost (Safety)
Aplikace je vyvíjena s ohledem na bezpečnost a využívá protokol HTTPS. Poskytuje tedy bezpečnou komunikaci v počítačové sítí, která zabraňuje odposlouchávání a současně zajišťuje, že s obsahem nebude manipulováno (Richard & al, 2020).
1.2.7 Nezávislost na konektivitě (Network independence)
K dosažení tohoto kritéria se využívá technologie Service worker. Jedná se o službu běžící na pozadí, která umožňuje data aplikace ukládat po delší dobu do cache prohlížeče zařízení.
Tímto způsobem lze aplikaci používat bez nutnosti opětovného načítání dat a docílit tak rychlého spuštění a používání aplikace bez ohledu na kvalitu připojení. Některé funkce, které pracují s existujícím obsahem, mohou požadovat připojení či fungují pouze s omezením. Po opětovném připojení se obsah synchronizuje se serverem a následně se aktualizuje na zařízení uživatele. V případě, že zařízení není připojeno k internetu, je třeba uživatele náležitě informovat (Richard & al, 2020).
1.2.8 Opětovné zapojení uživatele (Re-engageability)
Aplikace se snaží pomocí push notifikacemi opětovně zapojit uživatele do používání aplikace (Mozilla, 2020).
1.2.9 Působící jako nativní aplikace (Native-like)
Při vývoji PWA je doporučeno používat architekturu zvanou aplikační schránka (z anglického Application shell). Hlavní myšlenkou této architektury je rozdělení návrhu
1 Mezi hlavní prohlížeče patří Google Chrome, Mozilla FireFox, Safari, Edge a Opera (Archibald, 2021)
aplikace na dvě části – aplikační schránka (základní prvky grafického rozhraní jako je např.
menu, navigace atd.) a obsah (Richard & al, 2020).
Obrázek 2 Ukázka architektury – aplikační schránky a obsah (Osmani, 2020)
Aplikační schránka se ukládá do cache zařízení (pomocí service worker) a při spouštění aplikace se načítá bez ohledu na připojení. Mimo to také aplikace umožňuje bez připojení načíst obsah, který byl již jednou načten. Dynamický obsah se načítá v závislosti na konektivitě (Osmani, 2020).
1.2.10 Aktuální (Up-to-date)
Starou verzi aplikace, která je uložena v cache zařízení, lze nahradit novou verzí pomocí service worker. Uživatel je o nové verzi informován a je mu nabídnuta možnost aktualizace (Mozilla, 2020).
1.3 Kontrolní seznamy pro PWA
Společnost Google vytvořila kontrolní seznamy pro PWA, které dále dělí na dvě skupiny (Richard & al, 2020):
• Základní PWA kontrolní seznam
• Optimální PWA kontrolní seznam
PWA nemusí splňovat všechna kritéria uvedená v kontrolních seznamech. Některá kritéria se týkají pouze určité funkcionality, kterou aplikace nemusí zahrnovat. Před využitím kontrolních seznamů je vhodné vybrat pouze kritéria, která jsou relevantní k danému projektu.
Stejnou společností byl ke kontrolním seznamům vytvořen analytický nástroj Lighthouse, který automatizovaně testuje jednotlivá kritéria PWA (Google, 2021).
Tabulka 1 Kritéria pro základní PWA (Brightscout, 2018)
ID Kritérium Podpora
Lighthouse
CPWA1 Aplikace používá protokol HTTPS Ano
CPWA2 Aplikace je responzivní na všech velikostech obrazovky Ano CPWA3 Aplikace je instalovatelná (využívá a má správně konfigurovaný
service worker a web app manifest)
Ano
CPWA4 Doba k interaktivitě2 přes 3G připojení je do 10 vteřin Ano CPWA5 Aplikace je funkční ve všech prohlížečích Ne CPWA6 Aplikace je částečně funkční v off-line režimu Ne
CPWA7 Každá webová stránka má své URL Ne
Tabulka 2 Kritéria pro optimální PWA (Brightscout, 2018) ID Kritérium
OPWA1 Obsah stránek je indexovatelný vyhledavačem společnosti Google OPWA2 Metadata Schema.org jsou v případě potřeby k dispozici
OPWA3 Sociální metadata jsou v případě potřeby k dispozici OPWA4 Kanonické URL adresy jsou v případě potřeby k dispozici OPWA5 Stránky využívají History API
OPWA6 Při načítání stránky je pozice obsahu nehybná
OPWA7 Vrácením se ze stránky se zachová scrollovací pozice předešlé stránky OPWA8 Textová pole, při jejich plnění, nejsou překryta klávesnicí
OPWA9 Obsah stránek je možný sdílet i z celoobrazovkového režimu
2 Doba k interaktivitě pochází z anglického pojmu Time To Interactive (zkráceně TTI). Doba k interaktivitě je metrika, která měří dobu, po které je stránka plně interaktivní (Google, 2019).
OPWA10 Stránka se přizpůsobuje velikostem všech zobrazovacích zařízení (desktop, telefon i tablet)
OPWA11 Aplikace uživateli nabídne aplikaci přidat na domovskou stránku
OPWA12 Výzvy k přidání aplikace na domovskou stránku nejsou zobrazovány nadměrně OPWA13 Doba k interaktivitě přes 3G připojení je do 5 vteřin
OPWA14 Aplikace používá cache-first přístup (aplikace načítá prvně data z mezipaměti zařízení)
OPWA15 Pokud není zařízení připojeno k internetu, aplikace uživatele vhodně informuje OPWA16 Aplikace poskytuje uživateli informace o tom, jak budou notifikace použity OPWA17 Oznámení povzbuzující uživatele k zapnutí push notifikací nesmí být příliš
agresivní
OPWA18 Při zobrazení žádosti o povolení se jas obrazovky ztlumí OPWA19 Push notifikace jsou včasná, přesná a relevantní
OPWA20 Aplikace poskytuje možnost push notifikace vypnout a zapnout
OPWA21 K placení se využívá Native UI, které je poskytováno Payment Request API
1.4 Struktura PWA
Tato kapitola se zabývá důležitými prvky tvorby PWA. Kapitola je rozdělena tak, aby byly souhrnně popsány možnosti naplnění všech požadavků PWA uvedených v předchozí kapitole. Při dodržení všech bodů v této kapitole by měla aplikace splňovat všechna kritéria uvedených v kontrolním seznamu.
Předpokladem v této kapitole je SPA webová aplikace, která se bude rozšiřovat o funkcionality, které PWA nabízí.
1.4.1 Service Worker
Service Worker (česky služba na pozadí) je script běžící na pozadí. Je kompletně oddělen od webové stránky a nemá tedy přímý přístup k DOM. Místo toho komunikuje s webovou stránkou prostřednictvím rozhraní. Service worker je nedílnou součástí PWA a umožňují vývojářům implementovat funkce, které dělají běžné webové aplikace progresivními.
Webová aplikace se bez service worker spouští pouze na serverové nebo klientské části webové aplikace. Service worker v podstatě funguje jako proxy server, který je umístěn mezi
webovou aplikací, prohlížečem a sítí (je-li k dispozici). Z této mezivstrvy může service worker reagovat na události webové aplikace.
Service worker funguje nezávisle na připojení k internetu. V případě, že samotná aplikace nebude připojena k internetu, service worker nedostupnost rozpozná, zachytí požadavek a vrátí obsah, který byl uložen v cache.
Obdobně funguje i při zavření záložky prohlížeče s aplikací. Service worker na pozadí stále poslouchá a komunikuje se serverem. Tímto způsobem může provádět různé akce, jako je např. upozornění uživatele posíláním notifikací (GDev, 2019).
Životní cyklus
První událostí životního cyklus service worker je registrace, která je prvním krokem instalace. Registrace probíhá pomocí javascriptového kódu. Po úspěšné instalaci nastává aktivační krok, kdy je možné spouštět další akce jako je např. manipulace dat v cache. Po aktivaci může být service worker v jednom ze dvou stavů: buď bude service worker
ukončen, aby se šetřilo pamětí, nebo bude zpracovávat události načítání a zpráv, ke kterým dojde při odeslání požadavků z webové aplikace (GDev, 2019).
Obrázek 3 Životní cyklus service workeru při první instalaci (GDev, 2019)
Registrace service workeru
Nejvyšší prioritou by mělo být zajištění pozitivního zážitku pro uživatele z první návštěvy.
Je tedy nutné, aby registrace service workeru proběhla až po načtení stránky.
if ('serviceWorker' in navigator) {
window.addEventListener('load', () => {
navigator.serviceWorker.register('/service-worker.js').then((registration)
=> {
// Registrace úspěšná
console.log('Registrace service workeru úspěšná se scopem: ', registra- tion.scope);
}, function(err) { // Registrace selhala
console.log('Registrace service workeru selhala: ', err);
});
});
}
Výpis zdrojového kódu 1: Registrace service worker (GDev, 2019)
Tato část javascriptového kódu kontroluje, zda je service worker API dostupný. Pokud je API dostupné, registrace proběhne až při úplném načtení obsahu webové stránky.
Argumentem metody register() je cesta k javascriptovému souboru service-worker.js, ve kterém je samotný service worker definován. Při úspěšné registrace kód informuje vývojáře o scope, který definuje, k jakým souborům má service worker přístup (GDev, 2019).
Úspěšnost registrace lze zjistit přímo v prohlížeči. Kontrolu lze provést např. DevTools nástrojem, který integrován přímo v prohlížeči Google Chrome. Na chrome://inspect/#service-workers je zobrazen seznam všech registrovaných service workerů (viz obrázek 4).
Obrázek 4: DevTools - seznam registrovaných service workerů (GDev, 2019) Instalace service workeru
Po úspěšné registraci následuje instalace. Instalace je spouštěna událostí install, kterou zachycuje service worker a která dále volá další akce. Jednou z těchto akcí může být uložení stránky do cache prohlížeče (viz Výpis zdrojového kódu 2) (GDev, 2019).
var CACHE_NAME = 'my-site-cache-v1';
var urlsToCache = [ '/',
'/styles/main.css', '/script/main.js' ];
self.addEventListener('install', function(event) { // Instalace
event.waitUntil(
caches.open(CACHE_NAME) .then(function(cache) {
return cache.addAll(urlsToCache);
}) );
});
Výpis zdrojového kódu 2: Instalace service workeru (GDev, 2019)
V momentě, kdy se do cache prohlížeče uloží všechny soubory, bude instalace service workeru úspěšně ukončena. V opačném případě instalace selže a nový pokus o instalaci proběhne až při dalším načtení stránky.
Aktivace service workeru
Po instalačním kroku následuje krok aktivační. V případě, že je nějaká část aplikace stále řízena předchozím service workerem, přejde nově nainstalovaný service worker do stavu čekání. Service worker je aktivován jen v případě, kdy již není žádná část aplikace řízena předchozím service workerem. Metoda activate tedy zajišťuje to, že v daný okamžik běží pouze jedna verze service workeru (GDev, 2019).
self.addEventListener('activate', evet => { // Dělej něco
});
Výpis zdrojového kódu 3: Aktivace Service Workeru (GDev, 2019) Další události
Service worker je řízen událostmi. Procesy instalace a aktivace spouští odpovídající instalační a aktivační události, na které je service worker schopen odpovídat. Mezi tyto události patří (GDev, 2019):
- Message – událost, pomocí které service worker přijímá informace z jiných skriptů - Fetch – událost, pomocí které service worker reaguje na HTTP požadavek
- Push – událost, pomocí které service worker posílá notifikace
- Sync – událost, pomocí které service worker synchronizuje data
1.4.2 Bezpečnost
Service worker je schopen manipulovat s odpověďmi, které uživatel dostane. Proto je nezbytné, aby veškerá komunikace mezi klientem, service workerem a serverem byla šifrovaná. Jedním z útoků, na který by mohl uživatel na nezabezpečené aplikaci narazit je tzv. man-in-the-middle útok3.
Proti útokům tohoto typu je možné se bránit protokolem HTTPS, který společně s SSL nebo novějším TLS certifikátem ověřuje identitu webového serveru. O vystavení certifikátu lze zažádat u certifikačních autorit jako je např. Let's Encrypt. Po vystavení je třeba certifikát na serveru nainstalovat.
Ověření, zda aplikace používá HTTPS protokol, je možné zjistit z webového prohlížeče.
Pokud webová adresa na adresním řádku začíná na https, nutně to neznamená, že je stránka zabezpečená. Dále je nutné zkontrolovat i platnost certifikátu (Google, 2021).
Obrázek 5: Ukázka HTTPS protokolu a platného certifikátu
1.4.3 Web app manifest
Web app manifest dokument poskytující informace o webové aplikaci v JSON formátu, který umožňuje stažení a správného zobrazení webové aplikace na ploše zařízení. PWA manifest obsahuje mnoho klíčů. K tomu, aby se dala aplikace přidat na plochu zařízení je třeba definovat alespoň tyto klíče4 (Mozilla, 2021):
- name – název aplikace, které bude zobrazeno na ploše zařízení
3 Man in the middle útok je útok na kryptografii, kde se útočník snaží odposlouchávat a měnit komunikaci mezi účastníky tak, že se stane aktivním prostředníkem (Wikipedia, 2021).
4 Kompletní seznam klíčů je popsán v dokumentaci Web App Manifests (Mozilla, 2021).
- start_url – preferovaná adresa, která se načte při spuštění aplikace - icons – ikona aplikace, která bude zobrazena na ploše zařízení
- display – určuje preferovaný režim zobrazení webu. Může se jednat např. o režim celé obrazovky, kde nejsou zobrazeny žádné ovládací prvky webového prohlížeče.
Manifest se vkládá do HTML stránky aplikace pomocí elementu <link> v <head>
dokumentu.
{
"name": "HackerWeb",
"short_name": "HackerWeb", "start_url": ".",
"display": "standalone",
"description": "A readable Hacker News app.", "icons": [{
"src": "images/touch/homescreen48.png", "sizes": "48x48",
"type": "image/png"
}, {
"src": "images/touch/homescreen72.png", "sizes": "72x72",
"type": "image/png"
}]
}
Výpis zdrojového kódu 4: Příklad web app manifestu (Mozilla, 2021)
Aby se dala aplikace přidat na plochu, je třeba zajistit následující kritéria (Mozilla, 2021):
- šifrovaná komunikace přes HTTPS
- správně nadefinovaný web app manifest dokument, který obsahuje alespoň minimum klíčů uvedených výše
- k dispozici je vhodná ikona pro zobrazení na ploše zařízení
- prohlížeč Google Chrome navíc vyžaduje registrovaného service workera
1.4.4 Cache a přípojení k internetu
Aplikace by měla alespoň omezeně fungovat i bez připojení k internetu. V případě, že připojení k internetu není dostupné, je nutné uživatele upozornit o nedostupnosti připojení a omezené funkcionalitě prostřednictvím push notifikací. Skutečnost, zda je klient připojen k internetu, lze zjistit zachycováním událostí offline a online (Mozilla, 2021).
function updateOnlineStatus(event) { // Dělej něco když online/onffline }
window.addEventListener('online', updateOnlineStatus);
window.addEventListener('offline', updateOnlineStatus);
});
Výpis zdrojového kódu 5: Zachycení stavu připojení (Mozilla, 2021)
Aby aplikace fungovala částečně i offline, je nutné ukládat statický obsah (HTML, JavaScript, CSS, obrázky atd.) a data do cache prohližeče. Obecně je doporučeno využívat Cache Storage API (součást service worker) na statický obsah aplikace a pro ostatní data využívat IndexedDB (Web.dev, 2019).
Ukládání zdrojů
(Google, 2019) ve své dokumentaci uvádí několik situací, kdy ukládat zdroje do cache:
Při instalaci (jako dependency) – Přístup vhodný pro ukládání statického obsahu webové aplikace. Jedná se o HTML, JavaSript, CSS soubory nebo obrázky. Ukládání probíhá s počáteční instalací service workeru. Depedency je chápáno, jako závislost při instalaci.
Pokud by instalace service workeru nebo ukládání do cache selhalo, proces selže a celá akce se opakuje.
Při instalaci – Přístup vhodný pro ukládání většího obsahu, kdy obsah není potřebný při počáteční instalaci, ale až v pozdější fázi. Příkladem může být např. hra, která si při instalaci uloží jen první část hry. Druhá část se nainstaluje po skončení první části.
Při aktivaci – Přístup vhodný pro smazání či migraci dat z cache. Jakmile se nainstaluje nový service worker a předchozí verze se nevyužívá, nový service worker se aktivuje a zachytí událost activate. Zvolená data se přesunou do nové cache a zbytek se smaže.
Při interakci s uživatelem – V případě, že celou webovou stránku nelze uložit do cache prohlížeče, si uživatel zvolí část obsahu, která se do cache uloží a bude dostupná i bez internetového připojení. Může se jednat např. o video, článek, obrázek apod.
Při požadavku ze sítě – Pokud nejsou data v cache, jsou data získána ze sítě. Data se zobrazí uživateli v prohlížeči a uloží do cache. Je třeba dbát opatrnosti, aby se nezaplnilo uložiště.
Načítání zdrojů z cache
Dále (Google, 2019) představuje strategie načítání dat z cache a ze sítě. Mezi nejčastěji využívané strategie patří:
Výhradně z cache – Strategie ideální pro ukládání statické části aplikace, která se nemění. Jedná se např. o statický soubor pro vykreslování webové stránky, který je uložen v cache při instalaci service workeru.
Obrázek 6: Výhradně z cache (Web.dev, 2020)
Výhradně ze sítě – Strategie ideální pro obsah, který se neustále mění a je třeba mít jeho nejaktuálnější verzi. Také se jedná o všechny HTTP dotazovací metody kromě metody GET – HEAD, POST, PUT, DELETE atd.
Obrázek 7: Výhradně ze sítě (Web.dev, 2020)
Prvně z cache, potom ze sítě – Strategie ideální pro aplikace tvořené s konceptem offline-first. Jedná se kombinaci první a druhé strategie, kdy se zdroje načtou prvně z cache a vše co není uloženo v cache se načte ze sítě.
Obrázek 8: Prvně z cache, potom ze sítě (Web.dev, 2020)
Prvně ze sítě, potom z cache – Strategie ideální pro obsah, který je nutný mít aktuální při dostupnosti připojení. V případě, že připojení není dostupné, se načte starší obsah z cache. Tento přístup má však nedostatky. Pokud by měl uživatel přerušované či pomalé
připojení, musel by čekat, až připojení kompletně selže, aby se mu načetl obsah alespoň z cache. To by způsobilo velkou dobu čekání a aplikace by působila celkově negativně. Proto je doporučeno využívat spíše přístup Prvně z cache, potom ze sítě, kdy se při horší konektivitě načtou alespoň data z cache a při kvalitnějším připojení se data aktualizují.
Obrázek 9: Prvně ze sítě, potom z cache (Web.dev, 2020)
Cache/siť závod – Strategie ideální pro obsah, který dosahuje pouze několika kilobajtů.
V tomto přístupu jde primárně o výkon na zařízeních s pomalým diskem. Data se načtou z cache/sítě podle toho, který je rychlejší.
Obrázek 10: Cache/síť závod (Web.dev, 2020)
1.4.5 Výkon
Jednou z hlavních podmínek při tvorbě webových aplikací je svižné počáteční i opětovné načítání aplikace. Tato podkapitola pojednává pouze o klientské části a možnostech optimalizace.
Zdroje špatně navrhnuté aplikace mohou dosahovat obrovských velikostí. Při nekvalitním internetovém připojení by se zdroje ze serverové části stahovali velmi dlouho a uživatel by tak musel čekat na první načítání a vykreslování aplikace.
Na výkonnost aplikace má nejčastěji vliv neoptimalizovaná multimédia a Javascript (Mozilla, 2021).
Optimalizace multimédií
Média, hlavně videa a obrázky, tvoří průměrně více než 70 % při stahování zdrojů ze serveru.
Proto by neměla být zanedbána. Technik optimalizace je několik, mezi ty nejpoužívanější patří (Mozilla, 2021):
- Lazy loading – načítání multimédií pouze v případě potřeby. Příkladem může být galerie fotek, kde se fotky nenačtou hned při spuštění, ale až poté, co uživatel posune stránkou.
- Výběr optimálního formátu – Optimální formát souboru obvykle závisí na charakteru obrázku. Formát SVG je vhodnější pro obrázky, které mají málo barev a nejsou fotorealistické. PNG formát je vhodný pro ilustrační grafiku, loga, mapy apod. Pokud to situace dovoluje, je doporučeno používat moderní formáty WebP nebo AVIF, které jsou vhodné pro obrázky i animované obrázky.
- Používání optimální velikosti – Pro menší obrazovky budou obrázky v menším rozlišení, a naopak pro větší obrazovky budou obrázky ve větším rozlišení.
Optimalizace javascriptového kódu
Přestože multimédia tvoří většinu stažených zdrojů. Javascript může mít na výkonnost aplikace větší negativní dopad. Podobně jako u multimédií, nejlepší způsob, jak zvýšit výkonnost, je vynechat to, co není opravdu nutné.
Mezi hlavní praktiky optimalizace Javascriptu patří (Mozilla, 2021):
- Snížení množství potřebného kódu – použití knihoven a jejich funkci může zlepšit vývojářskou zkušenost. Prohlížeč si knihovnu stáhne celou i přesto, že se použije pouze jedna funkce, a tím se zvýší množství stažených dat. Proto je nutné zvážit, zda je knihovna zapotřebí či nikoliv.
- Odstranění nepoužitého kódu
- Rozdělení kódu do menších souborů – Technice dělení kódu do menších souborů se nazývá code-splitting. Kód se dělí do kritických a nekritických částí. Pro rozdělení je možné použít nástroje pro zpracování souborů, jako je např. Webpack.
- Optimalizace menších souborů
o Minifikace – Minifikace je proces odstranění nepotřebných nebo nadbytečných dat, aniž by to ovlivnilo způsob, jakým prohlížeč soubory zpracovává. Může zahrnovat odstranění komentářů, prázdných míst a nepoužitého kódu, zkrácení názvů funkcí a proměnných.
o Komprese souborů – Ke kompresi souborů se většinou používá Gzipping či Brotli. Komprese dokáže snížit velikost souboru až o 95 % a je doporučeno používat kompresi v každém případě.
1.4.6 History API
Přístup k historii relací prohlížeče je poskytován prostřednictvím objektu history. Objekt umožňuje procházení vpřed a zpět v historií uživatele a manipulovat s obsahem history stacku5. History API také umožňuje to, aby každá webová stránka měla unikátní URL adresu (Mozilla, 2021).
History API také dovoluje webovým aplikacím explicitně nastavit výchozí chování scrollování při přechodu na předešlou stránku. Tohoto chování je docíleno pomocí scrollRestoration (Mozilla, 2021).
window.onpopstate = function(event) {
alert(`location: ${document.location}, state:${JSON.stringify(event.state)}`) }
history.pushState({page: 1}, "title 1", "?page=1") history.pushState({page: 2}, "title 2", "?page=2") history.replaceState({page: 3}, "title 3", "?page=3") history.back()
history.back() history.go(2)
Výpis zdrojového kódu 6: History API (Mozilla, 2021)
1.4.7 Indexace ve webových vyhledávačích
Indexace javascriptových aplikací funguje v každém vyhledávači odlišně. Proces indexace bude popsán pouze pro nejvyužívanější vyhledávač od společnosti Google.
K indexaci používá tzv. Googlebot. Googlebot zpracovává javascriptové aplikace ve třech fázích (Google, 2021):
1) Crawling (prohledávání) 2) Rendering (vykreslování) 3) Indexace
Proces procházení začíná se seznamem webových adres z minulých vyhledávání a mapami webů, které byli poskytnuty jejich vlastníky. Prohledávač (crawler) zkontroluje soubor robots.txt, kde si ověří oprávnění k prohledávání. Dále Googlebot načte všechny povolené stránky k vykreslování a dochází k vyhodnocení důležitých parametrů – od klíčových slov až po stáří webové stránky. Vše se následně zaznamená do indexu vyhledávání.
Procházení webových stránek vytvořených v javascriptu je problematické, jelikož počáteční HTML soubor neobsahuje v HTTP hlavičce skutečný obsah stránek. Tento problém se dá
5 Stack, nebo také zásobník, je obecná datová struktura, která se používá jako uložiště pro dočasná data (Wikipedia, 2021)
vyřešit pomocí tzv. server side rendering (dále jen SSR), což je technika, ve které se stránky vykreslují na serverové části. Server dále vykreslenou stránku pošle ve formě odpovědi klientovi (Google, 2021).
Framework React obsahuje balíček react-dom, který umožňuje na serveru vygenerovat textovou podobu toho, co se má vykreslit na klientské části (Facebook, 2021).
Metadata Schema.org
Schema.org je slovník, který slouží k popisu strukturovaných dat. Strukturovaná data jsou standardizovaný formát pro poskytování informací o stránce a pro třídění obsahu stránky.
Vyhledávání Google také strukturovaná data používá k aktivaci zvláštních funkcí a vylepšení výsledků vyhledávání. Popis dat by měl být ve formátu JSON-LD (Google, 2021).
<div itemscope itemtype ="https://schema.org/Movie">
<h1 itemprop="name">Avatar</h1>
<div itemprop="director" itemscope itemtype="https://schema.org/Person">
Director: <span itemprop="name">James Cameron</span>
(born <span itemprop="birthDate">August 16, 1954</span>) </div>
<span itemprop="genre">Science fiction</span>
<a href="../movies/avatar-theatrical-trailer.html"
itemprop="trailer">Trailer</a>
</div>
Výpis zdrojového kódu 7: Metadata Schema.org (Google, 2021) Kanonické URL
Kanonická adresa URL je adresa URL nejlepší reprezentativní stránky ze skupiny duplicitních stránek podle vyhledávače. Jestliže existují např. dvě adresy URL pro jednu stránku (priklad.cz?priklad=1234 a priklad.cz/priklady/1234), vyhledávač jednu vybere jako kanonickou. Podobně platí, že pokud existuje více stránek, které jsou téměř totožné, může je vyhledávač seskupit. Jedná se např. o stránky, které se liší pouze řazením nebo filtrováním obsahu, třeba podle ceny nebo barvy položky (Google, 2021).
Vyhledávačům je možné explicitně sdělit, která URL je kanonická. Zapisuje se do hlavičky stránky do tagu <link> s atributem rel=”canonical”.
1.4.8 Metadata sociálních sítí
Metadata sociálních sítíInformace, které se při sdílení odkazu na nějaký web objeví na sociálních sítích nejsou načítány náhodně. Obrázek, název článku i doplňkový text lze ovlivnit pomocí protokolu Open Graph. Jedná se o speciální meta značky v HTML souboru stránky. Je možné upravit URL, titulek, popisek, typ obsahu a obrázek (OGP, 2021).
<head>
<meta property="og:title" content="Titulek" />
<meta property="og:description" content="Popisek"/>
<meta property="og:type" content="Typ obsahu" />
<meta property="og:image" content="obrázek.webp" />
<meta property="og:url" content="https://www.url.cz" />
</head>
Výpis zdrojového kódu 8: Příklad umístění značek Open Graph v hlavičce HTML (zdroj: autor)
1.4.9 Responzivní web design
Aplikace s responzivním web designem se automaticky přizpůsobuje různým rozlišením a správně se zobrazuje, jak na mobilních zařízeních (tablet, mobil), tak i desktopových zařízeních. Responzivity lze dosáhnout pomocí Viewport a Media Queries.
Viewport
V kontextu webového designu je Viewport označení pro výřez stránky viditelný v okně prohlížeče. Na zařízeních, kde je možné měnit velikost okna (typicky se jedná o desktopové zařízení), tedy viewport představuje šířku a výšku okna bez rozhraní prohlížeče.
Manipulace s tímto výřezem probíhá pomocí meta tagu v hlavičce HTML souboru (Mozilla, 2021).
<meta name="viewport" content="width=device-width, initial-scale=1.0">
Výpis zdrojového kódu 9: Viewport – meta tag (zdroj: autor)
Width udává šířku layoutového viewportu v pixelech. Nejčastěji využívaná hodnota device-width sjednotí šířku layoutového viewportu se šířkou ideálního viewportu.
Uživatel si nebude muset webovou stránku přibližovat.
Initial-scale prakticky dělá totéž, co width=device-width. Uvádí se kvůli kompatibilitě se staršími prohlížeči (Mozilla, 2021).
Media Queries
Media Queries jsou podmínky, které umožňují aplikovat různá CSS pravidla v různých technických kontextech.
@media screen and (max-width: 800px) { /* CSS pravidla */
}
Výpis zdrojového kódu 10: Media Queries (zdroj: autor)
Media Query se skládá z typu média (@media screen) a podmínky, která obsahuje vlastnosti média s hodnotou (max-width: 800px).
1.4.10 UX
Z optimálních kritérií týkajících se uživatelské přívětivosti zbývá vyřešit nehybnost pozice obsahu stránky při načítání a překrývání textového pole klávesnicí.
Nehybnost pozice obsahu stránky při načítání
Při počátečním vykreslování obsahu je možné, že pozice obsahu bude na obrazovce přeskakovat. Jedná se např. o načítání obrázků. Řešení, jak tento problém vyřešit, existuje více. Avšak nejběžnějším řešením je nastavení fixní velikosti elementu pomocí min-height, který pro obrázek vytvoří prázdné místo se správnou velikostí. Po vykreslení obrázek nezpůsobí skákání obsahu.
V situaci, kdy není možné nastavit fixní velikost elementu, lze použít transition (přechod).
Použitím plynulých přechodů může neočekávaná změna obsahu působit méně rušivě (CSS- TRICKS, 2016).
Překrývání textového pole klávesnicí
Při aktivaci textového pole na mobilním zařízení se uživateli zobrazí klávesnice. Klávesnice může textové pole skrýt a uživatel bude muset obrazovku posunout tak, aby viděl co do pole zadává. Použitím javascriptové metody scrollIntoViewIfNeeded() a scrollIntoView() lze tento problém eliminovat. Obě metody posouvají element, na který je metoda volána, tak aby na něj uživatel viděl. Obecně není doporučeno používat metodu scrollIntoViewIfNeeded(), jelikož je poměrně nová a není podporována na všech hlavních prohlížečích (Mozilla, 2021).
1.4.11 Push notifikace
Notifikace je oznámení nebo upozornění. Obvykle se jedná o krátkou textovou zprávu, která oznamuje nějakou aktualitu. Notifikace má například podobu upozornění na nově příchozí poštu, oznámení o změně stavu platby nebo připomenutí nadcházející události.
Push notifikaci je možné poslat jak z klientské částí aplikace, tak i ze serverové. Klientská část využívá Web Notification API (Mozilla, 2021) a pokud je klientská část neaktivní (změna okna v prohlížeči, minimalizace prohližeče apod.), tak se notifikace posílají přes serverovou část, která využívá Push API (Mozilla, 2021).
Web Notifications API
Nejprve musí udělit uživatel oprávnění k zobrazování systémových notifikací, což se obvykle provádí při první inicializaci aplikace pomocí metody Notification.requestPermission(). V případě, že uživatel oprávnění odmítne, by se neměla žádost při další návštěvě zobrazit. V žádosti by měl být také uveden důvod a informace o tom, jaké notifikace bude uživatel dostávat. Notifikace se vytváří pomocí konstruktoru Notification() (Mozilla, 2021).
Push API
Každý prohlížeč spravuje push notifikace prostřednictvím svého vlastního systému, který se nazývá push service (česky push služba). V případě udělení oprávnění k zasílání notifikací je možné aplikaci přihlásit k push službě prohlížeče. Tímto se vytvoří speciální objekt obsahující endpoint URL (URL koncového bodu), který je unikátní, a veřejný klíč. Na tuto URL adresu se zasílá zašifrovaná push zpráva a push služba zasílá notifikaci správnému klientovi.
Shrnutí celého procesu odesílání a přijímání push zprávy a následného zobrazení notifikace se dá shrnout následnovně (Mozilla, 2021):
Na straně klienta:
- Přihlášení k push službě
- Odeslání vytvořeného objektu na server Na straně serveru:
- Generování dat, které budou uživateli odeslány - Šifrování vygenerovaných dat pomocí veřejného klíče
- Odeslání zašifrovaných dat na URL koncového bodu push služby
Zpráva probudí prohlížeč, který najde příslušného service workera a vyvolá push událost.
Dále na straně klienta probíhá:
- Zachycení push události - Přijmutí a zpracování dat - Zobrazení notifikace uživateli
self.addEventListener('push', function(event) {
if (!(self.Notification && self.Notification.permission === 'granted')) { return;
}
var data = {};
if (event.data) {
data = event.data.json();
}
var title = data.title || "Something Has Happened";
var message = data.message || "Here's something you might want to check out.";
var icon = "images/new-notification.png";
var notification = new self.Notification(title, { body: message,
tag: 'simple-push-demo-notification', icon: icon
});
notification.addEventListener('click', function() { if (clients.openWindow) {
clients.openWindow('https://example.blog.com/2015/03/04/something- new.html');
} });
});
Výpis zdrojového kódu 11: Zpracování push události (zdroj: autor)
1.4.12 Podpora prohlížečů
Jeden z hlavních požadavků PWA je podpora všech hlavních prohlížečů – Google Chrome, Mozilla FireFox, Safari, Edge a Opera. Hlavní zdroj informací pro kontrolu podpory využívaných API byl webový portál MDN Web Docs (Mozilla, 2021). Jedná se o portál, který obsahuje nejen dokumentaci k API, ale také popis webových standardů a technologií.
Všechny potřebné API jsou na hlavních prohlížečích podporované. Výjimkou je prohlížeč Safari, který nepodporuje Push API a jen částečně podporuje Web Notification API.
Safari
Safari, webový prohlížeč společnosti Apple, na zařízeních s operačním systémem iOS a iPadOS je podpora Web Notification API velmi omezená. Na těchto zařízeních není možné zobrazit notifikace odděleně. Notifikace je možné zobrazit v rámci webové aplikace, avšak po přepnutí či minimalizaci aplikace není možné uživateli poslat notifikaci.
Jak již bylo zmíněno, Push API není podporováno v žádné verzi Safari. Pro Safari na desktopových zařízeních společnost Apple vyvinula vlastní implementaci push API, které
využívá tzv. Apple’s push notification service (dále jen APNs) (Apple, 2021). Vedle standardní implementace Push API je nutné implementovat také APNs. Pro Safari na mobilních zařízeních není v době psaní téhle práce žádné řešení.
1.5 PWA vs Nativní mobilní aplikace
Některé funkcionality PWA jsou omezeny podporou prohlížečů nebo mobilních zařízeních na, kterých se aplikace spouští. Tato podkapitola srovnává PWA pouze s nativními mobilními aplikacemi, jelikož jsou PWA zaměřené primárně na mobilní zařízení.
Srovnání je členěno do následujících oblastí:
- Publikace a dostupnost - Výkon
- Přístup k hardwaru a k funkcionalitám specifickým pro mobilní zařízení - Implementace
1.5.1 Publikace a dostupnost
Nativní mobilní aplikace jsou publikovány v příslušném digitálním obchodě s aplikacemi.
Zařízení s operačním systém Android mohou stahovat aplikace z Google Play Store.
Ekvivalentem pro zařízení s operačním systémem iOS, iPadOS a macOS je App Store.
Aplikace se po stažení uloží do interní paměti zařízení a dají se spouštět bez internetového připojení.
PWA se načítají z webového prohlížeče a pomocí service workeru je možné aplikaci nainstalovat. Aplikace se uloží do cache a je taktéž spustitelná bez internetového připojení.
V následujících tabulkách jsou popsané výhody a nevýhody jednotlivých platforem týkajících se jejich publikace a dostupnosti.
Tabulka 3: Výhody a nevýhody publikace a dostupnosti nativních aplikací (zdroj: autor) Nativní mobilní aplikace
Výhody
Distribuční služba s aplikacemi má jistá pravidla a požadavky, které se musí splnit při publikaci aplikací. Ne všechny aplikace se tak dostanou do katalogu, a tím se celkově zvýší bezpečnost a kvalita aplikací.
Obchod poskytuje procházení nabídky softwaru, vyhledání, prohlížení kategorií, žebříčků a recenzí, což značně zjednoduší výběr správné aplikace.
Nevýhody
Pro používání aplikace je nutná instalace
Komplexní proces publikace aplikace
Tabulka 4: Výhody a nevýhody publikace a dostupnosti PWA (zdroj: autor) PWA
Výhody
PWA je dostupná z prohlížeče a není tedy nutná instalace.
PWA lze nechat vyhledávači indexovat. Na webových vyhledávačích je tak jednodušeji dohledatelná.
Nevýhody
Absence katalogu nebo obchodu s dostupnými PWA, které by bylo spravováno vyšší autoritou6.
1.5.2 Výkon
Nativní mobilní aplikace, jak už z názvu vypovídá, běží na zařízeních nativně. Má možnost přistupovat k hardwaru a softwaru zařízení a tyto systémové prostředky dokáže lépe optimalizovat.
Díky ukládání zdrojů aplikace do cache se progresivní webové aplikace načítají rychleji.
Hlavním důvodem, proč PWA nebudou nikdy výkonnější než nativní aplikace, je že se PWA spouští z prohlížeče. Při špatné konektivitě může docházet k latenci. Také mají vyšší spotřebu baterie (Relevant, 2021).
1.5.3 Přístup k hardwaru a funkcionalitám mobilního zařízení
Nativní aplikace běžně přistupují k hardwaru a funckionalitám specifickým pro mobilní zařízení. Tyto funkcionality se běžně ve webových aplikacích nevyužívají. Tato podkapitola je věnována podpoře těchto funkcionalit v PWA. Jelikož je PWA spouštěna v prohlížeči, nemusí některé funkcionality vůbec podporovat. Hlavním zdrojem pro kontrolu podpory funkcionalit a přístupu k hardwaru je webový portál What Web Can Do (Bar, 2021), který obsahuje databázi dostupných API a jejich podporu v prohlížečích a zařízeních.
6 Tato nevýhoda se vztahuje pouze na obchod s aplikacemi společnosti Apple (Koombea, 2021).
Společnost nedovoluje publikaci PWA. Publikace PWA do Google Play Store je povolena (Medium, 2019).
Geolokace
Poloha zařízení se získává pomocí Geolocation API, které umožňuje autorizovaným webovým aplikacím přistupovat k údajům o poloze poskytnuté zařízením. Poloha se získává pomocí GPS nebo ze sítě (Bar, 2021).
Fotoaparát a mikrofon
Focení, natáčení videa či nahrávání zvuku jsou dostupné v PWA pomocí Media Capture API.
Media Capture API umožňuje používat data dostupná z fotoaparátu a mikrofonu zařízení, případně i záznamy pořizovat. Pořizování fotografií pomocí tohoto API je velmi omezené (Bar, 2021). K použití pokročilejších nastavení fotoaparátu, jako je např. přibližování, vyváženost barev, ISO nebo zaostřovací body, je Image Capture API (Bar, 2021).
Úložiště
Aplikace může k souborům zařízení přistupovat pomocí File API. Aplikace bude mít pouze read-only oprávnění. Native File Systém API, které je momentálně ve fázi návrhu, by mělo v budoucnu umožnit soubory i editovat (Bar, 2021).
Co se offline uložiště týče existují tři standardizované a plně dostupné technologie: Web Storage, IndexedDB API a Cache API. Každý slouží k něčemu jinému. Web storage dovoluje ukládat pouze textová data ve formátu JSON a byl navržen pro menší objem dat. IndexedDB slouží jako uložiště pro větší objem strukturovaných dat. Cache API slouží k ukládání statického obsahu webové aplikace (Bar, 2021).
Notifikace
Posílání notifikací z klientské i serverové části je popsáno v předchozí kapitole (viz. 1.4 Struktura PWA).
Orientace a pozice zařízení
Screen Orientation API umožňuje webovým aplikacím získat informace o aktuální orientaci stránky (na výšku nebo na šířku) a také uzamknout orientaci obrazovky v požadovaném stavu (Bar, 2021).
Device Orientation API umožňuje webovým aplikacím přistupovat k datům gyroskopu a kompasu, aby bylo možné určit statickou orientaci zařízení ve všech třech dimenzích (Bar, 2021).
Funkcionality zařízení
Stav připojení a chování PWA při nedostupném připojení je popsáno výše (viz. 1.4 Struktura PWA).
Informace jako typ připojení a maximální rychlost stahování lze zjistit pomocí Network Information API. Toto API je podporováno pouze v prohlížečích Google Chrome na zařízeních Android (Bar, 2021).
Stav baterie lze zjistit pomocí Battery Status API. Kromě stavu baterie lze zjistit informace o zdroji napájení, úroveň nabití, předpokládané době plného nabití či vybití (Bar, 2021).
Vibration API umožňuje aplikaci spouštět v případě potřeby vibrace. API není v Safari podporováno (Bar, 2021).
Bezdrátová komunikace
Web Bluetooth API umožňuje párování s blízkými periferními zařízeními podporující technologii Bluetooth Low Energy a přístup k jejich službám (Bar, 2021).
Schopnost číst a zapisovat do zařízení NFC (Near-Field Communication) umožňuje Web NFC API. Toto API je v experimentální fázi a je částečně podporovaná pouze v prohlížeči Chrome pro Android (Bar, 2021).
Volání, SMS a MMS
Volání, přístup ke kontaktům zařízení, zasílání a přijímání SMS či MMS není povoleno v žádném prohlížeči.
1.5.4 Implementace
Nativní mobilní aplikace je nutné vyvíjet pro každou platformu zvlášť. Aplikace pro zařízení s operačním systémem Android se vyvíjí v jazyce Java, Kotlin nebo C#. Aplikace pro iOS, iPadOS, macOS jsou vyvíjeny v jazyce Switch či Objective-C. Což většinou znamená, že je nutné mít specializované týmy pro každý programovací jazyk. Taková implementace je z hlediska finančního, technologického i časového hlediska velmi náročná.
PWA je možné napsat v jednom jazyce – Javascript nebo C#. Výsledná aplikace bude spustitelná nejen na mobilních zařízeních a prohlížečích, ale i na desktopových zařízeních.
