Zarządzanie rejestracją

W tym temacie opisano sposób rejestrowania urządzeń w centrach powiadomień w celu odbierania powiadomień wypychanych. W tym temacie opisano rejestracje na wysokim poziomie, a następnie przedstawiono dwa główne wzorce rejestrowania urządzeń: rejestrowanie z urządzenia bezpośrednio do centrum powiadomień i rejestrowanie za pośrednictwem zaplecza aplikacji.

Co to jest rejestracja urządzenia

Rejestracja to jednostka podrzędna centrum powiadomień i kojarzy uchwyt usługi PNS urządzenia (uchwyt usługi powiadomień platformy, na przykład ChannelURI, token urządzenia, GCM registrationId) z tagami i ewentualnie szablonem. Tagi służą do kierowania powiadomień do poprawnego zestawu dojść urządzeń. Aby uzyskać więcej informacji, zobacz Routing i wyrażenia tagów. Szablony służą do implementowania transformacji na rejestrację. Aby uzyskać więcej informacji, zobacz Szablony.

Należy pamiętać, że rejestracje są przejściowe. Podobnie jak w przypadku obsługiwanych przez usługę PNS, które zawierają, rejestracje wygasają. Możesz ustawić czas wygaśnięcia na potrzeby rejestracji w centrum powiadomień, maksymalnie 90 dni. Ten limit oznacza, że muszą być okresowo odświeżane, a także że nie powinny być jedynym magazynem ważnych informacji. To automatyczne wygaśnięcie upraszcza również czyszczenie po odinstalowaniu aplikacji mobilnej.

Rejestracje muszą zawierać najnowsze dojście PNS dla każdego urządzenia/kanału. Ponieważ uchwyty pnS można uzyskać tylko w aplikacji klienckiej na urządzeniu, jednym ze sposobów zarządzania rejestracjami jest bezpośrednio w tej aplikacji klienckiej. Z drugiej strony zagadnienia dotyczące zabezpieczeń i logika biznesowa związane z tagami mogą wymagać zarządzania rejestracją w zapleczu aplikacji. W poniższej sekcji opisano te dwa podejścia.

Zarządzanie rejestracją z urządzenia

Podczas zarządzania rejestracjami z aplikacji klienckich zaplecze jest odpowiedzialne tylko za wysyłanie powiadomień. Aplikacje klienckie zapewniają aktualność obsługi usługi PNS i rejestrują się w tagach. Na poniższej ilustracji przedstawiono ten wzorzec.

Urządzenie najpierw pobiera uchwyt pnS z usługi PNS, a następnie rejestruje się bezpośrednio w centrum powiadomień. Po pomyślnym zakończeniu rejestracji zaplecze aplikacji może wysłać powiadomienie przeznaczone dla tej rejestracji. Aby uzyskać więcej informacji na temat wysyłania powiadomień, zobacz Routing and Tag Expressions (Wyrażenia routingu i tagów).

Należy pamiętać, że w tym przypadku będziesz używać tylko praw nasłuchiwania w celu uzyskania dostępu do centrów powiadomień z urządzenia. Aby uzyskać więcej informacji, zobacz Zabezpieczenia.

Poniższy kod rejestruje urządzenie przy użyciu odwołań interfejsu API usługi Notification Hubs:

await hub.RegisterNativeAsync(channelUri, tags);

[hub registerNativeWithDeviceToken:deviceToken tags:nil completion:^(NSError* error) {
    if (error != nil) {
        NSLog(@"Error registering for notifications: %@", error);
    }
}];

hub.register(regid, tags);

Te metody tworzą lub aktualizują rejestrację urządzenia, na którym są wywoływane. Oznacza to, że aby zaktualizować uchwyt lub tagi, należy zastąpić całą rejestrację. Pamiętaj, że rejestracje są przejściowe, dlatego zawsze należy mieć niezawodny magazyn (magazyn lokalny na urządzeniu lub w zapleczu aplikacji) z bieżącymi tagami, które wymagają określonego urządzenia. Aby uzyskać bardziej szczegółowe przykłady sposobu aktualizowania rejestracji, zobacz samouczek Aktualności o nowościach .

