Översikt över Windows Push Notification Services (WNS)

Med Windows Push Notification Services (WNS) kan tredjepartsutvecklare skicka popup-, panel-, märkes- och råuppdateringar från sin egen molntjänst. Detta ger en mekanism för att leverera nya uppdateringar till dina användare på ett energieffektivt och tillförlitligt sätt.

Så här fungerar det

Följande diagram visar det fullständiga dataflödet för att skicka ett push-meddelande. Det omfattar följande steg:

1. Din app begär en push-meddelandekanal från WNS.
2. Windows ber WNS att skapa en meddelandekanal. Den här kanalen returneras till den anropande enheten i form av en URI (Uniform Resource Identifier).
3. URI:n för meddelandekanalen returneras av WNS till din app.
4. Din app skickar URI:n till din egen molntjänst. Sedan lagrar du URI:n i din egen molntjänst så att du kan komma åt URI:n när du skickar meddelanden. URI:n är ett gränssnitt mellan din egen app och din egen tjänst. det är ditt ansvar att implementera det här gränssnittet med säkra och säkra webbstandarder.
5. När molntjänsten har en uppdatering att skicka meddelar den WNS med hjälp av kanal-URI:n. Detta görs genom att utfärda en HTTP POST-begäran, inklusive aviseringsnyttolasten, via Secure Sockets Layer (SSL). Det här steget kräver autentisering.
6. WNS tar emot begäran och dirigerar meddelandet till lämplig enhet.

Registrera din app och ta emot autentiseringsuppgifterna för din molntjänst

Innan du kan skicka meddelanden med WNS måste din app registreras i Store-konsolen, enligt beskrivningen här.

Begära en meddelandekanal

När en app som kan ta emot push-meddelanden körs måste den först begära en meddelandekanal via CreatePushNotificationChannelForApplicationAsync. En fullständig diskussion och exempelkod finns i Så här begär, skapar och sparar du en meddelandekanal. Det här API:et returnerar en kanal-URI som är unikt länkad till det anropande programmet och dess panel, och genom vilken alla meddelandetyper kan skickas.

När appen har skapat en kanal-URI skickar den den till sin molntjänst, tillsammans med alla appspecifika metadata som ska associeras med den här URI:n.

Viktiga anteckningar

• Vi garanterar inte att meddelandekanalens URI för en app alltid förblir densamma. Vi rekommenderar att appen begär en ny kanal varje gång den körs och uppdaterar sin tjänst när URI:n ändras. Utvecklaren bör aldrig ändra kanal-URI:n och bör betrakta den som en svart lådsträng. För närvarande upphör kanal-URI:er att gälla efter 30 dagar. Om din Windows 10-app förnyar sin kanal regelbundet i bakgrunden kan du ladda ned exemplet på push- och periodiska meddelanden för Windows 8.1 och återanvända dess källkod och/eller mönstret det demonstrerar.
• Gränssnittet mellan molntjänsten och klientappen implementeras av dig, utvecklaren. Vi rekommenderar att appen går igenom en autentiseringsprocess med sin egen tjänst och överför data via ett säkert protokoll, till exempel HTTPS.
• Det är viktigt att molntjänsten alltid ser till att kanal-URI:n använder domänen "notify.windows.com". Tjänsten bör aldrig skicka meddelanden till en kanal på någon annan domän. Om återanropet någonsin komprometteras för din app, kan en angripare skicka en kanal-URI för att imitera WNS. Utan att inspektera domänen kan molntjänsten potentiellt avslöja information till angriparen omedvetet. Underdomänen för kanal-URI:n kan komma att ändras och bör inte beaktas när kanal-URI:n verifieras.
• Om molntjänsten försöker leverera ett meddelande till en kanal som har upphört att gälla returnerar WNS svarskod 410. Som svar på den koden bör tjänsten inte längre försöka skicka meddelanden till den URI:n.

Autentisera din molntjänst

