Опубликован: 28.01.2014 | Доступ: свободный | Студентов: 2265 / 265 | Длительность: 14:33:00
Лекция 10:

Использование Windows Azure Mobile Services

< Лекция 9 || Лекция 10: 1234 || Лекция 11 >

Push-уведомления

Если разработчик имеет перед собой задачу уведомлять всех пользователей или конкретного пользователя о произошедшем событии или действии, он может воспользоваться сервисом Windows Azure Mobile Services для интеграции Push-уведомлений в свое приложение. При этом нет необходимости вручную реализовывать все низлежащие механизмы – достаточно открыть специальный канал с помощью API Windows Azure Mobile Services и настроить скрипты на стороне сервера таким образом, чтобы они, в зависимости от какого-либо действия, высылали Push-уведомления пользователям.

Push-уведомления подразделяются на два типа:

  1. XML-обновления, содержащие обновленные тайлы или бейджи. Могут быть интерпретированы Windows.
  2. Бинарные, или raw-уведомления, содержащие любые данные, которые необходимо послать – эти уведомления не могут быть обработаны Windows, так как неизвестна логика их обработки – логика должна быть реализована в клиентском приложении.
Механизм рассылки Push-уведомлений

Рис. 14.6. Механизм рассылки Push-уведомлений

Оба типа Push-уведомлений, как уже было сказано ранее, могут быть выполнены с помощью PushNotificationChannel. При этом для взаимодействия, например, с Windows Notification Service (WNS, сервис, обеспечивающий работу с уведомлениями и каналами), необходимо выполнить следующие шаги:

  1. Зарегистрировать приложение в Магазине Windows (Windows Store).
  2. Получить SID и Client Secret, значения которых будут использоваться для аутентификации в WNS.
  3. Во время выполнения приложения запросить URL канала WNS. Серверу WNS необходимо знать информацию о получателе или получателях – это может уникальное устройство либо уникальный пользователь. Устройство (device) может быть использовано большим количеством пользователям, пользователи могут использовать несколько устройств. Эта идентификационная информация используется URL канала. Приложение должно получить URL канала у Windows API, который будет использоваться далее для коммуникаций с конкретными пользователями или устройствами. Рекомендуемым способом сохранения идентификационной информации (например, GUID устройства) является ее сохранение при первом запуске приложения в локальном хранилище и проверка при каждом последующем. При каждом запуске может происходить запрос нового URL канала (несмотря на то, что URL канала имеет срок "жизни", равный 30 дням, операция запроса нового URL достаточно легковесна и может быть использована вместо реализации логики обновления) и аутентификация пользователя.

Скрипты на стороне сервера конфигурируются с помощью портала управления либо Visual Studio (в новых версиях) и используют в качестве собственного бэкенда виртуальную машину с процессом Node.js – разработчик может использовать модули, например:

  • Request – для работы с HTTP-запросами
  • Push.* - для инкапсуляции всей работы с Push-нотификациями со всеми популярными сервисами APNS, GCM, WNS, MPNS
  • Console – для логирования
  • MSSQL – для выполнения собственных T-SQL запросов и выполнения хранимых процедур
  • statusCodes – возврат HTTP-кодов
  • Azure – для получения доступа к другим сервисам Azure - Windows Azure Storage, Service Bus и др.
  • Sendgrid – для посылки почты
  • Twilio – посылка SMS-сообщений и Voice Mail

Функциональной обвязкой для REST API является автоматически генерируемый набор скриптов, перехватывающий запросы к таблице 4-х основных типов. Так как мобильные сервисы работают на базе Node.js, то и скрипты пишутся на Node.js. По умолчанию эти скрипты работают в режиме Pass-through, то есть перехватывают запрос и переводят его в источник данных (SQL Azure Databases) в том же виде, в каком он пришел на сервер. Это поведение является настраиваемым – от самой простой логики, например, валидации пришедших в запросе данных, до более сложной, включающей, например, работу с источником данных.

Одной из новых функций стала внедренная летом 2013 года интеграция Git-based систем контроля версий для серверных скриптов. Эта интеграция предоставляет возможность локального редактирования скриптов (например, в Visual Studio) – изменения попадают в локальный репозиторий Git, который синхронизирует свое состояние с сервером.

Подробная информация про скрипты на стороне сервера находится на MSDN: http://msdn.microsoft.com/en-us/library/windowsazure/jj554226.aspx

Скрипт-перехватчик операции Insert

Рис. 14.7. Скрипт-перехватчик операции Insert

Планировщик задач

В сервисе Windows Azure Mobile Services есть собственный планировщик задач, полезный в тех сценариях, когда необходимо определить код на стороне сервера, который должен выполняться по расписанию, определенному разработчиком. Помимо других предложений планировщиков задач (например, реализации планировщика задач с помощью Cloud Services или Cloud Based CRON Scheduler), Windows Azure Mobile Services Scheduler является интегрированным в платформу средством, с помощью которого можно реализовывать такие задачи, как, например, периодическое обновление и сохранение данных из внешних и внутренних сервисов.

Выполнение кода возможно по следующим временным промежуткам:

  • Раз в X минут
  • Раз в Y часов
  • Раз в M дней
  • Раз в N месяцев

Где переменная может быть равна тем значениям, которые заданы для каждого промежутка, например, для месяцев это могут быть значения 1, 2 и 3.

Создание задачи в планировщике

Рис. 14.8. Создание задачи в планировщике

Примеры использования планировщика Windows Azure Mobile Services:

  • Удаление устаревших данных из хранилища
  • Получение данных из внешних источников
  • Обработка файлов, например, изображений
  • Отправка Push-уведомлений по расписанию
< Лекция 9 || Лекция 10: 1234 || Лекция 11 >
Руслан Муравьев
Руслан Муравьев

Сайт dreamspark пишет что код истек :(

Andriy Zymenko
Andriy Zymenko

Этот курс требует оновления https://portal.azure.com/#create/hub здесь нет пункта Web Site в разделе Compute. К тому же для создание трубуется подписка