Un ghid pentru începători pentru aplicații web progresive

Aplicațiile web progresive ar putea fi următorul lucru important pentru web-ul mobil. Propuși inițial de Google în 2015, ele au atras deja multă atenție din cauza relative ușurinței de dezvoltare și a câștigurilor aproape instantanee pentru experiența de utilizare a aplicației.

Citiți suplimentare despre SmashingMag:

• Elementele de bază ale aplicațiilor web progresive
• Elemente esențiale de design conversațional: sfaturi pentru construirea unui chatbot
• Creați o aplicație de primă clasă care să vă folosească site-ul
• Crearea unei aplicații web complete în Foundation For Apps

O aplicație web progresivă profită de cele mai noi tehnologii pentru a combina cele mai bune aplicații web și mobile . Gândiți-vă la el ca la un site web construit folosind tehnologii web, dar care acționează și se simte ca o aplicație. Progresele recente în browser și în disponibilitatea lucrătorilor de servicii și în API-urile Cache și Push le-au permis dezvoltatorilor web să permită utilizatorilor să instaleze aplicații web pe ecranul lor de start, să primească notificări push și chiar să lucreze offline.

Aplicațiile web progresive profită de ecosistemul web, pluginurile și comunitatea mult mai mare și de ușurința relativă de implementare și întreținere a unui site web în comparație cu o aplicație nativă din magazinele de aplicații respective. Pentru cei dintre voi care dezvoltați atât pe mobil, cât și pe web, veți aprecia că un site web poate fi construit în mai puțin timp, că un API nu trebuie să fie întreținut cu compatibilitate inversă (toți utilizatorii vor rula aceeași versiune a site-ului dvs. cod, spre deosebire de fragmentarea versiunii a aplicațiilor native) și că aplicația va fi în general mai ușor de implementat și întreținut .

De ce aplicații web progresive?

Un studiu a arătat că, în medie, o aplicație pierde 20% din utilizatorii săi pentru fiecare pas între primul contact al utilizatorului cu aplicația și utilizatorul începe să folosească aplicația. Un utilizator trebuie mai întâi să găsească aplicația într-un magazin de aplicații, să o descarce, să o instaleze și apoi, în cele din urmă, să o deschidă. Când un utilizator găsește aplicația dvs. web progresivă, va putea începe imediat să o utilizeze, eliminând etapele inutile de descărcare și instalare. Și când utilizatorul revine la aplicație, i se va solicita să instaleze aplicația și să facă upgrade la o experiență pe ecran complet.

Cu toate acestea, o aplicație nativă cu siguranță nu este deloc rea. Aplicațiile mobile cu notificări push realizează de până la trei ori mai multă reținere decât omologii lor fără push, iar un utilizator are de trei ori mai multe șanse să redeschidă o aplicație mobilă decât un site web. În plus, o aplicație mobilă bine concepută consumă mai puține date și este mult mai rapidă, deoarece unele resurse rezidă pe dispozitiv.

O aplicație web progresivă profită de caracteristicile unei aplicații mobile, rezultând în reținerea și performanța utilizatorilor îmbunătățite, fără complicațiile pe care le implică întreținerea unei aplicații mobile.

Cazuri de utilizare

Când ar trebui să construiți o aplicație web progresivă? Nativ este de obicei recomandat pentru aplicațiile la care vă așteptați ca utilizatorii să revină frecvent, iar o aplicație web progresivă nu este diferită. Flipkart folosește o aplicație web progresivă pentru populara sa platformă de comerț electronic, Flipkart Lite, iar SBB utilizează o aplicație web progresivă pentru procesul de check-in online, permițând utilizatorilor să-și acceseze biletele fără conexiune la internet.

Când evaluați dacă următoarea dvs. aplicație ar trebui să fie o aplicație web progresivă, un site web sau o aplicație mobilă nativă, mai întâi identificați utilizatorii și cele mai importante acțiuni ale utilizatorului. Fiind „progresivă”, o aplicație web progresivă funcționează în toate browserele, iar experiența este îmbunătățită ori de câte ori browserul utilizatorului este actualizat cu funcții și API-uri noi și îmbunătățite.