Om du vill skicka ett meddelande måste molntjänsten autentiseras via WNS. Det första steget i den här processen inträffar när du registrerar din app med Microsoft Store-instrumentpanelen. Under registreringsprocessen får din app en paketsäkerhetsidentifierare (SID) och en hemlig nyckel. Den här informationen används av molntjänsten för att autentisera med WNS.

WNS-autentiseringsschemat implementeras med hjälp av profilen för klientautentiseringsuppgifter från OAuth 2.0-protokollet . Molntjänsten autentiserar med WNS genom att ange sina autentiseringsuppgifter (paket-SID och hemlig nyckel). I gengäld får den en åtkomsttoken. Med den här åtkomsttoken kan en molntjänst skicka ett meddelande. Token krävs för varje meddelandebegäran som skickas till WNS.

På hög nivå är informationskedjan följande:

1. Molntjänsten skickar sina autentiseringsuppgifter till WNS via HTTPS enligt OAuth 2.0-protokollet. Detta autentiserar tjänsten med WNS.
2. WNS returnerar en åtkomsttoken om autentiseringen lyckades. Den här åtkomsttoken används i alla efterföljande meddelandebegäranden tills den upphör att gälla.

I autentiseringen med WNS skickar molntjänsten en HTTP-begäran via SSL (Secure Sockets Layer). Parametrarna anges i formatet "application/x-www-for-urlencoded". Ange ditt paket-SID i fältet "client_id" och din hemliga nyckel i fältet "client_secret" enligt följande exempel. Syntaxinformation finns i referensen för begäran om åtkomsttoken .

 POST /accesstoken.srf HTTP/1.1
 Content-Type: application/x-www-form-urlencoded
 Host: https://login.live.com
 Content-Length: 211
 
 grant_type=client_credentials&client_id=ms-app%3a%2f%2fS-1-15-2-2972962901-2322836549-3722629029-1345238579-3987825745-2155616079-650196962&client_secret=Vex8L9WOFZuj95euaLrvSH7XyoDhLJc7&scope=notify.windows.com

WNS autentiserar molntjänsten och skickar, om det lyckas, ett svar på "200 OK". Åtkomsttoken returneras i parametrarna som ingår i http-svarets brödtext med medietypen "application/json". När din tjänst har tagit emot åtkomsttoken är du redo att skicka meddelanden.

I följande exempel visas ett lyckat autentiseringssvar, inklusive åtkomsttoken. Syntaxinformation finns i push-meddelandetjänstens begäran och svarshuvuden.

 HTTP/1.1 200 OK   
 Cache-Control: no-store
 Content-Length: 422
 Content-Type: application/json
 
 {
     "access_token":"EgAcAQMAAAAALYAAY/c+Huwi3Fv4Ck10UrKNmtxRO6Njk2MgA=", 
     "token_type":"bearer"
 }

Viktiga anteckningar

• OAuth 2.0-protokollet som stöds i den här proceduren följer utkastversion V16.
• OAuth Request for Comments (RFC) använder termen "klient" för att referera till molntjänsten.
• Det kan finnas ändringar i den här proceduren när OAuth-utkastet har slutförts.
• Åtkomsttoken kan återanvändas för flera meddelandebegäranden. Detta gör att molntjänsten bara kan autentisera en gång för att skicka många meddelanden. Men när åtkomsttoken upphör att gälla måste molntjänsten autentiseras igen för att ta emot en ny åtkomsttoken.

Skicka ett meddelande

Med hjälp av kanal-URI:n kan molntjänsten skicka ett meddelande när den har en uppdatering för användaren.

Åtkomsttoken som beskrivs ovan kan återanvändas för flera meddelandebegäranden. molnservern krävs inte för att begära en ny åtkomsttoken för varje meddelande. Om åtkomsttoken har upphört att gälla returnerar meddelandebegäran ett fel. Vi rekommenderar att du inte försöker skicka meddelandet igen mer än en gång om åtkomsttoken avvisas. Om det här felet uppstår måste du begära en ny åtkomsttoken och skicka meddelandet igen. Den exakta felkoden finns i Svarskoder för push-meddelanden.

