Elementele de bază ale aplicațiilor web progresive

Aplicațiile web pot înlocui simultan toate funcțiile aplicațiilor native și ale site-urilor web. Acestea ies din ce în ce mai mult în prim-plan în aceste zile, dar încă nu sunt suficienti oameni familiarizați cu ele sau care le adoptă.

În acest articol, veți putea găsi câteva lucruri de făcut și care nu sunt despre cum să creați o aplicație web progresivă, precum și resurse pentru cercetări ulterioare. Voi aborda, de asemenea, diferitele componente și probleme de asistență legate de aplicațiile web. Deși nu orice browser este prietenos cu ei, există încă câteva motive convingătoare pentru a afla mai multe despre această tehnologie.

Ce face ca o aplicație web să fie progresivă?

O aplicație web progresivă este un termen umbrelă pentru anumite tehnologii care merg împreună pentru a produce o experiență asemănătoare aplicației pe web. De dragul simplității, de acum înainte mă voi referi la ele pur și simplu ca aplicații web.

O aplicație web ideală este o pagină web care are cele mai bune aspecte atât ale aplicațiilor web, cât și ale aplicațiilor native. Ar trebui să interacționeze rapid și rapid cu acesta, să se potrivească în fereastra de vizualizare a dispozitivului, să rămână utilizabil offline și să poată avea o pictogramă pe ecranul de pornire.

În același timp, nu trebuie să sacrifice lucrurile care fac web-ul grozav, cum ar fi capacitatea de a conecta profund în aplicație și de a folosi adrese URL pentru a permite partajarea conținutului. La fel ca web, ar trebui să funcționeze bine pe toate platformele și să nu se concentreze doar pe mobil. Ar trebui să se comporte la fel de bine pe un computer desktop ca și în alți factori de formă, ca să nu riscăm să avem o altă eră a site-urilor web m.example.com care nu răspund.

Aplicațiile web progresive nu sunt noi. Browserele mobile au capacitatea de a marca un site web pe ecranul de pornire al telefonului din 2011 (2013 pe Chrome Android), cu metaetichete în head determinând aspectul paginii web instalate. Financial Times folosește o aplicație web pentru livrarea de conținut digital pe dispozitive mobile din 2012.

Trecerea la o aplicație web a permis Financial Times să folosească aceeași aplicație pentru a livra peste platforme într-un singur canal de distribuție. Pe vremea când lucram pentru Financial Times, cu o singură versiune am putut să sprijinim următoarele:

• iOS,
• Android (4.4+) Chrome,
• Android mai vechi (prin intermediul unui wrapper),
• Windows 8,
• Mure,
• Firefox OS.

Acest lucru realizează cu adevărat „construiți o dată, implementați oriunde”.

„Dar nu este într-un magazin de aplicații”

Există câteva motive bune pentru care completarea unei aplicații native cu un site web este încă o practică standard pentru majoritatea companiilor importante. Printre acestea se numără preocupările legate de suportul pentru browser și de faptul că majoritatea utilizatorilor sunt aclimatizați să folosească aplicații native. Voi aborda aceste probleme mai detaliat mai târziu. Nu în ultimul rând aceste preocupări este modul în care aplicația va fi expusă dacă nu este într-un magazin de aplicații.

Aș argumenta că a fi într-un magazin de aplicații nu are un avantaj major, deoarece s-a demonstrat că, dacă nu sunteți în primele 0,1% dintre aplicațiile din magazinul de aplicații, nu obțineți beneficii semnificative de a fi acolo.

Utilizatorii tind să găsească aplicațiile dvs. găsindu-vă mai întâi site-ul. Dacă site-ul dvs. este o aplicație web, atunci acestea sunt deja la destinație.

Unul dintre punctele forte ale unei aplicații web este că vă permite să îmbunătățiți implicarea prin reducerea numărului de clicuri necesare pentru a reangaja utilizatorul între aterizarea pe site-ul dvs. și interacțiunea cu aplicația dvs.

Prin solicitarea utilizatorului să „instaleze” aplicația dvs. web prin adăugarea acesteia pe ecranul de pornire, acesta poate continua să interacționeze cu site-ul dvs. Când închid browserul web, telefonul le va arăta unde este instalată aplicația web, readucându-vă la cunoștința lor.

Context și clima actuală

