Bloki konstrukcyjne progresywnych aplikacji internetowych

Aplikacje internetowe mogą jednocześnie zastąpić wszystkie funkcje aplikacji natywnych i witryn internetowych. W dzisiejszych czasach coraz bardziej wysuwają się na pierwszy plan, ale wciąż zbyt mało osób je zna lub je adoptuje.

W tym artykule dowiesz się, co robić, a czego nie, jak tworzyć progresywną aplikację internetową, a także znaleźć zasoby do dalszych badań. Zajmę się również różnymi składnikami i rozwiązywaniem problemów związanych z aplikacjami internetowymi. Chociaż nie każda przeglądarka jest dla nich przyjazna, wciąż istnieją ważne powody, aby dowiedzieć się więcej o tej technologii.

Co sprawia, że ​​aplikacja internetowa jest progresywna?

Progresywna aplikacja internetowa to ogólny termin określający pewne technologie, które łączą się, aby stworzyć w sieci wrażenia podobne do aplikacji. Dla uproszczenia będę odtąd nazywał je po prostu aplikacjami internetowymi.

Idealna aplikacja internetowa to strona internetowa, która ma najlepsze cechy zarówno aplikacji internetowych, jak i natywnych. Powinien być szybki i szybki w obsłudze, pasować do widoku urządzenia, pozostawać użyteczny w trybie offline i mieć ikonę na ekranie głównym.

Jednocześnie nie może poświęcać rzeczy, które sprawiają, że sieć jest świetna, takich jak możliwość łączenia się w głąb aplikacji i używania adresów URL do udostępniania treści. Podobnie jak sieć, powinna działać dobrze na różnych platformach i nie skupiać się wyłącznie na urządzeniach mobilnych. Powinien zachowywać się równie dobrze na komputerze stacjonarnym, jak w innych formach, aby nie ryzykować kolejnej ery nieodpowiadających witryn m.example.com.

Progresywne aplikacje internetowe nie są niczym nowym. Przeglądarki mobilne mają możliwość tworzenia zakładek na ekranie głównym telefonu od 2011 roku (2013 na Chrome Android), z metatagami w head określającymi wygląd zainstalowanej strony internetowej. Financial Times korzysta z aplikacji internetowej do dostarczania treści cyfrowych na urządzenia mobilne od 2012 roku.

Przejście na aplikację internetową umożliwiło Financial Times używanie tej samej aplikacji do wysyłania na różne platformy w jednym kanale dystrybucji. Kiedy pracowałem dla Financial Times, w jednej wersji byliśmy w stanie obsłużyć następujące elementy:

• iOS,
• Android (4.4+) Chrome,
• starszy Android (przez wrapper),
• Windows 8,
• Jeżyna,
• Firefox OS.

To naprawdę osiąga „buduj raz, wdrażaj w dowolnym miejscu”.

„Ale to nie jest w App Store”

Istnieje kilka dobrych powodów, dla których uzupełnianie natywnej aplikacji o stronę internetową jest nadal standardową praktyką dla większości dużych firm. Wśród nich są obawy dotyczące obsługi przeglądarek oraz fakt, że większość użytkowników jest przyzwyczajona do korzystania z aplikacji natywnych. Omówię te kwestie bardziej szczegółowo później. Nie mniej ważne jest to, w jaki sposób aplikacja będzie widoczna, jeśli nie znajduje się w sklepie z aplikacjami.

Twierdzę, że przebywanie w sklepie z aplikacjami nie ma żadnej większej przewagi, ponieważ wykazano, że jeśli nie znajdujesz się wśród 0,1% najlepszych aplikacji w sklepie z aplikacjami, nie odnosisz znaczących korzyści z przebywania tam.

Użytkownicy zwykle znajdują Twoje aplikacje, najpierw znajdując Twoją witrynę. Jeśli Twoja witryna jest aplikacją internetową, są już w miejscu docelowym.

