Delen via

Migratie van functionaliteit voor pushmeldingen

Dit onderwerp bevat migratierichtlijnen in het functiegebied voor pushmeldingen.

Belangrijk

Momenteel worden alleen onbewerkte pushmeldingen en app-pushmeldingen ondersteund. Badge-pushmeldingen en tegel-pushmeldingen worden niet ondersteund.

Overzicht van verschillen tussen API's en/of functies

Pushmeldingen kunnen worden opgesplitst in deze vier afzonderlijke fasen.

Podium UWP (Universal Windows Platform) Windows App SDK
Identiteit Partnercentrum (MSA) Azure App Registration (AAD)
Kanaalaanvraag Asynchroon Asynchroon
Registratie-id van Azure-app
Ingebouwde logica voor opnieuw proberen (maximaal 5 nieuwe pogingen)
Activering In-process, PushTrigger*, COM-activering* In-process, COM-activering, ShellExecute
Pushmeldingen verzenden Gebruikt login.live.com eindpunt om een toegangstoken te ontvangen Gebruikt het https://login.microsoftonline.com/{tenantID}/oauth2/token-eindpunt voor tokenaanvraag

* Ondersteund voor Windows 10, versie 2004 (10.0; Build 19041) en hoger.

Identiteit instellen

In de Windows App SDK maakt de functie voor pushmeldingen gebruik van identiteit van Azure App Registration (AAD), waardoor de vereiste om een Package Family Name (PFN) uit het Partner Center te hebben voor gebruik van pushmeldingen wordt verwijderd.

Kanaalaanvragen

Kanaalaanvragen worden asynchroon verwerkt en vereisen de GUID van de Azure AppID en Azure tenantID (u ontvangt de Azure AppID en tenant ID van een AAD-app-registratie). U gebruikt de Azure AppID voor uw identiteit in plaats van de PFN (Package Family Name) die een UWP-app gebruikt. Als de aanvraag een fout ondervindt die opnieuw kan worden geprobeerd, probeert het meldingsplatform meerdere nieuwe pogingen uit te voeren.

Een Windows App SDK-app kan de status van een kanaalaanvraag controleren.

Activering

Zie de registratie- en activeringsstappen voor Windows App SDK op Configureer uw app voor het ontvangen van pushmeldingen.

Pushmeldingen verzenden

Een Windows App SDK-app moet het toegangstoken aanvragen vanaf het AAD-eindpunt in plaats van het MSA-eindpunt.

Toegangstokenaanvraag

Voor een UWP-app:

POST /accesstoken.srf HTTP/1.1
Host: login.live.com
Content-Type: application/x-www-form-urlencoded
Cookie: MSCC=73.140.231.96-US
Content-Length: 112

grant_type=client_credentials&client_id=<AppID_Here>&client_secret=<Client_Secret_Here>&scope=notify.windows.com

Voor een Windows App SDK-app (AAD-toegangstokenaanvraag):

POST /{tenantID}/oauth2/v2.0/token Http/1.1
Host: login.microsoftonline.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 160

grant_type=client_credentials&client_id=<Azure_App_Registration_AppId_Here>&client_secret=<Azure_App_Registration_Secret_Here>&resource=https://wns.windows.com/

HTTP-post naar WNS

Als het gaat om het verzenden van een HTTP POST-aanvraag naar WNS, zijn er geen wijzigingen van UWP. Het toegangstoken wordt nog steeds doorgegeven in de autorisatieheader.

POST /?token=[ChannelURI] HTTP/1.1
Host: dm3p.notify.windows.com
Content-Type: application/octet-stream
X-WNS-Type: wns/raw
Authorization: Bearer [your access token]
Content-Length: 46

{ Sync: "Hello from the Contoso App Service" }

Zie ook

  • Last updated on