1. Molntjänsten gör en HTTP POST till kanal-URI:n. Den här begäran måste göras via SSL och innehåller nödvändiga rubriker och nyttolasten för meddelanden. Auktoriseringshuvudet måste innehålla den förvärvade åtkomsttoken för auktorisering.

   En exempelbegäran visas här. Syntaxinformation finns i Svarskoder för push-meddelanden.

   Mer information om hur du skapar aviseringsnyttolasten finns i Snabbstart: Skicka ett push-meddelande. Nyttolasten för ett push-meddelande för paneler, popup-fönster eller märken tillhandahålls som XML-innehåll som följer deras respektive definierade schema för anpassningsbara paneler eller schema för äldre paneler. Nyttolasten för ett rått meddelande har inte någon angiven struktur. Den är strikt appdefinierad.

    POST https://cloud.notify.windows.com/?token=AQE%bU%2fSjZOCvRjjpILow%3d%3d HTTP/1.1
    Content-Type: text/xml
    X-WNS-Type: wns/tile
    Authorization: Bearer EgAcAQMAAAAALYAAY/c+Huwi3Fv4Ck10UrKNmtxRO6Njk2MgA=
    Host: cloud.notify.windows.com
    Content-Length: 24
   
    <body>
    ....
   

2. WNS svarar för att ange att meddelandet har tagits emot och kommer att levereras vid nästa tillgängliga tillfälle. WNS ger dock ingen bekräftelse från slutpunkt till slutpunkt om att ditt meddelande har tagits emot av enheten eller programmet.

Det här diagrammet illustrerar dataflödet:

Viktiga anteckningar

• WNS garanterar inte tillförlitligheten eller svarstiden för ett meddelande.
• Meddelanden bör aldrig innehålla konfidentiella, känsliga eller personliga data.
• För att skicka ett meddelande måste molntjänsten först autentisera med WNS och ta emot en åtkomsttoken.
• En åtkomsttoken tillåter endast att en molntjänst skickar meddelanden till den enda app som token skapades för. En åtkomsttoken kan inte användas för att skicka meddelanden i flera appar. Om molntjänsten har stöd för flera appar måste den därför tillhandahålla rätt åtkomsttoken för appen när en avisering skickas till varje kanal-URI.
• När enheten är offline lagrar WNS som standard en av varje meddelandetyp (panel, märke, popup-kod) för varje kanal-URI och inga råa meddelanden.
• I scenarier där meddelandeinnehållet är anpassat för användaren rekommenderar WNS att molntjänsten omedelbart skickar dessa uppdateringar när de tas emot. Exempel på det här scenariot är uppdateringar av sociala medier, snabbkommunikationsinbjudningar, nya meddelandemeddelanden eller aviseringar. Som ett alternativ kan du ha scenarier där samma allmänna uppdatering ofta levereras till en stor delmängd av dina användare. till exempel uppdateringar av väder, lager och nyheter. WNS-riktlinjerna anger att frekvensen för dessa uppdateringar ska vara högst en var 30:e minut. Slutanvändaren eller WNS kan fastställa att mer frekventa rutinuppdateringar är missbrukande.
• Windows Notification Platform upprätthåller en periodisk dataanslutning med WNS för att hålla socketen vid liv och felfri. Om det inte finns några program som begär eller använder meddelandekanaler skapas inte socketen.

Förfallodatum för panel- och märkesmeddelanden

Som standard upphör panel- och märkesmeddelanden att gälla tre dagar efter att de har laddats ned. När ett meddelande upphör att gälla tas innehållet bort från panelen eller kön och visas inte längre för användaren. Det är bästa praxis att ange ett förfallodatum (med en tid som passar din app) på alla panel- och märkesmeddelanden så att panelens innehåll inte bevaras längre än vad som är relevant. En explicit förfallotid är nödvändig för innehåll med en definierad livslängd. Detta säkerställer också att inaktuellt innehåll tas bort om molntjänsten slutar skicka meddelanden, eller om användaren kopplar från nätverket under en längre period.