Jedną z mocnych stron aplikacji internetowej jest to, że umożliwia ona zwiększenie zaangażowania poprzez zmniejszenie liczby kliknięć wymaganych do ponownego zaangażowania użytkownika między wejściem na Twoją witrynę a interakcją z Twoją aplikacją.

Dzięki temu, że użytkownik „zainstalował” Twoją aplikację internetową, dodając ją do swojego ekranu głównego, może kontynuować interakcję z Twoją witryną. Gdy zamkną przeglądarkę internetową, telefon pokaże im, gdzie jest zainstalowana aplikacja internetowa, przywracając ich świadomość.

Tło i aktualny klimat

Nowoczesne aplikacje internetowe opierają się na nowej technologii zwanej Service Worker. Serviceworkers to programowalne serwery proxy, które znajdują się między zakładką użytkownika a szeroko rozumianym Internetem. Przechwytują i przepisują lub wytwarzają żądania sieciowe, aby umożliwić bardzo szczegółowe buforowanie i obsługę offline.

Od początków aplikacji internetowej w 2011 roku, która umożliwiała dodawanie stron internetowych do zakładek na ekranie głównym, dokonano wielu zmian, aby stworzyć więcej podstaw do tworzenia progresywnych aplikacji internetowych.

Chrome 38 wprowadził manifest aplikacji internetowej, który jest plikiem JSON opisującym konfigurację Twojej aplikacji internetowej. To pozwoliło nam usunąć konfigurację z head .

W przeglądarce Chrome 40 (grudzień 2014 r.) pracownicy usług zaczęli wdrażać się w przeglądarkach Firefox i Chrome. Apple do tej pory zdecydowało się nie wdrażać tej funkcji w Safari w momencie pisania tego tekstu, ale „rozważa”. Funkcją pracownika serwisu jest uproszczenie procesu przełączania aplikacji w tryb offline; kładzie również podwaliny pod przyszłe funkcje podobne do aplikacji, takie jak powiadomienia push i synchronizacja w tle.

Aplikacje, które zostały zbudowane w oparciu o nowe procesy robocze i manifest aplikacji sieci Web, stały się znane jako progresywne aplikacje sieci Web.

Progresywna aplikacja internetowa to nie to samo, co specyfikacja. W rzeczywistości zaczęło się od definicji tego, czym powinna być aplikacja internetowa w erze pracowników usług, biorąc pod uwagę nową technologię wbudowaną w przeglądarki. W szczególności Chrome używa tej definicji, aby wyświetlić monit o instalację w przeglądarce, gdy zostanie spełniony szereg warunków. Warunki są takie, że aplikacja internetowa:

• ma pracownika serwisu (wymaga HTTPS);
• posiada plik manifestu aplikacji webowej (z minimalną konfiguracją i display: "standalone" );
• odbył dwie różne wizyty.

W tym przypadku „progresywny” oznacza, że ​​im więcej funkcji obsługuje przeglądarka, tym bardziej przypomina ona działanie aplikacji.

Monit o zainstalowanie aplikacji internetowej jest obecnie wyświetlany w różnych warunkach w przeglądarce Opera, Chrome i Samsung.

Apple wykazał zainteresowanie progresywnymi aplikacjami internetowymi na iOS, ale w chwili pisania tego tekstu nadal opiera się na metatagach do konfiguracji aplikacji internetowych i pamięci podręcznej aplikacji (AppCache) do użytku w trybie offline.

W którym momencie strona internetowa staje się aplikacją internetową?

Wiemy, jak wygląda strona internetowa i jak wygląda aplikacja, ale w którym momencie strona internetowa staje się aplikacją internetową? Nie ma ostatecznego wskaźnika określającego, co sprawia, że ​​coś jest aplikacją internetową, a nie witryną internetową.

Tutaj omówimy bardziej szczegółowo cechy aplikacji internetowej.

Progresywna aplikacja internetowa powinna wykazywać pewne właściwości podobne do aplikacji…