Aplicațiile web moderne se bazează pe o nouă tehnologie numită lucrători de servicii. Lucrătorii de servicii sunt proxy programabili care stau între fila utilizatorului și internetul mai larg. Ei interceptează și rescriu sau fabrică cereri de rețea pentru a permite stocarea în cache foarte granulară și suport offline.

De la originile aplicației web în 2011, care a permis ca site-urile web să fie marcate pe ecranul de pornire, au avut loc o serie de evoluții pentru a pune bazele pentru crearea de aplicații web progresive.

Chrome 38 a introdus manifestul aplicației web, care este un fișier JSON care descrie configurația aplicației dvs. web. Acest lucru ne-a permis să eliminăm configurația din head .

În Chrome 40 (decembrie 2014), lucrătorii de service au început să se lanseze pe Firefox și Chrome. Până acum, Apple a ales să nu implementeze această caracteristică în Safari în momentul scrierii, dar o are „în considerare”. Funcția lucrătorului de servicii este de a simplifica procesul de deconectare a unei aplicații; de asemenea, pune bazele viitoarelor funcții asemănătoare aplicațiilor, cum ar fi notificările push și sincronizarea în fundal.

Aplicațiile care au fost construite pe baza noilor lucrători de servicii și a manifestului aplicației web au devenit cunoscute ca aplicații web progresive.

O aplicație web progresivă nu este aceeași cu specificațiile. De fapt, a început ca o definiție a ceea ce ar trebui să fie o aplicație web în epoca lucrătorilor de servicii, având în vedere noua tehnologie încorporată în browsere. Mai exact, Chrome folosește această definiție pentru a declanșa o solicitare de instalare în browser atunci când sunt îndeplinite o serie de condiții. Condițiile sunt ca aplicația web:

• are un service worker (necesită HTTPS);
• are un fișier manifest al aplicației web (cu cel puțin configurație minimă și cu display: "standalone" );
• a avut două vizite distincte.

În acest caz, „progresiv” înseamnă că cu cât browserul acceptă mai multe funcții, cu atât experiența poate fi mai asemănătoare aplicației.

Solicitarea de instalare a aplicației web este afișată în prezent în diferite condiții în Opera, Chrome și browserul Samsung.

Apple și-a arătat interesul față de aplicațiile web progresive pentru iOS, dar la momentul scrierii, încă se bazează pe metaetichete pentru configurarea aplicației web și pe cache-ul aplicației (AppCache) pentru utilizarea offline.

În ce moment devine un site web o aplicație web?

Știm cum arată un site web și cum arată o aplicație, dar în ce moment devine un site web o aplicație web? Nu există o valoare definitivă cu privire la ceea ce face ceva mai degrabă o aplicație web decât un site web.

Aici vom intra în mai multe detalii despre caracteristicile unei aplicații web.

O aplicație web progresivă ar trebui să prezinte anumite proprietăți asemănătoare aplicației...

• Receptiv
  Umplend perfect ecranul, aceste site-uri web sunt destinate în primul rând telefoanelor și tabletelor și trebuie să răspundă la multitudinea de dimensiuni de ecran. De asemenea, ar trebui să funcționeze doar ca site-uri web desktop. Designul responsive a fost o parte importantă a construirii site-ului web de mulți ani. Smashing Magazine are câteva articole grozave despre el.
• Offline-în primul rând
  Aplicația trebuie să poată porni offline și să afișeze în continuare informații utile.
• Capabil tactil
  Interfața ar trebui să fie proiectată pentru atingere, cu interacțiune prin gesturi. Interacțiunea utilizatorului trebuie să fie receptivă și rapidă, fără întârziere între o atingere și un răspuns.
• Metadatele aplicației
  Aplicația ar trebui să furnizeze metadate pentru a spune browserului cum ar trebui să arate când este instalată, astfel încât să obțineți o pictogramă frumoasă de înaltă rezoluție pe ecranul de pornire și un ecran de introducere pe unele platforme.
• Notificări
  Aplicația poate primi notificări atunci când aplicația nu rulează (dacă este cazul).

… Dar ar trebui să mențină anumite proprietăți asemănătoare web-ului

• progresivă
  Capacitatea aplicației de a fi instalată este o îmbunătățire progresivă. Este vital ca aplicația să funcționeze în continuare ca un site web normal, în special pe platformele care nu acceptă încă instalarea sau lucrătorii de service.
