ASP.NET Core Blazor Progressive Web Application (PWA)

A Blazor progresszív webalkalmazások (PWA) egy egyoldalas alkalmazások (SPA), amelyek modern böngésző API-kat és képességeket használnak asztali alkalmazásként való viselkedésre.

Blazor WebAssembly egy szabványalapú ügyféloldali webalkalmazás-platform, így bármilyen böngésző API-t használhat, beleértve a PWA API-kat is, amelyek a következő képességekhez szükségesek:

• Offline munka és azonnali betöltés, a hálózati sebességétől függetlenül.
• A saját alkalmazásablakában fut, nem csak egy böngészőablakban.
• Az indítás a gazdagép operációs rendszerének Start menüjéből, dokkjából vagy kezdőképernyőjéről történik.
• Leküldéses értesítések fogadása háttérkiszolgálóról, még akkor is, ha a felhasználó nem használja az alkalmazást.
• Automatikus frissítés a háttérben.

A progresszív szó az alábbi alkalmazások leírására szolgál, mert:

• A felhasználó először felfedezheti és használhatja az alkalmazást a webböngészőben, mint bármely más SPA.
• Később a felhasználó továbbhalad a telepítésig az operációs rendszerében, és engedélyezi a leküldéses értesítéseket.

Projekt létrehozása a PWA-sablonból

Visual Studio

Új Blazor WebAssembly alkalmazás létrehozásakor jelölje be a Progresszív webalkalmazás jelölőnégyzetet.

Visual Studio Code/ .NET CLI

A következő paranccsal hozzon létre egy PWA-projektet egy parancshéjban a --pwa kapcsolóval:

dotnet new blazorwasm -o MyBlazorPwa --pwa

Az előző parancsban a -o|--output beállítás létrehoz egy új mappát az alkalmazáshoz.MyBlazorPwa

Meglévő Blazor WebAssembly alkalmazás átalakítása PWA-vá

Blazor WebAssembly Meglévő alkalmazás átalakítása PWA-vá az ebben a szakaszban található útmutatást követve.

Az alkalmazás projektfájljában:

• Adja hozzá a következő ServiceWorkerAssetsManifest tulajdonságot a következőhöz PropertyGroup:

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

• Adja hozzá a következő ServiceWorker elemet egy ItemGroup-hez.

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

Statikus eszközök beszerzéséhez használja az alábbi módszerek egyikét :

• Hozzon létre egy különálló, új PWA-projektet egy parancshéjban a dotnet new paranccsal:

  dotnet new blazorwasm -o MyBlazorPwa --pwa
  

  Az előző parancsban a -o|--output beállítás létrehoz egy új mappát az alkalmazáshoz.MyBlazorPwa

  Ha nem a legújabb kiadáshoz konvertál egy alkalmazást, adja meg a -f|--framework lehetőséget. Az alábbi példa létrehozza az alkalmazást a .NET 5-höz:

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

