Эта статья посвящена Дню № 28 из 31-й серии Windows 8 . Каждая из статей этой серии будет опубликована как для HTML5 / JS, так и для XAML / C # . Вы можете найти дополнительные ресурсы, загрузки и исходный код на нашем сайте .
Сегодня мы собираемся погрузиться в мир Push-уведомлений. Короче говоря, push-уведомления — это механизм для какой-то внешней вещи, чтобы отправить пользователю уведомление в различных формах. Теперь, это не что-то новое для нас. На 9-й день мы представили живые плитки , 10-й день — уведомления о тостах и 11-й день . Это были все методы, с помощью которых мы могли уведомлять пользователей и позволять им предпринимать действия, если они того пожелают. Когда мы исследуем каждый из этих методов, мы отправляем уведомление из нашего приложения или какого-либо фонового процесса. Push-уведомления — действительно последняя часть в этой головоломке уведомлений, и, возможно, мы должны были заказать ее немного иначе в нашей серии. Задним числом всегда 20/20 правильно?
Прежде чем мы углубимся в Push-уведомления, я хочу немного установить сцену. Я собираюсь принять веб-подобный сценарий. Я собираюсь создать простой сайт. На этом веб-сайте мы в конечном итоге отправляем уведомления нашим приложениям на разных клиентов. Сервер будет определять, кто, что, когда получит эти уведомления. Конечно, в демонстрационных целях мы собираемся вырезать часть этой «бизнес-логики» так, чтобы мы могли просто использовать Интернет-каналы. На уровне 50 000 футов все это выглядит примерно так:
Что?
Что же такое Push-уведомления? Well Push Notifications — это действительно некоторая облачная инфраструктура для управления и облегчения отправки уведомлений для приложений, которые подписались на их получение. Эти уведомления могут быть плиткой , тостами , значками и необработанными уведомлениями (любыми или всеми). Они фактически определяются с сервера и затем отправляются на сервер WNS, который затем отправляет его соответствующему клиенту. Уведомления работают так же, как мы видели в наших предыдущих статьях, но просто отправляются из внешнего источника, такого как маленький веб-сайт, который мы создадим.
Эти уведомления управляются через так называемые службы push-уведомлений Windows или WNS. Это часть облачной архитектуры, которая находится в центре всего. Сервер WNS — это то, с чем взаимодействуют наш клиент и сервер для отправки и получения уведомлений. Сказав, что наш клиент * все еще должен будет * отправить свою конечную точку на веб-сайт, чтобы он знал, кто хотел бы получить уведомление.
Основные шаги таковы:
- Прежде чем мы сможем что-либо сделать, нам нужно зарегистрироваться в магазине. Это даст нам наши ключи, чтобы мы могли проходить аутентификацию на сервере WNS.
- Наше приложение должно зарегистрировать канал на сервере WNS. Результатом успешной регистрации является URI. Это будет выглядеть примерно так:
- https://bn1.notify.windows.com/?token=AgYAAAAe%2buFwf2o%2fz1nJdCAMwzf4bO9u3QXmrW4L73WAPNpsP8DpbfSmHIuRpoOIJKusNKxTvkXo4tposjhTPkbLNnsvXXzCh8eIMpyTPXOFNStcZ0FR7kQZHf86MwL4Ga5f7vg%3d
- После того, как у нас есть URI, нам нужно предоставить его нашему облачному сервису, чтобы он знал, какие клиенты хотят общаться
- Наш облачный сервис (в нашем случае наш веб-сайт) должен будет иметь некоторые знания о наших секретных ключах WNS. Эти ключи используются нашим сайтом для аутентификации на сервере WNS. После аутентификации он может отправить уведомление на тот URI, который ему дал клиент.
Изображение любопытства MSDN: http://msdn.microsoft.com/en-us/library/windows/apps/hh913756.aspx . Дополнительные сведения о процессе push-уведомлений см. В разделе Обзор push-уведомлений на MSDN .
Настройка
Для начала нам нужно зарегистрировать наше приложение. Сейчас на момент написания этой статьи,
похоже,
Теперь Windows Store является официальным способом регистрации вашего приложения. Команда Windows собрала хороший набор документации о том, как зарегистрироваться, поэтому я не буду перефразировать это здесь. Просто ознакомьтесь со статьей Как пройти проверку подлинности с помощью службы push-уведомлений Windows (WNS). В первой части статьи подробно рассказывается, как зарегистрировать свое приложение в магазине и так далее.
Центр разработчиков Live Connect раньше был местом, где вы также могли зарегистрировать приложение и получить все товары, но, похоже, это недавно изменилось. Я говорю вам об этом, потому что есть много постов в блоге с устаревшей информацией (как однажды это тоже будет). Да, вы все равно можете создать приложение там, но вам не хватит некоторых важных данных (таких как SID), необходимых для правильной аутентификации. Сказав все это, все приложения, которые вы создадите в Магазине Windows, появятся в списке здесь и с этой информацией.
Зачем нам что-то регистрировать, чтобы делать Push-уведомления? Безопасность. Этот процесс регистрации делает две вещи для нас. 1. Он идентифицирует наше приложение не только в Магазине, чтобы мы могли представить наше замечательное приложение, но и правильно идентифицировать себя на серверах WNS. 2. Предоставляет нам удостоверение личности для использования вне нашего приложения (также называемое серверной стороной), которое может аутентифицироваться через OAuth с нашими серверами WNS, это наш SID и секрет. Если ваш секрет когда-либо был раскрыт, вы всегда можете восстановить его либо из Магазина (который действительно переносит вас в Live), либо из Центра разработчиков Live Connect. Под верхним изображением находятся наши результаты из Магазина, а нижнее — страница портала Live Connect.
Хорошо, теперь у вас есть приложение, зарегистрированное в магазине, и вам нужно связать решение с магазином. Что это действительно означает, так это изменение всей той замечательной информации, о которой мы не говорили на вкладке «Упаковка» нашего appxmanifest. Но вместо того, чтобы вводить все вручную, мы можем просто перейти к Project -> Store -> Associate App with the Store . Это сделает все неприятное для нас.
— совет —
Одна вещь, которая поймала меня раз или два, была генерация нашего сертификата. Каждое приложение имеет уникальный сертификат, связанный с ним. Когда вы создаете новый пустой шаблон, Visual Studio фактически создаст для вас временный сертификат, что-то вроде App29_TevenKey.pfx . Этот сертификат будет связан с вашим приложением на вкладке упаковки файла appxmanifest. Теперь, когда вы связываете свое приложение с магазином, оно не только обновляет эту вкладку «Упаковка» новой информацией, но вы также должны * получить * новый сертификат, который будет связан с магазином.
Теперь я лично видел, что этого не произошло, и сколько бы раз я ни пытался связать свое приложение, я не мог получить сертификат Store. Как оказалось, это было легко исправить. Убедитесь, что вы не испортили свой временный сертификат. Если вам действительно не хватает вашего pfx-файла (скажем, вы удалили его или исключили из системы контроля версий), вы можете восстановить временный файл на вкладке «Упаковка» в appxmanifest. После того, как ваш сертификат будет правильно ассоциирован, снова связывайтесь с магазином, и вы фактически получите свой официальный ключ.
Клиент
Теперь, когда наше приложение зарегистрировано, и у нас есть ключи (SID и Secret) для нашего замка, первое, что наше приложение должно будет сделать, это зарегистрировать канал на сервере WNS. Наше приложение * должно * сообщать серверам WNS, что мы на самом деле хотим получать уведомления. В свою очередь наш WNS-сервер сообщит нашему приложению, каким будет фактический URI push-уведомлений. Получив эту конечную точку, мы можем передать ее нашим облачным службам, чтобы начать получать уведомления.
Как ни странно, клиентская часть — легкая часть. Единственное, что нам нужно сделать в нашем приложении — это зарегистрироваться на сервере WNS и передать наш URI. Как мы видели из наших бесед на плитку , тосты , бейджи уведомлений мы действительно не были никакой работы , чтобы получать уведомления. Это означает, что нам не нужно было настраивать события на уровне ОС для захвата и всплывающих диалоговых окон, в отличие от нашего разговора на устройствах, где мы это делали (по крайней мере, должны были зарегистрироваться).
Когда наше приложение запускается, мы можем зарегистрироваться на серверах WNS.
var notify = Windows.UI.Notifications;
var push = Windows.Networking.PushNotifications;
var net = Windows.Networking.Connectivity;
notify.TileUpdateManager.createTileUpdaterForApplication().clear();
notify.BadgeUpdateManager.createBadgeUpdaterForApplication().clear();
var profile = net.NetworkInformation.getInternetConnectionProfile();
if (profile.getNetworkConnectivityLevel() === net.NetworkConnectivityLevel.internetAccess) {
push.PushNotificationChannelManager.createPushNotificationChannelForApplicationAsync()
.then(function (channel) {
document.querySelector("#uri").innerText = channel.uri;
/*
this would be the place to post your uri to your cloud service.
*/
})
}
Выше я просто очищаю все уведомления (в конце концов, это демо), затем проверю доступ в интернет. Если это так, то мы можем зарегистрироваться для Push-уведомлений и передать наш URI. В нашем случае я просто собираюсь поместить URI на экран, чтобы мы могли его увидеть.
— еще один совет —
Доступ в Интернет. По умолчанию в шаблоне Visual Studio уже проверена возможность доступа в Интернет . На самом деле это функция, которая нам нужна для push-уведомлений, поэтому мы не нуждаемся в немедленной работе.
Тем не менее, если у нас проверен доступ в Интернет, то при попытке опубликовать наше приложение в магазине нам также потребуется предоставить политику конфиденциальности. См. Раздел 4.1.1 для получения дополнительной информации. Без этого вы будете отклонены.
Вы были предупреждены.
Сервер
Наш сервер — это место, где случится вся магия. Чтобы отправить уведомление, нужно всего несколько простых шагов. Выполните аутентификацию на серверах WNS, создайте свои уведомления и затем отправьте их вместе. Так как мы уже рассмотрели , как создать плитку , тосты и значка уведомления я не буду рассматривать, а я хотел бы представить библиотеку , которая будет делать все это довольно простой мертвой. Это называется Рецепт WNS . Хотя я мог бы провести вас через процесс аутентификации OAuth с серверами WNS, почему?
Рецепт WNS , делает все это очень простым. В качестве забавного небольшого эксперимента я создал простую веб-страницу на 31 день для тестирования Push-уведомлений . Вы включаете свою информацию, и она отправит вам уведомление о плитке и тосте. Конечно, я мог бы пойти намного дальше, но пока он хотя бы проверит трубы. Ниже приведена большая часть этого кода.
var sid = Request["sid"];
var secret = Request["secret"];
var uri = Request["uri"];
var message = Request["message"];
WnsAccessTokenProvider tokenProvider = new WnsAccessTokenProvider(sid, secret);
var title = "31 Days";
var subText = message;
var tileNotification = TileContentFactory.CreateTileWideText01();
tileNotification.RequireSquareContent = false;
tileNotification.TextHeading.Text = "31 days";
tileNotification.TextBody1.Text = message;
var tileResult = tileNotification.Send(new Uri(uri), tokenProvider).ErrorDescription;
if (!string.IsNullOrEmpty(tileResult) ){
<h1>tile result: @tileResult</h1>
}
Первый важный шаг — создание экземпляра того, что называется поставщиком токенов. Для его создания нам понадобятся тот идентификатор безопасности и секрет, который мы получили при регистрации нашего приложения. Они будут выглядеть примерно так:
- SID: ms-app: // s-1-15-2-1368837720-1402593261-3975316331-362590900-1199389545-3359712884-900627795
- Секрет: 7PQ5upGa7rrYHM + fKe60Am81lU + mca / 7
Как только у нас будет наш поставщик токенов, нам просто нужно создать уведомления, которые мы хотели бы отправить. WNS Recipe делает это легко, так как он включает в себя все типы уведомлений на некоторых хороших фабриках. Если вы помните, есть несколько различных шаблонов для каждой категории уведомлений. WNS Recipe облегчает работу с этими шаблонами.
Затем, когда мы готовы к отправке, мы просто отправляем на тот URI, который дало нам наше приложение, используя наш токен.
Звучит легко
Звучит легко, Кларк, я звоню BS. Хорошо, ну, может быть, вы меня поймали. Push-уведомления на самом деле очень просто. Вот что может быть болью. Управление этими URI будет отправлять вам сотни миллионов клиентов.
Да, ваши облачные службы должны иметь конечную точку, к которой ваше приложение может отправлять свой URI. Затем необходимо будет определить, истек ли срок действия этого URI (да, они могут изменяться и истекать), кому вы отправляете и когда, и так далее. Так что да, отправка уведомления очень проста. То, как вы их используете, — это отдельная история.
Но подождите, это еще не все. Сегодня я рассказал о необработанных деталях отправки Push-уведомлений. На момент написания этой статьи Microsoft недавно выпустила нечто, называемое Azure Mobile Services . Мобильные службы Azure — отличная утилита для разработчиков приложений. Мобильные службы Azure на самом деле установят и разместят большую часть этой сантехники, о которой я только что говорил. Теперь Джефф провел свой 28 день, работая над этим подходом. Это то, что я очень рекомендую прочитать.
Надеемся, что между нами будет более чем полная картина того, как вы можете использовать Push-уведомления в своем приложении.
Резюме
Push-уведомления это очень круто. В последнее время были проведены исследования, в которых приложения требуют push-уведомлений, что приводит к более чем 60% взаимодействия с приложением. Независимо от этого, наличие возможности побудить пользователей вернуться — это всегда хорошо.
Если вы хотите загрузить мой рабочий образец, использующий код из этой статьи, нажмите значок ниже:
Завтра мы наконец поговорим об управлении жизненным циклом процесса. Увидимся позже!