Astfel, nu există niciun compromis în experiența utilizatorului cu o aplicație web progresivă în comparație cu un site web tradițional; totuși, poate fi necesar să decideți ce funcționalitate să suportați offline și va trebui să facilitați navigarea (rețineți că în modul de sine stătător, utilizatorul nu are acces la butonul înapoi). Dacă site-ul dvs. are deja o interfață asemănătoare aplicației, aplicarea conceptelor de aplicații web progresive nu va face decât să-l îmbunătățească .

Dacă anumite funcții sunt necesare pentru acțiunile critice ale utilizatorului, dar nu sunt încă disponibile din cauza lipsei de suport între browsere, atunci o aplicație mobilă nativă ar putea fi opțiunea mai bună, garantând aceeași experiență pentru toți utilizatorii.

Caracteristicile unei aplicații web progresive

Înainte de a intra în cod, este important să înțelegem că aplicațiile web progresive au următoarele caracteristici:

• Progresist . Prin definiție, o aplicație web progresivă trebuie să funcționeze pe orice dispozitiv și să se îmbunătățească progresiv, profitând de orice caracteristici disponibile pe dispozitivul și browserul utilizatorului.
• Descoperibil . Deoarece o aplicație web progresivă este un site web, ar trebui să fie descoperită în motoarele de căutare. Acesta este un avantaj major față de aplicațiile native, care încă rămân în urma site-urilor web în ceea ce privește capacitatea de căutare.
• Legabil . Ca o altă caracteristică moștenită de la site-uri web, un site web bine conceput ar trebui să folosească URI-ul pentru a indica starea curentă a aplicației. Acest lucru va permite aplicației web să-și păstreze sau să-și reîncarce starea atunci când utilizatorul marchează sau distribuie adresa URL a aplicației.
• Receptiv . Interfața de utilizare a unei aplicații web progresive trebuie să se potrivească cu factorul de formă și dimensiunea ecranului dispozitivului.
• Ca o aplicație . O aplicație web progresivă ar trebui să arate ca o aplicație nativă și să fie construită pe modelul shell-ului aplicației, cu reîmprospătări minime ale paginii.
• Independent de conectivitate . Ar trebui să funcționeze în zone cu conectivitate scăzută sau offline (caracteristica noastră preferată).
• Reangajabil . Este mai probabil ca utilizatorii de aplicații mobile să-și refolosească aplicațiile, iar aplicațiile web progresive au scopul de a atinge aceleași obiective prin funcții precum notificările push.
• Instalabil . O aplicație web progresivă poate fi instalată pe ecranul de pornire al dispozitivului, făcându-l ușor disponibil.
• Proaspăt . Când se publică conținut nou și utilizatorul este conectat la internet, acel conținut ar trebui să fie disponibil în aplicație.
• În siguranță . Deoarece o aplicație web progresivă are o experiență de utilizator mai intimă și pentru că toate solicitările de rețea pot fi interceptate prin lucrătorii de servicii, este imperativ ca aplicația să fie găzduită prin HTTPS pentru a preveni atacurile de tip man-in-the-middle.

Hai să codificăm!

Prima noastră aplicație web progresivă, Sky High, va simula programul de sosiri al unui aeroport. Prima dată când utilizatorul accesează aplicația noastră web, dorim să le arătăm o listă de zboruri viitoare, preluate dintr-un API. Dacă utilizatorul nu are o conexiune la internet și reîncarcă aplicația web, dorim să îi arătăm programul de zbor așa cum era când l-a descărcat ultima dată cu o conexiune.

Cele elementare

