ASP.NET Core Blazor Progresywna aplikacja internetowa (PWA)

Progresywna Blazor aplikacja internetowa (PWA) to jednostronicowa aplikacja , która używa nowoczesnych interfejsów API przeglądarki i możliwości do zachowania się jak aplikacja klasyczna.

Blazor WebAssembly to oparta na standardach platforma aplikacji internetowej po stronie klienta, dzięki czemu może używać dowolnego interfejsu API przeglądarki, w tym interfejsów API programu PWA wymaganych do następujących funkcji:

• Praca w trybie offline i ładowanie natychmiast, niezależnie od szybkości sieci.
• Uruchamianie we własnym oknie aplikacji, a nie tylko w oknie przeglądarki.
• Uruchamianie z menu startowego systemu operacyjnego hosta, docka lub home ekranu.
• Odbieranie powiadomień wypychanych z serwera zaplecza, nawet jeśli użytkownik nie korzysta z aplikacji.
• Automatyczne aktualizowanie w tle.

Słowo progresywne służy do opisywania tych aplikacji, ponieważ:

• Użytkownik może najpierw odkryć i użyć aplikacji w przeglądarce internetowej, jak każdy inny SPA.
• Później użytkownik przechodzi do instalowania go w systemie operacyjnym i włączania powiadomień wypychanych.

Tworzenie projektu na podstawie szablonu programu PWA

Program Visual Studio

Podczas tworzenia nowej Blazor WebAssembly aplikacji zaznacz pole wyboru Progresywna aplikacja internetowa.

Visual Studio Code/interfejs wiersza polecenia platformy .NET

Użyj następującego polecenia, aby utworzyć projekt PWA w powłoce poleceń z przełącznikiem --pwa :

dotnet new blazorwasm -o MyBlazorPwa --pwa

W poprzednim poleceniu -o|--output opcja tworzy nowy folder dla aplikacji o nazwie MyBlazorPwa.

Konwertowanie istniejącej Blazor WebAssembly aplikacji na aplikację PWA

Przekonwertuj istniejącą Blazor WebAssembly aplikację na aplikację PWA, postępując zgodnie ze wskazówkami w tej sekcji.

W pliku projektu aplikacji:

• Dodaj następującą ServiceWorkerAssetsManifest właściwość do elementu PropertyGroup:

    ...
    <ServiceWorkerAssetsManifest>service-worker-assets.js</ServiceWorkerAssetsManifest>
  </PropertyGroup>
  

• Dodaj następujący ServiceWorker element do elementu ItemGroup:

  <ItemGroup>
    <ServiceWorker Include="wwwroot\service-worker.js" 
      PublishedContent="wwwroot\service-worker.published.js" />
  </ItemGroup>
  

Aby uzyskać zasoby statyczne, użyj jednej z następujących metod:

• Utwórz oddzielny, nowy projekt PWA za pomocą dotnet new polecenia w powłoce poleceń:

  dotnet new blazorwasm -o MyBlazorPwa --pwa
  

  W poprzednim poleceniu -o|--output opcja tworzy nowy folder dla aplikacji o nazwie MyBlazorPwa.

  Jeśli nie konwertujesz aplikacji dla najnowszej wersji, przekaż -f|--framework tę opcję. Poniższy przykład tworzy aplikację dla ASP.NET Core w wersji 5.0:

  dotnet new blazorwasm -o MyBlazorPwa --pwa -f net5.0
  

