Merge pull request #99216 from sethmanheim/syntax

Add language specifiers per GH issue #44743, also misc cleanup

Author: PRMerger7

articles/notification-hubs/notification-hubs-push-notification-registration-management.md

@@ -13,16 +13,14 @@ ms.workload: mobile
 ms.tgt_pltfrm: mobile-multiple
 ms.devlang: dotnet
 ms.topic: article
-ms.date: 04/08/2019
+ms.date: 12/17/2019
 ms.author: sethm
 ms.reviewer: jowargo
 ms.lastreviewed: 04/08/2019
 ---
 
 # Registration management
 
-## Overview
-
 This topic explains how to register devices with notification hubs in order to receive push notifications. The topic describes registrations at a high level, then introduces the two main patterns for registering devices: registering from the device directly to the notification hub, and registering through an application backend.
 
 ## What is device registration
@@ -38,15 +36,15 @@ A registration associates the Platform Notification Service (PNS) handle for a d
 
 ### Installations
 
-An Installation is an enhanced registration that includes a bag of push related properties. It is the latest and best approach to registering your devices. However, it is not supported by client-side .NET SDK ([Notification Hub SDK for backend operations](https://www.nuget.org/packages/Microsoft.Azure.NotificationHubs/)) as of yet.  This means if you are registering from the client device itself, you would have to use the [Notification Hubs REST API](https://docs.microsoft.com/rest/api/notificationhubs/create-overwrite-installation) approach to support installations. If you are using a backend service, you should be able to use [Notification Hub SDK for backend operations](https://www.nuget.org/packages/Microsoft.Azure.NotificationHubs/).
+An Installation is an enhanced registration that includes a bag of push related properties. It is the latest and best approach to registering your devices. However, it is not supported by client-side .NET SDK ([Notification Hub SDK for backend operations](https://www.nuget.org/packages/Microsoft.Azure.NotificationHubs/)) as of yet.  This means if you are registering from the client device itself, you would have to use the [Notification Hubs REST API](/rest/api/notificationhubs/create-overwrite-installation) approach to support installations. If you are using a backend service, you should be able to use [Notification Hub SDK for backend operations](https://www.nuget.org/packages/Microsoft.Azure.NotificationHubs/).
 
 The following are some key advantages to using installations:
 
 - Creating or updating an installation is fully idempotent. So you can retry it without any concerns about duplicate registrations.
 - The installation model supports a special tag format (`$InstallationId:{INSTALLATION_ID}`) that enables sending a notification directly to the specific device. For example, if the app's code sets an installation ID of `joe93developer` for this particular device, a developer can target this device when sending a notification to the `$InstallationId:{joe93developer}` tag. This enables you to target a specific device without having to do any additional coding.
 - Using installations also enables you to do partial registration updates. The partial update of an installation is requested with a PATCH method using the [JSON-Patch standard](https://tools.ietf.org/html/rfc6902). This is useful when you want to update tags on the registration. You don't have to pull down the entire registration and then resend all the previous tags again.
 
-An installation can contain the following properties. For a complete listing of the installation properties, see [Create or Overwrite an Installation with REST API](https://docs.microsoft.com/rest/api/notificationhubs/create-overwrite-installation) or [Installation Properties](https://docs.microsoft.com/dotnet/api/microsoft.azure.notificationhubs.installation).
+An installation can contain the following properties. For a complete listing of the installation properties, see [Create or Overwrite an Installation with REST API](/rest/api/notificationhubs/create-overwrite-installation) or [Installation Properties](/dotnet/api/microsoft.azure.notificationhubs.installation).
 
 ```json
 // Example installation format to show some supported properties
@@ -96,7 +94,7 @@ Registrations and installations must contain a valid PNS handle for each device/
 
 If you want to use [Templates](notification-hubs-templates-cross-platform-push-messages.md), the device installation also holds all templates associated with that device in a JSON format (see sample above). The template names help target different templates for the same device.
 
-Each template name maps to a template body and an optional set of tags. Moreover, each platform can have additional template properties. For Windows Store (using WNS) and Windows Phone 8 (using MPNS), an additional set of headers can be part of the template. In the case of APNs, you can set an expiry property to either a constant or to a template expression. For a complete listing of the installation properties see, [Create or Overwrite an Installation with REST](https://docs.microsoft.com/rest/api/notificationhubs/create-overwrite-installation) topic.
+Each template name maps to a template body and an optional set of tags. Moreover, each platform can have additional template properties. For Windows Store (using WNS) and Windows Phone 8 (using MPNS), an additional set of headers can be part of the template. In the case of APNs, you can set an expiry property to either a constant or to a template expression. For a complete listing of the installation properties see, [Create or Overwrite an Installation with REST](/rest/api/notificationhubs/create-overwrite-installation) topic.
 
 ### Secondary Tiles for Windows Store Apps
 
@@ -108,7 +106,7 @@ The SecondaryTiles dictionary uses the same TileId that is used to create the Se
 
 When managing device registration from client apps, the backend is only responsible for sending notifications. Client apps keep PNS handles up-to-date, and register tags. The following picture illustrates this pattern.
 
-![](./media/notification-hubs-registration-management/notification-hubs-registering-on-device.png)
+![Registration from device](./media/notification-hubs-registration-management/notification-hubs-registering-on-device.png)
 
 The device first retrieves the PNS handle from the PNS, then registers with the notification hub directly. After the registration is successful, the app backend can send a notification targeting that registration. For more information about how to send notifications, see [Routing and Tag Expressions](notification-hubs-tags-segment-push-message.md).
 
@@ -121,11 +119,11 @@ Registering from the device is the simplest method, but it has some drawbacks:
 
 ### Example code to register with a notification hub from a device using an installation
 
-At this time, this is only supported using the [Notification Hubs REST API](https://docs.microsoft.com/rest/api/notificationhubs/create-overwrite-installation).
+At this time, this is only supported using the [Notification Hubs REST API](/rest/api/notificationhubs/create-overwrite-installation).
 
 You can also use the PATCH method using the [JSON-Patch standard](https://tools.ietf.org/html/rfc6902) for updating the installation.
 
-```
+```csharp
 class DeviceInstallation
 {
     public string installationId { get; set; }
@@ -206,7 +204,7 @@ else
 
 These methods create or update a registration for the device on which they are called. This means that in order to update the handle or the tags, you must overwrite the entire registration. Remember that registrations are transient, so you should always have a reliable store with the current tags that a specific device needs.
 
-```
+```csharp
 // Initialize the Notification Hub
 NotificationHubClient hub = NotificationHubClient.CreateClientFromConnectionString(listenConnString, hubName);
 
@@ -261,7 +259,7 @@ catch (Microsoft.WindowsAzure.Messaging.RegistrationGoneException e)
 
 Managing registrations from the backend requires writing additional code. The app from the device must provide the updated PNS handle to the backend every time the app starts (along with tags and templates), and the backend must update this handle on the notification hub. The following picture illustrates this design.
 
-![](./media/notification-hubs-registration-management/notification-hubs-registering-on-backend.png)
+![Registration management](./media/notification-hubs-registration-management/notification-hubs-registering-on-backend.png)
 
 The advantages of managing registrations from the backend include the ability to modify tags to registrations even when the corresponding app on the device is inactive, and to authenticate the client app before adding a tag to its registration.
 
@@ -271,7 +269,7 @@ The client device still gets its PNS handle and relevant installation properties
 
 You can also use the PATCH method using the [JSON-Patch standard](https://tools.ietf.org/html/rfc6902) for updating the installation.
 
-```
+```csharp
 // Initialize the Notification Hub
 NotificationHubClient hub = NotificationHubClient.CreateClientFromConnectionString(listenConnString, hubName);
 
@@ -317,7 +315,7 @@ public async Task<HttpResponseMessage> Put(DeviceInstallation deviceUpdate)
 
 From your app backend, you can perform basic CRUDS operations on registrations. For example:
 
-```
+```csharp
 var hub = NotificationHubClient.CreateClientFromConnectionString("{connectionString}", "hubName");
 
 // create a registration description object of the correct type, e.g.