Отправка уведомлений отдельным пользователям с помощью Центра уведомлений Azure

Я создаю серверную часть веб-API для приложения. В настоящее время приложение планируется только для WP8, но мы также планируем выпустить версии для других платформ в более позднее время.

Наши push-уведомления основаны на Центре уведомлений Azure. Приложение не будет регистрироваться напрямую, но вызовет метод веб-API, который выполнит регистрацию для приложения.

Есть две вещи, которые у меня возникают с трудом:

  1. Я не могу найти никакой документации по отправке уведомлений отдельным пользователям WP8. Я не хочу вещать; Я просто хочу отправить одно уведомление одному пользователю. Поддерживается ли этот вариант использования? Как это можно сделать с помощью Microsoft.ServiceBus.Notifications API?

  2. Я нашел это: http://www.windowsazure.com/en-us/documentation/articles/notification-hubs-aspnet-notify-users/ - Это реализует многие функции, которые мне нужны, с точки зрения уведомлений. В образец включены только приложения из магазина iOS и Windows. Это потому, что этот вариант использования не поддерживается в WP8? Я не понимаю почему, но я новичок в WP8.


azure azure-notificationhub windows-phone-8
person Elad Lachmi    schedule 06.02.2014    source источник
comment
если вы этого еще не видели, проверьте это blogs.msdn.com/b/andy_wigley/archive/2013/08/22/   -  person Aravind    schedule 06.02.2014
comment
@Aravind - Спасибо. Я видел это, но он показывает, как отправить широковещательное уведомление. Я ищу пример отправки одного уведомления одному пользователю, и в этом примере отсутствует часть, в которой регистрация определяется идентификатором устройства и идентификатором установки.   -  person Elad Lachmi    schedule 06.02.2014
comment
Некоторое время назад я работал над проектом, который использовал MPNS для отправки push-уведомлений зарегистрированным пользователям WP. Когда вы регистрируетесь, MPNS предоставляет channelUri, который связан с конкретным устройством / пользователем. что-то вроде этого stackoverflow.com/questions/19149995/   -  person Aravind    schedule 06.02.2014
comment
@Aravind - в этом примере рассказывается о ручном хранении и работе с Uris. Я могу это сделать, но я бы хотел воспользоваться Центром уведомлений Azure.   -  person Elad Lachmi    schedule 06.02.2014
comment
@Elad Посмотрите на [полную рабочую реализацию здесь] [1]. Вы можете напрямую использовать с небольшими изменениями [1]: stackoverflow.com/questions/31912711/   -  person Premchandra Singh    schedule 11.08.2015

Ответы (3)


arrow_upward
12
arrow_downward

Центры уведомлений Azure поддерживают теги, как в примере здесь.

В веб-трансляции Channel9 (которую я не могу найти прямо сейчас) они говорили об использовании тегов для отправки уведомлений определенным пользователям / группам.

Поскольку я хотел бы использовать все дополнительные возможности Центров уведомлений, я помечу каждую запись именем пользователя, используемым в моем приложении, и буду использовать его для отправки требований конкретным пользователям по имени пользователя.

РЕДАКТИРОВАТЬ: здесь в в официальной документации по Windows Azure я нашел пример, говорящий именно о том, что я хотел сделать. В качестве дополнительного бонуса они также подали мне идею также пометить идентификатором установки, чтобы один и тот же пользователь мог получать собственные уведомления на разных устройствах с разными операционными системами.

person Elad Lachmi    schedule 09.02.2014
comment
Любая ссылка на выполнение той же задачи на бэкэнде javascript? - person TheLoneWolf91193; 28.01.2016

arrow_upward
3
arrow_downward

Центр уведомлений - для трансляции уведомлений большой мобильной аудитории.

Push через мобильные сервисы - для конкретных уведомлений. См. Q4 в разделе вопросов и ответов здесь http://blogs.msdn.com/b/windowsazure/archive/2013/10/11/recap-mobile-services-azurechat.aspx

Push-уведомление в мобильных службах < / а>

person Aravind    schedule 07.02.2014
comment
Хороший! :) но у меня все еще проблема с этим. Центры уведомлений кажутся более управляемыми. Я за подход «сделай сам», но не тогда, когда мне придется вручную управлять миллионами пользователей (надеюсь на лучшее :)). Архитектура мобильных концентраторов кажется более надежной и полнофункциональной, а мобильные службы, похоже, ограничены 500 уведомлениями на устройство в день. - person Elad Lachmi; 07.02.2014
comment
@EladLachmi Я понимаю вашу точку зрения. Я не особо знаком с мобильными сервисами. Возможно, вам нужно спроектировать его таким образом, чтобы классифицировать пользователей, которые хотят получать уведомления отдельно и как часть массовых уведомлений. Если индивидуальные уведомления - единственный вариант, вы можете подумать об использовании подхода uri. - person Aravind; 07.02.2014

arrow_upward
3
arrow_downward

В то время как другие здесь уже рассмотрели использование тегов, есть еще один вариант, который не так хорошо известен. В документации REST API центров уведомлений Azure на MSDN есть следующая страница прямой отправки: https://msdn.microsoft.com/en-us/library/azure/mt608572.aspx

По сути, вы добавляете «прямой» к строке запроса в URL-адресе и предоставляете токен push в виде заголовка «* -DeviceHandle».

Пользователям этого API не нужно использовать Регистрации или Установки. Вместо этого пользователи этого API управляют всеми устройствами самостоятельно и используют Центр уведомлений Azure исключительно в качестве сквозной службы для связи с различными службами push-уведомлений.

Что это значит? Перед вызовом ANH REST API необходимо получить токен push-уведомления устройства от клиента (и эффективно использовать его повторно).

И последнее замечание для всех, кто сталкивался с этим предыдущим, но уклонялся от него: в документации говорилось, что вам нужно связаться со службой поддержки, чтобы выбрать эту функцию, но недавно она была обновлена, чтобы удалить это предостережение, когда я спросил об этом. :)

person Matt Kerr    schedule 13.07.2016
comment
Небольшое обновление: вам нужно будет использовать концентратор уведомлений типа Standard (с другой ценой). - person Matt Kerr; 05.12.2016
comment
Обновление: похоже, что эта методология больше не поддерживается. - person Matt Kerr; 19.02.2018