Übersicht über die Windows-Pushbenachrichtigungsdienste (Windows Push Notification Services, WNS)

Die Windows-Pushbenachrichtigungsdienste (Windows Push Notification Services, WNS) ermöglichen es Drittanbieterentwicklern, Toast-, Kachel-, Signal- und unformatierte Updates von ihrem eigenen Clouddienst zu senden. Dies bietet einen Mechanismus zum Bereitstellen neuer Updates für Ihre Benutzer auf effiziente und zuverlässige Weise.

Funktionsweise

Das folgende Diagramm zeigt den vollständigen Datenfluss zum Senden einer Pushbenachrichtigung. Dazu gehören die folgenden Schritte:

1. Ihre App fordert einen Push-Benachrichtigungskanal von WNS an.
2. Windows fordert WNS auf, einen Benachrichtigungskanal zu erstellen. Dieser Kanal wird in Form eines URI (Uniform Resource Identifier) an das aufrufende Gerät zurückgegeben.
3. Der URI des Benachrichtigungskanals wird von WNS an Ihre App zurückgegeben.
4. Ihre App sendet den URI an Ihren eigenen Clouddienst. Anschließend speichern Sie den URI in Ihrem eigenen Clouddienst, damit Sie beim Senden von Benachrichtigungen auf den URI zugreifen können. Der URI ist eine Schnittstelle zwischen Ihrer eigenen App und Ihrem eigenen Dienst. Es liegt in Ihrer Verantwortung, diese Schnittstelle mit sicheren und sicheren Webstandards zu implementieren.
5. Wenn Ihr Clouddienst ein Update senden muss, benachrichtigt er WNS mithilfe der Kanal-URL. Dazu wird eine HTTP POST-Anforderung gesendet, einschließlich des Payloads der Benachrichtigung, über Secure Sockets Layer (SSL). Für diesen Schritt ist eine Authentifizierung erforderlich.
6. WNS empfängt die Anforderung und leitet die Benachrichtigung an das entsprechende Gerät weiter.

Registrieren Ihrer App und Empfangen der Anmeldeinformationen für Ihren Clouddienst

Bevor Sie Benachrichtigungen mit WNS senden können, muss Ihre App im Store-Dashboard registriert werden, wie hier beschrieben.

Anfordern eines Benachrichtigungskanals

Wenn eine App, die Push-Benachrichtigungen empfangen kann, ausgeführt wird, muss sie zuerst über die CreatePushNotificationChannelForApplicationAsynceinen Benachrichtigungskanal anfordern. Eine vollständige Diskussion und ein Beispielcode finden Sie unter "Anfordern, Erstellen und Speichern eines Benachrichtigungskanals". Diese API gibt einen Kanal-URI zurück, der eindeutig mit der aufrufenden Anwendung und deren Kachel verknüpft ist und über den alle Benachrichtigungstypen gesendet werden können.

Nachdem die App erfolgreich einen Kanal-URI erstellt hat, sendet sie ihn zusammen mit allen App-spezifischen Metadaten, die diesem URI zugeordnet werden sollen, an seinen Clouddienst.

Wichtige Hinweise

• Wir garantieren nicht, dass der Benachrichtigungskanal-URI für eine App immer gleich bleibt. Wir empfehlen, dass die App bei jeder Ausführung einen neuen Kanal anfordert und den Dienst aktualisiert, wenn sich der URI ändert. Der Entwickler sollte den Kanal-URI niemals ändern und als Blackbox-Zeichenfolge betrachten. Derzeit laufen Kanal-URIs nach 30 Tagen ab. Wenn Ihre Windows 10-App ihren Kanal im Hintergrund in regelmäßigen Abständen aktualisiert, können Sie das Beispiel für Push-Benachrichtigungen und periodische Benachrichtigungen für Windows 8.1 herunterladen und den Quellcode und/oder das darin veranschaulichte Muster wiederverwenden.
• Die Schnittstelle zwischen dem Clouddienst und der Client-App wird von Ihnen, dem Entwickler, implementiert. Es wird empfohlen, dass die App einen Authentifizierungsprozess mit eigenem Dienst durchläuft und Daten über ein sicheres Protokoll wie HTTPS überträgt.
• Es ist wichtig, dass der Clouddienst immer sicherstellt, dass der Kanal-URI die Domäne "notify.windows.com" verwendet. Der Dienst sollte niemals Pushbenachrichtigungen an einen Kanal in einer anderen Domäne senden. Wenn der Rückruf für Ihre App jemals kompromittiert wird, könnte ein böswilliger Angreifer einen Kanal-URI einreichen, um WNS zu täuschen. Ohne überprüfung der Domäne könnte Ihr Clouddienst möglicherweise Informationen an diesen Angreifer unwissentlich offenlegen. Die Unterdomäne der Kanal-URI unterliegt möglichen Änderungen und sollte beim Überprüfen der Kanal-URI nicht berücksichtigt werden.
• Wenn Ihr Clouddienst versucht, eine Benachrichtigung an einen abgelaufenen Kanal zu übermitteln, gibt WNS Antwortcode 410zurück. Als Reaktion auf diesen Code sollte Ihr Dienst nicht mehr versuchen, Benachrichtigungen an diesen URI zu senden.