Możesz również użyć interfejsów API REST do zarejestrowania się z urządzenia. Aby uzyskać więcej informacji, zobacz How to Use the Notification Hubs REST Interface (Jak używać interfejsu REST usługi Notification Hubs).

Poniższe samouczki dotyczące scenariusza zawierają szczegółowe wskazówki dotyczące rejestrowania się od klienta:

• Wprowadzenie za pomocą usługi Notification Hubs

• Wiadomości o aktualnościach

Szablony

Jeśli chcesz użyć szablonów, każda rejestracja reprezentuje pojedynczy szablon. Oznacza to, że jeśli urządzenie korzysta z dwóch szablonów, musisz zarejestrować każdy szablon niezależnie przy użyciu własnego uchwytu pnS i zestawu tagów.

W przypadku rejestracji natywnych (czyli bez szablonu) metody rejestracji szablonów tworzą lub aktualizują istniejące rejestracje. Aby określić różne szablony, należy podać nazwę szablonu podczas rejestrowania. Możesz podać różne nazwy, jeśli chcesz zachować wiele szablonów dla tego samego urządzenia.

Ważne

W przypadku korzystania z szablonów nie trzeba rejestrować urządzenia, jak pokazano w poprzedniej sekcji. Ta rejestracja jest używana tylko wtedy, gdy wysyłasz powiadomienia natywne (powiadomienia wysyłane w formacie specyficznym dla platformy).

Poniższy kod rejestruje urządzenie przy użyciu odwołań interfejsu API usługi Notification Hubs:

await hub.RegisterTemplateAsync(channelUri, template, templateName, tags);

[hub registerTemplateWithDeviceToken:deviceToken name:templateName jsonBodyTemplate: template expiryTemplate:nil tags:nil completion:^(NSError* error) {
    if (error != nil) {
        NSLog(@"Error registering for notifications: %@", error);
    }
}];

hub.registerTemplate(regId, templateName, template, tags);

Należy pamiętać, że każde wywołanie rejestracji zapewnia, oprócz uchwytu pnS i opcjonalnego zestawu tagów, szablon treści powiadomienia i nazwy szablonu. Ponadto każda platforma może mieć dodatkowe właściwości, które są częścią szablonu. W przypadku Windows Store (przy użyciu usługi WNS) i Windows Phone 8 (przy użyciu usługi MPNS) dodatkowy zestaw nagłówków może być częścią szablonu. W przypadku sieci APNs można ustawić właściwość wygaśnięcia na stałą lub na wyrażenie szablonu.

Aby uzyskać instrukcje dotyczące modyfikowania tych pól szablonu, zobacz Dokumentacja interfejsu API lub Interfejsy API REST usługi Notification Hubs.

Kafelki pomocnicze dla aplikacji ze sklepu Windows

W przypadku aplikacji klienckich Windows Store wysyłanie powiadomień do kafelków pomocniczych jest takie samo, jak wysyłanie ich do podstawowej. Obsługiwane są rejestracje natywne i szablonu. Jedyną różnicą jest to, że kafelki pomocnicze mają inny identyfikator ChannelUri, który zestaw SDK w aplikacji klienckiej obsługuje w sposób niewidoczny.

Na wysokim poziomie wszystkie informacje podane w poprzednich sekcjach działają z kafelkami pomocniczymi przez wywołanie odpowiednich metod na obiektach uwidocznionych we właściwości słownika Microsoft.WindowsAzure.Messaging.NotificationHub.SecondaryTiles. Przykład:

await hub.SecondaryTiles["myTileId"].RegisterNativeAsync(new string[] {"Yankees"});
await hub.SecondaryTiles["myTileId"].RegisterTemplateAsync(buildToastTemplate(), "toastTemplate", new string[] {"RedSox"});

Słownik SecondaryTiles używa tego samego identyfikatora TileId, który służy do tworzenia obiektu SecondaryTiles w aplikacji Windows Store.