• Czuły
  Idealnie wypełniające ekran strony te są przeznaczone przede wszystkim na telefony i tablety i muszą odpowiadać mnogości rozmiarów ekranu. Powinny również działać jako strony internetowe na komputery stacjonarne. Responsywne projektowanie jest głównym elementem tworzenia stron internetowych od wielu lat. Smashing Magazine ma na ten temat kilka świetnych artykułów.
• Najpierw offline
  Aplikacja musi być w stanie uruchomić się w trybie offline i nadal wyświetlać przydatne informacje.
• Obsługa dotykowa
  Interfejs powinien być zaprojektowany do dotyku, z interakcją gestami. Interakcja użytkownika musi być responsywna i szybka, bez opóźnień między dotykiem a reakcją.
• Metadane aplikacji
  Aplikacja powinna dostarczać metadane, aby poinformować przeglądarkę, jak powinna wyglądać po zainstalowaniu, aby uzyskać ładną ikonę o wysokiej rozdzielczości na ekranie głównym i ekran powitalny na niektórych platformach.
• Powiadomienia push
  Aplikacja może otrzymywać powiadomienia, gdy aplikacja nie jest uruchomiona (jeśli dotyczy).

… Ale powinien zachowywać pewne właściwości internetowe

• Progresywny
  Możliwość zainstalowania aplikacji jest stopniowym ulepszeniem. Bardzo ważne jest, aby aplikacja nadal działała jak normalna strona internetowa, zwłaszcza na platformach, które nie obsługują jeszcze instalacji ani pracowników serwisowych.
• HTTPS w otwartej sieci
  Aplikacja nie powinna być zablokowana w żadnej przeglądarce ani sklepie z aplikacjami. Powinien być w stanie zawierać głębokie linki i powinien zapewniać metody udostępniania bieżącego adresu URL.

Przełączanie witryny w tryb offline

Przełączenie witryny w tryb offline niesie ze sobą kilka istotnych korzyści.

Po pierwsze, będzie nadal działać, gdy użytkownik ma niestabilne połączenie sieciowe.

Ponadto czas od otwarcia aplikacji do korzystania z aplikacji jest znacznie skrócony, jeśli aplikacja nie jest zależna od sieci. Daje to użytkownikowi wspaniałe wrażenia. Starannie zoptymalizowana aplikacja internetowa może uruchomić się szybciej niż natywna, jeśli przeglądarka była ostatnio używana.

Istnieją dwa sposoby na uruchomienie witryny w trybie offline:

• Stara i zepsuta metoda
  Wsparcie dla uruchamiania witryny w trybie offline istnieje od lat w postaci AppCache. AppCache ma jednak kilka poważnych wad, a nawet został wycofany ze specyfikacji. Jest to trudne w obsłudze, a jeśli jest źle skonfigurowane, może trwale uszkodzić Twoją witrynę. Mimo to jest to jedyny sposób na robienie offline na iOS, przynajmniej do czasu, gdy Apple zrobi krok w kierunku wsparcia pracowników serwisu.
• Nowa ostrość
  Skuteczni są również pracownicy usług, którzy są obecnie obsługiwani w przeglądarkach Chrome, Firefox i Opera, a wkrótce pojawią się w Edge. Zespół WebKit firmy Apple oznaczył go jako „rozważany”.

Service Workery są podobne do innych pracowników sieci Web, ponieważ działają w osobnym wątku, ale nie są powiązane z żadną konkretną kartą. Podczas tworzenia są im przypisywany zakres adresu URL i mogą przechwytywać i ponownie zapisywać dowolne żądania w tym zakresie. Jeśli Twój Service Worker znajduje się pod https://example.com/my-site/sw.js , będzie mógł przechwycić wszystkie żądania kierowane do /my-site/ lub niższego, ale nie może przechwycić żądań do głównego https://example.com/ .

Ponieważ nie są powiązane z żadną kartą, można je ożywić w tle, aby obsługiwać powiadomienia push lub synchronizację w tle. Co więcej, niemożliwe jest trwałe zerwanie z nimi Twojej witryny, ponieważ zaktualizują się one automatycznie po wykryciu nowego skryptu Service Worker.