Authentifizieren Ihres Clouddiensts

Zum Senden einer Benachrichtigung muss der Clouddienst über WNS authentifiziert werden. Der erste Schritt in diesem Prozess tritt auf, wenn Sie Ihre App beim Microsoft Store-Dashboard registrieren. Während des Registrierungsprozesses erhält Ihre App eine Paketsicherheits-ID (Package Security Identifier, SID) und einen geheimen Schlüssel. Diese Informationen werden von Ihrem Clouddienst verwendet, um sich bei WNS zu authentifizieren.

Das WNS-Authentifizierungsschema wird mithilfe des Clientanmeldeinformationsprofils aus dem OAuth 2.0--Protokoll implementiert. Der Clouddienst authentifiziert sich mit WNS, indem er seine Anmeldeinformationen (Paket-SID und geheimer Schlüssel) bereitstellt. Im Gegenzug empfängt es ein Zugriffstoken. Dieses Zugriffstoken ermöglicht es einem Clouddienst, eine Benachrichtigung zu senden. Das Token ist bei jeder an den WNS gesendeten Benachrichtigungsanforderung erforderlich.

Auf hoher Ebene ist die Informationskette wie folgt:

1. Der Clouddienst sendet seine Anmeldeinformationen über HTTPS nach dem OAuth 2.0-Protokoll an WNS. Dadurch wird der Dienst mit WNS authentifiziert.
2. WNS gibt ein Zugriffstoken zurück, wenn die Authentifizierung erfolgreich war. Dieses Zugriffstoken wird in allen nachfolgenden Benachrichtigungsanforderungen verwendet, bis es abläuft.

Bei der Authentifizierung mit WNS sendet der Clouddienst eine HTTP-Anforderung über Secure Sockets Layer (SSL). Die Parameter werden im Format "application/x-www-for-urlencoded" angegeben. Geben Sie die Paket-SID im Feld "client_id" und den geheimen Schlüssel im Feld "client_secret" an, wie im folgenden Beispiel gezeigt. Ausführliche Informationen zur Syntax finden Sie in der Zugriffstokenanforderung Referenz.

 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 authentifiziert den Cloud-Dienst und sendet bei Erfolg eine Antwort von "200 OK". Das Zugriffstoken wird in den Parametern zurückgegeben, die im Textkörper der HTTP-Antwort enthalten sind, wobei der Medientyp "application/json" verwendet wird. Nachdem Ihr Dienst das Zugriffstoken erhalten hat, können Sie Benachrichtigungen senden.

Das folgende Beispiel zeigt eine erfolgreiche Authentifizierungsantwort, einschließlich des Zugriffstokens. Ausführliche Informationen zur Syntax finden Sie unter Anforderungs- und Antwortheader des Pushbenachrichtigungsdiensts.

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

Wichtige Hinweise

• Das in diesem Verfahren unterstützte OAuth 2.0-Protokoll folgt der Entwurfsversion V16.
• Die OAuth-Anforderung für Kommentare (RFC) verwendet den Begriff "Client", um auf den Clouddienst zu verweisen.
• Möglicherweise gibt es Änderungen an diesem Verfahren, wenn der OAuth-Entwurf abgeschlossen ist.
• Das Zugriffstoken kann für mehrere Benachrichtigungsanforderungen wiederverwendet werden. Dadurch kann sich der Clouddienst nur einmal authentifizieren, um viele Benachrichtigungen zu senden. Wenn das Zugriffstoken jedoch abläuft, muss sich der Clouddienst erneut authentifizieren, um ein neues Zugriffstoken zu erhalten.

Senden einer Benachrichtigung

Mithilfe des Kanal-URI kann der Clouddienst eine Benachrichtigung senden, wenn er über ein Update für den Benutzer verfügt.

Das oben beschriebene Zugriffstoken kann für mehrere Benachrichtigungsanforderungen wiederverwendet werden; der Cloudserver muss nicht für jede Benachrichtigung ein neues Zugriffstoken anfordern. Wenn das Zugriffstoken abgelaufen ist, gibt die Benachrichtigungsanforderung einen Fehler zurück. Es wird empfohlen, dass Sie nicht mehr als einmal versuchen, Ihre Benachrichtigung erneut zu senden, wenn das Zugriffstoken abgelehnt wird. Wenn dieser Fehler auftritt, müssen Sie ein neues Zugriffstoken anfordern und die Benachrichtigung erneut senden. Den genauen Fehlercode finden Sie unter "Antwortcodes für Pushbenachrichtigungen".