Podobnie jak w przypadku podstawowego identyfikatora ChannelUris kafelków pomocniczych mogą ulec zmianie w dowolnym momencie. Aby zachować zaktualizowane rejestracje aplikacji klienckiej w centrum powiadomień, urządzenie musi odświeżyć je przy użyciu bieżących identyfikatorów ChannelUris kafelków pomocniczych.

Uwaga

Kafelki pomocnicze można usunąć, gdy aplikacja jest nieaktywna. Odpowiednie rejestracje nie spowodują żadnych powiadomień i zostaną automatycznie usunięte przez centra powiadomień.

Wady rejestrowania z urządzenia

Rejestrowanie z urządzenia jest najprostszą metodą, ale ma pewne wady.

Pierwszą wadą jest to, że aplikacja kliencka może aktualizować tagi tylko wtedy, gdy aplikacja jest aktywna. Jeśli na przykład użytkownik ma dwa urządzenia, które rejestrują tagi związane z zespołami sportowymi, gdy pierwsze urządzenie zarejestruje się na potrzeby dodatkowego tagu (na przykład Seahawks), drugie urządzenie nie otrzyma powiadomień o seahawks, dopóki aplikacja na drugim urządzeniu nie zostanie wykonana po raz drugi. Ogólnie rzecz biorąc, gdy tagi mają wpływ na wiele urządzeń, zarządzanie tagami z zaplecza jest pożądaną opcją.

Drugą wadą zarządzania rejestracją z aplikacji klienckiej jest to, że ponieważ aplikacje mogą zostać zhakowane, zabezpieczenie rejestracji do określonych tagów wymaga dodatkowej ostrożności, jak wyjaśniono w sekcji "Zabezpieczenia na poziomie tagu".

Zarządzanie rejestracją z zaplecza aplikacji

Zarządzanie rejestracjami z zaplecza wymaga pisania dodatkowego kodu. Aplikacja z urządzenia musi podać zaktualizowaną dojścia pnS do zaplecza za każdym razem, gdy aplikacja rozpoczyna się (wraz z tagami i szablonami), a zaplecze musi zaktualizować ten uchwyt na Service Bus. Na poniższej ilustracji przedstawiono ten projekt.

Zalety zarządzania rejestracjami z zaplecza to możliwość modyfikowania tagów do rejestracji nawet wtedy, gdy odpowiednia aplikacja na urządzeniu jest nieaktywna, oraz uwierzytelnianie aplikacji klienckiej przed dodaniem tagu do jego rejestracji.

Z poziomu zaplecza aplikacji możesz wykonywać podstawowe operacje CRUDS na rejestracjach. Przykład:

var hub = NotificationHubClient.CreateClientFromConnectionString("{connectionString}", "hubName");
            
// create a registration description object of the correct type, e.g.
var reg = new WindowsRegistrationDescription(channelUri, tags);

// Create
await hub.CreateRegistrationAsync(reg);

// Get by id
var r = await hub.GetRegistrationAsync<RegistrationDescription>("id");

// update
r.Tags.Add("myTag");

// update on hub
await hub.UpdateRegistrationAsync(r);

// delete
await hub.DeleteRegistrationAsync(r);

Możesz również użyć węzła lub interfejsów API REST.

Ważne

Zaplecze musi obsługiwać współbieżność między aktualizacjami rejestracji. Service Bus oferuje optymistyczną kontrolę współbieżności na potrzeby zarządzania rejestracją. Na poziomie HTTP jest to implementowane przy użyciu narzędzia ETag w operacjach zarządzania rejestracją. Ta funkcja jest w przezroczysty sposób używana przez zestawy SDK firmy Microsoft, co zgłasza wyjątek, jeśli aktualizacja została odrzucona ze względów współbieżności. Zaplecze aplikacji jest odpowiedzialne za obsługę tych wyjątków i ponawianie próby aktualizacji w razie potrzeby.

Dodatkowe zasoby

Poniższe samouczki dotyczące scenariusza zawierają szczegółowe wskazówki dotyczące rejestrowania się z zaplecza aplikacji:

• Wysyłanie powiadomień do uwierzytelnionych użytkowników przy użyciu tagów

• Wysyłanie powiadomień międzyplatformowych do uwierzytelnionych użytkowników przy użyciu szablonów