Dobrą wskazówką jest to, że jeśli budujesz nową stronę internetową od podstaw, zacznij od pracownika serwisu. Jeśli jednak Twoja strona internetowa działa już offline z AppCache, możesz użyć narzędzia sw-appcache-behaviour, aby wygenerować z tego service workera, ponieważ możemy wkrótce dojść do punktu, w którym niektóre przeglądarki zaakceptują tylko service workery, a inne tylko zaakceptują Pamięć podręczna aplikacji.

Ponieważ AppCache jest przestarzały, nie będę go dalej omawiać w tym artykule.

Konfigurowanie pracownika serwisu

(Ponadto, zobacz „Konfigurowanie Service Worker”, aby uzyskać bardziej szczegółowe instrukcje).

Ponieważ Service Worker jest specjalnym typem współdzielonego webworkera, działa on w osobnym wątku do strony głównej. Oznacza to, że jest on współdzielony przez wszystkie strony internetowe na tej samej ścieżce, co Service Worker. Na przykład pracownik serwisu znajdujący się w /my-page/sw.js może mieć wpływ na /my-page/index.html i my-page/images/header.jpg , ale nie /index.html .

Pracownicy usług są w stanie przechwycić i przepisać lub sfałszować wszystkie żądania sieciowe wykonane na stronie, w tym te skierowane do adresów URL data:// !

Ta moc umożliwia dostarczanie odpowiedzi w pamięci podręcznej, aby strony działały, gdy nie ma połączenia danych. Mimo to jest wystarczająco elastyczny, aby umożliwić wiele możliwych przypadków użycia.

Jest to dozwolone tylko w bezpiecznych kontekstach (tj. HTTPS), ponieważ jest tak potężny. Uniemożliwia to stronom trzecim trwałe nadpisanie Twojej witryny za pomocą wstrzykniętego pracownika usługi z zainfekowanego lub złośliwego punktu dostępu Wi-Fi.

Konfiguracja HTTPS w dzisiejszych czasach może wydawać się zniechęcająca i kosztowna, ale w rzeczywistości nigdy nie była łatwiejsza ani tańsza. Let's Encrypt zapewnia bezpłatne certyfikaty SSL i skrypty do automatycznej konfiguracji serwera. Jeśli hostujesz na GitHub, strony GitHub są automatycznie obsługiwane przez HTTPS. Strony Tumblr można również skonfigurować tak, aby działały w protokole HTTPS. CloudFlare może proxy żądać uaktualnienia do HTTPS.

Offline zazwyczaj polega na wybraniu pewnych metod buforowania dla różnych części witryny, aby umożliwić ich szybsze serwowanie lub gdy nie ma połączenia z Internetem. Poniżej omówię różne metody buforowania.

Używam Service Worker Toolbox do abstrahowania złożonej logiki buforowania. Tę bibliotekę można ustawić do obsługi routingu, udostępniając cztery wstępnie skonfigurowane trasy, które można skonfigurować w czysty sposób. Można go zaimportować do pracownika serwisu.

Przypadek użycia 1: Wstępne buforowanie

Precaching ściąga żądania, zanim witryna zorientuje się, że są one potrzebne. Może to znacznie skrócić czas pierwszego malowania, ponieważ Twoja witryna nie musi analizować /site.css przed rozpoczęciem pobierania logo witryny, /images/logo.png .

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

Przypadek użycia 2: Offline

W najprostszym przypadku umożliwienie użytkownikom ponownego odwiedzenia witryny w trybie offline oznacza powrót do pamięci podręcznej, jeśli urządzenie jest w trybie offline. Ustawienie tutaj limitu czasu jest ważne, ponieważ niestabilna sieć, źle skonfigurowany router lub portal przechwytujący mogą sprawić, że użytkownik będzie czekał w nieskończoność.

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