Molntjänsten kan ange ett förfallodatum för varje meddelande genom att ange X-WNS-TTL HTTP-huvudet för att ange den tid (i sekunder) som meddelandet förblir giltigt när det har skickats. Mer information finns i push-meddelandetjänstens begärans- och svarshuvuden.

Under en börs aktiva handelsdag kan du till exempel ange förfallodatumet för en aktiekursuppdatering till dubbelt så mycket som för ditt sändningsintervall (till exempel en timme efter mottagandet om du skickar meddelanden varje halvtimme). Som ett annat exempel kan en nyhetsapp avgöra att en dag är en lämplig förfallotid för en daglig nyhetspaneluppdatering.

Push-meddelanden och batterisparläge

Batterisparfunktionen förlänger batteritiden genom att begränsa bakgrundsaktiviteten på enheten. Med Windows 10 kan användaren ange att batterisparläge ska aktiveras automatiskt när batteriet sjunker under ett angivet tröskelvärde. När batterisparfunktionen är på inaktiveras mottagandet av push-meddelanden för att spara energi. Men det finns ett par undantag till detta. Följande inställningar för Windows 10-batterisparläge (finns i Windows-inställningar) gör att appen kan ta emot push-meddelanden även när batterisparfunktionen är på.

• Tillåt push-meddelanden från valfri app när du är i batterisparläge: Med den här inställningen kan alla appar ta emot push-meddelanden medan batterisparfunktionen är på. Observera att den här inställningen endast gäller för Windows 10 för skrivbordsversioner (Home, Pro, Enterprise och Education).
• Tillåts alltid: Med den här inställningen kan specifika appar köras i bakgrunden medan batterisparfunktionen är på , inklusive att ta emot push-meddelanden. Den här listan underhålls manuellt av användaren.

Det går inte att kontrollera tillståndet för de här två inställningarna, men du kan kontrollera batterisparläget. I Windows 10 använder du egenskapen EnergySaverStatus för att kontrollera batterispartillståndet. Din app kan också använda händelsen EnergySaverStatusChanged för att lyssna efter ändringar i batterisparfunktionen.

Om din app är starkt beroende av push-meddelanden rekommenderar vi att du meddelar användarna att de kanske inte får aviseringar medan batterisparfunktionen är på och gör det enkelt för dem att justera inställningarna för batterisparfunktioner. Med hjälp av URI-schemat för batterisparinställningar i Windows ms-settings:batterysaver-settingskan du tillhandahålla en praktisk länk till Windows-inställningar.

Här är ett exempel på hur du kontrollerar om batterisparfunktionen är aktiverad i Windows 10. Det här exemplet meddelar användaren och startar Inställningar för batterisparinställningar. dontAskAgainSetting Låter användaren ignorera meddelandet om de inte vill bli meddelad igen.

using System;
using Windows.UI.Xaml;
using Windows.UI.Xaml.Controls;
using Windows.UI.Xaml.Navigation;
using Windows.System;
using Windows.System.Power;
...
...
async public void CheckForEnergySaving()
{
   //Get reminder preference from LocalSettings
   bool dontAskAgain;
   var localSettings = Windows.Storage.ApplicationData.Current.LocalSettings;
   object dontAskSetting = localSettings.Values["dontAskAgainSetting"];
   if (dontAskSetting == null)
   {  // Setting does not exist
      dontAskAgain = false;
   }
   else
   {  // Retrieve setting value
      dontAskAgain = Convert.ToBoolean(dontAskSetting);
   }
   
   // Check if battery saver is on and that it's okay to raise dialog
   if ((PowerManager.EnergySaverStatus == EnergySaverStatus.On)
         && (dontAskAgain == false))
   {
      // Check dialog results
      ContentDialogResult dialogResult = await saveEnergyDialog.ShowAsync();
      if (dialogResult == ContentDialogResult.Primary)
      {
         // Launch battery saver settings (settings are available only when a battery is present)
         await Launcher.LaunchUriAsync(new Uri("ms-settings:batterysaver-settings"));
      }

      // Save reminder preference
      if (dontAskAgainBox.IsChecked == true)
      {  // Don't raise dialog again
         localSettings.Values["dontAskAgainSetting"] = "true";
      }
   }
}