• HTTPS pe web deschis
  Aplicația nu ar trebui să fie blocată în niciun browser sau magazin de aplicații. Ar trebui să poată fi conectat la adresa URL curentă și ar trebui să ofere metode de partajare.

Luarea site-ului dvs. offline

Luarea site-ului dvs. offline aduce câteva avantaje majore.

În primul rând, va funcționa în continuare atunci când utilizatorul se află într-o conexiune de rețea defectuoasă.

În plus, timpul de la deschiderea aplicației până la utilizarea aplicației este mult redus dacă aplicația nu se bazează pe rețea. Acest lucru oferă utilizatorului o experiență excelentă. O aplicație web atent optimizată poate porni mai repede decât una nativă dacă browserul a fost folosit recent.

Există două metode pentru a face ca un site web să funcționeze offline:

• Metodă veche și ruptă
  Suportul pentru pornirea site-ului dvs. offline există de ani de zile sub formă de AppCache. AppCache are totuși unele defecte serioase și chiar a fost depreciat din specificație. Este dificil de lucrat cu și, dacă este configurat greșit, îți poate distruge definitiv site-ul. Totuși, este singura modalitate de a face offline pe iOS, cel puțin până când Apple face o mișcare pentru a sprijini lucrătorii de service.
• Noua fierbinte
  De asemenea, eficienți sunt lucrătorii de servicii, care sunt acceptați în prezent în Chrome, Firefox și Opera și vor veni foarte curând pe Edge. Echipa Apple WebKit l-a marcat „în luare în considerare”.

Lucrătorii de servicii sunt ca alți lucrători web prin faptul că rulează într-un fir separat, dar nu sunt legați de nicio filă specifică. Li se atribuie un domeniu de adresă URL atunci când sunt creați și pot intercepta și rescrie orice solicitare din acest domeniu. Dacă lucrătorul dvs. de servicii se află la https://example.com/my-site/sw.js , acesta va putea intercepta orice solicitări făcute către /my-site/ sau mai jos, dar nu poate intercepta solicitările către rădăcina https://example.com/ .

Deoarece nu sunt legate de nicio filă, pot fi aduse la viață în fundal pentru a gestiona notificările push sau sincronizarea în fundal. Nu în ultimul rând, este imposibil să vă spargeți permanent site-ul web cu ei, deoarece se vor actualiza automat atunci când este detectat un nou script de service worker.

Un ghid bun este că, dacă construiți un nou site web de la zero, începeți cu un lucrător de service. Cu toate acestea, dacă site-ul dvs. web funcționează deja offline cu AppCache, atunci puteți utiliza instrumentul sw-appcache-behavior pentru a genera un lucrător de service din acest lucru, deoarece este posibil să ajungem în curând la punctul în care unele browsere vor accepta doar lucrători de service, iar altele vor accepta doar AppCache.

Deoarece AppCache este depreciat, nu voi discuta mai departe în acest articol.

Stabilirea unui lucrător de service

(De asemenea, consultați „Configurarea unui lucrător de service” pentru instrucțiuni mai detaliate.)

Deoarece un lucrător de servicii este un tip special de lucrător web partajat, rulează într-un fir separat către pagina principală. Aceasta înseamnă că este partajat de toate paginile web pe aceeași cale ca lucrătorul de service. De exemplu, un lucrător de servicii situat la /my-page/sw.js ar putea afecta /my-page/index.html și my-page/images/header.jpg , dar nu /index.html .

Lucrătorii de servicii sunt capabili să intercepteze și să rescrie sau să falsifice toate solicitările de rețea făcute pe pagină, inclusiv cele făcute către adrese URL data:// !

Această putere îi permite să furnizeze răspunsuri în cache pentru a face paginile să funcționeze atunci când nu există o conexiune de date. Cu toate acestea, este suficient de flexibil pentru a permite multe cazuri de utilizare posibile.

Este permis doar în contexte securizate (adică HTTPS) pentru că este atât de puternic. Acest lucru împiedică terții să anuleze permanent site-ul dvs. web folosind un lucrător de servicii injectat de la un punct de acces Wi-Fi infectat sau rău intenționat.