1. Der Clouddienst führt einen HTTP POST an die Channel-URI aus. Diese Anforderung muss über SSL erfolgen und enthält die erforderlichen Header und die Benachrichtigungsnutzlast. Der Autorisierungsheader muss das erworbene Zugriffstoken für die Autorisierung enthalten.

   Hier wird eine Beispielanforderung gezeigt. Ausführliche Informationen zur Syntax finden Sie unter Antwortcodes für Pushbenachrichtigungen.

   Ausführliche Informationen zum Verfassen der Benachrichtigungsnutzlast finden Sie unter Schnellstart: Senden einer Pushbenachrichtigung. Die Nutzlast einer Kachel-, Toast- oder Abzeichen-Pushbenachrichtigung wird als XML-Inhalt bereitgestellt, der dem jeweils definierten Schema für adaptive Kacheln oder dem Legacy-Kachelschemaentspricht. Die Nutzlast einer rohen Benachrichtigung hat keine festgelegte Struktur. Es ist streng app-definiert.

    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 bestätigt den Empfang der Benachrichtigung und teilt mit, dass sie bei der nächsten verfügbaren Gelegenheit zugestellt wird. WNS stellt jedoch keine End-to-End-Bestätigung bereit, dass Ihre Benachrichtigung vom Gerät oder der Anwendung empfangen wurde.

Dieses Diagramm veranschaulicht den Datenfluss:

Wichtige Hinweise

• WNS garantiert nicht die Zuverlässigkeit oder Latenz einer Benachrichtigung.
• Benachrichtigungen sollten niemals vertrauliche, sensible oder personenbezogene Daten enthalten.
• Zum Senden einer Benachrichtigung muss sich der Clouddienst zuerst mit WNS authentifizieren und ein Zugriffstoken empfangen.
• Mit einem Zugriffstoken kann ein Clouddienst nur Benachrichtigungen an die einzelne App senden, für die das Token erstellt wurde. Ein Zugriffstoken kann nicht zum Senden von Benachrichtigungen über mehrere Apps hinweg verwendet werden. Wenn Ihr Clouddienst mehrere Apps unterstützt, muss er daher beim Senden einer Benachrichtigung an jede Kanal-URI das richtige Zugriffstoken für die App bereitstellen.
• Wenn das Gerät offline ist, speichert WNS standardmäßig einen der einzelnen Benachrichtigungstypen (Kachel, Signal, Popup) für jeden Kanal-URI und keine unformatierten Benachrichtigungen.
• In Szenarien, in denen der Benachrichtigungsinhalt für den Benutzer personalisiert wird, empfiehlt WNS, dass der Clouddienst diese Updates sofort sendet, wenn diese empfangen werden. Beispiele für dieses Szenario sind Updates für Social-Media-Feeds, Einladungen zur Sofortkommunikation, Benachrichtigungen über neue Nachrichten oder andere Alarmmeldungen. Alternativ können Sie Szenarien haben, in denen dasselbe generische Update häufig an eine große Teilmenge Ihrer Benutzer übermittelt wird. z. B. Wetter-, Aktien- und Nachrichtenupdates. WNS-Richtlinien geben an, dass die Häufigkeit dieser Updates höchstens alle 30 Minuten betragen sollte. Der Endbenutzer oder WNS kann häufigere Routineupdates als missbräuchlich betrachten.
• Die Windows-Benachrichtigungsplattform verwaltet eine regelmäßige Datenverbindung mit WNS, um den Socket lebendig und fehlerfrei zu halten. Wenn keine Anwendungen vorhanden sind, die Benachrichtigungskanäle anfordern oder verwenden, wird der Socket nicht erstellt.

Verfall von Kachel- und Badge-Benachrichtigungen

Kachel- und Signalbenachrichtigungen laufen standardmäßig drei Tage nach dem Herunterladen ab. Wenn eine Benachrichtigung abläuft, wird der Inhalt aus der Kachel oder Warteschlange entfernt und dem Benutzer nicht mehr angezeigt. Es ist eine bewährte Methode, für alle Kachel- und Signalbenachrichtigungen ein Ablaufdatum (unter Verwendung eines für Ihre App sinnvollen Zeitpunkts) festzulegen, damit der Inhalt der Kachel nicht länger erhalten bleibt, als er relevant ist. Eine explizite Ablaufzeit ist für Inhalte mit definierter Lebensdauer unerlässlich. Dadurch wird auch sichergestellt, dass veraltete Inhalte entfernt werden, wenn Ihr Clouddienst das Senden von Benachrichtigungen beendet oder der Benutzer die Verbindung zum Netzwerk für einen längeren Zeitraum trennt.