W rzeczywistości możemy być trochę mądrzejsi, ponieważ większość Twoich zasobów nie zmieni się w czasie. Prawdopodobnie chcemy po prostu pobrać zawartość tak szybko, jak to możliwe, czy to z pamięci podręcznej, czy z sieci. Poniższy wiersz informuje Service Worker Toolbox, że wszystkie żądania do ścieżek obrazów powinny pochodzić z pamięci podręcznej, jeśli są tam dostępne.

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

W tym przypadku, gdy użytkownik uwierzytelnia się, ważne jest, abyśmy nie zwracali tylko odpowiedzi z pamięci podręcznej; powinniśmy stwierdzić, że żądania kierowane do /auth/ powinny dotyczyć tylko sieci.

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

Oto kilka dobrych praktyk dotyczących trybu offline:

• Początkowe zasoby statyczne należy wstępnie umieścić w pamięci podręcznej. Spowoduje to ich pobranie i zapisanie ich w pamięci podręcznej, gdy jest zainstalowany Service Worker. Oznacza to, że nie trzeba ich ładować z serwera, gdy są ostatecznie potrzebne.
• Domyślnie żądania powinny być świeżo pozyskiwane z sieci, ale wracać do pamięci podręcznej, aby były dostępne w trybie offline.
• Stosunkowo krótki limit czasu sieci oznacza, że ​​żądania będą mogły zwracać dane z pamięci podręcznej w połączeniu sieciowym, które mówi, że ma połączenie danych, ale nie są zwracane żadne odpowiedzi.
• Rzadko aktualizowane zasoby, takie jak obrazy, należy najpierw wysłać z pamięci podręcznej, a następnie przeglądarka również spróbuje je zaktualizować. Jeśli używany jest toolbox.cacheOnly , może również zapisywać dane użytkownika.

Uwaga: pamięć podręczna przeglądarki i interfejs API pamięci podręcznej to różne zwierzęta. Interfejs API pamięci podręcznej został pominięty w przypadku sieci najpierw lub tylko sieci. Żądanie może nadal trafić do pamięci podręcznej przeglądarki, ponieważ nagłówki pamięci podręcznej w żądaniu mówią, że nadal jest prawidłowe. Może to spowodować problem, że użytkownik otrzyma mieszankę danych z pamięci podręcznej i świeżych. Jake Archibald ma kilka dobrych wskazówek, jak uniknąć tego problemu.

Debugowanie pracownika usługi

Jeśli korzystasz z przeglądarki Chrome lub Opera, przejdź do chrome://serviceworker-internals . Umożliwi to sprawdzenie, wstrzymanie i odinstalowanie skryptu Service Worker.

W najnowszych wersjach Chrome i Opery możesz uzyskać szczegółowe widoki i narzędzia do debugowania za pomocą zakładki „Aplikacja” w inspektorze.

Interakcja i wydajność animacji

Ludzie zaczęli oczekiwać, że w sieci nie ma płynnie animowanych interfejsów, które mają aplikacje natywne. Jednak ten sam standard nie jest akceptowalny w przypadku aplikacji internetowych. Aplikacje internetowe muszą płynnie animować, aby nasi użytkownicy nie czuli, że dostarczamy zdegradowane, drugorzędne wrażenia. Mamy trzy cele, aby było szybko :

• Kiedy użytkownik coś robi, aplikacja musi również zrobić coś w ciągu 100 milisekund; w przeciwnym razie użytkownik zauważy opóźnienie. Liczy się to za dotknięcia, kliknięcia, przeciągnięcia i przewijanie.
• Każda klatka musi być renderowana w stałych 60 klatkach na sekundę (16 milisekund na klatkę). Nawet kilka wolnych klatek będzie oczywistych.
• Musi być szybki na trzyletnim telefonie z budżetem działającym w słabej sieci, a nie tylko na błyszczącej maszynie programistycznej.
• Musi zacząć się szybko. Od dawna koncentrujemy się na utrzymaniu zaangażowania użytkowników, zapewniając widoczność i użyteczność naszych witryn w mniej niż 1 do 2 sekund. Jeśli chodzi o aplikacje internetowe, czas uruchamiania jest tak samo ważny jak zawsze. Jeśli cała zawartość aplikacji jest buforowana, a przeglądarka nadal znajduje się w pamięci urządzenia, aplikacja internetowa może uruchomić się szybciej niż aplikacja natywna. Jednym z błędów popełnianych zarówno przez natywnych twórców aplikacji, jak i stron internetowych, jest wymaganie treści sieciowych, aby produkt działał.
• Aplikacja internetowa musi być niewielka, aby można ją było pobrać i zaktualizować: 10 MB ze sklepu z aplikacjami nie wydaje się dużo, ale 10 MB bez pamięci podręcznej pobieranych za każdym razem jest bardzo niemożliwe do zarządzania dla wielu użytkowników mobilnych.