Configurarea HTTPS în zilele noastre ar putea părea descurajantă și costisitoare, dar de fapt nu a fost niciodată mai ușoară sau mai ieftină. Let's Encrypt oferă certificate SSL și scripturi gratuite pentru a vă configura automat serverul. În cazul în care găzduiți pe GitHub, Paginile GitHub sunt difuzate automat prin HTTPS. Paginile Tumblr pot fi configurate să ruleze și pe HTTPS. CloudFlare poate trimite solicitări de upgrade la HTTPS.

Deconectarea implică, de obicei, alegerea anumitor metode de stocare în cache pentru diferite părți ale site-ului dvs., pentru a le permite să fie servite mai rapid sau atunci când nu există conexiune la internet. Voi discuta mai jos despre diferite metode de stocare în cache.

Folosesc Service Worker Toolbox pentru a abstrage logica de stocare în cache complexă. Această bibliotecă poate fi setată să gestioneze rutarea furnizând patru rute preconfigurate, care pot fi configurate într-un mod curat. Poate fi importat în lucrătorul dumneavoastră de service.

Cazul de utilizare 1: Precaching

Precaching-ul trage în jos solicitările înainte ca site-ul dvs. să descopere că sunt necesare. Acest lucru poate reduce foarte mult timpul pentru prima vopsire, deoarece site-ul dvs. nu trebuie să analizeze /site.css înainte de a începe descărcarea sigla site-ului dvs., /images/logo.png .

 toolbox.precache(['/index.html', '/site.css', '/images/logo.png']);

Cazul de utilizare 2: Offline

Permiterea utilizatorilor să revină site-ul dvs. atunci când sunt offline în cel mai simplu caz înseamnă să reveniți la cache dacă dispozitivul este offline. Setarea unui timeout aici este importantă, deoarece o rețea defectuoasă, un router configurat greșit sau un portal captiv ar putea lăsa utilizatorul să aștepte la nesfârșit.

 toolbox.router.default = toolbox.networkFirst; toolbox.options.networkTimeoutSeconds = 5;

În realitate, putem fi de fapt puțin mai deștepți, deoarece majoritatea activelor tale nu se vor schimba în timp. Probabil că vrem doar să obținem conținutul cât mai curând posibil, fie din cache, fie din rețea. Următoarea linie spune Service Worker Toolbox că ​​toate solicitările către căile imaginilor ar trebui să provină din cache dacă sunt disponibile acolo.

 toolbox.router.all('/images/*', toolbox.fastest);

În acest caz, când utilizatorul se autentifică, este important să nu returnăm doar un răspuns în cache; ar trebui să menționăm că solicitările făcute către /auth/ ar trebui să fie numai pentru rețea.

 toolbox.router.post('/auth/*', toolbox.networkOnly);

Iată câteva bune practici pentru offline:

• Elementele statice inițiale ar trebui să fie precacheate. Acest lucru le descarcă și le memorează în cache atunci când lucrătorul de service este instalat. Aceasta înseamnă că nu trebuie să fie încărcate de pe server atunci când sunt necesare în cele din urmă.
• În mod implicit, solicitările ar trebui, în mod ideal, să fie proaspăt provenite din rețea, dar să revină în cache, astfel încât să fie disponibile offline.
• Un timeout de rețea relativ scurt înseamnă că cererile vor putea returna date stocate în cache pe o conexiune de rețea care spune că are o conexiune de date, dar nu se returnează niciun răspuns.
• Activele actualizate rar, cum ar fi imaginile, ar trebui să fie trimise mai întâi din cache, apoi browserul ar încerca, de asemenea, să le actualizeze. Dacă toolbox.cacheOnly este folosit, atunci ar putea salva și datele utilizatorului.

Notă: cache-ul browserului și API-ul Cache sunt animale diferite. API-ul Cache a fost ocolit în cazul rețelei în primul rând sau numai în rețea. Solicitarea poate ajunge în continuare în memoria cache a browserului, deoarece antetele de stocare în cache din cerere spun că este încă validă. Acest lucru ar putea duce la problema ca utilizatorul să primească un amestec de date din cache și date proaspete. Jake Archibald are câteva sugestii bune pentru a evita această problemă.

Depanarea lucrătorului de servicii

Dacă sunteți în Chrome sau Opera, accesați chrome://serviceworker-internals . Acest lucru vă va permite să inspectați și să întrerupeți și să dezinstalați scriptul de service worker.