Ihr Clouddienst kann einen Ablauf für jede Benachrichtigung festlegen, indem der X-WNS-TTL HTTP-Header so festgelegt wird, dass die Zeitdauer (in Sekunden) angegeben wird, die Ihre Benachrichtigung nach dem Senden gültig bleibt. Weitere Informationen finden Sie unter Anforderungs- und Antwortheader des Push-Benachrichtigungsdienstes.

So können Sie z. B. an einem aktiven Börsenhandelstag den Ablauf einer Aktienkursaktualisierung auf das Doppelte des Sendeintervalls festlegen (z. B. eine Stunde nach Empfang, wenn Sie Benachrichtigungen alle halbe Stunde senden). Als weiteres Beispiel kann eine Nachrichten-App feststellen, dass ein Tag eine geeignete Ablaufzeit für die tägliche Aktualisierung eines Nachrichtenelements ist.

Pushbenachrichtigungen und Stromsparmodus

Der Stromsparmodus erweitert die Akkulaufzeit, indem die Hintergrundaktivität auf dem Gerät eingeschränkt wird. Mit Windows 10 kann der Benutzer den Stromsparmodus so einstellen, dass er automatisch aktiviert wird, wenn der Akku unter einen angegebenen Schwellenwert fällt. Wenn der Stromsparmodus aktiviert ist, wird der Empfang von Pushbenachrichtigungen deaktiviert, um Energie zu sparen. Aber es gibt einige Ausnahmen davon. Mit den folgenden Windows 10-Einstellungen für den Stromsparmodus (unter Windows-Einstellungen) kann Ihre App Pushbenachrichtigungen auch dann empfangen, wenn der Stromsparmodus aktiviert ist.

• Pushbenachrichtigungen von jeder App zulassen, während der Stromsparmodus aktiviert ist: Mit dieser Einstellung können alle Apps Pushbenachrichtigungen empfangen, während der Stromsparmodus aktiviert ist. Beachten Sie, dass diese Einstellung nur für Windows 10 für Desktopeditionen (Home, Pro, Enterprise und Education) gilt.
• Immer zulässig: Mit dieser Einstellung können bestimmte Apps im Hintergrund ausgeführt werden, während der Stromsparmodus aktiviert ist – einschließlich des Empfangens von Pushbenachrichtigungen. Diese Liste wird manuell vom Benutzer verwaltet.

Es gibt keine Möglichkeit, den Status dieser beiden Einstellungen zu überprüfen, aber Sie können den Zustand des Stromsparmodus überprüfen. Verwenden Sie in Windows 10 die EnergySaverStatus--Eigenschaft, um den Status des Energiesparmodus zu überprüfen. Ihre App kann auch das EnergySaverStatusChanged Ereignis verwenden, um Änderungen am Stromsparmodus zu überwachen.

Wenn Ihre App stark von Pushbenachrichtigungen abhängt, empfehlen wir, Benutzern mitzuteilen, dass sie möglicherweise keine Benachrichtigungen erhalten, während der Stromsparmodus aktiviert ist, und Benutzern das Anpassen der Stromsparmodus-Einstellungenzu erleichtern. Mithilfe des URI-Schemas für den Stromsparmodus in Windows ms-settings:batterysaver-settingskönnen Sie einen bequemen Link zu den Windows-Einstellungen bereitstellen.

Hier ist ein Beispiel für die Überprüfung, ob der Stromsparmodus in Windows 10 aktiviert ist. In diesem Beispiel wird der Benutzer benachrichtigt und die Einstellungen zu Batteriespareinstellungen geöffnet. Der dontAskAgainSetting Benutzer kann die Nachricht unterdrücken, wenn er nicht erneut benachrichtigt werden möchte.

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

Dies ist der XAML-Code für das in diesem Beispiel vorgestellte ContentDialog.

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

Zugehörige Themen

• Eine lokale Kachelbenachrichtigung senden
• Schnellstart: Senden einer Pushbenachrichtigung
• So aktualisieren Sie ein Abzeichen über Push-Benachrichtigungen
• Anfordern, Erstellen und Speichern eines Benachrichtigungskanals
• Abfangen von Benachrichtigungen für laufende Anwendungen
• Authentifizieren beim Windows-Pushbenachrichtigungsdienst (Windows Push Notification Service, WNS)
• Anforderungs- und Antwortheader des Pushbenachrichtigungsdiensts
• Richtlinien und Prüfliste für Pushbenachrichtigungen
• Rohe Benachrichtigungen