Poza tym najistotniejszą pozycją jest to, w head dokumentu:

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

Ta linia zapewnia, że ​​nie ma 300-milisekundowego opóźnienia w dotknięciu w przeglądarkach telefonicznych opartych na Chromium lub Firefox, ale nadal umożliwia użytkownikowi powiększanie przez szczypanie (idealne dla ułatwień dostępu).

Odkąd pojawił się iOS 8, kliknięcia są domyślnie szybkie, ale mogą wydawać się wolne, jeśli stuknięcie jest szybkie, zgodnie z niektórymi heurystykami. Jeśli jest to dla Ciebie problem, polecam użyć FastClick, aby usunąć opóźnienie.

Jest też kwestia wykonania animacji. Prawdopodobnie będziesz potrzebować wielu ładnych elementów animowanych, które mogą być przeciągane przez użytkownika i innych uroczych interakcji.

Wydajność sieci można omówić bardzo szczegółowo i jest to temat bliski mojemu sercu, ale nie będę się tutaj zagłębiał. Dotknę tego, co robię, aby moje interakcje i animacje były ostre i płynne.

Poszukaj lub zapytaj znajomych lub rodzinę o stary smartfon. Zwykle pożyczam Nexusa 4 mojego partnera.

Podłącz telefon do komputera i wejdź na chrome://inspect/#devices . Spowoduje to otwarcie okna kontroli, którego możesz użyć do sprawdzenia stron internetowych uruchomionych w telefonie. Możesz użyć profilowania i wyświetlić oś czasu, aby znaleźć źródła słabej wydajności, a następnie zoptymalizować je w oparciu o rzeczywiste urządzenie bazowe.

Animowanie niektórych właściwości CSS jest jedną z największych przyczyn niestabilnej animacji, znanej jako jank. Wyzwalacze CSS to doskonałe źródło informacji, które pozwalają określić, które właściwości można bezpiecznie animować bez konieczności przemalowywania przeglądarki lub zmiany układu całej strony.

Jeśli pisanie wydajnych animacji jest dla ciebie zniechęcającym zadaniem, wiele bibliotek poradzi sobie z tym zadaniem. Moim ulubionym jest GreenSock, który bardzo dobrze radzi sobie z interakcjami dotykowymi, takimi jak przeciąganie przedmiotów, i który może wykonywać bardzo fantazyjne animacje i animacje.

Powiadomienia push

Powiadomienia push to świetny sposób na ponowne nawiązanie kontaktu z użytkownikami. Prosząc użytkownika, stawiasz swoją aplikację na pierwszym planie. Mogli dokończyć niedokończoną transakcję lub otrzymać alerty o nowej, istotnej treści.

Upewnij się, że powiadomienia push są istotne dla użytkownika w przypadku wydarzeń, które mają miejsce w tym momencie. Nie trać czasu na rzeczy, które można zrobić później. To, o czym ich powiadamiasz, powinno wymagać ich działania (odpowiedzi komuś lub pójścia na wydarzenie). Nie wysyłaj też powiadomienia, jeśli Twoja aplikacja internetowa jest widoczna lub ma fokus.