#include <winrt/Windows.Foundation.h>
#include <winrt/Windows.Storage.h>
#include <winrt/Windows.System.h>
#include <winrt/Windows.System.Power.h>
#include <winrt/Windows.UI.Xaml.h>
#include <winrt/Windows.UI.Xaml.Controls.h>
#include <winrt/Windows.UI.Xaml.Navigation.h>
using namespace winrt;
using namespace winrt::Windows::Foundation;
using namespace winrt::Windows::Storage;
using namespace winrt::Windows::System;
using namespace winrt::Windows::System::Power;
using namespace winrt::Windows::UI::Xaml;
using namespace winrt::Windows::UI::Xaml::Controls;
using namespace winrt::Windows::UI::Xaml::Navigation;
...
winrt::fire_and_forget CheckForEnergySaving()
{
    // Get reminder preference from LocalSettings.
    bool dontAskAgain{ false };
    auto localSettings = ApplicationData::Current().LocalSettings();
    IInspectable dontAskSetting = localSettings.Values().Lookup(L"dontAskAgainSetting");
    if (!dontAskSetting)
    {
        // Setting doesn't exist.
        dontAskAgain = false;
    }
    else
    {
        // Retrieve setting value
        dontAskAgain = winrt::unbox_value<bool>(dontAskSetting);
    }

    // Check whether battery saver is on, and whether it's okay to raise dialog.
    if ((PowerManager::EnergySaverStatus() == EnergySaverStatus::On) && (!dontAskAgain))
    {
        // Check dialog results.
        ContentDialogResult dialogResult = co_await saveEnergyDialog().ShowAsync();
        if (dialogResult == ContentDialogResult::Primary)
        {
            // Launch battery saver settings
            // (settings are available only when a battery is present).
            co_await Launcher::LaunchUriAsync(Uri(L"ms-settings:batterysaver-settings"));
        }

        // Save reminder preference.
        if (dontAskAgainBox().IsChecked())
        {
            // Don't raise the dialog again.
            localSettings.Values().Insert(L"dontAskAgainSetting", winrt::box_value(true));
        }
    }
}

Det här är XAML för ContentDialog som visas i det här exemplet.

<ContentDialog x:Name="saveEnergyDialog"
               PrimaryButtonText="Open battery saver settings"
               SecondaryButtonText="Ignore"
               Title="Battery saver is on."> 
   <StackPanel>
      <TextBlock TextWrapping="WrapWholeWords">
         <LineBreak/><Run>Battery saver is on and you may 
          not receive push notifications.</Run><LineBreak/>
         <LineBreak/><Run>You can choose to allow this app to work normally
         while in battery saver, including receiving push notifications.</Run>
         <LineBreak/>
      </TextBlock>
      <CheckBox x:Name="dontAskAgainBox" Content="OK, got it."/>
   </StackPanel>
</ContentDialog>

Relaterade ämnen

• Skicka en lokal tile-avisering
• Snabbstart: Skicka ett push-meddelande
• Så här uppdaterar du ett märke via push-meddelanden
• Så här begär, skapar och sparar du en meddelandekanal
• Så här intercepterar du notiser för körande applikationer
• Autentisera med Windows Push Notification Service (WNS)
• Push-meddelandetjänstens begäran och svarsrubriker
• Riktlinjer och checklista för push-meddelanden
• Råa meddelanden