Prima caracteristică a unei aplicații web progresive este că trebuie să funcționeze pe toate dispozitivele și trebuie să se îmbunătățească pe dispozitivele și browserele care o permit. Prin urmare, ne-am construit site-ul web folosind HTML5 tradițional și JavaScript care simulează preluarea datelor dintr-un API simulat. Pe parcursul aplicației, folosim fragmente mici de Knockout pentru a gestiona legările noastre Model-View-ViewModel (MVVM) - un cadru JavaScript ușor care ne permite să legăm modelele noastre JavaScript la vizualizările noastre HTML. Am ales să folosim Knockout deoarece este relativ simplu de înțeles și nu aglomera codul; cu toate acestea, îl puteți înlocui cu orice alt cadru, cum ar fi React sau AngularJS.

Site-ul nostru web urmează regulile Google pentru proiectarea materialelor, un set de principii care ghidează proiectarea și interacțiunea. Designul materialului nu numai că servește ca un standard unificat pentru aplicații și dispozitive, dar oferă și sens designului. Am folosit designul de materiale pentru vizualizarea sosiri a Sky High pentru a oferi aplicației noastre web progresive acel aspect și senzație de aplicație nativă.

În cele din urmă, ne-am testat aplicația pentru a ne asigura că nu are șocuri și că derularea este netedă. Sa demonstrat că redarea fără Jank îmbunătățește implicarea utilizatorilor. Urmăriți o randare de 60 de cadre pe secundă.

Pentru această demonstrație, vom prelua un fișier JSON static, în loc de un API real. Acest lucru este doar pentru a menține lucrurile simple. În lumea reală, ați interoga un API sau ați folosi WebSockets.

index.html

 <!DOCTYPE html> <html lang="en"> <head> <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>Sky-High Airport Arrivals</title> <link async rel="stylesheet" href="./css/style.css"> <link href="https://fonts.googleapis.com/css?family=Roboto:300,600,300italic,600italic" rel="stylesheet" type="text/css"> </head> <body> <header> <div class="content"> <h3>Arrivals</h3> </div> </header> <div class="container"> <div class="content"> <ul class="arrivals-list" data-bind="foreach: arrivals"> <li class="item"> <span class="title" data-bind="html: title"></span> <span class="status" data-bind="html: status"></span> <span class="time" data-bind="html: time"></span> </li> </ul> </div> </div> <script src="./js/build/vendor.min.js"></script> <script src="./js/build/script.min.js"></script> </body> </html>
<!DOCTYPE html> <html lang="en"> <head> <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>Sky-High Airport Arrivals</title> <link async rel="stylesheet" href="./css/style.css"> <link href="https://fonts.googleapis.com/css?family=Roboto:300,600,300italic,600italic" rel="stylesheet" type="text/css"> </head> <body> <header> <div class="content"> <h3>Arrivals</h3> </div> </header> <div class="container"> <div class="content"> <ul class="arrivals-list" data-bind="foreach: arrivals"> <li class="item"> <span class="title" data-bind="html: title"></span> <span class="status" data-bind="html: status"></span> <span class="time" data-bind="html: time"></span> </li> </ul> </div> </div> <script src="./js/build/vendor.min.js"></script> <script src="./js/build/script.min.js"></script> </body> </html>

Fișierul index.html este relativ standard. Am creat o listă HTML și am legat arrivals proprietății noastre View Model la aceasta folosind Knockout, prin atributul data-bind=“foreach: arrivals” . arrivals de model de vizualizare sunt declarate în fișierul page.js de mai jos și expuse în modulul Page . Pe pagina noastră HTML, pentru fiecare articol din matricea de arrivals , am legat proprietățile title , status și time la vizualizarea HTML.