Podczas interakcji powiadomienie powinno przenosić użytkownika na stronę działającą w trybie offline. Powiadomienia mogą być nieprzeczytane; mogą wchodzić w interakcje, gdy użytkownik nie ma połączenia z siecią. Użytkownik będzie sfrustrowany, jeśli Twoje powiadomienie push odmówi działania po próbie interakcji z nim.

Najlepsze wrażenia z powiadomień push uwalniają użytkownika od konieczności otwierania aplikacji internetowej ! „Masz nową wiadomość” jest bezużyteczne i irytujące jak nagłówek typu clickbait. Wyświetl wiadomość i nadawcę.

Przyciski akcji w powiadomieniu mogą wyświetlać monity o interakcję, które niekoniecznie otwierają przeglądarkę („Podoba mi się ten post”, „Odpowiedz tak”, „Odpowiedz nie”, „Przypomnij mi później”). Służą one użytkownikowi na jego warunkach, utrzymują jego zaangażowanie i minimalizują jego inwestycję czasu.

Jeśli spamujesz użytkownika zwykłymi lub nieistotnymi powiadomieniami, może on wyłączyć powiadomienia dla Twojej aplikacji w przeglądarce. Po tym, ponowne zaangażowanie ich będzie prawie niemożliwe i nie będziesz w stanie ponownie poprosić ich o pozwolenie!

Aby tego uniknąć, ustaw trasę do przycisku „wyłącz powiadomienie” w aplikacji, aby była przejrzysta i łatwa. Po rozwiązaniu problemów frustrujących użytkowników możesz spróbować ponownie zaangażować.

Interfejs API powiadomień push wymaga pracownika usługi. Ponieważ możliwe jest otrzymywanie powiadomień wypychanych, gdy żadna karta przeglądarki nie jest otwarta, service worker obsłuży żądanie powiadomienia w wątku w tle. Może wykonywać operacje asynchroniczne, takie jak wysyłanie żądania pobrania do interfejsu API przed wyświetleniem powiadomienia użytkownikowi.

Aby utworzyć powiadomienie push, wyślij żądanie do punktu końcowego dostarczonego przez producenta przeglądarki. W przypadku przeglądarek opartych na Chromium (Opera, Samsung i Chrome) jest to Firebase Cloud Messaging. Te przeglądarki również zachowują się nieco poza specyfikacją.

Szczegółowe informacje na ten temat można znaleźć, prosząc o pozwolenie na powiadomienia 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); })

Subskrypcja to obiekt, który wygląda tak:

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

W powyższym przykładzie identyfikator uuid jednoznacznie identyfikuje aktualnie używaną przeglądarkę.

Uwaga: przeglądarki oparte na Chromium zachowują się nieco inaczej. Potrzebny będzie identyfikator aplikacji Firebase, który należy wpisać w pliku manifestu aplikacji internetowej (na przykład "gcm_sender_id": "90157766285" ).

Ponadto punkt końcowy nie będzie działał w podanym formacie. Twój serwer musi go nieco zmanipulować, aby działał. Musi to być żądanie POST z kluczem API w head i identyfikatorem uuid w body .

Podczas wysyłania powiadomienia push istnieje możliwość wysłania danych w treści samego powiadomienia push. Jest to złożone i obejmuje szyfrowanie zawartości żądania API. Pakiet web-push dla Node.js poradzi sobie z tym, ale nie wolę tego.

Możliwe jest wykonywanie żądań asynchronicznych po otrzymaniu powiadomienia, więc wolę wysłać minimalne powiadomienie, znane jako „łaskotanie”, do klienta, a następnie pracownik serwisu wyśle ​​żądanie pobrania do mojego interfejsu API, aby pobrać dowolne ostatnie aktualizacje.

Uwaga: Service worker może zostać zamknięty przez przeglądarkę w dowolnym momencie. Funkcja event.waitUntil w zdarzeniu wypychania informuje pracownika serwisu, aby nie zamykał, dopóki zdarzenie nie zostanie zakończone.

 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' }) }) ); });