• Przejdź do repozytorium ASP.NET Core GitHub pod następującym adresem URL, które łączy się ze źródłem i elementami zawartości odwołania do main gałęzi. Wybierz wersję, z którą pracujesz, z listy rozwijanej Przełącz gałęzie lub tagi , która ma zastosowanie do aplikacji.

  Blazor WebAssembly folder szablonu wwwroot projektu (dotnet/aspnetcore gałąź repozytorium main GitHub)

  Uwaga

  Linki dokumentacji do źródła referencyjnego platformy .NET zwykle ładują domyślną gałąź repozytorium, która odzwierciedla bieżące programowanie dla następnej wersji platformy .NET. Aby wybrać tag dla określonej wersji, użyj listy rozwijanej Przełącz gałęzie lub tagi. Aby uzyskać więcej informacji, zobacz Jak wybrać tag wersji kodu źródłowego platformy ASP.NET Core (dotnet/AspNetCore.Docs #26205).

  Z folderu źródłowego wwwroot w aplikacji utworzonej lub z zasobów referencyjnych w dotnet/aspnetcore repozytorium GitHub skopiuj następujące pliki do folderu aplikacji wwwroot :

  • icon-192.png
  • icon-512.png
  • manifest.webmanifest
  • service-worker.js
  • service-worker.published.js

W pliku aplikacji wwwroot/index.html :

• Dodaj <link> elementy dla ikony manifestu i aplikacji:

  <link href="manifest.webmanifest" rel="manifest" />
  <link rel="apple-touch-icon" sizes="512x512" href="icon-512.png" />
  <link rel="apple-touch-icon" sizes="192x192" href="icon-192.png" />
  

• Dodaj następujący <script> tag wewnątrz tagu zamykającego </body> bezpośrednio po tagu skryptu blazor.webassembly.js :

      ...
      <script>navigator.serviceWorker.register('service-worker.js');</script>
  </body>
  

Instalacja i manifest aplikacji

Podczas odwiedzania aplikacji utworzonej przy użyciu szablonu programu PWA użytkownicy mają możliwość zainstalowania aplikacji w menu Start systemu operacyjnego, doku lub home ekranie. Sposób prezentowania tej opcji zależy od przeglądarki użytkownika. W przypadku korzystania z przeglądarek opartych na chromium na pulpicie, takich jak Edge lub Chrome, na pasku adresu URL zostanie wyświetlony przycisk Dodaj . Gdy użytkownik wybierze przycisk Dodaj , otrzyma okno dialogowe potwierdzenia:

W systemie iOS odwiedzający mogą zainstalować aplikację PWA przy użyciu przycisku Udostępnij w przeglądarce Safari i opcji Dodaj do ekranu głównego. W przeglądarce Chrome dla systemu Android użytkownicy powinni wybrać przycisk Menu w prawym górnym rogu, a następnie pozycję Dodaj do Home ekranu.

Po zainstalowaniu aplikacja zostanie wyświetlona we własnym oknie bez paska adresu:

Aby dostosować tytuł okna, schemat kolorów, ikonę lub inne szczegóły, zobacz manifest.json plik w katalogu projektu wwwroot . Schemat tego pliku jest definiowany przez standardy sieci Web. Aby uzyskać więcej informacji, zobacz Dokumentację internetową usługi MDN: Manifest aplikacji internetowej.

Obsługa trybu offline

Aplikacje utworzone przy użyciu opcji szablonu programu PWA mają obsługę uruchamiania w trybie offline. Użytkownik musi najpierw odwiedzić aplikację, gdy jest w trybie online. Przeglądarka automatycznie pobiera i buforuje wszystkie zasoby wymagane do działania w trybie offline.

Ważne

Wsparcie programistyczne zakłócałoby zwykły cykl programowania wprowadzania zmian i ich testowania. W związku z tym obsługa trybu offline jest włączona tylko dla opublikowanych aplikacji.

Ostrzeżenie

Jeśli zamierzasz dystrybuować aplikację PWA z obsługą trybu offline, istnieje kilka ważnych ostrzeżeń i zastrzeżeń. Te scenariusze są związane z agentami PWA w trybie offline i nie są specyficzne dla Blazorprogramu . Pamiętaj, aby przeczytać i zrozumieć te zastrzeżenia przed wprowadzeniem założeń dotyczących działania aplikacji z obsługą trybu offline.

Aby zobaczyć, jak działa obsługa trybu offline:

1. Opublikuj aplikację. Aby uzyskać więcej informacji, zobacz Host and deploy ASP.NET Core Blazor.

2. Wdróż aplikację na serwerze obsługującym protokół HTTPS i uzyskaj dostęp do aplikacji w przeglądarce pod bezpiecznym adresem HTTPS.

3. Otwórz narzędzia deweloperskie przeglądarki i sprawdź, czy proces roboczy usługi jest zarejestrowany dla hosta na karcie Aplikacja :

   

4. Załaduj ponownie stronę i sprawdź kartę Sieć . Proces roboczy usługi lub pamięć podręczna są wyświetlane jako źródła wszystkich zasobów strony:

   

5. Aby sprawdzić, czy przeglądarka nie jest zależna od dostępu do sieci w celu załadowania aplikacji, albo:

   • Zamknij serwer internetowy i sprawdź, jak aplikacja nadal działa normalnie, co obejmuje ponowne ładowanie strony. Podobnie aplikacja nadal działa normalnie, gdy występuje wolne połączenie sieciowe.
   • Poinstruuj przeglądarkę, aby symulowała tryb offline na karcie Sieć :

   

Obsługa trybu offline przy użyciu procesu roboczego usługi jest standardem internetowym, a nie specyficznym dla Blazorelementu . Aby uzyskać więcej informacji na temat procesów roboczych usług, zobacz dokumentację internetową usługi MDN: interfejs API procesu roboczego usługi. Aby dowiedzieć się więcej na temat typowych wzorców użycia dla procesów roboczych usług, zobacz Google Web: Cykl życia procesu roboczego usługi.

BlazorSzablon programu PWA tworzy dwa pliki procesu roboczego usługi:

• wwwroot/service-worker.js, który jest używany podczas programowania.
• wwwroot/service-worker.published.js, który jest używany po opublikowaniu aplikacji.

Aby udostępnić logikę między dwoma plikami procesu roboczego usługi, rozważ następujące podejście:

• Dodaj trzeci plik JavaScript, aby przechowywać wspólną logikę.
• Użyj self.importScripts polecenia , aby załadować wspólną logikę do obu plików procesów roboczych usługi.

Strategia pobierania najpierw pamięci podręcznej

Wbudowany service-worker.published.js proces roboczy usługi rozwiązuje żądania przy użyciu strategii opartej na pamięci podręcznej. Oznacza to, że proces roboczy usługi preferuje zwracanie buforowanej zawartości, niezależnie od tego, czy użytkownik ma dostęp do sieci, czy nowszą zawartość jest dostępna na serwerze.

Strategia pierwszej pamięci podręcznej jest cenna, ponieważ:

• Zapewnia niezawodność. Dostęp sieciowy nie jest stanem logicznym. Użytkownik nie jest po prostu w trybie online ani w trybie offline:

  • Urządzenie użytkownika może zakładać, że jest w trybie online, ale sieć może być tak niska, aby czekać na niepraktyczne.
  • Sieć może zwracać nieprawidłowe wyniki dla niektórych adresów URL, takich jak w przypadku, gdy istnieje portal sieci WI-Fi, który obecnie blokuje lub przekierowuje określone żądania.

  Dlatego interfejs API przeglądarki navigator.onLine nie jest niezawodny i nie powinien być zależny od.

• Zapewnia poprawność. Podczas tworzenia pamięci podręcznej zasobów w trybie offline proces roboczy usługi używa skrótów zawartości, aby zagwarantować, że pobrał kompletną i spójną migawkę zasobów w jednym momencie. Ta pamięć podręczna jest następnie używana jako jednostka niepodzielna. Nie ma sensu prosić sieci o nowsze zasoby, ponieważ jedyne wymagane wersje są już buforowane. Inne elementy są zagrożone niespójnością i niezgodnością (na przykład próba użycia wersji zestawów platformy .NET, które nie zostały skompilowane razem).

Jeśli musisz uniemożliwić przeglądarce pobieranie service-worker-assets.js z pamięci podręcznej HTTP, na przykład aby rozwiązać tymczasowe błędy sprawdzania integralności podczas wdrażania nowej wersji procesu roboczego usługi, zaktualizuj rejestrację procesu roboczego usługi w wwwroot/index.html updateViaCache ustawieniu na wartość "none":

<script>
  navigator.serviceWorker.register('/service-worker.js', {updateViaCache: 'none'});
</script>

Aktualizacje w tle

Jako model mentalny można traktować aplikację PWA w trybie offline, która działa jak aplikacja mobilna, którą można zainstalować. Aplikacja uruchamia się natychmiast niezależnie od łączności sieciowej, ale zainstalowana logika aplikacji pochodzi z migawki punktu w czasie, która może nie być najnowszą wersją.

Szablon Blazor pwA tworzy aplikacje, które automatycznie próbują zaktualizować się w tle za każdym razem, gdy użytkownik odwiedza i ma działające połączenie sieciowe. Sposób, w jaki to działa, wygląda następująco:

• Podczas kompilacji projekt generuje manifest zasobów procesu roboczego usługi o nazwie service-worker-assets.js. Manifest zawiera listę wszystkich zasobów statycznych, których aplikacja wymaga, aby działała w trybie offline, takich jak zestawy platformy .NET, pliki JavaScript i arkusze CSS, w tym skróty zawartości. Lista zasobów jest ładowana przez proces roboczy usługi, aby wiedzieć, które zasoby mają być buforowane.
• Za każdym razem, gdy użytkownik odwiedza aplikację, przeglądarka ponownie żąda service-worker.js i service-worker-assets.js w tle. Pliki są porównywane bajty dla bajtów z istniejącym zainstalowanym procesem roboczym usługi. Jeśli serwer zwraca zmienioną zawartość dla jednego z tych plików, proces roboczy usługi próbuje zainstalować nową wersję samego siebie.
• Podczas instalowania nowej wersji procesu roboczego usługi tworzy nową, oddzielną pamięć podręczną dla zasobów w trybie offline i rozpoczyna wypełnianie pamięci podręcznej zasobami wymienionymi w service-worker-assets.jstemacie . Ta logika onInstall jest implementowana w funkcji wewnątrz service-worker.published.js.
• Proces kończy się pomyślnie, gdy wszystkie zasoby są ładowane bez błędu i wszystkie skróty zawartości są zgodne. W przypadku powodzenia nowy proces roboczy usługi wprowadza stan oczekiwania na aktywację. Gdy tylko użytkownik zamknie aplikację (nie ma pozostałych kart aplikacji lub okien), nowy proces roboczy usługi staje się aktywny i jest używany do kolejnych wizyt w aplikacji. Stary proces roboczy usługi i jego pamięć podręczna są usuwane.
• Jeśli proces nie zostanie ukończony pomyślnie, nowe wystąpienie procesu roboczego usługi zostanie odrzucone. Proces aktualizacji zostanie ponowiony podczas następnej wizyty użytkownika, gdy miejmy nadzieję, że klient ma lepsze połączenie sieciowe, które może zakończyć żądania.

Dostosuj ten proces, edytując logikę procesu roboczego usługi. Żadne z powyższych zachowań nie jest specyficzne, Blazor ale jest tylko domyślnym środowiskiem udostępnianym przez opcję szablonu programu PWA. Aby uzyskać więcej informacji, zobacz Dokumentacja sieci Web usługi MDN: interfejs API procesu roboczego usługi.

Jak żądania są rozwiązywane

Zgodnie z opisem w sekcji Strategia Pobierania po raz pierwszy w pamięci podręcznej domyślny proces roboczy usługi używa strategii buforowania pierwszej pamięci podręcznej, co oznacza, że próbuje obsłużyć buforowane zawartość, gdy jest dostępna. Jeśli nie ma zawartości buforowanej dla określonego adresu URL, na przykład podczas żądania danych z interfejsu API zaplecza, proces roboczy usługi wraca do zwykłego żądania sieciowego. Żądanie sieciowe powiedzie się, jeśli serwer jest osiągalny. Ta logika jest implementowana wewnątrz onFetch funkcji w programie service-worker.published.js.

Jeśli składniki aplikacji Razor polegają na żądaniu danych z interfejsów API zaplecza i chcesz zapewnić przyjazne środowisko użytkownika dla żądań niepomyślnie z powodu niedostępności sieci, zaimplementuj logikę w składnikach aplikacji. Na przykład użyj polecenia try/catch wokół HttpClient żądań.

Obsługa stron renderowanych przez serwer

Zastanów się, co się stanie, gdy użytkownik najpierw przejdzie do adresu URL, takiego jak /counter lub dowolny inny link bezpośredni w aplikacji. W takich przypadkach nie chcesz zwracać zawartości buforowanej jako /counter, ale zamiast tego potrzebujesz przeglądarki, aby załadować zawartość z pamięci podręcznej, /index.html aby uruchomić Blazor WebAssembly aplikację. Te początkowe żądania są nazywane żądaniami nawigacji , a nie:

• subresource żądania dotyczące obrazów, arkuszy stylów lub innych plików.
• fetch/XHR żądania dotyczące danych interfejsu API.

Domyślny proces roboczy usługi zawiera logikę specjalnej wielkości liter dla żądań nawigacji. Proces roboczy usługi rozwiązuje żądania, zwracając buforowaną zawartość dla /index.html, niezależnie od żądanego adresu URL. Ta logika onFetch jest implementowana w funkcji wewnątrz service-worker.published.js.

Jeśli aplikacja ma określone adresy URL, które muszą zwracać kod HTML renderowany przez serwer i nie obsługiwać /index.html z pamięci podręcznej, należy edytować logikę w ramach procesu roboczego usługi. Jeśli wszystkie adresy URL zawierające muszą /Identity/ być obsługiwane jako zwykłe żądania tylko online do serwera, zmodyfikuj logikę service-worker.published.js onFetch . Znajdź następujący kod:

const shouldServeIndexHtml = event.request.mode === 'navigate';

Zmień kod na następujący:

const shouldServeIndexHtml = event.request.mode === 'navigate'
  && !event.request.url.includes('/Identity/');

Jeśli tego nie zrobisz, niezależnie od łączności sieciowej proces roboczy usługi przechwytuje żądania dotyczące takich adresów URL i rozwiązuje je przy użyciu polecenia /index.html.

Dodaj dodatkowe punkty końcowe dla zewnętrznych dostawców uwierzytelniania do sprawdzenia. W poniższym przykładzie /signin-google do sprawdzania dodano uwierzytelnianie Google:

const shouldServeIndexHtml = event.request.mode === 'navigate'
  && !event.request.url.includes('/Identity/')
  && !event.request.url.includes('/signin-google');

W środowisku nie jest wymagana Development żadna akcja, w której zawartość jest zawsze pobierana z sieci.

Kontrolowanie buforowania zasobów

Jeśli projekt definiuje ServiceWorkerAssetsManifest właściwość MSBuild, Blazornarzędzie kompilacji generuje manifest zasobów procesu roboczego usługi o określonej nazwie. Domyślny szablon programu PWA tworzy plik projektu zawierający następującą właściwość:

<ServiceWorkerAssetsManifest>service-worker-assets.js</ServiceWorkerAssetsManifest>

Plik jest umieszczany w katalogu wyjściowym wwwroot , więc przeglądarka może pobrać ten plik, żądając /service-worker-assets.jspolecenia . Aby wyświetlić zawartość tego pliku, otwórz /bin/Debug/{TARGET FRAMEWORK}/wwwroot/service-worker-assets.js plik w edytorze tekstów. Nie edytuj jednak pliku, ponieważ jest on ponownie wygenerowany w każdej kompilacji.

Lista manifestów:

• Wszystkie Blazorzasoby zarządzane, takie jak zestawy .NET i pliki środowiska uruchomieniowego zestawu WebAssembly platformy .NET wymagane do działania w trybie offline.
• Wszystkie zasoby do publikowania wwwroot w katalogu aplikacji, takie jak obrazy, arkusze stylów i pliki JavaScript, w tym statyczne zasoby internetowe dostarczane przez projekty zewnętrzne i pakiety NuGet.

Możesz kontrolować, które z tych zasobów są pobierane i buforowane przez proces roboczy usługi, edytując logikę w programie .onInstall service-worker.published.js Proces roboczy usługi pobiera i buforuje pliki pasujące do typowych rozszerzeń nazw plików internetowych, takich jak , , i , oraz .wasmtypy plików specyficzne dla Blazor WebAssemblyprogramu , takie jak .pdb pliki (wszystkie wersje) i .dll pliki (ASP.NET Core na platformie .NET 7 lub starszej). .js.css.html

Aby uwzględnić dodatkowe zasoby, które nie znajdują się w katalogu aplikacji wwwroot , zdefiniuj dodatkowe wpisy programu MSBuild ItemGroup , jak pokazano w poniższym przykładzie:

<ItemGroup>
  <ServiceWorkerAssetsManifestItem Include="MyDirectory\AnotherFile.json"
    RelativePath="MyDirectory\AnotherFile.json" AssetUrl="files/AnotherFile.json" />
</ItemGroup>

Metadane AssetUrl określają względny podstawowy adres URL, którego przeglądarka powinna używać podczas pobierania zasobu do pamięci podręcznej. Może to być niezależne od oryginalnej nazwy pliku źródłowego na dysku.

Ważne

Dodanie elementu ServiceWorkerAssetsManifestItem nie powoduje opublikowania pliku w katalogu aplikacji wwwroot . Dane wyjściowe publikowania muszą być kontrolowane oddzielnie. Jedyną ServiceWorkerAssetsManifestItem przyczyną jest pojawienie się dodatkowego wpisu w manifeście zasobów procesu roboczego usługi.

Powiadomienia wypychane do aplikacji

Podobnie jak w przypadku każdego innego programu PWA program Blazor WebAssembly PWA może odbierać powiadomienia wypychane z serwera zaplecza. Serwer może wysyłać powiadomienia wypychane w dowolnym momencie, nawet jeśli użytkownik nie korzysta aktywnie z aplikacji. Na przykład powiadomienia wypychane można wysyłać, gdy inny użytkownik wykonuje odpowiednią akcję.

Mechanizm wysyłania powiadomień wypychanych jest całkowicie niezależny od Blazor WebAssemblyprogramu , ponieważ jest implementowany przez serwer zaplecza, który może korzystać z dowolnej technologii. Jeśli chcesz wysyłać powiadomienia wypychane z serwera ASP.NET Core, rozważ użycie techniki podobnej do podejścia podjętego w warsztatach Blazing Pizza.

Mechanizm odbierania i wyświetlania powiadomienia wypychanego na kliencie jest również niezależny od Blazor WebAssemblyprogramu , ponieważ jest on implementowany w pliku JavaScript procesu roboczego usługi. Aby zapoznać się z przykładem, zobacz podejście używane w warsztatach Blazing Pizza.

Zastrzeżenia dotyczące agentów PWA w trybie offline

Nie wszystkie aplikacje powinny próbować obsługiwać użycie w trybie offline. Obsługa trybu offline zwiększa znaczącą złożoność, ale nie zawsze jest odpowiednia dla wymaganych przypadków użycia.

Obsługa trybu offline jest zwykle odpowiednia tylko:

• Jeśli podstawowy magazyn danych jest lokalny w przeglądarce. Na przykład podejście jest istotne w aplikacji z interfejsem użytkownika dla urządzenia IoT , które przechowuje dane w localStorage bazie danych lub IndexedDB.
• Jeśli aplikacja wykonuje znaczną ilość pracy, aby pobrać i buforować dane interfejsu API zaplecza odpowiednie dla każdego użytkownika, aby mogły przechodzić przez dane w trybie offline. Jeśli aplikacja musi obsługiwać edytowanie, należy skompilować system śledzenia zmian i synchronizowania danych z zapleczem.
• Jeśli celem jest zagwarantowanie, że aplikacja zostanie załadowana natychmiast niezależnie od warunków sieciowych. Zaimplementuj odpowiednie środowisko użytkownika wokół żądań interfejsu API zaplecza, aby pokazać postęp żądań i zachowywać się bezpiecznie, gdy żądania kończą się niepowodzeniem z powodu niedostępności sieci.

Ponadto, w trybie offline, pwA musi radzić sobie z szeregiem dodatkowych komplikacji. Deweloperzy powinni dokładnie zapoznać się z zastrzeżeniami w poniższych sekcjach.

Obsługa trybu offline tylko w przypadku opublikowania

Podczas programowania zwykle każda zmiana jest odzwierciedlana natychmiast w przeglądarce bez przechodzenia przez proces aktualizacji w tle. BlazorW związku z tym szablon PWA umożliwia obsługę trybu offline tylko po opublikowaniu.

Podczas tworzenia aplikacji obsługującej tryb offline nie wystarczy przetestować aplikację w Development środowisku. Musisz przetestować aplikację w stanie opublikowanym, aby zrozumieć, jak reaguje na różne warunki sieciowe.

Uzupełnianie aktualizacji po zakończeniu nawigacji użytkownika z aplikacji

Aktualizacje nie są wykonywane, dopóki użytkownik nie przejdzie z dala od aplikacji na wszystkich kartach. Jak wyjaśniono w sekcji Aktualizacje w tle, po wdrożeniu aktualizacji w aplikacji przeglądarka pobiera zaktualizowane pliki procesu roboczego usługi w celu rozpoczęcia procesu aktualizacji.

To, co zaskakuje wielu deweloperów, jest to, że nawet po zakończeniu tej aktualizacji nie będzie obowiązywać, dopóki użytkownik nie przejdzie na wszystkie karty. Nie wystarczy odświeżyć kartę wyświetlającą aplikację, nawet jeśli jest to jedyna karta wyświetlającą aplikację. Dopóki aplikacja nie zostanie całkowicie zamknięta, nowy proces roboczy usługi pozostanie w stanie oczekiwania na aktywację . Nie jest to specyficzne dla Blazorelementu , ale raczej jest standardowym zachowaniem platformy internetowej.

Zwykle dotyczy to deweloperów, którzy próbują przetestować aktualizacje procesu roboczego usługi lub zasobów buforowanych w trybie offline. Jeśli zaewidencjonujesz narzędzia deweloperskie przeglądarki, może zostać wyświetlony komunikat podobny do następującego:

Tak długo, jak lista "klientów", które są kartami lub oknami wyświetlającym aplikację, jest brakiem, proces roboczy będzie czekać. Powodem, dla którego pracownicy usług to robią, jest zagwarantowanie spójności. Spójność oznacza, że wszystkie zasoby są pobierane z tej samej niepodzielnej pamięci podręcznej.

Podczas testowania zmian warto wybrać link "skipWaiting", jak pokazano na powyższym zrzucie ekranu, a następnie ponownie załadować stronę. Można to zautomatyzować dla wszystkich użytkowników, kodując proces roboczy usługi, aby pominąć fazę "oczekiwanie" i natychmiast aktywować aktualizację. Jeśli pominiesz fazę oczekiwania, zrezygnowasz z gwarancji, że zasoby są zawsze pobierane spójnie z tego samego wystąpienia pamięci podręcznej.

Użytkownicy mogą uruchamiać dowolną historyczną wersję aplikacji

Deweloperzy sieci Web zwykle oczekują, że użytkownicy uruchamiają tylko najnowszą wdrożoną wersję swojej aplikacji internetowej, ponieważ jest to normalne w tradycyjnym modelu dystrybucji sieci Web. Jednak aplikacja PWA działająca w trybie offline jest bardziej zgodna z natywną aplikacją mobilną, w której użytkownicy nie muszą używać najnowszej wersji.

Jak wyjaśniono w sekcji Aktualizacje w tle, po wdrożeniu aktualizacji w aplikacji każdy istniejący użytkownik będzie nadal używać poprzedniej wersji przez co najmniej jedną dalszą wizytę, ponieważ aktualizacja występuje w tle i nie jest aktywowana, dopóki użytkownik nie przejdzie dalej. Ponadto używana poprzednia wersja nie musi być wcześniej wdrożona. Poprzednia wersja może być dowolną wersją historyczną, w zależności od tego, kiedy użytkownik ostatnio ukończył aktualizację.

Może to być problem, jeśli części frontonu i zaplecza aplikacji wymagają umowy dotyczącej schematu żądań interfejsu API. Nie można wdrażać zmian schematu interfejsu API niezgodnych z poprzednimi wersjami, dopóki nie będzie można mieć pewności, że wszyscy użytkownicy zostali uaktualnioni. Możesz też zablokować użytkownikom używanie niezgodnych starszych wersji aplikacji. To wymaganie scenariusza jest takie samo jak w przypadku natywnych aplikacji mobilnych. W przypadku wdrożenia zmiany powodującej niezgodność w interfejsach API serwera aplikacja kliencka zostanie przerwana dla użytkowników, którzy jeszcze nie zaktualizowali.

Jeśli to możliwe, nie wdrażaj zmian powodujących niezgodność w interfejsach API zaplecza. Jeśli musisz to zrobić, rozważ użycie standardowych interfejsów API procesu roboczego usługi, takich jak ServiceWorkerRegistration , aby określić, czy aplikacja jest aktualna, a jeśli nie, aby zapobiec użyciu.

Interferencja stron renderowanych przez serwer

Zgodnie z opisem w sekcji Obsługa stron renderowanych na serwerze, jeśli chcesz pominąć zachowanie procesu roboczego usługi zwracania /index.html zawartości dla wszystkich żądań nawigacji, edytuj logikę w ramach procesu roboczego usługi.

Cała zawartość manifestu zasobu procesu roboczego usługi jest buforowana

Zgodnie z opisem w sekcji Kontrola buforowania zasobów plik service-worker-assets.js jest generowany podczas kompilacji i wyświetla listę wszystkich zasobów, które proces roboczy usługi powinien pobrać i buforować.

Ponieważ ta lista zawiera wszystkie elementy emitowane do wwwrootprogramu , w tym zawartość dostarczaną przez zewnętrzne pakiety i projekty, należy zachować ostrożność, aby nie umieszczać tam zbyt dużej ilości zawartości. wwwroot Jeśli katalog zawiera miliony obrazów, proces roboczy usługi próbuje pobrać i buforować je wszystkie, zużywając nadmierną przepustowość i najprawdopodobniej nie kończy się pomyślnie.

Zaimplementuj dowolną logikę, aby kontrolować, który podzbiór zawartości manifestu powinien być pobierany i buforowany przez edytowanie onInstall funkcji w programie service-worker.published.js.

Interakcja z uwierzytelnianiem

Szablon programu PWA może być używany w połączeniu z uwierzytelnianiem. Program PWA obsługujący tryb offline może również obsługiwać uwierzytelnianie, gdy użytkownik ma początkową łączność sieciową.

Gdy użytkownik nie ma łączności sieciowej, nie może uwierzytelnić ani uzyskać tokenów dostępu. Próba odwiedzenia strony logowania bez dostępu do sieci powoduje wyświetlenie komunikatu o błędzie sieciowym. Należy zaprojektować przepływ interfejsu użytkownika, który umożliwia użytkownikowi wykonywanie przydatnych zadań w trybie offline bez próby uwierzytelnienia użytkownika lub uzyskania tokenów dostępu. Alternatywnie możesz zaprojektować aplikację, aby bezpiecznie zakończyć się niepowodzeniem, gdy sieć nie jest dostępna. Jeśli nie można zaprojektować aplikacji do obsługi tych scenariuszy, możesz nie chcieć włączyć obsługi offline.

Gdy aplikacja przeznaczona do korzystania w trybie online i offline jest ponownie w trybie online:

• Aplikacja może wymagać aprowizacji nowego tokenu dostępu.
• Aplikacja musi wykryć, czy inny użytkownik jest zalogowany do usługi, aby można było zastosować operacje na koncie użytkownika, które zostało wykonane podczas pracy w trybie offline.

Aby utworzyć aplikację PWA w trybie offline, która współdziała z uwierzytelnianiem:

• Zastąp element AccountClaimsPrincipalFactory<TAccount> fabryką, która przechowuje ostatniego zalogowanego użytkownika i używa przechowywanego użytkownika, gdy aplikacja jest w trybie offline.
• Operacje kolejki, gdy aplikacja jest w trybie offline i stosują je, gdy aplikacja zwraca dane w trybie online.
• Podczas wylogowywanie wyczyść przechowywanego użytkownika.

Przykładowa CarChecker aplikacja demonstruje powyższe podejścia. Zobacz następujące części aplikacji:

• OfflineAccountClaimsPrincipalFactory (Client/Data/OfflineAccountClaimsPrincipalFactory.cs)
• LocalVehiclesStore (Client/Data/LocalVehiclesStore.cs)
• LoginStatus component (Client/Shared/LoginStatus.razor)

Dodatkowe zasoby

• Rozwiązywanie problemów ze skryptem programu PowerShell integralności
• Negocjacje między źródłami po stronie SignalR klienta na potrzeby uwierzytelniania