În versiunile recente de Chrome și Opera, puteți obține vizualizări detaliate și instrumente de depanare prin fila „Aplicație” din inspector.

Interacțiune și performanță de animație

Oamenii au ajuns să se aștepte ca web-ul să nu aibă interfețele animate fără probleme pe care le au aplicațiile native. Cu toate acestea, același standard nu este acceptabil pentru aplicațiile web. Aplicațiile web trebuie să se anime fără probleme, pentru ca utilizatorii noștri să nu simtă că oferim o experiență degradată, de clasa a doua. Avem trei obiective pentru a face să se simtă rapid:

• Când utilizatorul face ceva, aplicația trebuie, de asemenea, să facă ceva în 100 de milisecunde; în caz contrar, utilizatorul va observa o întârziere. Acest lucru contează pentru atingeri, clicuri, glisări și derulări.
• Fiecare cadru trebuie să fie randat la o consecvență de 60 de cadre pe secundă (16 milisecunde pe cadru). Chiar și câteva cadre lente vor fi evidente.
• Trebuie să fie rapid pe un telefon cu buget vechi de trei ani care rulează pe o rețea slabă, nu numai pe mașina dvs. strălucitoare de dezvoltare.
• Trebuie să înceapă repede. De mult ne-am concentrat pe menținerea angajamentului utilizatorilor, făcând ca site-urile noastre web să fie vizibile și utilizabile în mai puțin de 1 până la 2 secunde. Când vine vorba de aplicații web, timpul de pornire este la fel de important ca întotdeauna. Dacă tot conținutul unei aplicații este stocat în cache și browserul este încă în memoria dispozitivului, o aplicație web poate porni mai repede decât o aplicație nativă. O greșeală făcută de dezvoltatorii nativi de aplicații și site-uri web deopotrivă este necesitatea de conținut în rețea pentru ca produsul să funcționeze.
• Aplicația web trebuie să fie mică pentru descărcare și actualizare: 10 MB dintr-un magazin de aplicații nu se simt prea mult, dar 10 MB necacheți descărcați de fiecare dată sunt foarte imposibil de gestionat pentru mulți utilizatori de telefonie mobilă.

Din start, cel mai esențial element este acesta, în head documentului:

 <meta name="viewport" content="width=device-width">

Această linie asigură că nu există o întârziere de atingere de 300 de milisecunde pe browserele de telefon care sunt bazate pe Chromium sau Firefox, dar permite totuși utilizatorului să mărească prin ciupire (excelent pentru accesibilitate).

De când a apărut iOS 8, clicurile sunt rapide în mod implicit, dar pot părea lente dacă atingerea este rapidă, conform anumitor euristici. Dacă aceasta este o problemă pentru dvs., vă recomand să utilizați FastClick pentru a elimina întârzierea.

Există și problema performanței animației. Probabil că veți dori o mulțime de elemente drăguțe animate înăuntru și în afară, elemente care pot fi trase de utilizator și alte interacțiuni minunate.

Performanța web poate fi discutată în detaliu și este un subiect care îmi ține inima, dar nu voi intra în multe detalii aici. Voi atinge ceea ce fac pentru a mă asigura că interacțiunile și animațiile mele sunt clare și fluide.

Caută sau cere prietenilor sau familiei un smartphone vechi. De obicei, împrumut Nexus 4 al partenerului meu.

Conectați telefonul la computer și accesați chrome://inspect/#devices . Aceasta va deschide o fereastră de inspecție, pe care o puteți utiliza pentru a inspecta paginile web care rulează pe telefon. Puteți utiliza profilarea și vizualiza cronologia pentru a găsi surse de performanță slabă și apoi să le optimizați pe baza unui dispozitiv de referință real.

Animarea anumitor proprietăți CSS este una dintre cele mai mari cauze ale animației nervoase, cunoscută sub numele de jank. Declanșatoarele CSS sunt o resursă excelentă pentru a determina ce proprietăți pot fi animate în siguranță, fără a determina browserul să picteze sau să reașeze întreaga pagină.

Dacă scrierea de animații performante este o sarcină descurajantă pentru tine, multe biblioteci de acolo se vor ocupa de treaba. Unul de-al meu favorit este GreenSock, care poate gestiona foarte bine interacțiunile tactile, cum ar fi tragerea de elemente, și care poate face animații și interpolari foarte fanteziste.