• Keresse meg az ASP.NET Core GitHub-adattárat az alábbi URL-címen, amely az ág referenciaforrására és elemeire mutat main. Válassza ki azt a kiadást, amellyel dolgozik, az alkalmazásra vonatkozó Ágak vagy címkék váltása legördülő listából.

  Blazor WebAssembly projekt sablon wwwroot mappa (dotnet/aspnetcore GitHub tárház main ág)

  Megjegyzés:

  A .NET referenciaforrásra mutató dokumentációs hivatkozások általában betöltik az adattár alapértelmezett ágát, amely a .NET következő kiadásának aktuális fejlesztését jelöli. Egy adott kiadás címkéjének kiválasztásához használja az Ágak vagy címkék közötti váltás legördülő listát. További információ: A ASP.NET Core-forráskód (dotnet/AspNetCore.Docs #26205) verziócímkéjének kiválasztása.

  Másolja a következő fájlokat az alkalmazás wwwroot mappájába a létrehozott alkalmazás forrásmappájából dotnet/aspnetcore vagy a wwwroot GitHub-adattár hivatkozási eszközeiből:

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

Az alkalmazás fájljában wwwroot/index.html :

• Elemek hozzáadása <link> a jegyzék- és alkalmazásikonhoz:

  <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" />
  

• Közvetlenül a szkriptcímke után adja hozzá a következő JavaScriptet a </body> záró blazor.webassembly.js címkéhez:

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

  A updateViaCache: 'none' beállítás biztosítja, hogy:

  • A böngésző nem használja a szolgáltatásvégző szkript gyorsítótárazott verzióit.
  • A szolgáltatásvégző frissítések megbízhatóan, a HTTP-gyorsítótárazás letiltása nélkül lesznek alkalmazva.
  • A PWA-alkalmazások kiszámíthatóbb módon frissíthetik a szolgáltatásmunkásokat.

  Ez olyan gyorsítótárazási problémákat old meg, amelyek megakadályozhatják, hogy a szolgáltatásvégző frissítések megfelelően legyenek alkalmazva, ami különösen fontos azon PWA-k számára, amelyek szolgáltatásmunkásokra támaszkodnak az offline funkciókhoz.

Telepítési és alkalmazásjegyzék

A PWA-sablonnal létrehozott alkalmazás felkeresésekor a felhasználóknak lehetőségük van arra, hogy az alkalmazást telepítsék az operációs rendszerük start menüjébe, dockjára vagy kezdőképernyőjére. A beállítás megjelenítési módja a felhasználó böngészőjétől függ. Asztali Chromium-alapú böngészők, például az Edge vagy a Chrome használatakor megjelenik egy Hozzáadás gomb az URL-sávon. Miután a felhasználó a Hozzáadás gombra kattintott, megerősítést kérő párbeszédpanelt kap:

iOS rendszeren a látogatók a Safari Megosztás gombjával és a Hozzáadás a kezdőképernyőre lehetőséggel telepíthetik a PWA-t. Az Android Chrome-ban a felhasználóknak a jobb felső sarokban válasszák a Menü gombot, majd a Hozzáadás a Home képernyőhöz.

A telepítés után az alkalmazás a saját ablakában jelenik meg címsor nélkül:

Az ablak címének, színsémának, ikonjának vagy egyéb részleteinek testreszabásához tekintse meg a manifest.json fájlt a projekt könyvtárában wwwroot . A fájl sémáját webes szabványok határozzák meg. További információ: MDN webes dokumentumok: Webalkalmazás-jegyzék.

Támogatás offline módban

A PWA sablonbeállítással létrehozott alkalmazások támogatják az offline futtatásokat. A felhasználónak először meg kell látogatnia az alkalmazást, amíg online állapotban van. A böngésző automatikusan letölti és gyorsítótárazza az offline működéshez szükséges összes erőforrást.

Fontos

A fejlesztési támogatás megzavarná a módosítások és tesztelések szokásos fejlesztési ciklusát. Ezért az offline támogatás csak a közzétett alkalmazások esetében engedélyezett.

Figyelmeztetés

Ha offline kompatibilis PWA-t kíván terjeszteni, számos fontos figyelmeztetés és kiegészítés érhető el. Ezek a forgatókönyvek elválaszthatatlanul hozzátartoznak az offline PWA-khoz, és nem kifejezetten a Blazor. Mindenképpen olvassa el és ismerje meg ezeket a kikötéseket, mielőtt feltételezné, hogyan működik az offline kompatibilis alkalmazás.

Az offline támogatás működésének megtekintése:

1. Tegye közzé az alkalmazást. További információ: ASP.NET Core alkalmazások hosztolása és telepítése Blazor.

2. Helyezze üzembe az alkalmazást egy HTTPS-t támogató kiszolgálón, és a biztonságos HTTPS-címén fér hozzá az alkalmazáshoz egy böngészőben.

3. Nyissa meg a böngésző fejlesztői eszközeit, és ellenőrizze, hogy a service worker regisztrálva van-e a hoston az Alkalmazás lapon:

   

4. Töltse be újra a lapot, és vizsgálja meg a Hálózat lapot. A szolgáltatás-feldolgozó vagy a memória-gyorsítótár a lap összes eszközének forrásaként jelenik meg:

   

5. Annak ellenőrzéséhez, hogy a böngésző nem függ-e a hálózati hozzáféréstől az alkalmazás betöltéséhez, tegye a következők egyikét:

   • Állítsa le a webkiszolgálót, és nézze meg, hogyan működik az alkalmazás továbbra is a szokásos módon, beleértve a lapbetöltéseket is. Hasonlóképpen, az alkalmazás továbbra is normálisan működik, ha lassú a hálózati kapcsolat.
   • Utasítsa a böngészőt, hogy szimulálja az offline módot a Hálózat lapon:

   

A service worker használatával történő offline támogatás egy webes szabvány, amely nem kifejezetten Blazor-ra vonatkozik. További információ a szolgáltatásmunkásokról: MDN webes dokumentáció: Service Worker API. A szolgáltatásmunkások általános használati mintáiról a Google Web: The Service Worker Lifecycle című témakörben olvashat bővebben.

BlazorA PWA-sablon két szolgáltatásvégző fájlt hoz létre:

• wwwroot/service-worker.js, amelyet a fejlesztés során használnak.
• wwwroot/service-worker.published.js, amelyet az alkalmazás közzététele után használnak.

Ha meg szeretné osztani a logikát a két szolgáltatásvégző fájl között, fontolja meg a következő megközelítést:

• Adjon hozzá egy harmadik JavaScript-fájlt a közös logika tárolásához.
• Használja a self.importScripts-t a közös logika betöltésére mindkét szolgáltatási munkás fájlba.

Gyorsítótár-prioritású lekérési stratégia

A beépített service-worker.published.js szolgáltatási munkavállaló cache-first stratégiával oldja meg a kéréseket. Ez azt jelenti, hogy a szolgáltatásvégző szívesebben ad vissza gyorsítótárazott tartalmat, függetlenül attól, hogy a felhasználó rendelkezik-e hálózati hozzáféréssel, vagy újabb tartalom érhető el a kiszolgálón.

A gyorsítótár-első stratégia azért értékes, mert:

• Biztosítja a megbízhatóságot. A hálózati hozzáférés nem bináris állapot. A felhasználó nem egyszerűen online vagy offline:

  • A felhasználó eszköze feltételezheti, hogy online állapotban van, de a hálózat olyan lassú lehet, hogy nem praktikus várni.
  • Előfordulhat, hogy a hálózat érvénytelen eredményeket ad vissza bizonyos URL-címek esetében, például ha van egy kötött WIFI-portál, amely jelenleg blokkol vagy átirányít bizonyos kéréseket.

  Ez az oka annak, hogy a böngésző navigator.onLine API-ja nem megbízható, és nem szabad rá támaszkodni.

• Biztosítja a helyességet. Az offline erőforrások gyorsítótárának létrehozásakor a szolgáltatásvégző tartalomkivonat használatával garantálja, hogy egyetlen pillanat alatt lekérte az erőforrások teljes és önkonzisztens pillanatképét. Ezt a gyorsítótárat ezután atomi egységként használják. Nincs értelme újabb erőforrásokat kérni a hálózattól, mivel csak a már gyorsítótárazott verziókra van szükség. Bármi más kockázattal jár az inkonzisztencia és az inkompatibilitás (például a .NET-szerelvények nem együtt összeállított verzióinak használata).

Ha meg szeretné akadályozni, hogy a böngésző lekérje a service-worker-assets.js a HTTP-gyorsítótárból, például a szolgáltatásmunkás új verziójának telepítésekor fellépő ideiglenes integritás-ellenőrzési hibák elhárításához, a szolgáltatásmunkás regisztrálása wwwroot/index.html értékre van állítva: updateViaCachenone.

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

A updateViaCache: 'none' beállítás biztosítja, hogy:

• A böngésző nem használja a szolgáltatásvégző szkript gyorsítótárazott verzióit.
• A szolgáltatásvégző frissítések megbízhatóan, a HTTP-gyorsítótárazás letiltása nélkül lesznek alkalmazva.
• A PWA-alkalmazások kiszámíthatóbb módon frissíthetik a szolgáltatásmunkásokat.

Ez olyan gyorsítótárazási problémákat old meg, amelyek megakadályozhatják, hogy a szolgáltatásvégző frissítések megfelelően legyenek alkalmazva, ami különösen fontos azon PWA-k számára, amelyek szolgáltatásmunkásokra támaszkodnak az offline funkciókhoz.

Háttérfrissítések

Mentális modellként az offline-first PWA-t úgy képzelheti el, mint egy telepíthető mobilalkalmazást. Az alkalmazás a hálózati kapcsolattól függetlenül azonnal elindul, de a telepített alkalmazáslogika egy időponthoz kötött pillanatképből származik, amely lehet, hogy nem a legújabb verzió.

A Blazor PWA-sablon olyan alkalmazásokat hoz létre, amelyek automatikusan megpróbálják frissíteni magukat a háttérben, amikor a felhasználó meglátogatja őket, és működő hálózati kapcsolattal rendelkezik. Ennek működése a következő:

• A fordítás során a projekt létrehoz egy szolgáltatás-feldolgozói eszközjegyzéket, amely neve service-worker-assets.js. A jegyzék felsorolja azokat a statikus erőforrásokat, amelyekre az alkalmazásnak offline működésre van szüksége, például .NET-szerelvényeket, JavaScript-fájlokat és CSS-eket, beleértve a tartalomkivonatokat is. Az erőforráslistát a szolgáltatómunkás tölti be, hogy tudja, mely erőforrásokat tárolja gyorsítótárban.
• Minden alkalommal, amikor a felhasználó meglátogatja az alkalmazást, a böngésző a(z) service-worker.js és service-worker-assets.js elemeket újra kéri a háttérben. A fájlok bájtonkénti összehasonlítása a meglévő telepített szolgáltatásvégzővel. Ha a kiszolgáló ezen fájlok bármelyikének módosított tartalmát adja vissza, a szolgáltatásvégző megpróbálja telepíteni magának az új verzióját.
• Az új verzió telepítésekor a szolgáltatásvégző létrehoz egy új, különálló gyorsítótárat az offline erőforrásokhoz, és megkezdi a gyorsítótár feltöltését a listában felsorolt service-worker-assets.jserőforrásokkal. Ez a logika a onInstall-en/ön/ban/ben belül a(z) service-worker.published.js függvényben van implementálva.
• A folyamat sikeresen befejeződik, amikor az összes erőforrás hiba nélkül betöltődik, és minden tartalomkivonat megegyezik. Ha sikeres, az új szolgáltatásvégző aktiválásra váró állapotba kerül. Amint a felhasználó bezárja az alkalmazást (nincsenek további alkalmazásfülek vagy ablakok), az új szolgáltatásvégző aktívvá válik, és a későbbi alkalmazáslátogatásokhoz lesz felhasználva. A régi szolgáltatás worker és gyorsítótára törlésre kerül.
• Ha a folyamat nem fejeződik be sikeresen, az új szolgáltatási munkaerő példányát elveti a rendszer. A frissítési folyamat újra megkísérlése a felhasználó következő látogatásán történik, amikor remélhetőleg az ügyfél jobb hálózati kapcsolattal rendelkezik, amely képes teljesíteni a kéréseket.

A folyamat testreszabása a szolgáltatásmunkás logikájának módosításával. Az előző viselkedések egyike sem sajátja Blazor-nek, hanem csupán a PWA sablon opció által biztosított alapértelmezett élmény része. További információ: MDN webes dokumentumok: Service Worker API.

A kérelmek megoldása

A Gyorsítótár–első beolvasás stratégia szakaszban leírtak szerint az alapértelmezett szolgáltatásvégző egy gyorsítótár-első stratégiát használ, ami azt jelenti, hogy a gyorsítótárazott tartalmat próbálja kiszolgálni, ha elérhető. Ha egy adott URL-címhez nincs gyorsítótárazott tartalom, például amikor adatokat kér egy háttér API-ból, a szolgáltatásvégző visszatér egy normál hálózati kéréshez. A hálózati kérés sikeres, ha a kiszolgáló elérhető. Ez a logika a onFetch funkcióban van megvalósítva a service-worker.published.js részeként.

Ha az alkalmazás Razor összetevői a háttérBELI API-któl származó adatok lekérésére támaszkodnak, és a hálózat elérhetetlensége miatt meghiúsult kérések esetében felhasználóbarát felhasználói élményt szeretne nyújtani, implementálja a logikát az alkalmazás összetevőin belül. Használja például a try/catch kérések köré a HttpClient .

Kiszolgáló által renderelt lapok támogatása

Gondolja át, mi történik, ha a felhasználó először egy URL-címre, például /counter az alkalmazás bármely más mélyhivatkozására navigál. Ezekben az esetekben nem a gyorsítótárazott /countertartalmat szeretné visszaadni, hanem a böngészőnek kell betöltenie a gyorsítótárazott /index.html tartalmat az Blazor WebAssembly alkalmazás elindításához. Ezeket a kezdeti kéréseket navigációs kéréseknek nevezzük, szemben a következőkkel:

• subresource képekre, stíluslapokra vagy más fájlokra vonatkozó kérések.
• fetch/XHR API-adatokra vonatkozó kérések.

Az alapértelmezett szolgáltatásvégző speciális esetlogikát tartalmaz a navigációs kérésekhez. A szolgáltatásvégző a kéréseket a kért URL-címtől függetlenül a gyorsítótárazott tartalom /index.htmlvisszaadásával oldja fel. Ez a logika a onFetch-en/ön/ban/ben belül a(z) service-worker.published.js függvényben van implementálva.

Ha az alkalmazás olyan URL-címekkel rendelkezik, amelyeknek kiszolgáló által renderelt HTML-t kell visszaadnia, és nem a gyorsítótárból kell szolgálniuk /index.html , akkor szerkesztenie kell a logikát a szolgáltatásvégzőben. Ha az összes /Identity/ tartalmazó URL-címet szokásos, csak online a kiszolgálóhoz irányuló kérésekként kell kezelni, akkor módosítsa a service-worker.published.jsonFetch logikát. Keresse meg a következő kódot:

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

Módosítsa a kódot a következőre:

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

Ha ezt nem teszi meg, akkor a hálózati kapcsolattól függetlenül a szolgáltatási munkás elfogja az ilyen URL-címekre irányuló kéréseket, és /index.html segítségével oldja fel őket.

Adjon hozzá további végpontokat a külső hitelesítésszolgáltatókhoz az ellenőrzéshez. Az alábbi példában /signin-google a Google-hitelesítést a rendszer hozzáadja az ellenőrzéshez:

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

Nincs szükség műveletre a Development környezethez, ahol a rendszer mindig lekéri a tartalmat a hálózatról.

Eszköz gyorsítótárazásának vezérlése

Ha a projekt definiálja az ServiceWorkerAssetsManifest MSBuild tulajdonságot, a Blazor fordító eszköz létrehoz egy szolgáltatásmunkás eszközök jegyzékét a megadott névvel. Az alapértelmezett PWA-sablon létrehoz egy projektfájlt, amely a következő tulajdonságot tartalmazza:

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

A fájl a wwwroot kimeneti könyvtárba kerül, így a böngésző a kéréssel /service-worker-assets.jslekérheti a fájlt. A fájl tartalmának megtekintéséhez nyisson meg /bin/Debug/{TARGET FRAMEWORK}/wwwroot/service-worker-assets.js egy szövegszerkesztőben. Ne szerkessze azonban a fájlt, mert minden builden újragenerálva van.

A manifeszt felsorolja:

• Az offline működéshez szükséges minden Blazorfelügyelt erőforrás, például a .NET-szerelvények és a .NET WebAssembly futtatókörnyezet fájljai.
• Az alkalmazás könyvtárában wwwroot való közzétételhez szükséges összes erőforrás, például képek, stíluslapok és JavaScript-fájlok, beleértve a külső projektek és NuGet-csomagok által biztosított statikus webes objektumokat is.

A szolgáltatási dolgozóban lévő logika szerkesztésével szabályozhatja, hogy ezek közül az erőforrások közül melyiket tölti le és tárolja a gyorsítótárban a szolgáltatási dolgozó onInstallservice-worker.published.js. A szervizmunkás lekéri és gyorsítótárazza a tipikus webfájlnévkiterjesztéseknek megfelelő fájlokat, például .html, .css, .js és .wasm, valamint az adott Blazor WebAssembly fájltípusokat, például a .pdb fájlokat (az összes verziót) és a .dll fájlokat (ASP.NET Core fájlok a .NET 7-ben vagy korábbi verziókban).

Ha olyan további erőforrásokat szeretne felvenni, amelyek nem szerepelnek az alkalmazás wwwroot könyvtárában, adjon meg további MSBuild ItemGroup bejegyzéseket az alábbi példában látható módon:

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

A AssetUrl metaadatok azt az alap relatív URL-címet határozzák meg, amelyet a böngészőnek használnia kell az erőforrás gyorsítótárba való lekéréséhez. Ez független lehet a lemez eredeti forrásfájlnevétől.

Fontos

Ha hozzáad egy ServiceWorkerAssetsManifestItem, az nem okozza azt, hogy a fájl közzététele az alkalmazás wwwroot könyvtárában történjék. A közzétételi kimenetet külön kell szabályozni. Csak ServiceWorkerAssetsManifestItem egy további bejegyzés jelenik meg a szolgáltatás-feldolgozó eszközeinek jegyzékében.

Push értesítések

Mint minden más PWA, a Blazor WebAssembly PWA is fogadhat leküldéses értesítéseket egy háttérkiszolgálóról. A kiszolgáló bármikor küldhet leküldéses értesítéseket, még akkor is, ha a felhasználó nem használja aktívan az alkalmazást. Például push értesítések küldhetők, ha egy másik felhasználó végrehajt egy releváns műveletet.

Az offline PWA-kra vonatkozó korlátozások

Nem minden alkalmazásnak kell támogatnia az offline használatot. Az offline támogatás jelentősen összetettebbé teszi a szolgáltatást, de nem mindig releváns a szükséges használati esetekhez.

Az offline támogatás általában csak az alábbiakra vonatkozik:

• Ha az elsődleges adattár helyi a böngészőben. A megközelítés például egy olyan IoT-eszköz felhasználói felületével rendelkező alkalmazásban releváns, amely adatokat tárol az localStorage.
• Ha az alkalmazás jelentős mennyiségű munkát végez az egyes felhasználók számára releváns háttér API-adatok lekérése és gyorsítótárazása érdekében, hogy offline módban navigáljanak az adatok között. Ha az alkalmazásnak támogatnia kell a szerkesztést, létre kell építeni egy rendszert a változások követésére és az adatok háttérrendszerrel való szinkronizálására.
• Ha a cél annak biztosítása, hogy az alkalmazás a hálózati feltételektől függetlenül azonnal betöltődjön. Megfelelő felhasználói élményt valósíthat meg a háttér API-kérések körül, hogy megjelenítse a kérések előrehaladását, és zökkenőmentesen viselkedjen, ha a kérések a hálózat elérhetetlensége miatt meghiúsulnak.

Emellett az offline képességű PWA-knak számos további komplikációval kell megbirkózniuk. A fejlesztőknek alaposan meg kell ismerkedniük a következő szakaszokban ismertetett kikötésekkel.

Offline támogatás csak a közzététel után

A fejlesztés során általában minden módosítás azonnal megjelenik a böngészőben anélkül, hogy háttérfrissítési folyamaton haladna végig. Ezért a BlazorPWA-sablon csak közzétételkor teszi lehetővé az offline támogatást.

Offline képes alkalmazás létrehozásakor nem elegendő az alkalmazás tesztelése a Development környezetben. Tesztelnie kell az alkalmazást a közzétett állapotában, hogy megértse, hogyan reagál a különböző hálózati feltételekre.

Frissítés befejezése a felhasználó alkalmazáson kívülre történő navigálását követően

A frissítések mindaddig nem fejeződnek be, amíg a felhasználó el nem navigál az alkalmazástól az összes lapon. A Háttérfrissítések szakaszban leírtak szerint, miután telepített egy frissítést az alkalmazásban, a böngésző lekéri a frissített szolgáltatásvégző fájlokat a frissítési folyamat megkezdéséhez.

Ami sok fejlesztőt meglep, hogy még a frissítés befejezésekor sem lép érvénybe, amíg a felhasználó el nem navigál az összes lapon. Nem elegendő frissíteni az alkalmazást megjelenítő lapot, még akkor sem, ha ez az egyetlen lap, amely az alkalmazást jeleníti meg. Amíg az alkalmazás teljesen be nem záródik, az új szolgáltatásvégző továbbra is várakozik az aktiválási állapotra . Ez nem a Blazor sajátossága, hanem a webplatform szokásos viselkedése.

Ez gyakran problémákat okoz a fejlesztőknek, akik megpróbálják tesztelni a szolgáltatásvégző vagy az offline gyorsítótárazott erőforrások frissítéseit. Ha bejelentkezik a böngésző fejlesztői eszközeibe, az alábbihoz hasonlót láthat:

Mindaddig, amíg az alkalmazást megjelenítő lapok vagy ablakok "ügyfelek" listája nem üres, a munkás továbbra is várakozik. Ezt azért teszik a szervizmunkások, hogy garantálják a konzisztenciát. A konzisztencia azt jelenti, hogy a rendszer minden erőforrást ugyanabból az atomi gyorsítótárból hív le.

A módosítások tesztelésekor célszerű lehet kiválasztani a "skipWaiting" hivatkozást az előző képernyőképen látható módon, majd újra betölteni a lapot. Ezt az összes felhasználó számára automatizálhatja úgy, hogy a szolgáltatásvégző kódolásával kihagyja a "várakozás" fázist, és azonnal aktiválódik a frissítéskor. Ha kihagyja a várakozási fázist, lemond arról a garanciáról, hogy az erőforrások mindig következetesen legyenek lekérve ugyanabból a gyorsítótárpéldányból.

A felhasználók az alkalmazás bármely előzményverzióját futtathatják

A webfejlesztők általában arra számítanak, hogy a felhasználók csak a webalkalmazás legújabb telepített verzióját futtatják, mivel ez a hagyományos webterjesztési modellben megszokott. Az offline-első PWA azonban inkább egy natív mobilalkalmazáshoz hasonlít, ahol a felhasználók nem feltétlenül a legújabb verziót futtatják.

A Háttérfrissítések szakaszban leírtak szerint, miután telepített egy frissítést az alkalmazásban, minden meglévő felhasználó továbbra is egy korábbi verziót használ legalább egy további látogatáshoz, mert a frissítés a háttérben történik, és nem aktiválódik, amíg a felhasználó el nem lép. Ráadásul a használt korábbi verzió nem feltétlenül az előző, amelyet üzembe helyezett. Az előző verzió bármilyen korábbi verzió lehet, attól függően, hogy a felhasználó mikor végzett utoljára frissítést.

Ez akkor lehet probléma, ha az alkalmazás előtér- és háttérrendszer-részeinek meg kell egyezniük az API-kérések sémájáról. Nem helyezhet üzembe visszamenőlegesen inkompatibilis API-sémamódosításokat, amíg nem biztos abban, hogy az összes felhasználó frissítve lett. Azt is megteheti, hogy letiltja a felhasználók számára az alkalmazás nem kompatibilis régebbi verzióit. Ez a forgatókönyv követelmény ugyanaz, mint a natív mobilalkalmazások esetében. Ha változást vezet be, amely megszakítja a kompatibilitást a szerver API-kban, a kliensalkalmazás megszakad azoknál a felhasználóknál, akik még nem frissítették.

Ha lehetséges, ne helyezzen üzembe kompatibilitástörő módosításokat a háttérbeli API-kban. Ha ezt meg kell tennie, fontolja meg a standard Service Worker API-k, például a ServiceWorkerRegistration használatát annak megállapítására, hogy az alkalmazás naprakész-e, és ha nem, annak használatának megakadályozására.

Interferencia kiszolgáló által renderelt oldalakkal

A támogatási kiszolgáló által renderelt lapok szakaszban leírtaknak megfelelően, ha meg szeretné kerülni a szolgáltatásvégző viselkedését, amely szerint minden navigációs kérés tartalmának visszaadása /index.html történik, szerkessze a logikát a szolgáltatásvégzőben.

A szolgáltatási munkás összes eszközjegyzéke gyorsítótárazott.

A Control eszköz gyorsítótárazási szakaszában leírtak szerint a fájl service-worker-assets.js a buildelés során jön létre, és felsorolja az összes olyan eszközt, amelyet a szolgáltatásvégzőnek le kell kérnie és gyorsítótáraznia.

Mivel ez a lista mindent tartalmaz, ami a(z) wwwroot-hez kibocsátásra kerül, beleértve a külső csomagok és projektek által biztosított tartalmakat is, ügyeljen arra, hogy ne helyezzen oda túl sok tartalmat. Ha a wwwroot címtár több millió lemezképet tartalmaz, a szolgáltatásvégző megpróbálja lekérni és gyorsítótárazza az összeset, túlzott sávszélességet használva, és valószínűleg nem fejeződik be sikeresen.

Tetszőleges logika alkalmazásával szabályozza, hogy a jegyzékfájl tartalmának mely részhalmazát kell beolvasni és gyorsítótárazni a(z) onInstall fájlban a service-worker.published.js függvényt szerkesztve.

Interakció a hitelesítéssel

A PWA-sablon a hitelesítéssel együtt használható. Az offline képességű PWA akkor is támogatja a hitelesítést, ha a felhasználó kezdeti hálózati kapcsolattal rendelkezik.

Ha egy felhasználó nem rendelkezik hálózati kapcsolattal, nem tudja hitelesíteni vagy beszerezni a hozzáférési jogkivonatokat. Ha hálózati hozzáférés nélkül próbál meg a bejelentkezési oldalt felkeresni, az "hálózati hiba" üzenetet eredményez. Olyan felhasználói felületi folyamatot kell megterveznie, amely lehetővé teszi, hogy a felhasználó offline állapotban hasznos feladatokat végezzen anélkül, hogy megkísérli hitelesíteni a felhasználót, vagy hozzáférési jogkivonatokat szerez be. Másik lehetőségként úgy is megtervezheti az alkalmazást, hogy kecsesen meghiúsuljon, ha a hálózat nem érhető el. Ha az alkalmazás nem tervezhető ezeknek a forgatókönyveknek a kezelésére, előfordulhat, hogy nem szeretné engedélyezni az offline támogatást.

Ha egy online és offline használatra tervezett alkalmazás ismét online állapotban van:

• Előfordulhat, hogy az alkalmazásnak ki kell építenie egy új hozzáférési jogkivonatot.
• Az alkalmazásnak észlelnie kell, hogy egy másik felhasználó van-e bejelentkezve a szolgáltatásba, hogy az a felhasználó offline állapotában létrehozott fiókjára alkalmazza a műveleteket.

Hitelesítést használó offline PWA-alkalmazás létrehozása:

• Cserélje le a AccountClaimsPrincipalFactory<TAccount> egy olyan gyárra, amely az utolsó bejelentkezett felhasználót tárolja, és a tárolt felhasználót használja, amikor az alkalmazás offline.
• Helyezze sorba a műveleteket, amíg az alkalmazás offline állapotban van, és alkalmazza őket, amikor az alkalmazás online állapotba kerül.
• Kijelentkezéskor törölje a tárolt felhasználót.

A CarChecker mintaalkalmazás az előző megközelítéseket mutatja be. Tekintse meg az alkalmazás alábbi részeit:

• OfflineAccountClaimsPrincipalFactory (Client/Data/OfflineAccountClaimsPrincipalFactory.cs)
• LocalVehiclesStore (Client/Data/LocalVehiclesStore.cs)
• LoginStatus összetevő (Client/Shared/LoginStatus.razor)

További erőforrások

ügyféloldali SignalR kereszt-eredetű tárgyalás hitelesítéshez