Możesz także nasłuchiwać kliknięcia lub interakcji z naciśnięciem na zdarzeniach powiadomień. Użyj ich, aby zdecydować, jak odpowiedzieć. Możesz otworzyć nową kartę przeglądarki, skoncentrować się na istniejącej karcie lub złożyć żądanie API. Możesz także wybrać, czy zamknąć powiadomienie, czy pozostawić je otwarte. Użyj tej funkcji z akcjami na powiadomieniu, aby wbudować wspaniałe funkcje w samo powiadomienie. Zapewni to wspaniałe wrażenia, ponieważ użytkownik nie będzie musiał za każdym razem otwierać Twojej aplikacji.

Nie ignoruj ​​​​mocnych stron sieci

Ostatnią i najważniejszą kwestią jest to, że w naszym pośpiechu na doświadczenie podobne do aplikacji, nie powinniśmy zapominać o tym, by pozostać internetowym w jednym bardzo ważnym aspekcie: adresach URL.

Zainstalowane aplikacje internetowe często ukrywają powłokę przeglądarki. Nie ma paska adresu, w którym użytkownik mógłby udostępnić bieżący adres URL, a użytkownik nie może zapisać bieżącej strony na później.

Adresy URL mają wyjątkową zaletę internetową: możesz zachęcić użytkowników do korzystania z Twojej aplikacji, klikając, a nie opisując, jak się po niej poruszać. Mimo to bardzo łatwo zapomnieć o ujawnieniu tego użytkownikom. Możesz napisać najlepszą aplikację na świecie, ale jeśli nikt nie będzie mógł się nią podzielić, wyrządzisz sobie wielką krzywdę.

Sprowadza się to do tego: Zapewnij sposoby udostępniania aplikacji za pomocą przycisków udostępniania lub przycisku do ujawnienia adresu URL.

A co z przeglądarkami, które nie obsługują progresywnych aplikacji internetowych?

Sprawdź Czy ServiceWorker jest gotowy? dla aktualnego stanu wsparcia dla pracowników usług w różnych przeglądarkach.

Być może zauważyłeś przez to wszystko, że wspomniałem o Chrome, Firefox i Edge, ale pominąłem Safari. Firma Apple przedstawiła światu aplikacje internetowe i wykazywała zainteresowanie progresywnymi aplikacjami internetowymi, ale nadal nie obsługuje pracowników usług ani manifestu aplikacji internetowych. Co możesz zrobić?

Możliwe jest utworzenie witryny offline dla Safari z AppCache, ale jest to zarówno trudne, jak i obarczone dziwnymi przypadkami, które mogą zepsuć stronę lub sprawić, że będzie ona trwale nieaktualna po pierwszym załadowaniu.

Zamiast tego stwórz świetną aplikację internetową. Twoja praca nie pójdzie na marne, ponieważ wrażenia z Safari, które jest bardzo dobrą przeglądarką, nadal będą świetne. Kiedy pracownicy serwisu przyjdą do Safari, będziesz gotowy, aby z nich skorzystać.

Wreszcie, możemy spodziewać się wielu ekscytujących zmian w świecie aplikacji internetowych, z rosnącą obsługą technologii stojących za nimi i nowymi funkcjami pojawiającymi się na platformie internetowej, takimi jak Web Bluetooth API do interakcji ze sprzętem, WebVR do wirtualnego rzeczywistości i WebGL 2 do grania z dużą szybkością. Teraz jest doskonały czas na poznanie możliwości aplikacji internetowych i wzięcie udziału w kształtowaniu przyszłości sieci.

Spinki do mankietów

Inne pisanie w progresywnych aplikacjach internetowych

• „Kolejny blog o stanie i przyszłości progresywnej aplikacji internetowej”, Ada Rose Edwards

Linki, o których mowa w artykule

• „Kształt App Store”, Charles Perry
• Pomocnicy Service Worker, Google, GitHub
• Service Worker Toolbox, Google, GitHub
• „Opóźnienie kliknięcia 300 milisekund i iOS 8”, TJ VanToll
• „Caching najlepsze praktyki i maksymalizacji wieku”, Jake Archibald