Notificări

Notificările push sunt o modalitate excelentă de a re-interacționa cu utilizatorii. Solicitați utilizatorului, vă aduceți aplicația în prim-planul minții sale. Aceștia ar putea finaliza o tranzacție neterminată sau pot primi alerte despre conținut nou relevant.

Asigurați-vă că notificările dvs. push sunt relevante pentru utilizator pentru evenimentele care au loc în acel moment. Nu-și pierde timpul cu lucruri care pot fi făcute mai târziu. Ceea ce îi notificați ar trebui să necesite acțiunea lor (răspunsul cuiva sau mergerea la un eveniment). De asemenea, nu împingeți o notificare dacă aplicația dvs. web este vizibilă sau focalizată.

Când interacționați cu, o notificare ar trebui să conducă utilizatorul la o pagină care funcționează offline. Notificările pot rămâne necitite; acestea pot fi interacționate atunci când utilizatorul nu are conexiune la rețea. Utilizatorul va fi frustrat dacă notificarea dvs. push refuză să funcționeze după ce a încercat să interacționeze cu ea.

Cea mai bună experiență pentru notificările push eliberează utilizatorul de a fi nevoit să deschidă aplicația web ! „Ai un mesaj nou” este inutil și la fel de enervant ca un titlu clickbait. Afișează mesajul și expeditorul.

Butoanele de acțiune din notificare pot oferi solicitări de interacțiune care nu deschid neapărat browserul („Apreciați această postare”, „Răspunde cu da”, „Răspunde cu nu”, „Amintește-mi mai târziu”). Acestea servesc utilizatorul în condițiile lor, îl mențin implicat și minimizează investiția lor de timp.

Dacă trimiteți spam utilizatorului cu notificări obișnuite sau irelevante, acesta ar putea dezactiva notificările pentru aplicația dvs. în browser. După aceea, va fi aproape imposibil să le reangajați și nu le veți putea solicita cu ușurință din nou permisiunea!

Pentru a evita acest lucru, faceți drumul către butonul „dezactivați notificarea” al aplicației dvs. clar și ușor. Odată ce ați rezolvat orice problemă care frustrează utilizatorii, puteți încerca să vă reangajați.

API-ul Push Notification necesită un lucrător de service. Deoarece este posibil să primiți notificări push atunci când nu este deschisă nicio filă de browser, lucrătorul de service va gestiona cererea de notificare într-un fir de fundal. Poate efectua operațiuni asincrone, cum ar fi efectuarea unei cereri de preluare către API-ul dvs. înainte de a afișa notificarea către utilizator.

Pentru a crea o notificare push, faceți o solicitare către un punct final furnizat de producătorul browserului. Pentru browserele bazate pe Chromium (Opera, Samsung și Chrome), aceasta ar fi Firebase Cloud Messaging. Aceste browsere se comportă, de asemenea, puțin în afara specificațiilor.