page.js

 (var Page = (function() { // declare the view model used within the page function ViewModel() { var self = this; self.arrivals = ko.observableArray([]); } // expose the view model through the Page module return { vm: new ViewModel(), hideOfflineWarning: function() { // enable the live data document.querySelector(".arrivals-list").classList.remove('loading') // remove the offline message document.getElementById("offline").remove(); // load the live data }, showOfflineWarning: function() { // disable the live data document.querySelector(".arrivals-list").classList.add('loading') // load html template informing the user they are offline var request = new XMLHttpRequest(); request.open('GET', './offline.html', true); request.onload = function() { if (request.status === 200) { // success // create offline element with HTML loaded from offline.html template var offlineMessageElement = document.createElement("div"); offlineMessageElement.setAttribute("id", "offline"); offlineMessageElement.innerHTML = request.responseText; document.getElementById("main").appendChild(offlineMessageElement); } else { // error retrieving file console.warn('Error retrieving offline.html'); } }; request.onerror = function() { // network errors console.error('Connection error'); }; request.send(); } } })();

Acest fișier page.js expune modulul Page , care conține vm -ul nostru ViewModel și două funcții, hideOfflineWarning și showOfflineWarning . Modelul de vizualizare ViewModel este un simplu literal JavaScript care va fi folosit în întreaga aplicație. Proprietatea sosită pe arrivals este observableArray al lui Knockout, care leagă automat HTML-ul nostru la o matrice JavaScript, permițându-ne să împingem și să introducem elemente în matricea noastră în JavaScript și să actualizăm automat HTML-ul paginii.

Funcțiile hideOfflineWarning și showOfflineWarning permit restului aplicației noastre să apeleze aceste funcții pentru a actualiza interfața de utilizare a paginii care afișează dacă suntem conectați online. showOfflineWarning adaugă o clasă de loading la elementul HTML al arrivals-list pentru a estompa lista, apoi preia fișierul HTML offline.html prin XHR. Presupunând că fișierul a fost preluat cu succes ( response.status === 200 ), îl anexăm la HTML-ul nostru. Desigur, dacă nu folosim lucrători de servicii și utilizatorul nu este conectat la Internet, atunci nu ar fi posibil să recuperăm offline.html și astfel utilizatorul va vedea pagina offline a browserului.

Logica de afaceri de unde preluăm datele din API-ul nostru și le legăm la modelele și vizualizările noastre se găsește în arrivals.js și este funcționalitatea standard MVVM folosind Knockout. În fișierul arrivals.js , pur și simplu inițializam serviciile și modelele de vizualizare pe care le vom folosi în întreaga aplicație și expunem o funcție — Arrivals.loadData() — care preia datele și le leagă de modelul de vizualizare.

Manifestul aplicației web

Să facem aplicația noastră web mai asemănătoare aplicației. Un fișier manifest al aplicației web este un fișier JSON simplu care urmează specificațiile W3C. Cu acesta, este posibil să rulați aplicația web în modul ecran complet ca o aplicație autonomă, să atribuiți o pictogramă care va fi afișată atunci când aplicația este instalată pe dispozitiv și să atribuiți o temă și o culoare de fundal aplicației. În plus, Chrome pe Android va sugera în mod proactiv utilizatorului să instaleze aplicația web, printr-un banner de instalare a aplicației web. Pentru a afișa promptul de instalare, aplicația dvs. web trebuie să:

• au un fișier manifest valid al aplicației web,
• să fie difuzat prin HTTPS,
• să aibă un lucrător de servicii valabil înregistrat,
• au fost vizitate de două ori, cu cel puțin cinci minute între fiecare vizită.

manifest.json

 { "short_name": "Arrivals", "name": "Arrivals at Sky High", "description": "Progressive web application demonstration", "icons": [ { "src": "launcher-icon.png", "sizes": "48x48", "type": "image/png" }, { "src": "launcher-icon-96.png", "sizes": "96x96", "type": "image/png" }, { "src": "launcher-icon-144.png", "sizes": "144x144", "type": "image/png" }, { "src": "launcher-icon-192.png", "sizes": "192x192", "type": "image/png" }, { "src": "launcher-icon-256.png", "sizes": "256x256", "type": "image/png" } ], "start_url": "./?utm_source=web_app_manifest", "display": "standalone", "orientation": "portrait", "theme_color": "#29BDBB", "background_color": "#29BDBB" }

Să defalcăm acest fișier manifest:

• short_name este un nume care poate fi citit de om pentru aplicație. În Chrome pentru Android, acesta este și numele care însoțește pictograma de pe ecranul de pornire.
• name este, de asemenea, un nume care poate fi citit de om pentru aplicație și definește cum va fi listată aplicația.
• description oferă o descriere generală a aplicației web.
• icons definește o serie de imagini de diferite dimensiuni care vor servi drept set de pictograme al aplicației. În Chrome pentru Android, pictograma va fi folosită pe ecranul de start, pe ecranul de pornire și în comutatorul de activități.
• start_url este adresa URL de pornire a aplicației.
• display definește modul de afișare implicit pentru aplicația web: fullscreen , standalone , minimal-ui sau browser .
• orientation definește orientarea implicită pentru aplicația web: portrait sau landscape .
• theme_color este culoarea implicită a temei pentru aplicație. Pe Android, acesta este folosit și pentru a colora bara de stare.
• background_color definește culoarea de fundal a aplicației web. În Chrome, definește și culoarea de fundal a ecranului de splash.
• related_applications nu este implementat în exemplul nostru, dar este folosit pentru a specifica alternative de aplicații native în diferite magazine de aplicații.

Adăugați referința manifest.json la eticheta head a fișierului index.html :

 <link rel="manifest" href="./manifest.json">

Odată ce un utilizator a adăugat aplicația web pe ecranul de pornire, acesta va putea să reinteracționeze cu aplicația dvs. imediat de pe dispozitivul său, fără a fi nevoie să deschidă direct browserul. Puteți vedea cum acest lucru este mult mai mult decât un marcaj web.

Adăugați pe ecranul de pornire pe Chrome pentru Android din Smashing Magazine pe Vimeo.

Lucrători de servicii

Unul dintre cele mai interesante aspecte ale aplicațiilor web progresive este că pot funcționa offline. Folosind lucrători de servicii, este posibil să afișați datele care au fost preluate în sesiunile anterioare ale aplicației (folosind IndexedDB) sau, alternativ, să afișați shell-ul aplicației și să informați utilizatorul că nu sunt conectați la Internet (abordarea pe care am avut-o luate în acest demo). Odată ce utilizatorul se reconecta, putem prelua cele mai recente date de pe server.

Toate acestea sunt posibile prin intermediul lucrătorilor de servicii, care sunt scripturi bazate pe evenimente (scrise în JavaScript) care au acces la evenimente la nivelul întregului domeniu, inclusiv preluări de rețea. Cu ele, putem stoca în cache toate resursele statice, ceea ce ar putea reduce drastic solicitările de rețea și, de asemenea, ar putea îmbunătăți considerabil performanța.

Shell de aplicație

Shell-ul aplicației este HTML, CSS și JavaScript minim necesar pentru a alimenta o interfață cu utilizatorul. O aplicație mobilă nativă include shell-ul aplicației ca parte a distribuibilului său, în timp ce site-urile web de obicei solicită acest lucru prin rețea. Aplicațiile web progresive compensează acest decalaj prin plasarea resurselor și activelor shell-ului aplicației în memoria cache a browserului. În aplicația noastră Sky High, putem vedea că shell-ul aplicației noastre constă din bara de antet de sus, fonturile și orice CSS necesar pentru a le reda elegant.

Pentru a începe cu lucrătorii de servicii, trebuie mai întâi să creăm fișierul JavaScript al lucrătorilor de servicii, sw.js , plasat în directorul rădăcină.

sw.js

 // Use a cacheName for cache versioning var cacheName = 'v1:static'; // During the installation phase, you'll usually want to cache static assets. self.addEventListener('install', function(e) { // Once the service worker is installed, go ahead and fetch the resources to make this work offline. e.waitUntil( caches.open(cacheName).then(function(cache) { return cache.addAll([ './', './css/style.css', './js/build/script.min.js', './js/build/vendor.min.js', './css/fonts/roboto.woff', './offline.html' ]).then(function() { self.skipWaiting(); }); }) ); }); // when the browser fetches a URL… self.addEventListener('fetch', function(event) { // … either respond with the cached object or go ahead and fetch the actual URL event.respondWith( caches.match(event.request).then(function(response) { if (response) { // retrieve from cache return response; } // fetch as normal return fetch(event.request); }) ); });

Să ne uităm mai atent la lucrătorul nostru de service. Mai întâi, setăm o variabilă cacheName . Acesta este folosit pentru a determina dacă s-au făcut modificări la activele noastre din cache. Pentru acest exemplu, vom folosi un nume static, ceea ce înseamnă că activele noastre nu se vor modifica și nu vor necesita actualizare.

 self.addEventListener('install', function(e) { // declare which assets to cache }

Evenimentul de install se declanșează în timpul fazei de instalare a lucrătorului de service și se va declanșa o singură dată dacă lucrătorul de service este deja instalat. Prin urmare, reîmprospătarea paginii nu va declanșa din nou faza de instalare. În timpul fazei de instalare, putem declara ce active vor fi stocate în cache. În exemplul nostru de mai sus, memorăm în cache un fișier CSS, două fișiere JavaScript, fișierul fonturi, șablonul HTML offline și, desigur, rădăcina aplicației. self.skipWaiting() forțează lucrătorul de serviciu în așteptare să devină activ.

Până acum, ne-am declarat lucrătorul de service, dar înainte de a-l vedea în vigoare, trebuie să-l facem referire în JavaScript. În aplicația noastră, o înregistrăm în main.js

 // Register the service worker if available. if ('serviceWorker' in navigator) { navigator.serviceWorker.register('./sw.js').then(function(reg) { console.log('Successfully registered service worker', reg); }).catch(function(err) { console.warn('Error whilst registering service worker', err); }); } window.addEventListener('online', function(e) { // Resync data with server. console.log("You are online"); Page.hideOfflineWarning(); Arrivals.loadData(); }, false); window.addEventListener('offline', function(e) { // Queue up events for server. console.log("You are offline"); Page.showOfflineWarning(); }, false); // Check if the user is connected. if (navigator.onLine) { Arrivals.loadData(); } else { // Show offline message Page.showOfflineWarning(); } // Set Knockout view model bindings. ko.applyBindings(Page.vm);

Am inclus și doi ascultători de evenimente pentru a verifica dacă starea sesiunii s-a schimbat de la online la offline sau invers. Managerii de evenimente apelează apoi diferitele funcții pentru a prelua datele prin Arrivals.loadData() și pentru a activa sau dezactiva mesajul offline prin Page.showOfflineWarning și, respectiv, Page.hideOfflineWarning . Aplicația noastră verifică, de asemenea, dacă utilizatorul este online în prezent, folosind navigator.onLine și fie preia datele, fie afișează avertismentul offline în consecință. Și în ultima linie a main.js , aplicăm legăturile Knockout la View Model Page.vm .

Dacă încărcăm aplicația noastră pentru prima dată (cu Chrome Developer Tools), nu vom vedea nimic nou. Cu toate acestea, la reîncărcare, vom vedea că un număr de resurse de rețea au fost preluate de la lucrătorul de serviciu. Acesta este shell-ul nostru de aplicație.

Test offline

Un utilizator care rulează aplicația fără conexiune la internet (presupunând că a fost deja pe pagină) va avea ca rezultat pur și simplu afișarea shell-ului aplicației și avertismentul offline - o îmbunătățire față de t-rex-ul Chrome. Odată ce utilizatorul a stabilit o conexiune la rețea, dezactivăm avertismentul și recuperăm cele mai recente date.

The Guardian adoptă o abordare deosebit de interesantă atunci când utilizatorii offline accesează site-ul său web, oferind un puzzle de cuvinte încrucișate:

Notificări

Notificările push permit utilizatorilor să opteze pentru actualizări în timp util din aplicațiile în care au încredere, ajutându-i să se reinteractureze cu aplicațiile. Notificările push de pe web vă permit să interacționați cu publicul chiar și atunci când browserul este închis.

API-ul Push este acceptat în browserul Chrome, Opera și Samsung și este în curs de dezvoltare în Firefox și Microsoft Edge. Din păcate, nu există nicio indicație că funcția va fi implementată în Safari.

Performanţă

Unul dintre cele mai ușoare câștiguri cu lucrătorii din service este că putem îmbunătăți performanța cu puțin sau deloc efort. Comparând site-ul nostru web cu el însuși înainte ca lucrătorii de service să fie implementați, înainte de a prelua peste 200 KB la încărcarea paginii; care este acum redus la 13 KB. Într-o rețea 3G obișnuită, pagina ar fi durat 3,5 secunde să se încarce; acum durează 500 de milisecunde.

Aceste îmbunătățiri ale performanței sunt drastice deoarece aplicația în sine este foarte mică și are funcționalități limitate. Cu toate acestea, prin utilizarea corectă a stocării în cache, este posibilă îmbunătățirea semnificativă a performanței și a performanței percepute, în special pentru utilizatorii din locurile cu conectivitate scăzută.

Far

Echipa Google Chrome a creat un instrument pentru testarea aplicațiilor web progresive. Lighthouse rulează în Node.js sau ca plugin Chrome și poate fi găsit și pe GitHub.

Pentru a rula un test Lighthouse, site-ul dvs. trebuie să fie disponibil online, ceea ce înseamnă că nu puteți testa pe localhost .

Pentru a începe, descărcați pachetul npm:

 npm install -g GoogleChrome/lighthouse

După ce este instalat, rulați Chrome (versiunea 52 începând cu):

 npm explore -g lighthouse -- npm run chrome lighthouse https://incredibleweb.github.io/pwa-tutorial/

Ieșirea rulării Lighthouse va fi vizibilă în linia de comandă și va evalua site-ul dvs. în funcție de caracteristicile și proprietățile aplicației web progresive pe care le-ați implementat - de exemplu, dacă utilizați un fișier manifest.json sau dacă pagina dvs. este disponibilă offline .

Concluzie

Acest articol este doar un aperitiv pentru aplicațiile web progresive. Am putea face mult mai mult pentru a crea acea experiență asemănătoare aplicației pe care o caută utilizatorii, fie prin sprijinirea notificărilor push cu API-ul Push, făcând aplicația reactivabilă sau folosind IndexedDB și sincronizarea în fundal pentru a îmbunătăți experiența offline.

Asistență între browsere

Acestea sunt încă primele zile pentru aplicațiile web progresive, iar suportul între browsere este încă limitat, în special în Safari și Edge. Cu toate acestea, Microsoft acceptă în mod deschis aplicațiile web progresive și ar trebui să implementeze mai multe funcții până la sfârșitul anului.

• Lucrătorii de servicii și API-ul Cache . Acceptat în browserul Chrome, Firefox, Opera și Samsung. În dezvoltare în Microsoft Edge, se așteaptă să fie disponibil până la sfârșitul anului 2016. În curs de examinare pentru Safari.
• Adăugați pe ecranul de start . Acceptat în Chrome, Firefox, Opera, browserul Android și browserul Samsung. Microsoft pare să indice că aplicațiile web progresive vor fi disponibile ca listări în magazin. Încă nu există planuri pentru Safari.
• Push API . Acceptat în cea mai mare parte în browserul Chrome, Firefox, Opera și Samsung. În dezvoltare în Microsoft Edge. Încă nu există planuri pentru Safari.

Dacă mai mulți dezvoltatori profită de caracteristicile oferite de aplicațiile web progresive – care sunt relativ ușor de implementat și oferă recompense imediate – atunci utilizatorii vor prefera să consume aceste aplicații web în browsere acceptate, sperăm că îi va convinge pe ceilalți furnizori de browsere să se adapteze.

Cod sursa

Întregul cod sursă pentru acest tutorial este disponibil într-un depozit Github, iar demonstrația este disponibilă pe Paginile GitHub.