Puteți găsi detalii despre acest lucru solicitând permisiunea de notificare push:

 serviceWorkerRegistration .pushManager .subscribe({ // Required parameter as receiving updates // but not displaying a message is not supported everywhere. userVisibleOnly: true }) .then(function(subscription) { return sendSubscriptionToServer(subscription); })

Abonamentul este un obiect care arată astfel:

 { "endpoint": "https://example.com/some/uuid" }

În exemplul de mai sus, uuid -ul identifică în mod unic browserul utilizat în prezent.

Notă: browserele bazate pe Chromium se comportă puțin diferit. Veți avea nevoie de un ID de aplicație Firebase, care trebuie introdus în fișierul manifest al aplicației dvs. web (de exemplu, "gcm_sender_id": "90157766285" ).

De asemenea, punctul final nu va funcționa în formatul dat. Serverul dvs. trebuie să-l deranjeze ușor pentru a-l face să funcționeze. Trebuie să fie o solicitare POST , cu cheia API în head și uuid în body .

Când trimiteți o notificare push, este posibil să trimiteți date în corpul notificării push în sine. Acest lucru este complex și implică criptarea conținutului din cererea API. Pachetul web-push pentru Node.js poate gestiona acest lucru, dar nu îl prefer.

Este posibil să se efectueze solicitări asincrone odată ce notificarea a fost primită, așa că prefer să trimit clientului o notificare minimă, cunoscută sub numele de „gâdilă”, iar apoi lucrătorul de service va face o solicitare de preluare către API-ul meu pentru a extrage orice actualizări recente.

Notă: lucrătorul de service poate fi închis de browser în orice moment. Funcția event.waitUntil din evenimentul push îi spune lucrătorului de service să nu se închidă până când evenimentul este terminat.

 self.addEventListener('push', function(event) { event.waitUntil( // Makes API request, returns Promise getMessageDetails() .then(function (details) { self.registration.showNotification( details.title, { body: details.message, icon: '/my-app-logo-192x192.png' }) }) ); });

Puteți asculta un clic sau apăsați interacțiunea cu privire la evenimentele de notificare, de asemenea. Folosiți-le pentru a decide cum să răspundeți. Puteți deschide o nouă filă de browser, puteți concentra o filă existentă sau puteți face o solicitare API. De asemenea, puteți alege dacă să închideți notificarea sau să o mențineți deschisă. Utilizați această funcționalitate cu acțiuni asupra notificării pentru a construi o funcționalitate excelentă în notificarea în sine. Acest lucru va oferi o experiență grozavă, deoarece utilizatorului nu i se va cere să deschidă aplicația de fiecare dată.

Nu ignora punctele forte ale web-ului

Ultimul și cel mai important punct este că, în graba noastră pentru o experiență asemănătoare aplicației, nu ar trebui să uităm să rămânem ca pe web într-un aspect foarte important: URL-urile.

Aplicațiile web instalate ascund adesea shell-ul browserului. Nu există o bară de adrese pentru ca utilizatorul să partajeze adresa URL curentă și utilizatorul nu poate salva pagina curentă pentru mai târziu.

Adresele URL au un avantaj web unic: puteți determina oamenii să vă folosească aplicația făcând clic, mai degrabă decât descriind cum să o navigheze. Cu toate acestea, este foarte ușor să uitați să expuneți acest lucru utilizatorilor. Ai putea scrie cea mai bună aplicație din lume, dar dacă nimeni nu o poate distribui, ți-ai fi făcut un deserviciu major.

Se reduce la aceasta: oferiți modalități de a vă partaja aplicația fie prin butoane de partajare, fie prin intermediul unui buton pentru a expune adresa URL.

Dar browserele care nu acceptă aplicații web progresive?

Verificați Este ServiceWorker gata? pentru starea actuală de asistență pentru lucrătorii de servicii în toate browserele.

Poate că ați observat în toate acestea că am menționat Chrome, Firefox și Edge, dar am omis Safari. Apple a introdus aplicații web în lume și și-a manifestat interes pentru aplicațiile web progresive, dar încă nu acceptă lucrătorii de servicii sau manifestul aplicației web. Ce poti face?

Este posibil să creați un site web offline pentru Safari cu AppCache, dar acest lucru este atât dificil, cât și plin de cazuri de margine ciudate care pot sparge pagina sau o pot menține permanent neactualizată după prima încărcare.

În schimb, creați o experiență excelentă a aplicației web. Munca dvs. nu va fi irosită, deoarece experiența va fi în continuare grozavă în Safari, care este un browser foarte bun. Când lucrătorii de service vin la Safari, veți fi gata să profitați de ei.

În cele din urmă, putem aștepta cu nerăbdare o mulțime de dezvoltări interesante în lumea aplicațiilor web, cu suport din ce în ce mai mare pentru tehnologiile din spatele lor și noi funcții care vin pe platforma web, cum ar fi API-ul Web Bluetooth pentru interacțiunea cu hardware-ul, WebVR pentru virtual realitate și WebGL 2 pentru jocuri de mare viteză. Acum este un moment excelent pentru a explora posibilitățile aplicațiilor web și pentru a lua parte la modelarea viitorului web.

Legături

Alte scriere pe aplicații web progresive

• „Încă un blog despre starea și viitorul aplicației web progresive”, Ada Rose Edwards

Link-uri la care se face referire în articolul

• „Forma App Store”, Charles Perry
• Service Worker Helpers, Google, GitHub
• Service Worker Toolbox, Google, GitHub
• „Întârzierea clicului de 300 de milisecunde și iOS 8”, TJ VanToll
• „Cele mai bune practici de stocare în cache și probleme de vârstă maximă”, Jake Archibald